Internet Data Delivery for Future Space Missions[^1]

> James Rash Ralph Casasanta
>
> NASA Goddard Space Flight Center Computer Sciences Corporation
>
> Greenbelt, MD 20771 Lanham, MD 20706
>
> 301-286-9572 301-794-2076
>
> <james.rash@gsfc.nasa.gov> <rcasasan@csc.com>
>
> Keith Hogie
>
> Computer Sciences Corporation
>
> Lanham, MD 20706
>
> 301-794-2999
>
> [keith.hogie@gsfc.nasa.gov](mailto:james.rash@gsfc.nasa.gov)

***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 as the need increases
for more network-oriented mission operations. Another element of
increasing significance will be the increased cost effectiveness of
designing, building, integrating, and operating instruments and
spacecraft that will come to the fore as more missions take up the
approach of using commodity-level standard communications
technologies.**

**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.**

Table of Contents

I[ntroduction]{.smallcaps}

NASA/GSFC L[egacy]{.smallcaps} M[ission]{.smallcaps}
S[upport]{.smallcaps} I[nfrastructure]{.smallcaps}

NASA/GSFC N[ascom]{.smallcaps} T[ransition]{.smallcaps}

P[otential]{.smallcaps} N[ew]{.smallcaps} A[pproach]{.smallcaps}
F[or]{.smallcaps} GPM

F[uture]{.smallcaps} E[fforts]{.smallcaps}

C[onclusions]{.smallcaps}

A[cknowledgments]{.smallcaps}

[Biography]{.smallcaps}

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.
This paper describes how Internet technologies can facilitate new kinds
of space operations and support a vision for operations of earth and
space science missions. The application of Internet technologies in
space systems will increase mission flexibility. 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. Higher data rates, radio frequency (RF) versus optical, longer
distances, and cross-link communications are but a few of the issues.

Over the past 40 years, NASA has gone from developing and operating
custom solutions to adopting more commercial off-the-shelf (COTS)
products and industry standard solutions. There was a time when NASA
drove communication technology not only in space, but also on the
ground. 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 Legacy Mission Support Infrastructure

Operations and the necessary infrastructure for early NASA spacecraft
communications and control was very labor intensive, requiring a large
support staff to monitor and maintain the communications lines between
ground stations, control centers, and users. In addition to the support
staff, other factors had to be reflected in each mission's design, often
in form of unique application code. The first factor was the large ratio
of data rates for downlink (telemetry) and uplink (commanding). Another
factor stemmed from the problems typically encountered during the
integration and test (I&T) phase of the mission.

The Nascom group provided the support to develop, manage, and operate
the NASA communications backbone. The early paradigm for mission support
also required a dedicated (normally either 24x7 or 12x5) operations team
to monitor the spacecraft's health and safety and generate command loads
to support spacecraft operations and the instrument's science collection
activities.

Nascom Support

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. Using this type of a legacy system from the 1980s,
Nascom employed a staff of 70 programmers to develop and maintain the
communications systems. 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.

Figure 1. NASA Data Delivery Protocols -- Evolution and Throughput
Capacity Upgrades

As can been seen from Figure 1, as Nascom moved to more standard
protocols the throughput capacity increased. This allowed Nascom to
support missions with progressively higher data rates.

Flight Operations Team (FOT)

The FOT provides spacecraft support to ensure the health and safety of
both the instrument suite and the spacecraft, monitoring the spacecraft
for anomalies and generating command uploads on a daily basis to support
the spacecraft and science operations. An operations team was often
required to provide continuous, 24-hour operations for spacecraft
support. At best, the spacecraft required less than full-time support by
an operations team for either an 8x5 or 12x7 effort.

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. This was the only operational method to downlink data; the
reliable transfer of this data was accomplished by using various data
coding and forward error correction (FEC) schemes, such as convolutional
encoding or Reed-Solomon encoding. These methods were normally
sufficient to ensure reliable data delivery even with a noisy RF link,
albeit at the sacrifice of some throughput.

![](media/image1.pct){width="3.263888888888889in"
height="2.8569444444444443in"}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. The use of
the on-board SSR was a step forward for the spacecraft; however, the FOT
was still charged with the complex task of data management and playback
of the recorder's storage. 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. In addition to the overhead associated
with this version of NASA's legacy systems, each mission required unique
development to use the Nascom-standard 4800-bit block communications
protocol. Once the spacecraft transmitted the data, the mission-unique
ground-based systems would reassemble the data and begin the initial
level-zero processing, the purpose of which was to verify that all data
was received without errors; any problems would result in a request to
retransmit the stored data.

Another time-consuming role for the FOT was the formatting of command
loads and ensuring that the commands were reliably uplinked to the
spacecraft. While supporting legacy missions, the FOT employed various
methods to ensure command uplink occurred correctly. These methods were
normally predicated upon a form of command operations procedures (COP)
protocol \[[^2]\]. Possible variations of this protocol (a) allowed
commands to be received in sequence (normal commanding), (b) allowed
commands to bypass the sequence checks (bypass commanding), or (c)
allowed special HW commanding to reset the on-board computer (OBC) to a
"safehold" or cold-start state.

Command Uplink and Telemetry downlink differences

Under the legacy mission domain, a major concept was that the telemetry
downlink formats and protocols were different from those in the
corresponding command uplink, e.g., the COP protocols. 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.

![](media/image2.pct){width="3.3673611111111112in"
height="2.3881944444444443in"}Integration and Test (I&T) Phase Support

During the I&T phase of the mission, unique HW and SW were required to
completely check the instrument suite and the spacecraft. Also, the
testing process was repeated numerous times between instrument I&T and
then final spacecraft I&T. Typically, the instruments were all tested
independently at their distant development facilities, and then a whole
new test phase was conducted as each instrument was mated to the
spacecraft. With this "waterfall style" approach to I&T, interface
problems often are not detected and corrected until the end when the
cost of fixing the problem has increased dramatically.

NASA/GSFC Nascom Transition

As indicated in Fig. 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 on-board systems or the ground support system.

After the IP transition (which could be regarded as a watershed event),
Nascom only required a staff of 5 programmers to maintain the
communications system. Additionally, with the switch to an IP
ground-based communications system, Nascom was able to reduce the
operations staff by consolidating systems and responsibilities. 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. With the IP transition approach,
Nascom ultimately supported a dramatic increase in the overall data
throughput rates. However, the basic spacecraft and ground systems were
still based on the legacy concepts; NASA/GSFC had not begun to
incorporate the concepts of the 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.

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 \[[^3]\]. 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. However, 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). With the insertion of the IP suite, any previous unique
application code to support data transport could be removed since the
data transport layer is inherent within IP.

Additionally, the OMNI Project suggested the use of 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].
![](media/image3.pct){width="6.783333333333333in"
height="4.253472222222222in"}

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. These capabilities would assist the GPM
mission to pass a NASA/GSFC security audit and would support the ability
to more freely automate the commanding functions when an uplink pathway
is needed to command the spacecraft.

The data transfer mechanisms were further refined with the following
application controls:

-   On-board science data transport using UDP/IP packets

-   Data downlink, including the real-time spacecraft housekeeping data
    (in UDP/IP packets) and science data file transfer using the
    multicast dissemination protocol (MDP) application \[[^5]\],

-   TCP/IP for reliable real-time commanding and ack/nack confirmations

-   UPD/IP for commanding in the blind

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 outages resulting from TDRSS
handovers, or DSN zones of exclusion, 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
\[[^6]\] 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.

The GPM spacecraft may use the Multicast Dissemination Protocol (MDP)
applications task, which guarantees reliable data file delivery over a
variety of link types, either infrequent return links or full duplex
links.

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. This working group is
currently defining three protocol instantiations, which can be used to
support a reliable multicast:

-   NORM, the Nack Oriented Reliable Multicast protocol, which uses
    NACKS for reliability

-   TRACK, TRee ACKnowledgment based protocol, which uses a tree for
    controlling feedback and repairs

-   ALC, Asynchronous Layered Coding, which uses FEC based techniques
    and does not require any feedback

The OMNI group is currently using the MDP based approach for a reliable
file transfer to support a space to ground transfer of the on-board
files. However, the OMNI group is working with the RMT and will use one
of the three defined approaches listed above, whenever they become
standardized within the working group. Additional details on the roles,
responsibilities, and charters of the reliable multicast transport
working group are contained on the IETF web site [^7].

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 in the previous sub-section 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 to many
users, or any combination of these options.

File Store and Forward

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.

Real-time UDP packet transfer

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 an MDP client task reassembles
the 1-Kbyte packets into the copy of the original file. This MDP client
task performs the necessary acknowledgments or negative acknowledgments
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 different
locations, i.e., 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. The
spacecraft will respond to this advertisement and return authorization
packets, which are routed to the MOC for authentication. 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, not a TCP
byte stream as was done in the previous scenario.

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. To fully support this scenario, the ground site(s) would only
need to have a standard router that can support both IP security and IP
mobility protocols. However, in this failure scenario, the real-time
data would not always be flowing to all science users. The MOC would
still be capable of providing the files for the complete set of science
products. In the event of this failure scenario, a ground station would
have approximately 4- to 8-minutes of spacecraft contact, with an
average of approximately 7-minutes. 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 at the commanded downlink
rate.

Future Efforts

Complete security studies

Before any new mission is allowed access to the GSFC closed IP
Operational Network (IONet); the project must first complete a Risk
Assessment document that identifies the possible risks associated with
adding this control center to the network, as well as the mitigation
efforts to ensure data integrity and facility security. In addition to
this standard risk assessment document, any mission using a full-up IP
implementation would be required to complete an IP-in-Space Risk
Assessment, as required by the NASA/GSFC IT security organization. The
OMNI Project is actively working with the IT security organization and
several of the security studies are currently under way.

Each new mission at NASA that plans to use an IP-in-Space architecture
approach will be required to complete a corresponding risk assessment
security study and document their risks and mitigation activities. The
mission would submit these studies and documents to the NASA/GSFC IT
security organization for ratification and acceptance.

Prototyping issues

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 the full IP implementation approach.

The OMNI Project has another effort underway to support a flight-based
MDP system, which is scheduled to be tested in the summer of 2002 on the
Communication and Navigation Demonstration on Shuttle (CANDOS) mission.
This mission is part of a 16-day Shuttle flight, and has its own
independent transceiver, which will be used to directly contact either
ground stations or TDRSS, independent of the Shuttle communications
system. CANDOS will demonstrate basic IP connectivity on the space link,
mobile-IP routing, and reliable file transfer using MDP. The CANDOS
mission is discussed in more detail in the paper "Space Communications
Demonstration Using Internet Technology"\[[^8]\].

Another prototyping effort, by a separate group that develops flight
hardware, is in the planning phase to develop a space qualified onboard
LAN, including the up/down card/router; OMNI currently has scheduled
this activity to be completed later this year.

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.

Organizationally, IP can enable a new way of doing business. 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 successfully completed prototyping and
demonstration activities using a total end-to-end IP-based architecture.
The OMNI Black Sea mission to test the prototype IP mission during a
solar eclipse took place in 1999 \[[^9]\], followed by the UoSat-12
mission \[[^10]\], and the laboratory OMNI Flatsat development
\[[^11]\]. The OMNI Project is currently supporting the CANDOS mission.
These approaches and results are documented on the OMNI website
\[[^12]\]. The OMNI Project has shown that a complete IP system not only
can be done but also has been done. 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.
![](media/image4.pct){width="3.3625in" height="2.467361111111111in"}

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.

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

Biographies

![](media/image5.jpeg){width="0.8854166666666666in"
height="1.125in"}*James Rash -- Goddard Space Flight Center -- Mr. Rash
currently manages the Operating Missions as Nodes on the Internet (OMNI)
Project in the Advanced Architectures and Automation Branch at NASA's
Goddard Space Flight Center. He also leads development of formal methods
capabilities with respect to agent-based systems. Previous assignments
have included development of systems applying artificial intelligence
and evolutionary programming techniques.*

![](media/image6.bmp)*Keith Hogie -- Computer Sciences Corporation --
Mr. Hogie has an extensive background in designing and building
satellite data processing systems, control centers, and networks at
GSFC. He has developed ground data processing systems and control
centers for over 14 spacecraft over the last 25 years at NASA/GSFC, and
led the development of the NASA Internetworking Laboratory Environment
in 1990. He is the technical leader of the OMNI Project at GSFC where he
is applying his networking and satellite background to develop and
demonstrate new communication technologies for future space missions.*

![](media/image7.bmp)*Ralph Casasanta -- Computer Sciences Corporation
-- Mr. Casasanta has been involved in ground system engineering for the
SMEX and Triana missions since 1994; he is currently supporting the OMNI
Project by developing mission specific documentation for the use of IP
for total spacecraft and ground transport. Over the course of his
26-year career with Computer Science Corporation, he has been involved
in software development, test and systems engineering projects for both
NASA and the Federal Aviation Administration.*

[^1]: U.S. Government work not protected by U.S. copyright

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

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

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

[^5]: \[?\] Jim Rash, Ed Crisuolo, Keith Hogie, Ron Parise, "MDP:
    reliable file transfer for space missions", in press*,* June 2002

[^6]: \[?\] 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

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

[^8]: \[?\] 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

[^9]: \[?\] Ron Parise, Jim Rash, OMNI Black Sea mission to test
    prototype IP concepts, August 1999,
    <http://ipinspace.gsfc.nasa.gov/eclipse99/>

[^10]: \[?\] James Rash, Ron Parise, Keith Hogie, Ed Criscuolo, Jim
    Langston, "Internet technology on spacecraft", Space 2000
    Conference, Long Beach, Ca, Sep. 21, 2000

[^11]: \[?\] James Rash, Ron Parise, Keith Hogie, Ed Criscuolo, OMNI
    Phase III - Flatsat demonstrations, April 15, 2002,
    <http://ipinspace.gsfc.nasa.gov/flatsat/>

[^12]: <http://ipinspace.gsfc.nasa.gov/>