Download presentation
Presentation is loading. Please wait.
Published byStephany Park Modified over 9 years ago
1
Seminar WS 03/04 „Satellite-Based Internet“: The CANDOS-Project Carsten Krüger27.11.2003 Julius-Maximilians-Universität Würzburg Lehrstuhl für Informatik VII Prof. Dr. Klaus Schilling
2
Content CANDOS Overview Mission Objectives Space Network & Ground Network The Low Power Transceiver (LPT) Protocols Experiments Conclusions
3
1. CANDOS Overview
4
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
5
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
6
3. Space Network & Ground Network
7
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
8
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
9
3. Space Network & Ground Network 97 SN events were supported for approximately 52 hours of total time 91 successful events (94%) 4 partially successful events (4%) 2 unsuccessful events (2%) (Linux OS crashed / hung up; conflict between blind commands and background scripts for configuring 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%)
10
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)
11
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
12
4. The Low Power Transceiver (LPT) LPT 18” S-Band Transmit Antenna 3” L-Band Receive Antenna 3” S-Band Receive Antenna 3” S-Band Transmit Antenna
13
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
14
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
15
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
16
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
17
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
18
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
19
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/
20
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
21
5. Protocols
22
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
23
5. Protocols
24
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
25
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
26
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
27
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
28
6. Experiments
29
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
30
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
31
6. Experiments
32
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
33
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
34
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
35
The End
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.