Validation and Assessment of Multi-GNSS Real-Time Precise Point Positioning in Simulated Kinematic Mode Using IGS Real-Time Service

Abstract

Precise Point Positioning (PPP) is a popular technology for precise applications based on the Global Navigation Satellite System (GNSS). Multi-GNSS combined PPP has become a hot topic in recent years with the development of multiple GNSSs. Meanwhile, with the operation of the real-time service (RTS) of the International GNSS Service (IGS) agency that provides satellite orbit and clock corrections to broadcast ephemeris, it is possible to obtain the real-time precise products of satellite orbits and clocks and to conduct real-time PPP. In this contribution, the real-time multi-GNSS orbit and clock corrections of the CLK93 product are applied for real-time multi-GNSS PPP processing, and its orbit and clock qualities are investigated, first with a seven-day experiment by comparing them with the final multi-GNSS precise product ‘GBM’ from GFZ. Then, an experiment involving real-time PPP processing for three stations in the Multi-GNSS Experiment (MGEX) network with a testing period of two weeks is conducted in order to evaluate the convergence performance of real-time PPP in a simulated kinematic mode. The experimental result shows that real-time PPP can achieve a convergence performance of less than 15 min for an accuracy level of 20 cm. Finally, the real-time data streams from 12 globally distributed IGS/MGEX stations for one month are used to assess and validate the positioning accuracy of real-time multi-GNSS PPP. The results show that the simulated kinematic positioning accuracy achieved by real-time PPP on different stations is about 3.0 to 4.0 cm for the horizontal direction and 5.0 to 7.0 cm for the three-dimensional (3D) direction.

1. Introduction

Precise Point Positioning (PPP) [1,2] is a popular and widely-used technique in high-precision positioning applications of the Global Navigation Satellite System (GNSS); it can provide users centimeter-level to millimeter-level positioning results on a global scale with a single receiver and the undifferenced observations by applying the precise satellite orbit and clock products from the International GNSS Services (IGS) agency or from several Analysis Centers (ACs) [3]. In the early years, PPP was mainly performed for the Global Positioning System (GPS) only. With the development of other GNSSs such as Russia’s GLObal Navigation Satellite System (GLONASS), China’s BeiDou Navigation Satellite System (BDS), and Europe’s GALILEO system, multi-GNSS combined positioning, which can significantly improve the positioning availability, continuity, and accuracy when compared to the single-system case, has become an inevitable trend for future GNSS-based applications [4,5]. In particular, under the support of IGS’s Multi-GNSS Experiment (MGEX) project [6,7,8], various analysis centers and agencies are now providing multi-GNSS precise products for research and application [9,10,11], and thus multi-GNSS combined PPP has become possible and a hot topic for GNSS research [12,13,14].

Due to the latencies (about two weeks for the final products and one day for the rapid products) of precise satellite orbit and clock products released by IGS/ACs, PPP is mainly carried out in post-mission positioning and data processing. Though real-time PPP can be achieved by applying the predicted part of ultra-rapid products, its positioning performance is poor due to the low accuracy of the predicted satellite clock product, which is about 3 ns (~0.9 m) [15]. In order to meet the demands of real-time precise applications, the IGS Real-time Pilot Project was launched in 2007 and officially operated from April 2013, aiming to provide access to precise satellite orbit and clock correction products via NTRIP (Networked Transport of RTCM via Internet Protocol) for real-time service (RTS) [16,17]. RTS products contain the satellite orbit and clock corrections to the broadcast ephemeris, and they are expressed within the International Terrestrial Reference Frame 2008 (ITRF08) and formatted for state space representation (SSR) according to the SSR standard of RTCM (Radio Technical Commission for Maritime Services). The orbit corrections are provided as radial, along-track, and cross-track offsets to the broadcast satellite positions in the Earth-Centered Earth-Fixed (ECEF) reference frame, and the clock corrections are given as offsets to the broadcast satellite clocks. After applying those orbit and clock corrections to the broadcast satellite orbits and clocks derived from the broadcast ephemeris, the precise satellite orbits and clocks for PPP processing can be calculated and are referred to the ‘Ionospheric-Free’ phase center of the satellite antenna (for APC streams) or to the satellite Center of Mass (for CoM streams). Additionally, the information of the ionosphere Vertical Total Electron Content (VTEC), code and phase biases for selected systems and signals are also included in RTS products. RTS products can be accessed through the internet without needing any special licensing, as the only requirement is a user registration. More detailed information about RTS can be found on the IGS website (http://igs.org/rts).

The ‘State Space Representation (SSR)’ Working Group of RTCM has developed appropriate v3.x messages [18], such as the combined orbit and clock corrections messages of 1060 for GPS and 1066 for GLONASS, etc., to disseminate such RTS corrections in real-time streams. Currently, several real-time product streams are provided by different agencies, such as BKG (Bundesamt für Kartographie und Geodäsie), CNES (Centre National d’Etudes Spatiales), DLR (Deutsches Zentrum für Luft- und Raumfahrt), ESA/ESOC (European Space Agency/European Space Operations Centre), GFZ (Deutsches GeoForschungsZentrum), GMV (GMV Aerospace and Defense), NRCan (Natural Resources Canada), and WHU (Wuhan University) [19]. The detailed information of these real-time product streams can be found on the BKG website (https://igs.bkg.bund.de/ntrip/orbits).

Table 1. Some APC (antenna phase center) streams of real-time SSR (state space representation) products.

Products/Streams	Supported Systems	Generator	Software
IGS01	GPS	Single-Epoch Combination	RETINA
IGS02	GPS	Kalman-Filter Combination	BNC
IGS03	GPS, GLONASS	Kalman-Filter Combination	BNC
CLK10	GPS	BKG	RTNet + BNC
CLK11	GPS, GLONASS	BKG	RTNet + BNC
CLK16	GPS	WHU	PANDA + BNC
CLK20	GPS	GSOC/DLR	RETICLE
CLK22	GPS	NRCan	HPGPSC
CLK53	GPS	ESA/ESOC	RETINA + BNC
CLK70	GPS	GFZ	Epos-RT + BNC
CLK80	GPS, GLONASS	GMV	magicGNSS
CLK91	GPS, GLONASS	CNES	PPP-Wizard + BNC
CLK93	GPS, GLONASS, GALILEO, BDS	CNES	PPP-Wizard + BNC

lists some product streams which are referred to the satellite antenna phase center (APC) in detail. From Table 1, it can be seen that some products are only available for GPS, while some of them support GPS and GLONASS. In particular, the product CLK93 released by CNES includes the correction information for GPS, GLONASS, GALILEO, and BDS [20]. Thus, the real-time product CLK93 is employed in this study for multi-GNSS real-time PPP processing. Though some analyses about the quality of real-time products can be found in References [19,21], the positioning performance of real-time multi-GNSS PPP using real-time products need to be investigated and evaluated further since the positioning accuracy and convergence time are the most important performance indicators of PPP, especially the convergence time.

This work focuses on the validation and positioning performance evaluation of multi-GNSS real-time PPP in simulated kinematic mode by using the IGS RTS. In Section 2, the computation method of how to derive the real-time precise satellite orbits and clocks from the RTS SSR products and broadcast ephemeris is introduced first, and the quality of real-time orbit and clock corrections of multi-GNSS of the CLK93 product is investigated. Following this, the detailed mathematic model and data processing strategies applied in this work for multi-GNSS simulated kinematic PPP are presented in Section 3. Moreover, the performances of convergence time and positioning accuracy of real-time multi-GNSS PPP in simulated kinematic mode are evaluated, and the evaluation results and analysis are given in Section 4. Finally, the discussion and conclusions are given in Section 5 and Section 6, respectively.

2. Real-Time Precise Satellite Orbits and Clocks from IGS RTS

2.1. Computation Method of Real-Time Precise Satellite Orbits and Clocks

The information of satellite orbit and clock corrections in the RTCM-SSR format can be expressed as:

$${\mathsf{\Delta }}_{ssr}(t_0,IODE)=(\delta O_r,\delta O_a,\delta O_c;\delta {\dot{O}}_r^{},\delta {\dot{O}}_a^{},\delta {\dot{O}}_c^{};C_0,C_1,C_2)$$

(1)

where t₀ is the Issue of Data (IOD); IODE represents the corresponding broadcast ephemeris used for the calculation of the current orbit and clock corrections; (δO_r, δO_a, δO_c) are the correction components in radial, along-track, and cross-track directions; $(\delta {\dot{O}}_r^{},\delta {\dot{O}}_a^{},\delta {\dot{O}}_c^{})$ are the correction rates in radial, along-track, and cross-track directions; and (C₀, C₁, C₂) are the polynomial coefficient terms of the real-time satellite clock corrections.

The RTCM-SSR real-time satellite orbit corrections, which are the corrections referred to the satellite broadcasted ephemerides, are defined in the RAC (radial, along-track, and cross-track) orbital coordinate system, but the broadcast ephemeris is referred to the Earth-Centered-Earth Fixed (ECEF) coordinate system; the real-time orbit corrections should be therefore transformed from the RAC coordinate system to the ECEF coordinate system [15,22].

For any epoch t, the real-time precise satellite orbit can be derived via the following steps:

(1) Compute the real-time corrections in the RAC coordinate system.

According to the SSR message, the orbit correction δO_t in the RAC coordinate system at epoch t can be derived by:

$$\delta O_t\equiv {\left[\begin{array}{l}\delta O_r\\ \delta O_a\\ \delta O_c\end{array}\right]}_t={\left[\begin{array}{l}\delta O_r\\ \delta O_a\\ \delta O_c\end{array}\right]}_{t_0}+\left[\begin{array}{l}\delta {\dot{O}}_r^{}\\ \delta {\dot{O}}_a^{}\\ \delta {\dot{O}}_c^{}\end{array}\right]\cdot (t-t_0)$$

(2)

where (δO_r, δO_a, δO_c)_t are the correction components in radial, along-track, and cross-track directions for epoch t.

(2) Transform the RAC corrections into ECEF corrections.

In order to transform the RAC corrections into ECEF corrections, the transformation matrix R has to be computed first; it is expressed as [18]:

$$R\equiv {\left[{\overrightarrow{e}}_r,{\overrightarrow{e}}_a,{\overrightarrow{e}}_c\right]}^T={\left[\frac{\overrightarrow{v}}{\left|\overrightarrow{v}\right|}\times \frac{\overrightarrow{r}\times \overrightarrow{v}}{|\overrightarrow{r}\times \overrightarrow{v}|},\frac{\overrightarrow{v}}{\left|\overrightarrow{v}\right|},\frac{\overrightarrow{r}\times \overrightarrow{v}}{|\overrightarrow{r}\times \overrightarrow{v}|}\right]}^T$$

(3)

where $({\overrightarrow{e}}_r,{\overrightarrow{e}}_a,{\overrightarrow{e}}_c)$ are the unit vectors in radial, along-track, and cross-track directions; $\overrightarrow{r}$ and $\overrightarrow{v}$ are, respectively, the broadcast satellite position vector and velocity vector at epoch t computed by the broadcast ephemeris.

Following this, the ECEF orbit corrections δX_t for epoch t can be derived by:

$$\delta X_t\equiv {\left[\begin{array}{l}\delta x\\ \delta y\\ \delta z\end{array}\right]}_t=R\cdot {\left[\begin{array}{l}\delta O_r\\ \delta O_a\\ \delta O_c\end{array}\right]}_t$$

(4)

where (δx, δy, δz)_t are the correction components in the X, Y, and Z directions for epoch t.

(3) Correct the broadcast satellite coordinates by applying the ECEF orbit corrections.

The broadcast satellite coordinates of each GNSS can be calculated according to the corresponding signal-in-space interface control documents (SIS-ICDs). Once the above steps are completed, the precise satellite coordinates for epoch t can then be computed by:

$${\left[\begin{array}{l}{X}_{prec}\\ Y_{prec}\\ Z_{prec}\end{array}\right]}_t={\left[\begin{array}{l}{X}_{brdc}\\ Y_{brdc}\\ Z_{brdc}\end{array}\right]}_t-{\left[\begin{array}{l}\delta x\\ \delta y\\ \delta z\end{array}\right]}_t$$

(5)

where (X_brdc, Y_brdc, Z_brdc) are the broadcast satellite coordinates in the ECEF coordinate system; (X_prec, Y_prec, Z_prec) are the precise satellite coordinates for PPP. It is worth noting that the phase center offsets (PCOs) of satellites have to be corrected if the real-time satellite orbit corrections are referred to the satellite Center of Mass (CoM), but there is no need to do this for those that refer to APC.

As for the precise satellite clock at any epoch t, it can be derived by subtracting the real-time clock correction from the broadcast satellite clock, and is expressed as follows [18]:

$$\{\begin{array}{l}\delta C=C_0+C_1(t-t_0)+C_2{(t-t_0)}^2\\ t_{prec}^s=t_{brdc}^s-\frac{\delta C}{c}\end{array}$$

(6)

where (C₀, C₁, C₂) are the polynomial coefficients terms in the SSR clock correction message; δC is the real-time clock correction in meters obtained from the SSR clock correction message; c is the speed of light in meters per second in the vacuum; $t_{brdc}^s$ is the satellite time computed according to the corresponding GNSS SIS-ICD from the broadcast clock parameters; and $t_{prec}^s$ is the precise satellite time corrected by the SSR clock correction message.

2.2. Evaluation of Real-Time Precise Satellite Orbits and Clocks Derived from the CLK93 Product

Precise satellite orbit and clock products are the essential prerequisites of PPP; therefore, the performance of real-time PPP will rely highly on the quality of real-time SSR corrections. In order to evaluate the quality of real-time GPS, GLONASS, GALILEO, BDS orbit, and clock corrections, the real-time SSR product CLK93 is applied and the final precise product “GBM” for multi-GNSS from GFZ is chosen as a reference. The real-time CLK93 stream is received from BKG NTRIP Caster, and its update interval for the satellite orbit and clock SSR correction is 5 s. We analyzed the differences between the real-time corrections and the final products over seven days from DOY (day of year) 254 to 260 of the year 2017.

The satellite-specific root mean square (RMS) values of orbit differences in the radial, along-track, and cross-track directions are calculated between the real-time derived orbit and the GFZ’s final orbit products for the evaluation of the real-time orbit corrections. Additionally, the clock differences between the real-time derived clocks and the GFZ’s final clock products are computed to evaluate the quality of the real-time SSR clock corrections. In order to remove the systematic bias, the resulting clock differences are aligned in relation to a reference satellite, following the standard practice in IGS clock comparisons [23,24]. In this work, the chosen reference satellites are PRN#G32 for GPS, PRN#R24 for GLONASS, PRN#E30 for GALILEO, and PRN#C14 for BDS. The standard deviation (STD) value of each satellite clock, which has a significant impact on PPP results, is taken as the quality indicator to evaluate the accuracy of the satellite clock [19,25]. In addition, the RMS values of clock differences are also computed. The RMS values indicate the consistency of clock biases which directly propagate into the code range modeling [24]. The final presented satellite-specific RMSs of orbit differences as well as the STDs and RMSs of clock differences are the averaged results for seven days, as shown in Figure 1. Additionally, their mean values over all satellites are computed for each GNSS and are also presented in Figure 1. It should be noted that the five BDS Geostationary Earth Orbit (GEO) satellites (C01–C05) are excluded from the evaluation due to their current low final product accuracies.

For GPS satellites, the orbit accuracy is generally better than 3 cm in the radial and cross-track directions and 4 cm in the along-track direction, with the mean RMS of orbit errors being 2.12, 3.13, and 2.72 cm for the radial, along-track, and cross-track directions, respectively. The STD values of the clock differences are generally smaller than 0.1 ns (~3 cm) for each GPS satellite, with the mean STD value being 0.08 ns, which indicates that GPS has the most accurate clock products.

For GLONASS satellites, the orbit accuracy is generally about 3 to 4 cm in the radial direction and 6 cm in the cross-track direction, while it varies from 5 to 25 cm in the along-track direction; additionally, the STD values of the clock differences of GLONASS are generally smaller than 0.25 ns. However, there is an exception for the PRN#R09 satellite, whose radial accuracy and clock STD is about 11 cm and 0.6 ns, respectively. The mean accuracy of the GLONASS orbit is 3.22, 10.47, and 6.22 cm for the radial, along-track, and cross-track directions, respectively. The mean clock accuracy is 0.2 ns of the STD for GLONASS, which is comparatively worse than that of GPS.

For GALILEO, the orbit accuracy is generally about 2, 4.5, and 7 cm, respectively, in the radial, cross-track, and along-track directions, with the mean accuracy being 1.93, 6.44, and 4.41 cm. It is slightly worse than that of GPS in the along-track direction. The STD values of GALILEO clocks are generally smaller than 0.15 ns, with the mean clock accuracy being 0.13 ns, which is close to that of GPS.

However, the orbit accuracy for BDS satellites (C06–C14) is 7.21, 16.50, and 18.95 cm on average for the radial, along-track, and cross-track directions, respectively, which is worse than that of GPS, GLONASS, and GALILEO. As to the accuracy of the BDS clock, the mean STD value of the clock differences is 0.24 ns, which is three times more than that of GPS.

3. Real-Time Multi-GNSS PPP

3.1. Mathematic Model of Multi-GNSS PPP

The traditional undifferenced Ionospheric-Free Linear Combination (IFLC) model between two different frequency signals is normally applied in precise point positioning to remove first-order ionospheric delay errors. The IFLC code and carrier-phase observations can be expressed as follows [26,27]:

$$\{\begin{array}{l}{P}_{r,IF}^{SYS,s}=\alpha P_{r,1}^{SYS,s}+\beta P_{r,2}^{SYS,s}={\rho }_r^{SYS,s}+c(\delta t_r^{SYS}-\delta t^{SYS,s})+T_r^{SYS,s}+(b_{r,IF}^{SYS}-b_{IF}^{SYS,s})+{\epsilon }_{r,IF}^{SYS,s}\\ {\mathsf{\Phi }}_{r,IF}^{SYS,s}=\alpha {\mathsf{\Phi }}_{r,1}^{SYS,s}+\beta {\mathsf{\Phi }}_{r,2}^{SYS,s}={\rho }_r^{SYS,s}+c(\delta t_r^{SYS}-\delta t^{SYS,s})+T_r^{SYS,s}+N_{r,IF}^{SYS,s}+({\phi }_{r,IF}^{SYS}-{\phi }_{IF}^{SYS,s})+{\zeta }_{r,IF}^{SYS,s}\\ \alpha =f_1^2/(f_1^2-f_2^2),\beta =-f_2^2/(f_1^2-f_2^2)\end{array}$$

(7)

where the superscripts SYS and s represent the satellite system (GPS, GLONASS, GALILEO, and BDS) and the corresponding satellite PRN (Pseudo Random Noise) number; the subscript r represents a user receiver and the subscripts 1 and 2 represent the signal band (for example, GPS L1 and L2); P_i and Φ_i (i = 1, 2) represent the raw code and carrier-phase observations (in meters), respectively; P_IF and Φ_IF are the ionospheric-free code and carrier-phase observables, respectively; α and β are the coefficients for forming the IFLC model; f₁ and f₂ are the two carrier-phase frequencies in Hertz; ${\rho }_r^s=\Vert X^s-X_r\Vert$ is the geometric range between satellite s and receiver r in meters; c is the speed of light in meters per second in the vacuum; δt_r is the receiver clock offset in seconds; δt^s is the satellite clock offset in seconds; $T_r^s$ is the tropospheric delay in meters; N_IF is the IFLC ambiguity of the carrier-phase in meters; $b_{r,IF}$ and $b_{IF}^s$ are the IFLC code hardware delays in meters for receiver r and satellite s, respectively; ${\phi }_{r,IF}$ and ${\phi }_{IF}^s$ are the IFLC uncalibrated phase delays in meters for the receiver r and satellite s, respectively; and finally, ${\epsilon }_{IF}$ and ${\zeta }_{IF}$ represent the IFLC pseudo-range and carrier-phase observation noises in meters, respectively.

As an IGS convention, the precise clock products are generated using the ionospheric-free linear combination; as a result, the satellite-dependent IFLC code hardware delays are absorbed in satellite clock products [28,29], while the receiver-dependent IFLC code hardware delay will be absorbed by the receiver clock. Thus, the above equation can be rewritten as:

$$\{\begin{array}{l}{P}_{r,IF}^{SYS,s}={\rho }_r^{SYS,s}+c\delta {\tilde{t}}_r^{SYS}-c\delta {\tilde{t}}^{SYS,s}+T_r^{SYS,s}+{\epsilon }_{r,IF}^{SYS,s}\\ {\mathsf{\Phi }}_{r,IF}^{SYS,s}={\rho }_r^{SYS,s}+c\delta {\tilde{t}}_r^{SYS}-c\delta {\tilde{t}}^{SYS,s}+T_r^{SYS,s}+B_{r,IF}^{SYS,s}+{\zeta }_{r,IF}^{SYS,s}\end{array}$$

(8)

with

$$\{\begin{array}{l}c\delta {\tilde{t}}^s=c\delta t^s+b_{,IF}^s\\ c\delta {\tilde{t}}_r=c\delta t_r+b_{r,IF}\\ B_{r,IF}^s=N_{r,IF}^s+({\phi }_{r,IF}-{\phi }_{,IF}^s)-(b_{r,IF}-b_{,IF}^s)\end{array}$$

(9)

Hence, for a multi-constellation case, the general GPS/GLONASS/GALILEO/BDS combined IFLC PPP equation can be written as:

$$\{\begin{array}{l}{P}_{r,IF}^{G,s}={\rho }_r^{G,s}+c\delta {\tilde{t}}_r^G-c\delta {\tilde{t}}^{G,s}+T_r^{G,s}+{\epsilon }_{r,IF}^{G,s}\\ {\mathsf{\Phi }}_{r,IF}^{G,s}={\rho }_r^{G,s}+c\delta {\tilde{t}}_r^G-c\delta {\tilde{t}}^{G,s}+T_r^{G,s}+B_{r,IF}^{G,s}+{\zeta }_{r,IF}^{G,s}\\ P_{r,IF}^{R,s}={\rho }_r^{R,s}+c\delta {\tilde{t}}_r^R-c\delta {\tilde{t}}^{R,s}+T_r^{R,s}+{\epsilon }_{r,IF}^{R,s}\\ {\mathsf{\Phi }}_{r,IF}^{R,s}={\rho }_r^{R,s}+c\delta {\tilde{t}}_r^R-c\delta {\tilde{t}}^{R,s}+T_r^{R,s}+B_{r,IF}^{R,s}+{\zeta }_{r,IF}^{R,s}\\ P_{r,IF}^{E,s}={\rho }_r^{E,s}+c\delta {\tilde{t}}_r^E-c\delta {\tilde{t}}^{E,s}+T_r^{E,s}+{\epsilon }_{r,IF}^{E,s}\\ {\mathsf{\Phi }}_{r,IF}^{E,s}={\rho }_r^{E,s}+c\delta {\tilde{t}}_r^E-c\delta {\tilde{t}}^{E,s}+T_r^{E,s}+B_{r,IF}^{E,s}+{\zeta }_{r,IF}^{E,s}\\ P_{r,IF}^{C,s}={\rho }_r^{C,s}+c\delta {\tilde{t}}_r^C-c\delta {\tilde{t}}^{C,s}+T_r^{C,s}+{\epsilon }_{r,IF}^{C,s}\\ {\mathsf{\Phi }}_{r,IF}^{C,s}={\rho }_r^{C,s}+c\delta {\tilde{t}}_r^C-c\delta {\tilde{t}}^{C,s}+T_r^{C,s}+B_{r,IF}^{C,s}+{\zeta }_{r,IF}^{C,s}\end{array}$$

(10)

where the superscripts G, R, E, and C stand for GPS, GLONASS, GALILEO, and BDS, respectively.

Instead of estimating the receiver clock parameters with respect to each GNSS, the additional inter-system biases (ISBs) are introduced alternatively with respect to a GNSS time scale (GPST). As for the tropospheric delay term, the Global Mapping Function (GMF) [30] is applied to convert the zenith delay to a slant delay, and the tropospheric zenith delay is estimated as an unknown parameter. After applying the precise satellite orbits and clocks derived from the RTS SSR message and broadcast ephemeris, four types of estimated parameters in multi-GNSS IFLC PPP are the user’s coordinates $(x_u,y_u,z_u)$, the receiver clock offset and the inter-system biases with respect to GPST $(\delta {\tilde{t}}_r^G,\delta t_{ISB}^{G-SYS})$, the tropospheric zenith delay T_z, and the real-valued IFLC phase ambiguities $B_{r,IF}^{SYS,s}$.

3.2. Real-Time PPP Data Processing Models/Strategies

In

Table 2. Data processing strategies and settings for real-time multi-GNSS PPP.

Items	Models/Strategies
Processing mode	Real-time (receiving real-time data streams in RTCM format via NTRIP);
Observations	Ionospheric-free linear combination code and carrier-phase measurements;
Constellations	GPS/GLONASS/BDS/GALILEO;
Signal frequencies	GPS/GLONASS: L1&L2; BDS: B1&B2; GALILEO: E1&E5a;
Estimator	Extended Kalman Filter (EKF) [31];
Data interval	1 s;
Elevation cutoff angle	7°;
Stochastic model and weighing strategy	A priori precision of 1.0 cm and 1.0 m for carrier-phase and pseudo-range; The elevation-dependent stochastic model ${\sigma }^2={\sigma }_0^2/{\sin }^2(el)$ is applied; The standard deviation ratio among GPS, GLONASS, BDS, and GALILEO observations are set to 1:2:2:2; Down-weighting for GLONASS pseudo-range to reduce the effect of IFBs; Down-weighting for BDS GEO satellites due to the poor qualities of their orbit and clock products;
Precise satellite orbits and clocks	Derived from real-time streams: CLK93 (APC) + broadcast ephemeris (RTCM3EPH-MGEX);
Receiver antenna phase center	PCO and PCV values for GPS and GLONASS from igs14.atx file are used; Corrections for BDS and GALILEO are assumed the same as those for GPS since the precise corrections are not currently available [12,29]; Considering the elevation and azimuth dependent terms;
Code biases	Using CODE’s DCB products to correct the satellite-end P1C1 differential code biases (DCB) [32]; The elevation- and frequency-dependent corrections are applied for BDS code measurements [33];
Ionospheric delay	Using the IFLC model to eliminate the first-order ionospheric delay;
Zenith tropospheric delay	A priori value provided by Saastamonien model [34]; Estimated as random-walk noise (10−8 m2/s); The Global Mapping Function [30] is applied; The troposphere gradient parameters in north and east directions are also estimated;
Tidal effects	Corrected by IERS Convention 2010, including solid earth tide and ocean tide loading [35];
Phase windup	Corrected [36];
Station coordinates	Estimated as white noises in simulated kinematic mode;
Receiver clock offset and ISBs	Estimated as white noise;
Phase ambiguities	Estimated as real value;
Cycle slips	Detected by the Melbourne-Wübbena (MW) combination and Geometry-Free (GF) combination.

, we provide the detailed data processing models/strategies and settings for the real-time multi-GNSS simulated kinematic PPP applied in our study. The input observation data for the PPP model are both the undifferenced first-order ionosphere-free linear combination of multi-GNSS code and the carrier-phase measurements. All raw data are received from NTRIP Caster in real-time via NTRIP in RTCM format. Figure 2 briefly shows the flow diagram of the real-time PPP processing in this study.

4. Performance Evaluation of Real-Time Multi-GNSS Simulated Kinematic PPP

4.1. Evaluation of the Convergence Time of Real-Time PPP

In order to investigate the convergence/initialization time of real-time PPP in simulated kinematic mode, the PPP estimator, based on the processing strategies given in Table 2, is restarted repeatedly every 4 h. This is automatically controlled by software, i.e., we can obtain six sessions of PPP results in one day. The real-time streams of observations from three IGS/MGEX stations (FFMJ, POTS, SIN1), the CLK93 (APC) stream of the SSR orbit/clock correction product, and the RTCM3EPH-MGEX stream of the multi-GNSS broadcast ephemeris are received via NTRIP and decoded in real-time for PPP processing. All the real-time data are received from BKG NTRIP Caster and the length of the testing period is about two weeks.

Table 3. Station information for the test of real-time PPP convergence time.

Station	Location	Receiver	Antenna	Combined Systems
FFMJ	Germany	TRIMBLE NETR9	LEIAR25.R4 + LEIT	G
POTS	Germany	JAVAD TRE_G3TH DELTA	JAV_RINGANT_G3T + NONE	G/R
SIN1	Singapore	TRIMBLE NETR9	LEIAR25.R3 + LEIT	G/R/C/E

gives information on selected stations, such as receiver type, antenna type, etc. The system combination mode of PPP processing is GPS-only for FFMJ, GPS + GLONASS for POTS, and GPS + GLONASS + BDS + GALILEO for SIN1. The convergence times of real-time PPP in East (E), North (N), Horizontal (H), and Up (U) or Vertical directions are evaluated respectively. Additionally, the convergence condition is defined as the absolute positioning error remains below 20 cm for at least 10 min afterward for the corresponding direction. The positioning error is the difference between the real-time PPP solution and the ‘true’ coordinate released by IGS in the weekly station information file (i.e., igs17Pweek.snx), except for the SIN1 station. Since, for the testing periods, there is no precise coordinate information for this station in the IGS station files, the ‘true’ coordinate of SIN1 is derived from post-processing of GPS-only static PPP using RTKLIB software.

As an example, Figure 3 illustrates the positioning error series in the E/N/U directions and the absolute positioning error series in the E/N/H/U directions of real-time simulated kinematic PPP in a time scale of 24 h, for each respective station. We can see that the large positioning errors occurred every 4 h because of the re-initialization of PPP when the estimator restarted in each session, and the positioning errors become inferior to 20 cm again after a short period of convergence time.

Figure 4, Figure 5 and Figure 6 show the bar series of the convergence time for the 20-cm level of each session (left) and the cumulative distribution function (CDF) curve of the convergence time (right) in the E/N/H/U directions for stations FFMJ, POTS, and SIN1, respectively. The statistical convergence times for the 20-cm level on average (ave) and at the 68% confidence level (1-sigma, 1σ) are computed for each station and are also presented in Figure 4, Figure 5 and Figure 6.

As shown in Figure 4, in the case of FFMJ, which is in GPS-only PPP mode, the averaged convergence times for the accuracy level of 20 cm in East, North, Horizontal, and Up directions are 12.6, 7.9, 16.2, and 11.9 min, respectively, and the 68% confidence-level convergence times are 12.2 min for the East direction, 8.8 min for the North direction, 14.2 min for the Horizontal direction, and 10.6 min for the Up direction.

For the POTS station in GPS + GLONASS combined PPP mode, as presented in Figure 5, it takes average times of 10.8, 6.7, 13.4, and 10.9 min to converge to the accuracy level of 20 cm in the East, North, Horizontal, and Up directions, respectively; meanwhile, when considering the 68% confidence-level, the convergence times for East, North, Horizontal, and Up directions are 9.1, 6.3, 12.5, and 10.4 min, respectively.

For the multi-GNSS case of combined GPS/GLONASS/BDS/GALILEO PPP carried out for the SIN1 station, Figure 6 shows that it takes 12.0 and 6.7 min on average to converge to the accuracy level of 20 cm in the Horizontal and Up/Vertical directions, respectively, which is shorter than the FFMJ and POTS times, especially since it only takes 3.7 min on average for the convergence in the North direction to be reached. In addition, it can be seen that the real-time PPP can, in some cases, also achieve a fast convergence of under 5 min to the accuracy level of 20 cm for FFMJ, POTS, and SIN1.

From Figure 4, Figure 5 and Figure 6, we can draw the conclusion that real-time PPP can achieve a convergence performance of under 15 min on average for the 20-cm level accuracy. Furthermore, despite a few cases which also have a long convergence time, multi-GNSS combined PPP, when compared with single GPS PPP, can accelerate convergence because of the significant increase of the number of observed satellites and the optimized spatial geometry to which multi-GNSS contributes. In addition, it can be further accelerated when the quality of the real-time satellite orbit and clock products of multi-GNSS are further improved.

4.2. Evaluation of the Accuracy of Real-Time PPP

In order to evaluate the accuracy of real-time multi-GNSS PPP, real-time data streams in RTCM format from 12 stations in the IGS/MGEX network are selected in this study. Additionally, the CLK93 (APC) stream of the SSR orbit/clock correction product and the RTCM3EPH-MGEX stream of the multi-GNSS broadcast ephemeris are received via NTRIP and decoded in real-time for PPP processing. Based on the real-time streams, real-time PPP was carried out continually in October 2017 (31 days) for each station separately. The data interval is 1 s and the detailed processing strategies are given in Table 2. The distribution of the selected stations for the experiment is shown in Figure 7. Detailed information (receivers and antennas) about these stations and the combination mode of GNSS systems for PPP of each station are given in

Table 4. Station information for the accuracy test of real-time PPP.

No.	Station	Receiver	Antenna	Combined Systems
1	FFMJ	JAVAD TRE_G3TH DELTA	LEIAR25.R4 + LEIT	G
2	POTS	JAVAD TRE_G3TH DELTA	JAV_RINGANT_G3T + NONE	G/R
3	MRO1	TRIMBLE NETR9	TRM59800.00 + NONE	G/R/C
4	PNGM	TRIMBLE NETR9	TRM59800.00 + NONE	G/R/C
5	COCO	SEPT POLARXS	AOAD/M_T + NONE	G/R/C
6	LAUT	TRIMBLE NETR9	JAVRINGANT_DM + NONE	G/R/C
7	HRAG	JAVAD TRE_G3TH DELTA	LEIAR25.R3 + LEIT	G/R/E
8	STFU	JAVAD TRE_G3TH DELTA	TRM57971.00 + NONE	G/R/E
9	UCAL	TRIMBLE NETR9	TRM57971.00 + NONE	G/R/E
10	GMSD	TRIMBLE NETR9	TRM59800.00 + SCIS	G/R/E/C
11	KZN2	TRIMBLE NETR9	TRM59800.00 + SCIS	G/R/E/C
12	SIN1	TRIMBLE NETR9	LEIAR25.R3 + LEIT	G/R/E/C

.

The real-time data streams for the tests of FFMJ, POTS, and SIN1 stations are received from the BKG NTRIP Caster, while the others are received from the self-built NTRIP Caster of Academy of Opto-Electronics (AOE) of the Chinese Academy of Sciences (CAS). To evaluate the positioning accuracy of real-time PPP, the daily RMS values of positioning errors in East, North, and Up directions for each station are computed. It should be noted that the PPP filter may be re-initialized due to the instability of real-time streams or networks, in which case the PPP results of the first 30 min of the re-initializing period are not taken into account in the evaluation.

Taking the second day during the one-month test as an example, Figure 8 shows the time series of positioning errors in the East, North, and Up components (denoted by blue/B, green/G, and red/R lines, respectively) for each station. The STD and RMS values of positioning errors are also computed for each station and are also presented in Figure 8.

From the results shown in Figure 8, we can see that the positioning errors for all of the stations vary slightly within ±5 cm in the East and North components for most of the epochs, with the daily RMS values ranging between 2 and 3 cm. Meanwhile, for the Up component, the positioning errors are ±10 cm most of the time, and the variation of the positioning error is more remarkable than that in the East and North components; for some epochs, the errors in the Up component can reach up to 15 to 20 cm, and this may be due to the lower accuracy of the precise satellite clock product in the corresponding periods.

To evaluate the positioning accuracy of real-time multi-GNSS PPP in simulated kinematic mode, the daily RMS values of positioning errors in the East, North, Up, Horizontal, and three-dimensional (3D) directions for each station are computed and depicted in Figure 9 as boxplots. Additionally, the mean RMS values in each direction for each station are given in

Table 5. Mean RMS value of positioning errors for each station.

No.	Station	Mean RMS (cm)
		E	N	U	H	3D
1	FFMJ	3.0	2.2	4.5	3.8	5.8
2	POTS	2.4	2.2	4.3	3.2	5.3
3	STFU	2.0	1.7	4.3	2.7	5.0
4	UCAL	3.0	2.4	5.5	3.8	6.7
5	HRAG	2.9	2.4	5.8	3.8	6.9
6	COCO	2.9	2.4	5.3	3.8	6.5
7	LAUT	2.8	2.4	4.9	3.7	6.2
8	MRO1	2.7	2.6	4.3	3.7	5.6
9	PNGM	3.0	2.4	5.5	3.8	6.7
10	GMSD	2.5	1.8	4.6	3.1	5.6
11	SIN1	2.6	1.8	4.9	3.2	5.8
12	KZN2	2.5	2.6	4.3	3.6	5.5

.

As can be seen from Figure 9 and Table 5, the variation of daily RMSs of positioning errors for each station are smoothly distributed over the whole testing period. For the East and North components in particular, the RMSs are generally smaller than 4.0 cm during most of the testing days, with a minimum value of about 1.5 cm. For all of the stations in general, the positioning accuracy of the North component is about 2.2 cm of the RMS on average, which is slightly better than that of the East component with an averaged RMS of about 2.7 cm. For the Up component, the daily RMS values of each station are generally below 6.0 cm during most of the days, with a minimum value of about 2.5 to 4.0 cm for different stations; the statistical positioning accuracies of each station in the Up direction range between 4.0 and 6.0 cm, which is worse than those in the East and North directions. The Horizontal and 3D accuracies are about 3.0 to 4.0 cm for the Horizontal direction and 5.0 to 7.0 cm for the 3D direction for different stations.

5. Discussion

By taking the final multi-GNSS precise product from GFZ as a reference, the qualities of real-time orbit and clock corrections of multi-GNSS in the CLK93 product are investigated, first with a testing period of seven days. By comparing our results with those in Reference [21], we can see that: (1) the evaluation results for GPS are very similar; and (2) the evaluation results for GLONASS and BDS are similar and at the same level; while (3) the evaluation result for the GALILEO orbit and clock accuracy in our study is better than that in Reference [21]. This difference is due to the differing data used in the analyses. There were only nine GALILEO satellites available (April 2016) in Reference [21], but in our study 15 GALILEO satellites were available during our testing period (September 2017). Additionally, the results reported in Reference [37] show that the orbit and clock accuracies of GPS and GALILEO satellites are better than those of GLONASS and BDS satellites. The evaluation results in our study show, similarly, that the current accuracies of the real-time precise products of GPS and GALILEO satellites are better than those of GLONASS and BDS.

The poor quality of the BDS RTS products could be attributed to the limited number of satellites in the current BDS constellation, as well as to the limited number of ground tracking stations. However, this is expected to be improved with new BDS satellites launched into orbit and a more densified tracking network in the near future [19,38]. In addition, although the RMS values of the along-track and cross-track components are larger than those of the radial component, the positioning users on the Earth’s surface are less sensitive to errors in along-track and cross-track directions than to those in the radial direction; the orbit errors in the along-track and cross-track directions may therefore have a less significant impact on the accuracy of user positioning [24].

Following this, in order to analyze the convergence performance of real-time PPP in simulated kinematic mode, an experiment of real-time PPP processing was carried out over about two weeks for three IGS/MGEX stations. Finally, to assess and validate the positioning accuracy of real-time multi-GNSS PPP in simulated kinematic mode, another real-time PPP processing experiment was carried out continually in October 2017 over 31 days by applying the real-time data streams from 12 globally distributed stations in the IGS/MGEX network. From the experiment results given in Figure 4, Figure 5 and Figure 6, we can see that there are big differences between the minimum and maximum convergence times for the 20-cm level. This may be caused by the poor quality of real-time products or by the poor stability of real-time data streams during some periods. On the one hand, the quality (accuracy and availability) of the real-time products in different periods may be different, especially for GLONASS, GALILEO, and BDS satellites. On the other hand, there are some uncertain factors which cannot be avoided in real-time processing, such as the potential instability or unavailability of real-time products broadcasted by NTRIP Caster, the loss of a network connection with the Caster when receiving data streams on the user’s side, etc. As a result, the stability of the real-time PPP solutions will be influenced.

It is difficult to determine the optimum weights or the stochastic models for multi-GNSS observations, especially in real-time processing currently. In our work, the weights for GLONASS, GALILEO, and BDS are increased by a factor of 2.0 times to GPS to limit their contributions to the solutions in multi-GNSS PPP, due to the lower accuracy of their real-time satellite orbit and clock products and the lower number of visible satellites of GALILEO and BDS currently available. These empirical weighting factors are obtained by numerous multi-GNSS PPP (in static and kinematic) data processing both in real time and post-mission. An optimum weighting strategy or stochastic model for real-time processing was proposed in Reference [39], in which the quality of the real-time orbit and clock products (expressed with signal-in-space ranging errors (SISRE)) should be taken into account for weighting the multi-GNSS observations. Also in Reference [39], it was suggested that a service for regular monitoring of SISRE values for real-time products should be prepared, which could be applied in future works connected with multi-GNSS real-time positioning.

With the future development of GLONASS, BDS, and GALILEO systems, the accuracies of multi-GNSS orbit and clock products will be further improved. As a result, the positioning performance of multi-GNSS real-time PPP will be better in the near future.

6. Conclusions

With the operation of the IGS real-time service, it becomes possible to obtain precise satellite orbit and clock products of multi-GNSS in real-time, after which real-time PPP can be conducted. Currently, the CLK93 product released by CNES, which was used for real-time PPP processing in this study, includes the correction information for multi-GNSSs such as GPS, GLONASS, GALILEO, and BDS.

In this contribution, a detailed description of the recovery method for precise satellite orbits and clocks from the real-time SSR messages and the broadcast ephemeris is introduced. By taking the final multi-GNSS precise product “GBM” from GFZ as a reference, the qualities of real-time orbit and clock corrections of multi-GNSS in the CLK93 product were investigated over a seven-day testing period. Following this, we carried out a real-time PPP processing for three IGS/MGEX stations with a testing period of about two weeks by restarting the PPP estimator every 4 h, in order to analyze the convergence performance of real-time PPP in the simulated kinematic mode. Finally, the real-time data streams over one month from 12 globally distributed stations in the IGS/MGEX network were used to assess and validate the positioning accuracy of real-time multi-GNSS PPP in simulated kinematic mode.

The evaluation results show that the orbit and clock corrections of GPS, GLONASS, GALILEO, and BDS in the CLK93 product exhibit different accuracies in their current stages. GPS has the best accuracies, which are about 2 cm in the radial direction and 3 cm in along-track and cross-track directions for orbits, and 0.08 ns (~2.4 cm) for clocks, respectively. For GALILEO, the orbit accuracies are about 2, 6, and 4 cm in the radial, along-track, and cross-track directions, respectively, and the clock accuracy is about 0.13 ns. GLONASS’s accuracy is relatively worse than that of GPS and GALILEO; its orbit accuracy is about 3, 10, and 6 cm in the radial, along-track, and cross-track directions, while the clock accuracy is about 0.2 ns. Meanwhile, for BDS the orbit accuracies in the radial, along-track, and cross-track directions are about 7, 17, and 19 cm respectively, and the clock accuracy is 0.24 ns; these accuracies are worse than those of other GNSSs.

As for the positioning performance of real-time PPP, the experimental results show that (1) the real-time PPP can achieve a convergence performance of less than 15 min for the accuracy level of 20 cm; and (2) the positioning accuracies better than 10 cm can be achieved by real-time PPP for those IGS/MGEX stations that are in simulated kinematic mode; these accuracies are about 3.0 to 4.0 cm for the Horizontal direction and 5.0 to 7.0 cm for the 3D direction for different stations.