Seminar WS 03/04„Satellite-Based Internet“:

The CANDOS-Project

Carsten Krüger 27.11.2003

Julius-Maximilians-Universität Würzburg

Lehrstuhl für Informatik VII

Prof. Dr. Klaus Schilling

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 downto ground stations32 kbps forward / 128 kbps returnthrough 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 de-scrambling for all links

3. Space Network & Ground Network

• 97 SN events were supported forapproximately 52 hours of totaltime

• 91 successful events (94%)• 4 partially successful events (4%)• 2 unsuccessful events (2%)

(Linux OS crashed / hung up;conflict between blind commandsand background scripts forconfiguring the RF module)

• 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%)

SN & GN Communications Passes

SN Communications

TDRSS SSA 52

TDRSS MA 45

GN Communications

MILA 16

Wallops 21

Total Passes 134

4. The Low Power Transceiver (LPT)

• A multi-band, multi-channel, lowpower, lightweight, low cost,modular, software programmable,navigation and communicationtransceiver prototype.

• Developed by NASA / Goddard SpaceFlight Center (GSFC) andITT 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)

LPT

18” S-BandTransmitAntenna

3” L-BandReceiveAntenna

3” S-BandReceiveAntenna

3” S-BandTransmitAntenna

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

• First end-to-enddemonstration ofOMNI

• Benefits of theOMNI Concept:- Mobile Satellite/Instrument LAN - Easier Integration - Virtual Control Center - Off-The-Shelf Hard- and Software - Distributed Computing Concepts - Reliable Data Transfer

5. Protocols

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 andtwo-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-trip-time delays on the order of hours or days

• Noise manifests itself as dropped packets:Solved by retransmissions and application-level 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