Cooperative Negotiation Schemes for Distributed Resource Allocation

1
Cooperative Negotiation Schemes for Distributed
Resource Allocation
Martin Frank and Pedro Szekely(with Bob Neches,
Min Cai, Alejandro Bugacov, Jinbo Chen, and
Donghan Kim)AFOSR GRANT NUMBER
F49620-01-1-0341Distributed Scalable Systems
DivisionInformation Sciences InstituteUniversity
of Southern California Annual Review
SummaryFebruary 7, 2003http//www.isi.edu/marble
s
2
Objective Distributed, Adaptive
Real-TimeWeapon-Target Pairing for UCAV Swarms
Enable UCAVs to autonomously and effectively
adapt weapon-target pairings in the face of
targetgone
UCAVlost
intermittent link
newtargetdetected
laser designatornon-operational
link out
Communication Disruptions
Changing Situations,
Degraded Capabilities,
by developing distributed algorithms that are
poor connectivity...lets go with a
lesscommunication-intensivesynchronization
protocol...
abandoning target 4 toattack higher-valuedtarget
5 with UCAV D...
not enough time...not initiating optimizationof
munitions for target 1...
adaptive,
real-time,
and robust
with quantifiably measurable effectiveness.
3
Approach Market-inspired Real-timeNetwork-aware
Cooperative Negotiation
Distinctiveness of Approach
Overview of Approach

• Model targets as tasks and the UCAVs weapons
  systems as resources
• Execute a market-inspired Marbles resource
  allocation scheme that naturally steers resources
  to their best use without central coordination
• Reason explicitly about the cost versus the
  benefit of initiating new communication in the
  face of an upcoming deadline, taking measured
  communications quality into account

• Distinct from e-commerce and auctions research
  coordinated purposive action under changing
  communication conditions
• Unique concept of altruistic task withdrawal
  when time is running out so that competing tasks
  can succeed

4
Research Status Testing Multi-UCAV Missions in
Simulation
Simulated Message Passing between UCAVsusing
MARBLES Negotiations

• Technical Focus To-Date
• Decentralization
• Scalability
• Fault tolerance against messaging failures/delays
• Solution within deadline

Taking on A at 0445Z with my Hellfire-1, with 04
designating. Could take on B with my Hellfire-2
if someone else can designate.
Designating A for 02 at 0445Z.Designating C for
07 at 0430Z.Designating D for 07 at 0500Z.

• Current Technical Focus
• Adaptivity to situation changes (includes
  quantifying adaptivity, i.e. how often can the
  swarm re- target per minute?)
• Fault tolerance against sudden UCAV death
  (includes quantifying tolerance as well)

A value 200B value 600C value 400D value
100
Bidding 200 marbles for useof your laser
designator for Bat 0430Z or 0500Z.Respond no
later than 0420Z.
Taking on C at 0430Z with 04 designating. Taking
on D at 0500Z with 04 designating.
Reneging on designating D(to take on
higher-valuedB with 02 at 0500Z).
5
Results Showed Feasibility of Decentralized
Planning without Loss of Quality, Despite
Communication Disruptions
More Robust Against Message Loss
QUALITY (more better)
Same Quality
Problem Number
COMPUTATION TIME (less better)
10X faster
Problem Number
6
Spin-off Benefit Near-term Transition to USMC
via Incorporation into SNAP Flight Scheduling
Software
C. Solution Quality Metrics. Shown here are (1)
the projected Combat Readiness Percentage (CRP)
and (2) the number of sorties scheduled.
A. The clock displays simulated time. It also
lets users give the system more or less time.
B. Distributed computation bars show CPU usage
on processors (only one is used here).
D. Resource Schedules display time horizontally
(five days with 24 one-hour slots each) and
resources vertically (16 pilots followed by 8
aircraft and then 8 ranges). Gray resource is
unavailable, blue booked, white free (and
always was), red free through renege on a prior
commitment, black free through sortie
decommitment.
E. Pilot Qualifications shows all possible
quals horizontally and the 16 pilots
vertically. Red qual that will expire this
week, yellow qual that was saved, blue
persisting qual, green freshly gained qual.
F. Commitments Display shows the 100 sorties
from left to right (the 94 green ones are
scheduled, the 6 black ones could not be
scheduled), and the 32 resources (pilots,
aircraft, ranges) from top to bottom. Black
resource not applicable, green current
commitment, yellow commitment was considered,
pink resource renege, gray sortie
decommitment.
The SNAP flight scheduling prototype is fielded
with Marine Air Group 13 and includes a basic
version of the MARBLES scheduling software.
G. Agent Communication Monitor visualizes
message traffic. There are 127 agents - 2
market agents that point to resource agents, 1
range agent, 100 sortie agents, 16 pilot agents,
and 8 aircraft/simulator agents. The agents are
shown on both axes. The diagonal line sums up all
communication by a single agent.
() This enhanced MARBLES version will allow the
squadrons scheduling officers to adapt an
existing schedule to a changed situation rather
than having to re-compute it from scratch, as
well as allow them to tell SNAP how much time
they can afford to allot it to re-plan a flight
schedule in the face of those changes.
Next step timely
adaptive schedule repair.
MAG 13 deployed with
our software to the Persian
Gulf on Jan. 17, 2003 onboard the
USS Richard Bonhomme, from which
this picture was taken on Jan. 19, 2003.
7
Extra Material
8
Example of a Marbles Cooperative Negotiation
Scheme for Weapon-Target Pairing
9
Animated Example of one MARBLESCooperative
Negotiation Scheme
10
Architecture Overview of MARBLES Contributions to
SNAP

• Jointly defined the schedulingproblem and
  solution APIs withthe DARPA-funded CAMERA
  andATTEND projects (Joint API).
• Contributed a (so far non-adaptive, not
  real-time) negotiation-basedsolver used by the
  version of SNAPdeployed to the Marine Corps.