Embed Size (px)
Citation preview
EXPERIMENTAL STUDIES OF WIRELESS
COMMUNICATION AND GNSS KINEMATIC
POSITIONING PERFORMANCE IN
HIGH-MOBILITY VEHICLE ENVIRONMENTS
Ming Qu
Submitted in fulfilment of the requirements for the degree of
Master of Information Technology (research)
Faculty of Science and Engineering
Queensland University of Technology
March, 2012
Keywords
3G network; vehicle positioning; RTK; PPP; NTRIP
Abstract
In order to support intelligent transportation system (ITS) road safety applications
such as collision avoidance, lane departure warnings and lane keeping, Global
Navigation Satellite Systems (GNSS) based vehicle positioning system has to provide
lane-level (0.5 to 1 m) or even in-lane-level (0.1 to 0.3 m) accurate and reliable
positioning information to vehicle users. However, current vehicle navigation systems
equipped with a single frequency GPS receiver can only provide road-level accuracy
at 5-10 meters. The positioning accuracy can be improved to sub-meter or higher with
the augmented GNSS techniques such as Real Time Kinematic (RTK) and Precise
Point Positioning (PPP) which have been traditionally used in land surveying and or
in slowly moving environment. In these techniques, GNSS corrections data generated
from a local or regional or global network of GNSS ground stations are broadcast to
the users via various communication data links, mostly 3G cellular networks and
communication satellites.
This research aimed to investigate the precise positioning system performances when
operating in the high mobility environments. This involves evaluation of the
performances of both RTK and PPP techniques using: i) the state-of-art dual
frequency GPS receiver; and ii) low-cost single frequency GNSS receiver.
Additionally, this research evaluates the effectiveness of several operational strategies
in reducing the load on data communication networks due to correction data
transmission, which may be problematic for the future wide-area ITS services
deployment. These strategies include the use of different data transmission protocols,
different correction data format standards, and correction data transmission at the
less-frequent interval.
A series of field experiments were designed and conducted for each research task.
Firstly, the performances of RTK and PPP techniques were evaluated in both static
and kinematic (highway with speed exceed 80km) experiments. RTK solutions
achieved the RMS precision of 0.09 to 0.2 meter accuracy in static and 0.2 to 0.3
meter in kinematic tests, while PPP reported 0.5 to 1.5 meters in static and 1 to 1.8
meter in kinematic tests by using the RTKlib software. These RMS precision values
could be further improved if the better RTK and PPP algorithms are adopted. The
tests results also showed that RTK may be more suitable in the lane-level accuracy
vehicle positioning. The professional grade (dual frequency) and mass-market grade
(single frequency) GNSS receivers were tested for their performance using RTK in
static and kinematic modes. The analysis has shown that mass-market grade receivers
provide the good solution continuity, although the overall positioning accuracy is
worse than the professional grade receivers.
In an attempt to reduce the load on data communication network, we firstly evaluate
the use of different correction data format standards, namely RTCM version 2.x and
RTCM version 3.0 format. A 24 hours transmission test was conducted to compare
the network throughput. The results have shown that 66% of network throughput
reduction can be achieved by using the newer RTCM version 3.0, comparing to the
older RTCM version 2.x format. Secondly, experiments were conducted to examine
the use of two data transmission protocols, TCP and UDP, for correction data
transmission through the Telstra 3G cellular network. The performance of each
transmission method was analysed in terms of packet transmission latency, packet
dropout, packet throughput, packet retransmission rate etc. The overall network
throughput and latency of UDP data transmission are 76.5% and 83.6% of TCP data
transmission, while the overall accuracy of positioning solutions remains in the same
level. Additionally, due to the nature of UDP transmission, it is also found that 0.17%
of UDP packets were lost during the kinematic tests, but this loss doesn't lead to
significant reduction of the quality of positioning results. The experimental results
from the static and the kinematic field tests have also shown that the mobile network
communication may be blocked for a couple of seconds, but the positioning solutions
can be kept at the required accuracy level by setting of the Age of Differential. Finally,
we investigate the effects of using less-frequent correction data (transmitted at 1, 5, 10,
15, 20, 30 and 60 seconds interval) on the precise positioning system. As the time
interval increasing, the percentage of ambiguity fixed solutions gradually decreases,
while the positioning error increases from 0.1 to 0.5 meter. The results showed the
position accuracy could still be kept at the in-lane-level (0.1 to 0.3 m) when using up
to 20 seconds interval correction data transmission.
Acknowledgment
Firstly, I would like to acknowledge my supervisor, Prof. Yanming Feng, for his
invaluable guidance and encouragement throughout this one year research master
project. He offered me a great opportunity to get in touch with the GNSS area which
may affect my career life in the future.
I would also like to express my gratitude to my co-supervisor, Prof. Edward Chung,
for his constructive suggestions in determining the research questions of this project,
and his support to me in the study of transport safety issues. The same thankfulness
goes to another co-supervisor, Dr. Charles Wang; this research work would not have
been possible without his patient and detailed advices to my various reports and
thesis.
Special thanks to the Queensland Department of Environment and Resource
Management (DERM) for offering access to SunPOZ data streams in real time for
experimental purposes.
This research project is financially supported by the Queensland University of
Technology (QUT) who offered me the full scholarship and the expenses to attend an
international conference.
Finally, I would like to give my deepest appreciation to my parents and my girl friend,
their selfless love and support is the most helpful spiritual strength for me to
overcome any difficulty in the past one year.
Table of contents
Chapter 1 Introduction ................................................................................................... 1
1.1 Research Background ........................................................................................ 1
1.2 Research Questions ........................................................................................... 4
1.3 Research Objectives and Constraints ................................................................ 5
1.4 Thesis Structure ................................................................................................ 8
Chapter 2 Review of GNSS and Data Communications ................................................. 9
2.1 GNSS and Positioning Technologies .................................................................. 9
2.1.1 Standalone GNSS Positioning .................................................................. 9
2.1.2 Differential GNSS and Space Based Augmentation Systems (SBAS) ..... 11
2.1.3 RTK GPS ................................................................................................. 12
2.1.4 Network RTK and VRS ........................................................................... 12
2.1.6 Precise Point Positioning ....................................................................... 14
2.2 GNSS Data Formats ......................................................................................... 15
2.2.1 RTCM 2.x ............................................................................................... 16
2.2.2 RTCM3 ................................................................................................... 16
2.2.3 CMR ....................................................................................................... 17
2.3 Correction Data Transmission Methods .......................................................... 18
2.3.1 Radio Link .............................................................................................. 18
2.3.2 Internet‐based Communication ............................................................ 18
2.3.3 NTRIP ..................................................................................................... 19
2.4 Network Communication ................................................................................ 22
2.4.1 3rd Generation Mobile Telecommunication Standards ........................ 22
2.4.2 IPv4 and IPv6 Headers .......................................................................... 22
2.4.3 Mobile IPv6 in Vehicle Navigation......................................................... 24
2.4.4 TCP and UDP Protocols ......................................................................... 25
2.4.5 Network Performance Measures .......................................................... 27
Chapter 3 Experiment Designs and Configurations ..................................................... 29
3.1 Experiment Design .......................................................................................... 29
3.2 Field Campaigns .............................................................................................. 30
3.3 CORS and RTK Correction Services .................................................................. 32
3.3.1 SunPOZ CORS Network ......................................................................... 32
3.3.2 International GNSS Service (IGS)........................................................... 32
3.4 Hardware ......................................................................................................... 33
3.4.1 NovAtel DL‐v3 ....................................................................................... 33
3.4.2 U‐blox EVK LEA‐6T ................................................................................. 34
3.5 Software .......................................................................................................... 34
3.5.1 RTKlib .................................................................................................... 34
3.5.2 GNSSsurfer ............................................................................................ 35
3.5.3 Wireshark .............................................................................................. 35
3.5.4 TEQC ...................................................................................................... 36
3.6 Age of Differential ........................................................................................... 37
Chapter 4 Experiment Results and Evaluation ............................................................. 38
4.1 Experiment 1: RTK and PPP Precise Positioning Technologies Performance
Evaluation .............................................................................................................. 38
4.1.1 Experiment Design ................................................................................ 38
4.1.2 Static Test Results .................................................................................. 39
4.1.3 Kinematic Test Results ........................................................................... 44
4.1.4 Research findings .................................................................................. 45
4.2 Experiment 2: Single Frequency and Dual Frequency Precise Positioning
Platforms Performance Evaluation ....................................................................... 46
4.2.1 RTK Static Test ................................................................................ 47
4.2.2 RTK Kinematic test ......................................................................... 51
4.2.3 Solution continuity ................................................................................ 56
4.2.4 Experiments findings ............................................................................. 58
4.3 Experiment 3: RTCM Formats and Network Protocols Evaluation ................. 59
4.3.1 RTCM2.x & RTCM3 transmission experiments ..................................... 59
4.3.2 Evaluation of TCP and UDP in transmitting RTK corrections................. 60
4.3.3 Summary of Experiment 3 .................................................................... 67
4.4 Experiment 4: Different Correction Service Time Interval Assessment .......... 68
Chapter 5 Conclusion and future research .................................................................. 71
5.1 Thesis Conclusions .......................................................................................... 71
5.2 Future works ................................................................................................... 72
Reference ..................................................................................................................... 74
APPENDIX 1 .................................................................................................................. 78
List of Figures Figure 2.1: Network RTK progress (Wegener and Wanninger 2005) ...................................... 13
Figure 2.2: Virtual Reference Station System (Trimble VRS) ................................................... 13
Figure 2.3: NTRIP System Components (Weber, Dettmering et al. 2005) ............................... 20
Figure 2.4: IPv4 and IPv6 header comparison ......................................................................... 23
Figure 2.5: TCP and UDP header structures ............................................................................ 26
Figure 2.6: Example of TCP data transmission with three‐way handshake ............................. 27
Figure 2.7: Example of UDP data transmission without three‐way handshake ...................... 27
Figure 3.1: Experimental equipments setup ........................................................................... 31
Figure 3.2: Kinematic test trajectory ....................................................................................... 31
Figure 3.3: The service coverage of Queensland SunPOZ CORS network ............................... 32
Figure 3.4: NovAtel DL‐v3 GPS dual‐frequency Receiver ........................................................ 34
Figure 3.5: U‐blox EVK 6T ........................................................................................................ 34
Figure 3.6: RTKNAVI, main interface of RTKlib ........................................................................ 35
Figure 3.7: Wireshark interface ............................................................................................... 36
Figure 3.8: Age of Differential ................................................................................................. 37
Figure 4.1: RTK and PPP processing flows ............................................................................... 38
Figure 4.2: RTK and PPP static positioning results –ground track ........................................... 43
Figure 4.3: Solution quality of DL‐v3 and EVK 6T in the static test ......................................... 48
Figure 4.4: variation of DL‐v3 observable satellites in static test ............................................ 50
Figure 4.5: variation of EVK 6T observable satellites in static test .......................................... 50
Figure 4.6: DL‐v3 RTK static positioning results ...................................................................... 51
Figure 4.7: EVK 6T RTK static positioning results .................................................................... 51
Figure 4.8: Solution quality of DL‐v3 and EVK 6T in kinematic test ........................................ 53
Figure 4.9: valid satellites and AoD of DL‐v3 in kinematic test ............................................... 55
Figure 4.10: valid satellites and AoD of EVK 6T in Kinematic test ........................................... 55
Figure 4.11: the positioning results of DL‐v3 and EVK 6T in kinematic mode ......................... 56
Figure 4.12: Overall experiment architecture (MCD) .............................................................. 61
Figure 4.13: Packets transmission graphic of TCP (left) and UDP (right) ................................. 63
Figure 4.14: TCP packets capture list ....................................................................................... 63
Figure 4.15: UDP packets capture list ...................................................................................... 63
Figure 4.16: AoD for static TCP (top diagram) and UDP (bottom diagram) solutions ............. 64
Figure 4.17: static (left) and kinematic (right) trajectories for TCP/UDP transmission ........... 65
Figure 4.18: Quality of positioning solutions for TCP/UDP ..................................................... 65
Figure 4.19: position variations of TCP static solutions in E (up) and N (bottom) directions .. 66
Figure 4.20: Solution qualities in different correction data intervals ...................................... 69
Figure 4.21: Accuracy of all solutions under different time intervals of correction data service
......................................................................................................................................... 70
Figure 4.22: Accuracy of fixed only solutions under different time intervals of correction data
service ............................................................................................................................. 70
List of Tables
Table 4.1: Accuracy of DL‐v3 RTK and PPP real time results in static test ............................... 41
Table 4.2: Accuracy of DL‐v3 RTK and PPP real‐time results in kinematic test ....................... 45
Table 4.3: Accuracy of DL‐v3 and EVK 6T (RTK all solutions and fixed only solutions) in static
test .................................................................................................................................. 49
Table 4.4: Accuracy of DL‐v3 and EVK 6T (RTK all solutions and fix only solutions) in
kinematic test .................................................................................................................. 54
Table 4.5: Discontinuous solutions of DL‐v3 and EVK 6T when passing under the bridges .... 57
Table 4.6: solution continuity statistics for the kinematic test................................................ 58
Table 4.7: network throughput of three mount points with different RTCM versions ........... 60
Table 4.8: Network transmission results in static test ............................................................. 62
Table 4.9: Position difference between TCP/UDP real‐time static RTK solutions and the
reference point in E and N directions .............................................................................. 66
Table 4.10: Position difference between TCP/UDP real‐time kinematic RTK solutions and the
reference point in E and N directions .............................................................................. 67
List of Abbreviations
A-GPS: Assistant GPS
CMR/CMR+: Compact Measurement Record
DGPS: Differential GPS
DSRC: Dedicated Short-Range Communications
GNSS: Global Navigation Satellite Systems
GPS: Global Positioning System
HSPA: High Speed Packet Access
IGS: International GNSS Service
IP: Internet Protocol
ITS: Intelligent Transportation System
MCU: Mobile Computing Unit
NMEA: National Marine Electronics Association
NTRIP: Networked Transport of RTCM via Internet Protocol
PPP: Precise Point Positioning
RTCM: Radio Technical Commission for Maritime Services
RTK: Real Time Kinematic
SUPL：Secure User Plane
TCP: Transport Control Protocol
TTFF: Time to First Fix
UDP: User Datagram Protocol
UMTS: Universal Mobile Telecommunication Service
Statement of Original Authorship
The work contained in this thesis has not been previously submitted to meet
requirements for an award at this or any other higher education institution. To the best
of my knowledge and belief, the thesis contains no material previously published or
written by another person except where due reference is made.
Signature: _________________________
Date: _________________________
Chapter 1 Introduction
1.1 Research Background
Until 2010, there were roughly 800 million vehicles on the roads worldwide (OICA
2010) and the number is rapidly increasing. As a result, transportation always faces
significant challenges such as road safety, traffic congestion and greenhouse gas
emissions. Road accidents are a leading cause of deaths worldwide. It is estimated
that 1.2 million people are killed, and over 50 million are injured each year as a result
of road accidents. Road safety is a serious problem in Australia. In 2008, 1463 people
were killed in road accidents, and over 22,000 were seriously injured in Australia
(Department of Infrastructure and Transport 2009). One widely adopted solution is
through the use of the Intelligent Transportation Systems (ITS), which integrates
various information and communications technologies into both vehicles and roadside
infrastructures. The addition of wireless communications offers a powerful and
transformative opportunity to establish transportation connectivity that further enables
cooperative systems and dynamic data exchange. In Australia, this transformative ITS
solution is explicitly known as the Cooperative-Intelligent Transportation Systems
(C-ITS). C-ITS employs vehicle to infrastructure (V2I) and vehicle to vehicle (V2V)
(V2X for both V2V and V2I) communications to connect transport infrastructures,
vehicles and travellers, in order to make road travel safer, faster, cleaner and more
convenient. The precise position information obtained from through its onboard
Global Navigation Satellite Systems (GNSS) based platform, is used not only to
locate and navigate the vehicle, but is also used to share its position with surrounding
vehicles to provide cooperative traffic management and collision avoidance (Du and
Barth 2008).
Requirements for vehicle positioning systems for ITS safety applications have been
studied in a number of international ITS projects and have also attracted research
1
attentions. In general, this is a development stage. The first systematic effort was the
Enhanced Digital Maps (EDMaps) project conducted by the USA Department of
Transport’s Intelligent Vehicle Initiative (IVI) (IVI Light Vehicle Enabling Research
Program 2004). The project was performed by four vehicle OEMs (DaimlerChrysler,
Ford, General Motors and Toyota), together with a commercial map database supplier
(NAVTEQ, Federal Highway Administration and National Highway Traffic Safety
Administration). This project classified the types of vehicle positioning system in two
levels:
Road level; which road the vehicle is placed on
Lane level; which lane the vehicle is in or where the vehicle is in the lane.
Road level positioning, which enables the vehicle to position itself on a road,
generally requires about 5- to 10-metre horizontal location Root Mean Square (RMS)
precision. For most road level applications, it is necessary only to know which road
the vehicle is travelling on. Examples are Curve Speed Assistant Warning (CSA-W),
and Stop Sign Assistant Warning (SSA-W) and Location-based Hazard Warning
(LBH-W). The current vehicle navigation system can marginally meet these
requirements. The road maps that are used by the current vehicle navigation systems
are merely accurate to the road level; they are not sufficiently detailed for safety
purposes.
For most of ITS safety applications, it is necessary to know which lane the vehicle is
travelling in. Examples include Traffic Signal Assistant Warning (TSA-W) and
Intersection Collision Warning (ICW). These require a positional accuracy of 0.5 to
1.0 m (IVI Light Vehicle Enabling Research Program 2004). Examples of General
Motors safety applications requiring the same level of accuracy also include ICW,
Blind spot warning, Forward Collision Warning (ICW) and Lane change warning. For
other lane-level applications, such as Lane Departure Warning (LDW), it is necessary
to know where the vehicle is within the lane, thus requiring positional accuracy better
2
than 0.3 m (IVI Light Vehicle Enabling Research Program 2004). The positioning
system has to provide the vehicle with a lateral offset from the lane centreline.
The current and most widely used vehicle navigation systems are based on single
frequency standalone Global Positioning System (GPS) chips that can provide only
road-level accuracy, mainly because of the errors created by the satellites orbits,
clocks, ionospheric and the effects of multipath.
The solution for eliminating errors and achieving higher precision is to apply
corrections for various biases generated from either a vicinal precisely located
reference station or a regional or global network of reference stations to the rover
GNSS users in real-time. There are a number of positioning methods that can
potentially offer required positioning performance depending on how these
corrections are generated and delivered to users.. Smoothed Differential GPS (SDGPS)
technique using code phase measurement (also referred to as pseudo range corrections)
can provide sub-meter level accuracy service, while Real Time Kinematic (RTK) GPS
could achieve centimetre level accuracy by utilizing carrier phase measurements
(Soares, Malheiro et al. 2004). In recent years, the GPS Precise Point Positioning
(PPP) technique using a single GNSS receiver with precise orbits and clock correction
data from the International GNSS Service (IGS) has also become an attractive
solution for achieving centimetre to decimetre accurate positioning results (Kouba and
Heroux 2001).
Conventionally, GPS correction data are broadcasted to users using VHF and UHF
radio links, which has some drawbacks in terms of the transmission range and the
capability of resisting signal interference. Since the early 2000s, wireless mobile
communication has become a preferred option as it provides more reliable correction
data service over wide areas. Third generation technology is especially designed for
high quality fast Internet Protocol (IP)-based data communication (Liu 2004). In order
to disseminate GNSS observation and differential correction data over IP capable
3
communication links, the application-level protocol, Networked Transport of RTCM
via Internet Protocol (NTRIP), has been designed and developed.
These techniques have usually provided GNSS correction services only to static
and/or low mobility users, such as land surveying, mining and agriculture machinery.
The question is if these techniques can work properly in high mobility environments
to satisfy the requirements for safety applications. Meanwhile, for massive vehicle
users equipped with precise positioning technologies, the onboard positioning units
will have to be affordable for drivers. Most vehicles will have to rely on mass-market
products that can generate raw measurement data to provide positioning solutions. In
addition to needing these expensive professional grade GNSS receivers, the question
is to what degree a typical low-cost GNSS receiver can meaningfully satisfy the
required positioning accuracy for ITS purposes. In addition, the ongoing cost based on
wireless network data transmission throughput, will be the other important aspect for
users to consider, as the usage could be many hours per day.
1.2 Research Questions
This research aims to evaluate GNSS RTK and PPP performance in conjunction with
GNSS correction data transmission via NTRIP or other internet links (TCP or HTTP
server) with high mobility vehicles.
Current vehicle navigation systems still use standalone GPS receiver or A-GPS
technology. A-GPS can improve only the Time-To-First Fix (TTFF), not the precision.
The positioning accuracy offered by code-based DGPS is typically a few metres,
which is not sufficient for most ITS safety applications which require the sub-metre
accuracy or better, as outlined in Section 1.1. On the other hand, although GPS RTK
and PPP technologies could in principle provide high accuracy positioning services,
they have so far been applied in real time mainly to survey, marine navigation, and
4
low dynamic machinery. The communication data links and the hardware/software
systems have demonstrated to work well in static and low mobility environments, but
their performance remains unknown in high mobility environments. In addition, the
price of professional grade equipment is very expensive to individual clients.
Therefore, the first question of this research project is:
Q1: What accuracy can the precise positioning technologies reach when
working in high mobility environments?
In the future, when a large number of vehicles equipped with safety systems are
running on roads, network-based precise positioning applications will require a much
wider network bandwidth and more stable network service to provide service to all
the users simultaneously. This demand for communication networks raises the second
question of this research project:
Q2: What strategies can be taken to reduce the correction transmission load on
the communication network for future wide-area deployment?
1.3 Research Objectives and Constraints
The duration of this master research has been limited to 12 months. Therefore, the
work has focused on the above questions, rather than attempting to cover all aspects
of GNSS positioning performance and mobile telecommunication in vehicle
navigation. This research has three main objectives.
Objective 1: Experimentally study the performance of precise positioning
technologies in high mobility environments, focusing on RTK and PPP real-time
capability. RTK has been the most popular precise positioning solution in mining
operation and agricultural fields, while PPP is the latest emerging precise positioning
technology. This research component aimed to experimentally study the performance
5
of these two precise positioning technologies in order to determine potential solutions
for vehicle precise positioning systems for road safety purposes.
Objective 2: Experimentally compare the professional grade GNSS receivers with
mass-market grade products. The price of the positioning unit is an important factor
that should be considered in a large-scale application. Professional grade GNSS
products (usually equipped with dual-frequency receiver chips and antennas) could
have their prices reduced to some extent, but could still be unavailable to low- and
medium-class. On the other hand, the mass-market grade GNSS products (usually
equipped with single-frequency receiver chips and antenna) could be much more
affordable, but could be less suitable in term of performance. It is necessary to
compare these two different types of devices and gain some insights into the potential
for performance improvement for vehicle precise positioning applications.
Objective 3: Experimentally study a more efficient method to deliver GNSS
correction data for its future massive implementation in ITS. The study will
compare the RTCM 2.x and 3.0 correction messages in throughput, variation of
transmission speed and number of satellites in review. The study also includes
analysis of two network protocols in delivering GNSS correction data packages: TCP
and UDP. They all have pros and cons in terms of the data transmission efficiency,
reliability and security. UDP was treated as a mere connectionless and unreliable
protocol than TCP; however, with the support of RTP in the NTRIP version 2, UDP
transmission was enhanced in reliability. On the other hand, UDP has a more efficient
encapsulation format and a simpler connection mechanism which can provide a
low-data-consumption data delivery service to users.
Objective 4: Simulate different correction service time intervals and examine their
impact on the quality of positioning solutions. Expanding the interval of correction
data transmission could be another strategy to reduce the data transmission
throughputs. However, to what extent can the correction transmission interval be
6
extended without affecting the positioning results? This will be tested by simulations
in the solution post processing.
This project has four constraints.
Constraint 1: Field test environment -- Brisbane M3 Highway
The Brisbane M3 highway (upper Mount Gravatt to CBD segment) is chosen as the
experimental field in this research. M3 is part of the Pacific Motorway between
Brisbane in Queensland and Tweed Heads in New South Wales. The motorway
features four to six lanes with up to 110-km/h speed limit. The test network is fully
covered by the Next G network, and the typical customer download speed is between
550 kbps and 3Mbps(Telstra 2011).
Constraint 2: High mobility platform – passenger vehicle
On the M3 highway, because of the Queensland road rules, all vehicles should be
driven with the maximum speed limit of 110 km/h.
Constraint 3: Mobile wireless network platform – Australia Telstra NextG network
As the leading Australian telecommunications and information services provider,
Telstra provides 12.2 million mobile services throughout Australia. The Telstra Next
G network has covered almost 99% of the Australian population (Telstra 2011).
Constraint 4: The GNSS correction sources – local and global GNSS reference
networks
One reference station located at the Land Centre in Woolloongabba was chosen to
stream RTK correction data to the Mobile Computing Unit (MCU) via Queensland
SUNPOZ NTRIP caster. Another stream from the International GNSS Service (IGS)
Real-time Pilot Project provided precise GNSS satellite orbits and clocks for Precise
Point Positioning (PPP) via the NTRIP caster.
7
1.4 Thesis Structure
The rest of the thesis is divided into four chapters:
Chapter 2 reviews the GNSS technologies being used in common precise positioning
areas and previous experiments in employing them in high mobility environments.
Various GNSS data formats are also discussed, including their structure and message
contents. To deliver this correction information wirelessly to the rovers, conventional
and novel communication methods are introduced and their speed, latency and
reliability compared. Current and future network protocols are compared in this
chapter as well.
Chapter 3 introduces the methodology to address the research questions stated in
Chapter 1. General ideas are described first, and then the relevant hardware and
software are introduced, outlining especially their particular configurations that fit the
purpose of this research.
Chapter 4 presents four scenarios to experimentally examine and to compare the
performance of precise positioning technologies from different aspects. Scenario 1
compares RTK and PPP in the high mobility environment. Scenario 2 contrasts the
RTK performance of professional grade and mass-market grade GNSS receivers.
Several sets of field test results collected from static and kinematic environments are
discussed in these scenarios. Scenario 3 tests the network throughput of different
versions of RTCM correction data in 24 hours and also presents another field test to
examine the solution quality that could be achieved by UDP transmission, compared
with TCP. Scenario 4 introduces a simulation experiment to discover a time unit
suitable for use in transmitting the correction data with a low throughput but with no
significant degradation to positioning results.
Chapter 5 concludes the research with the findings and an outline for future works.
8
Chapter 2 Review of GNSS and Data
Communications
This chapter provides an overview of GNSS technologies and network concepts for
mobile positioning, including current GNSS, various precise positioning techniques,
network transmission protocols and the applications to transport GNSS correction
data via the internet.
2.1 GNSS and Positioning Technologies
2.1.1 Standalone GNSS Positioning
Global Navigation Satellite Systems (GNSS) is the standard generic term for any
satellite navigation systems that include satellites, ground infrastructures and user
receiving equipments to provide geo-spatial positioning services worldwide.
Currently there are two GNSS systems that can provide global positioning service;
GPS from USA and GLONASS from Russian. Two other Global Navigation
Satellites Systems being developed include the European Union’s Galileo positioning
system and the Chinese Beidou navigation system, Compass. The former has 2 IOV
satellites in orbit (Oct 2011) and the later has launched its 9th satellites recently and
will form the constellation of 12 satellites by the end of 2012 for regional positioning
capabilities and by 2020 for global services. Other regional GNSS systems under
development are the Indian Regional Navigation Satellite System (IRNSS) and the
Quasi-Zenith Satellite System (QZSS) from Japan. Australia will be one of the few
countries on earth with the ability to receive signals from all of these GNSS/RNSS
systems (Queensland Department of Environment and Resource Management 2010).
The existing vehicle positioning systems are predominately based on the US Global
Positioning System (GPS), although some are able to receive the GLONASS signals
9
for improved positioning availability. Using a standard low-cost single frequency
receiver and code-phase measurement, stand-alone GPS has the capability to achieve
a horizontal Root Mean Square (RMS) precision of 5m to10m with the standard point
positioning (SPP) algorithms. SPP estimates the user locations epoch by epoch with
broadcast GNSS ephemerides and code measurements corrected by standard
troposphere models.
Like many other worldwide positioning, navigation and timing (PNT) users, vehicle
positioning users can expect significant performance benefits from multi-GNSS
receivers which may receive and process ranging signals from any 2 to 4 of the GNSS
constellations. PNT performance is usually represented by parameters such as
accuracy, availability, continuity and integrity. Multiple GNSS constellations will
certainly increase PNT availability and continuity, and will satisfy the requirements of
mass market users. However, under multi-constellation GNSS conditions, two serious
challenges still remain to be addressed. One challenge is the integrity of these satellite
systems, because more signal-in-space failures can occur with more satellite systems.
Integrity of satellite systems is a measure of the trust that can be placed in the
correctness of the information supplied by the system. Integrity includes the ability of
a system to provide valid and timely warnings or “alerts” to the user (eg. within 6
seconds) when the system must not be used for the intended operations. An integrity
requirement is essential for safety-critical users such as aviation, maritime, and land
transportation for road safety applications. There are rapidly growing needs for
integrity features in liability-critical applications such as machine automation in
agriculture and mining operations, and for PNT within critical infrastructure. Another
challenge is the accuracy of PNT solutions, which still suffer from the effects of
systematic errors such as satellite-specific and atmosphere-specific delays in all
GNSS measurements. As a result, a multiple GNSS receiver may improve the
positioning accuracy to a factor of 2 or so, but still cannot offer lane-level positioning
accuracy.
10
2.1.2 Differential GNSS and Space Based Augmentation
Systems (SBAS)
The Differential Global Positioning System (DGPS) is an enhancement to GPS that
uses a single station or a network of ground-based reference stations to generate
differential corrections for systematic ranging errors common to users within a certain
geographic coverage. These corrections prepared in the RTCM SC 104 formats, are
broadcast to users via data links such as Internet, cellular networks or VHF data links.
Typically, using code measurements and standard positioning algorithms, GPS users
can determine the position state to the accuracy of 1 to3 metres, while multiple GNSS
users may expect horizontal positioning solutions with the accuracy of 0.5 to 2
metres.
In the USA, standalone GNSS vehicle navigation systems have options to receive
Wide Area Augmentation Systems (WAAS) ranging signals and corrections to
improve the positioning accuracy to the level of 1 to 3 metres. European
Geostationary Navigation Overlay Services (EGNOS) began operating in 2009. Both
WAAS and EGNOS are Satellite Based Augmentation Systems (SBAS). A
satellite-based augmentation system is a system that supports wide-area or regional
augmentation through the use of additional satellite-broadcast messages which are
generated from a network of ground stations. SBASs are also part of the multi-GNSS
definition. However, the signals of SBAS are limited to the coverage of the ground
network and the geostationary satellites footprints. Australia is out of the coverage. In
addition to correction signals, SBAS also provides integrity messages and additional
availability to road users. In Australia, hundreds of available ground GNSS stations
can be used to provide corrections in RTCM SC 104 format as similar data services to
vehicle users. The key problem is again that direct use of code-based DGPS technique
and SBAS still cannot offer lane-level positioning services.
11
2.1.3 RTK GPS
RTK is the acronym of Real-Time Kinematic. DGPS positioning accuracy cannot
satisfy the requirements from precise measurement fields such as land surveying,
vehicle collision avoidance systems. The centimetre-level positioning accuracy can be
obtained only through carrier phase measurement in real-time using the RTK
technique. However, the rover should be within the range of 20 km from a reference
station if it works in a single-based RTK mode. Otherwise, the distance dependent
error will be significant and cause the solutions to fail. Moreover, if there are several
rover DGPS receivers working for a large project, and they acquire correction data
from different reference stations, the error would be enlarged as these reference
stations may have different levels of accuracy (El-Mowafy and Al-Musawa 2009).
Although the accuracy and the reliability can be improved by utilizing dual-frequency
receivers (L1&L2 frequencies) and by combining GPS and GLONASS, there is still
an error source in the RTK technique: the data latency from reference stations and
rover receivers. This latency is caused by transmission delay, decoding and software
handling; the value could range between 100ms to several seconds. El-Mowafy and
Al-Musawa’s research proposed a prediction algorithm based on the constant
measurement corrections within a short period of time.
2.1.4 Network RTK and VRS
The main systematic errors in RTK positioning data processing are multipath,
atmospheric and ephemeris errors etc (Vollath, Landau et al. 2002). To reduce the
effects of such errors, as well as to extend the possible distance between rover
receiver and reference station, RTK reference networks are designed to link all
stations to a central data processing centre to optimize the calculation and provide
real-time, high-quality positioning service to rovers, As illustrated in Figure 2.1.
12
Figure 2.1: Network RTK progress (Wegener and Wanninger 2005)
Based on this concept, the virtual reference station (VRS) was proposed to generate
observation data from a virtual station close to the rover user. It could significantly
reduce the effects of observation errors in double difference phase measurements and
improve the accuracy over longer distance (Retscher 2002), as shown in Figure 2.2.
Firstly the user determines its approximate position by an uncorrected solution; it is
then sent to the computing centre with NMEA messages through the mobile phone
network. The virtual reference station data can be returned to the user immediately.
Figure 2.2: Virtual Reference Station System (Trimble VRS)
13
2.1.6 Precise Point Positioning
Different with the structure of differential GPS which needs to set ground-based
reference stations and broadcast measured correction data to rover receivers, Precise
Point Positioning (PPP) can provide centimetre level positioning accuracy for static
applications and sub-decimetre accuracy for kinematic applications from a single
receiver with real-time access to precise GPS orbits and clock corrections. PPP is very
cost effective, has simple operation and is globally available, all of which has
attracted much interest from GPS positioning and navigation community.
StarFireTM, a good example of commercial services based on PPP algorithms is
actually a global satellite based augmentation system. StarFireTM was designed and
operated by Navcom. Unlike regional SBAS solutions such as WAAS and EGNOS, it
utilizes more than 60 GPS reference stations around the world to compute GPS
satellite orbit and clock corrections. These data are uploaded to three geostationary
satellites and broadcast to worldwide receivers. The StarFireTM network began
commercial operation in 1999 and has expanded its service into land survey and
Aerial Mapping (NAVCOM 2011). To reach optimal performance, StarFireTM users
are equipped with GNSS and L-Band receiver hardware that is integrated with inertial
sensors to reduce the convergence time for PPP algorithm. According to Dixon tests,
the StarFireTM PPP network responds much more quickly than the GPS Master
Control Station to anomalous GPS behaviour; the user clock and orbit errors are less
than 8 cm in StarFireTM, compared with IGS final values; and the Quick-start feature
can eliminate convergence times. This research has also determined that after up to 20
minutes of losing connection with StarFireTM corrections, the horizontal accuracy can
still be maintained at its decimetre level (Dixon 2006).
Like other precise positioning systems, GPS PPP methods have also been evaluated in
the vehicular environment. (Honda, Murata et al. 2006) have developed generic
software that uses both pseudo range and carrier phase data from a dual frequency
14
receiver and IGS precise satellite ephemerides and clock corrections. The IGS
officially provides three categories of products for precise orbits and clocks:
UltraRapid, Rapid, and Final (Kouba 2003). In this research, Kouba proposed to use
Rapid orbit and clock products, the Extended Kalman Filter (EKF) and the Unscented
Kalman Filter (UKF) as the estimation methods. After the on-board experiments and
post-processing by this particular software, decimetre level point positioning accuracy
can be achieved in kinematic mode, which is similar to kinematic DGPS.
To eliminate the ionospheric effect and other errors, use of dual-frequency GPS
receiver is suggested in PPP. However, as many of the GPS receivers currently being
used are single-frequency, Gao, Zhang and Chen designed a real-time PPP
architecture to utilize single-frequency equipment(Chen and Gao 2005). Its decimetre
accuracy was achieved by road and marine testing. The single GPS receiver tested
in these experiments can get decimetre to sub-meter level kinematic positioning
accuracy. Using the methods and algorithms reported in their previous research to
support both commercial product development and the Internet-based Global
Differential GPS (IGDG) service from Jet Propulsion Laboratory (JPL).
2.2 GNSS Data Formats
GNSS data format is important for efficient correction data transmissions. It specifies
the message structure and the encoding methods used when representing the
observation or correction information. In the internet-based GNSS operation, the
minimum bandwidth to transmit this information depends on the types of message
being generated at the reference station and on the message period. Also the position
error will grow with the increase of data transmission latency (Liu and Gao 2001).
By using optimized formats for particular GNSS receivers or programs, a more
efficient and reliable performance can be achieved.
15
This section will introduce various GNSS data formats including public standards
from non-profit organizations and dedicated standards designed by GNSS
manufacturers to fit their own software and hardware.
2.2.1 RTCM 2.x
The RTCM-recommended Standards for Differential Navstar GPS Service version 2.0
was published in 1990. After further revising versions 2.1 and 2.2, the latest version
of RTCM 2.x is RTCM 2.3, published in 2001 (RTCM SC-104 2001).
Version 2.3 added several new messages to improve RTM, radio beacon broadcasts,
and use of Loran-C. RTCM message types 18 and 19 are the most important messages
for RTK positioning, usually output at 1 Hz frequency. Message Type 18 has the raw
carrier-phase measurements for RTK, while Message Type 19 contains the raw
pseudo-range measurement for RTK as well. To the dual-frequency GPS observation
at one epoch, the message size for both pseudo range and carrier-phase measurement
can be calculated as follows (Yan 2008):
M = 37.5 * Ns (1)
M represents the message size (bytes), Ns represents the number of satellites tracked.
However, RTCM version 2 was inefficient and independent in its parity scheme.
2.2.2 RTCM3
Version 3.0 of the RTCM-recommended Standards for Differential GNSS Service
was published in 2004. These standards are more efficient, with both higher integrity
and simplicity of development as well (RTCM SC-104 2004). The main aim of
RTCM 3.0 is to improve RTK. After an update version from version 3.0 in 2006,
RTCM standard 10403.1 can support Network RTK. New GPS and GLONASS
messages were also added; as well, some GNSS venders and service providers who
16
can encapsulate their own information into the messages were also added. In RTCM
version 3.0, message types 1003 and 1004 provide pseudo-ranges and the phase range
of dual-frequency GPS RTK, while message types 1011 and 1012 provide similar
data for GLONASS RTK operation.
The size of message type 1003 (similar to message type 1011) can be calculated as
follows(Yan 2008):
M = 8 + 12.625 * Ns (2)
While the size of message type 1004 (similar as message type 1012) can be calculated
as follows:
M = 8 + 15.625 * Ns (3)
M represents the message size (bytes), Ns represents the number of satellites tracked.
2.2.3 CMR
The Compact Measurement Record (CMR) format was first developed in 1996 by
Trimble Navigation an advanced positioning solutions provider for a worldwide
market (Trimble Navigation 2011). CMR was designed to resolve some of the
drawbacks in the RTCM-SC104 format, especially the high bandwidth consumption
and the large framing overhead in RTCM version 2.x. CMR also uses data
compression algorithms to reduce the data size of each epoch: the bandwidth could be
as low as 2400 baud per second, which is less than 50% of the equivalent RTCM
format (Talbot 1996). Because the CMR standard has been openly published, all other
GNSS equipment manufacturers can use it to compress their own data for multiple
purposes. In 1997, CMR+ was published as the revised version of CMR to reduce the
peak throughput requirements by 40% (Talbot 1997).
17
2.3 Correction Data Transmission Methods
The performance of a real-time positioning system is highly dependent on the data
link component between reference stations and rovers (Talbot 1996). The
conventional options, including UHF/VHF radio broadcast, wired network, mobile
internet and satellite link, provide different service quality of bandwidth, coverage
and communication cost.
2.3.1 Radio Link
To achieve high survey accuracy, DGPS, RTK and PPP all need the support of
correction data to eliminate several kinds of errors. Data transmission is usually via
UHF or VHF radio broadcasting to users. However, is the radio link has a typical
short transmission range of low-powered systems caused by obstacles located in the
path between a base station and a mobile receiver. The maximum transmission
distance of radio frequency signals is ideally at 50 kilometres. The signal interference
is another drawback: the shadowing and signal loss can reduce transmission range and
cause poor signal quality (Kim and Langley 2003).
2.3.2 Internet‐based Communication
With the rapid development in Internet applications and next generation mobile
network, it could be an alternative solution for transmitting correction data. The
advantages of utilizing the Internet for high accuracy GNSS positioning systems are
not only the longer transmission distance but also the reliability and security service it
can provide.
A reference station can be set as a server to broadcast its correction data to the client
who would need to know the IP address and port to connect. It will be inconvenient to
remember a list of IP addresses if a user needs to switch frequently between them. To
18
the server, a large number of concurrent connections from clients may cause denial of
service. Another problem is the network security, a public IP address usually suffers
more threaten from the internet. It is also wasteful to install extra firewall or secure
software to guard each of the reference stations all alone. A new network delivery
method is required to make up these drawbacks.
2.3.3 NTRIP
NTRIP stands for Networked Transport of RTCM via Internet Protocol. It is based on
the Hypertext Transfer Protocol HTTP/1.1; the NTRIP Caster is the actual HTTP
server program while the NTRIP Client acts as HTTP clients (Weber, Dettmering et al.
2005).
NTRIP is a generic, stateless protocol based on the Hypertext Transfer Protocol
HTTP/1.1 that is enhanced to GNSS data streams (Weber, Dettmering et al. 2005). It
is an internet-based application used for high-accuracy positioning and navigation.
This new technique was developed out by the Federal Agency for Cartography and
Geodesy (BKG), together with partners including the University of Dortmund and
Trimble Terrasat GmbH.
According to the NTRIP specification (RTCM) version 2.0, as illustrated below in
Figure 2.3,the NTRIP system consists of:
NTRIP Sources, GNSS receivers that provide continuous GNSS data such as
RTCM-104 corrections referring to a known or specific location
NTRIP Servers, servers that transfer the data streams from NTRIP sources to a
third installation (the NTRIP caster)
NTRIP Caster, a HTTP server that acts as a broadcaster integrated between the
data sources (NTRIP server) and the data receiver (NTRIP clients)
19
NTRIP Client, fixed or mobile users who can access data stream of desired
source at the NTRIP Caster. (Lenz 2004)
Figure 2.3: NTRIP System Components (Weber, Dettmering et al. 2005)
To test and compare the achievable accuracy of different GPS receivers, especially
the affect of the new NTRIP technique, Dammalage, Srinuandee, Samarakoon and
Susaki conducted a field experiment comparing two high accuracy GPS receivers
(Trimble ProXR GPS receiver, SOKKIA GSR2600 receiver) and one low accuracy
GPS receiver (Garmin eTrex) under post-processing, radio-RTK differential corrected
observations, and NTRIP with uncorrected observations situation. The results showed
that all these GPS receivers could get more accurate observation values than RAW
observations, but that the results generated from conventional DGPS and RTK
techniques were similar in accuracy. Another important field test result from their
work is that the handheld GPS receiver can promote its observation accuracy from
5m-10m to 1m-3m by receiving internet DGPS streaming based on NTRIP
(Dammalage, Srinuandee et al. 2006).
Uradzinski, Jingnan & Weiping evaluated the performance of NTRIP/RTK solutions
for accurate and precise car navigation and proposed to develop a functional system
of determining lane positions on highways. As the lane change collision avoidance
system requires very high relative accuracies between moving objects, they designed
20
a Relative Moving Base Software (RMBS) implemented in real time into GNSS
receivers to cooperate with the NTRIP/RTK solution. Their experiments showed this
solution to be suitable for practical application controlling vehicle motion for driver
assistance (Uradzinski, Jingnan et al. 2010).
Rohm designed a DGPS application in mobile phones to increase the accuracy of
mobile phone positioning by using an internet data link. This software consists of
three parts: a NMEA (National Marine Electronics Association) decoder part, NTRIP
Client software, and the DGPS solution. (Rohm 2011) The NMEA decoder transfers
the measurements (pseudo ranges residuals, almanac, coordinates), to the required
form/file, and the NTRIP Client connects to the port on the NTRIP Caster to
download the pseudo-range corrections data, so the ephemeris could speed up the fix
time. Finally the DGPS solution can be delivered as simply as possible to speed up the
processing.
As these tests were conducted with a TCP connection using NTRIP version 1.0 in a
small-scale deployment environment, the introduction of UDP connectivity in NTRIP
version 2.0 may be useful for ITS road safety applications where thousands of
connections may be made simultaneously. With the delayed data packet being
dropped rather than retransmitted with smaller packet header size and no handshake
mechanism, the UDP unicast transport option can reduce the overall communication
traffic and hence reduce the network latency and the potential of overloading the
network bandwidth capacity. Preliminary tests have shown that network latency may
be reduced by 30% with only 0.03% of data loss, when UDP is used instead of a TCP
connection (Yan 2007).
The benefits of using NTRIP are many. To the network operator, only one TCP port
has to be opened for an unlimited number of user requests for correction data streams.
Usually ports 80 and 8080 for HTTP access are not blocked by firewalls or proxy
servers. There is no direct connection between reference stations (NTRIP Server) and
21
customers (NTRIP Client), all streams are transmitted by NTRIP Caster to the public
safely. To the customers, on the other hand, there is no extra hardware needed for
receiving corrections; most of the latest GNSS hardware and software support NTRIP.
It is very easy to obtain the service by using a username and password (Waese
Christian 2006).
2.4 Network Communication
2.4.1 3rd Generation Mobile Telecommunication Standards
Current mobile communication systems have been upgraded to third generation
mobile telecommunications (3G) in many countries including Australia. 3G is
particularly designed for mobile internet data communication as well as the voice
services, which had been the major objective in designing the previous generations.
To fulfil the International Mobile Telecommunications-2000 (IMT-2000)
specifications by the International Telecommunication Union (ITU), 3G is required to
support a faster data rate than 200 kbit/s. The 3G network is a packet-switched
network: the data stream can be fragmented into IP packets, with the header in front
of the datagram to indicate its source and destination address and other parameters to
control the quality of service. Recently released 3G standards worldwide include
UMTS, HSPA+ and TD-SCDMA, which can support a much higher transmission
speed, up to 56Mbit/s in theory. Several field experiments have been conducted
previously to investigate the suitability of 2G networks for implementing the RTK
positioning technology. The rate of obtaining fixed RTK solutions varying between
50% and 90% were reported in the GSM and GPRS cellular networks.
2.4.2 IPv4 and IPv6 Headers
Current internetworking architecture still widely uses IPv4 as the internet layer
protocol. Ipv4 uses 32 bits binary to define the source and destination addresses in the
22
communication. There are also several elements (called ‘fields’) in front of the IP
addresses to introduce more characters for this IP package, including Type of Service
(TOS), datagram length for the whole package, Time To Live (TTL) and Header
checksum for package error detection. Some other options can be added after the
standard IPv4 header for various services, as shown in the left part of Figure 2.4.
However, IPv4 has some natural disadvantages which cannot fulfil the fast-growing
demand in internet services. Lack of enough IP addresses is the most serious issue, 32
bits space can provide only 4 billion (232) public addresses in theory, has and there
were already allocated at the beginning of 2011. Most mobile internet users have to be
assigned a dynamic private address due to the shortage. As mentioned above, if ITS
services need to involve all of the vehicles, hundreds of millions of IP addresses are
required.
IPv6 was designed to overcome this problem with a 128 bit address space. The
available source and destination addresses could be as many as 2128. By reducing the
redundant IPv4 segments as well as the Option field, the length of the IP header has
not increased much from IPv4 (see the right part of Figure 2.4). With its simple but
efficient header, IPv6 also offers other benefits, such as Auto-configuration and IPSec,
and also the enhancement to mobile IP applications. IPv6 can be expected to be
intelligent transmission framework for the future.
Figure 2.4: IPv4 and IPv6 header comparison 23
2.4.3 Mobile IPv6 in Vehicle Navigation
The TCP/IP reference model could be treated as a packet-switched technology, rather
than circuit-switched technologies like conventional telephone networks, because the
network infrastructure is only providing internetworking that delivers packets
between two end-points. The routers within the network make their decision packet
by packet (Ernst and Uehara 2002). The connection constructed is not permanent but
depends on the communication status.
To keep vehicles on roads connected with the internet in these mobile environments,
Five networking features have been proposed (Uehara 2002): a) In-vehicle
communication system, on-board computer systems controlling different parts that
need to interchange their various types of information; b) Permanent Internet access,
for steady Internet access for multimedia and critical applications; c) Wireless
Communication and fast handovers, to keep the seamless connection when vehicles
are moving rapidly; d) Vertical Handover, the necessary backup access to avoid single
system failure; e) Scalability and flexibility, as the growing number of automobiles
means sufficient space is required to accommodate and allocate to each one.
IPv6 as the next generation network protocol has overcome some shortages in IPv4,
especially in vehicular communication environment. Multi-hop ad hoc networks were
proposed following the concept of DSRC (dedicated short range communication), so
that communication between vehicles could be applied without other infrastructures.
To handle the mobility of vehicles, Marc and Lars designed a mobility management
protocol called MMIPv6 (Multi-hop Mobile IPv6). It uses an agent-based system with
a home agent (HA) to represent a vehicle in the home network, but also uses foreign
agents (FA), which is similar to mobile IPv4, to represent the vehicle located in the
VANET. The important feature of MMIPv6 is that it can rely on permanently
allocated and globally accessible IPv6 addresses to identify the vehicles. (Bechler and
24
Wolf 2005) It could also support research into vehicle collision avoidance systems
and precise vehicle positioning.
IPv6 provides a multicast mechanism which can replace broadcast in which had not
been part of IPv4. Some vehicular applications such as collision avoidance systems
and ad hoc networks need to connect with an appropriate range of addresses. The
multicast mechanism with IPv6 is considered to be a suitable solution. A study was
conducted to analyse the possibilities for applying the IPv6 multicast mechanism in
VANET and also for using GPS coordinates in IPv6 multicast addresses in order to
map multicast addresses to dedicated areas (Khaled, Ben Jemaa et al. 2009). In this
paper, researchers test IPv6 multicast using Geo-Broadcast by considering the GeoNet
project (GeoNet 2010), which designed an architecture to make the IPv6
communication multi-hop ad hoc domain available. Also, combining geographical
information with IP addresses could well define the multicast group based on the
geographical area.
2.4.4 TCP and UDP Protocols
Transmission Control Protocol (TCP) and User Data Protocol (UDP) are two
transmission protocols working on the IP layer. They both have pros and cons.
Transmission Control Protocol (TCP) is a reliable and connection-oriented network
protocol that is responsible for transporting data packets from source to destination in
an orderly, integral and reliable manner. Each of the TCP packets consists of a TCP
header of length 20 Bytes, as well as the TCP payload. The TCP header contains
information necessary to guarantee that the data packet can be transmitted to the
destination, while the TCP payload contains the actual information to be delivered.
Figure 2.5 shows the structure of the TCP header, which contains information that
allows it to perform actions such as three-way handshake, packet retransmission and
packet flow control. Besides the source and destination port specifying the IP of
25
sender and receiver, TCP also uses 32-bit accumulated sequence numbers to
determine every packet sent over the TCP connection. If the ACK flag is set, the
acknowledgement number will be the next sequence number that the receiver is
expecting. TCP uses data offset to specify the length of the header; the reserved bits
are for future use while the flags are to mark the special function of the packet. The
Window controls the number of data bytes the sender is willing to accept, the
checksum is for error detection, and at the end the urgent pointer can be used for
urgent data.
User Datagram Protocol (UDP) is a connection-less network protocol without
complicate transmission mechanisms that exist in TCP. As shown in Figure 2.5, the
UDP header does not have sequence numbers, acknowledgement numbers or flags, as
used in TCP. It uses the length just to indicate the size of the entire datagram and the
checksum to verify the header and data. As a result, a data packet may be lost during
transmission, or may arrive at the destination out of order. UDP packets have a
smaller header size (8 Bytes compared to 20 Bytes of TCP) and do not need an
acknowledgement packet from the destination. As a result, this usage will reduce the
traffic required, thus avoiding network overloading.
Figure 2.5: TCP and UDP header structures
The three-way handshake used by TCP establishes a reliable connection between the
sender and the receiver, as illustrated in Figure 2.6. It begins with the client
(131.181.26.206) sending a synchronization (SYN) packet to the server
(131.181.88.180) to request for synchronization. As the server receives the SYN
packet, it accepts the connection by replying with an Acknowledgement (ACK) and
26
SYN packet to the client. Finally, once the ACK and SYN packet reaches the client, a
reply ACK confirms the connection so that the data can be transmitted from the server.
In contrast, UDP sends the packets without any confirmation, as shown in Figure 2.7.
Figure 2.6: Example of TCP data transmission with three-way handshake
Figure 2.7: Example of UDP data transmission without three-way handshake
TCP is a connection-oriented protocol which requires reliable connection with the
opposite side before sending or receiving data. It can also use a data checksum to
guarantee accurate transmission. However, these characters may consume extra
network resources, so transmission latency will be longer. UDP on the other hand is a
connectionless protocol: the UDP packet header is much simpler than TCP. As in
radio broadcasting, UDP is responsible only for sending data packets, no matter
whether user can receive it or not. It is an unreliable protocol but its communication
efficiency is higher and its latency is lower than that of TCP. NTRIP can support both
TCP and UDP transmission.
2.4.5 Network Performance Measures
There are many ways to measure the performance of a wireless communication
network; some of the most commonly used parameters are listed as below. These will
be used in the result sections for communication network performance evaluation.
27
Pack transmission latency: the data transmission time from when the packet
enters the network to the time it reaches the destination. Low latency means
short delays, while high latency means long delays. (Lehpamer 2004)
Packet transmission loss: the failure of one or more packets failed to reach their
destination when they crossed over the communication network.
Packet retransmission: after the sender has transmitted the data packet, a timer
will start until an ACK packet returns from the receiver; if none comes, this data
packet will be transmitted again.
Packet out-of-order: if data packets arrive at the destination in an order
different from how they were sent, TCP uses sequence numbers to ensure the
right order delivery; in NTRIP version 2, RTP can also provide the sequence
numbering mechanism to cooperate with UDP transmission.
Transmission speed: the number of data that can be transmitted per unit of time.
28
Chapter 3 Experiment Designs and Configurations
3.1 Experiment Design
This research evaluates and analysis the effects on the high mobility environment of
applying these state-of-the-art precise positioning technologies highlighted in the
knowledge & literature reviewed in Chapter 2. Several experiments were designed to
address the three research objectives: 1) Experimentally study the performance of
precise positioning technologies in the high mobility environment, focusing on RTK
and PPP real-time capability; 2) Experimentally study a more efficient method of
delivering GNSS correction data for future mass implementation in ITS; and 3)
Simulate different correction service time intervals and examine their impact to the
quality of positioning solutions.
To meet the first objective, experiments were conducted in both static and kinematic
environments, where RTK and PPP solutions were obtained simultaneously using the
best available equipment, a professional grade dual-frequency GNSS receiver
(NovAtel DL-v3; more details in Section 3.4.1). The evaluation of static results will
offer an insight into the true potential of RTK and PPP performances within the
research platform, whereas the kinematic tests offer real-world performances in the
high mobility environment. Additionally, a low-cost single frequency GNSS precise
positioning solution (U-blox EVK6t; more detail in Section 3.4.2) were evaluated
against the professional grade (NovAtel DL-v3) to gain some insights into its
capability of satisfying the requirements of vehicle precise positioning applications.
In order to meet the second objective, two experiments were designed and conducted
to better understand the effects of data communication performances on positioning
results, as well as to develop a more efficient method of delivering GNSS correction
data in the future. First of all, studies were conducted on the use of different
29
correction data formats (namely, the different RTCM versions) on the data
communication network load. Secondly, the performances of TCP and UDP
connections for correction data transmission were analysed with respect to the five
network performance measures: packet transmission latency, packet transmission loss,
packet retransmission, packet out of order, and transmission speed. In addition to the
TCP connection, the UDP unicast was added as an alternative correction data delivery
option available since NTRIP version 2. As noted, UDP is a connectionless network
protocol that is much more efficient than the TCP connection; however, it has some
drawbacks, such as no packet sequence number or packet acknowledgement. Thus, it
is necessary to compare UDP with TCP to find out if the drawbacks might affect the
quality of positioning results.
To further reduce the network load, objective 3 considers using different correction
service time intervals and examining its impact to the quality of positioning solutions.
Currently, most of the reference stations transmit correction data in 1 Hz, which
places a heavy load on both the NTRIP server and the communication network if
there are thousands of users connected simultaneously. Different correction update
intervals were set to evaluate their effects on positioning solutions.
3.2 Field Campaigns
Field experiments were carried out in both static and kinematic environments. Figure
3.1 shows the static tests environment, located at a yard with clear sky approximately
10 km away from the chosen SunPOZ base station (LAND). The receiver was
connected to the laptop with data connection via a Telstra 3G/NextG USB modem.
30
Figure 3.1: Experimental equipments setup
Figure 3.2 shows the kinematic tests which were carried out along on the Brisbane
M3 highway between Beenleigh and CBD, a round trip distance of 35 km. The
vehicle was travelling at speeds between 80 and 110 km/h and there were several
overhead bridges along the route.
Figure 3.2: Kinematic test trajectory
Novatel DL‐v3
U‐blox
EVK LEA‐6T
Antennas
31
3.3 CORS and RTK Correction Services
3.3.1 SunPOZ CORS Network
The base station data used for RTK positioning were provided by the SunPOZ
network operated by the Queensland Department of Natural Resources and Water.
Figure 3.3 shows the location and distribution of the SunPOZ, network which
currently consists of 12 Continuous Operating Reference Stations (CORS). The
SunPOZ NTRIP Caster is able to stream authenticated users with both real-time
observations for any of their reference stations, as well as for the RTK correction
stream. For single-base RTK computation, the SunPOZ NTRIP Caster mount point
"LAND_RTCM31" located at Woolloongabba was used as our base station. As most
of the field tests were conducted on the Brisbane M3 highway, this station is the
closest SunPOZ station available for most of the time during the experiment. Base
station data arriving at the MCD were recorded and converted to RINEX format for
analysis and post processing.
Figure 3.3: The service coverage of Queensland SunPOZ CORS network
3.3.2 International GNSS Service (IGS)
IGS is a voluntary federation of more than 200 worldwide organizations that pool
their resources and permanent GPS & GLONASS station data to generate precise
32
products including real-time Satellite Orbit and Clock. Future IGS will incorporate
more GNSS to provide the highest quality service for earth science research,
surveying and navigation applications. (Kouba 2009)
In this research project, two IGS-IP NTRIP broadcasters were selected to acquire
reference station observations or satellite orbit and clock correctors. The NTRIP
caster www.igs-ip.net provides connection to about 140 reference stations around the
world to stream observations for RTK operations. Because almost all these stations
are more than 100 km away from the location of the rover receiver in this research
project, the baselines are too long to make the valid results, so the streams were
downloaded only to evaluate their transmission performance through the network.
Another NTRIP caster, products.igs-ip.net:2101, can provide precise satellite orbits and
clock corrections for PPP operation. Several mount points were selected from IGS
NTRIP casters. One IGS mount point, CLK00, will be accessed to acquire precise
satellite orbit and clock data for real-time PPP operation. CLK00 is an IGS Ultra
Rapid orbit product that can provide a real-time correction service. The RTCM3
messages 1059 and 1060 are used to disseminate GPS code and combined orbit and
clock corrections to GPS Broadcast Ephemeris.
3.4 Hardware
3.4.1 NovAtel DL‐v3
The professional grade GNSS receiver used during the experiments was NovAtel
DL-v3 (Figure 3.4). It is a 72-channel receiver capable of tracking signals from both
the GPS and GLONASS constellations. The rover was connection to an Ashtech dual
frequency antenna mounted on the roof of the vehicle. GNSS raw observation
measurements were output to the MCD via USB cables.
33
Figure 3.4: NovAtel DL-v3 GPS dual-frequency Receiver 3.4.2 U‐blox EVK LEA‐6T
The Evaluation Kit with Precision Timing output was developed by U-blox, a leading
semiconductor provider of embedded positioning and wireless communication
solutions for the consumer, industrial and automotive markets. EVK 6T (Figure 3.5)
is a consumer-grade GNSS receiver equipped with the U-blox next generation GPS
platform LEA-6T and a high performance active GPS antenna. It integrates a built-in
USB interface for both power supply and high-speed data transfer. As a typical
low-cost single frequency GNSS receiver, EVK 6T can receive GPS and GALILEO
satellite signals and can export raw data to PDA or PC.
Figure 3.5: U-blox EVK 6T
3.5 Software
3.5.1 RTKlib
RTKlib (see Figure 3.6 below) is open source software designed by Tomoji Takasu
from Tokyo University of Marine Science and Technology. It can provide precise
real-time positioning solutions such as RTK and PPP; the recorded data in real-time
tests can also be post proceeding by RTKlib. Many standard formats and protocols are
34
supported. It can utilize a serial port, NTRIP, or TCP/IP as the external
communication methods(Takasu 2011). In the RTK static test of this research
program, RTKlib was configured in ‘static’ mode, with the integer ambiguity
resolution set to Fix and hold, while in the RTK high mobility tests, RTKlib was
configured in ‘kinematic’ mode, the integer ambiguity resolution was set to
‘Continuous’. All other configurations were set as default.
Figure 3.6: RTKNAVI, main interface of RTKlib
3.5.2 GNSSsurfer
GNSSsurfer is a GNSS correction stream decoding and reprocessing software. It can
pass correction data from a desired input device into up to 7 different output devices,
such as the TCP port, the UDP port and the NTRIP server (Siebert 2011). In this
research project, GNSSsurfer was primarily used as a NTRIP server to re-disseminate
the RTCM correction stream acquired from the NTRIP caster to the on-board MCU.
The stream could be encapsulated by either UDP or TCP network protocols for
Internet transmission. Copies of GNSSsurfer were installed on the MCU to
decapsulate these packages as well.
3.5.3 Wireshark
To monitor the network performance, a copy of Wireshark software was installed on
both the PC laptop and the MCD. This well known packet analysis software can
35
monitor and record all the data packets passing through the network interface on both
the base and the rover sides. As mentioned above, network latency from the sender to
the receiver is determined by merge, comparing two Wireshark captured files from
each side. Additionally, the packet loss rate can also be detected during the
comparison.
By filtering the dialog with specified source and destination IP addresses, only the
relevant packets with correction data transmission can be displayed on the interface of
Wireshark, as shown in Figure 3.7.
Figure 3.7: Wireshark interface
3.5.4 TEQC
TEQC is a powerful lightweight toolkit for dealing with the many pre-processing
problems of the primary GNSS systems. The main functions of TEQC are (Estey and
Meertens 1999):
Reading and translation binary data formats
Editing RINEX and BINEX metadata, especially the header information
Quality checks of GPS and GLONASS data and generates the report.
36
In this research project, TEQC used to filter the observation data from the base station
using various time intervals. The purpose was to simulate the different transmission
frequencies to the rover and to study their impacts on the positioning results.
3.6 Age of Differential
An important parameter being investigated in this research program is the Age of
Differential (AoD). AoD indicates the time difference between the rover observation
data and the correction data from the reference station; this time frame that can partly
reflect the network transmission delay or blocking. To prevent unexpected network
congestion that may temporarily block the correction stream, the AoD correction was
set to maintain the RTK solutions for a limited amount of time (Lefebure 2011). The
RTK software will still use the old correction data received at the last second or last
several seconds. Take TCP and UDP for example: due to the network transmission
delay or retransmission in TCP, the correction data usually arrive at the rover 1 to 2
seconds later, as obtained in See Figure 3.8(a). Because UDP usually segments the
whole one-second correction data into several smaller packets to transmit, an
out-of-order data fragment or packet loss may result in invalid data realignment.
These packets will be dropped and the AoD will be higher, to reuse the past valid
correction data, as seen in Figure 3.8(b).
(a)
(b) Figure 3.8: Age of Differential
37
Chapter 4 Experiment Results and Evaluation
4.1 Experiment 1: RTK and PPP Precise Positioning
Technologies Performance Evaluation
4.1.1 Experiment Design
In this experiment, NovAtel DL-v3 was used as the rover receiver, connected to an
Ashtech antenna mounted on the roof of a vehicle. The raw measurements were
output to the Mobile Computing Device (MCD) via the USB cable. On the other side,
two data streams sent from the NTRIP caster were transmitted through the Telstra
Next G network. One stream is the carrier phase measurement correction data
acquired from SunPOZ CORS network for RTK operation; the other stream is the
precise orbit and clock correction data from IGS for PPP processing. The RTKlib
software was installed in the laptop; and then computed the rover and receiver data in
real-time and output position solutions. The solution quality, accuracy and continuity
were evaluated. Figure 4.1 shows the design of this experiment.
Figure 4.1: RTK and PPP processing flows
The positioning mode of RTKlib was configured in the kinematic form when using
RTK to test in the static and kinematic environments. The Integer Ambiguity
Resolution was set to continuous mode to estimate and resolve the integer ambiguity
38
continuously. Because PPP needs about 30 minutes to converge, the PPP kinematic
mode was used in the static test and then started the kinematic test without stop.
In the post processing, the solution type was set to the combined mode to smoothly
combine the forward and backward filter solutions; this means that the post
processing will process the solution twice, with forward and backward filters
respectively. The solution result calculated in the post processing was used as the
benchmark in the analysis process for comparison with the real-time result. The
difference obtained was considered as the error in the experiment.
The fore-mentioned experiment has been conducted several times during the research:
the data was collected from June to November 2011 is presented in the following
sections to illustrate the RTK and PPP performances of GNSS receivers in the static
and the high mobility environments. The duration of the static test was approximately
1 hour including the converging period, while the kinematic test was usually lasted
approximately 20 to 30 minutes. During the whole experiment period (static,
transition and kinematic tests), all the equipment was in the continuous operation
mode and all the raw measurements from the rover, the base station, and satellite and
orbit correction were recorded for the post processing. The real time positioning
results (RTK and PPP) were also logged.
4.1.2 Static Test Results
The statistics of the RTK and PPP positioning results for the static tests (considered as
the ideal environment) are shown in Table 4.1. Results are shown for all the tested
solutions (for RTK, that includes AR fixed and float solutions) for the East (denoted
as E), North (denoted as N) and Upward (denoted as U) directions. The results are
calculated using the real-time positioning results derived from RTKLIB v2.4.1
software and the reference coordinates are averaged from the fixed solutions.
39
DL-v3 RTK All solutions E (m)
N (m)
U (m)
Fixed solutions only E (m)
N (m)
U (m) Average(m) 0.0589 0.0043 0.0526 Average(m) 0.0024 0.0001 0.0031STD(m) 0.0804 0.0171 0.0424 STD(m) 0.0099 0.0055 0.0209RMS(m) 0.0804 0.0171 0.0424 RMS(m) 0.0535 0.0119 0.0239DL-v3 PPP All solutions E
(m)
N (m)
U (m)
Solution after converging E (m)
N (m)
U (m) Average(m) 0.4264 0.5311 1.1948 Average(m) 0.2619 0.7202 1.8621STD(m) 1.0498 0.2974 1.1794 STD(m) 0.0546 0.0728 0.2736RMS(m) 1.1330 0.6087 1.6788 RMS(m) 0.2675 0.7238 1.8821(a) DL-v3 RTK All solutions E N U Fixed solutions only E N U
Average(m) 0.0223 0.0059 0.0101 Average(m) 0.0031 0.0009 0.0054STD(m) 0.1153 0.0260 0.2465 STD(m) 0.0002 0.0005 0.0020RMS(m) 0.1174 0.0266 0.2466 RMS(m) 0.0031 0.0010 0.0058DL-v3 PPP All solutions E N U Solution after converging E N U Average(m) 0.9660 1.1595 1.0584 Average(m) 0.1778 1.2023 1.4481STD(m) 0.5157 0.3757 2.2889 STD(m) 0.0197 0.0097 0.0074RMS(m) 1.0950 1.2188 2.5211 RMS(m) 0.1789 1.2023 1.4482
(b)
40
All solutions E N U Fixed solutions only E N U DL-v3 RTK Average(m) 0.0326 0.0067 0.0322 Average(m) 0.0297 0.0330 0.0417STD(m) 0.0828 0.0950 0.1215 STD(m) 0.0031 0.0021 0.0059RMS(m) 0.0828 0.0950 0.1215 RMS(m) 0.0298 0.0331 0.0421DL-v3 PPP All solutions E N U Solution after converging E N U
Average(m) 0.0046 0.1212 1.1506 Average(m) 0.1403 0.0019 0.0322STD(m) 0.8336 0.2105 4.1631 STD(m) 0.1124 0.0142 0.0460RMS(m) 0.8334 0.2429 4.3183 RMS(m) 0.1797 0.0143 0.0561(c) Table 4.1: Accuracy of DL-v3 RTK and PPP real time results in static test
As can be seen from Table 4.1 (a), the real-time RTK position has average errors of
5.89 cm, 0.43 cm, and 5.26 cm from the reference solutions for the East, North and
Upward directions, respectively. Additionally, the standard deviations of positioning
errors are 8.04 cm, 1.71 cm, and 4.24 cm for the East, North and Upward, respectively.
The same Root-Mean-Square (RMS) results can be estimated by RTKlib. If only the
fixed solutions in this static test are considered, more accurate results could be
obtained for the centimeter level. On the other hand, the PPP positioning errors are
derived by subtracting the real-time PPP solution with the static point. In the case of
the PPP solution using the RTKLIB software package, if the PPP converging period is
considered, the average errors are in the order of 42.6 cm, 53.1 cm, and 119.4 cm for
the East, North and Upward directions, and the STD error are 105 cm, 29.7 cm and
118 cm for the East, North and Upward directions. The RMS errors are 113.3 cm,
60.87 cm, and 167.9 cm. If the estimation is only after the PPP solution converging
41
period, more accurate results could be achieved, which shows that PPP static
positioning accuracy could achieve the sub metre level in the E and N directions.
Similar results were listed in Test (2) and Test (3). Clarification should be made here
that as RTKlib is open source software, the PPP process sometimes did not perform
steadily and the converging effect was not obvious.
In test (a), the overall RTK solution accuracy is slightly degraded from the typical
RTK solution performance (few centimetre level of accuracy). This is believed to be
caused by the float solutions, which also indicate that the Ambiguity Resolution (AR)
process was not effective. For the solution results, 61.40% can be fixed while 38.60%
is floating. For the PPP real-time processing, the converging period usually takes 20
to 60 minutes, which can significantly affects the overall results. Also, the variation in
the number of satellites can cause position mutation.
(a) (b)
(c) (d)
42
(e) (f) Figure 4.2: RTK and PPP static positioning results –ground track
Figure 4.2 shows the RTK and PPP results in the ground-track plot and the North-East
plot give the number of available satellites for test case (c). Figure 4.2 (a) and (b) use
the 1-metre scale to plot the ground track for the RTK and PPP solutions. However, as
the static error for RTK is at centimetre level, errors are shown as one single point at
the origin (see Figure 4.2 (a)), whereas in Figure 4.2 (b), the PPP processing started
converging at metre-level error and kept steady at sub-metre level accuracy. Figure
4.2 (c) and (d) show the position variation in E (top) and N (bottom) direction for
RTK and PPP solutions, respectively. In Figure 4.2 (c), the solutions fluctuate within
the centimetre level and few float solutions appeared when the number of observable
satellites changed, compared with Figure 4.2 (e). In Figure 4.2 (d), PPP solutions
fluctuated within the sub-metre level, and the variation of observable satellites (see
Figure 4.2 (f)) could affect significant jitters in position due to PPP re-convergence.
The experiment results have shown that RTK positioning can satisfy the requirements
of the ITS application (0.5m ~ 1.0m); however, the PPP positioning is not capable of
fulfilling such requirements. It needs to be noted that both RTK and PPP positioning
performances are highly related to the capability of the software package, the AR
algorithms used (for RTK), the quality of measurements, the distance to the base
station (for RTK), atmospheric conditions etc. Thus, the results presented reflect only
the capability of our research platform, including hardware, software and
experimental configurations.
43
4.1.3 Kinematic Test Results
By post processing the real-time RTK observation data in RTKlib, more accurate
positioning solutions can be found and used as the benchmark to compare with both
RTK and PPP real-time solutions. The following tables show the coordinate
differences between the real-time positions and the post-processed positions in the
Navigation coordinates (ENU).
All solutions E N U Fixed solutions only E N U DL-v3 RTK Average(m) 0.0297 0.0158 0.0348 Average(m) 0.0062 0.0004 0.0035STD(m) 0.2446 0.3865 0.3340 STD(m) 0.0486 0.0799 0.1261RMS(m) 0.2462 0.3866 0.3357 RMS(m) 0.0490 0.0799 0.1261DL-v3 PPP Average(m) -1.4337 0.0751 -1.3093 Average(m) - - - STD(m) 0.4895 1.0164 1.2071 STD(m) - - - RMS(m) 1.5149 1.0188 1.7805 RMS(m) - - - (a) All solutions E N U Fixed solutions only E N U DL-v3 RTK Average(m) 0.0055 0.0031 0.0065 Average(m) 0.0020 0.0003 0.0089STD(m) 0.1718 0.0988 0.3437 STD(m) 0.0231 0.0436 0.2655RMS(m) 0.1718 0.0988 0.3436 RMS(m) 0.0232 0.0436 0.2656DL-v3 PPP Average(m) -0.6489 0.3245 1.8476 Average(m) - - - STD(m) 0.3935 0.6592 1.7673 STD(m) - - - RMS(m) 0.7588 0.7345 2.5563 RMS(m) - - -
(b)
44
All solutions E N U Fixed solutions only E N U DL-v3 RTK Average(m) 0.0237 0.0705 0.0143 Average(m) 0.0003 0.0054 0.0104STD(m) 0.1529 0.2400 0.4971 STD(m) 0.0372 0.0463 0.1154RMS(m) 0.1546 0.2501 0.4971 RMS(m) 0.0372 0.0466 0.1158DL-v3 PPP Average(m) 1.9274 -0.2263 0.0756 Average(m) - - - STD(m) 0.6395 0.6795 2.4381 STD(m) - - - RMS(m) 2.0306 0.7160 2.4386 RMS(m) - - - (c) Table 4.2: Accuracy of DL-v3 RTK and PPP real-time results in kinematic test
Table 4.2 compares DL-v3 in the RTK and PPP modes in three independent kinematic
tests. Table 4.2 (a) illustrates that in the RTK mode the difference in the standard
deviation between RTK real-time solutions and post-processing solutions is around
0.3 metre in the E and N directions. Estimating only fixed solutions caused further
reduced difference to centimetre level. Similar results are obtained from test (b) and
(c). Thus, it can be concluded that the positioning results processed in the RTK mode
by RTKlib is suitable for in-lane level accuracy applications; however, in the PPP
mode, the real-time results were more than 1 metre different from the RTK
post-processing solutions. The error generated in these experiments is too large to
satisfy the lane level vehicle positioning applications.
4.1.4 Research findings
In experimental scenario 1, 6 sets of field tests results have been demonstrated in
static and kinematic environments; both RTK and PPP modes have also been
evaluated. RTK solutions can achieve centimetre to sub-meter accuracy in these tests,
45
while PPP solutions achieved sub-meter level of accuracy (after 30-minute
converging period) in static tests and meter level of accuracy in kinematic tests. The
results indicated RTK solution is more suitable for the high mobility vehicle
applications. Thus, the following experiments will only be focus on RTK technology.
It is to be noted that previous study of real-time static PPP using RTKlib software and
NovAtel OEMV-3G (TAKASU 2010) has obtained accuracy results of RMS error
15.4cm EW; 8.9cm NS and 16.7cm UD (after 30 minutes converging). Our
experiment results (sub-meter level of accuracy for static environment) are slighted
degraded due to different testing environments which may have different multipath
level, overhead bridges, surrounding obstacles and atmospheric activities.
Additionally, our PPP experiments have set to use estimate STEC (iono. correction)
and estimate ZTE (tropo. Option) as suggested by the author of RTKlib. These setting
may be different from previous experiments and hence contribute to the differences in
the results.
4.2 Experiment 2: Single Frequency and Dual
Frequency Precise Positioning Platforms
Performance Evaluation
In this scenario, two GNSS receivers are involved as rovers: NovAtel DL-v3,
representing the professional grade dual frequency (L1/L2) receiver, the U-blox EVK
6T representing the mass-market grade single frequency (L1 only) receiver. Each
rover receiver was connected to an individual antenna and mounted on the roof of the
vehicle. Due to the poor PPP positioning performance achieved from our research
platform, this experiment evaluates only RTK positioning performance for the two
receivers. Two copies of RTKlib ran in parallel to process data and generate RTK
solutions for each receiver. The RTK correction stream and all other system
46
configurations are the same as in Experiment 1 (Figure4.1). Six static or kinematic
experiments will be introduced respectively in this section.
4.2.1 RTK Static Test
Figure 4.3 shows the quality of RTK solutions (using percentage of float (yellow) and
fixed (green)) for DL-v3 and EVK 6T in a static environment, in 3 tests conducted at
different dates. The real-time solutions of both receivers were as recorded during the
experiment. The results show that the mass-market grade EVK 6T performs in a
similar way to the professional grade NovAtel DL-v3 platform and that the
post-processing results are able to produce more fixed solutions than those in the real
time. In different tests, the percentages of fixed and float solutions are varied. These
results reflect the capabilities of the chosen research platform (hardware and software)
and the experiment configuration and atmospheric condition of the day.
(a)
(b)
41.10%
64.60%
58.90%
35.40%
0% 20% 40% 60% 80% 100%
EVK 6T Real time
DL‐v3 Real time
97.40%
83.60%
2.60%
16.40%
0% 20% 40% 60% 80% 100%
EVK 6T Real time
DL‐v3 Real time
47
(c) Figure 4.3: Solution quality of DL-v3 and EVK 6T in the static test
Table 4.3 shows the error in East, North and Upward directions for both the
professional grade and the mass-market grade receiver in these 3 static tests. The
errors are estimated by comparing their real-time positioning results with the
reference point (calculated as the average of fixed RTK solutions). Statistics (average,
RMS and STD) are given in two categories: all solutions combined and fixed solution
only.
All solutions E N U Fixed only solutions E N U DL-v3 Average(m) 0.0008 0.0001 -1.8939 Average(m) -0.0513 0.0106 -1.9052RMS(m) 0.0799 0.0171 1.8944 RMS(m) 0.0522 0.0120 1.9053STD(m) 0.0799 0.0171 0.0422 STD(m) 0.0092 0.0056 0.0206EVK 6T Average(m) -0.0001 -0.0004 -1.0981 Average(m) -0.2263 0.0223 -1.0449RMS(m) 0.2316 0.0325 1.1002 RMS(m) 0.2265 0.0234 1.0452STD(m) 0.2317 0.0325 0.0674 STD(m) 0.0112 0.0072 0.0215(a)
97.30%
91.80%
2.70%
8.20%
0% 20% 40% 60% 80% 100%
EVK 6T Real time
DL‐v3 Real time
48
All solutions E N U Fixed only solutions E N U DL-v3 Average(m) -0.0002 0.0003 -0.8729 Average(m) 0.0023 0.0048 -0.8720 RMS(m) 0.0032 0.0016 0.8729 RMS(m) 0.0034 0.0016 0.8720STD(m) 0.0032 0.0016 0.8729 STD(m) 0.0033 0.0016 0.0049EVK 6T Average(m) 0.0015 0.0052 -1.0124 Average(m) 0.0391 -0.0100 -0.9976RMS(m) 0.1514 0.0756 1.0134 RMS(m) 0.0392 0.0102 0.9976STD(m) 0.1514 0.0756 0.0455 STD(m) 0.0028 0.0016 0.0065
(b)
All solutions E N U Fixed only solutions E N U DL-v3 Average(m) -0.0003 -0.0004 -0.6547 Average(m) -0.0003 -0.0004 -0.6549RMS(m) 0.0011 0.0015 0.6547 RMS(m) 0.0011 0.0015 0.6549STD(m) 0.0010 0.0014 0.0060 STD(m) 0.0010 0.0015 0.0060EVK 6T Average(m) -0.0001 0.0004 -0.2855 Average(m) -0.0004 0.0004 -0.2850RMS(m) 0.0078 0.0017 0.2857 RMS(m) 0.0010 0.0016 0.2851STD(m) 0.0078 0.0017 0.0118 STD(m) 0.0009 0.0015 0.0064
(c)
Table 4.3: Accuracy of DL-v3 and EVK 6T (RTK all solutions and fixed only
solutions) in static test
In test (a), the overall positioning errors of NovAtel DL-v3 for East, North and
Upward directions are at centimetre level in average, RMS and STD results, the
49
overall positioning errors achieved by U-blox EVK 6T are between sub-meter and
centimetre level. One possible reason could be that the percentage of fixed solutions
of the U-blox EVK 6T is lower than that of NovAtel DL-v3 in this test. In test 2 and
test 3, the errors of both receivers are similar to or lower than the results of test (a).
Although the U-blox EVK 6T had a higher percentage of fixed solutions than
NovAtel DL-v3 in both test (b) and (c), the errors are still larger. Further study into
the hardware and software is required in the future to identify and address this
problem. Further examination of the performance from the fixed only solutions found
that the average and STD errors from both receivers significantly reduced to the
millimetre level of accuracy. Thus, these results further strengthen the importance of
the ability to gain a fixed solution.
Figure 4.4: variation of DL-v3 observable satellites in static test
Figure 4.5: variation of EVK 6T observable satellites in static test
Figure 4.4 and Figure 4.5 show the variation of satellites numbers (top diagram) in the
static test 1 for DL-v3 and EVK 6T, respectively. Green colour represents the fixed
solution and the yellow colour represents the float solution. In the static experiment,
the average number of satellites observed by DL-v3 for the RTK operation is 8.64.
Similarly, EVK 6T could observe an average of 8.63 of satellites during the same
period. Similar diagrams can be generated from test (b) and test (c).
50
Figure 4.6: DL-v3 RTK static positioning results
Figure 4.7: EVK 6T RTK static positioning results
Figure 4.6 and Figure 4.7 plot the RTK positioning results of the DL-v3 and the EVK
6T epoch from one of the above static field tests by epoch with 2 centimetres scale.
Both of their fixed solutions can distribute within a 6*6 centimetres area, but the float
solutions of EVK 6T jumped to further places than DL-v3, resulting in less accurate
results to all solutions, as provided earlier in Table 4.3.
4.2.2 RTK Kinematic test
In the kinematic test, the observation environment changed rapidly which immensely
affected the solution results. In some extremely bad conditions, the number of useful
satellites was too low to have RTK processed, and thus only a few single solutions
were generated. Generally, the DL-v3 receiver still achieved high quality, but EVK
6T showed much lower quality. Three field tests were conducted on the Brisbane M3
motorway. Take test (a) for example: 84.5% of solutions were fixed (green) and 15.4%
solutions (yellow) were float. EVK 6T receiver, however, obtained only 19% fixed
51
solutions, but it achieved more single solutions (red) more than DL-v3: the cheap
antenna equipped for the test may have caused the problem.
(a)
(b)
24.10%
91.40%
19.00%
84.50%
75.90%
8.50%
80.60%
15.40%
0.10%
0.10%
0.40%
0.10%
0.00% 20.00% 40.00% 60.00% 80.00% 100.00%
EVK 6T Post processing
DL‐v3 Post processing
EVK 6T Real time
DL‐v3 Real time
14.10%
60.30%
7.70%
49.70%
85.90%
39.70%
92.30%
50.30%
0.00% 20.00% 40.00% 60.00% 80.00% 100.00%
EVK 6T Post processing
DL‐v3 Post processing
EVK 6T Real time
DL‐v3 Real time
52
(c) Figure 4.8: Solution quality of DL-v3 and EVK 6T in kinematic test
In the kinematic tests, DL-v3 can still keep the sub-meter level accuracy for its
category all solutions, and centimetre accuracy for its fixed only solutions. However
with EVK 6T, the value of RMS and STD were in the meter-level, which cannot
satisfy the vehicle safety requirements.
(a)
14.60%
65.10%
13.80%
63.70%
84.90%
34.80%
85.70%
36.20%
0.50%
0.10%
0.50%
0.10%
0.00% 20.00% 40.00% 60.00% 80.00% 100.00%
EVK 6T Post processing
DL‐v3 Post processing
EVK 6T Real time
DL‐v3 Real time
All solutions E N U Fixed only E N U
DL-v3
Average(m) 0.0156 0.0116 -0.0014 Average(m) 0.0001 0.0001 0.0001
RMS(m) 0.2001 0.2796 0.2680 RMS(m) 0.0024 0.0031 0.0045
STD(m) 0.1996 0.2795 0.2681 STD(m) 0.0024 0.0031 0.0045
EVK 6T
Average(m) 0.0425 0.0049 0.1141 Average(m) 0.0132 0.0148 0.0361
RMS(m) 0.7120 1.9598 2.5498 RMS(m) 0.1349 0.2192 0.2745
STD(m) 0.7110 1.9605 2.5482 STD(m) 0.1346 0.2193 0.2761
53
(b)
(c) Table 4.4: Accuracy of DL-v3 and EVK 6T (RTK all solutions and fix only solutions) in kinematic test
Figure 4.9 and Figure 4.10 show the variation of satellite numbers and AoD from one
of the kinematic tests for DL-v3 and EVK 6T, respectively. Green colour represents
the fixed solution and the yellow colour represents the float solution. These figures
show that as the vehicle was moving on the highway in a fast speed, the observation
All solutions E N U Fixed only E N U
DL-v3
Average(m) 0.0114 0.0564 0.3075 Average(m) 0.0002 0.0019 0.0098
RMS(m) 0.1932 0.3526 1.0875 RMS(m) 0.0237 0.0284 0.2829
STD(m) 0.1929 0.3482 1.0436 STD(m) 0.0237 0.0284 0.2831
EVK 6T
Average(m) 0.1942 -0.1435 0.1268 Average(m) 0.0008 0.2013 0.3188
RMS(m) 0.7678 0.9517 2.4619 RMS(m) 0.9078 0.6729 1.2283
STD(m) 0.7430 0.9411 2.4592 STD(m) 0.9159 0.6478 1.1967
All solutions E N U Fixed only E N U
DL-v3
Average(m) 0.0081 0.1341 0.2199 Average(m) 0.0038 0.0036 0.0051
RMS(m) 0.2942 1.3857 2.5284 RMS(m) 0.0452 0.0475 0.1839
STD(m) 0.2942 1.3917 2.5370 STD(m) 0.0454 0.0476 0.1838
EVK 6T
Average(m) 0.2817 0.2008 0.1722 Average(m) 0.2348 0.2418 0.1332
RMS(m) 1.0196 1.8919 3.1817 RMS(m) 0.5667 0.9455 1.5715
STD(m) 1.0574 1.9018 3.1851 STD(m) 0.6111 0.9720 1.5704
54
situation can hardly become stable within a couple of minutes. The average number of
satellites DL-v3 can observe for the RTK operation is 7.27, while EVK 6T average is
7.59. A few network congestion incidents happened in the kinematic test, which
caused significant rising in the AoD. Thanks to its prediction within the congestion
period, many of the positioning results could also remain fixed. Figure 4.11 shows the
overall trajectories for both DL-v3 and EVK 6T in this kinematic experiment, with a
1-kilometre scale. The differences of positioning results between these two
equipments were at sub-meter level.
Figure 4.9: valid satellites and AoD of DL-v3 in kinematic test
Figure 4.10: valid satellites and AoD of EVK 6T in Kinematic test
55
(a) (b) Figure 4.11: the positioning results of DL-v3 and EVK 6T in kinematic mode
4.2.3 Solution continuity
In several instances during the kinematic experiments, obstacles such as overhead
bridges and sound proofing barrier have partly or fully blocked the sky view and
interrupted the GNSS observations. During these instances, no positioning solution
could be obtained without the raw measurements from the GNSS receiver. Table 4.5
highlights the performance of the two receivers under such circumstances by plotting
the vehicle trajectory (from positioning results in kinematic test (a)) to Google Earth.
In case 1 and 2, several seconds of positioning results were lost by DL-v3 (loss of raw
measurements) immediately after it passed viaducts at a steady speed. The receiver
needed a few second to reinitiate the observation and regain its position. Compared
with DL-v3, EVK 6T tends to lose less positioning solution (1 second at the most).
However, the positioning solutions under such conditions experience a much higher
error than the normal. This phenomenon is more obvious in case 3 when the vehicle
was exiting the highway and turning a corner with the highway directly above it.
Although the DL-v3 lost more positioning results than the EVK 6T, most of the
56
available positioning solution can be mapped to the right lane in which that vehicle
was travelling, while the results of EVK 6T provided a more continuous vehicle
trajectory which was less accurate. Or some of the EVK6T solutions jumped to
another lane or even off the road.
DL-v3 EVK 6T
Case 1
Case 2
Case 3
Table 4.5: Discontinuous solutions of DL-v3 and EVK 6T when passing under the bridges
57
Table 4.6 shows the total available positioning solution obtained from 2 field tests in
the static and kinematic environments. From the table, DL-v3 lost 2.8% of the
solutions in the kinematic test, while EVK 6T lost 1.5%. In comparison, the results
from the static test show that DL-v3 and EVK 6T did not lose any positioning
solution.
The number of epochs (test duration) DL-v3 EVK 6T
Static 3961seconds 3961(100%) 3961(100%)
Kinematic 1994seconds 1937(97.14%) 1964(98.50%) Table 4.6: solution continuity statistics for the kinematic test
4.2.4 Experiments findings
In this scenario, the professional and mass-market grade GNSS receivers in RTK
mode were tested under the static and the kinematic environments. By using the
correction data from NTRIP casters, both systems are capable of achieving higher
positioning accuracy than the current vehicle navigation equipment. However, the
quality and accuracy of the mass-market grade GNSS receiver (EVK 6T) are lower
than in DL-v3, especially in the high mobility environment. That may be due to the
GNSS receiver chip design and the low-quality antenna, which further reduced the
chance of obtaining correctly fixed integer ambiguity. However, the high sensitivity
GNSS receiver chip design has better tracking ability (hence the solution continuity)
than DL-v3 when working in the canopied areas. For vehicle navigation system
requirements, stability is also an important factor as well as accuracy.
From this experiment, some suggestions can be made for the future vehicle precise
positioning equipment design: firstly, use compact size and light weight to fit the
vehicle space; secondly, secondly, improve the features of hardware to suit the high
mobility environment; thirdly, decrease the cost of manufacture for massive
applications.
58
4.3 Experiment 3: RTCM Formats and Network Protocols
Evaluation
Experiment 3 evaluated the data communication performances and their impact on the
precise positioning solutions, as well as developing a more efficient method for
delivering GNSS correction data.
First, studies were conducted on the use of different correction data formats on the
data communication load. A 24-hour RTCM correction data transmission test was
performed to compare the network throughput between different RTCM protocol
versions.
Secondly, the two network transportation protocols, TCP and UDP, were evaluated
for five network performance measures: packet transmission latency, packet
transmission loss, packet retransmission, packet out of order, and transmission speed.
Additionally, evaluations were conducted to determine the effect, if any, on the
positioning results. As both TCP and UDP are supported by the latest NTRIP version
2, this experiment could help determining a better choice of communication protocol
for the future mass deployment ITS services.
4.3.1 RTCM2.x & RTCM3 transmission experiments
Although most of the GNSS reference stations in the world have upgraded their
decoder to RTCM version 3, a few stations continue to use RTCM version 2.x (x= 1,
2 or 3) to provide correction data service. To find out the network throughput of each
format, a 24-hour transmission experiment was conducted. Three mount points were
selected to acquire observations through the NTRIP broadcaster www.igs-ip.net:2101
operated by Federal Agency for Cartography and Geodesy of Germany (BKG) as a
gateway to access worldwide correction services from gathered resources. All these
59
reference stations can observe GPS and GLONASS satellites. The test results are
shown in Table 4.7.
Table 4.7: network throughput of three mount points with different RTCM versions
RTCM 3 is seen to be the most efficient correction data version out of these four
different versions. Even the number of satellites it observed was more than other
mount points: the throughput of mount point BNDY0 is just 40% of CAGZ0 and 33%
of GOPE0. That is because RTCM version 3 has reduced some redundant messages in
version 2.x, and uses compression to transmit message with a low bandwidth.
4.3.2 Evaluation of TCP and UDP in transmitting RTK
corrections
Figure 4.12 shows the overall system architecture design of the experiment. First of
all, a Mobile Computing Device (MCD) is used for three purposes: 1) to receive data
from the rover and the base station, 2) to perform RTK computation and; 3) to record
and measure the network performances. To compare the performance of the TCP and
UDP connections and their influences on the positioning results, two copies of RTK
software are required at the MCD to process the duplicated rover data set
simultaneously. However, the first RTK software requires obtaining the base-station
data through a TCP connection from an NTRIP Caster, while the second RTK
software obtains the same base-station data through a UDP connection from an
NTRIP Caster. Finally, MCD performs RTK computation to provide real-time precise
Mount point RTCM
version
Country Throughput in
24 hours MB
Multiple Average
satellites
BNDY0 3.0 Australia 24.277 1 10.64
CAGZ0 2.1 Italy 60.867 250% 8.58
GOPE0 2.3 Czech 73.354 302% 8.49
60
vehicle positions at 1 Hz update rate, as well as to record both the rover and the base
station data for post processing purposes.
In order to precisely measure the network latency from the NTRIP Caster to the MCD,
it is important to know the exact data packet transmitting time. However, as there is
no permission to install network monitor software at the NTRIP Caster, a fixed PC
laptop is required to be configured as the packet repeater to relay the base station data
stream from the NTRIP Caster to the MCD and to record the data packet transmission
time. By comparing the sending and receiving records of the base station data, latency
and other network performance parameters can be determined. It is important that the
computer clock drift phenomenon must be considered, as it may cause the
incorrect/imprecise calculation in data transmission latency (Mills 1992).
GNSSsurfer software was used to allow experiments to be conducted over TCP and
UDP simultaneously. A copy of the software is installed at the PC laptop (data packet
repeater) and configured to have the input stream as the base station data from
SunPOZ NTRIP Caster and the output, with duplicated base station data streams
transmitted simultaneously to the MCD, one stream using the TCP connection and the
other using the UDP connection. On the MCD, two copies of GNSSsurfer were
installed to listen for the base-station data stream in the TCP and UDP connections
respectively. Each base-station stream is transferred to the individually assigned RTK
computation software.
Figure 4.12: Overall experiment architecture (MCD) 61
The Wireshark recorded the whole progress by capturing all packets that passed the
network interface on the computer. Table 4.8 summarizes the performance of the TCP
and UDP packets in each test, including the experiment duration, throughput,
transmission latency, amount of packets, average packet length, packet lost,
retransmission packets and the speed. This analysis found that the latency of the UDP
packets is less than that of the TCP packets in the static and kinematic tests. As the
UDP header and the average data length are all shorter, UDP packets can be quickly
processed by routers; the latency of UDP was 75% to 80% of TCP. Because UDP
does not have the packet acknowledgement or retransmission mechanisms, the
throughput of the UDP transmission was 70% to 75% of TCP.
Table 4.8: Network transmission results in static test
Some data gaps and jitters can be found by investigating the network throughput
graphic from the Wireshark files,. Figure 4.13 shows a significant gap from the times
22:59:40 to 22:59:50 in both the TCP and UDP transmissions when implementing the
static test. Figure 4.14 and Figure 4.15 explain this progress by listing the packet
details. When the TCP server could not detect the acknowledgement message from
the client, it stopped the connection and initialised a new connection request to the
client by a three-way handshake. After reconnection was established, all congested
correction data in that period were resent to the client. The first 2 packets were 5 to 6
times larger than other regular packets. Figure 4.14 highlights this information. As
there is no congestion control mechanism in UDP, all blocked packets sent by the
server were dropped and would not be retransmitted. The UDP client needed to wait
62
until the connection was rebuilt after about 6 seconds, As shown in the highlighted
packets information in Figure 4.15.
Figure 4.13: Packets transmission graphic of TCP (left) and UDP (right)
Figure 4.14: TCP packets capture list
Figure 4.15: UDP packets capture list
Figure 4.16 demonstrates the AoD for TCP and UDP solutions in the static test. Due
to the network transmission latency, the correction data usually arrive at the rover 1
second later or even more. Because TCP is a reliable and ordered protocol, each
packet can reach the destination in its correct sequence; Figure 4.16(a) shows a few
63
values older than 2 seconds. In contrast, UDP is unreliable and unordered, some
correction packets may be delayed or out of order in transmission, and a higher
interval can be found in Figure 4.16(b). A long AoD showed on both figures, which
indicates that the network congestion accident happened at the same time as
Wireshark recorded it (as noted previously). However, as the RTK software can still
utilise the previous correction data within the range of AoD, the RTK solution kept
fixed in both TCP and UDP.
(a)
(b) Figure 4.16: AoD for static TCP (top diagram) and UDP (bottom diagram) solutions
Figure 4.17 shows the trajectories of static and kinematic tests for both TCP and UDP.
(Scale: left, 1 cm; right, 1 km).
64
Figure 4.17: static (left) and kinematic (right) trajectories for TCP/UDP transmission
Figure 4.18 compares the quality of positioning solutions for TCP and UDP in static
and kinematic environments. It noted that the percentage of fixed solutions that the
correction data transmitted via UDP is similar to that of TCP. By comparing the
coordinates of the reference point, the overall static solutions estimated for TCP and
UDP can all achieve sub-meter differences in E and N directions; millimetre level
difference could be achieved if only the fixed solutions are considered. Figure 4.19
shows clearer plots of position variation for TCP static solutions in E and N
directions.
Figure 4.18: Quality of positioning solutions for TCP/UDP in the static and kinematic modes
76.10% 76.60% 81% 80.70%
23.90% 23.40% 19% 19.30%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
TCP static UDP static TCP kinematic
UDP kinematic
Float solution
Fix solution
65
Static RTK Solution - Overall
Real-time RTK (TCP) Real-time RTK (UDP)
All solutions E (m) N (m) E (m) N (m)
Average(m) 0.0086 0.0098 0.0085 0.0097
RMS(m) 0.1096 0.1154 0.1056 0.1223
STD(m) 0.1095 0.1153 0.1056 0.1224
Static RTK Solution – Fixed only
Real-time RTK (TCP) Real-time RTK (UDP)
All solutions E (m) N (m) E (m) N (m)
Average(m) 0.0087 0.0098 0.0082 0.0097
RMS(m) 0.0092 0.0099 0.0088 0.0098
STD(m) 0.0030 0.0015 0.0032 0.0015 Table 4.9: Position difference between TCP/UDP real-time static RTK solutions and the reference point in E and N directions
E-W direction
N-S direction Figure 4.19: position variations of TCP static solutions in E (up) and N (bottom) directions 66
Table 4.10 compares the difference between TCP/UDP real-time kinematic solutions
and the TCP post-processing solutions. Both of these can achieve centimetre accuracy
if only the fixed solutions are estimated. In the overall solutions, UDP which is at
centimetre level can get even more accurate results than TCP,.
Kinematic RTK Solution - Overall
Real-time RTK (TCP) Real-time RTK (UDP)
All solutions E (m) N (m) E (m) N (m)
Average(m) 0.0062 0.0023 0.0031 0.0002
RMS(m) 0.1757 0.0956 0.0825 0.0694
STD(m) 0.1757 0.0956 0.0824 0.0694
Kinematic RTK Solution – Fixed only
Real-time RTK (TCP) Real-time RTK (UDP)
All solutions E (m) N (m) E (m) N (m)
Average(m) 0.0020 0.0004 0.0030 0.0013
RMS(m) 0.0240 0.0450 0.0233 0.0199
STD(m) 0.0239 0.0450 0.0231 0.0199 Table 4.10: Position difference between TCP/UDP real-time kinematic RTK solutions and the reference point in E and N directions 4.3.3 Summary of Experiment 3
From the statistics collected in the tests, UDP had lower latency and transmission
speed than TCP when transmitting the correction data in the static and high mobility
environments. Also when the vehicle is moving at a high speed, not only the precision
of the position but also the wireless network performance may be down. By receiving
the correction data transmitted via UDP, the same level of precision can be achieved
as for TCP, and the packet loss rate is also acceptable. Comparing the throughput,
67
UDP could save 20% to 30% more than TCP: about 3 Mb data could be saved per
hour. Assuming there will be 10,000 vehicles in Brisbane using precise navigation
services for safety applications, 29.30 Gb of network throughput would be saved in
one hour. UDP transmission can be considered in ITS when a massive of connections
requests the correction data service.
4.4 Experiment 4: Different Correction Service Time
Interval Assessment
Reducing the data transmission frequency could be a simple way to save network
throughput; meanwhile, the low frequency data may cause more errors and inaccuracy
in operation. To study how this can affect the positioning results, and also to find the
most suitable interval for continuous vehicle precise positioning services, a simulation
experiment was done in this research. TEQC in the command line was used to
reprocess the recorded observation file from the reference station with update
intervals of 1-5 seconds, 10 seconds, 15 seconds, 20 seconds, 30 seconds or even 1
minute. The RTK post-processing program in RTKlib then processed these files with
the original rover observation file to generate new solution results. The AoD was set
to 70, so that the received correction data, with a maximum latency of 70 seconds can
be treated as a valid value for RTK operation.
As the time interval increased, the integer ambiguity resolution was hard to keep fix.
The quality of positioning solutions was degrading, as seen in Figure 4.20. Within the
time interval of up to 20 seconds, more than 85% solutions were fixed, while the float
solutions were less than 15%. But when the time interval was extended to 30 seconds,
the fixed solution was down to 76.2%. Only 52.5% of solutions can still keep fixed
when we set the interval to 60 seconds.
68
Figure 4.20: Solution qualities in different correction data intervals
Because of the lack of real-time observation from the reference station, the rover had
to predict this from the previous received data. This extended the error of positioning
result from 0.1 to 0.4 metre in the ENU coordinates system (see Figure 4.21). To
satisfy the in-lane-level accuracy requirement, up to 0.3 metre position errors can be
accepted. From the results in this experiment, a 20-second time interval could be
suitable to operate. On the other hand, the errors for fixed only solutions kept steady
between 0.05 and 0.2 metre when the time interval increased. Figure 4.22 shows the
variation.
93.90%
89.70%
90.20%
90.10%
91.40%
90.20%
88.00%
87.70%
76.20%
52.50%
6.10%
10.20%
9.70%
9.90%
8.60%
9.80%
12.00%
12.30%
23.70%
47.50%
0.00% 20.00% 40.00% 60.00% 80.00% 100.00%
1 second
2 seconds
3 seconds
4 seconds
5 seconds
10 seconds
15 seconds
20 seconds
30 seconds
60 seconds
Float solutions
Fix solutions
69
Figure 4.21: Accuracy of all solutions under different time intervals of correction data service
Figure 4.22: Accuracy of fixed only solutions under different time intervals of correction data service
‐0.2
‐0.1
0
0.1
0.2
0.3
0.4
0.5
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
1 S 2 S 3 S 4 S 5 S 10 S 15 S 20 S 30 S 60 S
E
N
U
‐0.15
‐0.1
‐0.05
0
0.05
0.1
0.15
0.2
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
AVE
STD
RMS
1 S 2 S 3 S 4 S 5 S 10 S 15 S 20 S 30 S 60 S
E
N
U
70
Chapter 5 Conclusion and future research
5.1 Thesis Conclusions
A current vehicle navigation system equipped with a single frequency or low-cost
GPS receiver can provide road-level accuracy only at 5 to 10 metres and cannot fulfil
the requirements for ITS safety applications. For road safety applications, such as
collision avoidance, lane departure warnings or lane keeping, A Global Navigation
Satellite System (GNSS) based vehicle positioning system has to provide lane-level
(0.5-1m) or even in-lane-level (0.1-0.3m) accuracy and reliable positioning
information to vehicle users. The current precise positioning technologies, such as
real-time kinematic (RTK) and Precise Point Positioning (PPP), can achieve
positioning accuracy of as high as a few centimetres in real time which will
theoretically be sufficient to meet the requirements of vehicle positioning systems at
lane level. However, so far most RTK and PPP applications are found in static and
low mobility environments. This research has experimentally studied the performance
of RTK and PPP techniques when they work in a high mobility environment,
considering the factors of communication data links and IP transmission protocols.
Experiments were performed with NovAtel DL-V3 and U-blox EVK 6T receivers.
NovAtel DL-v3 is a professional dual-frequency receiver while U-blox EVK 6T
represents a mass-market single-frequency GNSS receiver. The results have shown
that EVK 6T cannot satisfy lane level accuracy requirements, but that its solution
continuity was better than that of DL-v3 when the signal obstacles are severed around
the GNSS antenna. RTK solutions have achieved the RMS precision of 0.09 to 0.2
meter in the static test and 0.2 to 0.3 meter in the kinematic test, while PPP reported
from 0.5 to 1.5 meters in static and 1 to 1.8 meter in kinematic tests by using the
RTKlib software. These RMS precision values could be further improved if better
71
RTK and PPP algorithms are adopted. The tests results also showed that RTK may be
more suitable for lane-level accuracy vehicle positioning.
Meanwhile, the internet connection was identified as another key factor for these
positioning technologies; this depends on low latency and high reliability
communication links. The thesis also analysed network performance in transmitting
correction data packages. The RTCM version 3 correction data consumes the least
network usage than other RTCM version 2.x data in a 24-hour continuous test. These
data can be encapsulated in TCP or UDP format packages. Another test has examined
the difference between TCP and UDP transmission in latency, throughput and other
network parameters: UDP was shown to achieve the same accuracy in positioning
results as TCP, but to consume less network resources. As NTRIP version 2 can
support UDP in the transport layer, UDP could be a better choice for massive
applications.
Effects of different time intervals on the real-time positioning results also have been
experimentally studied to further investigate a more economic way in transmitting
correction data. Results have shown that the RTK solutions from the DL-v3 receiver
can keep the in-lane-level accuracy with the update rate of correction data up to 20
seconds. This result indicates the potential to reduce the data transmission rates from
the infrastructure to vehicle users. This conclusion is certainly not applicable to
vehicle-to-vehicle relative positioning where the reference vehicles are moving.
5.2 Future works
As RTKlib is open source software for free use, there is a room to improve the
algorithm robustness to obtain better positioning results with the same data and
experiments. This master project is considered as the initial attempt. More
experiments with the research and commercial software packages have been in the lab
72
research agenda to verify the usefulness and problems of RTK and PPP techniques in
the high-mobility vehicle environment.
As NTRIP is being used by more and more users, it is necessary to study this protocol
in detail, especially as NTRIP version 2 has implemented a Real-Time Streaming
Protocol (RTSP) to overcome the drawbacks in the UDP transmission.
The shortage of IP addresses is another important problem for ITS applications. To
involve all vehicles into ITS, tens of millions of IP addresses will be required to
access the internet services. However, current IPv4 addresses are all used up as of the
beginning of 2011 due to the ever-increasing market demand for internet-based
services. IPv6 was designed to solve this issue and to provide more convenient and
secure services to users, particularly through its enhanced functions in high mobility
environments. How to adapt these in vehicle positioning systems is an interesting
question for future study.
73
Reference
Bechler, M. and L. Wolf (2005). Mobility management for vehicular ad hoc networks. Vehicular
Technology Conference, 2005. VTC 2005‐Spring. 2005 IEEE 61st.
Chen, K. and Y. Gao (2005). Real‐Time Precise Point Positioning Using Single Frequency Data.
Proceedings of ION GNSS 2005, Long Beach, California.
Dammalage, T. L., P. Srinuandee, et al. (2006). "Potential Accuracy and Practical Benefits of NTRIP
Protocol Over Conventional RTK and DGPS Observation Methods." Proceeding Map Asia.
Department of Infrastructure and Transport, A. G. (2009). Road Deaths Australia, 2008 Statistical
Summary.
Dixon, K. (2006). StarFire: A global SBAS for sub‐decimeter precise point positioning. Proceedings of
the 19th International Technical Meeting of the Satellite Division of The Institute of Navigation, Fort
Worth, TX. .
Du, J. and M. J. Barth (2008). "Next‐Generation Automated Vehicle Location Systems: Positioning at
the Lane Level." IEEE Transactions on Intelligent Transportation Systems 9(1): 48‐57.
El‐Mowafy, A. and M. Al‐Musawa (2009). Machine automation using RTK GPS positioning. ISMA '09.
6th International Symposium on Mechatronics and its Applications.
Ernst, T. and K. Uehara (2002). Connecting automobiles to the internet. 3rd International Workshop on
ITS Telecommunications, Seoul, South Korea Citeseer.
Estey, L. H. and C. M. Meertens (1999). "TEQC: The Multi‐Purpose Toolkit for GPS/GLONASS Data." GPS
solutions 3(1): 42‐49.
GeoNet (2010). "Geonet project." from http://www.geonet‐project.eu.
Honda, M., M. Murata, et al. (2006). GPS Precise Point Positioning Methods Using IGS Products for
Vehicular Navigation Application. SICE‐ICASE, 2006. International Joint Conference.
IVI Light Vehicle Enabling Research Program (2004). Enhanced Digital mapping project final report.
Washington, DC.
Khaled, Y., I. Ben Jemaa, et al. (2009). Application of IPv6 multicast to VANET. Intelligent Transport
Systems Telecommunications, (ITST) ,2009 9th International Conference
Kim, D. and R. B. Langley (2003). A Dual‐Mode GPS Real‐Time Kinematic System for Seamless
Ultrahigh‐Precision Positioning and Navigation. ION GPS/GNSS 2003, 16th International Technical
74
Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon.
Kouba, J. (2003). "A guide to using International GPS Service (IGS) products." Publication of the IGS
Central Bureau.
Kouba, J. (2009). "A guide to using International GNSS Service (IGS) products." from http://igscb. jpl.
nasa. gov/components/usage. html .
.
Kouba, J. and P. Heroux (2001). "GPS Precise Point Positioning using IGS orbit products." GPS solutions
5(2): 12‐28.
Lefebure, L. (2011). "Effects of RTK correction data age on accuracy ". from
http://lefebure.com/articles/rtk‐correction‐data‐age‐accuracy/.
Lehpamer, H. (2004). Microwave transmission networks: planning, design, and deployment,
McGraw‐Hill Professional.
Lenz, E. (2004). Networked transport of RTCM via internet protocol (NTRIP) Capplication and benefit in
modern surveying systems. Pres. FIG Working Week 2004, Athens, Greece.
Liu, G. C. (2004). "GPS RTK positioning via Internet‐based 3G CDMA2000/1X wireless technology." GPS
solutions 7(4): 222‐229.
Liu, Z. and Y. Gao (2001). Research toward wireless Internet‐based DGPS. Proceedings of KIS 2001,
Banff, Canada.
Mills, D. (1992). Network Time Protocol (Version 3) specification, implementation and analysis. Univ.
Delaware.
NAVCOM (2011). "The Starfire network." from http://www.navcomtech.com/StarFire/.
OICA (2010). OICA (Organisation Internationale des Constructeurs d'Automobiles).
Queensland Department of Environment and Resource Management (2010, 25 November).
"Surveying information,." from http://www.derm.qld.gov.au/gnss/systems.html.
Retscher, G. (2002). "Accuracy performance of virtual reference station (VRS) networks." Journal of
Global Positioning Systems 1(1): 40‐47.
Rohm, W. (2011). DGPS in mobile phones‐ perspectives, technology, limitations. JUNIORSTAV 2011.
RTCM SC‐104 (2001). RTCM Recommended Standards for Differential GNSS Service Version 2.3., .
Arlington, VA, USA, Radio Technical Commission for Maritime Services.
75
RTCM SC‐104 (2004). RTCM Recommended Standards for Differential GNSS Service Version 3.0.
Arlingto, VA, USA, Radio Technical Commission for Maritime Services
Siebert, J. (2011). Manual for GnssSurfer Version 1.08b Berlin, SAPOS Germany.
Soares, M. G., B. Malheiro, et al. (2004). "Evaluation of a real time DGPS data server." Components
(January): 1‐8.
TAKASU, T. (2010). real‐time PPP with RTKLIB and IGS real‐time satellite orbit and clock. IGSWorkshop
2010.
Takasu, T. (2011). "RTKLIB ver 2.4.1 Manual." from http://www.rtklib.com/prog/manual_2.4.1.pdf.
Talbot, N. (1996). Compact data transmission standard for high‐precision GPS. 9th Int. Tech. Meeting
of the Sat. Div. of the U.S. Inst. of Navigation. Kansas City, Missouri, Institute of navigation. 9: 861‐871.
Talbot, N. (1997). Improvements in the Compact Measurement Record Format. Trimble User
Conference San Jose, Califonia USA.
Telstra (2011). "Telstra Mobile Broadband Coverage." from
http://telstra.com.au/mobile/networks/coverage/broadband.html.
Telstra (2011). "Telstra profile." from
http://www.telstra.com.au/abouttelstra/company‐overview/telstra‐profile/index.htm.
Trimble Navigation (2011). "Company Introduction." from
http://www.trimble.com/abouttrimble.shtml.
Uehara, K. (2002). "Overview of the Internet Connected Automobiles." IPSJ Magazine (in Japanese)
43(4): 350‐356.
Uradzinski, M., L. Jingnan, et al. (2010). Towards precise car navigation: Detection of relative vehicle
position on highway for collision avoidance. Ubiquitous Positioning Indoor Navigation and Location
Based Service (UPINLBS), 2010.
Vollath, U., H. Landau, et al. (2002). Network RTK‐‐‐‐Concept and performance. Proceedings of the
GNSS Symposium, WuHan, China.
Waese Christian (2006). NTRIP ‐ Purpose and Perspectives. 2nd Trimble GPSNet Users Seminar.
Munich, Germany.
Weber, G., D. Dettmering, et al. (2005). Networked Transport of RTCM via Internet Protocol (Ntrip)
IP‐streaming for real‐time GNSS applications. ION GNSS 18th International Technical Meeting of the
76
Satellite Division, Long Beach, CA.
Wegener, V. and L. Wanninger (2005). Communication options for Network RTK/SAPOS(R) realization.
Proceedings of the 2nd Workshop on Positioning, Navigation and Communication (WPNC 05),
Hannover, Germany.
Yan, T. S. (2007). Test results from the next generation of NTRIP. International Global Navigation
Satellite Systems Society. The University of New South Wales, Sydney, Australia.
Yan, T. S. (2008). Analysis on distribution of real‐time GNSS data using IP. School of Surveying and
Spatial Information Systems. Sydney, The University of New South Wales. Master of Engineering 100.
77
APPENDIX 1
Appendix Configuration for RTK and PPP kinematic, static and
post processing in RTKlib
RTK PPP
Static Kinematic Post
processing Static Kinematic
Post
processing
Solution Forward Forward Combined Forward Forward Combined
Elev mask 10 deg 10 deg 10 deg 10 deg 10 deg 10 deg
Snr mask 0.0dBHz 0.0dBHz 0.0dBHz 0.0dBHz 0.0dBHz 0.0dBHz
dynamics Off Off Off Off Off Off
tidecorr Off Off Off Off Off Off
Ionos opt broadcast broadcast broadcast Estimate
STEC
Estimate
STEC
Estimate
STEC
Tropo opt saastamoinen saastamoinen saastamoinenEstimate
ZTE
Estimate
ZTE
Estimate
ZTE
Ephemeris precise precise precise SSR CoM SSR CoM SSR CoM
Navi sys gpsglonass gpsglonass gpsglonass gpsglonass gpsglonass gpsglonass
Ambiguty
resolution fix and hold continuous fix and hold N/A N/A N/A
Ambglos auto calib auto calib auto calib auto calib auto calib auto calib
Val thres 3.0 3.0 3.0 3.0 3.0 3.0
78
