1American Institute of Aeronautics and Astronautics

OPTIMIZING COMMUNICATIONS FOR CONSTELLATION SPACE MISSIONS

Yingyong Chen, Michael Hadjitheodosiou

CSHCN, University of Maryland,College Park, MD 20742, USA

E-mail: {yychen, michalis}@isr.umd.edu

Cynthia Cheung

NASA/GSFC Code 695 Planetary MagnetospheresBranch

Greenbelt, MD 20771, USAE-mail: cynthia.cheung@gsfc.nasa.gov

Abstract – NASA is interested in developing a newclass of space missions that will consist of a number ofspacecraft operating in unison for a specific scientificobjective. We outline the challenges in providingseamless communication support for this new class ofconstellation missions. We are interested in developingintelligent and autonomous network architecture andprotocols suitable for the next-generation space networkthat resembles the ground networks in terms of itsflexibility and capability of providing different servicesto individual users. Currently, we are focusing onnetwork layer protocols, and a suitable dynamic routingalgorithm will be introduced in this paper. We outline amodular simulation framework for constellation missionscurrently being developed to evaluate the performance ofsuch protocols. Data download from one of theconstellation missions currently planned by NASA, theMagnetospheric MultiScale (MMS) mission, is studied indetail using our simulation environment.

Keywords – Constellation mission, Wireless network,Routing;

1 IntroductionNASA is interested in developing a new class of

space missions that will consist of a number of spacecraftoperating in unison for a specific scientific objective. Byutilizing multiple spacecraft for both scientific datacollection and mission communication, NASA scientistsare planning missions that are much more complex thanwhat they had before. Examples of constellation missionsinclude Magnetospheric Multiscale (MMS) mission [1,2],

Magnetospheric Constellation Mission and AutonomousNano Technology Swam (ANTS)[6]. The number ofspacecraft involved in such missions can be verydifferent, four satellites is planned to participate in MMSwhile thousands of small spacecraft might take part inANTS mission. Spacecraft participating in constellationspace missions will need to tightly coordinate with oneanother; spacecraft’ role may change during the course ofthe mission operation [6]. Traditionally, mission datadelivery requires pre-determined mission-specificscheduling and constant human interaction. By utilizingmultiple spacecraft, NASA scientists can now plancomplex missions that can only be imagined before.Traditionally, NASA missions operations are strictlyfollowing either pre-determined schedule or groundcontrol all the time. This approach is not scalable nor is itcost-effective. So, to support increasingly complexmissions, to support many missions at the same time andto improve the flexibility and cost-effectiveness ofmission operations, we need a common intelligentcommunication architecture with necessary networkfunctionalities built in that can provide autonomous datadelivery and transparent end-to-end connection for allmissions. Such a common space communication networkfor all mission communication support relieve missionscientists and engineers from worrying about every step adata packet has to take to reach its destination and caninstead focus on how to achieve their scientific goals.

The new space network architecture will have muchmore compatibility with Internet than the current onedoes, and it should be based on Internet technology [7], [8],

[9]. The compatibility is a vital issue for the healthydevelopment of space communication technology. With

Figure 1: Future Space Mission Network

21st International Communications Satellite Systems Conference and Exhibit AIAA 2003-2401

Copyright © 2003 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.

2American Institute of Aeronautics and Astronautics

this compatibility, more commercial of the shelf (COTS)software & hardware can then be used in spacecommunication. Modular COTS products can be easilyupdated when a new version becomes available. Besides,the COTS products are often being updated at muchfaster paces than those proprietary NASA-only products.Thus, Internet compatibility can help to keep spacecommunication technology up-to-date and improve itscost-effectiveness, which are vital for the success ofspace missions.

The Internet-based space network will possess built-in network functionalities similar to what we currentlyhave in ground Internet to enable transparent end-to-endconnectivity and interactivity throughout the network;data will be autonomously handled and delivered fromthe source to destination by the network nodes withoutexplicit human interaction. The space network willprovide communication support service for all spacemissions and will expand as the demand grows or newdemand arises. With such a unified space networkarchitecture, mission communication support is no longera unique task for every single space missions, but rathera common task for the whole network: all the networkresources can be used to support any mission.

To enable fully autonomous mission operation,nodes in space network need to be able to automaticallyadapt and reconfigure based on the network environment.Thus, efficient dynamic routing protocol that moves dataaccording to real-time network topology is a necessity.Traditional routing algorithms widely used in groundInternet, like RIP and OSPF, may not providesatisfactory performances because intermittent spacecommunication links and fast topology changes willresult in excessive amount of control overhead. Mostrecent work on routing in a space environment has beenconcentrated in designing routing algorithms for somespecific commercial LEO satellite constellations, likeIridium and Teledesic, which has symmetric circularorbits and dense connectivity among nodes, and can’t beeasily generalized to a common scenario [10], [11]. Therouting protocol proposed in this paper does notexplicitly depend on any specific type of satellitecommunication network topology.

In this paper, we will first describe briefly acommunication infrastructure and architecture for thefuture space network, as envisioned by some NASAscientists and engineers [7], [8]. We will focus on networklayer issues and present a dynamic routing algorithm forthe future space network. We will then describe asimulation framework we are developing forconstellation space missions and some simulation resultswe obtained for the MMS mission, a simple example of afour-spacecraft constellation.

2 Future Space Mission CommunicationNetwork Architecture

A detailed description of the future space Internetarchitecture can be found in [7] and [8]. We will justbriefly describe the key elements in this section. Aconceptual sketch of future space mission network isshown in Fig. 1.

The backbone network (BN) of the future spaceInternet will consist of NASA/non-NASA groundfacilities and relay satellites. So current Space Network(SN), Deep Space Network (DSN) and Tracking & DataRelay Satellite System (TDRSS) can all be part of the

backbone network. The backbone network elements areinterconnected via high-speed communication links andprovide access points for mission spacecraft and groundusers who wish to access science data collected bymission spacecraft.

Inter-spacecraft network (ISN) is formed by missionspacecraft (from the same mission or from differentmissions). Existence of ISN can potentially increase thecoverage of the backbone network, because missionspacecraft can utilize other mission spacecraft as relay toform a multi-hop path to access the backbone resourcesif a direct route is not possible. This could utilize thenetwork resources more efficiently and provide extracommunication capabilities.

An Internet-based architecture could also makepossible for the space nodes to provide service like FTPand HTTP so that those authorized scientists on theground can access onboard instruments and selectivelyobtain critical data without having to download all thedata to the ground, or have interaction with their spaceexperiments.

One last element of future space Internet not shownin Fig.1 is proximity network, (PN), formed by rovers,landers, robots, sensors and other types of landed orairborne entities. A PN is usually deployed by missionspacecraft in a relatively small region. PN elementsinterconnect with each other to form an ad-hoc networkand often use their mothership to deliver the data theycollected through the network infrastructure.

3 Dynamic Routing AlgorithmOne of the major goals of mission support is to

download as much data as possible from missionspacecraft to ground. In this section, we will present adynamic routing protocol to automatically direct datatraffic from spacecraft to ground.

Routing algorithms can be divided into twocategories: proactive (table-driven) or reactive (on-demand). Proactive routing protocols require each nodeto maintain a routing table to all other nodes andperiodically broadcast its routing information to keepeach other informed of the latest network changes.Examples of proactive routing protocols are RIP, OSPFand DSDV. RIP and OSPF are both widely used inInternet. Reactive routing protocols are also called on-demand routing protocols. They don’t require periodicbroadcasting of routing information; nor do the nodeshave to maintain a route to every other node. A route isdiscovered and maintained only if needed. Reactiveprotocols include Dynamic Source Routing (DSR) [4] andAd-hoc On-demand Distance Vector (AODV) [12]

Routing. They were developed in recent years forMANETs with the objective of reducing unnecessarycontrol data broadcasting generated by routing protocolsto conserve bandwidth and power. However, reactiveprotocols do introduce extra delay in having to discover aroute before a transmission can happen if a fresh routedoesn’t already exist. Additionally, network nodes willnot have the same level of knowledge about the networktopology as a node would have if they use proactiverouting protocols. The routing algorithm we propose here belongs toreactive category. Two major factors contributed to thischoice: bandwidth efficiency and the often stream-likespace mission data flow pattern. The routing algorithm iscalled Space On-Demand Dynamic Routing (SODR).

3American Institute of Aeronautics and Astronautics

We can divide future mission support network intoground segment and space segment, consisting of groundand airborne nodes, respectively. We assume that allground nodes are interconnected and that the routinginside ground segment has been solved. We also assumethat the communication “cost” associated with groundlinks are negligible compared with space links. Zerometric will be assigned to every ground link. So thewhole ground segment is viewed as a single compoundnode by space nodes. When a spacecraft needs to senddata to a certain ground node, what it really needs tosolve is to select the “best” route from itself to anyground node rather than to the destination ground node,the well-established and low-cost terrestrial network isthen responsible for routing the traffic from this groundnode to the destination ground node. We assume allnodes are identified by their IP addresses. We alsoassume that all space nodes form a space subnet,identified by a unique network prefix in the IP addressesof all space nodes. Thus any node can tell if a node is aspace node from the network prefix of its IP address.

Space nodes don’t try to maintain a complete routetable to all other nodes. Route is discovered only whennecessary. Route will be aged out if it’s not used for acertain amount of time. SODR will try to find theminimum end-to-end delay path from the source to thedestination.

SODR can be implemented similar to the wayAODV [12] is implemented if we decided only to utilizebi-directional links and that’s we do in this paper.However, it can also be implemented as a source routingprotocol, as DSR [4], [5] is implemented. By implementingit as a source routing protocol, unidirectional links can beutilized, but it reduces the bandwidth utilizationefficiency, because all data packets will have to carryadditional detailed route record and thus consume morebandwidth. Since even with DSR, additional efforts needto be made such as the tunneling of link-level ACK [13] toactually utilize unidirectional links, which will results inadditional control traffic. Thus before the benefits ofutilizing unidirectional links obviously outweigh itsadditional cost, we will stick to the AODV approach.

3.1 Route Discovery When a source space node need to send data to somedestination node, it will first check its route cache to seeif it currently has an unexpired route to that destinationnode. However, if the destination node is a ground node,then it’s enough to have a route to any ground node,which is called a Touch-Down Node (TDN).

If a route to the destination (or to a TDN when thedestination is a ground node) doesn’t exist already, thesource node will initialize a Route Discovery process bybroadcasting a Route Request (RREQ) message, whichcontains the source node address, target node address, aTime-to-live (TTL) field, a Request-Time (REQ-T) field,a hop count field, a sequence number associated with thesource, and the last known sequence number associatedto the destination. The source node time stamps theRREQ packet by storing the time it sent out the RREQ inthe Request-Time field. The source IP address, target IPaddress and Request-Time field can uniquely identify aRREQ packet. Hop count field is set to be zero when theRREQ is sent out.

Upon receiving a RREQ, a node first check to see ifit has already seen the same packet by checking the

source IP address, target IP address and Request-Time ofthe packet. Each node maintains a list of RREQ seenrecently by this node for a certain time. If this RREQ hasbeen seen before, it will be dropped immediately.Otherwise, the node will process the packet.

When processing the RREQ, the hop count in theRREQ will be incremented by one. A reverse route entryfor the source node will be recorded at this node. Thereverse route entry contains the IP address of the sourcenode, the sequence number associated with the source,the IP address of the node from which this RREQ isreceived, the number of hops to reach back the source,and the delay this RREQ endured traveling from thesource to this node. The delay is calculated as thedifference between the Request-Time and the arrivaltime of the RREQ at this node. The reverse route entryalso has a lifetime, if it’s not used within that time, theentry will be deleted.

A node can always respond to a RREQ if it’s theintended target node. If the target is a ground node, thenany ground node can reply as if it’s the intended target.Otherwise, an intermediate node can respond to a RREQonly if the following two conditions are both satisfied:

1. It has an unexpired route entry to the target.

2. The sequence number associated with thetarget node for this route entry is no smallerthan that included in the RREQ.

To reply, the node generates a Route Reply (RREP)packet and sends it back to the source node, through thenode from which the RREQ is received. The RREPpacket contains the IP address of the source and thetarget, the destination sequence number recorded at thereplying node, hop count, a Lifetime field, an source-to-destination delay field and a Reply-Time (REP-T) field.Reply-Time is the time when the RREP is sent out. Thesource-to-destination delay is equal to the time differencebetween REP-T and REQ-T if the replying node is thetarget node itself or a Touch-Down node when the targetnode is a ground node; Otherwise it’s set to be the timedifference between REP-T and REQ-T plus the delayvalue for the corresponding route entry from this node tothe target node. Hop count will be set as 0 if the replyingnode is the target or a Touch-Down node; otherwise, hopcount will be set as the hop count corresponding to thevalue in the corresponding route entry.

When an intermediate node receives a RREP, itincreases the hop count field in the RREP by one. Then itwill set up the forward route entry, which contains the IPaddress of the destination, the destination sequencenumber, the route lifetime, the number of hops to reachthe destination, and the delay calculated as the timedifference between the Reply-Time (of the RREP) andthe arrival time of the RREP at this node. The routelifetime is set to be the lifetime value contained in theRREP. The node will then forward this RREP toward thesource node using the reverse route entry set up before.

When the source node receives a RREP, it obtainsthe forward route end-to-end delay from the source-to-destination delay value in the RREP packet; it alsocalculates the backward route end-to-end delay (ETED)as the time difference between the RREP arrival time andthe Reply-Time in the RREP packet. We can use eitherthe forward route ETED or the average of the forwardETED and the backward route ETED as the route metric

4American Institute of Aeronautics and Astronautics

Figure 2: Spacecraft Node Model in OPNET

Figure 3: Ground Station Node Model

for this particular route. A source node can start using theroute as soon as one RREP is received. However, theroute received first is not necessarily the one with theminimum end-to-end delay, because the intermediatenodes are allowed to respond. The source will keep usethis route unless it later receive a RREP which has alarger destination sequence number or has a smaller end-to-end delay value.

3.2 Route Maintenance Nodes are required to broadcast periodical hellomessages to its immediate neighbors. The hello messagecontains the node’s IP address and its current sequencenumber and the time when it’s broadcasted. By settingthe TTL to be 1, hello packets will not be forwarded byany node. Nodes receive the hello message will thenupdate its route entry accordingly. Thus all nodesmaintain the list of their immediate neighbors and thecorresponding delays in its route table. If one nodedoesn’t receive hello message from a previous neighbor,it will declare that link is no longer available. Thecorresponding route entry will be updated, the delayvalue and hop count will be set to be infinity. Routeentries with infinite delay and hop count will be deletedonly after a certain amount of time.

When a link to a neighbor breaks down, a node willfirst check its route table and mark all routes whose nexthop is the lost neighbor as invalid by setting the delayand hop count to be infinity. It also generates a RouteError (RERR) message containing all the destinationsnow unreachable and sends it to the precursor nodes(obtained from the reverse route entries in the routetable) on those routes that currently utilize the brokenlink. The RERR will be forwarded back to the source,which can then restart the route discovery process if aroute is still needed. We assume that ground stationsinform all other ground stations of any changes in theirsequence number, thus make sure any ground node canhave the most fresh sequence numbers for all otherground stations to be able to respond as Touch-Downnode.

4 Simulation Model

We are building a simulation framework forconstellation space mission using OPNET.

Space mission communication network consists ofthree types of nodes:

1. Mission Satellites2. Relay Satellites3. Ground Stations.

Our OPNET node model for a mission spacecraft isshown in Fig. 2. A relay satellite model is similar to thisone, except that it doesn’t have its own data generator(source) because it doesn’t have mission science datacollecting devices onboard and is used for relaying dataonly. The ground station node model is shown in Fig. 3.A ground node has two set of transceivers, one for radiocommunication and one for ground communications. Theground stations have both radio transceiver and point-to-point transceiver for space and ground communication,respectively.

5 A Case Study: the MMS Mission

MMS mission is a constellation space missionwhich is currently scheduled to launch in 2006. In thissection, we use our simulation framework to conductcommunication trade-off studies for this mission andpresent some preliminary simulation results. We onlybriefly describe some key facts about MMS in this paper,details about MMS can be found in [1]. More results anddetailed explanations for MMS mission simulation canbe found in [3].

The MMS mission is designed to study thefundamental processes in space plasmas. As shown inFig. 4, four identical mission satellites in a variablyspaced tetrahedron (1 km to several RE) will carry out themission in four orbit phases with a minimum of 2-yearmission life. The period of the MMS satellite is exactly24 hours. The MMS mission spacecraft has an onboardstorage capacity of 3.5Gigbytes [2]. The plannedtransmission rate for MMS mission spacecraft is between1Mbps and 2.2Mbps. The satellite transmitter EIRP is14dbW. The MMS mission communication is planned inX-band, NASA’s Deep Space Network (DSN) is planned

5American Institute of Aeronautics and Astronautics

Figure 4: MMS Mission Network And Satellite Orbits

as the primary mission support facilities. The missionnetwork and spacecraft orbits are shown in Fig. 4. Thethree DSN stations are located at Goldstone (CA),Madrid (Spain) and Canberra (Australia). In MMSmission phase 1 and 2, commercial 11-meter dishes witha 5° minimum elevation angle.

We outline a possible communication process here,which is note necessarily the one that the actual missionwill implement. Because the orbits of all four MMSsatellites are very similar, it’s unlikely that one can usethe other three as relay to transmit data to groundstations. We assume that mission satellites have fullknowledge of the physical locations of DSN groundstations and itself. When a MMS satellite has data totransmit, it uses a dynamic routing algorithm todetermine the proper next-hop receiver for itself.Because of the very small number of nodes in thisnetwork and because that the use of other MMS satellitefor relay is unlikely, the minimum propagation delaypath to ground can be easily found.

The mission satellite will attempt to transmit only ifit discovers that there is a ground station in itscommunication range. Node A is said to be in thecommunication range of a node B if the SNR of thereceived signal at the node A from B is no less than therequired minimum SNR (Eb/N0). The required minimumSNR for MMS mission is 2.6dB [1]. SNR of the receivedsignal can be calculated as shown in Eq. 1 below.

SNR (dB) = EIRP + Lp + LAR + Lpolar + Limp

– KB (dB) + GR/T – DATA_RATE (dB)

(1)

The initial MMS plan also has a room for an extra2db SNR margin, so in most of our simulations, theminimum SNR required is 4.6db instead of 2.6db. Anadditional restriction on mission spacecraft is that it canonly transmit within a time window around its perigeewhere it’s close to the earth. The actual time window sizeis a simulation parameter.

The MMS mission data collector onboard missionsatellite can generate data at either the burst rate of104kbps when there are a lot of geomagnetic activities orthe normal rate of 18kbps [1], [2]. We use an empiricaltraffic model based on observed daily geomagnetic dataprovided by National Oceanic And Atmospheric

Administration (NOAA). [14] The geomagnetic dataprovides us the most realistic picture of the geomagneticactivities MMS is trying to study, thus it can be used informing a realistic traffic model for MMS mission. Thegeomagnetic K-index ranges from 0 to 7, measured everythree hours. We interpret the K-index in the followingway: an index with value 5 or higher represents highlevel of geomagnetic activities and a high science datageneration rate (104kbps for MMS); an index value of 4or less represents low level of activities and low sciencedata generation rate (18kbps for MMS).

5.1 Scenario 1 We first consider the case when there is only onemission spacecraft in orbit. The simulation starts at time0, when the satellite is at its perigee. The simulationparameters are as following:

1. Satellite data generation rate = 104kbps for all thetime.

2. The transmission window size is set to 4hours, andis allocated as [0, 2] U [22, 24].

3. Satellite transmitter EIRP = 14dbW

4. Satellite transmission rate = 1mbps

5. Simulation duration = 28 hours

Results are shown in Fig 5,6 and 7. The figuresshow that the mission satellite is choosing a properground station as receiver without scheduling in advance,and that with a 4-hour transmission window, we cancompletely download all the data generated by one MMSmission satellite, because the onboard queue is emptiedin Fig 7.

A simple calculation can give us some idea aboutthe minimum transmission window size if we want todownload all the generated data to the ground. If thesatellite is generating data at 104kbps for one day, theminimum transmission window would be

T_MIN = 104kbps * 3600 * 24 / 1Mbps

= 8985 seconds @ 2.5 hours (2)

Our simulation results showed that [3], if thetransmission window is allocated symmetrically aroundtime 0 (the time when the satellite is at its perigee), then

6American Institute of Aeronautics and Astronautics

a total transmission window of 3 hours is needed todownload all the data generated by the missionspacecraft at 104kbps. The extra 0.5hour difference isneeded here because there is a small coverage gap whenthe satellite is around its perigee, which can be seen inFig. 5 and 6, and because the transmitter doesn’t work atits full rate when the onboard queue is empty.

5.2 Scenario 2We now consider the case when all four satellites

are on orbits. We notice the following two facts aboutthis mission:

1. The orbits of all four MMS satellites are veryclose, especially around the perigee when theycan transmit to ground.

2. The traffic patterns of all four satellites arevery similar, if not identical.

These two facts above mean that we can effectivelyuse just one combo satellite to model the data generationand transmission behaviors of all four satellites. And thatcombo satellite would generate four times as much as asingle MMS satellite would. Thus this combo satellitewill have a burst data generation rate of 104*4=416kbpsand a normal data generation rate of 18*4=72kbps. Sowe use the same simulation setup as we had before, butset the burst rate and normal rate to be 416kbps. Thecombo satellite will have four times the storage capacityone MMS satellite has, which is 28*4=112Gb.

So we run simulation with the followingparameters:

1. Satellite data generation rate = 104kbps for allthe time.

2. No transmission window restriction, satellitecan transmit whenever a receiver is available.

3. Satellite transmitter EIRP = 14dbW

4. Satellite transmission rate = 1mbps

5. Simulation duration = 29 hours

The results are shown in Fig.8 and Fig. 9. From Fig.8 and 9, we can tell that, with this system setup, all thedata generated by the combo satellites can not becompletely downloaded. This means that when weactually have four MMS satellites in operation and allgenerating maximum amount of data, then if the systemparameters are as above and the total downlink capacityfixed at 1mbps, then using DSN only can’t provideenough coverage for full data download. This is becauseany multi-access protocol will have a bandwidthefficiency less than 100%, which will results in a smallerscience data throughput of the system than the heuristicsystem using one combo satellite.

The minimum extra amount of coverage time neededto download all data with this system setup can beestimated as below:

The amount of accumulated data onboard at time19h30m is 22.5Gbits, as shown in Fig. 9. Let theminimum amount of time to download the 22.5Gbaccumulated data and the newly generated data after that(at 416kbps) be x. It can be solved from the followingequation:

xMbpsxMbpsMb *3600*1*3600*416.0)(22500 =+

(3)

The solution is: x=10.7 hour

While the total coverage time DSN provided toMMS satellites for every 24-hour period is about 9 hours,as shown in Fig.9. Thus we have a deficit of 1.7 hour forevery 24-hour period.

5.3 Scenario 3To increase the amount of data we can download

from MMS satellites, we can either increase the data rateof the downlink, or we can look for other ground stationsto provide extra coverage, or we can reduce theminimum acceptable SNR for received data which inturn means increased coverage.

In this scenario, we increase the downlink data ratefrom 1mbps to 2mbps (the range of downlink data rateplanned for MMS is between 1 and 2.2mbps [1]). Thesimulation set up is the same as in scenario 2, except thatthe downlink data rate is now 2mbps instead of 1mbps.The results are shown in Fig.10 and 11.

Besides the maximum data rate, another obviousdifference between Fig. 8 and Fig. 10 is the totalcoverage time. The coverage when the downlink rate is2mbps is substantially less than when the data rate is1mbps. The reason is simple. When the transmitterpower is fixed, the average energy per data bit decreaseswhen the data rate increase, so will the coverage time,which can be seen from Eq. 1. So there is a trade-off ofincreasing data rate and reduced coverage.

Fig.10 and 11 show that not all data is downloadedeven with the doubled 2mbps downlink rate. An estimateof minimum amount of coverage time needed todownload all data generated can be calculated the sameway as we did earlier in Eq. 3.

xMbpsxMbpsMb *3600*1*3600*416.0)(28000 =+ (4)

The solution is x=4.91hour = 4h55m.

The total coverage is about 4h53m – 13m = 4h40m,in which 13m is the amount of coverage gap for MMSsatellite around perigee, see Fig. 12.

So we have a deficit of 15 minutes of coveragetime. However, this small deficit can be fairly easilycompensated by either slightly decreasing the requiredSNR margin for acceptable received signal, or by slightlyincreasing the EIRP of the transmitter. But again, thisperformance is the upper limit of what we can get if weactually have four satellites on orbit, because all multi-access schemes have bandwidth efficiency less than100%.

6 Conclusions and Further Work In this paper, we outlined the communication

architecture for future space communication supportnetwork. We proposed a bandwidth-efficient dynamicon-demand routing protocol for future mission support,and it’s demonstrated in principle in our MMSsimulations that I can automatically direct data downloadfrom mission spacecraft. We showed that DSN canprovide enough coverage for downloading data generatedby one MMS satellite. By using a combo node, weobtained upper limits of data downloading capabilityprovided by DNS ground stations. However, we needmore detailed implementation of the routing algorithmand an reasonable multi-access protocol to simulate theactual network performance of the MMS mission with

7American Institute of Aeronautics and Astronautics

four satellites. We also need to study the performance ofSODR when the network consists of a relatively largenumber of spacecraft and when inter-satellite links arepresent. Orbit and location information of spacecraft mayalso be used to improve the performance of SODR in thefuture. In the future, we would also like to show theperformance of SODR when implemented as a sourcerouting protocol and compare it when our currentimplementation.

Figure 5: Satellite transmitter throughput (bps)

Figure 6: Ground receivers’ throughput

Figure 7: Satellite Queue Size (bits)

Figure 8: Combo Satellite Transmitter Throughput

Figure 9: Combo Satellite Onboard Cache Size

Figure 10: Combo Satellite TX Throughput

Figure 11. Combo Satellite Onboard Cache Size

8American Institute of Aeronautics and Astronautics

Figure 12. Coverage Gap

Acknowledgements: This work is supported bythe Center for Satellite and Hybrid CommunicationNetworks, under NASA cooperative agreementNCC3-528

References

1. Report of the NASA Science and TechnologyDefinition Team for the Magnetospheric Multiscale(MMS) Mission, December 1999.

2. Draft for Community Comment, Announcement ofOpportunity MMS Mission, June 17, 2002, A)_02-OSS-XX.

3. M. Hadjitheodosiou, Y. Chen, “A Case Study onOptimizing Communications for ConstellationSpace Missions”, (to appear in) the Proceeding of2003 IEEE Wireless Communication & NetworkingConference, 16-20 March, 2003, New Orleans, LA.

4. J. Broch, D.B. Johnson, and D.A. Maltz, “TheDynamic Source Routing Protocol for Mobile AdHoc Networks”, IETF Internet draft, draft-ietf-manet-dsr-01.txt, Dec. 1998

5. D.B. Johnson, D.A. Maltz and J. Broch, “DSR, TheDynamic Source Routing Protocol for MultihopWireless Ad Hoc Networks”, Ad Hoc Networking:139-172, Addison-Wesley, 2001.

6. S. Curtis, J. Mica, J. Nuth, and G. Marr, “ANTS(Autonomous Nano Technology Swarm): AnArtifical Intelligence Approach To Asteroid BeltResource Exploration”, Presented at 51st

International Astronautical Congress, 2-6 Oct2000/Rio de Janeiro, Brazil.

7. Bhasin K., Hayden J., “Space Internet Architecturesand Technologies for NASA Enterprises”,Proceedings of the 2001 IEEEE AerospaceConference, Big Sky, MT, March 12-16, 2001.

8. NASA Space Communications Project Website:http://scp.grc.nasa.gov

9. James Cutler, Gregory Hutchins, Christopher Kitts,Robert Twiggs, “Infrastructure for Internet BasedOperations”, Proceedings of the 2000 AIAA SmallSatellite Conference, Logan Utah, September 2000.

10. Eylem Ekici, Ian F. Akyildiz, and Michael D.Bender, “Datagram Routing Algorithm for LEOSatellite Networks”, Proceedings of INFOCOM

2000, Tel Aviv, Israel, March 28-30, 2000, pp. 500-508

11. H. S. Chang, B. W. Kim, C. G. Lee, Y. Choi, S. L.Min, H. S. Yang, and C. S. Kim, “TopologicalDesign and Routing for Low-Earth Orbit SatelliteNetworks”, Proc. Of IEEE GLOBECOM 95, pp.529-535, 1995

12. C. E. Perkins, E. M. Royer, “Ad hoc on demanddistance vector (AODV) routing (Internet-draft)”,Mobile Ad-hoc Network (MANET) WorkingGroup, IETF, Aug. 1998.

13. S. Nesargi and R. Prakash, “A Tunneling Approachto Routing with Unidirectional Links in Mobile Ad-Hoc Networks”, Proceedings of the IEEEInternational Conference on ComputerCommunications and Networks (ICCCN), LasVegas, October 16-18, 2000.

14. National Oceanic And Atmospheric Administrationwebsite: http://sec.noaa.gov/Data/geomag.html