Benefits of Using Galileo for Real-Time GNSS Meteorology

Remote sensing of water vapor using Global Navigation Satellite Systems (GNSS) is a well-established tool for weather and climate monitoring. The current challenges of GNSS meteorology are real-time performance and the inclusion of emerging GNSS, such as Galileo. We demonstrate that real-time GPS-only, Galileo-only, and GPS+Galileo solutions are consistent among each other. However, our results show that the Galileo-only solutions tend to underestimate Zenith Total Delay (ZTD) with respect to GPS. The Galileo-only real-time ZTD is less accurate as the one from GPS. The combination of both GNSS leads to a superior product. The daily solution availability increases by up to 50%, and the overall gain is 0.7% over the entire year. The accuracy improves by 3.7% to 8.5% and uncertainty is reduced by a factor of 1.5–2. A combined GPS and Galileo solution suppresses artifacts in a real-time ZTD product which otherwise would be attributed to high-frequency orbital effects.


I. INTRODUCTION
R EMOTE sensing of the troposphere using Global Navigation Satellite Systems (GNSS), called GNSS meteorology, is a well-established tool for weather and climate monitoring [1]. The standard product of GNSS meteorology is the zenith total delay (ZTD), which is operationally assimilated into numerical weather models by meteorological agencies [2]. Horizontal gradients and slant total delays are still considered as advanced tropospheric products, for which the assimilation has been performed only in a few case studies [3].
The advantages of using GNSS rather than the traditional sensors are continuous all-weather operation and very high temporal and spatial resolution. Using ZTD together with pressure and temperature determined from in situ measurements or a numerical weather model, integrated water vapor (IWV) content can be quantified with a similar accuracy as classical meteorological sensors, that is, water vapor radiometers [4]. The drawback of GNSS is that the most accurate results are obtained in the postprocessing mode, for which products are available with a significant latency due to batch processing of the GNSS data. The state-of-the-art processing regime for assimilation purposes is the near real-time (NRT), in which the latency varies from 15 to 60 min. Operational NRT ZTD products are provided, for example, under the EUMETNET EIG GNSS water vapour programme (E-GVAP) project (http://egvap.dmi.dk/), for over 2000 stations in Europe and hundreds of stations worldwide (mostly Australia and China). The accuracy of NRT ZTD is 3-10 mm [5], [6], which corresponds to 1-3 kg/m 2 of IWV roughly.
Currently, the following challenges for GNSS meteorology can be identified: transition from NRT to real-time, use of new GNSS signals, that is, new frequencies and constellations, and the provision of reliable advanced tropospheric products [7]. Precise processing of the GNSS data in real-time became possible since the International GNSS Service (IGS) established the Real-Time Service (RTS, http://www.igs.org/rts) in 2013 and started to deliver satellite orbit and clock corrections for GPS and GLONASS. Galileo and BeiDou are supported by one of the IGS analysis centers-Centre National d'Études Spatiales (CNES), allowing now for quad-constellation processing.
Several research groups already reported the accuracy ranging from 4 to 20 mm for ZTD from real-time GPS data processing [8]- [11]. The accuracy of real-time products, which is not as good as the one of final products, limits the accuracy of the resulting ZTD. Therefore, real-time solutions should benefit from adding more observation, for example, from other GNSS. The multi-GNSS real-time solutions are superior to the GPS-only solutions by up to 22% [12], [13], but so far they benefited only slightly from Galileo and BeiDou due to the limited number of satellites in both constellations and the lower accuracy of real-time products [14]. The latter one leads to justified downweighting of observations for GNSS other than GPS, thus further reducing the impact of new constellations [15]. A questionable improvement from GLONASS is expected, due to the low accuracy of its real-time orbits and clocks. A BeiDou-only ZTD real-time solution is still significantly worse than a GPS-only solution, but the combination of both GNSS leads to elimination of some outliers, which are present in the single-system approach [16]. Real-time Galileo-only ZTD has not been reported so far, simply due to the insufficient number of available satellites.
However, Galileo has evolved significantly over the past two years [17]. Since February 11, 2019, there are 22 operating Galileo satellites, which are supported by CNES in the RTS. An outstanding accuracy of the Galileo-only positioning, also in real-time, has already been reported [18], [19]. Galileo observations allow to compute postprocessed ZTD with a similar precision as with GPS, that is, 5.8 and 6.2 mm, respectively [20]. Adding observations from the third frequency further improves the precision by 4%. The maturity of the present Galileo constellation and the aforementioned research lead to an expectation of significant contribution of Galileo to real-time GNSS meteorology.
In this letter, a Galileo-only real-time ZTD product is presented and evaluated for the first time. Moreover, we investigate whether Galileo, with its incomplete but fully serviceable constellation, contributes to real-time GNSS meteorology and whether the combination of observations from GPS and Galileo leads to superior results when compared with a GPS-only solution.

A. Data and Products
The test period covers the entire year 2019. Observation data, recorded in RINEX 3.0x files with an observation interval of 30 s, originate from 18 IGS and 16 European Permanent Network (EPN) stations (see Fig. 1) which meet the following three requirements: they provide GPS and Galileo observations, they provide a real-time observation stream, and they are included in IGS or EPN final solutions.
The BNC v2.12 software is used to record real-time products from the multi-GNSS stream delivered by CNES (CLK93 identifier at the products.igs-ip.net caster). For IGS stations, the ZTD final products are provided by the United States Naval Observatory (USNO, the interval of ZTD product is 5 min) and the Center of Orbit Determination in Europe (CODE, 2-h interval). For the EPN stations, the ZTD final products from Bundesamt für Kartographie und Geodäsie (BKG, 1-h interval) and Warsaw University of Technology (WUT, 1-h interval) are used.

B. Processing Strategy
The processing of pseudorange P and carrier phase L dual-frequency observations from GPS and Galileo is performed in the original software [21] using the undifferenced uncombined (so-called "raw") observation model [22] of the precise point positioning (PPP) technique where s is the satellite number; c is the speed of the light; ρ s, * 0 is the geometric distance ρ s 0 between the position of the satellite s antenna phase center (X s , Y s , Z s ) and the a priori position of the receiver r antenna phase center (X r , Y r , Z r ) corrected for the satellite clock offset δt s , for satellite, receiver, and site displacement effect corrections s [23], and for the hydrostatic delay calculated as a priori zenith hydrostatic delay Z h mapped to slant directions with a hydrostatic mapping function m s h ; e is the direction vector; δ X is the position correction vector; δt r is the receiver clock offset; ISB G E is the receiver intersystem bias between GPS and Galileo; m s w is the wet mapping function; Z w is the zenith wet delay; I s is the slant ionosphere delay; and i is the number of frequency f with wavelength λ i and a corresponding ambiguity N s i . The estimated parameters are as follows: δ X r , δY r , δ Z r (static variables), δt r,G (white noise), ISB G E (static, only in GPS+Galileo processing), Z w (random walk), I s (white noise), and N s i (static). We provide three real-time solutions: GPS-only (rtG), Galileo-only (rtE), and GPS+Galileo (rtGE). L1 and L2 frequencies from GPS, and E1 and E5a from Galileo are used. We assume that the quality of real-time products for GPS and Galileo is comparable, and therefore a priori sigma of pseudorange and carrier phase observation are set to 0.30 and 0.01 m, respectively, for both GPS and Galileo. A classical elevation (e)-dependent weighting of observations (1/ sin e) and a 3 • elevation mask are applied. Troposphere a priori hydrostatic delay as well as hydrostatic and wet mapping functions are taken from forecast Vienna Mapping Functions 1 [24]. The sampling rate and parameter estimation interval are set to 60 s. Satellite orbits and clocks are fixed to information provided from the CLK93 stream. Ambiguities are estimated as float values. Phase center offsets and variations from the igs14.atx file are applied, whereas for Galileo E5a frequency they are adopted from GPS L2.

A. Availability of Real-Time Corrections, Final and Real-Time ZTD Products
The availability of a real-time solution depends on both the performance of the RTS and the reliability of the Internet connection (see Fig. 2). Due to the failure of the Internet connection, we miss to record corrections for 4.   Among real-time solutions (see Fig. 3), the lowest availability is obtained with rtE (91.3%), which we attribute to the lower number of Galileo satellites when compared with GPS and several periods of missing real-time Galileo corrections. For the majority of stations and days, rtG is slightly less available than the best final solution. Furthermore, rtE performs worse than rtG, except multiple PPP reinitialization periods, during which rtE converges faster than rtG. A combination of GPS and Galileo in rtGE occurs to be superior to rtG. Although the overall improvement is only 0.7%, in some cases the daily availability of rtGE increases with respect to rtG by up to 50%. The overall availability of rtGE is 94.8% and is close to the availability among final products (94.5%-97.3%). Individual cases when rtGE outperforms a final solution can be explained by more rigorous data screening and outlier detection in the postprocessing mode.

B. Intercomparison of Real-Time ZTD
The time series of various real-time ZTD are very consistent to each other, with correlation coefficients exceeding 0.99 for all stations. ZTD differences between real-time solutions are usually within a ±5 mm range. Larger ZTD differences, We attribute this to the missing phase center correction models for Galileo E5a frequency. The estimated standard deviations σ of ZTD are receiver/station-dependent, but among all stations σ ZTD from rtE is the largest and σ ZTD from rtGE is smaller than σ ZTD from rtG, roughly by a factor of 1.5-2 [ Fig. 4(a) and (b)]. Moreover, σ ZTD in rtE is significantly reduced since the four new Galileo satellites have been included in the real-time service.
We analyze power spectrum (PS) of ZTD from different real-time solutions [ Fig. 5(a)] and note an expected power increase with decreasing frequency. Although periodograms are similar to each other, there are a number of solution-dependent peaks among all stations, especially for subdaily periods. Wavelet coherence analysis [see Fig. 5(b)] reveals that the coherency between single-GNSS real-time ZTD drops significantly for periods shorter than 12 h. This means that there is a tendency that individual ZTD products contain high-frequency artifacts, with periods of 12 h or loss and other processing-dependent signals, which are not attributed to weather phenomena and thus would negatively impact the assimilation quality of the GNSS meteorological data.
The peaks at high frequencies are considered artificial and in general they are neglected in further analysis [25]. Orbit-related artificial signals might be expected at periods P n,m , which derive from the combination of the frequency of a satellite constellation period f S and the frequency of the Earth revolution period f E multiplied by small integers n, m, respectively [26] From differential periodograms, that is, PS differences between two real-time solutions for a test station, the peaks among all stations are extracted and stacked in Fig. 6.  All peaks in differential PS between rtE and rtG are related to P n,m . The majority of the peaks originate from Earth revolution only (n = 0), but some are due to satellite-Earth orbital resonance (n, m > 0). When a single-GNSS solution is compared with rtGE, some high-frequency peaks diminish, but most remain with a slightly smaller power magnitude. It means that the combination of GPS and Galileo reduces orbit-related artificial signals in real-time ZTD time series.

C. Evaluation of Real-Time ZTD Against Final Products
To assess the accuracy of real-time ZTD, we compare it with the final products from different analysis centers (see Fig. 7). The worst agreement is found with the official IGS product, which we attribute to an outdated processing strategy applied by USNO. The average offset ranges from −7 to +10 mm, and the standard deviation of differences varies from 4 to 11 mm. Although CODE does not provide reference products for all test stations, the agreement with real-time solutions is better, that is, offsets are reduced −4-+7 mm range, and the standard deviation exceeds 10 mm only for station FAA1 in rtE. The average standard deviations between real-time and USNO final product are 8.3, 9.3, and 8.0 mm for rtG, rtE, and rtGE, respectively. The corresponding standard deviations for comparison with CODE are 6.9, 7.6, and 6.5 mm. A very good agreement is found between real-time solutions and both final EPN solutions. Again, rtE is less accurate than the other two real-time products, and rtGE is much more precise and slightly more accurate than rtG. The average standard deviations between real-time and the BKG final product are 5.9, 7.2, and 5.4 mm for rtG, rtE, and rtGE, respectively. The corresponding numbers for comparison with WUT are 5.3, 6.6, and 5.0 mm.

IV. CONCLUSION
We demonstrate that Galileo and supporting services are already mature enough to provide a reliable information on troposphere state in real-time. A major improvement of the Galileo-only solution is noticed after February 11, 2019, since the newest four satellites are supported in the real-time service. However, the performance of the Galileo-only solution is still not as good as that the GPS-only solution in terms of continuous performance, standard deviation of estimated ZTD, and accuracy with respect to the final products from the IGS and EPN. We attribute this to the following imperfections of Galileo: fewer operational satellites than GPS (22 against 31), the entire system outage in July 2019, failures in RTS performance, and missing phase center corrections for a second Galileo frequency.
On the other hand, we prove that a combined GPS+Galileo solution can be achieved in real-time without a lot of extra effort, which leads to significantly better results than a GPS-only solution. The daily availability of a GPS+Galileo solution increases by up to 50% for individual days, that is, during poor performance of the real-time service. The overall availability increases by 0.7% (2.5 days), so the ZTD product is delivered during 94.8% of the entire year, which is comparable with the performance among final products. Processing of nearly twice as much observations in the combined solution leads to the decrease in the ZTD standard deviation by a factor of 1.5-2.0. The accuracy with respect to the final products improves by 3.7% to 8.5%. For IGS stations, the accuracy is 8.0 and 6.5 mm with respect to the USNO and CODE products, respectively. For EPN stations, the accuracy is 5.4 and 5.0 mm with respect to BKG and WUT solutions, respectively.
Finally yet importantly, the spectral analysis of real-time ZTD from the GPS-only, Galileo-only and GPS+Galileo solution reveals further advantages of using the combined solution. Whereas single-system ZTD products suffer from orbit-related artificial signals of high frequency, the combined GPS+Galileo solution suppress such effects. Thus, a combined GPS+Galileo solution is expected to be not only more available over an average day but also the solution itself will be more precise and accurate and is therefore definitely preferable to a GPS-only product when it comes to assimilation of GNSS ZTD in NRT numerical weather models.