Lloyd Wood

Cisco Systems, Inc., Bedfont Lakes, London, United Kingdom

William Ivancic

Glenn Research Center, Cleveland, Ohio

Alex da Silva Curiel and Chris Jackson

Surrey Satellite Technology Ltd., Guildford, Surrey, United Kingdom

Dave Stewart

Verizon Federal Network Systems, Cleveland, Ohio

Dan Shell

Cisco Systems, Inc., Richfield, Ohio

Dave Hodgson

Surrey Satellite Technology Ltd., Guildford, Surrey, United Kingdom

Adopting Internet Standards for Orbital Use

NASA/TM—2005-213881

November 2005

SSC05–IV–03
The NASA STI Program Office . . . in Profile

Since its founding, NASA has been dedicated to

the advancement of aeronautics and space

science. The NASA Scientific and Technical

Information (STI) Program Office plays a key part

in helping NASA maintain this important role.

The NASA STI Program Office is operated by

Langley Research Center, the Lead Center for

NASA’s scientific and technical information. The

NASA STI Program Office provides access to the

NASA STI Database, the largest collection of

aeronautical and space science STI in the world.

The Program Office is also NASA’s institutional

mechanism for disseminating the results of its

research and development activities. These results

are published by NASA in the NASA STI Report

Series, which includes the following report types:

• TECHNICAL PUBLICATION. Reports of

completed research or a major significant

phase of research that present the results of

NASA programs and include extensive data

or theoretical analysis. Includes compilations

of significant scientific and technical data and

information deemed to be of continuing

reference value. NASA’s counterpart of peerreviewed formal professional papers but

has less stringent limitations on manuscript

length and extent of graphic presentations.

• TECHNICAL MEMORANDUM. Scientific

and technical findings that are preliminary or

of specialized interest, e.g., quick release

reports, working papers, and bibliographies

that contain minimal annotation. Does not

contain extensive analysis.

• CONTRACTOR REPORT. Scientific and

technical findings by NASA-sponsored

contractors and grantees.

• CONFERENCE PUBLICATION. Collected

papers from scientific and technical

conferences, symposia, seminars, or other

meetings sponsored or cosponsored by

NASA.

• SPECIAL PUBLICATION. Scientific,

technical, or historical information from

NASA programs, projects, and missions,

often concerned with subjects having

substantial public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific

and technical material pertinent to NASA’s

mission.

Specialized services that complement the STI

Program Office’s diverse offerings include

creating custom thesauri, building customized

databases, organizing and publishing research

results . . . even providing videos.

For more information about the NASA STI

Program Office, see the following:

• Access the NASA STI Program Home Page

at http://www.sti.nasa.gov

• E-mail your question via the Internet to

help@sti.nasa.gov

• Fax your question to the NASA Access

Help Desk at 301–621–0134

• Telephone the NASA Access Help Desk at

301–621–0390

• Write to:

 NASA Access Help Desk

 NASA Center for AeroSpace Information

 7121 Standard Drive

 Hanover, MD 21076
Lloyd Wood

Cisco Systems, Inc., Bedfont Lakes, London, United Kingdom

William Ivancic

Glenn Research Center, Cleveland, Ohio

Alex da Silva Curiel and Chris Jackson

Surrey Satellite Technology Ltd., Guildford, Surrey, United Kingdom

Dave Stewart

Verizon Federal Network Systems, Cleveland, Ohio

Dan Shell

Cisco Systems, Inc., Richfield, Ohio

Dave Hodgson

Surrey Satellite Technology Ltd., Guildford, Surrey, United Kingdom

Adopting Internet Standards for Orbital Use

NASA/TM—2005-213881

November 2005

National Aeronautics and

Space Administration

Glenn Research Center

Prepared for the

19th Annual Conference on Small Satellites

cosponsored by the American Institute of Aeronautics and Astronautics

and Utah State University

Logan, Utah, August 8–11, 2005

SSC05–IV–03
Acknowledgments

We appreciate the efforts of the many collaborating participants in the Cisco router in Low Earth Orbit (CLEO) and

Virtual Mission Operations Center (VMOC) integration and testing. A detailed list of participants is given in the

NASA technical memo describing testing the orbiting router (NASA TM—2005–213556, May 2005).

Available from

NASA Center for Aerospace Information

7121 Standard Drive

Hanover, MD 21076

National Technical Information Service

5285 Port Royal Road

Springfield, VA 22100

Trade names or manufacturers’ names are used in this report for

identification only. This usage does not constitute an official

endorsement, either expressed or implied, by the National

Aeronautics and Space Administration.

Available electronically at http://gltrs.grc.nasa.gov
NASA/TM—2005-213881 1

Adopting Internet Standards for Orbital Use 

Lloyd Wood 

Cisco Systems, Inc. 

Bedfont Lakes, London, United Kingdom 

William Ivancic 

National Aeronautics and Space Administration 

Glenn Research Center 

Cleveland, Ohio 44135 

Alex da Silva Curiel and Chris Jackson 

Surrey Satellite Technology Ltd. 

Guildford, United Kingdom 

Dave Stewart 

Verizon Federal Network Systems 

Cleveland, Ohio 44135 

Dan Shell 

Cisco Systems, Inc. 

Richfield, Ohio 44286 

Dave Hodgson 

Surrey Satellite Technology Ltd. 

Guildford, United Kingdom 

Abstract 

After a year of testing and demonstrating a Cisco mobile 

access router intended for terrestrial use onboard the lowEarth-orbiting UK-DMC satellite as part of a larger merged 

ground/space IP-based internetwork, we reflect on and 

discuss the benefits and drawbacks of integration and 

standards reuse for small satellite missions. Benefits include 

ease of operation and the ability to leverage existing systems 

and infrastructure designed for general use, as well as reuse 

of existing, known, and well-understood security and 

operational models. Drawbacks include cases where 

integration work was needed to bridge the gaps in 

assumptions between different systems, and where 

performance considerations outweighed the benefits of reuse 

of pre-existing file transfer protocols. We find similarities 

with the terrestrial IP networks whose technologies we have 

adopted—and also some significant differences in 

operational models and assumptions that must be considered. 

Introduction 

On 27 September 2003, a Cisco Systems mobile access 

router was launched into low Earth orbit as a secondary 

experimental payload onboard the UK-DMC disaster 

monitoring constellation satellite built by Surrey Satellite 

Technology Ltd. (SSTL). The UK-DMC satellite’s primary 

mission is to provide Landsat-style, mid-resolution, remote 

sensing imagery. This satellite operates within the Disaster 

Monitoring Constellation (DMC) of small satellites built by 

SSTL for a number of collaborating countries. 

That Cisco router was able to be integrated into the UKDMC satellite because of engineering study work done 

previously that had adopted the Internet Protocol, IP, for 

communication with onboard network stacks, and which had 

built the ground station network around a Cisco router and 

standard serial interfaces using HDLC (ref. 1). 

The onboard router was tested as part of a wider 

internetworking experiment involving a wide range of 

organizations across civil, commercial and defense sectors. 

In June 2004, after lying dormant while the satellite’s 

primary payloads were commissioned and used, the router 

was used as the IP-compliant, space-based asset that was 

evaluated as part of the evaluation of the OSD Rapid 

Acquisition Initiative Net Centricity (RAI-NC) “Virtual 

Mission Operations Center” (VMOC) demonstration that 

took place at Vandenberg Air Force Base (ref. 2). 
NASA/TM—2005-213881 2

Cisco Router in Low Earth Orbit 

The Cisco router in Low Earth Orbit (CLEO) deployed 

onboard the UK–DMC satellite consists of two PC-104/Plusbased circuit boards: the PowerPC-based Cisco 3251 Mobile 

Access Router (MAR) processor card, and a four-port serial 

mobile interface card (SMIC). 

Although this mobile access router is capable of 

supporting 100 Mbps Fast Ethernet connections, there is no 

Ethernet onboard the UK-DMC satellite, and 8.1 Mbps serial 

interfaces are used to connect to other payloads (ref. 3). The 

onboard serial links are designed to match the use of an 

8.1 Mbps serial interface on a Cisco 2621 router receiving 

the output of the downlink from the modem in each ground 

station; the downlink is extended to each payload as required. 

The router cards flown (fig. 1) received some hardware 

modifications for the space environment: 

1. The cards were flow-soldered with lead-based, rather 

than tin-based, solder. Although tin is environmentally 

friendlier than lead, tin solder is particularly prone to 

growing “whiskers” in a vacuum, leading to shorted circuits. 

2. All terrestrial plastic connectors which would warp in 

temperature extremes were removed and replaced with 

point-to-point soldered wiring. Unused components around 

those connectors were removed. 

3. A large heatsink was attached to the main processor, 

and a brace conducted heat away to the payload’s aluminum 

chassis. 

4. Wet electrolytic capacitors with vents that would leak in 

a vacuum were replaced with dry capacitors. 

5. The clock battery was removed to avoid explosion and 

leakage; the router was later configured in orbit to use 

Network Time Protocol (NTP) in order to automatically 

learn the correct time from a ground-based server whenever 

it is powered up. 

The cards were mounted on an SSTL-designed 

“motherboard” that provided connectivity and power control. 

The completed assembly took up half a payload tray. The 

router assembly successfully survived full system flight-level 

qualification testing (vibration, vacuum and thermal cycling) 

on its first attempt. This included a temperature range of 

–60 to 35 °C and a vacuum of less than 1×10–3Pa. 

Total power consumption of the combined unit is 

approximately 10 W at 5 V. The router cards flown were not

modified in any way to provide increased radiation tolerance, 

and did not use space-qualified parts. The router software 

was also unmodified—a commercial release of Cisco’s IOS 

Internetworking Operating System software (12.2(11)YQ of 

September 2002) was flown. This use of commerciallyavailable hardware and software is unrestricted by ITAR 

regulations. 

Figure 1.—CLEO assembly mounted in rack tray. At back 

left: router card with heatsink brace in place. At front left: 

serial card is connected to payloads via half-width 

motherboard under cards. 

Access to configure CLEO on orbit via internetworked 

ground stations has been via the console serial port, telnet, 

secure shell (ssh), and secured web interfaces. As an 

experimental payload added to the UK-DMC satellite, the 

router is not connected directly to the satellite downlink. 

Instead, when testing the router during a ten-minute pass 

over a ground station, the onboard computers form a virtual 

star topology centered on the router, and frames are passed 

from the router to an onboard computer to be copied out to 

the downlink. 

While being tested during satellite passes over 

groundstations, CLEO has operated as expected on orbit, 

both in power draw and performance. Although CLEO is far 

less power-hungry than traditional 19 in. rack-mounted 

routers, the 10 W the assembly draws, combined with the 

10 W taken by the 8 Mbps S-band downlink when that is 

operational, forms a significant proportion of the UK-DMC 

satellite’s 30 W power budget. CLEO is powered off when 

not being tested in order to conserve available satellite power 

and battery life. 

UK-DMC Imagery and Networking 

The DMC small satellite constellation, within which the 

UK-DMC satellite operates, is a co-coordinated collection of 

ground and space assets owned by multiple organizations 

(ref. 4). Each of the sun-synchronous-orbiting DMC 

satellites, including the UK-DMC satellite, carries an optical 

imaging payload developed by SSTL to provide a minimum 

of 32 m ground resolution with a uniquely wide swath width 
NASA/TM—2005-213881 3

of over 640 km. (Some DMC satellites provide better 

resolutions.) All payloads use green, red and near-infrared 

bands equivalent to Landsat TM+ bands 2, 3 and 4. 

Images are stored onboard the UK-DMC in two PowerPCbased computers designed by SSTL, with 1 and 0.5 gigabytes 

of RAM respectively. These are the Solid-State Data 

Recorders (SSDRs). During passes over groundstations, 

images are copied as files to the SSTL mission operations 

center or partner groundstations via an 8.1 Mbps S-band 

downlink. 8.1 Mbps was chosen as it is the maximum rate 

supported by the serial interface on the Cisco routers to be 

used in the ground stations; this is also the rate at which the 

onboard router communicates via its serial links. There is 

also a low-rate 38.4 kbps downlink to provide satellite status 

telemetry when the high-rate downlink is not active, while 

commands are received via a low-rate uplink at 9600 bps. 

All links carry IP packets inside frame relay and HDLC 

encapsulation. This protocol encapsulation is an engineering 

choice made as a result of experience gained previously 

testing IP use with SSTL’s UoSAT-12 satellite (ref. 1). 

Payloads are given dedicated access to the downlink 

according to an uploaded schedule, and must flood the 

downlink with packets to transfer as much data as possible in 

the limited time available during a pass. Image transfer from 

satellite to ground station uses a custom rate-based UDPbased file transfer protocol designed and implemented by 

SSTL (ref. 5). This protocol gives smaller code footprint size 

and increased performance when compared to SSTL’s earlier 

implementation of the CCSDS File Delivery Protocol 

(CFDP), allowing more image data to be transferred during a 

pass, so that the entire contents of an SSDR’s memory can be 

downloaded, and the SSDR can then be turned off until its 

next use, in order to save power. 

The UK-DMC on-board computer (OBC) that controls the 

platform provided telemetry about the status of the satellite 

as a UDP broadcast stream from its IP stack. 

The ground stations belonging to SSTL and to the partner 

countries owning other satellites in the Disaster Monitoring 

Consortium are networked together using IP. PCs on each 

ground station Ethernet local area networks (LANs) run 

applications for dealing with satellite telemetry and images. 

The SSTL Mission Planning System 

To provide command and control across the disaster 

monitoring constellation, SSTL developed a secure 

distributed Mission Planning System (MPS) with distributed 

systems interfaces and a web-based end user interface. It is 

the responsibility of this MPS to: 

1. Receive and collate image requests for areas of interest. 

2. Perform orbit propagation. 

3. Prioritize and schedule acquisition opportunities based 

on request priorities and asset constraints. 

4. Automatically generate spacecraft and ground station 

command schedules to execute the image acquisition plan. 

Use of each country’s spacecraft and ground station in the 

DMC is planned through an independent MPS that holds its 

master schedule. Each MPS can communicate with its peers 

over the public IP Internet, via standard web services (the 

SOAP Simple Object Access Protocol), through secure 

encrypted tunnels (SSL secure sockets layer) and using a 

Virtual Private Network (VPN). With little modification, that 

web services interface was used to negotiate unplanned 

programmed image requests received in real-time from the 

General Dynamics VMOC software used during 

internetwork tests, using well-understood network standards: 

XML-RPC (remote procedure calls) and SOAP. The VMOC 

was allocated an appropriate priority so as not to interrupt 

commercial imaging. This live interaction between 

distributed planning systems was demonstrated successfully, 

with the UK-DMC MPS executing and delivering on VMOC 

image requests during and after testing and demonstrations at 

Vandenberg. 

Testing CLEO With VMOC 

The Cisco router in Low Earth Orbit (CLEO) project, 

funded by Cisco Systems, and the VMOC project, funded by 

the RAI-NC program, are separate but complementary in 

their shared use of the Internet Protocol, and the overlapping 

organizational groups involved in these projects gain mutual 

benefit from working together, as they are already 

compatible technically thanks to their shared use of common 

open standards. The VMOC and router testing was a 

collaborative experiment centered on the Air Force, the 

Army and NASA Glenn Research Center, and involving 

other organizations (ref. 6). NASA Glenn worked with Cisco 

to test the CLEO router under a mutually beneficial Space 

Act agreement. 

The Army and Air Force Space Battle Labs provided 

support and performed the overall metrics collection 

and evaluation as part of the OSD-sponsored VMOC effort. 

The VMOC demonstrations occurred “in the field” during 

1 to 13 June 2004, followed by a three-day demonstration 

during 14 to 16 June. Operators at the Vandenberg 

demonstration specified areas of the Earth, received satellite 

images and telemetry, and commanded the router. 

Field users relied on mobile routing to communicate across 

the Internet via a home agent at NASA Glenn’s headquarters 

in Cleveland, Ohio, to the Cisco router onboard the satellite 

via the supporting SSTL ground station (fig. 2). The 

addressing for SSTL’s existing ground station network 
NASA/TM—2005-213881 4

Figure 2.—Network topology for the Vandenberg demonstration. 

design is flat, with all ground stations numbered similarly, 

and addresses are translated to the outside world if necessary; 

support for mobile networking had to be added without 

disrupting either SSTL’s existing network operations or the 

primary imaging mission. 

Use of mobile routing provided CLEO with a static IP 

address that the VMOC could use to command the 

spaceborne router, entirely independent of the ground station 

currently visible to the satellite. CLEO can currently be 

accessed either via SSTL’s own ground station in Guildford, 

England, or via the Universal Space Network ground station 

in Poker Flat, Alaska, which replicates the SSTL ground 

station and modem use. 

Both the CLEO router and the IP-based VMOC software 

application were able to build upon SSTL’s adoption of IP 

and the IP-based infrastructure of the satellites and ground 

stations that was being built, and so could treat the satellites 

as nodes on a large IP-based network that seamlessly merged 

space and ground assets. The capabilities demonstrated here 

are evolutionary and desirable outcomes emerging from all 

parties adopting use of the Internet Protocol and being able to 

collaborate fully technically as a result; not as a result of any 

careful top-down long-term planning. 

Other Networking Demonstrations 

Further demonstrations of CLEO and VMOC have been 

held. 

On 5 November 2004, VMOC/MPS imaging request 

operations, using the SSTL ground station to task the UKDMC satellite, were demonstrated at Air Force Space 

Command Headquarters in Colorado Springs. 

On 18 November 2004, further demonstrations took place 

to the leadership of Air Force Space Command during its 

Commanders’ Conference in Los Angeles, CA. On 2 

December 2004, the Joint VMOC team performed a similar 

demonstration to leadership from the Air Staff and Joint Staff 

in the Washington, DC area. 

On 10 May 2005, a public demonstration of CLEO and 

VMOC was held at the AFEI Net-Centric Operations 

conference in Washington, DC, using the Universal Space 

Network Alaska ground station to access the router during 

two satellite passes. 

Lessons From Tests and Operation 

An Internet router is good for arbitrating fairly between 

nodes competing for access to a link in order to provide 

multiplexed access to connectivity. This is the dominant 

mobile routing 

Home Agent 

(NASA Glenn) 

Segovia 

NOC

“shadow” backup 

VMOC-2 

(NASA Glenn) 

UK-DMC/CLEO router 

high-rate passes over 

SSTL ground station 

(Guildford, England) 

primary VMOC-1 

Air Force Battle Labs 

(CERES) 

Internet 

mobile router 

appears to 

reside on 

Home Agent’s 

network at 

NASA Glenn 

secure Virtual 

Private Network 

tunnels (VPNs) 

between VMOC 

partners 

“battlefield operations” 

(tent and Humvee, 

Vandenberg AFB) 

low-rate UK-DMC passes over 

secondary ground stations 

receiving telemetry 

(Alaska, Colorado Springs) 8.1 Mbps downlink 

38400 bps 

downlink 

other satellite 

telemetry to 

VMOC 

UK-DMC 

satellite

CLEO onboard 

mobile access 

router 

secondary 

ground station 

9600 bps uplink 
NASA/TM—2005-213881 5

terrestrial Internet mode of operation. But when you own and 

manage your own computers onboard your own small 

satellite, and you have the power budget and accessibility 

concerns of a small satellite, a coarser-grained scheduling 

paradigm becomes much more attractive. You download data 

files from an onboard computer payload, and once it holds 

nothing more of interest you simply turn that computer off 

until it is next needed. Each computer is scheduled dedicated 

access to the downlink, and other engineering design 

decisions fall out from that. (Although scheduling of payload 

on times and access to the multiplexer is timetabled in 

advance, a “soft scheduling” model is used where the 

schedule is uploaded as a textfile to the platform’s onboard 

computer to interpret and follow, and the schedule for future 

events can be updated, altered and uploaded during any pass 

prior to events taking place.) 

The dominant terrestrial Internet mode of operation would 

be more attractive for large shared platforms (ISS, Hubble), 

or for payloads onboard permanently accessible 

geostationary satellites with higher bandwidth links. 

In the terrestrial Internet, immediate end-to-end 

connectivity is important; the ability to reach another 

endpoint in a timely fashion. This is what makes the instant 

clickability of the web and audio and video streaming 

possible. 

For a low-Earth-orbiting small satellite doing store-anddownload that is not backhauled via connectivity through a 

geostationary transponder to download its images 

immediately after taking them, pass utilization—getting as 

much out of each pass over each ground station and available 

download time—dominates. This desire to download as 

much data as possible, in the case of the UK-DMC imaging 

requirements, led to the development of a custom network 

stack using the rate-based UDP transfer protocol, SSTL’s 

Saratoga, in order to fill the downlink with image files and 

use the ten or so minutes of a pass as effectively as possible. 

The images were downloaded across a single link, the 

downlink, to a ground station, and no further. Saratoga’s 

design lacks congestion control algorithms, making it 

unsuitable for widespread Internet use between any endhosts 

—while the TCP suitable for Internet use would not make 

efficient use of the available pass, and would be more 

effective for arbitrating between multiple competing onboard 

computers using a multiplexing, rather than the scheduling, 

model outlined above. 

The image download model here is more analogous to e.g., 

application-level http proxy caching, where files are cached 

locally to avoid creating bottleneck-constrained long paths, 

and processed at the ground station cache, and then fetched 

on demand by terrestrial users. However, the end-to-end 

connectivity model still applies for real-time commanding 

(done by uploading scheduling files by TCP/IP, and for 

direct access to the onboard router) and for streaming 

telemetry (implemented as broadcast UDP from the satellite 

for the ground station LAN and repeated to select 

destinations via a unicast UDP reflector, but which could 

easily be implemented as multicast traffic.) 

Even if a LEO imaging satellite used a geostationary 

transponder to communicate with a ground station for 

extended periods of time, power and link efficiency concerns 

and the desire to switch between scheduled payloads based 

on need would still encourage the adoption of rate-based 

transfer protocols rather than TCP, given TCP’s well-known 

inefficiencies in adjusting to geostationary delays. 

Adoption of terrestrial network technologies means 

necessary adoption of widespread terrestrial security 

paradigms, which are fortunately well-understood. SSTL’s 

ground station LAN becomes an integral part of SSTL’s 

corporate network, and is now managed in the same way by 

the same people. Cisco PIX firewalls were used to set up a 

Virtual Private Network (VPN) between ground stations. 

Link-level encryption of the UK-DMC satellite link might 

also be considered necessary, but was not done. Future SSTL 

missions are considering link encryption. 

Given the limited pass times and availability of the 

onboard router, it was extremely helpful to have a groundbased testbed, combining the sister engineering model of the 

flight router with one of SSTL’s SSDRs (fig. 3). This rackmounted ground-based testbed is connected to a personal 

computer, which emulates the OBC. 

This testbed was constructed after launch for NASA Glenn 

to gain familiarity with the SSTL network environment and 

payloads, and to enable NASA Glenn to determine 

successful and safe configurations for the onboard router that 

would not interfere with SSTL’s primary mission. Working 

configurations were copied to the router in orbit once tested 

and validated on the ground-based testbed. This enabled 

effective use of the limited on-orbit testing time, enabling the 

ability to configure the on-orbit router essentially from 

nothing in few passes. 

Figure 3.—Ground-based testbed. On left: SSTL 

SSDR assembly. On right: router assembly. 
NASA/TM—2005-213881 6

Problems Encountered 

Technical problems encountered during testing and 

operating the router payload were relatively minor. 

While in the Vandenberg tent, the VMOC operators found 

that they were getting satellite passes finishing a couple of 

minutes earlier than expected—because their Solaris 

workstations were not configured to use the network to query 

time server using Network Time Protocol (NTP) to update 

their local clocks. When operating actual satellites, it is 

helpful to know the actual time. 

The UK-DMC satellite was temporarily unavailable 

between the testing campaign and the demonstration, due to a 

problem encountered by its on-board computer (OBC) 

requiring that computer to be reset. As a knock-on effect, 

SSTL had been rebooting its SSDRs daily to work around a 

problem with their serial driver software in coming out of 

pass-through mode to support the router, so access to the 

router was unavailable until both the OBC and SSDRs had 

been commanded to reboot on subsequent passes. Given 

SSTL’s soft scheduling methodology, rescheduling future 

events to take account of lost time is relatively 

straightforward. 

The OBC IP stack is written in-house by SSTL and 

considered experimental; the OBC can also run AX.25-based 

communications software (and the other DMC satellites do 

so, while their payload computers are IP based). This AX.25 

fallback use reflects SSTL’s long amateur radio experience 

and heritage. SSTL has moved the UK-DMC OBC back to 

AX.25 while debugging its internal software, removing a 

source of UDP-based telemetry during passes. 

The Universal Space Network Alaska ground station used 

to receive low-rate telemetry during the Vandenberg 

demonstration took some time to become fully operational; it 

was discovered that the high-speed downlink signal was too 

strong for and saturated the Comtech modem in use, 

requiring additional attenuation to be inserted. That 

attenuation was achieved by the Alaska RF chain working 

off right-circular polarisation, while the signal is left-circular 

polarised. Occasional multipath distortion resulting from this 

led to occasional poor link quality during passes over Alaska. 

The General Dynamics VMOC models satellite orbits, 

visibility and availability. However, for a satellite operated 

by a third party, this model turns out to be approximate at 

best, as the GD VMOC is unaware of other parties’ 

conflicting scheduling requirements or of power demands 

onboard the UK-DMC, or of details of imaging capabilities 

or storage limitations. The GD VMOC can only prioritise 

requirements that it is aware of, resolving conflicts between 

and for its own users. The VMOC’s assumptions were not 

always applicable to shared assets over which the VMOC 

does not have absolute control. A later iteration of the GD 

VMOC/SSTL MPS interface handed off more functionality 

to the autonomous SSTL MPS, moving away from hard 

absolute commanding by VMOC to a higher-level softer 

request negotiation model. 

The CLEO Cisco router performed entirely as expected. 

Ongoing Development of CLEO 

Testing of the CLEO router continues only when the UKDMC satellite is not otherwise tasked with its primary 

imaging mission. This testing relies on scheduled passes over 

the USN Alaska ground station to avoid using passes over 

SSTL’s own ground station whose opportunity cost would 

detract from SSTL’s normal operations and from the 

satellite’s primary mission. 

The CLEO Cisco router has been in space for over twenty 

months, and has been tested in orbit for over a year. CLEO 

has been powered up more than forty times for testing during 

passes over ground stations. There is interest in seeing how 

long this commercial, non-hardened computing device using 

non-space-qualified parts will last in low Earth orbit, and 

what total radiation dose it will tolerate. Several passes per 

week used for accessing and configuring the router can be 

accomplished. 

The success of CLEO, showing the use of Cisco’s IOS 

router software in orbit, has led to Cisco Systems taking the 

next step of porting IOS to a space-qualified radiationhardened processor in the PowerPC family: the BAE750. 

This would be used in a fully space-qualified embedded 

router. 

Conclusions 

The UK-DMC satellite demonstrates that handling satellite 

command and telemetry and data delivery based upon the 

Internet Protocol and related commercially-used standards is 

possible and can be successful. 

The CLEO experiment onboard the UK-DMC satellite has 

shown that a commercial off-the-shelf router can be adapted 

to and work in the space environment in low Earth orbit, 

building on commercially-used standards that had already 

been adopted for their benefits. The use of CLEO for mobile 

networking showed that mobile networking is a viable 

technology for networking across disparate and separate 

networks on two continents. 

The use of VMOC with the SSTL mission planning system 

shows that a high-level approach to exchanging data between 

complex systems, building on open standards, can allow 

independently-developed autonomous systems to 

interoperate with beneficial results. 

References 

1. Hogie, K., E. Criscuolo, and R. Parise, Using Standard Internet 

Protocols and Applications in Space, Computer Networks, 

special issue on Interplanetary Internet, vol. 47 no. 5, pp. 603–

650, April 2005. 
NASA/TM—2005-213881 7

2. Conner, B., L. Dikeman, V. Osweiler, S. Groves, D. 

Schoenfelt, P. Paulsen, W. Ivancic, E. Miller and J. Walke, 

Bringing Space Capabilities to the Warfighter: Virtual Mission 

Operations Center (VMOC), paper SSC04-II-7, Proceedings of 

18th AIAA/USU Conference on Small Satellites, Logan, Utah, 

August 2004. 

3. Cooke, D., R. Lancaster, and J. Buckley, Cisco router 3200 

UK-DMC payload interface control, SSTL internal technical 

document, May 2003. 

4. Hodgson, D., L. Boland, S. Mackin, P. Palmer, Y. Hashida, N. 

Bean, A. Brewer, H. Kadhem, C. Jackson, P. Davies, A. da 

Silva Curiel and M. Sweeting, Earth Observation 

Constellations with Automated Image Delivery, paper IAC-04-

IAA.4.11.1.05, Proceedings of IAC 2004, Vancouver, Canada, 

October 2004. 

5. Jackson, C., Saratoga file transfer protocol, SSTL internal 

technical document, May 2004. 

6. Ivancic, W., P. Paulsen, D. Stewart, D. Shell, L. Wood, C. 

Jackson, D. Hodgson, J. Northam, N. Bean, E. Miller, M. 

Graves and L. Kurisaki, Secure, network-centric operations of 

a space-based asset: Cisco router in Low Earth Orbit (CLEO) 

and Virtual Mission Operations Center (VMOC), NASA 

Technical Memorandum TM—2005-213556, May 2005. 
This publication is available from the NASA Center for AeroSpace Information, 301–621–0390.

REPORT DOCUMENTATION PAGE

2. REPORT DATE

19. SECURITY CLASSIFICATION

 OF ABSTRACT

18. SECURITY CLASSIFICATION

 OF THIS PAGE

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources,

gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this

collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson

Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)

Prescribed by ANSI Std. Z39-18

298-102

Form Approved

OMB No. 0704-0188

12b. DISTRIBUTION CODE

8. PERFORMING ORGANIZATION

 REPORT NUMBER

5. FUNDING NUMBERS

3. REPORT TYPE AND DATES COVERED

4. TITLE AND SUBTITLE

6. AUTHOR(S)

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

11. SUPPLEMENTARY NOTES

12a. DISTRIBUTION/AVAILABILITY STATEMENT

13. ABSTRACT (Maximum 200 words)

14. SUBJECT TERMS

17. SECURITY CLASSIFICATION

 OF REPORT

16. PRICE CODE

15. NUMBER OF PAGES

20. LIMITATION OF ABSTRACT

Unclassified Unclassified

Technical Memorandum

Unclassified

National Aeronautics and Space Administration

John H. Glenn Research Center at Lewis Field

Cleveland, Ohio 44135–3191

1. AGENCY USE ONLY (Leave blank)

10. SPONSORING/MONITORING

 AGENCY REPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration

Washington, DC 20546–0001

Available electronically at http://gltrs.grc.nasa.gov

November 2005

NASA TM—2005–213881

SSC05–IV–03

E–15252

WBS–22–258–70–03

13

Adopting Internet Standards for Orbital Use

Lloyd Wood, William Ivancic, Alex da Silva Curiel, Chris Jackson, Dave Stewart,

Dan Shell, and Dave Hodgson

Satellites; Internet; Protocol

Unclassified -Unlimited

Subject Categories: 62 and 17

Prepared for the 19th Annual Conference on Small Satellites cosponsored by the American Institute of Aeronautics and Astronautics

and Utah State University, Logan, Utah, August 8–11, 2005. Lloyd Wood, e-mail: lwood@cisco.com, Cisco Systems, Inc., Cisco

Systems Global Defense, Space and Security, Bedfont Lakes, London, United Kingdom; William Ivancic, e-mail:

wivancic@grc.nasa.gov, NASA Glenn Research Center; Alex da Silva Curiel, e-mail: a.da-silva-curiel@sstl.co.uk, and Chris Jackson,

e-mail: c.jackson@sstl.co.uk, Surrey Satellite Technology Ltd., University of Surrey, Guildford, Surrey GU2 7XH, United Kingdom;

Dave Stewart, e-mail: dstewart@grc.nasa.gov, Verizon Federal Network Systems, Cleveland, Ohio 44135; Dan Shell, e-mail:

dshell@cisco.com, Cisco Systems, Inc., Cisco Systems Government Services Unit, Richfield, Ohio 44286; and Dave Hodgson, e-mail:

d.hodgson@ssl.co.uk, Surrey Satellite Technology Ltd./DMC International Imaging, Guildford, Surrey GU2 7XH, United Kingdom.

Responsible person, William Ivancic, organization code RCN, 216–433–3494.

After a year of testing and demonstrating a Cisco mobile access router intended for terrestrial use onboard the lowEarth-orbiting UK-DMC satellite as part of a larger merged ground/space IP-based internetwork, we reflect on and

discuss the benefits and drawbacks of integration and standards reuse for small satellite missions. Benefits include ease

of operation and the ability to leverage existing systems and infrastructure designed for general use, as well as reuse of

existing, known, and well-understood security and operational models. Drawbacks include cases where integration work

was needed to bridge the gaps in assumptions between different systems, and where performance considerations outweighed the benefits of reuse of pre-existing file transfer protocols. We find similarities with the terrestrial IP networks

whose technologies we have adopted and also some significant differences in operational models and assumptions that

must be considered.