1 / 35

Julius-Maximilians-Universität Würzburg Lehrstuhl für Informatik VII Prof. Dr. Klaus Schilling

Seminar WS 03/04 „Satellite-Based Internet“: Transport Protocols and Applications for Internet Use in Space Alexander Pasztor 15.01.2004. Julius-Maximilians-Universität Würzburg Lehrstuhl für Informatik VII Prof. Dr. Klaus Schilling. Content. Overview of Internet Protocols in Space

beryl
Télécharger la présentation

Julius-Maximilians-Universität Würzburg Lehrstuhl für Informatik VII Prof. Dr. Klaus Schilling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Seminar WS 03/04„Satellite-Based Internet“:Transport Protocols and Applications for Internet Use in SpaceAlexander Pasztor 15.01.2004 Julius-Maximilians-Universität Würzburg Lehrstuhl für Informatik VII Prof. Dr. Klaus Schilling

  2. Content • Overview of Internet Protocols in Space • Space vs. Terrestrial issues • IP Based Operations Scenarios • Present Results • Future Work and Conclusion

  3. 1. Introduction

  4. 1. Introduction • Transmission and routing protocols for space missions need not to be developed from scratch • Use of off-the-shelf, low-cost and commodity-level applications • Protocols based on layer 4 and 7 of OSI seven-layer model

  5. 1. Introduction • Transport layer (UDP, TCP): stream multiplexing and reliable transfer • UDP: very basic, fast • TCP: reliable due to automatic retransmission • RTP: data streaming • Application layer: NTP, FTP, SMTP; run over transport protocols

  6. 2. Internet Protocols in Space - Overview Only end-to-end data delivery between the nodes Use of IP as the base protocol: provides end-to-end communication Popular and well researched protocol Automated routing without limitation of the number of nodes Reference architecture developed by the OMNI project Common Protocol is IP Independence of the upper resp. lower layers

  7. 2. Internet Protocols in Space - Overview

  8. 2. Internet Protocols in Space - Overview • Transport layer offers stream multiplexing • Used for transmitting asynchronous data streams • Mix of different protocols is possible • Each protocol has 65,535 ports • Commonly used: UDP, TCP, RTP • RTP bases on UDP • Choice of the protocol depends on mission type

  9. 2. Internet Protocols in Space - Overview • UDP: • Simple and connectionless • No guarantee for arrival and sequence of packets • Error detection • Faster because no connection establishment phase • “atomic packet delivery” • Use on highly asymmetric links • Delay insensitive, multicast • No flow control or reliable transport

  10. 2. Internet Protocols in Space - Overview • RTP: • Real-time data – audio, video, Voice-over-IP • On top of UDP because of multiplexing and checksum functionality • Extends UDP by payload type identification, sequence numbering, timestamping • Header 12 bytes longer than in UDP • For any isochronous data where timing counts • Possibility of adding reliability and flow control

  11. 2. Internet Protocols in Space - Overview • TCP: • Connection oriented • Reliable byte stream • Flow control, “out-of-band” handling of priority messages • Phases: connection setup, data delivery • Status resp. acknowledgement information • For download of instrument science data, upload of spacecraft or instrument command loads • Many off-the-shelf applications • Necessity of bidirectional link; max. asymmetry about 50:1

  12. 2. Internet Protocols in Space - Overview • TCP – continuing • Large RTT -> larger window buffers -> larger penalties for packet retransmissions • No ability to distinguish between loss due to congestion and loss due to noise • Noise reduces throughput because timeouts grow • Max. distance: about the way from earth to moon • Bit rate at geosynchronous distance: ~400mbps

  13. 2. Internet Protocols in Space - Overview • Application Layer provides additional functionality • Self-defined protocols possible • UDP-Based applications: Simple Data Delivery: • Self-made protocols • CCSDS protocols for telemetry, command packets Reliable File Transfer with UDP: • Relevant for satellite communication: PBP, MFTP, CFDP • Do not need bidirectional link

  14. 2. Internet Protocols in Space - Overview • Receive list of packets that have to be resent • Any kind of return link required • Delay-insensitive • Work well for deep space missions Time Synchronization • NTP over UDP • Time of client or server is synchronized with other server • Redundancy for preciseness • In space missions: primary server at ground station -> minimized delay

  15. 2. Internet Protocols in Space - Overview • TCP-Based applications Reliable Simple Data Delivery: • Automatic retransmission of needed data • Not used yet • CCSDS COP-1 protocol for commanding data • For telemetry data whole data resent or losses accepted Reliable File Transfer with TCP: • Internet standards FTP and HTTP • FTP more efficient but complex to implement • HTTP is simple but needs special connection on each transfer

  16. 2. Internet Protocols in Space - Overview Email: • SMTP used • Either transmission of 7-bit ASCII text or binary data • Client keeps mail being transmitted until it has been copied to the recipient’s server • With servers as mail gateways store-and-forward transmission is possible • Space missions profit by this because of the long periods where no contact to spacecraft is possible • Data is queued and delivered later

  17. 3. Space vs. Terrestrial issues • Popular Argument: Conditions for data transfer are totally different in space • Very similar conditions to Internet • Research in one domain profits by research in the other one • Common problems: • Asymmetric data transfer • Long delays • Errors • Loss of connections

  18. 3. Space vs. Terrestrial issues • Long Delay: • RTT and propagation delays are similar on LEO missions and the Internet • RTT for LEO ~4ms when spacecraft is overhead • ~32ms at horizon • ~240ms at geosynchronous orbit • Experiment with ACTS Satellite at NASA Glenn Research Center: 480ms RTT and 400mbps (geosync.) • Max. distance for TCP is the moon; RTT 1666ms

  19. 3. Space vs. Terrestrial issues • Noise: • TCP: no distinction between congestion and noise • TCP implies congestion -> slows down • Space very noisy -> analogue to telephone line (BER of 10E-5) • Error correction on lower layers needed • BER reduced from 10E-5 to 10E-7 • Standards to improve TCP itself: ECN, SACK, TCP/PEACH

  20. 3. Space vs. Terrestrial issues • Power, CPU and Bandwidth constraints: • Also similar to cellular phones • New CPUs: StrongArm, Power PC 750 • Intermittent connectivity and variable routing: • Limited Time frame where contact between ground station and spacecraft is possible • Routing important because of more ground stations • Use of Mobile-IP • Like laptops -> change location, keep IP address

  21. 3. Space vs. Terrestrial issues • Forward/Return Path Asymmetry: • Similar to Internet • Greater downlink than uplink bandwidth by convention • Uplink bandwidth limited to 8kbps • Allows 400kbps downlink with max. asymmetry 50:1 • Enough for more than half of all space missions • For larger uplink the standard 16kHz subcarrier uplink must be increased (e.g. TDRSS) • UDP can use full bandwidth

  22. 4. IP-Based Operations Scenarios • Many space operations profit from IP • For Real-time engineering and monitoring of housekeeping data: UDP/IP • For reliable data transfer: TCP/IP • Storage of onboard collected data by off-the-shelf file system • Delivery of this data later by FTP or Starbust/MFTP if RTT too big • Synchronization of onboard clock by NTP • NTP calculates propagation delay times, time variance and drift rates -> precision up to 240 picoseconds

  23. 4. IP-Based Operations Scenarios • SMTP for store-and-forward delivery of data when spacecraft is not in range • Other way around also possible • Blind commanding by UDP in emergency case and no downlink available • Other scenarios: • User interaction • Spacecraft cross-support • Ad-hoc collaborations • Formation flights

  24. 5. Present Results • On-orbit clock synchronization: (by OMNI) • Test run on April 14, 2000 • UoSat-12 with onboard NTP client • Synchronized with USNO timeserver to UTC • Worst-case as ground station is in the UK • First onboard server not connected to clock • Every 30sec calculated offset sent to ground by UDP • Sever enabled for clock adjustment and after 2 calculations clock was synchronized • Now clock manually set to a wrong time • Again after 1 minute clock was UTC-conform • Clock adjusted if offset over 1 second • Fractional seconds in next adjustment period

  25. 5. Present Results

  26. 5. Present Results • Error-Free Download with FTP: • Test run on July 5, 2000 • Data downloaded without automatic retransmission today • Image data often lost due to noise and large BER • LandSat-7: BER of 10E-7 to 10E-9 • Large ground antennas, forward-error-correction • UoSat-12: BER of 10E-5 to 10E-6 • No forward-error-correction, modest antennas • Dropped scan lines with LandSat-7

  27. 5. Present Results

  28. 5. Present Results • FTP: automatic retransmission • UoSat-12 equipped with off-the-shelf FTP server and packet trace software • Packets still get lost but are not noticeable

  29. 5. Present Results • Loss of performance at BER below 10E-7 • 60% bandwidth utilization at BER of 10E-5 • Packet trace: 227kB, 445 packets, 9 retransmissions • 7 single and 2 multiple packet losses • Single packet losses: “rapid-retransmission” • Multiple packet losses: retransmission timeout • In experiment: 79.2% bandwidth utilization achieved • Theoretical max. bandwidth utilization: 91.2%

  30. 5. Present Results

  31. 5. Present Results • On-Orbit HTTP test • Test run on January 25, 2001 • HTTP for real-time transfer of telemetry and image data to ground • Homepage with link to image and live-updated page with telemetry data • Client-pull every 10 seconds • Transfer to multiple browsers at GSFC

  32. 5. Present Results

  33. 5. Present Results

  34. 5. Future Work • Most techniques only experimental status • Research on testing under space conditions • Making a standard • HDLC framing, IP on spacecraft, routers on ground stations no big problems • Concentration on network security and handling mobility • OMNI project building experimental setup • Testing of security protocols (IPsec) and VPNs • Very important: reliable transfer over UDP

  35. 6. Conclusion • Many advantages of IP in space • Convincing results of experiments with UoSat-12 • Very low costs • Conversion of spacecraft, ground station and tests: 5 moths work, $50,000 • No changes required when using standard Internet protocols in space • End-to-end functionality matches space requirements • Flexibility: unidirectional or bidirectional • Widely available specifications

More Related