RTCM: Radio Technical Commission for Maritime Services
NTRIP: Network Transport of RTCM data via Internet Protocol
Historically, GNSS correction data was transported via radio links. Someone proposed the idea of transporting that data over the Internet. As the idea grew, a group of people got together to standardize the protocol for moving this data. While trying to decide how the system should work, they found that their requirements were very close to what is needed for streaming audio over the Internet, such as a music radio station would do.
The vast majority of the data on the Internet is point-to-point (technically called uni-cast). On small networks, data can also be one-to-many (multi-cast), but this is not available on the Internet. In the cast of a music radio station, the audio stream originates somewhere. If there are 100 listeners, there are 100 unique streams, all carrying the exact same data. The duplication of data means a high bandwidth requirement, so it is preferable to have those clients connecting to a server in a big data center that can handle lots of traffic. The resulting ideal design is that when a radio station plays music, they create one audio stream. That single stream is sent to a data center. In the data center, that stream is duplicated and sent out to all the clients that want the data. This eliminates the need to have huge bandwidth capacity at the location of the radio station.
Back in the world of networking, there are two components: servers and clients. Servers run all the time, waiting for requests and then serving those requests. Clients are only on when they want something. A client sends a request to a server, and the server responds. In the audio example, there is one server at the data center, and it waits for requests from both the listeners, and from the radio station. The client at the radio station will request the ability to send data, and the listeners' client will request the ability to receive the data.
NTRIP works exactly the same way. A client at the base station sends data to a server, which then forwards that data on to any clients that have requested that data. Unfortunately the people that documented the NTRIP protocol got a little confused in the way they named the pieces. They came up with the following:
- NTRIP Server (actually a client) - this is connected to a base station.
- NTRIP Caster (actually a server) - this waits for requests.
- NTRIP Client (actually a client) - this gets data from the caster and sends it to a GNSS rover.
The names "server" and "caster" are a cause of confusion. Just be aware of how the data flows within the system.
Last updated: June 15, 2011