Differential GNSS and RTK operation using RTCM streams is currently based on corrections and/or raw measurements from single or multiple reference stations. This approach to differential positioning is using 'observation space' information. The representation with the RTCM standard can be called 'Observation Space Representation' (OSR).

An alternative to the observation space approach is the so called 'sate space' approach. The principle here is to provide information on individual error sources and can be called 'State Space Representation' (SSR). For a rover position, state space information concerning precise satellite clocks, orbits, ionosphere, troposphere et cetera can be converted into observation space and used to correct the rover observables for more accurate positioning. Alternatively the state information can directly be used in the rover's processing or adjustment model.

In order to support applications following the state space approach, the purpose of BNS is to

• read GNSS clocks and orbits in a SP3-like format from an IP port. They can be produced by a real-time GNSS engine such as RTNet and should be referenced to the IGS Earth-Centered-Earth-Fixed (ECEF) reference system.
• read GNSS Broadcast Ephemeris in RINEX Navigation format from an IP port. This information can be provided in real-time by the 'BKG Ntrip Client' (BNC) program.
• convert the IGS Earth-Centered-Earth-Fixed clocks and and orbits into corrections to Broadcast Ephemeris with radial, along-track and cross-track components.
• refer the clock and orbit corretions to a specific reference system.
• upload the clock and orbit corrections as an RTCM Version 3.x stream to an NTRIP Broadcaster.
• log the Broadcast Ephemeris clock corrections as files in Clock RINEX files.
• log the Broadcast Ephemeris orbit corrections as files in SP3 files.

The procedures taken by BNS to generate clock and orbit corrections to Broadcast Ephemeris in radial, along-track and cross-track components are as follow:

• Continuously receive up-to-date Broadcast Ephemeris carrying approximate orbits and clocks for all satellites. Receive them in RINEX Version 3 Navigation file format. Read new Broadcast Ephemeris immediately whenever they become available. Tools like the 'BKG Ntrip Client' (BNC) provide this information.

Then, epoch by epoch:

• Continuously receive the best available clock and orbit estimates for all satellites in X,Y,Z Earth-Centered-Earth-Fixed IGS05 reference system. Receive them every epoch in a SP3-like format as provided by a real-time GNSS engine such as RTNet.
• Calculate X,Y,Z coordinates from Broadcast Ephemeris orbits.
• Calculate differences dX,dY,dZ between Broadcast Ephemeris and IGS05 orbits.
• Tranform these differences into radial, along-track and cross-track corrections to Broadcast Ephemeris orbits.
• Calculate corrections to Broadcast Ephemeris clocks as differences between Broadcast Ephemeris and IGS05 clocks.
• Encode Broadcast Ephemeris clock and orbit corrections in RTCM Version 3.x format.
• Upload corrections stream to NTRIP Broadcaster.

Although it is not compulsory, because BNS puts a significant load on the communication link, it is recommended that BNS, the Broadcast Ephemeris server (i.e. BNC), and the server providing orbits and clocks (i.e. RTNet) are run on the same host.

Apart from its regular window mode, BNS can be run as a background job in a 'no window' mode using processing options from a previously saved configuration.

BNS requires access to the Internet with a minimum of about 1 kbits/sec per stream depending on the number of GNSS systems. You need to make sure that the connection can sustain the required bandwidth.

It requires the clock of the host computer to be properly synchronized.

This section describes BNS's top menu bar, its processing options and its bottom menu bar.

The usual handling of BNS is that you first select severs for 'RINEX Ephemeris' and 'Clocks & Orbits'. You then select an NTRIP broadcaster for stream upload ('Broadcast Corrections') before you start the program ('Start'). Records of BNS's activities are shown in the 'Logs' canvas in the middle of the main window.

As a default, configuration files for running BNS on Unix/Linux/Mac systems are saved in directory '${HOME}/.config/BKG'. On Windows systems, they are typically saved in directory 'C:/Documents and Settings/Username/.config/BKG'. The default configuration file name is 'BNS.ini'.

The default file name 'BNS.ini' can be changed and the file contents can easily be edited. On graphical user interfaces it is possible to Drag & Drop a configuration file icon to start BNS. See annexed 'Configuration Example' for a complete set of configuration options.

The top menu bar allows to select a font for the BNS windows, save configured options or quit the program execution. It also provides access to a program documentation.

The 'File' button lets you

• select an appropriate font.
  Use smaller font size if the BNS main window extends beyond the size of your screen.
• save selected options in configuration file.
• quit the BNS program.

The 'Help' button provides access to

• help contents.
  You may keep the 'Help Contents' window open while configuring BNS.
• a 'Flow Chart' showing BNS linked to tools like BNC and a real-time GNSS engine such as RTNet.
• general information about BNS.
  Close the 'About BNS' window to continue working with BNS.

BNS comes with a help system providing online information about its functionality and usage. Short descriptions are available for any widget. Focus to the relevant widget and press Shift+F1 to request help information. A help text will appear immediately; it disappears as soon as the focus is shifted to something else. The dialogs on some operating systems may provide a "?" button that users can click; they then click the relevant widget to pop up the help text.

If you are running BNS within a protected Local Area Network (LAN), you might need to use a proxy server to access the Internet. Enter your proxy server IP and port number in case one is operated in front of BNS. If you don't know the address and port of your proxy server, check the proxy server settings in your Internet browser or ask your network administrator.

Note that IP streaming is often not allowed in a LAN. In this case you need to ask your network administrator for an appropriate modification of the local security policy or for the installation of a TCP relay to the NTRIP Casters. If these are not possible, you might need to run BNS outside your LAN on a host that has unobstructed connection to the Internet.

The following describes general settings for BNC's logfile, file handling and auto-start.

Records of BNS's activities are shown in the Log section on the bottom of the main window. These logs can be saved into a file when a valid path is specified in the 'Log (full path)' field. The message log covers the communication status between BNS and the NTRIP broadcaster as well as problems that may occur in the communication link, stream availability, stream delay, stream conversion etc. All times are given in UTC. The default value for 'Log (full path)' is an empty option field, meaning that BNS logs will not saved into a file.

When BNS is started, new files are created by default and any existing files with the same name will be overwritten. However, users might want to append existing files following a restart of BNS, a system crash or when BNS had crashed. Tick 'Append files' to continue with existing files and keep what has been recorded so far. Note that option 'Append files' affects all types of files created by BNS.

You may like to auto-start BNS at startup time in window mode with preassigned configuration options. This may be required i.e. immediately after booting your system. Tick 'Autostart' to supersede the usage of the 'Start' button. Make sure that you maintain a link to BNS for that in your Autostart directory (Windows systems) or call BNS in a script below directory /etc/init.d (Unix/Linux/Mac systems).

BNS requires GNSS Broadcast Ephemeris in RINEX Version 3 Navigation file format from an IP address and port. This information can be provided in real-time by the 'BKG Ntrip Client' (BNC) program. Note that whenever a new set of Broadcast Ephemeris becomes available, BNS needs it immediately.

The following is an example log of Broadcast Ephemeris records in RINEX Version 3 Navigation file format for satellite GPS PRN32 and GLONASS PRN04:

G32 2008 07 22 12 00 00  3.08818183839e-04  2.72848410532e-12  0.00000000000e+00
     1.10000000000e+01 -4.00312500000e+01  4.63269297026e-09  9.74027926504e-01
    -2.19419598579e-06  1.39143558918e-02  8.25151801109e-06  5.15381674576e+03
     2.16000000000e+05 -8.56816768646e-08 -3.26801342873e-02 -2.94297933578e-07
     9.68688494953e-01  2.30468750000e+02 -1.30607654294e+00 -8.26105839196e-09
    -3.62872257943e-10  1.00000000000e+00  1.48900000000e+03  0.00000000000e+00
     2.00000000000e+00  0.00000000000e+00 -2.79396772385e-09  1.10000000000e+01
     0.00000000000e+00  0.00000000000e+00
R04 2008 07 22 08 15 14  4.76110726595e-05  0.00000000000e+00  2.88600000000e+04
    -1.76267827148e+04 -4.64202880859e-01  1.86264514923e-09  0.00000000000e+00
    -1.79631489258e+04 -3.41343879700e-01 -2.79396772385e-09  6.00000000000e+00
    -4.20270556641e+03  3.50097942352e+00  0.00000000000e+00  0.00000000000e+00

Enter the IP address and port number of a Broadcast Ephemeris server like BNC to establish a persistent socket connection, see section 'Flow Chart' under 'Help' for socket communication details. If BNS runs on the same host as BNC, 127.0.0.1 should be used as the server's IP address. Make sure that this server is up and running before you start BNS.

BNS requires GNSS clocks and orbits in the IGS Earth-Centered-Earth-Fixed (ECEF) reference system in a SP3-like format referred to CoM and not containing the 2nd order relativistic effect. They can be provided by a real-time GNSS engine such as RTNet. The sampling rate should not be much greater than 10 sec. Note that otherwise in IP streaming involved tools on the NTRIP Broadcaster or client side may respond with a timeout.

Below you find an example of precise clocks and orbits coming in a SP3-like format from a real-time GNSS engine. Each epoch starts with an asterisk character followed by the time as year, month, day of month, hour, minute and second. Subsequent records provide the following set of parameters for each satellite:

• GNSS Indicator and Satellite Vehicle Pseudo Random Number
• X,Y,Z coordinates in Earth-Centered-Earth-Fixed system [km] at epoch T
• Satellite clock error [microsecond]
• 2nd order relativistic effect [microsecond]
• DX,DY,DZ [m] in Earth-Centered-Earth-Fixed system for translation CoM->APC
• Differential Code Bias P1C1 [m]
• Differential Code Bias P1P2 [m]
• Time increment dT [second]
• X,Y,Z coordinates in Earth-Centered-Earth-Fixed system [km] at epoch T+dT

*  2009 12  7 13 11  30.00000000
PG02  22354.452213 -13767.325289   1772.434231    228.750524     -0.001932  -0.522   0.321  -0.041   0.000   0.000  60.0  22377.342363 -13753.550786   1583.545731
PG03 -11102.768914  16968.159551  16622.454893    518.437937      0.001957   1.012  -1.908  -1.508   0.000   0.000  60.0 -11129.949019  16837.402637  16736.552194
PG04  24167.186374  -3628.894484 -11005.210034     19.658309     -0.001319  -2.103   0.034   0.921   0.000   0.000  60.0  24101.853298  -3576.088512 -11164.914026
PG05  14447.045279  -8140.619149  20744.274083     -7.120008     -0.004342  -0.381   0.215  -0.547   0.000   0.000  60.0  14578.754091  -8053.151311  20686.754446
...
...

BNS is listening at an IP port for incoming GNSS clocks and orbits in a SP3-like format. Enter the respective IP port number to setup a server socket for incoming data, see section 'Flow Chart' under 'Help' for socket communication details. Make sure that the software providing clocks and orbits is up and running before you start BNS.

Specify the full path to a file where received clocks and orbits from a real-time engine will be logged. Beware that the size of this file can rapidly increase. Default is an empty option field meaning that logging is disabled.

BNS can upload the resulting stream(s) of clock and orbit corrections to Broadcast Ephemeris to an NTRIP Broadcaster. Both EUREF and IGS operate an NTRIP broadcaster at http://www.euref-ip.net/home and http://www.igs-ip.net/home which can be used for stream upload. The stream's format is RTCM Version 3.x.

BNS allows to configure two Broadcast Corrections streams refering do different reference systems for upload to different NTRIP broadcasters. You may use this functionality for parallel support of a backup NTRIP broadcaster or for simultaneous support of two reference systems.

When using clocks from Broadcast Ephemeris (with or without applied corrections) or clocks from SP3 files, it may be important to understand that they are not corrected for the 2nd-order relativistic effect. The 2nd-order relativistic effect is a priodic time correction defined as -2 (R * V) / c^2 and includes the scalar product of satallite position and velocity divided by the speed of light raised to the second power.

Specify the 'Host' IP name or number of an NTRIP Broadcaster to upload the stream. An empty option field means that you don't want to upload corrections to Broadcast Ephemeris.

Enter the NTRIP Caster's IP 'Port' number for stream upload. Note that NTRIP Casters are often configured to provide access on more than one port, usually port 80 and 2101. If you experience communication problems on port 80, you should try to use the alternative port(s).

Each stream on an NTRIP Caster is defined using a unique source ID called mountpoint. An NTRIP Server like BNS uploads a stream to the Caster by referring to a dedicated mountpoint that has been set by the Caster operator. Specify here the mountpoint based on the details you received for your stream from the operator. It is often a four character ID (capital letters) plus an integer number.

BNS refers its clock and orbit corrections to a specific reference system. Available options are

• IGS05 which stands for the GNSS-based IGS realization of the International Terrestrial Reference Frame 2005 (ITRF2005), and
• ETRF2000 which stands for the European Terestrial Reference Frame 2000 adopted by EUREF, and
• NAD83 which stands for the North American Datum 1983 as adopted for the U.S.A., and
• GDA94 which stands for the Geodetic Datum Australia 1994 as adopted for Australia, and
• SIRGAS2000 which stands for the Geodetic Datum adopted for Brazil, and
• SIRGAS95 which stands for the Geodetic Datum adopted i.e. for Venezuela, and
• 'Custom' which allows a transformation of Broadcast Corrections from the IGS05 system to any other system through specifying up to 14 Helmert Transformation Parameters.

IGS05: As the clocks and orbits coming from real-time GNSS engine are expected to be in the IGS05 system, no transformation is carried out if this option is selected.

ETRF2000: The formulars for the transformation 'ITRF2005->ETRF2000' are taken from 'Claude Boucher and Zuheir Altamimi 2008: Specifications for reference frame fixing in the analysis of EUREF GPS campaign', see http://etrs89.ensg.ign.fr/memo-V7.pdf. The following 14 Helmert Transformation Parameters were introduced:

Translation in X at epoch To:  0.0541 m
Translation in Y at epoch To:  0.0502 m
Translation in Z at epoch To: -0.0538 m
Translation rate in X: -0.0002 m/y
Translation rate in Y:  0.0001 m/y
Translation rate in Z: -0.0018 m/y
Rotation in X at epoch To:  0.891 mas
Rotation in Y at epoch To:  5.390 mas
Rotation in Z at epoch To: -8.712 mas
Rotation rate in X:  0.081 mas/y 
Rotation rate in Y:  0.490 mas/y
Rotation rate in Z: -0.792 mas/y
Scale at epoch To : 0.00000000040
Scale rate: 0.00000000008 /y
To: 2000.0

NAD83: Formulars for the transformation 'ITRF2005->NAD83' are taken from 'Chris Pearson, Robert McCaffrey, Julie L. Elliott, Richard Snay 2010: 'HTDP 3.0: Software for Coping with the Coordinate Changes Associated with Crustal Motion', Journal of Surveying Engineering.

Translation in X at epoch To:  0.9963 m
Translation in Y at epoch To: -1.9024 m
Translation in Z at epoch To: -0.5219 m
Translation rate in X:  0.0005 m/y
Translation rate in Y: -0.0006 m/y
Translation rate in Z: -0.0013 m/y
Rotation in X at epoch To: 25.915 mas
Rotation in Y at epoch To:  9.426 mas
Rotation in Z at epoch To: 11.599 mas
Rotation rate in X:  0.067 mas/y 
Rotation rate in Y: -0.757 mas/y
Rotation rate in Z: -0.051 mas/y
Scale at epoch To : 0.00000000078
Scale rate: -0.00000000010 /y
To: 1997.0

GDA94: The formulars for the transformation 'ITRF2000->GDA94' are taken from 'John Dawson and Jim Steed 2004: International Terrestrial Reference Frame (ITRF) to GDA94 Coordinate Transformations', see http://www.ga.gov.au/servlet/BigObjFileManager?bigobjid=GA3795 .

Translation in X at epoch To:  0.07167 m
Translation in Y at epoch To:  0.00486 m
Translation in Z at epoch To: -0.04711 m
Translation rate in X: -0.00342 m/y
Translation rate in Y:  0.00055 m/y
Translation rate in Z:  0.00136 m/y
Rotation in X at epoch To:  9.1362 mas
Rotation in Y at epoch To:  9.3086 mas
Rotation in Z at epoch To:  9.1599 mas
Rotation rate in X:  1.4652 mas/y 
Rotation rate in Y:  1.1005 mas/y
Rotation rate in Z:  1.1480 mas/y
Scale at epoch To : -0.000000008239
Scale rate: -0.000000000212 /y
To: 2000.0

SIRGAS2000: The formulars for the transformation 'ITRF2005->SIRGAS2000' were provided via personal communication from CGED-Coordenacao de Geodesia, IBGE/DGC - Diretoria de Geociencias, Brazil..

Translation in X at epoch To: -0.0051 m
Translation in Y at epoch To: -0.0065 m
Translation in Z at epoch To: -0.0099 m
Translation rate in X:  0.0000 m/y
Translation rate in Y:  0.0000 m/y
Translation rate in Z:  0.0000 m/y
Rotation in X at epoch To:  0.150 mas
Rotation in Y at epoch To:  0.020 mas
Rotation in Z at epoch To:  0.021 mas
Rotation rate in X:  0.000 mas/y 
Rotation rate in Y:  0.000 mas/y
Rotation rate in Z:  0.000 mas/y
Scale at epoch To : 0.000000000000
Scale rate: -0.000000000000 /y
To: 2000.0

SIRGAS95: The formulars for the transformation 'ITRF2005->SIRGAS95' were provided via personal communication from Gustavo Acuha, Laboratorio de Geodesia Fisica y Satelital at Zulia University (LGFS-LUZ), parameters based on values from Table 4.1 of "Terrestrial Reference Frames (April 10, 2009), Chapter 4" in http://tai.bipm.org/iers/convupdt/convupdt_c4.html..

Translation in X at epoch To:  0.0077 m
Translation in Y at epoch To:  0.0058 m
Translation in Z at epoch To: -0.0138 m
Translation rate in X:  0.0000 m/y
Translation rate in Y:  0.0000 m/y
Translation rate in Z:  0.0000 m/y
Rotation in X at epoch To:  0.000 mas
Rotation in Y at epoch To:  0.000 mas
Rotation in Z at epoch To: -0.003 mas
Rotation rate in X:  0.000 mas/y 
Rotation rate in Y:  0.000 mas/y
Rotation rate in Z:  0.000 mas/y
Scale at epoch To : 0.00000000157
Scale rate: -0.000000000000 /y
To: 1995.4

Custom: The default numbers shown as examples are those for a transformation from ITRF2005 to ETRF2000'.

The clock and orbit corrections streamed by BNS to the NTRIP Caster can be logged locally. Specify a full 'Save stream' path here to save this information to a local file. Default value for 'Save stream' is an empty option field, meaning that logging is disabled.

The file is in plain ASCII format comprising records containing the following set of parameters:

• GPS Week
• Second in GPS Week
• GNSS Indicator and Satellite Vehicle Pseudo Random Number
• IOD referring to Broadcast Ephemeris set
• Clock Correction to Broadcast Ephemeris [m]
• Radial Component of Orbit Correction to Broadcast Ephemeris [m]
• Along-track Component of Orbit Correction to Broadcast Ephemeris [m]
• Cross-track Component of Orbit Correction to Broadcast Ephemeris [m]

The following is an example file contents based on combined orbit and clock corrections for GPS and GLONASS carried in RTCM Version 3.x message Type 1060 and 1066:

1489 325606.0 G31    18     -1.021      0.110   -1.308   -0.120
1489 412006.0 R10    18      7.342      1.393    4.858   -2.634
1489 412006.0 R19    18      4.696      2.358    1.707   -2.907
...
1489 325607.0 G30    80      6.022      0.591   -0.318    0.022
1489 325607.0 G31    18     -1.022      0.110   -1.308   -0.120
1489 412007.0 R10    18      7.341      1.390    4.860   -2.636
1489 412007.0 R19    18      4.698      2.356    1.706   -2.906
...

BNS allows to either refer orbit/clock corrections to the satellite's Center of Mass (CoM) or to the satellite's Antenna Phase Center (APC). By default corrections refer to APC. Tick 'Center of Mass' to refer uploaded corrections to CoM.

BNS can upload a stream carrying Broadcast Ephemeris in RTCM Version 3 format to an NTRIP Caster.

Specify the 'Host' IP name or number of an NTRIP Broadcaster to upload the stream. An empty option field means that you don't want to upload Broadcast Ephemeris.

Enter the NTRIP Caster's IP 'Port' number for stream upload. Note that NTRIP Casters are often configured to provide access on more than one port, usually port 80 and 2101. If you experience communication problems on port 80, you should try to use the alternative port(s).

Each stream on an NTRIP Caster is defined using a unique source ID called mountpoint. An NTRIP Server like BNS uploads a stream to the Caster by referring to a dedicated mountpoint that has been set by the Caster operator. Specify here the mountpoint based on the details you received for your stream from the operator. It is often a four character ID (capital letters) plus an integer number.

The clock corrections generated by BNS can be logged separately in Clock RINEX format. The file naming follows the RINEX convention.

Here you can specify the path to where the Clock RINEX files will be stored. If the specified directory does not exist, BNS will not create Clock RINEX files. Default value for 'Directory' is an empty option field, meaning that logging of Clock RINEX files is disabled.

Select the length of the Clock RINEX file generated. The default value is 1 day.

Select the Clock RINEX sampling interval in seconds. A value of zero '0' tells BNS to store all received epochs into Clock RINEX. This is the default value.

The orbit corrections generated by BNS can be logged separately in SP3 Orbit files. The file naming follows the IGS convention.

Here you can specify the path to where the SP3 Orbit files will be stored. If the specified directory does not exist, BNS will not create SP3 Orbit files. Default value for 'Directory' is an empty option field, meaning that logging of SP3 Orbit files is disabled.

Select the length of the SP3 Orbit file generated. The default value is 1 day.

Select the SP3 Orbit file sampling interval in seconds. A value of zero '0' tells BNS to store all received epochs into SP3 Orbit files. This is the default value.

The bottom menu bar allows to start or stop the execution of BNS and provides access to BNC's online help funtion.

Hit 'Start' to start receiving IGS orbits and clocks and convert them into corrections to Broadcast Ephemeris. Note that when started, BNS by default will begin with new files which might overwrite existing files when necessary unless the option 'Append files' is ticked.

Hit the 'Stop' button in order to stop BNS.

Command line options are available to run BNS in 'no window' mode or let it read a specific configuration file. Note that the self-explaining contents of the configuration file can easily be edited. It is possible to introduce a specific configuration file name instead of using the default name 'BNS.ini'.

Apart from its regular windows mode, BNS can be started on all systems as a background job with command line option '-nw'. BNS will then run in 'no window' mode, using processing options from its configuration file on disk. Terminate BNS using Windows Task Manager when running it in 'no window' mode on Windows systems.

Example:

bns.exe -nw

Example:

./bns --conf MyConfig.ini

This leads to a BNS job using configuration file 'MyConfig.ini'. The configuration file will be saved in the current working directory.

• In Qt-based desktop environments (such as KDE) on Unix/Linux/Mac platforms users may experience a crash at startup even when BNS is run in the background using the '-nw' option. This is a known bug most likely resulting from an incompatibility of Qt libraries in the environment and in BNS. Entering the command 'unset SESSION_MANAGER' before running BNS may help as a work-around.
• Currently BNS can only generate premature RTCM Version 3.x message Type 1057-1068 (see RTCM document 091-2009-SC104-542 'Version 3 Proposed Messages – Set 10') . Note that what is implemented in BNS is just a temporary solution.
• We experienced some limitation with the Standard Version of Microsoft Windows related to socket communication where sockets are not always handled properly. Since BNS makes intensive use of communication through sockets, we recommend to use the Server Version of Microsoft Windows when running BNS continuously for extended period on a Windows platform.
• Once BNS has been started, its configuration can not be changed unless without a restart. An on-the-fly reconfiguration is not implemented.

The BKG Ntrip State Space Server (BNS) Qt Graphic User Interface (GUI) has been developed for the Federal Agency for Cartography and Geodesy (BKG) by Leos Mervart, Czech Technical University Prague, Department of Geodesy. BNS includes a GNU GPL open source RTCM 3.x encoder, written for BKG by Dirk Stoecker, Alberding GmbH, Schoenefeld.

Georg Weber
Federal Agency for Cartography and Geodesy (BKG)
Frankfurt, Germany
[euref-ip@bkg.bund.de] or [igs-ip@bkg.bund.de]

The Radio Technical Commission for Maritime Services (RTCM) is an international non-profit scientific, professional and educational organization. Special Committees provide a forum in which governmental and non-governmental members work together to develop technical standards and consensus recommendations in regard to issues of particular concern. RTCM is engaged in the development of international standards for maritime radionavigation and radiocommunication systems. The output documents and reports prepared by RTCM Committees are published as RTCM Recommended Standards. Topics concerning Differential Global Navigation Satellite Systems (DGNSS) are handled by the Special Committee SC 104.

Personal copies of RTCM Recommended Standards can be ordered through http://www.rtcm.org/orderinfo.php.

'Networked Transport of RTCM via Internet Protocol' Version 1.0 (NTRIP) stands for an application-level protocol streaming Global Navigation Satellite System (GNSS) data over the Internet. NTRIP is a generic, stateless protocol based on the Hypertext Transfer Protocol HTTP/1.1. The HTTP objects are enhanced to GNSS data streams.

NTRIP Version 1.0 is an RTCM standard designed for disseminating differential correction data (e.g. in the RTCM-104 format) or other kinds of GNSS streaming data to stationary or mobile users over the Internet, allowing simultaneous PC, Laptop, PDA, or receiver connections to a broadcasting host. NTRIP supports wireless Internet access through Mobile IP Networks like GSM, GPRS, EDGE, or UMTS.

NTRIP is implemented in three system software components: NTRIP clients, NTRIP servers and NTRIP broadcasters. The NTRIP broadcaster is the actual HTTP server program whereas NTRIP client and NTRIP server are acting as HTTP clients. The NTRIP broadcaster maintains a source-table containing information on available NTRIP streams, networks of NTRIP streams and NTRIP broadcasters. The source-table is sent to an NTRIP client on request.

NTRIP is an open none-proprietary protocol. Major characteristics of NTRIP's dissemination technique are:

• Based on the popular HTTP streaming standard; comparatively easy to implement when having limited client and server platform resources available.
• Application not limited to one particular plain or coded stream content; ability to distribute any kind of GNSS data.
• Potential to support mass usage; disseminating hundreds of streams simultaneously for thousands of users possible when applying modified Internet Radio broadcasting software.
• Considering security needs; stream providers and users don't necessarily get into contact, streams often not blocked by firewalls or proxy servers protecting Local Area Networks.
• Enables streaming over mobile IP networks because of using TCP/IP.

The NTRIP Version 2 transport protocol is not implemented in BNS.

RTCM Version 3.x has been developed as a better alternative to RTCM Version 2.x. Service providers and vendors have asked for a standard that would be efficient, easy to use, and easily adaptable to new situations.

• Message type 1057: GPS orbit corrections to Broadcast Ephemeris
• Message type 1058: GPS clock corrections to Broadcast Ephemeris
• Message type 1059: GPS code biases
• Message type 1060: Combined orbit and clock corrections to GPS Broadcast Ephemeris
• Message type 1061: GPS User Range Accuracy (URA)
• Message type 1062: High-rate GPS clock corrections to Broadcast Ephemeris
• Message type 1063: GLONASS orbit corrections to Broadcast Ephemeris
• Message type 1064: GLONASS clock corrections to Broadcast Ephemeris
• Message type 1065: GLONASS code biases
• Message type 1066: Combined orbit and clock corrections to GLONASS Broadcast Ephemeris
• Message type 1067: GLONASS User Range Accuracy (URA)
• Message type 1068: High-rate GLONASS clock corrections to Broadcast Ephemeris

RTCM Version 3.x streams carrying these messages may be used for example to support real-time Precise Point Positioning (PPP) applications using the 'state space' approach.

The following table's left column is an example for the contents of a configuration file 'BNS.ini'. It enables the upload of streams CLCK1 and CLCK2 to www.igs-ip.net. Clock RINEX files and SP3 Orbit files are saved to a directory /home/weber/rinex :