The Operating Missions as Nodes on the Internet project (OMNI for short) is an attempt by NASA to use IP protocols for communication with satellites, the Space Shuttle and deep space probes. It is hoped that, by using standard protocols and equipment, costs and complexity will be decreased. The aim is to push everything that is space specific into the link layer, so that space specific problems are isolated there.


What has been done to date:

  • In April 1999, the UoSAT-12 satellite was launched, initially without any IP support. This was implemented later, and on April 10, 2000 NASA engineers got the first ping back from space.
  • April 14, 2000: The satellite starts to synchronise its clock via NTP
  • May 24, 2000: First fully RFC compliant FTP session with a host in space. Over the next few months a number of bugs in the onboard FTP server are corrected.
  • Jan 25 2001: First web server in space! HTTP is used on UoSAT-12 to transfer data and to monitor the satellite.
  • Jan 9 2002: CANDOS (Communications And Navigation Demonstration On Shuttle) project initiated. From the start it is decided that the platform will be running Linux.
  • Jan 12 2003: CHIPSat, the first operational NASA mission to use IP for all of its communications, is launched. CHIPSat is a plasma spectrometer.
  • Jan 16 2003: Space shuttle Columbia (mission STS-107) takes off with CANDOS on board. This consists of a PC with a 233 MHz processor with 128 MB of RAM, a 140 MB solid state drive (because of the intense vibrations during takeoff) and running Red Hat Linux.

Problem areas

There are several areas that are problematic (or would appear to be) with IP in space:

  • Return trip times: For deep space probes this prohibits the use of TCP. UDP still works fine. However for satellites "close" to earth TCP works perfectly. Throughputs of 540 Mbit/s have been achieved over TCP with a satellite in geosynchronous orbit.
  • Intermittent links: the satellite is continually moving, eventually moving out of the line of sight of the antenna (except of course for geostationary satellites). IP itself does not have the concept of a session, each packet has an address on it, so this is not a problem.
  • Interference: the large amounts of radiation in space and the long distances have the potential to interfere with signals. At first one might think this would rule out protocols like IP that were designed to operate in relatively safe environments. In real life, your average spacecraft RF link has the same bit error rate (BER) as a phone line (around 10-5). Like the designers of PPP, NASA uses a variety of error correction systems to bring this down to useful levels.
Most of these are problems are present whatever transmission method is used. Space is Space.


  • Cheaper equipment: If all satellites use IP then it would allow ground stations to all have the same standard equipment. In addition, NASA have developed a simple interface between a bog standard, commercially available, router and existing RF equipment.
  • Reduced development times: The tools, software and protocols for things like file transfer, VPNs etc. are already out there. Using them would save considerable amounts of work. Additionally all applications can use the same API for communications.
  • Better communication: Astronauts on the shuttle could communicate with friends, family or colleague without hassle, using email or voice over IP. It also makes it trivial to have several concurrent data transfers on a single link.
  • Cheaper communications: Current spacecraft communications need to be scheduled and are manpower intensive. Automation will reduce costs.
Over the past few years NASA has moved its NASCOM infrastructure over to an IP backbone. The rationale behind this is to make it easier to use cheap generic equipment and standard protocols.


The issue of communications security in space is not new. Security solutions can and should be deployed at all of the various layers used:

Additionally, for the forseeable future, the deployment of IP in space will use private networks.