1

Simulation of TCP for Orbiting Spacecraft Throughthe TDRS Satellite SystemMarco Duarte, Ken Fisher, Abdul Kabbani

Rice University{duarte, krfisher, akabbani}@rice.edu

Abstract— In recent years NASA engineers have de-signed an interface system that connects the Space Shuttleand Space Station communication system to the Interneton Earth. Such a system allows for the astronauts to useservices like the World Wide Web and Electronic Mail.This application provides a scenario with unique latencyand throughput parameters that the standard TCP/IPprotocol was not designed for. We discuss the changesto the TCP protocol for acceptable performance in thisscenario. Simulations of the behavior of the modified TCPprotocol over the Space Station or Space Shuttle links areperformed using ns− 2. This paper describes the methodand results of those simulations.

I. I NTRODUCTION

In recent years NASA engineers have found away to connect the Space Shuttle and Space Stationcommunication system to the Internet. This wasaccomplished by first designing an interface cardthat looks like an Ethernet adaptor to the PC, butsends data signals compatible with the existing Ku-Band communication system already present on theShuttle and Station. These communication systemswere designed from 1970’s and 1980’s technologyand were never designed for computer networkingof any kind. Since the distance through the satelliterelay link is on the order of 50,000 miles, theTCP protocol needed to be modified, particularlyin the way that the congestion control mechanismsare implemented. Once this was accomplished, theastronauts were able to use TCP to surf the Internetand send Email anywhere on the Internet.

The performance of the network link will be ad-versely affected by the increased propagation delay.The delay will be varied depending on the positionof the craft in its orbit in relation to the geostation-ary relay satellite. The roundtrip delays will be onthe order of 1 - 2 seconds. The RF signal must travelfrom the orbiter, which is at an altitude of 100 to 200

miles, to the relay satellite (located at an altitude ofabout 22,300 miles) then down to the ground stationin White Sands, New Mexico. From there, the signalmust be relayed to the NASA mission control centerin Houston. Our simulation does not include the tripfrom the ground station to Houston, but only fromthe mobile orbiter through TDRS (Tracking andData Relay Satellite) to the ground station. In orderto provide greater connectivity during one completeorbit, the communication system requires east andwest satellites and the implementation of handoversbetween the two. Each satellite must maintain lineof sight to the ground station. Therefore, they arepositioned approximately 120 to 130 degrees apartin geostationary orbits around the Equator. As aresult, there is also a zone of exclusion on theopposite side of the Earth, since the range of thesesatellites will not cover the Equator completely.

In our simulations we usens [1] to determinea maximum theoretical data rate through the linkbased on a data rate of 2 Mbps and a packet size of512 bytes. We observed a variation in this rate usingTCP based on the position of the orbiter aroundits orbit and also measured the actual latency usingCBR packets. We also observe the behavior duringthe east to west satellite handover and going into,during, and coming out of the zone of exclusion.

The system is being used currently by NASA,and we expect that the obtained simulation data willbe useful for the enhancement and development ofcommunication systems for future Spacecraft.

The paper is organized as follows. Section IIdescribes our implementation of the scenario forthe simulation. Section III describes the necessarychanges made to thens − 2 simulator. Section IVpresents our simulation results and Section V offersconclusions.

2

Fig. 1. Graphic 3-D depiction of the simulation scenario.

II. I MPLEMENTATION

In order to accomplish this simulation, we firstdeveloped a program to model the position of thenodes in xyz space. This program is a modificationof a graphics program that was developed for aprevious project. The program allows us to set upobjects such as a sphere (representing the Earth) acircle (representing the orbit), and points in space(representing the relay satellites) and then draw agraphic of them like the one shown in Figure 1.

The graphic shows the Earth and the two TDRSsatellites with solid rays drawn to the ground stationon the Z axis (actually used as the Y axis in ns). Onesatellite looks like it is at a higher altitude, but thatis just an illusion created by the viewing referencepoint. The orbiter is positioned on its initial pointon the X axis. The orbit circle cannot be seen in thispicture because it is so close to the Earth (200 miles)compared to the altitude of the satellites (22,300miles). At each increment the orbiter takes aroundits orbit, the program determines if each satellite isin line-of-sight. This is depicted on the graphic bydrawing a solid line to the satellite if it’s in line-off-sight, and drawing a dotted line if it is not inline-of-sight.

The program is run off-line and generates .tclscript commands that will place the node in aspecific position at a simulation time t. The programwill generate a file with commands in the followingformat:

$ns at t1 "$node (3) setdest x1 y1 7606.764"

;#LOS1:1 LOS2:0

These can be incorporated into the main .tclscript to simulate the orbit around the earth. Theoff-line program also sets flags to indicate if theorbiter has line of sight to the relay satellites ornot. This is printed as a comment with LOS1:1indicating that there is line-of-sight to satellite 1and LOS2:0 indicating that there is not line-of-sight to satellite 2. The number 7606.764 is thevelocity of the orbiter in meters per second. Thiscorresponds to a velocity of 17,500 miles/hr, whichis the approximate velocity of the obiter for a 90minute orbit. We set the increment to be 1 minute,so we generate 90 setdest commands per orbit.

We also modified the ns-2 source code to allowlonger propagation delays and longer ranges. Thisrequired modifications to both the TCP protocolimplementation and the physical wireless channelimplementation. In our problem, we assume that thecommunication link is in range as long as thereis line-of-sight. We also assume no interferencebetween the relaying satellites. We then implementthe positioning of objects in wireless scenarios inorder to simulate the effect of the line-of-sight lossbetween the orbiter and the satellite due to the Earth.For our case, the obstruction object type is a sphere.We also implement the handoff between relayingsatellites manually using a static routine table. Therouting is changed based on the simulation time.These times are determined by the LOS1 and LOS2flags that are calculated on the off-line program.

III. S IMULATOR MODIFICATIONS

In this section we describe the changes made tothe ns simulator for our scenario. These changescan be grouped into changes to the routing protocol,changes to the physical layer, changes to the MACprotocol, changes to the TCP protocol

A. Routing Protocol

For our project, we assumed the satellites to beusing DSR only for the simplicity of using DSRfor implementing a static routing protocol as far asour simulations are concerned. We had the samefunctions inside the DSRAgent class unchanged,with the exception of thercv function. This isthe function that handles the static routing schemethat we have for our project. This was implemented

3

by introducing a couple of nestedif statementsthat can handle the different combinations of thecurrent node, the destination node, and the reach-ability status (in terms of time) when this mightbe an involved factor. The reachability status wasimplemented in terms of time only because of thepath predictability for our shuttle’s motion, i.e.,because of its periodicity. Just before proceeding,we are going to define the node numbers that weused in our function: Node 0: Earth Station in WhiteSands, New Mexico Node; Node 1: TDRS SatelliteWest Node; Node 2: TDRS Satellite East; Node 3:Orbiter.

We saw that nodes 0, 1, and 2 are supposed tobe able to communicate with each other alwaysno matter where our orbiter’s position is (i.e., ir-respective of time). Note that we don’t need tohave all what we had in our actual code belowfor other nonexistent paths as far as our projectis concerned (for example between nodes 0 and2 or 1 and 2), nevertheless, we had that just forcompleteness. The parts in our code correspondingto what has been mentioned are shown below whereiph->daddr() is the address of the destinationnode, andcmh->next hop() is the node towhich we want or are supposed to forward to:

For node 0

if (iph->daddr() == 1) {cmh->next hop() = 1;

}else if(iph->daddr() == 2) {cmh->next hop() = 2;

}

For node 1

if (iph->daddr() == 0) {cmh->next hop() = 0;

}else if(iph->daddr() == 2) {cmh->next hop() = 0;

}

For node 2

if (iph->daddr() == 0) {cmh->next hop() = 0;

}else if(iph->daddr() == 1) {cmh->next hop() = 0;

}

For node 3

// All routes are time-dependent

On the other hand, and when the time factor isinvolved (i.e., when the path between either one ofthe satellites and the shuttle is involved), we hadthe periodicity of the connections (in terms of thehandover procedures and the blockage) by takingour time modulo the orbit period (equal to 5400seconds). Whenever one node was not supposed tobe in reach of another one while carrying a packetdestined to it, that node would drop that packet.Using the line of sight calculations from the offlineprogram described earlier, we found out that duringthe intervals [0, 870] and [3510, 5400] the orbiterwould be in line of sight with TDRS Satellite East;during the interval [1710, 4470] the orbiter wouldbe in line of sight with TDRS Satellite West; andtherefore during the interval [870, 1710] we willhave the zone of exclusion. Therefore, the interval[3510,4470] is the overlap period when the orbiterhas simultaneous line of sight to both satellites. Wedefine in our source code for the routing protocolthe times when line of sight begins and ends:

#define SAT1 START 1710

#define SAT1 STOP 4470

#define SAT2 START 3510

#define SAT2 STOP 870

On the other hand, we can have the handoverfrom TDRS Satellite West to Satellite East at anytime during the overlap period ([3510,4470]). Wecan set up the TDRS Satellite West to acquire thesignal when the orbiter comes out of the zone ofexclusion at any time during the zone of exclusionperiod ([870, 1710]). We set up the handovers tooccur at the middle of each time range. This assuresoptimal throughput behavior as described in SectionIV. The code that defines the handover time is asshown below:

hand21 = ((int)SAT2 STOP + (int)SAT1 START) / 2;

hand12 = ((int)SAT1 STOP + (int)SAT2 START) / 2;

The source code that implements our sta-tic routing tables is shown in Figure 2 whereiph->daddr() and cmh->next hop are thesame as defined before.

B. Physical Layer

We assume that as long as line of sight existsbetween two nodes, the signal will be received

4

Fig. 2. Source code for the static routing table.

5

correctly; the satellites are positioned so that theyalways have line of sight to the earth station, whilethe line of sight from the orbiter to the satellites isdependent to its position in the orbit. In addition,we assume that the nodes will always send packetsat sufficient high power for the destination to detectand decode the packet successfully. To account forthe huge distances involved, we set the receivepower threshold to zero to ensure that the packetis accepted at the receiver despite the transmissionpower levels used in the simulator.

C. MAC Protocol

In our scenario, due to its physical configuration,the connections between nodes are point-to-point,and thus no channel access arbitration is required.Thus, we used the generic MAC layer available inthe simulator for our case, which passes the packetsto the next layer with no processing. This allowsfor all senders to have continuous access to thetransmission channel without any need for accesscontrol.

D. TCP Protocol

Based on the transmission distances involved, ourround trip times vary from 0.52 sec to 0.62 sec. Thisspecial characteristic of our scenario led us to con-sider changes in some of the parameters of a TCPconnection; specifically, the parameters relevant tothe congestion control mechanism (RTT estimate,congestion window size, etc.). We expected thatsetting the initial RTT estimate to our projectedvalue would improve throughput at the beginningof the simulation due to the exponential weightedaveraging algorithm to estimate RTT in TCP; wefound that it did not affect the performance of thescenario since the first calculation of the RTT isdrawn from the actual round trip time delay for thesynchronization packet sent at the initialization ofthe TCP connection.

Another parameter that affects the throughput andis sensitive to the round trip time of the communi-cation is the congestion window size. The optimalmaximum size is equal to the amount of packetsthat can be in flight during a round trip time;this will allow for full utilization of the channelbandwidth while an acknowledgement is receivedby the sender. In the NS simulator, the original valueof this parameter was very low for our scenario (40

packets). We estimate the number of packetsN thatcan be sent during a round trip time as follows:

N = RTT ∗BW/PSIZE = 0.52∗2∗106/(8∗512) ≈ 254 (1)

The throughput then will not be constrained bythe maximum congestion window size if its valueis set larger than 254; we set it to 400 for oursimulations. We proceed to consider the effect ofthe initial congestion window size; we expectedthe throughput to increase if the initial congestionwindow size is set to the maximum instead of thedefault value of 1. We then considered that sincethe window size is doubled every round trip time,the calculated maximum value for the congestionwindow should be reached in approximately8 ∗RTT = 4.16 seconds. Thus, the throughput willimprove only for a very small section of the orbitperiod.

IV. RESULTS

We perform simulations for a FTP applicationthat originates at the orbiter and ends at the earthstation. Our simulator follows all the modificationsdescribed previously; our main design space con-siderations are the timing of the handover betweenthe two relaying satellites.

We first evaluate the performance of the TCP pro-tocol for this application using all the enhancementsdescribed earlier, and setting the handover timesto the middle point of the permissible ranges. Weevaluate the throughput of the connection in packetsper second; the results are shown in Figure 3.

We observe that the throughput per second in-creases up to 225 packets per second, which isequivalent to 900 kbps. We observe no throughputperiod during the zone of exclusion period (870- 1710 seconds), which is expected. However, weobserve a limited throughput phenomenon rightafter the acquisition of line of sight for Satellite 1(at 1710 seconds) and after the satellite handoff (at3990 seconds). We explored several different possi-ble reasons for this behavior. To test the correctnessof the physical and link layers, we simulated a CBRconnection over our same scenario to test packetreachability and propagation delay. The round triptime results are shown in Figure 4; the throughputis shown in Figure 5.

6

500 1000 1500 2000 2500 3000 3500 4000 4500 50000

50

100

150

200

250

Time, Seconds

Thr

ough

put,

pack

ets

per

seco

nd

Fig. 3. Throughput for TCP connection for standard settings.

0 1000 2000 3000 4000 5000 60000.49

0.5

0.51

0.52

0.53

0.54

0.55

0.56

Time, Seconds

Rou

nd T

rip T

ime,

Sec

onds

Fig. 4. Round Trip Time for CBR traffic for standard settings.

0 1000 2000 3000 4000 5000 60000

50

100

150

200

250

300

350

400

450

Time, Seconds

Thr

ough

put,

Pac

kets

per

Sec

ond

Fig. 5. Throughput for CBR traffic for standard settings.

0 1000 2000 3000 4000 50000

50

100

150

200

250

300

Time, Seconds

Con

gest

ion

Win

dow

Siz

e, P

acke

ts

Fig. 6. Congestion window of TCP connection for standard settings.

These figures show an expected behavior forthe latency of packet transmission, which variesaccording to the position of the active satellite. Wesee that the throughput to the satellite is stable,which shows that the characteristics of the channelare not dependent on the position of the satellite.This allows us to rule out simulation bugs in thephysical and link layers. We also notice that the re-duction in throughput occurs only during the periodwhere the distance from the orbiter to the activesatellite — and thus, the RTT — is decreasing.At the approximate point of minimum latency theexpected throughput is restored, and the throughputoscillates continuously between 10 and 225 packetsper second. After examining the simulator traces,we see that packet drops occur only during the zoneof exclusion; thus, we assume that the reduction inrate is due to congestion window resetting due toduplicate ACKs or retransmission timeout. Figure 6shows the size of the congestion window and Figure7 shows the number of duplicate ACKs received bythe orbiter as a function of time.

From this data we see that the throughput fallsrepeatedly during the simulation due to the duplicateACKs caused when a packet is sent out of order. Wealso see a frequent occurrence of three duplicateACKs during the periods of low throughput. Thereason behind this behavior is unknown to us at thispoint. We conjecture that out of order reception ofpackets has a large effect on the congestion controlmechanism due to the large latency of a round triptime.

7

0 1000 2000 3000 4000 5000 60000

50

100

150

200

250

300

350

Time, Seconds

Num

ber

of c

onse

cutiv

e du

plic

ate

AC

Ks

Fig. 7. Number of duplicate ACKs for standard settings.

0 1000 2000 3000 4000 5000 60000

50

100

150

200

250

300

350

Time, Seconds

Thr

ough

put,

pack

ets

per

seco

nd

Fig. 8. Throughput for TCP connection for minimum handoff times.

We also evaluate the effect of the satellite han-dover time on the throughput. We can set oneof the handovers to any time during the zone ofexclusion; the second one can be set to any timeduring the period when the orbiter has line of sightwith both relaying satellites. Figure 8 shows thethroughput when the handovers times are set to theminimum possible values, while Figure 9 shows thethroughput when the handover times are set to themaximum possible values.

We expect both of these schemes to performworse than the selected scheme due to the suddenchanges in round trip time. The round trip timefor the second scheme is shown in Figure 10; thechange in round trip time during handoff is propor-

0 1000 2000 3000 4000 5000 60000

50

100

150

200

250

300

350

Time, Seconds

Thr

ough

put,

pack

ets

per

seco

nd

Fig. 9. Throughput for TCP connection for maximum handoff times.

0 1000 2000 3000 4000 5000 60000.49

0.5

0.51

0.52

0.53

0.54

0.55

0.56

Time, Seconds

Rou

nd T

rip T

ime,

Sec

onds

Fig. 10. Round trip time for minimum handoff times.

tional to the change of distance between the orbiterand the satellites. The problem is critical whenthe round trip time increases suddenly, triggeringseveral timeouts and retransmissions. Furthermore,a new problem arises if the handover time is set tothe maximum for the second handover. The packetsthat are sent to the satellite by the earth station closeto the end of line of sight may be received by it afterthe line of sight is not present, and they will thusbe dropped, causing reduction in the throughput asseen in Figure 9. This leads to our reasoning ofperforming handover at the middle of the feasibleinterval, where the distance to each of the satellitesfrom the orbiter will be the same.

8

V. CONCLUSIONS ANDFUTURE WORK

We have modeled the Internet connection of theSpace Shuttle and Space Station using thens − 2simulator, and studied its behavior for typical TCPapplications. Some unexpected behavior was ob-served regarding out-of-order transmission of pack-ets, but theoretical figures for the performance ofthe system were obtained. We have not been ableto determine whether this behavior is inherent to thebehavior of TCP for our scenario or is introducedby errors in the modified simulator. If the formeris the case, we expect that a mechanism at theTCP protocol that would delay acknowledgementsfor some packets that are delivered out of orderwould allow us to reach the optimal throughputlevel throughout the simulation period. We haveconcluded that handoff should occur at the middlepoint of the overlap of line of sights to causethe smallest disturbance possible to the congestioncontrol mechanism state. We have also concludedthat a large part of the loss in potential performanceis due to the effect of the congestion control mech-anism during the zone of exclusion, in which nocommunication is possible. Since the orbit cycle ofthe orbiter is ninety minutes, applications that wouldrequire continuous connectivity for a larger intervalwill suffer. We expect that mechanisms similar to [2]that set the TCP connection to stand-by state duringperiods without connectivity, which was proposedfor ad-hoc wireless networks, should improve theperformance in this scenario as well. We remaininterested in determining the reasons behind theerratic behavior observed in the simulations, andwould welcome suggestions regarding these issues.

VI. A CKNOWLEDGEMENTS

We thank Shu Du and Khoa To for their invalu-able suggestions regarding the implementation ofthe handoff schemes.

REFERENCES

[1] (2004) The network simulator - ns-2. [Online]. Available:http://www.isi.edu/nsnam/ns/

[2] G. Holland and N. Vaidya, “Analysis of TCP performance overmobile ad hoc networks,” inProceedings of the Fifth AnnualInternational Conference on Mobile Computing and Networking(MOBICOM), Seattle, WA, August 1999.