Download CANDOS-Präsentation - Institut für Informatik

Julius-Maximilians-Universität Würzburg
Lehrstuhl für Informatik VII
Prof. Dr. Klaus Schilling
Seminar WS 03/04
„Satellite-Based Internet“:
The CANDOS-Project
Carsten Krüger
27.11.2003
Content
• CANDOS Overview
• Mission Objectives
• Space Network & Ground Network
• The Low Power Transceiver (LPT)
• Protocols
• Experiments
• Conclusions
1. CANDOS Overview
1. CANDOS Overview
• Flew as a hitchhiker payload on Columbia
STS-107
• Launched on January 16, 2003
• Completed its mission on January 31, 2003
• Part of FREESTAR (Fast Reaction
Experiments Enabling Science, Technology
Applications, and Research)
• End-to-end data flow architecture based
on standard IP protocols
• Used off-the-shelf commercial hardware
• Scheduled and operated as if it was a
free flying satellite
2. Mission Objectives
• Demonstration of the Low Power Transceiver
(LPT)
• Perform Internet-in-space experiments
• Communication over
Space Network
(SN) (TDRSS) and
Ground Network (GN) (Ground stations)
• GPS Navigation
• Space-Based Range Safety
• On-Orbit Reconfiguration
3. Space Network &
Ground Network
3. Space Network &
Ground Network
• Passes were possible when the LPT was the
primary objective in the Shuttle attitude
timeline
• Typical links:
2 kbps up / 128 kbps down
to ground stations
32 kbps forward / 128 kbps return
through TDRSS
• CANDOS communications links used the
standard IP protocol and HDLC data framing
• Each ground station was connected to the
NASA Closed IONet
3. Space Network &
Ground Network
• Routers: standard Cisco 2621 units
• Each router was configured to be a Mobile
IP foreign agent (standard Cisco IOS
configuration option)
• Ground Station Router Interface Device
(GRID): allowed the RF links to appear as
serial port connections between the flight
hardware and a ground station router
serial port
• GRID provided data scrambling and descrambling for all links
3. Space Network &
Ground Network
SN & GN Communications
• 97 SN events were supported for
SN Communications
approximately 52 hours of total
time
TDRSS SSA
• 91 successful events (94%)
TDRSS MA
• 4 partially successful events (4%)
GN Communications
• 2 unsuccessful events (2%)
(Linux OS crashed / hung up;
MILA
conflict between blind commands
and background scripts for
Wallops
configuring the RF module)
Total Passes
•
•
•
•
37 GN events were supported for a total of 6 hours
28 successful GN events (76%)
8 partially successful GN events (21%)
1 unsuccessful GN event (3%)
Passes
52
45
16
21
134
4. The Low Power
Transceiver (LPT)
• A multi-band, multi-channel, low
power, lightweight, low cost,
modular, software programmable,
navigation and communication
transceiver prototype.
• Developed by NASA / Goddard Space
Flight Center (GSFC) and
ITT Industries
• Uses three S-band antennas and one L-band
(GPS) antenna for communications
• Forward link frequency: 2106.4 MHz (S-Band)
• Return
link frequency: 2287.5 MHz (S-Band)
4. The Low Power
Transceiver (LPT)
• Based on PC-104 form factor
• Allows the flight unit to have an optional
233MHz 686 processor with 256 MB of RAM
and 144 MB of flashdisk
• Running Red Hat Linux 6.1 (2.2.12 kernel)
• Processes GPS signals using the civilian
C/A codes
• Status information logged to ‘syslog’ and
other files for later retrieval
• RS-422 synchronous serial interface
between CPU and LPT
4. The Low Power
Transceiver (LPT)
3” S-Band
Transmit
Antenna
18” S-Band
Transmit
Antenna
LPT
3” L-Band
Receive
Antenna
3” S-Band
Receive
Antenna
5. Protocols
Problems
• Noise:
- Internet: Losses due to congestion
- Space:
Losses due to noise
- TCP slows down
- UDP: no flow control, no throttle of data
• Delay:
- Shuttle in 250 km - Orbit
--> RTT: only 1,7 ms!
- TDRSS in 36.000 km -Orbit
--> RTT: 240 ms
- Limit of TCP based applications: 1,5 s RTT
5. Protocols
• All communications between the GSFC and the
LPT used HDLC framing and standard IP
• Standard operating systems process IP headers
• LPT looked like any addressable Internet node
• Ground IP packets delivered over NASA Closed
IONet
• Data packets addressed directly to multiple
ground destinations by onboard processor
• Multiple ground systems address data directly
to spacecraft, no need to specify ground
station
5. Protocols
• First end-to-end
demonstration of
OMNI
• Benefits of the
OMNI Concept:
- Mobile Satellite/Instrument LAN
- Easier Integration
- Virtual Control Center
- Off-The-Shelf Hard- and Software
- Distributed Computing Concepts
- Reliable Data Transfer
5. Protocols
Mobile IP
• Comes with Cisco routers
• Utilized on all two-way SN and GN passes
• Only required three packets to set up tunnel on
marginal links
• Performed very well (~50 ms setup + RTT delay)
• Automated route management to the Shuttle
• Autonomously addressed IP packets, as required
to route message traffic, regardless of the
ground station or TDRSS data relay satellite
through which they were communicating
5. Protocols
TCP
• TCP = Transmission Control Protocol
• Is designed as a guaranteed data stream
• Requires two-way link
• ACK for every packet
• Applications:
- Secure Shell (SSH) and Telnet:
TCP based remote login to the spacecraft
- Secure Copy (SCP) and FTP:
TCP based reliable file transfer to and
from the spacecraft
5. Protocols
UDP
• UDP = User Datagram Protocol
• Data stream is NOT guaranteed
• Standard protocol, supported by all routers
and computers
• No connection setup, each packet is self
identifying and routable
• Works over one-way links
• Unaffected by link delays and data rates
• UDP/IP packets well suited for space use:
- receive real-time spacecraft telemetry
- spacecraft one-way blind commanding
5. Protocols
MDP I
• MDP = Multicast Dissemination Protocol
• Developed over 5 years ago at Naval
Research Lab
• UDP based, reliable file transfer
• OSI-Model: Application layer protocol
• Used extensively for file transfer
• Supported transfers over one-way and
two-way links
• Code is freely available:
http://pf.itd.nrl.navy.mil/projects/mdp/
5. Protocols
MDP II
• Bandwidth utilization: max. 90%
• Provides the ability to throttle transfers
to a specified average bitrate
• Designed to operate with large round-triptime delays on the order of hours or days
• Noise manifests itself as dropped packets:
Solved by retransmissions and applicationlevel Reed-Solomon Forward Error Correction
• NACK back to sender, if the receiver missed
packet(s) --> automatic retransmission
5. Protocols
5. Protocols
MDP III
• The amount of added FEC is selectable
• High Link Asymmetry:
- Because MDP is NACK based, it is extremely
conservative of the uplink channel
- 1000:1 downlink/uplink ratio (10E-5 BER)
Ratios of 10.000:1 and beyond are common
• Unidirectional Link Capability:
- NACKs can even be segregated into a
different contact
- Emissions Control Mode (EMCOM):
client never requests retransmission,
best-effort attempt to receive the file
5. Protocols
5. Protocols
MDP IV
• Bandwidth utilization and link asymmetry are
essentially independent of round trip time
• MDP can handle intermittent links,
transfer is completed on subsequent contacts
• Potential enhancements:
- accept runtime commands to alter
parameters on the fly
- Runtime Datarate Throttle Control:
Dynamically change its bitrate to adapt to
changing spacecraft modes
- Pause / Resume: Pausing it when the
spacecraft was out of contact, all MDP's
timers would be frozen
5. Protocols
NTP
• NTP = Network Time Protocol
• On-board clock synchronization to ground
time standard using NTP
• provided accurate time stamps for all
system logs and telemetry samples
• NTP functioned but needs more work for high
precision:
- Precision timing not possible: simple
PC104 computer clock, no thermal control
- No independent onboard time reference to
measure against
5. Protocols
HDLC
• HDLC = High Level Data Link Control
• Layer 2 of the OSI model
• Variable length frames with CRC-16 error
check
• ISO standard supported by standard
router serial interfaces
• Works over one-way links
• Used over space links for over 20 years
• For use on point-to-point and multipoint
(multidrop) data links
5. Protocols
TDRSS
• IP connection to the South Pole since 1997
• CANDOS experiment demonstrated TDRSS IP
support to an orbiting user
• Orbiting user can have line of sight to
TDRSS for essentially an entire orbit
• Implemented Demand Access System (DAS)
Multiple Access (MA) return link
• Transmit data to any destination at any
time without any ground controller
interaction
6. Experiments
6. Experiments
File Transfer
• Upload of software update files using MDP
(using one- and two-way communication
links), automated hot-directory
• Return of science data files using MDP,
FTP and SCP
• File delivery spanning TDRSS and ground
station handovers using MDP, FTP and SCP
• FTP used for special cases with limited
bandwidth links
• Some files were compressed with GZIP
6. Experiments
Telemetry
• Real-time telemetry (status of LPT) using UDP
status packets over two-way and one-way links
• Telemetry to multiple destinations determined and
controlled by the onboard processor
• During contact with CANDOS status display was
updated every 30 s
• All information timestamped in SYSLOG facility or
application logs (NTP, GPS, MIP, BlindCmd,
RangeSafety, etc.)
• Manually compressed and moved log files to
download directories
6. Experiments
6. Experiments
On-Orbit-Reconfiguration & Commanding
• Multiple, simultaneous control of spacecraft
operations using SSH from multiple consoles
• Telnet used across very slow Hitchhiker 1200 baud
access link
• Automated spacecraft operations using the CRON
scheduling command
• Modified version of the LPT's firmware was
uploaded and commanded to reboot the experiment
• Blind commanding using UDP
• Commanding using Linux shell scripts
6. Experiments
GPS
• GEODE = GPS Enhanced Orbit Determination Experiment
• Four GPS experiment intervals occurred during the
mission, each requiring a minimum of 2 hours of
consecutive time without Shuttle attitude maneuvers
• Filter to estimate position, velocity, drag
coefficient, clock bias, and clock drift
• Force models for Earth's geopotential, drag
accelerations, and Sun/Moon perturbations
• Over 150 MB of navigation data was downlinked using
TDRS and GN communications
7. Conclusions
• Complete success of all flight primary and secondary
objectives
• Approximately 60 hours of payload contact time
• First demonstration of Mobile IP in orbit, as well
as other IP applications
• Standard off-the-shelf products worked well and can
work much better with a little design/configuration
effort and real flight hardware
• A long-term operational mission would need more
automation
• All data downloaded prior to the tragic loss of
STS-107 and crew during landing on February 1, 2003
The End