Using Internet nodes and routers onboard satellites
L. Wood,@ W. Ivancic,‡ D. Hodgson,+* E. Miller,& B. Conner,† S. Lynch,~
C. Jackson,* A. da Silva Curiel,* D. Cooke,* D. Shell,# J. Walke& and D. Stewart.%‡
This is a preprint of an article accepted for publication in the International Journal of Satellite Communications and Networking.
Copyright © 2007 John Wiley & Sons, Ltd. http://www.interscience.wiley.com/
@
Cisco Systems Global Government Solutions Group, Bedfont Lakes, London, England.
Surrey Satellite Technology Ltd, University of Surrey Research Park, Guildford, England.
+
DMC International Imaging, University of Surrey Research Park, Guildford, England.
&
General Dynamics Advanced Information Systems, California.
†
Air Force Space Battlelab, Schriever Air Force Base, Colorado.
~
Universal Space Network, Inc., Horsham, Pennsylvania.
‡
NASA Glenn Research Center, Cleveland, Ohio.
%
Verizon Federal Network Systems, Cleveland, Ohio.
#
Cisco Systems Government Services Unit, Richfield, Ohio.
Abstract: An Internet router was integrated into the UK-DMC remote-sensing satellite as
a secondary experimental payload. This commercial product has been orbiting in space
for over three years. We describe the integration of the router and satellite and the
successful on-orbit testing of the router, which took place using the Virtual Mission
Operations Center (VMOC) application as part of a larger systems internetworking
exercise. Placing this Cisco router in Low Earth Orbit (CLEO) onboard a small satellite is
one step towards extending the terrestrial networking model to the near-Earth space
environment as part of a merged space-ground architecture.
Key words: Internet, router, UK-DMC, satellite, HDLC, Frame Relay, IP, UDP
*
1. 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-class, mid-resolution,
remote sensing imagery. This satellite
operates within the growing Disaster
Monitoring Constellation (DMC) of small
satellites that has been built by SSTL for a
number of collaborating countries.1
The onboard router was tested as part of a
larger internetworking experiment involving a
wide range of organizations across civil,
commercial and defence sectors. In June 2004,
after lying dormant while primary payloads
were commissioned and used, the onboard
router acted as an Internet-Protocol compliant,
space-based asset that played a part in the
evaluation of the “Virtual Mission Operations
Center” (VMOC) demonstration that took
place at Vandenberg Air Force Base. VMOC
is one of the US Office of the Secretary of
Defense’s Rapid Acquisition Initiative Net
Centricity (OSD RAI-NC) pilot projects.2
The Cisco router was easily integrated into
the UK-DMC satellite due to previous
engineering work that had already adopted the
Internet Protocol, IP, for communication
between onboard IP network stacks and a
ground station network that relies on a Cisco
router with commercial serial interfaces.3
2. Extending the Internet to orbit
Satellites have been relaying Internet Protocol
(IP) traffic since the 1970s,4,5 but making an
orbiting satellite an active part of the Internet
is a more recent development. Several
previous experiments that have placed
Internet nodes on satellites are mentioned here.
In 1996, software uploaded to the STRV-1b
satellite, tested by NASA's Jet Propulsion Lab,
gave that satellite an IP address that could be
used for experimental communication.6
In 2000, a TCP/IP stack was uploaded to
SSTL’s UoSAT-12 satellite, and experiments
were run by NASA Goddard in collaboration
with SSTL as part of the OMNI (Operating
Missions as Nodes on the Internet) project.3,7
Correspondence to Lloyd Wood (lwood@cisco.com)
logical
system
flexibility
overall
functionality
physical
channel
flexibility
2
3
LINK LAYER:
onboard handling
and conversion of
MAC restricts choice
of waveforms.
NETWORK LAYER:
packet switching
to other payloads
increases overall
satellite functionality.
1
PHYSICAL LAYER:
bent-pipe amplification
gives flexible radio
channel.
3. Active network nodes on satellites
Traditionally, satellites do not possess routing
functionality. With a 'bent-pipe' geostationary
satellite, a satellite link is treated as just that: a
single link in each direction between ground
terminals. Although this ‘link’ consists of an
uplink followed by amplification, frequency
downshifting and a downlink returning the
carried signal to the ground, the single
satellite link budget combines all of these
steps. There is a strong codependency
between a signal's uplink and its downlink.
Often, even when demodulating or decoding
a signal to baseband onboard the satellite, the
relationship between the design of the uplink
and that of the downlink remains very strong.
This codependency can make for clarity of
design and engineering optimization when the
satellite transponder is used for its intended
purpose. This coupling between uplink and
downlink can also permit flexibility in use of
the single established radio channel through
both the uplink and downlink that results, e.g.
in allowing ground terminals to use turbo
coding across links using satellites deployed
before turbo coding had been developed,
without requiring any changes to the satellites.
However, a combined single link through a
satellite limits overall flexibility of link use,
terminal design, and thus the functionality of
networking services that can be offered by
available combined satellite capacity as a
system. On-board processing (OBP) can
decrease the uplink/downlink codependency.
Completely breaking this dependency can
increase the flexibility of use of available
uplinks, downlinks, payloads and terminals in
ways not envisaged by their original designers.
functionality
SSTL used experience gained from the OMNI
work by migrating from AX.25 towards IP
and adopting IP for operation of their Disaster
Monitoring Constellation (DMC) satellites,
launched from Plesetsk in Siberia. AlSAT-1,
the first of these satellites, was launched in
November 2002.8 The UK-DMC satellite,
which carries the Cisco router, was launched
alongside its sister satellites (BILSAT-1 and
NigeriaSat-1) in September 2003. The
Beijing-1 satellite joined the constellation in
October 2005. Further satellites are planned.
SpaceDev’s CHIPSat, which uses TCP/IP
for all communications with ground stations,
was launched for NASA from Vandenberg
Air Force Base in January 2003.9
Internet devices have also been used in
shirtsleeves environments in orbit by
astronauts. For example, in 2001, Cisco’s
SoftPhone was used on a laptop PC onboard
the space shuttle Atlantis, using voice over IP
(VoIP) to talk across a local Ethernet LAN
that was connected to the shuttle's custom
equipment that communicated via TDRSS
with NASA Johnson Space Center and the
ground phones there.10,11 The Russian
International Space Station (ISS) module
contains a terrestrial router and network.12
CCSDS protocols have been used by ESA
and NASA for communication with a variety
of orbiting and deep-space missions. The
CCSDS link protocols can optionally be made
to carry IP in a number of different ways.
Highest communications layer
supported by satellite payload
Figure 1: Flexibility/processing tradeoffs
2 of 18
Breaking this link dependency allows us to
consider the evolution of the middle of these
links: the satellite.
Introducing OBP with digital signal
processing (DSP) constrains the air interfaces
to predetermined waveforms, limiting the
flexibility of use of the radio channel. This
form of OBP can do e.g. onboard conversion
between different media access control (MAC)
link formats on the uplink and downlink, but
limits the uplink and downlink to use of those
chosen formats.
Leveraging use of OBP with frame and
packet processing can introduce system-level
logical flexibility, with more interaction
between onboard transponders and payloads,
compensating for the flexibility that has been
lost at the physical layer in the radio channels.
This tradeoff between radio and system
flexibility is shown in fig. 1.
Being either completely ‘bent-pipe’, fully
flexible in terms of waveforms that can be
amplified and repeated, or being networked
with smart payloads that are interconnected
for system flexibility, offers benefits. The
radio flexibility increases as we approach the
bent-pipe amplification; the system flexibility
increases as we approach networking.
We argue that a payload doing only onboard processing of only one type of
waveform limits both the physical radio
flexibility and future waveform choices that
ground terminals can make, as it is no longer
‘bent-pipe’, while also not supporting
networked
payloads.
Summing
the
independent frequency and system flexibility
curves suggests that limited, isolated, onboard processing is the least flexible of these
three approaches, as it constrains frequency
flexibility to a fixed waveform while not
embracing networking of payloads.
Increased onboard processing and switching
capabilities on computationally 'smarter'
satellites can introduce bridging and then
networking functionality within and between
payloads, and later between satellites with
intersatellite links, in an evolutionary
fashion.13,14 The satellites would contain
active network nodes that are linked together.
By operating a router onboard a satellite, we
have shown that on-board processing is
capable of packet switching and of
performing as an active network node. This
has led to interesting benefits for an overall
system for command and control, and for
integration with terrestrial networks, as shown
by our tests from Vandenberg Air Force Base.
4. Cisco router in Low Earth Orbit
The Cisco router in Low Earth Orbit (CLEO),
on the UK-DMC satellite, consists of just two
90 x 96 mm PC-104/Plus-based circuit boards:
• the Cisco 3251 Mobile Access Router Card
(MARC), based around a PowerPC
processor with a core speed of 210MHz;
• a Serial Mobile Interface Card (SMIC).
Although this mobile access router is capable
of supporting 100Mbps Fast Ethernet
connections, no Ethernet is used onboard the
UK-DMC satellite, and the four serial
interfaces on the SMIC card connect the
CLEO router to other onboard computers.15
These onboard serial links are designed to
match the use of a serial interface on a
commercial off-the-shelf Cisco 2621 router in
each ground station that receives the output of
the downlink from the modem at a maximum
rate of 8.1Mbps. The downlink is extended to
each payload as required.
The router cards flown as CLEO received
some simple hardware modifications for the
space environment:
1. The cards were flow-soldered with solder
including lead, instead of pure tin solder.
Although tin is considered more
environmentally friendly than lead, pure tin
solder is particularly prone to growing
crystalline “whiskers”. Tin whiskers
forming in free fall have led to shorted
circuits and the loss of satellites.16
2.All terrestrial plastic ‘push to fit’ connectors,
which would loosen during launch vibration
and 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 conducts heat away
to the aluminum chassis of the payload tray.
4. Wet electrolytic capacitors, with vents that
would leak in a vacuum, were replaced with
dry capacitors.
3 of 18
5. The clock battery was removed to avoid the
risks of explosion or leakage. The CLEO
router was later configured in orbit to use
Network Time Protocol (NTP) to learn the
time from a ground-based server whenever
the router is turned on. This made
timestamps of saved configuration files in
the router’s 32MB flash filesystem useful.
The two cards were mounted on an SSTLdesigned ‘motherboard’ that provides
connectivity and power control [fig. 2].
The completed CLEO assembly takes up
just half of an SSTL payload tray; the
modular design of SSTL satellites makes
adding or altering payloads straightforward.
This router assembly passed full systemlevel flight qualification testing (vibration,
vacuum and thermal cycling) at the first
attempt. This included a temperature range of
-60 to +35°C and a partial vacuum of less
than 1×10-3Pa pressure. Total power
consumption of the combined CLEO
assembly is approximately 10W at 5V.
The router cards flown were not modified in
any way for space to provide increased
radiation tolerance, and did not use any spacequalified parts.
The router software was also unmodified
for space
a commercial release of Cisco’s
IOS Internetworking Operating System
software (version 12.2(11)YQ, released
September 2002) was flown.
This use of commercially-available
hardware and software is unrestricted by US
ITAR (International Traffic in Arms
Regulations) export rules.
As the router is an experimental payload
added to the UK-DMC satellite, it is not
connected directly to a satellite downlink.
Instead, when testing the router during a pass
of up to twelve minutes over a ground station,
the other onboard computers form a virtual
star topology centered on the router, and
frames from the router are ‘passed through’
an onboard computer to be copied out to the
downlink.
Although CLEO is far less power-hungry
than traditional 19” rack-mounted routers, the
10W that the CLEO assembly draws,
combined with the 10W taken by the 8.1Mbps
S-band downlink when that is operational,
forms a significant fraction of the UK-DMC
satellite’s available 30W power budget.
CLEO is powered off when not being tested
during available passes in order to conserve
available satellite power and battery life.
While being tested during satellite passes
over groundstations and autonomously in
orbit, CLEO has operated as expected, in
power draw, performance, and reliability.
5. The ground-based testbed
Given the limited pass times and availability
of the onboard router, it was extremely
helpful to have a ground-based testbed
available.
This
rack-mounted
testbed
combines a sister engineering model of the
flight mobile router with one of SSTL’s
Solid-State Data Recorder computers [fig. 3].
The testbed is connected to a personal
computer, which emulates the on-board
computer controlling the satellite platform.
This testbed was intended for NASA Glenn to
gain familiarity with SSTL’s network
environment and custom payloads, and to
enable NASA Glenn to determine successful
and safe configurations for the onboard router
that would not interfere with SSTL’s preexisting use for the primary mission. NASA
Glenn personnel had helped Cisco Systems
define and develop its mobile router, so were
already extremely familiar with the router.
The testbed was constructed after launch.
Working configurations were copied to the
router in orbit after being tested and validated
for use on the ground-based testbed. This led
to effective use of limited on-orbit testing
time, enabling the ability to configure the onorbit router, essentially from nothing, in few
passes. Access to configure CLEO on orbit
via internetworked ground stations was
initially via its console serial port, which was
used to bootstrap configuration of telnet,
secure shell (ssh), and secured web interfaces.
6. UK-DMC imagery and networking
The UK-DMC satellite operates within the
Disaster
Monitoring
small
satellite
constellation, which is a co-coordinated set of
ground and space assets owned by multiple
organizations.17 The sun-synchronous-orbiting
DMC satellites each carry an optical imaging
4 of 18
payload, developed by SSTL, that provides a
minimum of 32m ground sample distance
(GSD) with a uniquely wide swath width of
over 640 km. (Some DMC satellites can also
provide better resolutions from other onboard
imagers.) These imagers use green, red and
near-infrared bands equivalent to Landsat
TM+ (Thematic Mapper) bands 2, 3 and 4.
Images are recorded onboard the UK-DMC
satellite in two SSTL-designed PowerPCbased computers, running at a core speed of
210MHz and with 1.0 and 0.5 gigabytes of
RAM each; similar technology to CLEO.
These are the Solid-State Data Recorders
(SSDRs). There is also a slower 80MHz
StrongArm-based SSDR, of older design,
controlling a GPS reflectometry experiment.18
During passes over groundstations, recorded
imagery data or reflectometry data is copied
as files to the SSTL mission operations center
or partner groundstations via an S-band
downlink providing an 8.1Mbps serial stream.
8.1Mbps was chosen because it is the
maximum rate supported by the serial
interface on the Cisco routers used in the
ground stations; this was adopted as the rate at
which onboard payloads communicate with
the ground station and the onboard router.
There is also a low-rate 38.4kbps downlink
to provide satellite status telemetry when the
high-rate downlink is not active. Commands
are received and software is uploaded via a
low-rate uplink at 9600bps [fig. 4].
All of these links carry IP packets inside
standard Frame Relay and HDLC (High-level
Data Link Control) 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 and an earlier Cisco
router in the Surrey ground station.3 Without
that previous work, done in cooperation with
NASA Goddard’s OMNI project, to lay down
use of commercial networking standards by
SSTL’s satellite and ground station network,
integration of a commercial router into the
satellite would have been far more difficult.
Payloads are given access to the downlink
according to an uploaded schedule planning
future events, and it is desirable to 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 Saratoga, a custom rate-based
UDP-based file transfer protocol designed and
implemented by SSTL.19 This protocol has a
far higher transfer rate than TCP’s design
permits. Its implementation has a smaller
code footprint size and faster performance
than an earlier onboard implementation of the
CCSDS File Delivery Protocol (CFDP) that
was written by SSTL and first used onboard
AlSAT-1. Use of Saratoga has increased the
amount of image data that can be transferred
during a pass, so that the entire contents of an
SSDR’s memory can be downloaded, and that
SSDR can then be turned off until its next use,
in order to conserve energy.
The on-board computer (OBC) that controls
the UK-DMC platform can provide telemetry
about the status of the satellite as a UDP
broadcast stream from its IP stack. This
telemetry stream is sent in-band down any
available high-rate or low-rate downlink. An
SSDR can repeat frames received from the
OBC onto a high-rate link in software to
enable this. The term 'OBC' dates from a time
when there was only one computer onboard
SSTL satellites.
The ground stations belonging to SSTL and
to the partner countries owning other satellites
in the Disaster Monitoring Consortium are
networked together using the Internet. PCs on
each ground station’s Ethernet local area
network (LAN) run applications for dealing
with satellite telemetry and images.
7. SSTL’s 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 each MPS to:
1. receive and collate imaging requests for
areas of user interest;
2. perform orbit propagation and calculate
satellite passes providing image acquisition
opportunities;
5 of 18
3. schedule
and
prioritize
acquisition
opportunities based on user 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 independent
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, the existing web
services interface was used to negotiate
unplanned programmed image requests
received in real-time from the General
Dynamics VMOC software that was used
during internetwork tests. This used widelyadopted network standards: XML-RPC
(remote procedure calls) and SOAP.
Live interaction between these systems was
demonstrated successfully, with the MPS at
SSTL’s ground station in Guildford executing
and delivering on VMOC image requests
during and after testing and demonstrations at
Vandenberg Air Force Base. The VMOC was
allocated an appropriate priority so as not to
interrupt established imaging commitments.
8. Virtual Mission Operations Center
The General Dynamics (GD) ‘Nautilus
Horizon’ VMOC software provides a
framework for the mission partners to define,
test, and field an IP-based command and
control (C2) system capable of supporting
secure distributed mission operations of any
IP-based platform or sensor.
Here, the VMOC provides a framework to
connect remote operators directly to an
orbiting space payload, using Internet
protocols to acquire satellite telemetry data
and imagery, dynamically task satellite
payloads, and undertake telemetry, tracking
and command (TT&C) of an on-orbit satellite
asset (the CLEO router) all through a userfriendly web-based interface requiring little
operator training [fig. 5].
With the satellite ground stations tied to the
Internet, a VMOC becomes the control
element that can orchestrate the tie between
the user and the spacecraft.
The functions of the GD VMOC include:
1. enabling system operators and data users to
be remote from ground stations;
2. verifying individual users and their
authorizations;
3. establishing a secure user session with the
platform;
4. performing user and command prioritization
and contention control; the ‘Nautilus’ name
reflects the multiple levels of tiered security
implemented;
5. applying mission rules and performing
command appropriateness tests.
6. relaying data directly to the remote user,
without human intervention;
7. providing a knowledge database, with the
capabilities to enable interaction with other,
similar, systems;
8. providing an encrypted gateway for access
by “unsophisticated” remote users of sensor
data.
9. Testing CLEO with VMOC
The CLEO project, funded by Cisco Systems,
and the VMOC project, funded by the RAINC program, are entirely separate, but are
complementary in their shared use of the
Internet Protocol.
The overlapping organizational groups
involved in these projects gained mutual
benefit from working together, as their work
was already compatible technically, due to
their shared use of common open standards.
The VMOC and router testing conducted at
Vandenberg Air Force Base was a
collaborative experiment centered on the Air
Force, the Army and NASA Glenn Research
Center, and involving many organizations,
including Cisco Systems and SSTL.
NASA Glenn worked with Cisco to test the
CLEO router under a mutually beneficial US
Space Act agreement. The Army and Air
Force Space Battlelabs provided support, and
performed their overall metrics collection and
evaluation of the utility of VMOC for
commanding space-based assets, as part of the
OSD-sponsored VMOC effort.
6 of 18
The VMOC evaluation occurred ‘in the field’
during 1-13 June 2004, followed by a threeday live demonstration during 14-16 June.
The Army Space Support Element Toolset
was deployed at the Vandenberg site.
Operators specified areas of the Earth,
received satellite images and telemetry, and
commanded the router [fig. 6].
VMOC users in the field relied on mobile
networking 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 in Guildford [fig. 7].
Both the CLEO router and the IP-based
VMOC software application were able to rely
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 active nodes on a large
IP-based network that seamlessly merged
space and ground assets.
The capabilities demonstrated here emerge
from the cooperation of all parts, and from the
whole created from those parts being greater
than the sum of the individual parts.
These desirable outcomes resulted from
shared adoption of the Internet Protocol
enabling full technical collaboration and
interaction.
The success of this demonstration was not
due to careful top-down long-term planning of
a single integrated system that would meet
agreed goals, but due to confidence that
interoperability of independent capabilities
based around common standards would itself
lead to success.
to be accessed from the Internet. Predictive
routing
knowing when a satellite will be
visible over a ground station, and thus which
spacecraft payloads are available and which
is used for remote
addresses are in use
access to the space-based part of the network.
Mobile networking, which shields an entire
local area network from address changes
using Mobile IP,20 was deployed with CLEO
to demonstrate a simplified method of direct
access to space-based assets. Mobile
networking makes it relatively easy to share
network resources and roam between different
IP networks, i.e. one does not have to
administer the entire ground station network
the spacecraft’s network connects to, or alter
its address space or routing.
As CLEO is a secondary, experimental,
payload, support for mobile networking had
to be added without disrupting either SSTL’s
existing network operations or the primary
imaging mission.
Use of mobile networking provides CLEO
with a permanent, static, public IP address
that the VMOC can use to command the
spaceborne router, separate from the ground
station currently visible to the satellite.
The CLEO router registers with the mobile
networking Home Agent at NASA Glenn’s
headquarters in Cleveland, Ohio, and can be
accessed indirectly via the Home Agent or
directly during a pass over a ground station.
CLEO has been controlled via both SSTL’s
own ground station in Guildford, England,
and the Universal Space Network (USN)
station near Poker Flat, Alaska, which
duplicates the modem use by SSTL.
10. Use of mobile networking
SSTL’s existing merged space-ground
architecture was designed around a single
ground station local area network as a flat
IPv4 network. All assets, both space- and
ground-based, appear to reside on the ground
station network.
All assets in each separate DMC ground
station use the same private address space. It
is necessary for the common addresses used
by each ground station to be manually
mapped to globally unique addresses, using
Network Address Translation (NAT), in order
11. Some problems during operations
Technical problems encountered while testing
and operating the router payload were
relatively small and surmountable.
‘Pass-through’ bridging software, needed
for frames from the router to reach the ground
as the router is not directly connected to the
satellite’s wireless links, was written and then
uploaded to the PowerPC SSDRs after launch.
Before this software was uploaded, the
onboard router was only reachable and shown
to work with console access via the OBC.
7 of 18
While in the field at Vandenberg, the VMOC
operators found that satellite passes over
ground stations were finishing a couple of
minutes earlier than expected because their
Solaris workstations had not been configured
to use the network to query a time server
using Network Time Protocol (NTP) to
update their local clocks. When operating real
satellites, it helps to know the real time.
The UK-DMC satellite was temporarily
unavailable between the testing campaign and
the demonstration, due to a problem
encountered by its platform 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 bridging 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. SSTL’s soft scheduling methodology
makes rescheduling future events by updating
an uploaded list of tasks to be carried out
relatively straightforward.
Soft configuration of CLEO could take
advantage of latent capabilities of the IOS
router software whose use had not been
anticipated earlier. For example, the onboard
topology for the router is such that when passthrough mode is active, the OBC and router
effectively share the serial interface and
address at the end of the uplink. When both
devices are active, only one should respond to
packets addressed to that interface. It was
straightforward to configure an access control
list on the router’s interface to limit its output
so that only the OBC would respond on the
shared interface. Testing this configuration
change on the ground-based testbed and then
repeating the commands on orbit during a
pass was simpler than recompiling and
uploading the OBC software would have been.
The OBC IP stack is written in-house by
SSTL and its implementation on the UKDMC satellite was considered experimental;
the OBC can also run third-party AX.25based communications software (and the
other DMC satellites have also done so, while
their payload SSDR computers are IP-based
and use Saratoga). This AX.25 fallback use
reflects SSTL’s long amateur radio
experience and heritage. Only one of the
AX.25 and IP/Frame Relay operating systems
is run onboard the UK-DMC OBC at a time.
These do share common HDLC framing.
The later Chinese Beijing-1 satellite is IP-only,
as is its OBC, and also has an X-band
downlink to support an extra high-resolution
camera. This downlink carries HDLC framing
at either 20 or 40 Mbps to a High Speed Serial
Interface (HSSI) on a Cisco 7204VXR router
in the ground station, following Hogie et al.3
SSTL has moved the UK-DMC OBC back
to AX.25 while debugging its internal
software, which removed a source of UDPbased telemetry during passes.
While returned to AX.25 use for
communication, the OBC is powered down
during high-rate passes to avoid inadvertently
responding to IP traffic that it would
misinterpret as AX.25 frames. This prevents
multiplexing of payload data with in-band
telemetry from the OBC. (Cisco routers
automatically discard frames that don’t match
specified Frame Relay headers; this and the
shared use of HDLC makes it easy for the
Cisco 2621 router to coexist with AX.25
equipment in each ground station.)
It may be useful to also carry AX.25 frames
within Frame Relay, to permit different types
of traffic to be clearly identified separately by
Frame Relay as outlined by Hogie et al.,3 so
that they can coexist within the same shared
infrastructure.
The Universal Space Network Alaska
ground station that was used to receive lowrate telemetry during the Vandenberg
demonstration took some time to make fully
operational.
It was discovered that the high-speed
downlink signal was too strong for and
saturated the Alaskan ground station’s
Comtech EF Data CDM-600 modem while 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. Multipath distortion resulting from
this led to experiencing poor link quality
during a number of passes over the Alaska
ground station. This problem is now well-
8 of 18
understood and needs to be addressed in
further ground station work.
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 General Dynamics 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 for and between 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 more functionality off to the
autonomous SSTL MPS, moving away from
hard absolute commanding by VMOC to a
higher-level softer request negotiation model.
Despite these minor problems with its
surrounding infrastructure, the CLEO onboard
router itself performed entirely as intended.
12. Further networking demonstrations
Other demonstrations of CLEO and VMOC
have been held, using as little as a laptop PC,
a web browser, and Internet connectivity.
On 5 November 2004, VMOC/MPS
imaging request operations, using the SSTL
ground station to task the UK-DMC satellite,
were demonstrated at Air Force Space
Command Headquarters in Colorado Springs.
Further demonstrations took place on 18
November 2004 to the leadership of Air Force
Space Command during its Commanders'
Conference in Los Angeles, California.
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, CLEO and VMOC were
demonstrated at the AFEI Net-Centric
Operations Conference in Washington, DC.
The USN Alaska ground station was used to
access the router during two satellite passes.
Access to CLEO using secure web access
via VMOC and the Alaska ground station was
shown during the IEEE Milcom conference
exhibition, from 18-20 October 2005.21
13. Moving GPS reflectometry data
CLEO interconnects the PowerPC SSDRs
with the slower StrongArm SSDR controlling
the onboard GPS reflectometry experiment18
[fig. 4]. If CLEO was not present, the SSDRs
would be interconnected by a redundant mesh
of links. As CLEO uses those connections,
CLEO acts as a ‘powered wire’ to allow the
StrongArm SSDR to talk to its peers.
The StrongArm-based SSDR is only fast
enough to output frames at a maximum of
around 3 Mbps. CLEO forwards data from it
to a PowerPC SSDR, from where the data can
be downloaded more rapidly with higher
wireless link utilization. The StrongArmbased SSDR is then turned off to conserve
energy. A reflectometry data transfer now
forms a small part of an image data transfer
pass, rather than needing a dedicated pass.
The normal operation for transferring GPS
reflectometry data to ground now involves
scheduling turning on CLEO for a period of
up to half an hour before a pass, to transfer all
data through CLEO to a faster SSDR. CLEO
and the StrongArm-based SSDR are then
powered down before the pass. This uses
autonomous onboard networking to show that
CLEO remains operational. This technique
has been carried out over thirty times.
14. Lessons from tests and operations
An Internet router is good for arbitrating
fairly between nodes and traffic competing for
access to a link in order to provide
multiplexed access to connectivity. This is the
dominant terrestrial Internet mode of
operation.
But when owning and managing all
computers onboard a small satellite, and with
the power budget and accessibility concerns
of a small satellite, a coarser-grained
scheduling paradigm becomes much more
attractive. Data files are downloaded from an
onboard payload, before switching attention
and link capacity to the next payload. Once a
data recorder holds nothing more of interest, it
is simply turned off until it is next needed.
9 of 18
On the DMC satellites, each computer is
scheduled with the aim of giving it dedicated
access to the downlink. Multiplexing of
frames sent from other payloads, such as the
low-rate telemetry generated by an IP-based
OBC, can also be carried out in software by
the computer driving the downlink. Although
scheduling of payload events is timetabled in
advance using ground station pass schedules,
a ‘soft scheduling’ model is used where the
schedule is uploaded as a textfile to the
platform’s onboard computer to interpret and
follow. The schedule for future events can be
updated, altered and uploaded during any pass
before the events take place.
Pass utilization
getting as much as
possible from each pass over a ground station
during the limited available download time
dominates the operating model for a lowEarth-orbiting small satellite doing store-andforward download. Pass utilization depends
on link utilization. (This assumes that the
satellite does not have connectivity through a
large-area geostationary transponder that
could relay image data as it is recorded.)
In the terrestrial Internet, immediate end-toend connectivity is important: the ability to
reach another endpoint in a timely fashion.
This is what makes possible the instant
clickability of the web and on-demand audio
and video streaming, as well as remote
connectivity via secure shell (ssh). For a
remote-sensing satellite whose images require
heavy computation to be processed and
adjusted, immediate end-to-end delivery of
payload data is less important.
End-to-end path utilization in the end-toend Internet model is lower than local link
utilization, and is dominated by Internet
congestion caused by competition. This
competition-oriented terrestrial Internet mode
of operation would be more attractive for
autonomous payloads on large shared
platforms, e.g. the International Space Station
or the Hubble telescope, or for payloads
onboard, interconnecting, or communicating
via always-accessible geostationary satellites
using shared high-bandwidth links.
The high asymmetry in the ratio of forward
downlink/back uplink link capacity for the
DMC satellites lies beyond the 50:1 ratio that
is considered a necessary minimum so that
congestion of TCP acknowledgments on the
back path does not limit TCP throughput on
the forward path. Along with TCP’s slowstart and congestion control algorithms, this
prevents TCP from effectively utilizing a
dedicated link.
The desire to increase link and pass utilization
and download as much imaging data as
possible led to replacing a network stack
implementing CFDP that was considered
large, slow and resource-hungry. A custom
network stack using a rate-based UDP transfer
protocol, Saratoga, was developed by SSTL in
order to fill the downlink with image files and
use the limited time of up to twelve minutes
in a pass as effectively as possible.19
The images are downloaded from the
satellite across a single link, the downlink, to
a ground station, and no further. Saratoga’s
simple rate-based design deliberately lacks
congestion control algorithms, making it
unsuitable for widespread Internet use
between any endhosts.
Although TCP has congestion control and is
suitable for Internet use, TCP cannot be
engineered to make efficient use of the
downlink during available limited pass times;
TCP’s slow start, probing the limits of link
capacity and backing off, are suboptimal for
link use dedicated to a single user. TCP would
be more effective for arbitrating access
between multiple competing onboard
computers, owned by different operators,
which use a multiplexing model of operation
rather than the overall shared scheduling
model outlined here.
Low-rate in-band telemetry frames from the
OBC, when copied over and multiplexed via
‘passthrough’ software on an SSDR, are
hardly competition to a Saratoga image
transfer from that SSDR that fills the majority
of the 8.1Mbps downlink.
The image download model here is more
analogous to e.g. application-level http proxy
caching, where files are cached locally to
avoid creating long, bottleneck-constrained,
paths. Images can be processed at the ground
station cache, and then fetched on demand by
terrestrial users. However, the end-to-end
connectivity model can still be used for:
10 of 18
1. 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 from the source. Telemetry
streams can have unreliable delivery; if a
packet describing the status of the satellite
is lost, there will be another one describing
much the same status along very soon.
2. real-time commanding, done by uploading
small scheduling files, and for direct access
to the onboard router;
A LEO imaging satellite could use a
geostationary transponder to download
imaging data to ground stations for longer
periods. This has been done via the European
Artemis satellite, which uses a Ka-band
transponder to relay data from the Envisat
satellite,22 and uses the SILEX (semiconductor
laser intersatellite-link experiment) payload to
receive data from SPOT-4.23
Even when downloading via a geostationary
satellite, power and link utilization efficiency
concerns, the desire to switch between
scheduled payloads based upon need, and
TCP’s well-documented inefficiencies in
adjusting to geostationary delays and high
bandwidth-delay products would encourage
the LEO satellite to adopt rate-based transfer
protocols and scheduled use rather than TCP
and competing use.
Adoption of terrestrial network technologies
means necessary adoption of widespread
terrestrial security paradigms, which are
fortunately well-understood. SSTL’s ground
station LAN becomes a part of SSTL’s
corporate network, and is 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
desirable, but has not been done. Later SSTL
missions are implementing link encryption.
15. Further developments with VMOC
Development of General Dynamics’ VMOC
software has continued to enhance system
interoperability and responsiveness, increase
situational awareness, and support automated
machine-to-machine interactions.
An enhanced VMOC, providing increased
Application Programming Interface (API)
functionality, has been prepared to support the
Air Force Space Battlelab’s SAFE (Space
Apportionment For Effect) demonstration. A
Space Apportionment VMOC can be used to
model conflicting mission requirements and
prioritize multiple user accesses to the
Mission VMOCs tied to the space
platforms.This “system of systems” approach
allows for centralized control with
decentralized execution within a net-centric
environment.
16. Further developments with CLEO
Testing of the CLEO router continues only
when the UK-DMC satellite is not otherwise
tasked with its primary imaging mission. This
ongoing testing has relied 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
normal operations and from the primary
imaging mission. Up to several passes per
week have been used to access and test the
CLEO router.
The CLEO router remains operational after
over three full years in space. CLEO has been
used in orbit for over twenty-seven months,
and has been turned on more than seventyfive times for use during passes over ground
stations and for reflectometry data transfer.
CLEO has had more than fifteen hours total
active use on orbit.
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. As a terrestrial product, CLEO
is not instrumented to measure space radiation
events or cumulative dosage. No anomalies
attributable to single-event upsets caused by
radiation have been noticed. CLEO is only
turned on for use for ground passes of twelve
minutes at a time, or for reflectometry data
transfers and testing for up to just over half an
hour, severely limiting its operational
radiation exposure. Commercial laptops
operated in manned environments in lower
11 of 18
orbits on Mir and the space shuttle have
encountered upsets after hours of use, as have
autopilots on commercial jet planes.24
Although CLEO was launched with IPv6
and IPsec functionality onboard in its
firmware, and the Cisco routers and firewalls
used in each DMC groundstation support
IPsec and are capable of running IPv6, IPv6
was yet to be enabled in space as we write.
The existing network infrastructure at SSTL
relies on IPv4, although this can be upgraded
to use IPv6 as well. Testing IPv6 and IPsec
with CLEO has already been examined in
detail via the ground-based testbed.
CLEO’s success in using IOS router
software in orbit has led to Cisco Systems
porting its IOS software to run on a spacequalified, radiation-hardened, processor in the
PowerPC family.25 This is a step towards a
hardened embedded router which could be
tested in geostationary orbit, or which could
be flown in high-altitude applications
demanding reliability. The hardware and
interfaces of such embedded routing
functionality would be very different from
that of either this porting experiment or the
CLEO demonstrator.
17. Further developments for satellites
With use of onboard processing and switching
of frames and packets, we envisage onboard
payloads being interconnected by smarter
satellite buses, where the platform provides a
network-level communications bus as well as
power and housekeeping. What such a bus
will be is an open question, with a number of
different approaches currently being pursued
by a number of organizations.
Elon Musk’s SpaceX has adopted Ethernet
as the bus onboard its rocket designs. This
could influence the bus designs of satellites
launched by those rockets, and how satellites
and payloads are activated after launch.26
Payloads that have different owners and
operators should be able to communicate with
other payloads onboard the same satellite to
increase their overall system-level flexibility.
With links between payloads on satellites
that already have uplinks and downlinks for
communications, switching decisions on
where to send data clearly have to be made.
Each satellite becomes a network (and, with
intersatellite links, part of a larger network),
and the boundaries between network
Autonomous Systems can lie between
payloads and within the satellite itself.
An initial unambitious step in the evolution
of satellites towards a fuller networking role
is to just stop thinking of a single satellite
transponder’s 'link budget' and to start talking
of the separate 'uplink budget' and 'downlink
budget'. Digital signal processing is just one
form of onboard processing. Onboard
processing can be incrementally extended in
order to support frame and packet processing,
which can then be leveraged to enable useful
interconnections between onboard payloads.
Conclusions
The CLEO experiment onboard the UK-DMC
satellite has shown that a commercial off-theshelf router can be adapted to and be used in
the space environment in low Earth orbit.
CLEO has demonstrated onboard IP
networking and has shown that mobile
networking can be used for communications
across disparate and separate networks via
ground stations in different continents.
The UK-DMC satellite has demonstrated
that handling satellite command and telemetry
and data delivery based upon the Internet
Protocol and related commercially-used
standards is possible and can be used to create
a successful operational service.
The Disaster Monitoring Constellation of
small satellites shows that IP-based data
delivery of remote sensing image files from
orbit can create a useful imaging service.
Use of VMOC with the SSTL mission
planning system shows that a successful highlevel approach to exchanging data between
complex systems can build upon open
standards based around IP to manage complex
applications involving satellites.
Acknowledgments
We greatly appreciate the combined,
coordinated and continuing efforts and the
ongoing
cooperation
of
the
many
collaborating commercial, civil and military
participants throughout the creation and
operation of CLEO, and its integration with
12 of 18
VMOC, testing and demonstrations. A list of
participants in the test campaign is given in
the NASA technical memorandum that
describes testing CLEO and VMOC.27
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
C. Underwood, S. Machin, P. Stephens, D.
Hodgson, A. da Silva Curiel and M. Sweeting,
Evaluation of the Utility of the Disaster
Monitoring Constellation in Support of Earth
Observation Applications, paper IAA-B51501, 5th IAA Symposium on Small Satellites
for Earth Observation, Berlin, Germany, April
2005.
B. Conner, 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, 18th AIAA/USU Conference on
Small Satellites, Logan, Utah, August 2004.
K. Hogie, 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.
V. G. Cerf, Packet satellite technology
reference sources, Internet Engineering Task
Force RFC 829, DARPA, November 1982.
K. Seo, J. Crowcroft, P. Spilling, J. Laws and
J.
Leddy,
Distributed
Testing
and
Measurement across the Atlantic Packet
Satellite Network (SATNET), SIGCOMM ’88,
Palo Alto, California, August 1988.
R. Blott, and N. Wells, The Space Technology
Research Vehicles: STRV-1a, b, c and d, 10th
AIAA/USU Conference on Small Satellites,
Logan, Utah, September 1996.
C. Jackson, C. Smithies and M. Sweeting,
NASA IP demonstration in-orbit via UoSATInternational
12
minisatellite,
52nd
Astronautical Congress, Toulouse, France,
October 2001.
A. da Silva Curiel, L. Boland, and J. Cooksley,
et al., First results from the Disaster
Monitoring Constellation (DMC), paper IAAB4-1302, 4th IAA Symposium on Small
Satellites for Earth Observation, Berlin,
Germany, April 2003.
K. Rubio, J. Janicik, and J. Szielenski,
CHIPSat’s TCP/IP mission operations
architecture
elegantly simple, paper
SSC02−IV−4, 16th AIAA/USU Conference on
Small Satellites, Logan, Utah, August 2002.
10. Cisco Systems, The first 90,000 miles are tollfree, company profile, Cisco Systems,
September 2002.
11. W. Jackson, Astronauts call home via shuttle
VoIP link, Government Computing News, vol.
20 no. 5, 5 March 2001.
12. W. Ivancic, T. Bell, and D. Shell, ISS and
STS commercial off-the-shelf router testing,
NASA Technical Memorandum TM-200221130, April 2002.
13. L. Wood, A. da Silva Curiel, J. Anzalchi, D.
Cooke and C. Jackson, Slot clouds: getting
more from orbital slots with networking,
paper IAC-03-U.4.07, 54th International
Astronautical Congress, Bremen, Germany,
September 2003.
14. D. Floreani and L. Wood, Internet to orbit,
Cisco Systems Packet Magazine, vol. 17 no. 3,
pp. 19-23, third quarter 2005.
15. D. Cooke, R. Lancaster, and J. Buckley, Cisco
router 3200 UK-DMC payload interface
control, SSTL internal technical document,
May 2003.
16 Hughes Electronics Corporation, Launches of
Hughes HS 601 satellites ready to resume,
press release, Hughes Electronics Corporation,
11 August 1998.
17. D. Hodgson, 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, 55th
International
Astronautical
Congress,
Vancouver, Canada, October 2004.
18. S. Gleason, S. Hodgart, S. Yiping, C.
Gommenginger, S. Mackin, M. Adjrad and M.
Unwin, Detection and Processing of
bistatically reflected GPS signals from low
Earth orbit for the purpose of ocean remote
sensing, IEEE Transactions on Geoscience
and Remote Sensing, Vol. 43, No. 6, pp.
1229-1241, June 2005.
19. C. Jackson, Saratoga file transfer protocol,
SSTL internal specification, May 2004.
20. C. Perkins, ed., IP Mobility Support for IPv4,
Internet Engineering Task Force RFC 3344,
August 2002.
21. L. Wood, D. Shell, W. Ivancic, B. Conner, E.
Miller, D. Stewart and D. Hodgson, CLEO
and VMOC: enabling warfighters to task
space payloads, unclassified track, IEEE
MILCOM 2005, Atlantic City, New Jersey,
October 2005.
22. P. A. Dubcock, F. Spoto, J. Simpson, D.
Spencer, E. Schutte and H. Sontag, The
13 of 18
23.
24.
25.
26.
27.
Envisat satellite and its integration, ESA
Bulletin no. 106, June 2001, pp. 26-45.
T. Tolker-Nielsen and G. Oppenhauser,
In-orbit test result of an operational optical
intersatellite link between ARTEMIS and
SPOT-4, Free-Space Laser Communication
Technologies XIV, Proceedings of SPIE, vol.
4635, April 2002, pp. 1-15.
C. Dyer, Radiation Effects on Spacecraft and
Aircraft, Space Weather Workshop, ESTEC,
Netherlands, December 2001.
D. Buster, Towards IP for space based
communications systems; a Cisco Systems
assessment of a single board router,
unclassified track, IEEE MILCOM 2005,
Atlantic City, New Jersey, October 2005.
Payload User’s Guide – Falcon Launch
Vehicle, SpaceX specification, p. 12, 2nd
revision, October 2004.
W. Ivancic, 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 spacebased asset: Cisco router in Low Earth Orbit
(CLEO) and Virtual Mission Operations
Center
(VMOC),
NASA
Technical
Memorandum TM-2005-213556, May 2005.
Author biographies
Lloyd Wood (lwood@cisco.com) is a Chartered
Engineer and serves as a space initiatives manager in the
Global Government Solutions Group at Cisco Systems.
Lloyd has responsibility for and coordinates all testing
with Cisco's first router in orbit. He spent some years
modifying IOS, Cisco's router software, and
contributing to the Internet Engineering Task Force.
Lloyd holds masters degrees in electronic and electrical
engineering and in satellite communication engineering.
Lloyd gained his doctorate from the Centre for
Communication Systems Research at the University of
Surrey, where he researched internetworking with
satellite constellations.
William Ivancic (wivancic@grc.nasa.gov) is a senior
research engineer at NASA’s Glenn Research Center,
where he directs research into hybrid satellite/terrestrial
networking, space-based Internet, and aeronautical
Internet. Will is leading a research effort to deploy
commercial-off-the-shelf (COTS) technology into
NASA missions, including the Space Exploration
Initiative, the Airspace Systems Program and the
Aviation Safety Program. Will holds BS and MS
degrees in electrical engineering.
David Hodgson (d.hodgson@dmcii.com) is the
Managing Director of DMC International Imaging Ltd.
Prior to this, for twelve years he held various roles at
Surrey Satellite Technology Ltd, focused on Information
Systems. He was the project manager responsible for the
DMC satellite constellation ground planning and
processing. David holds a BSc in Computing from the
University of Surrey.
Eric Miller (eric.miller@gd-ais.com) is General
Dynamics’ Vandenberg Operations Manager, with over
twenty years of space operations experience. He leads
the Virtual Mission Operations Center (VMOC) team.
Eric holds BS and MS degrees in electrical engineering.
He has been published by the Applied Computational
Electromagnetics Society and the IEEE Antennas and
Propagation. Journal.
Brett Conner (brett.conner@afosr.af.mil) was Chief
Scientist, Air Force Space Battlelab, Schriever Air Force
Base, Colorado. While at the Battlelab, Brett was the
RAI-NC Project Manager for the VMOC initiative.
After a year on assignment to the Pentagon, Brett is
program manager for metals research at the Air Force
Office of Scientific Research. Brett holds a BS in
physics from the University of Missouri. He holds MS
and PhD degrees in materials engineering from
Massachusetts Institute of Technology.
Scott Lynch (lynch@uspacenet.com) is a Systems
Engineer for Universal Space Network, Inc. He
previously gained a decade of experience of Electronic
Warfare Systems with the US Navy. Scott began
working with IP technology for commercial ground
station implementation with the CHIPSat mission in
2003, and has continued this with NASA Goddard and
Glenn for the UK-DMC satellite. Scott and the
Universal Space Network engineering team are working
to implement IP satellite communications across the
Universal Space Network ground network in support of
further IP-enabled missions.
Chris Jackson (c.jackson@sstl.co.uk) is a principal
engineer responsible for ground systems and operations
at Surrey Satellite Technology Ltd. Chris has worked at
SSTL for over twelve years, where he has been involved
with flight and ground software systems, space-toground protocols and flight operations for over twenty
space missions.
Alex da Silva Curiel (a.da-silva-curiel@sstl.co.uk) is
the technical director for the Surrey Satellite
Technology Ltd group, where he has been involved in
more than twenty small satellite missions in a variety of
engineering and management roles. He is a member of
the ESA/CNES Small Satellite Systems and Services
technical committee, a member of the IAF small satellite
technical committee, and the UK lead for the ISO
working group on Satellite Operations and Ground
systems. Alex holds a masters degree in satellite
engineering from the University of Surrey, and has
published more than fifty papers on aspects of satellite
communications and mission design.
David Cooke (d.cooke@sstl.co.uk) is a senior design
engineer at Surrey Satellite Technology Ltd, where he
designs onboard data-handling architectures and
subsystem modules. Dave holds a BEng degree in
electronic engineering.
14 of 18
back left: router card with heatsink brace.
right: UK-DMC battery charge regulator
front left: serial card interfaced to payloads via half-width motherboard.
Figure 2: CLEO assembly in payload tray
left: SSDR assembly.
right: router assembly.
Figure 3: Ground-based testbed
15 of 18
384kbps CANbus
interconnections
between payloads
9.6kbps
uplink
SSDR 0
low-rate
RX1
CANbus to serial conversion for
router console port access via OBC
low-rate
RX0
SSDR 1
PowerPC
PowerPC
Imaging
Imaging
38.4kbps
for low-rate
telemetry
38.4kbps
downlink
On-Board
Computer
low-rate
TX
SMIC
serial
MARC
PowerPC
SSDR 2
StrongArm
CLEO
reflectometry
high-rate
TX0
high-rate
TX1
8.1Mbps
downlink
9600bps
38400bps
8.1Mbps
Figure 4: Logical connectivity of the UK-DMC satellite’s internal onboard network
Dan Shell (dshellwireless@gmail.com) is a network
architect active in IP mobility consulting and research.
He is currently the primary investigator for a
Congressionally-funded research project using
aerostats and IP mobility. In twelve years at Cisco
Systems, Dan was a Technical Leader in the
Government Services Unit, where he led development
of mobile networking and drove development of
Cisco's mobile access router. Dan was active in IP
over satellite research with NASA Glenn Research
Center as part of Cisco’s Space Act agreement with
NASA, and supported other US federal agencies in
deploying network solutions.
Jon Walke (jon.walke@gd-ais.com) is a General
Dynamics Senior Systems Engineer, with over twenty
years of experience in systems design and integration.
He leads the Virtual Mission Operations Center
development and integration efforts for General
Dynamics. Jon holds BS and MS degrees in electrical
engineering and is a certified Network and Systems
Administrator.
David Stewart (dstewart@grc.nasa.gov) is a
communication engineer at Verizon. David specializes
in RF and wireless communication networks. For the
past six years, David has supported the development
and deployment of a mobile-router testbed at NASA
Glenn, as well as deployment of early-field-trial
aeronautic and maritime mobile networks. David
holds a BEE degree in electrical engineering.
16 of 18
a. Live UK-DMC telemetry relayed from ground stations during passes and recorded.
b. Graphical area selection and tasking interface.
Figure 5: Screenshots of the VMOC client web browser user interface
17 of 18
Figure 6: Space Support Element deployed ‘in the field’ at Vandenberg Air Force Base
UK-DMC
satellite
low-rate UK-DMC passes over
secondary ground stations
receiving telemetry
(Alaska, Colorado Springs)
38400bps
downlink
CLEO onboard
mobile access router
8.1Mbps downlink
9600bps uplink
other satellite
‘battlefield operations’ telemetry to VMOC
(tent and Humvee,
Vandenberg AFB)
Segovia Network
Operations Center
secondary
ground station
Internet
secure Virtual
Private Network
tunnels (VPNs)
between VMOC
partners
primary VMOC-1
Air Force Battle Labs
(CERES)
UK-DMC/CLEO router
high-rate passes over
SSTL ground station
(Guildford, England)
‘shadow’ backup
VMOC-2
(NASA Glenn)
mobile routing
Home Agent
(NASA Glenn)
mobile router
appears to
reside on
Home Agent’s
network at
NASA Glenn
Figure 7: Network topology for the Vandenberg demonstration
18 of 18