# INTERNET TECHNOLOGY FOR FUTURE SPACE MISSIONS

# James Rash

## NASA Goddard Space Flight Center

## Greenbelt, MD 20771

## 

## 

# Keith Hogie, Ralph Casasanta

## Computer Sciences Corporation

## Lanham, MD 20706

## 

## 

### ABSTRACT

Ongoing work at National Aeronautics and Space Administration Goddard
Space Flight Center (NASA/GSFC), seeks to apply standard Internet
applications and protocols to meet the technology challenge of future
satellite missions. Internet protocols and technologies are under study
as a future means to provide seamless dynamic communication among
heterogeneous instruments, spacecraft, ground stations, constellations
of spacecraft, and science investigators.

The primary objective is to design and demonstrate in the laboratory the
automated end-to-end transport of files in a simulated dynamic space
environment using off-the-shelf, low-cost, commodity-level standard
applications and protocols. The demonstrated functions and capabilities
will become increasingly significant in the years to come as both earth
and space science missions fly more sensors and the present
labor-intensive, mission-specific techniques for processing and routing
data become prohibitively.

This paper describes how an IP-based communication architecture can
support all existing operations concepts and how it will enable some new
and complex communication and science concepts. The authors identify
specific end-to-end data flows from the instruments to the control
centers and scientists, and then describe how each data flow can be
supported using standard Internet protocols and applications. The
scenarios include normal data downlink and command uplink as well as
recovery scenarios for both onboard and ground failures. The scenarios
are based on an Earth orbiting spacecraft with downlink data rates from
300 Kbps to 4 Mbps. Included examples are based on designs currently
being investigated for potential use by the Global Precipitation
Measurement (GPM) mission.

### KEY WORDS

Global Precipitation Measurement (GPM) mission, Internet Protocol (IP),
mobile IP, Operating Missions as Nodes on the Internet (OMNI),
High-Level Data Link Control (HDLC)

### INTRODUCTION

The goal of an Internet data delivery approach is to provide the
simplest, most cost-effective delivery of science data when and where
needed. The Operating Missions as Nodes on the Internet (OMNI) Project
at Goddard Space Flight Center (GSFC) has been demonstrating these
concepts and working with future missions to baseline these approaches.
The key issues for future National Aeronautics and Space Administration
(NASA) missions have less to do with protocols and more to do with basic
communication problems

Over the past 40 years, NASA has gone from developing and operating
custom solutions to adopting commercial off-the-shelf (COTS) products
and industry standard solutions. There was a time when NASA drove both
space and ground communication technologies. The NASA need to move large
volumes of data reliably over noisy channels in a time-critical
environment was out in front of any other organization. Now, with the
explosion of growth in commercial terrestrial communications, the space
community has the opportunity to use technologies into which the private
sector has poured billions of dollars. NASA Communications (Nascom) has
demonstrated the value to NASA in changing to IP on the ground. The
opportunity now exists for NASA to complete this transition in space.

This paper will briefly describe the methods and protocols that NASA
previously used to communicate with its spacecraft. The discussion then
describes newer approaches, some of which are being studied under
contract for the GSFC for the Global Precipitation Measurement (GPM)
mission. This possible GPM approach uses standard Internet technologies
and protocols to support all aspects of data communications with the
spacecraft.

### NASA/GSFC [L]{.smallcaps}egacy [M]{.smallcaps}ission [S]{.smallcaps}upport Infrastructure

NASA initially used a communications backbone that consisted of
specially developed hardware and software components. This legacy system
required constant monitoring to support all of the on-orbit missions.
Installing new features required extensive development and testing
efforts. The Nascom group provided the support personnel who were
responsible to continually manage the lines and circuits to ensure that
the operations team could communicate with the spacecraft on an
as-needed basis. As can been seen from Figure 1, as Nascom moved to more
standard protocols the throughput capacity increased, allowing Nascom to
support missions with progressively higher data rates.

Earlier NASA missions employed an old style tape recorder to store
science and housekeeping data. When the spacecraft was in contact with a
ground station, the recorder was commanded to rewind and begin a
playback. With the advent of the next generation of missions, NASA moved
to a space-qualified solid-state recorder (SSR), but the SSR still
emulated the older style tape recorders. With either of the previous
data storage techniques, there was no concept of files; the data was
simply stored on-board as a stream of data. Whenever a station contact
occurred, the operations team would request a data downlink based upon
the on-board computer's addressing scheme.

Under the legacy mission domain, a major concept was that the telemetry
downlink formats and protocols were different from those in the
corresponding command operations procedures (COP) protocols[^1]. These
different formats and protocols had to be tested prior to launch to
ensure that the spacecraft had been successfully checked out. Under this
approach, the telemetry downlink was used to provide a return link to
verify that the commands were received in the correct sequence. To
correctly design this type of an approach, unique application SW was
required both on the ground and on the spacecraft to ensure that
commands were not received out of sequence. This unique application code
also required extra test time to ensure that the code worked as
designed. Figure 1 identifies the underlying data delivery protocols
that Nascom has used since the early 1960s as well as the network
throughput capacity using these protocols during that period.

![](media/image1.pct){width="6.347222222222222in"
height="3.3472222222222223in"}Figure 1. NASA Data Delivery Protocols --
Evolution and Throughput Capacity Upgrades

### NASA/GSFC Nascom Transition

As indicated in Figure 1, Nascom began an evolution towards a
ground-based IP routing mechanism by developing and deploying the small
conversion devices (SCD) and programmable telemetry processors (PTPs).
These devices supported the use of IP for the ground transport of data;
however, at that time there still were no modifications to the
spacecraft or ground systems. After the IP transition (which could be
regarded as a watershed event), Nascom ultimately supported a dramatic
increase in the overall data throughput rates. Another benefit of the IP
transition was that Nascom could now more thoroughly use commodity-level
standards and COTS HW solutions to transport the data received at a
ground station. However, the basic spacecraft and ground systems were
still based on the legacy concepts; NASA/GSFC had not incorporated
Internet protocols in a complete end-to-end approach.

This all changed in the mid-1990s; NASA/GSFC began funding concepts and
prototyping efforts to explore the use of a full IP-based communications
protocol for space missions. This approach is leveraged against the Open
Systems Interconnection (OSI) seven-layer reference model for data
communications as noted in Figure 2. The OMNI Project at GSFC provided a
focal point not only for IP-based prototyping to identify concepts,
rationale, and requirements for the full use of IP for space missions
but also for testing and evaluating the various IP-based approaches and
solutions.

![](media/image2.pct){width="6.190277777777778in"
height="2.888888888888889in"}Figure 2. OSI Reference Model for space
missions

### Potential New Approach for GPM

In 2002, the OMNI Project began studying data system concepts for the
GPM mission to identify and document how IP could be used in both the
space segment and the ground segment. The essential objective was to
route data from the instruments on-board the spacecraft all the way to
the end users at either the mission operations control center or any
group of science users. The GPM mission architecture, data flows, and
concepts are described in greater detail in the draft Global
Precipitation Measurement (GPM) Spacecraft and Instrument Telemetry Data
Flow Interfaces and Operations Concepts document \[[^2]\]. A draft
spacecraft architectural system, as depicted in Fig. 3, was identified
to support the GPM mission. This architectural concept employs
fault-tolerant concepts with dual Ethernet Local Area Networks (LANs),
dual on-board computers (OBCs), and dual up/down cards that also perform
more routing functions.

A major shift for the GPM mission is to replace the storage concept,
since the GPM spacecraft will be designed with a modern operating system
that supports file management. The GPM spacecraft will store the science
data as files rather than storing the data as a stream onto a SSR.
Another conceptual change under review is the data transport mechanisms
used to support the spacecraft data transfer (both uplink and downlink
of data). A fully redundant Ethernet LAN is being considered to support
data transfer between the science instruments, the on-board computers
(OBCs), and the up/down cards using UDP/IP packets to transport the
data. A MIL-STD 1553 data bus is used as the data transport mechanism
among other spacecraft subsystems using the current data packet concepts
(e.g., between the attitude control subsystem and the OBC). The GPM
spacecraft may use the Multicast Dissemination Protocol (MDP) \[[^3]\]
applications task, which guarantees reliable data file delivery over a
variety of link types, either infrequent return links or full duplex
links.

Additionally, the OMNI Project suggested the use of High-Level Data Link
Control (HDLC) framing for the link layer for the space-ground RF
transmissions. The proposed use of HDLC is not considered risky, because
HDLC is the dominant link layer standard in terrestrial networks.
Further, currently there are eighty spacecraft that currently employ
this link layer framing technique. GSFC has funded additional studies on
the use of HDLC as a link framing technique on noisy space links;
including a study completed by ITT Industries on the use of HDLC framing
compared to CCSDS framing; these studies and results can be found on the
OMNI web site \[[^4]\]. The OMNI Project also proposed that the GPM
mission use a standard router at the ground station with the
corresponding IP mobility and security protocols enabled.

![](media/image3.pct){width="6.170138888888889in"
height="3.502083333333333in"}Figure 3 - Proposed Architectural Concepts
for GPM Spacecraft

#### On-board science data transport concepts

The science instruments format their data into UDP/IP packets for
transport to the OBC via the Ethernet LAN; the real-time housekeeping
data are sent to the OBC via the MIL-STD 1553 bus. In the OBC, the
science data are removed from the UDP packets and stored into files.
These files normally contain one minute's worth of science data; but the
OBC can be commanded to use different time slices to handle different
situations, like a TDRSS handover. The OBC contains a storage management
(SM) task, which provides file management for the spacecraft. It opens
new files, adds the data from real-time UDP packets into the files and
then closes the files when the maximum time limit, usually one minute,
is reached. The SM task then moves the file into the "hot directory" for
MDP to begin the associated processing to downlink the file. In this
example, MDP acts as the initiator of the file transfer to the ground.

#### Data downlink from spacecraft to ground station 

The data downlink consists of both real-time housekeeping data in UDP/IP
packets and the science data files downlinked using an MDP server task
on the spacecraft. These application data, both real-time and science
data are inserted into UDP/IP packets with the appropriate header
formats, including the Ethernet, IP, and UDP headers. The data are
transferred to the up/down card/router. The up/down card throttles the
data to the I and Q channels at an average rate of 150 kbps. When
required, the mission operations center (MOC) can schedule an S-band
single access (SSA) pass to provide an increase to the downlink rate and
provide the capability of downlinking a large volume of data in a short
period of time. The MOC would schedule an SSA pass in the event that
there is a backlog of science data on-board the spacecraft occurring
from a long TDRSS outage (over thirty minutes in duration). Shorter
TDRSS outages will be handled by the excess bandwidth within the
multiple access (MA) link.

The router or up/down card extracts the application data from the
Ethernet header and checks the UPD/IP header fields and determines that
the data are external to the local network. The up/down card is
responsible for adding the link layer header/trailer artifacts. The data
are inserted into a new packet using an HDLC header frame and "bit
stuffed" to mask any application data patterns that could match the HDLC
one-byte flag pattern; this bit stuffing ensures that the HDLC flag byte
can be used as a frame delimiter. An OMNI Project study using three
current NASA missions (WIND, POLAR, and SOHO) concluded that the
bit-stuffing overhead averaged approximately 1% for the set of sample
science data. Additional details are presented in the OMNI paper
\[[^5]\] HDLC Link Framing for Future Space Missions.

The data are converted into a serial stream for transmission by the
antenna to the ground site. At the ground station antenna, the data are
received as a serial stream and transferred to a local router. The
router strips and processes the HDLC frame header/trailer fields (e.g.,
the frame sync and the CRC information), checks the UDP/IP header
information to determine the next destination for the data and begins
the routing process for an eventual transmission of the data to that
address. On the ground, the standard protocols are used to route the
spacecraft's housekeeping data to the control center or any other
desired location. On the ground, the routers continually monitor the
data quality by checking the HDLC/Ethernet CRC information as well as
the IP checksum and UDP checksum fields. The checks using these fields
ensure that only "good quality" data are transmitted; no "bad quality"
data would be transmitted to the end-user.

MDP is a reliable file transfer application built upon UDP and is one of
many current applications used to support a reliable multicast transport
(RMT) protocol. The Internet Engineering Task Force (IETF) has chartered
a working group, the RMT WG, to standardize reliable multicast transport
protocols for "one-to-many bulk data" transport. Additional details on
the roles, responsibilities, and charters of the RMT WG are contained on
the IETF web site \[[^6]\].

The OMNI group is currently prototyping an MDP based approach for a
reliable file transfer to support a space to ground transfer of the
on-board files. With MDP, minimal, or no, operator intervention is
required to downlink stored files. The OBC contains a storage management
(SM) task, which acts as the initiator of the data transfer when a file
is complete with its allotted science data. The SM task will put the
science data file into the MDP's "hot directory", which triggers MDP to
begin processing this file for downlink to the ground station. The MDP
application will segment the science files into one Kbyte packets; MDP
sends these 1-Kbyte packets to spacecraft's up/down card where the
identical processing as discussed previously is done. Once on the
ground, the data are routed using the original destination information,
as sent from the spacecraft. The real-time spacecraft data are forwarded
to the MOC and used to monitor and trend the health and safety of the
spacecraft and instruments. At the ground station, a variety of options
are available to disseminate the science data, including file storing
and forwarding, forwarding data as UDP packets to one central location,
or multicasting these UDP science packets, or any combination of these
options.

As one of the scenarios, the data initially could be transferred to a
client MDP task on the ground station. This MDP client task reassembles
the 1-Kbyte packets into a copy of the original file and maintains the
responsibility for ensuring data completeness by transmitting the
necessary acknowledgments or negative acknowledgments. This MDP client
task provides a post-processing option that enables this file to be
transferred to any required user or group of users. As an alternative
example, the real-time science data initially bypass the MDP client and
are automatically routed to all science users who need the data for
real-time displays. The data also are routed to the MOC (or any other
central location) where again the MDP client task reassembles the
1-Kbyte packets into the copy of the original file and performs the
necessary processing to ensure data completeness. These data routing
alternatives are examples of the ways in which the mission engineering
trade space is opened up through the use of standard networking
technologies and protocols.

#### Real-time TCP/IP commanding

Under the proposed approach, the spacecraft becomes a mobile node on a
network and becomes attached to that network successively at the
different ground stations. Advanced groups in private industry are
currently addressing a similar issue in relation to wireless networking
for cars, laptops, personal digital assistants (PDAs), and a multitude
of other electronic devices that will be mobile and require IP network
access. The IETF is currently working to establish the standards,
practices and applications for wireless networking for mobile nodes.

GPM is considering the proposed use of standard mobile IP protocols to
support the forward link required for a TCP/IP connection for real-time
command delivery. The router located at the station will have both
mobile IP and IP security protocols enabled to support the GPM mission.
The router will act as the foreign agent and advertise its availability;
this agent advertisement will be scheduled to occur several seconds
before the actual time that the forward link is scheduled to begin.
Within a matter of seconds and with a minimum of 2-3 packets, the
spacecraft and the MOC have established a tunnel by which data from the
MOC can be uplinked to the spacecraft. This uplink data consists of
command data, the MDP ACK list and the MDP NACK list. The command data
are used to continue spacecraft and instrument operations and to
maintain the health and safety of the mission. The NACK list is used to
request retransmission of missing data while the ACK list is used to
confirm the successful receipt of the data file at the MOC.

#### UDP/IP for commanding in the blind

The non-reliable data transport for command data is accomplished using a
connectionless UDP session. This is similar in concept to what is done
to support current mission with CCSDS blind commanding. In this
scenario, no mobile IP routing is established since by definition,
mobile IP implies a two-way connection. For blind commanding, it is
necessary to establish a forward link to the spacecraft to uplink some
type of data (commands). Instead of mobile IP and the agent
advertisement that would be performed by the ground station routers, the
MOC manually establishes a tunnel to a specific ground station router;
this would be analogous with the approach that the MOC's currently use
to establish a session with a specific station/antenna as part of the
pre-pass setups. The process can be automated to occur several minutes
before a station contact, or, in the event of a critical spacecraft
problem, the FOT can command it to occur when a station can communicate
with the spacecraft. Once the tunnel is established between the MOC and
the ground station, the command data are transmitted to the station in
UDP packets.

#### Fail-over and recovery scenarios

GPM has considered the use of backup ground stations to support the
mission in the event of a failure of the GPM-TDRSS communications link.
In the event of this contingency situation, the data delivery
requirements will be relaxed because of the somewhat infrequent station
contacts and the short station contact times, nominally on the order of
7-minutes. To fully support this scenario, the ground site(s) would only
need to have a standard router that supports both IP security and
mobility protocols. However, while the real-time data would not always
be flowing to all science users, the MOC would still provide the files
for the complete set of science products. During the contact, the MOC
would command the spacecraft to downlink the data at a rate up to 4
Mbps, depending upon the station supporting the ground contact. The
downlink rate needs to be sufficient to allow transmission of all
science and housekeeping files and real-time spacecraft data and to
ensure that NACKs/ACKs can be sent to the spacecraft before the end of
the contact. Whatever data are not successfully transmitted during the
contact will be resent at the next available station contact.

In this scenario, the GPM instruments continue to create the science
data and the OBC will create the files corresponding to the data and put
these files into the "hot directory". These files will reside on-board
the spacecraft until the spacecraft establishes a downlink with the MOC.
When the spacecraft has a downlink established, the MDP server
automatically begins transmitting the files.

### Future Efforts

The OMNI Project is tasked to complete several trade studies and
prototyping efforts over the next year to provide additional input on
how GPM could be designed to use a full IP implementation. The OMNI
Project has another effort underway to demonstrate and support basic IP
connectivity on the space link, mobile-IP routing, and a flight-based
MDP system, on the Communication and Navigation Demonstration on Shuttle
(CANDOS) mission, which is scheduled to be tested in the summer of 2002.
CANDOS has its own independent transceiver, which will be used to
directly contact either ground stations or TDRSS, independent of the
Shuttle communications system. These concepts are discussed in the paper
"Space Communications Demonstration Using Internet Technology"\[[^7]\].

### Conclusions

As previously described in this paper, the full use of an IP
implementation for a space mission can be done with minimum risk. A full
end-to-end IP approach provides simple and flexible communications that
manages all mission requirements. Technically, IP works fine in space;
there are no showstoppers. The only remaining concern is simply the
application of a standard engineering process with the engineering
solution space enlarged. IP enables advanced mission concepts (e.g.,
collaborative science) and allows better alignment with industry
standards and products. IP supports a simpler, yet more capable, overall
mission design and enables a simpler operations solution.

The OMNI Project has shown that a complete IP system not only can be
done but also has been done. The OMNI Project has successfully completed
several prototyping and demonstration activities using a total
end-to-end IP-based architecture. The OMNI Black Sea mission employed an
IP data communications approach to transmit live data during the
1999solar eclipse from the Black Sea. OMNI then followed up with the
UoSat-12 mission and the laboratory OMNI Flatsat development. The OMNI
Project is currently supporting the CANDOS mission. These approaches and
results also are documented on the OMNI website \[[^8]\]. The next
generation solutions are on the drawing board. The vision will include a
full end-to-end IP solution that will evolve to support advanced mission
concepts and profiles as depicted in Fig. 4, with levels of
interoperability for future missions that have not been available in a
cost-effective manner up to this time. This approach will make it easier
for a constellation of satellites to directly communicate with one
another, transferring data directly between the spacecraft rather than
downlinking data, processing it on the ground and then uplinking the
data. The use of commodity-level standard transport and routing
protocols will reduce development costs, shorten schedules, and allow
for earlier integration and test activities, thereby maximizing science
return per dollar invested.

![](media/image4.pct){width="4.125in"
height="3.2916666666666665in"}Figure 4 - Evolutionary Vision of IP for
Mission Applications

### Acknowledgments

Computer Sciences Corporation personnel, working for NASA's Goddard
Space Flight Center under contract GS-35F-4381G S-43981-G, developed the
IP mission concepts described in this paper. Goddard personnel also
provided support to identify and describe these concepts. The authors
specifically would like to thank Dave Everett, from GSFC Code 532, for
his leadership regarding GPM as a possible IP mission. The authors would
like to thank the NASA Earth Science Technology Office (ESTO), which
provided encouragement and funding to bring IP missions closer to
reality.

### *References*

[^1]: \[?\] Consultative Committee for Space Data Systems (CCSDS),
    \"Telecommand Part 2.1 Command Operations Procedures Issue 2\",
    CCSDS 202.1-B-2, June 2001

[^2]: \[?\] Jim Rash, Ralph Casasanta, Keith Hogie, "Global
    Precipitation Measurement (GPM) Spacecraft and Instrument Telemetry
    Data Flow and Interface Operations Concepts", unpublished, April
    2002

[^3]: \]?\] Jim Rash, Ed Crisuolo, Keith Hogie, Ron Parise, "MDP:
    reliable file transfer for space missions", Earth Science Technology
    Conference 2002, Pasadena CA*,* June 2002

[^4]: \[?\] <http://ipinspace.gsfc.nasa.gov/documents/>

[^5]: \[?\] Rick Schnurr, John Wesdock, Ed Criscuolo, Keith Hogie, Ron
    Parise, "HDLC link framing for future space missions", SpaceOps 2002
    Conference, Houston, Texas, October 9-12, 2002

[^6]: \[?\] <http://ietf.org/html.charters/rmt-charter.html>

[^7]: \[?\] D. Israel, K Hogie, R Parise, E Criscuolo, \"Space
    communications demonstration using internet technology\",
    International Telemetering Conference ITC/USA 2002, San Diego CA,
    October 2002

[^8]: \[?\] <http://ipinspace.gsfc.nasa.gov/>