A 1.508Mb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE
An RTN (Real Time Network) is by nature sophisticated in its underlying science, but surprisingly simple in day to day use. A shining example of this is the simplicity of the interface utilized by most to access RTN services: Network Transport of RTCM via Internet Protocol, or NTRIP. NTRIP is the refreshingly simple solution to the complex technological (and often political) challenge of simultaneously providing multiple RTN services to multiple users.
This article will outline the original problem, how NTRIP helped solve it, and provide a short primer (using a free application) to illustrate how NTRIP typically works for the end user in the field.
Single CORS — The Good Old Days?
It used to be that a single CORS need only produce static files, often of one epoch, band, and file type, and for one user by direct export from the receiver. To serve multiple users, this may have been posted out to an FTP or website.
Then came early real-time; conventional single-base RTK, broadcasting those corrections via radio (which anyone could use, not just those who paid for it, if that was a concern). More to the point, there were limitations in radio range and effectiveness of the corrections over long baselines. Later, receivers were pushing data to software packages that began to fulfill multiple needs: log static files, push corrections through radio, Internet Protocol, or dial-up modems.
What if multiple users wanted concurrent access to varied flavors of correction or to download different file types? And what if an operator was managing multiple CORS? While there are a lot of ways to accommodate multiple accesses: modem banks, authentication servers, proxy servers; each solution spirals into levels of complexity, costs, maintenance, and configuration.
Networks - Many Services, Many Users
Soon small clusters of multiple stations became managed and monitored "networks", with each station capable of producing several flavors of static data, and several flavors of real-time corrections. Now add "network corrected real-time" to the mix. It is not uncommon for each station to provide half a dozen direct services, as well as to contribute to another half dozen network correction services.
So for a network of only 10 stations one could easily end up with 60 or more services (trust me, I have grey hairs as a result). So how do you serve these up to potentially hundreds of concurrent users? In what would otherwise be an enviable position many services with many folks wanting them now becomes a management nightmare for both network operators and users. Imagine the user that might have to know different phone numbers or IPs for each station (and each different service offered for each station). This scenario does not make for easy data sharing between different CORS and network operators, nor consider the information technology constraints, firewall rules, etc.
The BKG
In the late 90s and early 00s, this problem caught the attention of the Bundesamt für Kartographie und Geodäsie (Federal Agency for Cartography and Geodesy, BKG) that is responsible for the realization and provision of standard geodetic reference networks for the territory of the Federal Republic of Germany. One of the BKG’s primary functions (much like the NGS) is to assist the public in access to a uniform 3-dimensional reference system. Access to properly established, maintained and operated CORS had already been viewed as a viable augmentation to legacy control frameworks.
At the same time, a boom in the development of RTN hit Germany and other European countries. It was clear that for there to be broad usage of such amenities and data sharing between networks (even across international borders), a simple, secure, non-proprietary, and standardized solution must be developed. The BKG took on this development role, with a clear goal of providing a solution that would fall within the framework of the Radio Technical Commission for Maritime Services (RTCM), the international body for standardization of GPS data transmission types.
The Internet itself, with its own transmission protocols such as TCP and UDP (you do not have to drill down too deep into these two acronyms, but you may wish to Google them) is a perfect model for development of a GPS/ GNSS-centric protocol to ride upon and emulate. While the myriad of information technology (IT) departments in the world may agree on very little, at least most of them allow folks to have an Internet browser on their desktops. Multiple users can access a variety of data from a single website or URL. This URL "address" equates to an Internet Protocol address (IP), and a port (typically 80 for websites, 45 for FTP, etc.).
Many data types transmitted in this HTTP-compliant world already have well-thought-out and designed transmission protocols. An example familiar to most is streaming radio. If you wish to hear a streaming ball game, then you go to the league website and tune in. The selection of GPS/GNSS data from an NTRIP caster is just as simple, and surprisingly similar. The example of streaming audio provided the very model for Internet transmission of GPS data and corrections.
The BKG team began this quest under the leadership of Dr. Georg Weber, geodesist, internationally respected expert, and tireless booster for the real-time revolution (Google Dr. Weber’s name for papers and presentations). The result of this development by BKG and others resulted in NTRIP version1.0 (see more at http://igs.bkg.bund.de/index_ntrip_doc.htm); a published protocol implemented initially via some free applications. (A primer on one of those appears later in this article). In the early days of NTRIP there was an unfortunate rumor that NTRIP was a proprietary format, however, it was simply implemented earlier by some manufacturers than others. NTRIP did indeed become an RTCM standard in November of 2004 (see http://igs.bkg.bund.de/root_ftp/NTRIP/documentation/NtripPressRelease.pdf), and the manufacturers have handily stepped up to the plate with NTRIP implementation in nearly all new rover gear.
So was born the notion of a GPS/GNSS Internet "Radio" (Figure 1). This simple design is made up of three parts: sources (RTN software running on a server), an "exchange" (caster), and end user applications (clients/rovers).
Sources - NTRIP Servers
Sources of GPS/GNSS services can include individual CORS outputting raw observations destined for one or more of the central processing centers (CPC) of RTN. There could be multiple static files logging (e.g., RINEX, DAT, 1-sec, 5-sec, etc.), and some single-base correctors (e.g., CMR+, RTCM2.3, RTCM 3.0, etc.), ephemeral/almanac, meteorological data; the list goes on and on. If the various sources can be passed along to an "NTRIP Server" (attached workstation, dedicated device, or built-in as a feature in the hardware/software of the CORS unit itself), then each service or source can be sent to a corresponding slot on a "caster".
Most manufacturers have designed their newer reference station models to be able to operate as NTRIP servers. For older models there are options to stream data to RTN via other means or by dedicated NTRIP-capable add-on devices or applications on connected workstations.
The "Exchange" — NTRIP Casters
An NTRIP caster can be the central switchboard for a singl
e source, hundreds, or even thousands of sources. The caster can reside on an Internet server, even with a single IP and a single port. The caster is where the sources are sorted into a list that a user can access through the same single IP and port, but can then choose from a list of all of the services (at least those that they are authorized to access). The caster can also be configured to require authentication of the user via password, not only for security and/or commerce purposes, but to refine lists of services by user need.
A caster can be installed stand-alone on an Internet server and need not be associated with an RTN, and there are some CORS that can act as their own caster, but it is the use of casters in conjunction with RTN that will be most familiar to the end user. Central Processing Center (CPC) suites of software for RTNs typically include built-in or module-type casters. The RTN can receive some or all of the raw data from CORS at the caster, and also serve the RTN services to the user via caster.
End User - NTRIP Client
The NTRIP client is typically a very simple and small piece of software that accesses casters via an Internet connection to look for services, sees a list, authenticates the user on the caster, and initiates the streaming. In the case of a service like VRS, auto-master styles of MAC, or even auto-station-pick single-base RTK, the position of the rover is sent as standard GGA/NMEA via NTRIP to the CPC of the RTN. A service is initiated, then one of many corrector formats can be sent back to the rover. In the case of broadcast-only formats like Single-Base, FPK, and presetmaster styles of MAC, the user simply picks the source and the data starts flowing.
An NTRIP client can work stand-alone on a mobile device, workstation, or even some types of PDAs or cell phones (there are many flavors of client offered free by BKG and others, and also clients from commercial developers). Most rover manufacturers have added an NTRIP client directly into their software (or as a separate module). While the protocol has not changed substantially since its inception (an excellent design), there are implementations for newer rovers, and a "cottage industry" of NTRIP-related solutions to include dedicated hardware and software applications. This NTRIP boom is just hitting its stride.
Connecting via NTRIP - A Hands-on Example
A good way to learn about NTRIP is to connect to a caster and look at some sources. As caster outputs are HTTP compliant, you can look at a caster table directly in your web browser. The BKG has a caster open for testing and training. Type the following into the address bar of your web browser: http://www.igsip.net:2101. In this example the IP of the caster (URL) has been given a standardlooking web page name, followed by a colon and the port number (i.e., 2101). Most RTN caster addresses just use the IP (in the raw) followed by a colon and port. In the case of the BKG test caster: http://www.igs-ip.net you could alternately input http://81.3.62.36:2101.
More about this caster can be found at: http://www.igs-ip.net/home. The caster is operated by the BKG in support of the International GNSS Service (IGS), formerly the International GPS Service a voluntary federation of more than 200 worldwide agencies that pool resources and permanent GPS & GLONASS station data to generate precise GPS & GLONASS products.
What will show up in your browser will be a big scary scrolling mess of text. Do not worry, you do not have to know how to read any of this. This BKG test caster is exchanging data streams from all over the world for geodetic, academic, and scientific purposes But the main reason we are looking at it is that the BKG gave the "okay" and it has some streams that do not require authentication. A source we will be looking at is ARLI0, an RTCM stream from a local CORS in Arlington, Washington (state). The section of this caster table for this stream looks like this:
STR;ARLI0;Arlington;RTCM2.3;1(1)3(6),18(1),19(1),22(6),23(5),24(5);2;GPS;Test;USA;48.17;237.86;0;0;TRIMBLE NETRS;none;N;N;3600;Puget Sound Reference Network
Do not panic, you do not have to know how to read any of this that is what the client applications are for but in short, it is telling us the mountpoint name, and type of stream output (in this case it is RTCM2.3 suitable for single-base RTK). If one was close enough to the actual station in Arlington, one could initialize for RTK (it might be a bit of a challenge from the other Arlington across the continent near Washington, D.C.).
Mountpoint
The part of the caster list you are most concerned with is the "mountpoint". Most of the rover software packages ask you for a caster IP, a caster port, a username, a password, and will either prompt you to input a mountpoint name, or give you a list to choose from.
In some applications, the settings you make for the type of RTN service you want may narrow that list down for you. For example, if you want a VRS-style survey, with a CMR+ corrector, then the list might give you a list that looks like "ANETVRSCMR, BNETVRSCMR, CNETVRSCMR". In the BKG caster example, if you chose to do a single-base RTK style survey with an RTCM2.3 corrector, you would see "ARLI0" on the list (along with many others).
But in other applications you may just see the whole list, perhaps with some suffixes that help you figure out which is which, perhaps not. There is currently no standard on how folks name their mountpoints or how the manufacturers handle them. But we will look at a list through a free application from the BKG which can help you interpret them.
GNNSS Internet Radio - A Free Testing, Training, and Stream Relay Tool
Go to the BKG website: http://igs.bkg.bund.de/ntrip/ntrip_down.htm and download the first client on the list: GNSS Internet Radio Vers. 1.4.11 (or a newer one if they’ve updated since publication of this article). Install the application (it is very small and does not need to hit your registry so you will likely not need administrator rights to do so). If you are on a Linux PC you can find that client down the list along with other clients for mobile devices like CE, Palm, MS-Mobile, etc.
Open the application (Figure 2). To find the BKG test network click on "Broadcaster". For the "Host", input www.igs-ip.net; for the "Port" input "2101". You will not need to input a username and password in this example, but will most likely need to for other RTN. Leave other settings at defaults and click "OK" (Figure 3).
Back on the main menu, pick "All" under "Select Network", "Update Source Table" under "Select Stream or Update", then click "Start" (also shown in Figure 2). This updates a list of all network lists active under the www.igs-ip.net caster.
A caster can host multiple "networks" (or simply groups of sources and mountpoints). In this example, go to "Select Network" on the main menu and select "Test" from the scroll box. Arlington should show up on the list (Figure 4).
Now you need to decide what you would like to do with the data stream when you get it. An example may be to pass the data stream out of a serial port to a receiver (or a base radio, then broadcast out to an entire site more about that idea later).
Select "Settings" from the main menu and click the radio button for "ComPort", and set up for a streaming output; in Figure 5 it is set for the typical COM1 and 19200 baud used to send data to a lot of base ra
dios. Set and click OK to return to the main menu.
Once you return to the main menu and click the "Start" button you will see the data stream received being relayed to the COM1 port as shown in Figure 6.
Now hit "Stop" and then "Stream Details". You will now see a detailed summary of the source data for that mountpoint as shown in Figure 7. Key items include format, format details, whether or not authentication is needed, name, location, receiver type, and solution type.
This example is how you would access "broadcast only" stream from the caster. But the caster is capable of being the go-between in requests for correctors "customized" to your location (e.g., VRS, auto-master MAC, auto-select singlebase). If you go to the "Settings" menu you can set up a relay of the NMEA position from a receiver to go to the RTN to request the network-corrected stream, or you can manually set a GGA position to initiate a network-corrected stream (Figure 8).
Using an NTRIP Client to Relay Corrections
A great example of this versatility of NTRIP clients is to relay correctors for a job site. Quite a few of the construction users of RTN set up a laptop at their job shack, connect to the RTN via this same client, enter a GGA for the center of the job site, and relay the received VRS corrections out over a base radio for individual rovers and machine control receivers. Some base radios have the NTRIP capability built-in for such relay scenarios like the Trimble SNB900.
There are a number of third party manufacturers building clever NTRIPcentric devices and services. RTN operators can subscribe to commercial services that monitor the quality of RTN streams and availability via NTRIP with web-based reports and user customized email/SMS alarms, all for moderate fees. Another manufacturer has built a ruggedized standalone NTRIP server that can relay raw data from multiple receivers to an RTN or dedicated IP for user access. Other manufacturers have developed cell modems with an NTRIP client built-in so a user can slip in his own SIM card, program the NTRIP client by text messaging, and then output streams from this deck-of-cards sized device directly to a base-radio or a receiver. Even legacy receivers can now connect via these third-party solutions and NTRIP.
The NTRIP Client as an RTN Service Testing Tool
As an RTN user, your main access to a caster via NTRIP will likely be from your rover hardware/software. But this standalone client on your PC can provide another invaluable service (and as an RTN operator I urge every user to install and become familiar with this client). Test your logins, test sources, and test network corrections.
Many of the phone calls to an RTN operations center start with "Is my login current?", or "Is the network down?" While a password might exceed a try count (everybody fat-fingers sometime), and the networks are very rarely "down", the RTN operator may very likely utilize this very same client to test logins and stream availabilities, and we encourage the users to do the same. A quick check of login and streams before you leave the office only takes a few moments.
Get in there and experiment with this NTRIP client! It can help you gain a great understanding of how NTRIP works, provide an invaluable testing and relay tool, and give you an appreciation of how blessedly simple this whole thing is.
A hearty "thank you" to the gang at BKG y’all done good!
Gavin Schrock is a surveyor in Washington State where he is the administrator of the regional cooperative real-time network, the Washington State Reference Station Network. He has been in surveying and mapping for more than 25 years and is a regular contributor to this publication.
Sidebar:
ACROSPEAK (GLOSSARY OF TERMS)
Folks keep making up new terminology faster than we can forget the old ones. You probably know a lot of these terms already, but I wanted to reiterate definitions of some of them in context of how they are used in this series.
BKG Bundesamt für Kartographie und Geodäsie, or German Federal Agency for Cartography and Geodesy. Think of it as a kind of combined USGS and NGS, but in German.
CORS Continuously Operating Reference Station. A GPS and/or GNSS receiver monitored and maintained to provide observation data continuously.
CPC Central Processing Center. Not a real term, I made this one up to describe (without using vendor buzzwords) the nerve center of a Real-Time Network, where the servers, software, support center (and most of the angst) reside.
FKP Flächen-Korrektur-Parameter, or Area Correction Parameter, or Flat Plane Correction, or "Tilt" correction. Another network-corrected real-time approach that may be implemented as a broadcast-only format. (See the RTN101 installment in the May 2007 issue of The American Surveyor.)
FTP File Transfer Protocol. A protocol for file transfers over the Internet that typically takes the form of file folder hierarchies displayed in a web browser.
GGA Global Positioning System Fix Data (or at least as refers to one of its definitions). This is part of NMEA sentences that provides ID location and accuracy data. There are many options and variations, but as it refers to a typical NTRIP implementation, it can be as simple as a manual decimal latitude and longitude (e.g., 48.45 -122.35).
GNSS Global Navigation Satellite System(s). This term is generally used to describe multiple navigation satellite systems (e.g., the U.S. Navstar, a.k.a. GPS; the Russian GLONASS, a.k.a. GLN; the Chinese Compass; the European Union Galileo). When the equipment manufacturers say "GNSS" they are implying that the receiver is capable of receiving multiple constellations (or maybe merely have placeholders for constellations that are not quite there yet). There is nothing wrong with more satellites, but some of the differences in the constellations are not trivial (there is a cottage industry of folks that pontificate about this matter.)
GPS Global Positioning System. Nowadays this term more specifically refers to the U.S. Navstar constellation (the original, and for many, the best). The term has been so generally utilized to describe all global navigation satellite systems that you may find the terms GPS and GNSS used interchangeably for the next decade or so. Consumers just refer to it all as GPS, it is only when the gear starts costing a lot that folks with a lot of letters after their names seem to get persnickety abut the terminology.
IP Internet Protocol. An address of a computer, server, or other device that is attached to the Internet, typically a 32-bit numeric address written as four sets of numbers separated by periods (e.g., 81.3.62.36).
IT Information Technology. The systems, equipment, software, and technical folks that build maintain and administer many of the systems of networks, computers, and communications we all use in our everyday lives. Often wrongly labeled as "preventers of technology", these folks must balance the needs of the users while protecting us from ourselves. Often also called (or suffixed) IS or Information Systems. Geeks are essential, be nice to them.
MAC Master-Auxiliary Concept. Another approach to network-corrected real-time. As implemented utilizing the RTCM3.1-Network Message, it involves client-side processing of data from a master station, along with offset data from auxiliary stations (this can either be in pure broadcast mode with a predefined master station, or in bi-directional mode where the master is auto-selected). (See the RTN101 installment in the May 2007 issue of The American Surveyor.)
NGS National Geodetic Survey. This was started by President Thomas Jefferson as the first scientific U.S. agency, the "Survey of the Coast". Also the developers and stewards of our national spatial reference frameworks. Buried deep in the bureaucracy of the Commerce Department under the National Oceanic and Atmospheric Administration (NOAA). Woefully under-funded and understaffed. (Hey, surveying community! This is our reference framework! Maybe we ought to rally behind these folks!)
NMEA National Maritime Electronics Association. More specifically, as used to refer to the formats for expression of position and/or time that they have developed to interface various equipment and software. Survey equipment/software often includes options for NMEA input/output of position/time.
NTRIP Network Transport of RTCM via Internet Protocol. An internationally adopted digital protocol for GPS/GNSS data transmitted via the Internet.
Port This may refer to a physical port like those serial and parallel ports on a PC, but in terms of the Internet, servers, and NTRIP, then it refers to an adjunct to an Internet address (or IP) that handles the traffic to/from outside connections, internal applications, or an NTRIP caster. When you connect via NTRIP, you will need the IP of the caster (e.g., 81.3.62.36) and the port (e.g., 2101) typically expressed as http:// 81.3.62.36:2101.
RTCM Radio Technical Commission for Maritime services. An international non-profit committee of public and private organizations that develops international standards for maritime radio navigation and radio communications systems. Special Committee 104 works on formats and protocols for Differential Global Navigation Satellite Systems (DGNSS). Accepted formats and protocols are often prefixed by "RTCM" (e.g., RTCM2.1, RTCM 2.3, RTCM3.0, RTCM3.1-Network Message, etc.), and many of the real-time corrector formats have the RTCM blessing or were otherwise developed under the guidance of this group.
RTK Real-Time Kinematics. Differential positioning most typically referring to that which is achieved though the "live" or "real-time" comparison between dual-frequency base receiver(s) and mobile rover(s). When used in the context of an RTN, the term RTK is often used to describe "single-base" real-time, or "classical RTK" (which RTNs often provide as additional services).
RTN Real-Time Networks. More specifically, networks of continuously operating reference stations that provide a wide variety of positioning augmentation services to include networkcorrected real-time.
URL Uniform Resource Locator. The global address of resources on the Internet. The first part indicates the protocol to use (e.g., http or ftp); the second part is the IP address (e.g., 81.3.62.36). An address may be expressed as the protocol and numeric IP (e.g., http://81.3.62.36), or by a more user-friendly alphanumeric web name like http://igs-ip.net.
VRS Virtual Reference Station. The Trimbletrademarked name and acronym for their implementation of a "non-physical reference" approach to real-time network corrections. This is the most widely implemented and utilized method of the non-physical approach worldwide, so it has become somewhat synonymous with RTN services. There are a number of other approaches, and different implementations thereof (see the RTN101 installment in the May 2007 issue of The American Surveyor for more on the various approaches). RTN, including those using Trimble software, can (and often do) offer more than one approach useable by rovers of varied manufacturers.
TTFN "Ta Ta for Now". Something your kids type when they are text messaging.
This is not a technical white paper, so if you need to drill down deeper into the meaning of any of these terms, try a technical bookstore, Wikipedia, or Google. Usually the answers to questions about new technologies reveal themselves best when you start using them. Go forth and utilize NTRIP and RTN you’ll likely get hooked quickly.
A 1.508Mb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE