Distributed Network Scheduling

Bradley J. Clement, Steven R. SchafferJet Propulsion Laboratory, California Institute of Technology

Contact: {firstname.lastname}@jpl.nasa.gov

Abstract

Distributed Network Scheduling is the scheduling of future communications of a network by nodes in the network. This report details software for doing this onboard spacecraft in a remote network. While prior work on distributed scheduling has been

applied to remote spacecraft networks, the software reported here focuses on modeling communication activities in greater detail and including quality of service constraints. Our main results are based on a Mars network of spacecraft and include identifying a

maximum opportunity of improving traverse exploration rate by a factor of three; a simulation showing reduction in one-way delivery times from a rover to Earth from as much as 5 to 1.5 hours; simulated response to unexpected events averaging under an

hour onboard; and ground schedule generation ranging from seconds to 50 minutes for 15 to 100 communication goals.

References

• I. Akyildiz, O. Akan , C Chen, J. Fang, W. Su. InterPlaNetary Internet: state-of-the-art and research challenges. Computer Networks, 43, 75–112, 2003.• S. Chien, G. Rabideau, R. Knight, R. Sherwood, B. Engelhardt, D. Mutz, T. Estlin, B. Smith, F. Fisher, T. Barrett, G. Stebbins, D. Tran , ASPEN - Automating Space Mission Operations using Automated Planning and Scheduling, Proc. SpaceOps 2000, Toulouse, France, June 2000.• B. Clement, A. Barrett. Continual Coordination through Shared Activities. 2nd International Conference on Autonomous and Multi-Agent Systems (AAMAS 2003). Melbourne, Australia. July 2003.• B. Clement, A. Barrett, S. Schaffer. Argumentation for Coordinating Shared Activities. Proc. IWPSS, June 2004.• B. Clement, S. Schaffer. Distributed Network Scheduling. The Interplanetary Progress Report, 42(156), February 2004.• R. Sherwood, B. Engelhardt, G. Rabideau, S. Chien, R. Knight. ASPEN User’s Guide. JPL Technical Document D-15482, http://www-aig.jpl.nasa.gov/public/planning/aspen/, February 2000.

Portions of this work were carried out at the Jet Propulsion Laboratory, California Institute of Technology, under contract to NASA.

IWPSS June 2004

For more information about this work, contact: Brad ClementJet Propulsion Laboratory MS 126-3474800 Oak Grove DrivePasadena, CA 91109-8099Email: brad.clement@jpl.nasa.govTel: +1 (818) 393-4729

0

50

100

150

200

250

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

number of goals per spacecraft

seco

nd

s

mean system timemin system timemax system timeLinear (min system time)Linear (mean system time)Linear (max system time)

0.01

0.1

1

10

100

1000

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

number of goals per spacecraft

cp

u s

ec

on

ds

mean cpu time

max cpu time

min cpu time

Linear (min cpu time)

Linear (mean cpu time)

Linear (max cpu time)

• The middleware component provides an application-level interface to the communications protocol stack.

• The distributed planning interface receives requests, instantiates goals in the planner, and manages the negotiation process. The distributed planning interface returns the schedule and QoS information to the requestor as a reservation.

• The planner schedules communications to achieve the goals with help from adaptive communication algorithms. It does this by providing contextual information about the future network state and the communication goal in question.

• The adaptive algorithms then simulate and report how data will be transferred and with what quality of service (QoS).

Distributed network scheduler architecture

Planner/Scheduler

distributedplanning interface

Spacecraft

adaptive comm.interface

user

reservations,status/QoS

Middleware adaptive comm.algorithms

contextrouting,protocol,QoS decisions

Spacecraftrequests

requests

reservations,status/QoS

Planner/Scheduler

distributedplanning interface

Spacecraft

adaptive comm.interface

user

reservations,status/QoS

Middleware adaptive comm.algorithms

contextrouting,protocol,QoS decisions

Spacecraftrequests

requests

reservations,status/QoS

int id – index for trackingstring source – who is sending data string destination – who is receiving the dataint size – estimate of size of data to be sent in Kbitsreal bandwidth_min – minimum required bandwidth Kbits/sreal bandwidth_max – maximum usable bandwidth in Kbits/sreal priority – importance of fulfilling request (larger numbers indicate greater importance)int start_time_min – minimum requested start time of communicationint start_time_max – maximum requested start time of communicationint duration_min – minimum needed time duration of initial data transmissionint duration_max – maximum requested time duration of initial data transmissionint delivery_time_min – minimum required delivery timeint delivery_time_max – maximum requested delivery timebool progressive – whether data is recreated as it is received (= true) or transmission is only valuable when completed, i.e. all or nothing (= false)real loss_overall – maximum percentage loss tolerance of overall datareal loss_per_block – maximum percentage loss tolerance for any blockreal loss_block_size – size of block for which the loss tolerance is specifiedstring protocol – what protocol(s) should be used for transmission and with what options (e.g. CFDP -noack); this string has no generic structure and is to be generated and interpreted by adaptive communications software through an interface.

Communication requests, reservations, and status

imagesinteresting

rock

downlinkimages uplink

response

backtrack to rockfor experiments

continue traverse

imagesinteresting

rock

downlinkimages uplink

response

backtrack to rockfor experiments

continue traverse

0.30.40.50.60.70.80.9

1

0.01 0.1 1 10 100

# comm opportunities / # of rocks

eff

ec

tiv

e v

elo

cit

y /

rov

er

ve

loc

ity

Effect of adaptively scheduling communication on rover exploration performance

Rover backtracking to study a rock during a traverseIn worst case, rover traverses same terrain 3 times

The effect of increasing communication opportunities on rover exploration speed

Effect of adaptive re-schedulingon rover communication delay

Simulation shows reduction in one-way delivery times from a rover to Earth from as much as 5 to 1.5 hours

Mars network relay experiments

Shared Activity Coordination

SHACSHAC

ExecutionSystem

ExecutionSystem

SHACSHAC

ExecutionSystem

ExecutionSystem

SHACSHAC

CASPER CASPER CASPER

goal, constraint,& role updates

goal, constraint,& role updates

ExecutionSystem

ExecutionSystem

SHACSHAC

ExecutionSystem

ExecutionSystem

SHACSHAC

ExecutionSystem

ExecutionSystem

SHACSHAC

CASPER CASPER CASPER

goal, constraint,& role updates

goal, constraint,& role updates

ExecutionSystem

ExecutionSystem

Actual time to schedule a single goal

CPU time for scheduling a single goal

SHACSHAC

MGSMEX Odyssey

MER A MER B