Jet Propulsion Laboratory
California Institute of Technology
Mark D. Johnston
Jet Propulsion Laboratory — California Institute of Technology
4800 Oak Grove Dr., Pasadena CA 91109 mark.d.johnston@jpl.nasa.gov
IWPSS 2006
1

Jet Propulsion Laboratory
California Institute of Technology
• The evolution of the NASA Deep Space Network
• The scheduling problem
– how scheduling the array differs from scheduling individual antennas
– perspectives, objectives, and constraints
• Multi-objective optimization
• A multi-objective optimization formulation of the array scheduling problem
• Results
– competing missions example
– a representative 2015 mission set
– scalability
• Conclusions
2
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• Current DSN comprises
– 3 sites roughly equally spaced in longitude
– 26m, 34m, 70m antennas, same at each site
• DSN supports all planetary missions + some earth orbiters
• Drivers on evolution include:
– more missions (3x by 2030)
– data rates and volumes increasing by 100x by 2030
– manned missions place stringent availability and reliability requirements
– more cluster (multi-spacecraft) missions
– reduce costs (operations and maintenance)
– maintain high level of 24x7 support
3
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• An array-based network links together large numbers of less expensive antennas
– possibly at 3 balanced sites like today’s DSN, but possibly unbalanced
– some designs call for ~400 antennas/site
• Array-based network offers advantages
– allocation of antennas can be more granular
– subsets of the array can be allocated to simultaneous communications with different spacecraft
– antenna allocation can be time-phased within a single pass
– unused antennas could be allocated on-the-fly in case of equipment failure or spacecraft emergency
An array-based network will be much more flexible, but will require an approach to planning and scheduling that can take advantage of this flexibility
4
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
An arraybased network presents some challenges not present in today’s DSN:
– Shift to higher frequency (especially Ka band) makes communications sensitive to the weather
• signal is attenuated in bad weather much more than for X and S bands
– There are some array-specific constraints
• a sufficient number of signal combiners must be available to support the scheduled simultaneous users
• there may be limitations on which subsets can be used for a contact based on physical layout of the array
– The array will not suddenly replace the current DSN, but will likely be an evolutionary development over many years and multiple sites
5
IWPSS 2006

From multiple users:
• mission status, capabilities & requirements
• new service requests
• changed service requests
DSN array scheduler
• site status
(availability, maintenance, performance)
• weather
• execution feedback
Jet Propulsion Laboratory
California Institute of Technology
• site schedules
7
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• User requirements drive the scheduling of the DSN
– missions place a variety of constraints and preferences into their requirements for communications support
• data downlinks
• command uplinks
• navigation and control
• critical events
• s/c emergencies
– other user categories include
• radio science
• radio astronomy
8
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• Mission objectives can be categorized based on how they relate to the schedule:
– pass-based objectives are defined in terms of specific allocations of antennas to missions over some time interval, called a “pass”
• e.g. 25 antennas at Goldstone dedicated to Mars Phoenix for 6 hours would be a single pass
• objectives may be defined with respect to attributes of the pass, including duration, timing relative to absolute time or to other passes, etc.
– service-based objectives are defined at a higher level and refer to missions needs in terms of how well a service requirement is satisfied
• e.g. a mission may specify that it needs an 8h downlink at a certain data rate every 3 days over some mission phase
– model-based objectives are even higher level and require the scheduler to model some aspects of mission behavior to asses
• e.g. need to download data often enough to keep onboard storage from capacity limit
9
IWPSS 2006

• A sample of mission service-based objectives:
Objective contact duration contact gap duration pass duration gap duration coverage fraction coverage level total gap duration pass time shift objective out of limit
Jet Propulsion Laboratory
California Institute of Technology
Description min and max limits on duration, where a contact is the union of the coverage intervals of overlapping passes min and max limits on the sizes of any gaps between contacts min and max limits on individual pass duration min and max limits on the sizes of any gaps between individual passes fraction of some specified time interval with scheduled contact coverage (e.g. “1” means continuous coverage) number of distinct passes simultaneously providing coverage (e.g.
“2” would mean simultaneous coverage at two different sites) total gap in coverage over a specified interval how much a pass has shifted in time from some baseline requested time extent to which an objective value exceeds a specified limit
10
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• To some approximation, we can collect the non-mission objectives into a single “system” user, representing the overall operations of the DSAN:
– satisfy the users of the system
• captured in users own objectives
– minimize operational costs
• this is largely a function of the system configuration, operations, and maintenance policies, and not likely to be affected much by schedule variations
– maximize system availability
• this is a core system objective — maximize the number of users serviced by a given investment in assets and infrastructure
• counterintuitively, maximize the number of unallocated antennas
11
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• Constraints are factors that must be satisfied in order for the schedule to be feasible
• Examples:
– visibility constraints
– resource limitations (total number of antennas over time)
– mission-originated constraints (e.g. must have contact around course correction maneuver)
• Some constraints may be formulated as quantitative measures on a schedule that represent degree of violation , and thus be treated like objectives
– this is particularly useful when no feasible schedule exists, and constraint relaxation must be considered
– in this context, the ability to exchange constraints and objectives is a useful feature to incorporate
12
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• Approach: multiobjective optimization
– keep objectives separate and combine only when necessary
• do not lose information that separate objectives contain
• allows an explicit view into the tradeoffs when building and changing the schedule
– define a very general approach to specifying objectives and constraints
• penalty function f () applied to schedule as viewed from the user’s perspective
• can switch constraints  objectives to investigate overconstrained situations
– use multiobjective optimization techniques based on evolutionary algorithms
• maintain a population of candidate schedules that evolves to optimize M>1 objectives
• population provides an estimate of the Pareto frontier (tradeoff surface)
• population provides a starting point for schedule changes
• easy to distribute for processing in parallel
• enables user visibility into schedule tradeoffs, thus supporting collaborative schedule development, repair, and negotiation
13
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• Formulated as a minimization problem for M objectives subject to
K constraints
• Population of N solution candidates
• With each step (generation), generate a new population following rules for crossover (combining parents to make offspring) and mutation (introducing random variations into offspring)
• Considered two algorithm families:
– NSGA II (Deb et al. 2002) elitist method, pioneered
• non-dominated sorting
• crowding distance
– GDE3 (Kukkonen and Lampinen 2005) extended NSGA II by using differential evolution (DE) to generate offspring
14
IWPSS 2006

IWPSS 2006
Jet Propulsion Laboratory
California Institute of Technology
GDE3 is based on differential evolution for single-objective optimization
(Price, Storn and Lampinen 2005)
1. For each parent, select three distinct population members, all different and different from parent
2. Calculate a trial vector as: where F is a scaling factor
3. Modify the trial vector by binary crossover with parent with probability CR
Compare offspring with parent as follows
– both infeasible: choose less violated in constraint violation space
– one feasible, other infeasible: choose feasible
– both feasible: choose dominating if present, else choose both
Then, if necessary, reduce population back to size N via non-dominated sorting and crowding distance (to improve diversity along Pareto frontier)
17

Jet Propulsion Laboratory
California Institute of Technology
• Time is quantized to arbitrary buckets
• Boundary conditions allow for contacts outside scheduling interval
– needed to compute objectives/constraints that depend on contacts external to schedule
• Background of fixed contacts is supported
– could be higher priority allocations
– could be a frozen part of the schedule when rescheduling
• Decision variables based on user/viewperiod:
IWPSS 2006 max min
# ant.
req.
time (x
1
, x
2
, x
3
)
# ant.
req.
time
19

Jet Propulsion Laboratory
California Institute of Technology
• Two (identical) users, 4 day schedule, 10 antenna “array”, but only 5 available on 2 nd day (“maintenance”)
• Each user requires 5 antennas per contact, prefers 12hr contacts and gaps
<18hr, requires at least 3hr contacts; there is one 12hr viewperiod/day
• Initial population randomized (diversity helps search, especially in more complex situations) user 1 user 2
200 generations
2 sec runtime
(10K schedules/sec)
IWPSS 2006 user 1 penalty
 constraint viol.
dominated non-dominated (Pareto frontier) user 1 penalty

20

IWPSS 2006
Jet Propulsion Laboratory
California Institute of Technology
21

Jet Propulsion Laboratory
California Institute of Technology
• More extensive experiments were conducted on a model representative of a
2015 mission set:
– 17 missions requiring from 1 to 94 antennas for each pass
– periodic pass requirements over a range of time intervals (every 8 hours to once/week), with pass durations ranging up to 12 hours
– 3 sites, each with 100 antennas, equally spaced in longitude
– one week scheduling interval (760 decision variables)
• Model was used to explore:
– algorithm convergence and performance
– scalability with population size
– scalability with schedule time resolution
24
IWPSS 2006

• Results are very encouraging:
– Initial experiments comparing NSGA and GDE3 showed the latter to be superior
– GDE3 does a good job of finding a feasible population then optimizing and filling out the Pareto surface
– scalability with population size N is proportional to N log N
– scalability with time resolution is linear
Jet Propulsion Laboratory
California Institute of Technology
25
IWPSS 2006

Jet Propulsion Laboratory
California Institute of Technology
• Strengths of multi-objective formulation:
– explicit and separate representation of each mission’s objectives, making it easy to consider tradeoffs
– a population of solutions approximating the Pareto frontier, useful in scheduling selection and as a starting point when revising the schedule
• Results to date are encouraging in terms of convergence to Pareto frontier, scalability, and diversity of coverage
• Plans for future work include:
– modifying an existing schedule quickly and effectively e.g. to respond to changed scheduling requirements or s/c emergencies
– incorporating risk mitigation into the schedule, e.g. to optimally allocate unused antennas as a hedge against bad weather
– parallelizing the implementation to take advantage of grid or other distributed computing resources
26
IWPSS 2006