Introduction

In global navigation satellite system (GNSS) time-critical applications, the differential real-time kinematic (RTK) technique has prevailed for more than two decades. For conventional RTK, its service coverage is usually limited within a few tens of kilometers as the positioning accuracy decreases with increasing base-to-rover distances (Leick et al. 2015). This issue has been improved with the advent of network RTK (NRTK), which typically involves an array of continuously operating reference stations (CORS). However, owing largely to the inadequate atmospheric modeling, the interstation distances are still restricted to around 50–100 km for most NRTK implementations (Wielgosz et al. 2005; Grejner-Brzezinska et al. 2007; Li et al. 2010). Also, an extensive NRTK service is often impeded by the enormous costs of establishing and maintaining reference station networks, particularly in less-developed areas. While much research has been devoted to resolving the ambiguities for long-range RTK, it remains challenging to provide centimeter-level positioning for those applications where, for instance, baselines over 1000 km are desired, such as in marine geodesy and GNSS seismology (Feng 2008; Takasu and Yasuda 2010; Li et al. 2017).

With a stand-alone GNSS receiver, PPP can offer global geocentric solutions with centimeter- to millimeter-level accuracy in static mode and decimeter- to centimeter-level accuracy in kinematic mode (Malys and Jensen 1990; Zumberge et al. 1997; Kouba and Héroux 2001). In the past decade, RTPPP has been intensively studied in a wide variety of applications such as crustal deformation monitoring (Wright et al. 2012), tsunami early warning (Bar-Sever et al. 2009), atmosphere remote sensing (Dousa and Vaclavovic 2014), and maritime applications (Yang et al. 2019). Unlike the differential techniques, RTPPP does not rely on regional/local reference networks, but essentially requires the real-time precise satellite orbit and clock corrections, which are normally provided by external sources, e.g., the International GNSS Service (IGS) and its analysis centers.

Currently, the prediction accuracy of the ultra-rapid orbit products offered by most IGS analysis centers can be maintained at the level of about 5 cm for GPS and 13 cm for GLONASS within a few hours, which meets the needs of most RTPPP applications (Hadas and Bosy 2015). However, the predicted satellite clocks of the ultra-rapid products may fluctuate by several nanoseconds over a short period due to volatile and nonlinear behavior of the onboard atomic frequency standards (Hauschild and Montenbruck 2009). In order to provide RTPPP services to their users, some commercial companies like Fugro, Trimble, and Navcom routinely broadcast precise satellite clock corrections that are estimated in real time through global GNSS networks (Melgard et al. 2009; Leandro et al. 2011; Dai et al. 2016). In April 2013, the IGS launched the real-time service (RTS) with the goal of satisfying real-time users with precise satellite products to enable sub-decimeter RTPPP globally. The IGS RTS is currently able to provide real-time GPS clock corrections with an accuracy of better than 0.2 ns, whereas only a few analysis centers offer real-time GLONASS clock products. However, the heavy reliance on the real-time satellite clock products offered by external sources sometimes has a disadvantage. For instance, RTPPP applications are likely to be interrupted or limited if the real-time corrections are inaccessible or completely unavailable. Note that due to the volunteer nature of IGS, the RTS is offered without a service guarantee of accuracy or availability. Once the real-time data streams from tracking stations have been received, the satellite clock offsets are estimated independently within each analysis center (AC) and are made available to users through NTRIP (Network Transport of RTCM via Internet Protocol) casters. Unfortunately, real-time products generated by individual ACs usually suffer from unexpected outages, which may affect some specific satellites or even the whole constellation. This issue can be attributed to incomplete data streams, network transmission interruption, and dissemination caster malfunctioning (Kazmierski et al. 2018; Nie et al. 2018). Moreover, it is also difficult to detect outliers pertaining to a single AC product in real time and thus may increase the uncertainty of RTPPP applications (Chen et al. 2017). In order to ensure a robust distribution and to maximize availability, a redundancy concept has been designed and implemented in the process of generation and distribution of the RTS real-time corrections. The real-time correction products from at least three ACs are generated first and then transmitted to the real-time analysis center coordinator (RTACC) where they are combined and delivered. Though the reliability and stability of correction streams have been significantly improved, the availability of the RTS combination product is only about 90–95%, i.e., not readily available all the time (Hadas and Bosy 2015; Shi et al. 2017; Kazmierski et al. 2018). As to correction latency, each contributing AC needs about 10 s to deliver their uncombined products, and the RTACC requires at minimum an additional 10 s to collect data, analyze results, and eliminate outliers. The total latency of such a combination process is approximately 20 s or even longer, which is still noticeable for applications with a critical requirement on timing (Hadas and Bosy 2015; Zhang et al. 2018).

Since the 1990s, the IGS has established a network of over 500 permanent stations worldwide, providing open access to the public to GNSS tracking data at various observation intervals. In most recent years, following the IGS multi-GNSS Experiment (MGEX), the number of multi-GNSS stations capable of tracking one or more of the emerging constellations, such as Galileo and BeiDou, has increased drastically. About half of these stations have already been able to provide 1-Hz real-time GPS/GLONASS data streams, typically with transmission latency of 3 s or less. Making the best use of the IGS multi-GNSS network, we here introduce an approach of real-time undifferenced precise positioning, referred to as RUP, which is independent of any external satellite clock corrections. Contrary to differential RTK/NRTK techniques, which provide user coordinates relative to certain terrestrial reference site(s), RUP is designed to use IGS stations in an undifferenced manner and can provide absolute positioning in the global reference frame. It may also be distinguished from the practices of PPP-RTK (Wübbena et al. 2005; Geng et al. 2011; Teunissen and Khodabandeh 2015) or instantaneous ambiguity-fixed PPP (Mervart et al. 2008; Li et al. 2011; Collins et al. 2012), for which local GNSS reference networks are a necessity in order to provide proper atmospheric corrections.

Processing strategy

We begin with a brief introduction of real-time GPS satellite clock estimation using the extended Kalman filter (EKF). On that basis, an alternative approach of precise point positioning coupled with the GPS/GLONASS clock estimation is presented.

Real-time satellite clock estimation based on the extended Kalman filter

With the undifferenced code and phase observations, the simplified observation equations of GNSS tracking station \(r\) and satellite \(i\) (taking GPS as an example) may be described as

$$\begin{gathered} P_{{{\text{IF}},i}}^{{\text{G}}} = \rho^{{\text{G}}} + c({\text{d}}t_{r}^{{\text{G}}} - {\text{d}}t_{i}^{{{\text{G}}/{\text{s}}}} ) + \delta_{{{\text{trop}},i}}^{{\text{G}}} + \varepsilon_{{\text{P}}}^{{\text{G}}} \\ \Phi_{{{\text{IF}},i}}^{{\text{G}}} = \rho^{{\text{G}}} + c({\text{d}}t_{r}^{{\text{G}}} - {\text{d}}t_{i}^{{{\text{G}}/{\text{s}}}} ) + \lambda N_{{{\text{IF}},i}}^{{\text{G}}} + \delta_{{{\text{trop}},i}}^{{\text{G}}} + \varepsilon_{{\Phi }}^{{\text{G}}} \\ \end{gathered}$$
(1)

where the superscript G denotes the GPS system, \(P_{{{\text{IF}},i}}^{{\text{G}}}\) and \(\Phi_{{{\text{IF}},i}}^{{\text{G}}}\) represent the undifferenced ionospheric-free (IF) combination of dual-frequency code and phase observations, respectively, \(\rho^{{\text{G}}}\) denotes the satellite-to-receiver geometric distance, \({\text{d}}t_{r}^{{\text{G}}}\) is the reparameterized GPS receiver clock error, which consists of the original receiver clock error \({\text{d}}t_{r}\) and the code hardware delay \(D_{r}^{{\text{G}}}\), i.e., \({\text{d}}t_{r}^{{\text{G}}} = {\text{d}}t_{r} + D_{r}^{{\text{G}}}\), \({\text{d}}t_{i}^{{{\text{G}}/{\text{s}}}}\) is the satellite clock error, and \(c\) is the speed of light. \(\delta_{{{\text{trop}},i}}^{{\text{G}}}\) denotes the slant tropospheric delay, \(N_{{_{{{\text{IF}}}} ,i}}^{\text{G}}\) and \(\lambda\), respectively, refer to the float ambiguity and the wavelength corresponding to the phase IF combination, and \(\varepsilon_{{\text{P}}}^{{\text{G}}}\) and \(\varepsilon_{{\Phi }}^{{\text{G}}}\) are measurement noises.

In real-time satellite clock estimation, the orbit information may be acquired from the ultra-rapid orbit products. The tracking station coordinates are usually fixed or strongly constrained to known values, which can be obtained from the latest IGS SINEX (solution-independent exchange format) file. Note that the satellite and receiver clock parameters are linearly dependent in (1) and cannot be separated from each other. To avoid the singularity of the normal equation, one needs to select a reference clock from the receiver clocks of tracking stations. Consequently, the estimated satellite and receiver clocks are all aligned to the selected reference clock.

Assuming that there are \(k\) tracking stations contributing to the solution and the number of all visible GPS satellites is \(p\), the functional model for estimating GPS satellite clocks becomes

$$\left[ {\begin{array}{*{20}c} {\mathop {\tilde{{P}}_{{{\text{IF}}}}^{{\text{G}}} (t)}\limits_{p \times 1} } \\ {\mathop {\tilde{{\Phi }}_{{{\text{IF}}}}^{{\text{G}}} (t)}\limits_{p \times 1} } \\ \end{array} } \right] = \left[ {\begin{array}{*{20}c} {\mathop {{\varvec{A}}_{{}}^{{\text{G}}} }\limits_{(k - 1) \times 1} } & {\mathop {{\varvec{A}}_{{{\text{zwd}}}}^{{\text{G}}} }\limits_{k \times 1} } & {\mathop {{\varvec{A}}_{{}}^{{\text{G/s}}} }\limits_{m \times 1} } & {\mathop {{\varvec{A}}_{N}^{{\text{G}}} }\limits_{p \times 1} } \\ \end{array} } \right]\left[ {\begin{array}{*{20}c} {\mathop {{\delta t}_{{}}^{{\text{G}}} }\limits_{(k - 1) \times 1} } \\ {\mathop {{\delta {\rm T}}_{{{\text{zwd}}}} }\limits_{k \times 1} } \\ {\mathop {{\delta t}_{{}}^{{\text{G/s}}} }\limits_{m \times 1} } \\ {\mathop {{\varvec{N}}_{{{\text{IF}}}}^{{\text{G}}} }\limits_{p \times 1} } \\ \end{array} } \right] + {\varvec{\varepsilon}}_{{}}^{{\text{G}}} ,_{{}}^{{}} {\varvec{\varepsilon}}_{{}}^{{\text{G}}} \sim N(0,{\varvec{\varOmega}}^{{\text{G}}} )$$
(2)

where \(m\) is the number of GPS satellites. \(\tilde{{P}}_{{{\text{IF}}}}^{{\text{G}}} (t)\) and \(\tilde{{\Phi }}_{{{\text{IF}}}}^{{\text{G}}} (t)\) denote the corrected (observed-minus-computed) code and phase observation vectors. The unknown parameter vectors are \({\delta t}_{{}}^{{\text{G}}}\), \({\delta {\rm T}}_{{{\text{zwd}}}}\), \({\delta t}_{{}}^{{\text{G/s}}}\) and \({\varvec{N}}_{{{\text{IF}}}}^{{\text{G}}}\), corresponding to reparameterized GPS receiver clock errors, zenith wet delays, GPS satellite clock errors, and phase ambiguities. The design matrices are \({\varvec{A}}_{{}}^{{\text{G}}}\), \({\varvec{A}}_{{{\text{zwd}}}}^{{\text{G}}}\), \({\varvec{A}}_{{}}^{{\text{G/s}}}\), and \({\varvec{A}}_{N}^{{\text{G}}}\), and \({\varvec{\varepsilon}}^{{\text{G}}}\) is the measurement noise vector, following a normal distribution with mean zero and covariance matrix \({\varvec{\varOmega}}^{{\text{G}}}\).

Thus, the unknown parameters can be estimated with the EKF, including a set of error corrections for zenith hydrostatic delay, earth and ocean tides, relativistic effect, phase wind-up, antenna phase center offsets and variation for satellites and receivers. Regarding the stochastic model, the satellite and receiver clock errors are treated as white noises; the variation of residual zenith tropospheric delay is viewed as a process of a random walk; and the phase ambiguities are estimated as float values, which are assumed to be constant between neighboring observation epochs.

Coupling satellite clock estimation with precise point positioning

The method described above has been generally applied to real-time satellite clock estimation, usually with the support of a large network of GNSS tracking stations (Hauschild 2010). Due to the heavy computational load, the satellite clock corrections can only be updated every 5 s by most of the RTS ACs (Zhang et al. 2011; Ge et al. 2012). In fact, setting aside the unknown parameters to be determined, the code and phase observation equations in the satellite clock estimation are identical to those in PPP. In other words, GNSS satellite clock estimation and PPP essentially share the same functional model. Given that all the satellite clock offsets are to be determined, each station within the network is indeed undergoing a procedure that can be readily recognized as PPP. Inspired by this, we propose an approach of undifferenced precise positioning with satellite clock offsets estimated simultaneously, where the observation equations of user stations are jointly established with those of tracking stations, holding the same parameters as traditional PPP. Intuitively, the observations acquired from the user stations contribute to the satellite clock estimates as well.

Assuming that there are \(z\) users at epoch \(t\), the linearized RUP observation matrix for GPS can be derived from (2). It follows that

$$\left[ {\begin{array}{*{20}c} {\mathop {\tilde{{P}}_{{{\text{IF}}}}^{{\text{G}}} (t)}\limits_{p \times 1} } \\ {\mathop {\tilde{{\Phi }}_{{{\text{IF}}}}^{{\text{G}}} (t)}\limits_{p \times 1} } \\ \end{array} } \right] = \left[ {\begin{array}{*{20}l} {\mathop {{\varvec{A}}_{{}}^{{\text{G}}} }\limits_{2p \times (k + z - 1)} } \hfill & {\mathop {{\varvec{A}}_{{{\text{zwd}}}}^{{\text{G}}} }\limits_{2p \times (k + z)} } \hfill & {\mathop {{\varvec{A}}_{\psi }^{G} }\limits_{2p \times 3z} } \hfill & {\mathop {{\varvec{A}}_{{}}^{{\text{G/s}}} }\limits_{2p \times m} } \hfill & {\mathop {{\varvec{A}}_{N}^{{\text{G}}} }\limits_{2p \times p} } \hfill \\ \end{array} } \right]\left[ {\begin{array}{*{20}l} {\mathop {{\delta t}_{{}}^{{\text{G}}} }\limits_{(k + z - 1) \times 1} } \hfill \\ {_{{}}^{{}} \mathop {{\delta {\rm T}}_{{{\text{zwd}}}} }\limits_{(k + z) \times 1} } \hfill \\ {_{{}}^{{}} \mathop {\varvec{\psi}}\limits_{3z \times 1} } \hfill \\ {\mathop {_{{}}^{{}} {\delta t}_{{}}^{{\text{G/s}}} }\limits_{m \times 1} } \hfill \\ {\mathop {_{{}}^{{}} {\varvec{N}}_{{{\text{IF}}}}^{{\text{G}}} }\limits_{p \times 1} } \hfill \\ \end{array} } \right] + {\varvec{\varepsilon}}_{{}}^{{\text{G}}}$$
(3)

where \({\varvec{\psi}}\) denotes the user position vectors, \({\varvec{A}}_{\psi }\) is the design matrix of \({\varvec{\psi}}\) that can be described as

$${\varvec{A}}_{\psi } = {\varvec{H}}_{\psi } \otimes {\varvec{E}}_{\psi }$$
(4)

where \({\varvec{H}}_{\psi } = \left[ {\begin{array}{*{20}c} {{\varvec{h}}_{1} } & {{\varvec{h}}_{2} } & \ldots & {{\varvec{h}}_{k + z} } \\ \end{array} } \right]^{{\rm T}}\), \({\varvec{E}}_{\psi } = \left[ {\begin{array}{*{20}c} {{\varvec{e}}_{1} } & {{\varvec{e}}_{2} } & \ldots & {{\varvec{e}}_{k + z} } \\ \end{array} } \right]^{{\rm T}}\), and \(\otimes\) denotes the Kronecker product. \({\varvec{h}}_{i}\) represents a row vector of \(z\) dimensions. The column elements of \({\varvec{h}}_{i}\) are all set to be one for the user stations and zero for the tracking stations. \({\varvec{e}}_{i}\) denotes a coefficient matrix for the linearized position parameters. For tracking stations, \({\varvec{e}}_{i}\) is a zero matrix, and for user stations, the row vector of \({\varvec{e}}_{i}\) can be derived as \(\left[ {\begin{array}{*{20}c} {\frac{{ - (x_{{}}^{{\text{G/s}}} - x_{r}^{0} )}}{{\rho_{0}^{{\text{G}}} }}} & {\frac{{ - (y_{{}}^{{\text{G/s}}} - y_{r}^{0} )}}{{\rho_{0}^{{\text{G}}} }}} & {\frac{{ - (z_{{}}^{{\text{G/s}}} - z_{r}^{0} )}}{{\rho_{0}^{{\text{G}}} }}} \\ \end{array} } \right]\). The triplet \((x_{{}}^{{\text{G/s}}} ,y_{{}}^{{\text{G/s}}} ,z_{{}}^{{\text{G/s}}} )\) denotes the satellite position, \((x_{r}^{0} ,y_{r}^{0} ,z_{r}^{0} )\) denotes the approximate user position, and \(\rho_{0}^{{\text{G}}}\) refers to the approximate satellite-to-receiver geometric distance.

For GLONASS satellite \(j\), we have similar observation equations as given in (1):

$$\begin{aligned} P_{{{\text{IF}},j}}^{{\text{R}}} & = \rho^{{\text{R}}} + c({\text{d}}t_{r}^{{\text{R}}} - {\text{d}}t_{j}^{{\text{R/s}}} ) + \delta_{{{\text{trop}},j}}^{{\text{R}}} + \varepsilon_{{\text{P}}}^{{\text{R}}} \\ \Phi_{{{\text{IF}},j}}^{{\text{R}}} & = \rho^{{\text{R}}} + c({\text{d}}t_{r}^{{\text{R}}} - {\text{d}}t_{j}^{{\text{R/s}}} ) + \lambda N_{{{\text{IF}},j}}^{{\text{R}}} + \delta_{{{\text{trop}},j}}^{{\text{R}}} + \varepsilon_{{\Phi }}^{{\text{R}}} \\ \end{aligned}$$
(5)

where the superscript R denotes the GLONASS system.

It is widely known that GLONASS utilizes the frequency division multiple access (FDMA) technique to distinguish signals from different constellations. The original receiver clock error item \({\text{d}}t_{r}\) will absorb the mean code hardware delay, and the residual code inter-frequency biases (IFBs) will be mixed into the GLONASS satellite clock parameters due to the various frequencies of receiver channels (Yamada et al. 2010; Shi et al. 2013; Song et al. 2014). This issue may be mitigated by establishing a more rigorous satellite clock estimation model, where differential code bias parameters are separately set up for each GLONASS satellite (or alternatively for each frequency channel number) and for each involved GLONASS tracking station (Meindl et al. 2012). Yet it will significantly increase the dimensions of the main matrix and thus raise the computational burden.

Since being mostly absorbed by the satellite clock estimates, the GLONASS code IFBs can hardly impose any direct impact on the user position parameters. Concerning the computational efficiency, we here simply introduce the so-called inter-system bias (ISB) parameter, which is composed of the system time difference and the receiver mean hardware delay difference between GPS and GLONASS (Cai and Gao 2013). Hence, the reparameterized GLONASS receiver clock error \({\text{d}}t_{r}^{{\text{R}}}\) can be expressed as

$${\text{d}}t_{r}^{{\text{R}}} = {\text{d}}t_{r}^{{\text{G}}} + {\text{d}}t_{{{\text{ISB,}}r}} = {\text{d}}t_{r}^{{\text{G}}} + ({\text{d}}t_{{{\text{SYS}}}} + M_{r}^{{\text{R}}} - D_{r}^{{\text{G}}} )$$
(6)

where \({\text{d}}t_{r}^{{\text{G}}}\) is the reparameterized GPS receiver clock error; \({\text{d}}t_{{{\text{ISB,}}r}}\) and \({\text{d}}t_{{{\text{SYS}}}}\), respectively, denote the ISB parameter and the time difference between the GPS and GLONASS systems; \(D_{r}^{{\text{G}}}\) is the hardware delay contained in GPS code observables; \(M_{r}^{{\text{R}}}\) represents the mean hardware delay pertaining to GLONASS code observables.

Assuming that there are \(k\) tracking stations contributing to the solution and the number of all visible GLONASS satellites is \(q\), the linearized GPS/GLONASS observation matrix can be derived as follows:

$$\left[ {\begin{array}{*{20}c} {\mathop {\tilde{{P}}_{{{\text{IF}}}}^{{\text{G}}} (t)}\limits_{p \times 1} } \\ {\mathop {\tilde{{\Phi }}_{{{\text{IF}}}}^{{\text{G}}} (t)}\limits_{p \times 1} } \\ {\mathop {\tilde{{P}}_{{{\text{IF}}}}^{{\text{R}}} (t)}\limits_{q \times 1} } \\ {\mathop {\tilde{{\Phi }}_{{{\text{IF}}}}^{{\text{R}}} (t)}\limits_{q \times 1} } \\ \end{array} } \right] = \left[ {\begin{array}{*{20}c} {\mathop {{\varvec{A}}^{{\text{G}}} }\limits_{2p \times (k + z - 1)} } & {\mathop {{\varvec{O}}_{{{\text{ISB}}}} }\limits_{2p \times (k + z)} } & {\mathop {{\varvec{A}}_{{{\text{zwd}}}}^{{\text{G}}} }\limits_{2p \times (k + z)} } & {\mathop {{\varvec{A}}_{\psi }^{{\text{G}}} }\limits_{2p \times 3z} } & {\mathop {{\varvec{A}}^{{\text{G/s}}} }\limits_{2p \times m} } & {\mathop {\varvec{O}}\limits_{2p \times n} } & {\mathop {{\varvec{A}}_{N}^{{\text{G}}} }\limits_{2p \times p} } & {\mathop {\varvec{O}}\limits_{2p \times q} } \\ {\mathop {{\varvec{A}}^{{\text{R}}} }\limits_{2q \times (k + z - 1)} } & {\mathop {{\varvec{A}}_{{{\text{ISB}}}} }\limits_{2q \times (k + z)} } & {\mathop {{\varvec{A}}_{{{\text{zwd}}}}^{{\text{R}}} }\limits_{2q \times (k + z)} } & {\mathop {{\varvec{A}}_{\psi }^{{\text{R}}} }\limits_{2q \times 3z} } & {\mathop {\varvec{O}}\limits_{2q \times m} } & {\mathop {{\varvec{A}}^{{\text{R/s}}} }\limits_{2q \times n} } & {\mathop {\varvec{O}}\limits_{2q \times p} } & {\mathop {{\varvec{A}}_{N}^{{\text{R}}} }\limits_{2q \times q} } \\ \end{array} } \right]\left[ {\begin{array}{*{20}c} {\mathop {{\delta t}^{{\text{G}}} }\limits_{(k + z - 1) \times 1} } \\ {\mathop {{\delta t}_{{{\text{ISB}}}} }\limits_{(k + z) \times 1} } \\ {\mathop {{\delta {\rm T}}_{{{\text{zwd}}}} }\limits_{(k + z) \times 1} } \\ {\mathop {\varvec{\psi}}\limits_{3z \times 1} } \\ {\mathop {{\delta t}^{{\text{G/s}}} }\limits_{m \times 1} } \\ {\mathop {{\delta t}^{{\text{R/s}}} }\limits_{n \times 1} } \\ {\mathop {{\varvec{N}}_{{{\text{IF}}}}^{{\text{G}}} }\limits_{p \times 1} } \\ {\mathop {{\varvec{N}}_{{{\text{IF}}}}^{{\text{R}}} }\limits_{q \times 1} } \\ \end{array} } \right]{ + }\left[ {\begin{array}{*{20}c} {{\varvec{\varepsilon}}^{{\text{G}}} } \\ {{\varvec{\varepsilon}}^{{\text{R}}} } \\ \end{array} } \right]$$
(7)

where \({\delta t}_{{{\text{ISB}}}}^{{}}\) denotes the ISB parameter vector; \({\varvec{O}}\) denotes zero matrix. For the denotations of the other parameters, readers can refer to (2), (3), and (5).

Based on (7), the user coordinates can be estimated simultaneously with the GPS and GLONASS clock offsets. Since the time interval between neighboring epochs is usually short, the variation of the ISB parameters is considered fairly stable during that period. As such, its stochastic behavior can also be treated as a process of a random walk. In the static mode, the user coordinates are viewed as constants. In the kinematic mode, it is recommended that the a priori standard deviation (STD) of user coordinates be set to a relatively large value (e.g., 100 m) to allow for possible high uncertainty of user kinematics.

Performance tests

In this section, the feasibility, accuracy, and efficiency of RUP are examined for different situations. Given the limited availability of ultra-rapid GNSS orbit products, only GPS and GLONASS observations are used in the following tests.

Feasibility analysis with a limited and variable number of remote IGS stations

More supporting IGS stations tend to enhance the accuracy and reliability of RUP. However, the operating efficiency at the user should always be borne in mind for time-critical applications. Here, we conservatively restrict the number of auxiliary IGS stations to be within five to avoid the excessive burden of data transmission and computation. It is not uncommon that real-time GNSS data streams may be occasionally interrupted for some of the IGS stations, e.g., communication failure or power outage. For this reason, the number of auxiliary stations is designed to be variable. Additionally, the IGS stations are selected with such a criterion that the minimum distance to the user station(s) should be no less than 1000 km in consideration of the uneven geographical distribution of IGS multi-GNSS network so far. This could also make RUP complementary to the differential RTK/NRTK techniques, for which the solutions with long baselines (e.g., over 1000 km) are usually problematic.

As illustrated in Fig. 1, seven IGS multi-GNSS stations in the Asian Pacific region are selected to evaluate the feasibility of RUP. All the stations can provide 1-Hz real-time data with at least GPS/GLONASS measurements. The high-rate datasets covering 1 week from July 1 to 7 (DOY 182‒188), 2018, are used to simulate the observation data streams, which in practice can be retrieved in real time through an NTRIP client such as BNC (Weber et al. 2016). Two terrestrial stations, JFNG and CCJ2, act as user stations, while one or more of the other IGS stations may be accessed on demand. The distances between the user and auxiliary IGS stations are, respectively, listed in Table 1.

Fig. 1
figure 1

Distribution of the user stations (pentagrams) and the auxiliary IGS multi-GNSS stations (squares) used in the feasibility tests of RUP

Table 1 Distances between the user and auxiliary IGS multi-GNSS stations (unit km)

To make the simulation more realistic, the EKF is set to proceed in a forward direction only, without pre-cleaning of raw data or any smoothing process. The user coordinates are estimated epoch-by-epoch with a process noise of 100 m to fully demonstrate the inherent precision of RUP solutions in simulated kinematic mode. Regarding the real-time orbit information, we use the predicted part of the ultra-rapid orbit products that are updated every 3 h by the GFZ analysis center. It is worth mentioning that the real-time orbit corrections offered by most of the RTS ACs are generated directly from the ultra-rapid orbits. It has been verified that they are numerically compatible and have the same level of accuracy (Hadas and Bosy 2015; Elsobeiey and Al-Harbi 2016; El-Mowafy et al. 2017; Nie et al. 2018). For all situations, GPS-only and GPS/GLONASS combined modes are both examined and, for brevity, denoted as “G” and “G/R,” respectively.

Figure 2 shows the 3-D error series of RUP assisted by different auxiliary IGS station(s) for station JFNG and CCJ2 on DOY 182, 2018. The results indicate that even if only one auxiliary IGS station remains, the RUP is still feasible and can retain the accuracy of a few centimeters. The statistical distribution of position errors for station JFNG is illustrated in Fig. 3. It is apparent that more auxiliary stations can help improve RUP accuracy, whereas the improvement seems to be very marginal when the number of auxiliary stations is greater than three. Numerical statistics of RUP errors are further carried out for station JFNG, in terms of mean, STD, and root-mean-square (RMS) values, as listed in Table 2. Results show that the improvement of positioning accuracy is mainly in the east and up components when one or two more IGS stations are further included. Nevertheless, with more than three IGS stations, the accuracy improvement is only around 1–2 mm.

Fig. 2
figure 2

Position error series of GPS/GLONASS combined RUP for station JFNG (left) and CCJ2 (right) with varying auxiliary stations on DOY 182, 2018

Fig. 3
figure 3

Statistical distribution of RUP errors for station JFNG in the north, east, and up components with varying auxiliary stations on DOY 182, 2018

Table 2 Numerical statistics of RUP errors for station JFNG on DOY 182, 2018 (unit cm)

Theoretically, the redundancy of RUP observation equations is dependent on the number of satellites in common view between the user and auxiliary IGS stations. This implies the distances between them are not unlimited. To further investigate the relations between the positioning accuracy and the station distances, we process all the possible RUP combinations for station JFNG and CCJ2 over 1 week. For each test combination, we do not assign a specific reference clock in advance. Instead, the receiver clock of each auxiliary IGS station in the combination will, respectively, act as a reference clock, without loss of generality. The RMS errors and their corresponding average interstation distances are shown in Fig. 4.

Fig. 4
figure 4

Variation of RMS errors with the growth of average distances between the user (JFNG and CCJ2) and auxiliary IGS stations. The statistics are based on 1 week of GPS/GLONASS combined RUP solutions during DOY 182–188, 2018

Figure 4 shows that the RMS errors generally increase with the growth of the average interstation distance. Note that when the number of auxiliary stations is more than three, the positioning accuracy is less impacted by the station distances, particularly in the horizontal components. With one or two auxiliary IGS stations located 3000–5000 km away from the users, the horizontal accuracy can be obtained within 0.2 m, while the vertical one does not exceed 0.3 m. If the average station distance is confined within about 3000 km, an accuracy of better than 15 cm in both horizontal and vertical components can be expected for all cases. Typically, the average RMS errors of GPS/GLONASS combined RUP with three auxiliary stations are 1.7, 2.0, and 5.4 cm in the north, east, and up components, respectively, with the average interstation distances ranging from 2008.1 to 2953.2 km.

Performance evaluation with high-rate GNSS observations

We reprocess the 1-Hz GPS/GLONASS data of station JFNG with RUP in simulated real-time kinematic mode and in parallel with PPP. To make a better compromise between accuracy and efficiency, we here select three auxiliary IGS stations, namely CUSV (Thailand), LHAZ (China), and STK2 (Japan). All of the RUP and PPP processing is performed with strictly forward EKF using the ultra-rapid orbits, except that the final daily clock products, instead of the less accurate real-time clock corrections, are used for PPP. Specifically, the GPS-only PPP cases utilize the IGS final 30-s interval clocks (“IGS CLK30s”). Since the IGS has not yet included GLONASS clocks with its final combination products, the 30-s interval clocks from GFZ (“GFZ CLK30”) and the 5-s interval clocks from CODE (“COD CLK05s”) are, respectively, applied to the GPS/GLONASS combined PPP cases.

Figure 5 (left) shows the 12-h position error series of station JFNG for different RUP and PPP cases. Generally, the horizontal accuracy of better than 5 cm and vertical accuracy of better than 10 cm can be achieved for all the cases. The RUP accuracy is comparable to that of post-processed PPP, particularly in the horizontal components. When looking into the details of a 10-min period, as indicated in Fig. 5 (right), however, clear discrepancies can be observed for the five cases. The position error series of PPP using 30-s clock products demonstrate higher epoch-wise volatility than other cases. By contrast, moderate oscillations of position errors are observed in both RUP cases, whose results are also highly consistent with those of PPP using the “COD CLK05s” products.

Fig. 5
figure 5

Comparison between RUP and PPP error series of station JFNG with 1 Hz observations on DOY 182, 2018. Left: a continuous 12-h period during 0:00–12:00 (GPST). Right: a zoom-in view of the 10-min period during 11:00–11:10 (GPST)

Figure 6 (left) exemplarily presents the phase residuals of all the five cases. Clearly, the phase residuals of RUP are significantly smaller than those of PPP for most of the epochs, even compared to PPP using “COD CLK05s” products. More distinctive differences can be further observed in the residual series of G05 and R03, as shown in Fig. 6 (right). Figure 7 shows the STD series of position errors that are calculated minute-by-minute from 2:00 to 12:00 (GPST). One can see that the precision of RUP represented by the STDs is distinctly higher than that of PPP using 30-s clock products and highly comparable to that of PPP using 5-s clock products. In particular, the GPS/GLONASS combined RUP outperforms all the other cases, with an average STD of 3.2, 2.9, and 7.4 mm in the north, east, and up components, respectively.

Fig. 6
figure 6

Comparison between RUP and PPP phase residuals of station JFNG with 1 Hz observations on DOY 182, 2018. Left: a continuous 12-h period during 0:00–12:00 (GPST). Right: a zoom-in view of 10-min period during 11:00–11:10 (GPST)

Fig. 7
figure 7

Minute-by-minute STDs of RUP and PPP errors of station JFNG with 1 Hz observations during 2:00–12:00 (GPST) on DOY 182, 2018

Pros and cons of incorporating more GNSS observations

Based on 1-week (DOY 182–188, 2018) observations of station JFNG and CCJ2, we calculate the RMS errors for all the RUP solutions. As shown in Fig. 8, the horizontal accuracy is noticeably improved when GLONASS data are further incorporated. Note that the accuracy improvement in the east component is not as much as that in the north component, especially for the cases with less than three auxiliary IGS stations. This may be attributed to the lower redundancy of GLONASS observations and the simplified modeling of GLONASS IFBs, resulting in less accurate GLONASS ambiguity solutions.

Fig. 8
figure 8

Scatter plots of RMS errors in the horizontal components for both GPS-only (left) and GPS/GLONASS combined (right) modes with different auxiliary IGS stations. The statistics are based on 1-week (DOY 182–188, 2018) RUP solutions of the user station JFNG and CCJ2

With the assistance of three IGS stations (CUSV, LHAZ, and STK2), a 24-h dataset of JFNG is processed by RUP at 1-s sampling rate in simulated kinematic mode. The EKF is reinitiated every 4 h, and the position error series for both GPS-only and GPS/GLONASS combined RUP solutions are shown in Fig. 9. When further incorporating GLONASS observations, significant improvements in position accuracy and reductions in convergence time can be observed for most of the sessions. According to the statistics over 1 week (Fig. 10), the average convergence time has been reduced by 56.9% (from 41.9 to 18.1 min) with the addition of GLONASS, and the 3-D positioning accuracy has been improved by 31.8% (from 6.2 to 4.3 cm). Unless otherwise indicated, the term “convergence” in this study is referred to as the situation that the horizontal RMS is less than 5 cm and the 3-D RMS is less than 10 cm.

Fig. 9
figure 9

Comparison between GPS-only and GPS/GLONASS combined RUP solutions at 1-s sampling rate. The EKF is reinitiated every 4 h for a 24-h dataset at station JFNG on DOY 182, 2018

Fig. 10
figure 10

Statistics of 3-D RMS errors and convergence time for 1 Hz RUP with the assistance of three remote IGS stations (CUSV, LHAZ, and STK2) during DOY 182–188, 2018

The variations of the average processing time per epoch are shown in Fig. 11. The evaluation is carried out in the Matlab R2016b environment operating on a desktop personal computer with a 2.90-GHz Intel Core processor. As can be seen, the latency of each processing unit increases almost linearly with the growth of auxiliary IGS stations, especially when further including GLONASS observations. The minimum and maximum processing latencies are, respectively, 0.21 (with one IGS station) and 0.38 s (with five IGS stations) for the GPS-only solutions, which have increased to 0.33 and 0.63 s for the GPS/GLONASS combined solutions. Concerning the time-critical applications, more discretion must be exercised in determining the number of IGS stations employed in RUP, as well as whether more GNSS observations should be incorporated, to maintain an appropriate balance between accuracy, reliability, and efficiency.

Fig. 11
figure 11

Variations of the average processing time per epoch for GPS-only and GPS/GLONASS combined RUP with different auxiliary IGS stations

Application to the 2016 Mw 7.8 Kaikoura earthquake

GNSS seismology has been extensively recognized as a valuable and effective tool in earthquake monitoring, tsunami early warning, and seismic hazard mitigation. In this section, we attempt to apply RUP to the rapid determination of coseismic displacements and waveforms in a major earthquake situation.

GNSS data and auxiliary IGS stations

The M7.8 Kaikoura earthquake struck the northeastern South Island, New Zealand, on November 13, 2016, at 11:02:56 (UTC). The earthquake was successfully captured by the GeoNet (https://www.geonet.org.nz/). Based on the GeoNet data provided by the GNS Science, we here only analyze those stations with 1 Hz GPS/GLONASS data available during the earthquake. The 12 monitoring stations and the epicenter are illustrated in Fig. 12. Three remote IGS multi-GNSS stations are employed by RUP, namely PARK (Australia), PTVL (Vanuatu), and FTNA (French Polynesia), which are 2409.9, 2786.1, and 3228.6 km away from the epicenter, respectively, as shown in the right bottom of Fig. 12.

Fig. 12
figure 12

Distribution of 12 GPS/GLONASS monitoring stations (green dot) from GeoNet and the epicenter (pentagram) of the 2016 Kaikoura earthquake. Right bottom: the three auxiliary IGS stations (red triangle) and their location relative to the epicenter (pentagram)

Determination of coseismic displacements and waveforms

The 1-Hz GPS/GLONASS data are, respectively, processed with RUP in simulated real time and with PPP in post-processing mode for comparison. Figure 13 shows the seismic displacements at station LKTA (66.4 km away from the epicenter). All the RUP and PPP results are aligned to the epoch 11:02:00 (UTC) for clarity. The displacements derived from the five processing strategies generally match well. It is obvious that the waveforms of the RUP solutions bear a high resemblance to that of the PPP solution using 5-s clock products. Not unexpectedly, both the GPS-only and GPS/GLONASS combined PPP solutions using 30-s clock products perform much worse than the RUP ones, showing large bias fluctuations in all three components.

Fig. 13
figure 13

Seismic displacements at station LKTA (66.4 km away from the epicenter). The results are aligned to the epoch 11:02:00 (UTC) for comparison

We calculate the displacement differences between RUP and PPP using 5-s clock products for all the monitoring stations. For the GPS/GLONASS combined mode, the average RMS values of the differences are 5.8, 4.1, and 7.3 mm in the north, east, and up components, respectively. Figure 14 illustrates the coseismic displacements of nine monitoring stations whose 3-D deformation is less than 1 m during the earthquake. For clarity, only the results of GPS/GLONASS combined RUP and post-processed PPP using 5-s clock products are presented. Generally, RUP and PPP solutions show good agreement in determining the seismic waveforms. It is worth noting that, for station BLUF and WARK, which are located 569.6 and 714.7 km away from the epicenter, respectively, the displacement waveforms can also be precisely captured by RUP as well as by post-processed PPP, though their peak displacements are only a few centimeters.

Fig. 14
figure 14

Coseismic displacements of the nine monitoring stations with 3-D deformation less than 1 m during a period of 8 min before and after the shaking

Figure 15 (top) shows the 3-D displacements of three stations (KAIK, CMBL, and WITH) with peak amplitudes as large as 1.8–4.0 m. According to the statistical analysis over the shaking period, the average RMS of the displacement differences between RUP and post-processed PPP are 4.3, 7.2, and 12.7 mm in the north, east, and up components, respectively. Figure 15 (bottom) illustrates the velocity variations of the above three stations after 11:02:00 (UTC). Overall, the average RMS values of velocity differences between RUP and post-processed PPP in the north, east, and up components are 2.8, 2.6, and 4.9 mm/s, respectively.

Fig. 15
figure 15

Coseismic displacements (top) and velocity waveforms (bottom) of the three monitoring stations with peak amplitude around 2–4 m

Potential to facilitate real-time online GNSS processing services

Nowadays, many online GNSS processing services are available through the Internet, allowing users to achieve high-precision positioning without having to deal with sophisticated software or being skilled in GNSS data processing. Some of these services, such as AUSPOS, SCOUT, and OPUS, adopt relative positioning techniques, where several nearby IGS (or local CORS) stations are usually utilized. However, when the reference stations are too far away in the case of long baselines, the differential solutions can fail or have a higher chance of being of poor quality. Many other services like CSRS-PPP, APPS, GAPS, and magicGNSS are based on PPP. For online RTPPP service, it needs to be fed with real-time satellite clock corrections, of which the availability and quality are critical to ensure continuous and reasonable solutions.

Alternatively, the presented approach may offer a third option for online GNSS processing services. Compared to current online services, its potential benefits are threefold. First, reduced waiting time and more robust performance may be expected. Since the positioning process of RUP is performed simultaneously with the satellite clock estimation, it eliminates the need for awaiting the generation and transmission of satellite clock products, and more importantly, it is completely free from the interruption or quality degradation of external satellite clock corrections. Second, the interpolation of satellite clock corrections is no longer needed as the satellite clock offsets are estimated at a rate equal to that of the observations. This feature is especially advantageous for high-rate (e.g., 1 Hz or more) real-time positioning. Third, the user position and satellite clock parameters are mutually independent in the function model of RUP. This largely reduces the impact of unmodeled errors in the satellite clock estimates on positioning accuracy, as verified in the “Performance tests” section.

From an application point of view, the requests submitted by users may be promptly responded with RUP by simply incorporating a few IGS stations around the users, as elaborated in previous sections. Nevertheless, this does not necessarily lead to a guaranteed global service as the spatial coverage of the IGS multi-GNSS network is still limited in certain regions around the world. Hereafter, we will focus on the performance of RUP with the support of a sparse global network, regardless of the user location.

As shown in Fig. 16, a network with 30 multi-GNSS tracking stations is selected to realize global RUP. For the server, once receiving the GNSS data from users, the RUP module will respond by expanding its observation equations and setting additional unknown parameters associated with the user stations. In the same computational environment as described in previous tests, the average processing time per epoch increased to 2.17 s for the GPS-only mode and 3.61 s for the GPS/GLONASS combined mode. Since the process avoids the time-consuming combination of real-time satellite clock products, such latency is deemed acceptable and could be further reduced with advanced high-performance servers.

Fig. 16
figure 16

Distribution of the selected IGS multi-GNSS stations supporting global RUP for real-time online GNSS processing services

Figure 17 (top) shows the 24-h RUP errors of station MOBS (37.8294°S, 144.9753°E), one of the active IGS RTS stations capable of providing 1 Hz real-time GPS/GLONASS data streams. The RMS errors are 1.3, 1.8, and 2.8 cm for the GPS-only mode in the north, east, and up components, respectively, and 0.9, 1.4, and 2.7 cm for the GPS/GLONASS combined mode. In both cases, over 96% of the errors in the horizontal components and 92% in the vertical component are within \(\pm \;5\) cm. Figure 17 (bottom) shows the real-time ZTD estimates at station MOBS. Compared with the IGS final troposphere products, the RMS values of the ZTD biases are 4.6 mm for the GPS-only mode and 3.9 mm for the GPS/GLONASS combined mode, respectively.

Fig. 17
figure 17

Position errors (top) and ZTD biases (bottom) of station MOBS derived from global RUP on DOY 182, 2018

In addition, the real-time satellite clock estimates may be offered as a by-product of online services. For accuracy assessment, we calculate the differences between the clock estimates and the final “COD CLK05s” products. As shown in Fig. 18 (top), the biases of GPS clock estimates mostly vary within a range of about \(\pm \,0.2\) ns after convergence. There appears to be no significant discrepancy in clock accuracy between different GPS satellites, except for PRN18, holding a relatively large drift in the estimates. The degraded performance may be linked to the fact that PRN18 had just experienced a constellation switch from SVN054 (BLOCK-IIR-A) to SVN034 (BLOCK-IIA) on January 24, 2018. Also, it was the only on-orbit BLOCK-IIA constellation with a rubidium atomic standard during the period this experiment covered. Figure 18 (bottom) shows that the GLONASS clock errors oscillate largely for most epochs and vary within a range of about \(\pm \,0.5\) ns after convergence. Such degradation may be associated with the adverse impacts of GLONASS receiver code IFBs on the clock estimation.

Fig. 18
figure 18

Differences between the GPS (top) and GLONASS (bottom) clock estimates derived from global RUP and the final “COD CLK05s” products on DOY 182, 2018

The average RMS values of the GPS and GLONASS clock biases over 1 week (DOY 182‒188, 2018) are calculated against the final “COD CLK05s” products. As shown in Fig. 19, the accuracy of the satellite clock estimates is mostly better than 0.15 ns for GPS, with an average RMS of 0.10 ns, whereas it is lower and more diverse for GLONASS, with an average RMS of 0.28 ns. It should also be mentioned that the errors in the reference clock products are not considered in the accuracy assessment.

Fig. 19
figure 19

Average RMS of the estimated GPS (top) and GLONASS (bottom) satellite clock errors during DOY 182‒188, 2018. The final “COD CLK05s” products are taken as reference values

Concluding remarks

Taking advantage of the fast-growing IGS multi-GNSS network, we introduced an approach of real-time undifferenced precise positioning (RUP), which may serve as a viable alternative to real-time GNSS users. Different from traditional RTPPP, the new approach is not subject to the interruption or quality degradation of external satellite clock corrections. Employing only a few remote IGS stations around the users, RUP is more flexible and can potentially reduce the response time without the need for awaiting the dedicated real-time satellite clock products or the complex data processing of large networks. Compared to differential RTK/NRTK, RUP can extend the distance between the user and auxiliary stations to a few thousands of kilometers, with centimeter-level positioning accuracy, which is more applicable over vast areas.

With the assistance of three IGS stations around 2000–3000 km away, RUP can typically achieve an accuracy of about 2 cm in the horizontal and 5 cm in the vertical. It has been validated that centimeter-level RUP is feasible with a single auxiliary IGS station (1359.7 km away from the user), which also implies that occasional interruption of real-time data streams from some of the auxiliary stations does not necessarily prevent the continuous implementation of the approach. It should be noted that when the number of auxiliary stations is greater than three, the accuracy improvement of RUP is found marginal. In dealing with high-rate (1 Hz) GPS/GLONASS observations, the performance of RUP is comparable to that of PPP using 5-s satellite clock products and highlights its superior short-term precision, which can be attributed to the mutual independence of the user position and satellite clock parameters in the unified model, neutralizing largely the adverse impacts of unmodeled errors in the satellite clock estimates. Incorporating more GLONASS observations can significantly decrease the convergence time and improve the positioning accuracy, whereas the resulting reduction in operational efficiency is also noticeable.

The approach has been applied to the 2016 Mw 7.8 Kaikoura earthquake with three auxiliary IGS multi-GNSS stations over 2400 km away from the epicenter. In addition to its independence on external real-time clock corrections, RUP is not only insusceptible to the earthquake-induced disturbance on reference stations but can also depict the coseismic displacements and waveforms in the global reference frame (defined by the ultra-rapid orbits). The RUP-derived results generally agree well with those of post-processed PPP using CODE final 5-s clock products. The average RMS values of their differences in the north, east, and up components are, respectively, 5.8, 4.1, and 7.3 mm for displacement and 2.8, 2.6, and 4.9 mm/s for velocity.

The potential of RUP in facilitating real-time online GNSS services is explored with the support of a sparse global network. The results suggest that the real-time positioning accuracy of better than 5 cm, along with the ZTD retrieving accuracy of a few millimeters, can be expected. The intermediate satellite clock estimates can be offered in real time with an accuracy of 0.10 ns for GPS and 0.28 ns for GLONASS, respectively. Note that when dealing with massive user requests as a routine task, the challenge associated with the computational capacity at the server shall arise. In prospect, this limitation may be overcome through the development of the distributed computing technology and the cloud GNSS platforms as well (Boomkamp 2010; Li et al. 2015).

Due to the current lack of real-time orbit products, emerging GNSSs such as Galileo and BeiDou are not included in this study. We are currently exploring the possibility of introducing additional satellite position parameters to the model using the broadcast ephemeris. Besides using the data transmission between the user and auxiliary IGS stations via the BeiDou short-message communication (BD Standard 2015; Li et al. 2019), it will also be investigated to better support for those applications where wireless Internet access may not be available, such as on the ocean.