Skip to content

CHIPSat - Space Operations with TCP/IP

In the timeframe of the late 1990s and early 2000s, the Internet was growing rapidly and people had become widely exposed to using early web and other online services. Delivery of Internet services over satellite links, particularly GEO satellites, had been done routinely for some time and was in a phase of being optimized rather than pioneered.

However, use of the Internet and its TCP/IP protocol suite for direct communication with spacecraft was still mainly only done in experimental technology demonstrations. One prominent example was NASA Goddard's work under the OMNI (Operating Missions as Nodes on the Internet) project. Computing capability for spacecraft flight systems was beginning to become reasonable enough to run networking software, making use of TCP/IP onboard feasible. Further, networking software had become commonplace by this time, with widespread support in Microsoft Windows and the Unix-derived operating systems of the time (e.g. SunOS, Digital UNIX, BSDs, etc.) that would commonly be used in ground systems, as well as in some embedded real-time operating systems that would be used on spacecraft flight computers. But despite basic feasibility, there were good reasons why TCP/IP was not directly used for spacecraft communications.

Individualized per-mission command and telemetry formats were commonly used. These were designed from heritage in legacy serial communications systems with little in common to Internet applications. Doing things in a new and different way with Internet protocols would cost time and money (to train people, adapt processes, tooling, etc. away from the old paradigms). Additionally, data link framing using CCSDS protocols at the time did not easily support IP encapsulation (this was added later to the CCSDS suite). Finally, there were major concerns about security and malicious hackers being able to reach satellites via Internet connectivity. For many valid reasons, NASA missions at the time had not used Internet protocols to operate the spacecraft. The CHIPSat - Cosmic Hot Interstellar Plasma Spectrometer Satellite mission changed this.

CHIPSat

NASA, Public domain, via Wikimedia Commons

There is a nice short paper on the CHIPSat design by Janicik and Wolff, that can be found online in the SPIE Proceedings. This paper does a good job of describing some relevant properties of the mission's use of TCP/IP:

  • End-to-end networking - This was different from traditional ground-only based use of networks supporting other missions.

  • Low data rate links (tens of kbps) - This was in a similar range dial-up modems being used for Internet access in the 1990s (though a bit slower in the command uplink and a bit faster in the downlink from the satellite).

  • Network Time Protocol (NTP) - The spacecraft clock was estimated to be able to be kept within 100 milliseconds of UTC through NTP servers on the ground and an SNTP client onboard.

  • Use of Commercial Off-The-Shelf (COTS) operating systems - Windows NT, VxWorks, and Linux are mentioned for mission control, the on-board computer, and ground station routers, respectively.

  • High-level Data Link Control (HDLC) framing - Over the RF space links, HDLC was used to carry IP packets.

  • Security - Firewalls and VPN technology were used to secure the communications.

Keys to overcoming some of the traditional challenges for Internet protocols in spacecraft operations at the time seem to have been (1) that SpaceDev was a new smaller company at the time, so didn't have as much invested in legacy techniques, (2) that HDLC rather than only CCSDS framing was used on the low-rate space links so that IP could be reasonably supported, and (3) the use of firewalls and VPNs was able to satisfy network security requirements.

Overall, the novelty of CHIPSat's use of TCP/IP was relying on it for nominal operations, not just as an experiment or demonstration. Accounts from the mission designers indicate that this was a good decision to maintain low-costs and support mission development speed, since they were able to leverage COTS tools and products and support distributed and easily portable integration and test activities.