InterPlaNetary Internet


 
Project
Overview

 
Personnel

 
Project Description

 
Publications

 
BWN-Lab
Projects
 
You are visitor

sin ce Dec. 1'03.

   Updated on 12/01/03

 

Transport Protocols for InterPlaNetary Internet

In the proposed Mars-Earth communication network architecture, the InterPlaNetary Backbone Network plays a very important role for InterPlaNetary Internet and it has the following characteristics: 
 

  • Very Long Propagation Delay Time: The end-to-end round trip time for the Mars-Earth communication network varies from 9 minutes to 50 minutes. The one trip delay to Jupiter varies between approximately 30 and 45 minutes, to Saturn between 70 and 90 minutes. 
  • High Link Error Rate:  Deep space missions typically operate with uncoded bit error rates on the order of 10-1. If a concatenated code composed of a rate 7, constraint-length 1/2 inner convolutional code and a (233, 255) Reed-Solomon outer code are used, the error rates can be brought down to the order of 10-9 or better. 
  • Bandwidth Asymmetry: Data rate asymmetry in spacecraft missions is typically on the order of 1000:1 or higher. For example, most data are delivered from Mars to Earth in the Mars-Earth communication. 
  • Blackouts: In InterPlaNetary Internet, periodic link outages may occur due to orbital obscuration. Orbital obscuration is caused by losing line-of-sight due to the positions of planetary bodies or by the rotation of the asteroid or by the orbit of the spacecraft.


Among above the characteristics, very long propagation delay time has a significant effect on
the traditional currently known TCP protocols for reliable traffic and the  rate control schemes for real-time multimedia traffic. 

The way the RTT value affects the performance of traditional TCP protocols can be justified by two facts: the start phase interval, i.e., the time for TCP to reach a given window threshold, is dependent on the RTT value and TCP throughput is also dependent on the RTT value. If the RTT value is very large, the throughput becomes approximately zero. 

For the existing rate control schemes, the initial stage is also a problem. Because during the initial stage, no network information is available. If the RTT value is very large, how to decide on an appropriate initial data rate is a very challenging problem. Furthermore, most proposed rate control schemes are designed to behave TCP friendly, i.e., their throughput should not exceed those of their TCP counterparts. For example, equation-based rate control schemes use TCP throughput as a reference for rate adjustment. When the RTT value is very large in the case of InterPlaNetary Internet, the corresponding throughput becomes very low. 

As a result, current existing TCP protocols and rate control schemes perform very poor over InterPlaNetary Internet. Consequently, it is  necessary to develop new transport protocols for InterPlaNetary Internet. 

The objective of this project is to create transport protocols to achieve unicast communications in  InterPlaNetary Internet. The transport protocols consist of the following two parts: 
 

  • TP-Planet: Our new transport protocol, TP-Planet, aims to achieve high throughput performance and perform reliable data transmission on space links. TP-Planet is an end-to-end connection-oriented reliable transport protocol specifically tuned to deep space communication requirements. TP-Planet deploys an additive-increase multiplicative-decrease (AIMD) rate-based congestion control protocol. It runs on top of Internet Protocol (IP) layer and does not  require any specific modification to the underlying protocols in the current TCP/IP protocol suite. 
  • RCP-Planet: RCP-Planet is a real-time traffic transport protocol in InterPlaNetary Internet and it is mainly run at the sender and requires some functionality at the receiver. RCP-Planet is not an ARQ scheme and hence no retransmission is performed for any missing packet. RCP-Planet runs on top of RTP/RTCP and UDP. The rate control mechanism is not based on ACK reception for the transmitted packet. Therefore, the receiver does not send acknowledgement back to the sender for the data packets it receives. This also helps to save the scarce reverse channel resources which is desirable in such asymmetric communication links.