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 SP3 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.

Note that BNS currently only generates premature RTCM Version 3.x message types 4056 for combined GPS orbit and clock corrections and 4057 for combined GLONASS orbit and clock corrections to Broadcast Ephemeris.

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 SP3 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.

The current size of the real-time stream produced by BNS is in the order of 5 kbits/sec depending on the number of visible satellites. When uploading the stream to an NTRIP Broadcaster, user needs to ensure that the connection used can sustain the required bandwidth.

Running BNS requires the clock of the host computer to be properly synchronized.

All options for running BNS on Unix/Linux/Mac systems are saved in file ${HOME}/.config/BKG/BKG_NTRIP_Server.conf, see annexed 'Configuration File' example. On Windows systems options are saved in register BKG_NTRIP_Server. The self-explaining contents of the configuration file or the Windows register can easily be edited.

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.
  Note that on Windows systems options are saved in register BKG_NTRIP_Server. On Unix/Linux/Mac systems options are saved in file ${HOME}/.config/BKG/BKG_NTRIP_Server.conf.
• 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 BNC. 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.

Records of BNC'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 BNC 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 BNC 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.

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 SP3 format. They can be provided by a real-time GNSS engine such as RTNet. Their 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 SP3 format from a real-time GNSS engine. Each epoch starts with an asterisk character followed by GPS Week, Second in GPS Week and Number of satellites. 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]
• Satellite clock error [microsecond]

*  2008 11 15 23  9  40.00000000
PG02   9913.526202 -14009.502013  20043.508402    172.954389
PG04  23093.835904  -6682.421653  11570.857634   -233.598390
PG07  24249.710621   7319.754680   8146.397178     23.216940
PG08  26390.024445     40.546316  -4908.638575   -178.106488
PG10   1835.245663 -21440.492626  15205.319419     -7.272325
PG13  12906.569448   6704.608105  22108.581216    277.382794
PG16  -6605.961090  17147.164247  19156.319313     95.078459
PG20  13676.316680  22650.428992   2457.051428     98.981972
PG23   6709.764296  15204.810711  20604.601368    380.096453
PG25  19695.705366   9866.220333  15065.609012     26.781926
PG27  25598.219004   4571.609372   6357.551439      0.304345
PG29 -12376.531693  -8988.235685  21818.571434    -29.839454
PR04   9918.187580  23513.478040    319.847487    151.558351
PR06   8858.433630  -7341.610546  22646.535467   -244.283462
PR07  -2285.074648 -21548.431780  13471.401525   -122.300100
PR14  -4723.060343  10040.375495  22946.780676   -113.677871
PR15  14469.798068  10358.339867  18230.729298     79.645569
PR20  17648.744681 -16698.956975  -7876.252525    -62.588294
PR21  10448.514425 -21096.368284   9681.207096   -122.789091
PR22  -2707.192952 -13243.085608  21689.194398   -170.976408
PR23 -14575.573714   2817.925995  20728.130339   -263.187906

BNS is listening at an IP port for incoming GNSS clocks and orbits in SP3 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. Note that it only carries the premature message Types 4056 and 4057 for combined orbit and clock corrections to GPS and GLONASS Broadcast Ephemeris.

BNS allows to configure two Ephemeris 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.

Enter the NTRIP Caster's 'Host' IP name or number for stream upload.

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 upload 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 detail you received from the operator for your stream. 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.

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'. 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

Contact [igs-ip@bkg.bund.de] if you would like to see further Helmert transformation parameters implemented in BNS to support other national or regional reference system.

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 4056 and 4057:

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
...

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.

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.

On all systems BNS can be started in batch mode with the command line option '-nw'. BNS will then run in 'no window' mode, using options from the configuration file ${HOME}/.config/BKG/BNC_NTRIP_Server.conf (Unix/Linux/Mac, see 'Configuration File' example in the Annex) or from the register BKG_NTRIP_Server (Windows).

The self-explanatory contents of the configuration file or the Windows registry can easily be edited. Before editing, terminate BNS first using Windows Task Manager when running it in 'no window' mode on Windows systems.

• 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 4056 and 4057 for combined GPS and GLONASS orbit and clock corrections, see RTCM document 026-2008-SC104-429 'Version 1 Proposed SSR Messages prepared by Geo++'. Note that the length of data fields in these messages is not yet standardized. What's 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.

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 4050: GPS orbit corrections to Broadcast Ephemeris
• Message type 4051: GPS clock corrections to Broadcast Ephemeris
• Message type 4052: GPS code biases
• Message type 4053: GLONASS orbit corrections to Broadcast Ephemeris
• Message type 4054: GLONASS clock corrections to Broadcast Ephemeris
• Message type 4055: GLONASS code biases
• Message type 4056: Combined orbit and clock corrections to GPS Broadcast Ephemeris
• Message type 4057: Combined orbit and clock corrections to GLONASS 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 is an example of the contents of a Unix/Linux/Mac configuration file ${HOME}/.config/BKG/BKG_NTRIP_Server.conf. 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 :

[General]
clkPort=7000
ephEcho=/home/weber/rinex/eph.rnx
ephHost=clock-ip.bkg.bund.de
ephPort=6000
fileAppend=0
font="Helvetica [Adobe],8,-1,5,75,0,0,0,0,0"
inpEcho=/home/weber/rinex/ClocksOrbits.dat
logFile=/home/weber/rinex/bns.log
mountpoint_1=CLCK1
mountpoint_2=CLCK2
outFile_1=/home/weber/rinex/CLCK1
outFile_2=/home/weber/rinex/CLCK2
outHost=www.igs-ip.net
outPort=2101
password=serverPass
proxyHost=
proxyPort=
refSys_1=IGS05
refSys_2=ETRS89
rnxIntr=1 day
rnxPath=/home/weber/rinex
rnxSampl=30
sp3Intr=1 day
sp3Path=/home/weber/rinex
sp3Sampl=300

Note that on Windows systems configuration options are saved in register BKG_NTRIP_Server.