In the Real-time IGS context NTRIP stands for one of two options to stream GNSS data over the Internet. NTRIP, the abbreviation for “Networked Transport of RTCM data via Internet” is a generic, stateless application-level protocol based on the Hypertext Transfer Protocol HTTP/1.1. The HTTP objects are enhanced to GNSS data streams.

NTRIP is designed for disseminating RTCM formatted streams 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.

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 broadcast 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 Real-time IGS Call for Participation mentions two options for streaming data. We may call them here “SOC/UPD” and “RTCM/NTRIP”. You are free to choose one of them depending on your CORS hard and software and the needs that potential clients may have concerning data formats and transport protocols.

Quite a number of streaming formats is in use. Among them are various proprietary vendor formats as well as open RTCM or scientific formats. The long-term intention for Real-time IGS is to reduce the number of streaming formats as much as possible. Concerning GNSS observations, the wish is to adapt one open standard. Which format that will be is under discussion. Note that an open standard for streaming derived products like orbits and clocks remains to be developed.

As of today, Real-time IGS asks its contributors to accept the following priorities:

The RTCM Version 2.x standard is used to format GNSS code and phase observables. It defines a number of messages. Message types that may be of interest in the Real-time IGS context are the following:

• Type 1 message is the range correction message and is the primary message in code-phase differential positioning (DGPS). It is computed in the reverence station receiver by computing the error in the range measurement for each tracked SV.
• Type 2 message is automatically generated when a new set of satellite ephemeris is downloaded to the base receiver. It is the computed difference between the old ephemeris and the new ephemeris. Type 2 messages are used when the reference station is transmitting Type 1 messages.
• Type 3 and 22 messages are the reference station position and the antenna offset. They are used in RTK processing to perform antenna reduction.
• Type 18 and 20 messages are uncorrected carrier phase data and carrier phase corrections.
• Type 19 and 21 messages are the uncorrected pseudo-range measurements and pseudo-range corrections.
• Type 23 message provides the information on the antenna type used on the reference station.
• Type 24 message carries the coordinates of the installed antenna's ARP in the GNSS coordinate system coordinates.

Note that only RTCM Version 2.2 and 2.3 streams can include GLONASS data. The range resolution for RTCM Version 2.x is 2 cm and the phase resolution is 0.5 mm.

RTCM Version 3 is a GNSS streaming format that has been developed as an alternative to RTCM 2. Service providers and vendors have asked for an improved standard that would be more efficient, easy to use, and more easily adaptable to new situations.

RTCM Version 3 defines a number of message. Message types that may be of interest in the Real-time IGS context are:

• Type 1001, GPS L1 code and phase.
• Type 1002, GPS L1 code and phase and ambiguities and carrier to noise ratio.
• Type 1003, GPS L1 and L2 code and phase.
• Type 1004, GPS L1 and L2 code and phase and ambiguities and carrier to noise ratio.
• Type 1005, Station coordinates XZY for antenna reference point.
• Type 1006, Station coordinates XYZ for antenna reference point and antenna height.
• Type 1007, Antenna descriptor and ID.
• Type 1008, Antenna serial number.
• Type 1009, GLONASS L1 code and phase.
• Type 1010, GLONASS L1 code and phase and ambiguities and carrier to noise ratio.
• Type 1011, GLONASS L1 and L2 code and phase.
• Type 1012, GLONASS L1 and L2 code and phase and ambiguities and carrier to noise ratio.
• Type 1019, GPS Ephemeris (under development).
• Type 1020, GLONASS Ephemeris (under development).

Note that RTCM Version 3 today only allows to transport one code observation per frequency (i.e. CA or P1, L2C or P2). The range resolution is 2 cm and the phase resolution is 0.5 mm.

The RTCM formats 2.2, 2.3, 3.0, and 3.1 support GLONASS. NTRIP is a transport protocol for any GNSS data format.