## 1 Introduction  
The exploitation of Global Navigation Satellite System (GNSS) observations for monitoring the troposphere in support of meteorology has been proposed by [1]. The initial parameter of interest was the Zenith Total Delay (ZTD), which represents a GNSS signal path delay due to transecting the neutral atmosphere in a vertical column above the station. The ZTD depends mainly on atmospheric pressure and partial water vapor pressure [2]. First computation of ground-based GNSS ZTDs in near-real time (NRT) were demonstrated in 2000 [3, 4], i.e., shortly after establishing GNSS hourly data flow in 1999 and after providing precise orbits in ultra-rapid mode by the International GNSS Service (IGS, [[http://www.igs.org](http://www.igs.org)]([http://www.igs.org](http://www.igs.org))) in 2000 [5]. The COST Action 716 [6] then played an important role in developing and evaluating methods of GNSS NRT troposphere monitoring and defining the standard format (COST-716) for the product dissemination. The operational production of GNSS ZTDs was organized within the COST-716 Demonstration Project [7], and it has never been closed because its coordination was handed over to the newly established EUMETNET EIG GNSS Water Vapour Programme (E-GVAP, [[http://egvap.dmi.dk](http://egvap.dmi.dk)]([http://egvap.dmi.dk](http://egvap.dmi.dk))) in 2004. Operational assimilations of ZTDs from E-GVAPinto mesoscale Numerical Weather Models (NWM) for weather forecasting have been performed by Meteo-France [8; 9] and UK Met Office [10] since 2007. Both meteorological agencies started also an assimilation of the first E-Gvap global NRT ZTD product [11]. Until present days, the standard GNSS ZTD monitoring in E-Gvap is performed in hourly update rate with a maximum product delay of 45 min with respect to the last GNSS processed observation. These requirements are a prerequisite of the ZTD assimilation performed usually with a 3-6 h time resolution. Until now, a majority of E-Gvap analysis centers (ACs) uses a double-difference observation processing in a network solution. This strategy eliminates clock errors at GNSS receiver and satellite and was compulsory while public products were not available in NRT. The situation has changed in 2013, when the IGS introduced the Real-Time Service (RTS, [[http://rts.iggs.org](http://rts.iggs.org)]([http://rts.iggs.org](http://rts.iggs.org))) providing GPS and GLONASS orbit and clock corrections by combining contributions from several IGS real-time analysis centers [12]. The IGS RTS aims at supporting real-time (RT) analyses with the Precise Point Positioning (PPP) method [13]. The PPP is based on original observations or their linear combination without differencing between receivers or satellites. Though German Research Centre for Geosciences (GFZ) has provided a NRT PPP ZTD product [14; 15] since 2001, it was possible only thanks to their two-step processing approach consisting of (1) a global NRT solution for determining consistent satellite clock and orbit products and (2) a distributed PPP processing for ZTD estimated at each station individually. With the availability of global real-time data flow, software and standards specified for precise product dissemination, the PPP is becoming more popular for the troposphere monitoring. Compared to the traditional approach in E-Gvap dominated by the double-difference network processing, the PPP offers several advantages: (a) an easy production in real-time or NRT fashion, (b) flexible use of central or distributed processing scheme including a receiver built-in solution, (c) an estimation of tropospheric parameters in the absolute sense with a high spatio-temporal resolution, and (d) an optimal support of all satellite constellations and new signals including multiple frequencies; all profiting from a highly efficient and autonomous processing approach. The price for mentioned advantages is however paid by several disadvantages. Compared to the strategy using double differences, all observation models need to be carefully applied to reach the best accuracy.