1
Cooperative multi-agent systems
• In cooperative MAS agents strive to reach a common goal and increase the combined utility of their actions
• Limitations on computational power and bandwidth prohibit the global view of the task structure
• Exchange of complete local views between agents is prohibitive
• Need to find a trade-off between the amount of information exchanged and the negotiation’s contribution to increasing combined utility
2
Contribution
The proposed negotiation protocol:
– Empirically shown to approach the utility of distributed agents’ actions very close to that of their aggregation
– Multi-parameter
– Uses marginal utility gain and cost to drive the negotiation
3
Assumptions
• Agents possess local views of the task structures that define their functionality
• Agents have access to a scheduler that takes a task structure and utility function as input and produces a set of schedules that increase the utility function locally
4
Motivating example: task allocation
The agent needs a certain non-local task to be performed by some other agent.
The negotiation’s goal is to increase the combined utility of actions of both agents by choosing a certain quality and time range of the non-local task.
5
Vocabulary 1
• Contractor – agent that has a non-local task NL that needs to be assigned to another agent
• Contractee – agent that performs this task for the contractor
• Utility – weighted sum of quality, cost, and duration of a schedule
6
Vocabulary 2
• Marginal utility gain (MUG) – local utility increment for the contractor with NL performed
• Marginal utility cost (MUC) – local utility decrement for the contractee with NL performed
7
Motivating example: task structures
TCR
Task1 Task2
M1 M2 M4 M5M3
sum
sum sum
q:10c:10d:9
q:10c:10d:9
q:10c:10d:9
q:15c:0d:0
q:10c:10d:9
deadline:50
enables enables
TCE
Task1 Task2
B1 B2 B3 B4
sum
sum sum
q:10c:10d:9
q:10c:10d:9
q:10c:10d:9
q:10c:10d:9
deadline:47
enables
deadline:11 deadline:21
8
Contractor’s FSM
buildProposal
always
sndMsgProposal
Wait
EvalCounterProposal
Finish
NewProposal
rcvMsgCounterProposal
evalCounterProposal
Reject
sndMsgReject
Accept&GetNext
Accept&HaveEnoughsndMsgFinish
always
generateNewProposalsndMsgProposal
rcvMsgAccept&HaveEnough
sndMsgFinish
rcvMsgAccept&GetNext
Start
9
Contractee’s FSM
Start EvalProposal
Wait
Finish
rcvMsgProposal
evalProposal
Accept
sndMsgAccept
rcvMsgFinishReject
buildCounterProposalsndMsgCounterProposal
rcvMsgReject
10
Binary search approachEach next proposal is the midpoint between the contractor’s
current proposal and contractee’s current counter proposal.Disadvantages:• Finish time of first counter proposal may not be the actual
reasonable finish time• Negotiation is about multiple issues (time range, quality)
while the binary search focuses only on finish time• Binary search requires greater certainty about NL’s time
range• Both agents are likely to cling to their own proposals,
greater the likelihood that some solutions are missed.
11
Proposal/counterproposal information
• EST - Earliest start time of the non-local task NL
• FT - Finish time
• minq - Requested quality
• MUC - Marginal utility cost
• MUG - Marginal utility gain
12
Protocol functions overview
• buildProposal:– Creates the initial contractor’s proposal
including the time range and quality of NL and MUG
– Insists on highest local utility by executing NL according to the contractor’s best local schedule
13
Protocol functions overview
• generateCounterProposal:– Creates the contractee’s counter proposals
including the time range and quality of NL and MUC
– Initially insists on highest local utility by executing NL according to the contractee’s best local schedule
14
Protocol functions overview
• generateCounterProposal:– Tries to increase combined utility by lowering
MUC– Successive counter proposals relax the time
range and quality of NL until a schedule is found s.t. MUG>MUC
15
Protocol functions overview
• generateNewProposal:– Creates the next contractor’s proposal based on
the preceding proposal or counter proposal
16
Protocol functions overview
• generateNewProposal:– Tries to increase combined utility by doing
multi-parameter heuristic-based search in quality and time range space
17
Protocol functions: buildProposal
• buildProposal: – produces the initially requested earliest start
time and finish time of the non-local task according to the contractor’s best schedule
– has limited information about the NL’s quality, cost, and duration
– the greater the time range of NL’s execution is the closer to the high bound the requested quality is
18
Protocol functions: generateCounterProposal
• If no previous Counter Proposal exists:– produces a “what-if” local contractee’s schedule
ignoring the time range and quality of NL in the current proposal, but enforcing NL to be in the schedule, thus delivering the minimum marginal utility cost for the NL
• If there is a previous Counter Proposal :– Alternatively relaxes the NL’s time range and lowers
the requested quality from the current proposal until an acceptable schedule is found (MUG>MUC)
19
Protocol functions: generateNewProposal 1
• If Previous Proposal is acceptable for the contractee:– If the NL is out of initial time range and its quality
below average then increase the quality request and make later the deadline for the NL
– If the NL is in initial time range and its quality is above average then reduce quality request in the same time range thus trying to lower MUC
– Otherwise shift time range later and reduce quality request thus trying to lower MUC
20
Protocol functions: generateNewProposal 2
• If Previous Proposal is not acceptable for the contractee:– If this is first counter proposal:
• If the initial time range is too short then the deadline is moved later and lower quality is requested
• Otherwise make the initial range a bit longer than the current estimate of NL’s execution time and request higher than average quality
21
Protocol functions: generateNewProposal 3
– If this is not first counter proposal• Assume a previous counter proposal from the
contractee as current proposal
• If requested quality above average then shift the time range later
• If requested quality below average then request higher quality and shift the NL’s deadline later
22
Modified task structure
TCE
Task1 Task2
B1 B2 B3 B4
sum
sum sum
q:10c:10d:9
q:10c:10d:9
q:15c:0d:0
q:10c:10d:9
deadline:47
enables
deadline:11 deadline:21
New_TCE
M4
M41 M42 M43
exactly_one
sumTCR
Task1 Task2
M1 M2 M4 M5M3
sum
sum sum
q:10c:10d:9
q:10c:10d:9
q:10c:10d:9
q:15c:0d:0
q:10c:10d:9
deadline:50
enables enables
23
Protocol variants
• Single step: the contractor sends a proposal PC to the contractee which accepts it if MUG(PC)>MUC(PC) or rejects it otherwise
• Multi-step-Multiple-Try: the agents perform the negotiation process until a predefined number of acceptable solutions are found or iteration limits are exceeded
• Multi-step-Limited-Effort: the agents perform the negotiation process until iteration limits are exceeded
24
Experiment task structures
TCR
Task1 Task2
M1 M2 M4 M5M3
sum
sum sum
q:10c:10d:9
q:10c:10d:9
q:15c:0d:0
q:10c:10d:9
deadline:50
enables enables
q:10c:10d:9
enables
est:10 est:24
TCE
Task1 Task2
B1 B2 B3 B4
sum
sum sum
q:10c:10d:9
q:10c:10d:9
q:15c:0d:0
q:10c:10d:9
deadline:47
enables
deadline:11 deadline:21
enablesenables
25
Utility function
• S – schedule
Utility(S) = quality_gain(S)*quality_weight +
cost_gain(S)*cost_weight +
duration_gain(S)*duration_weight
26
Collected data
• Negotiation outcome: success if the combined utility is increased
• Utility gain: MUG - MUC
• Gain percentage: percentage of utility gain relative to the combined utilities without the task allocation
• Solution quality: utility percentage relative to the utility of the combined tasks
• Complexity of task structures: function of the number of interrelationships and temporal constraints in the task structures
• Number of negotiation steps (proposal/counterproposal messages).
27
Protocol comparisonSuccess Average Gain
PercentageANNS Gain per
StepSolution
Quality
Single-step 2850 7.63 1.0 7.63 94.43
Multi-step-One-Try
4088 10.17 1.48 6.87 96.69
Multi-step-Two-Try
4088 11.9 4.69 2.55 98.23
Multi-step-Three-Try
4088 13.4 6.42 2.09 99.51
Multi-step-Limited Effort 4088 13.9 8.15 1.7 99.93
28
Complexity
• ir1 – number of interrelationships in contractor’s task structure
• tr1 – number of temporal constraints in the contractor’s task structure
• ir2 – number of interrelationships in contractee’s task structure
• tr2 – number of temporal constraints in the contractee’s task structure
Complexity of task structure = ir1 + tc1 + ir2 + tc2 + (ir1*tc1 + ir2*tc2 + ir1*ir2 + tc1*tc2 + ir1*tc2 + ir2*tc1)/6
29
Dependence of SQ on complexity
88
90
92
94
96
98
100
102
0 5 10 15 20complexity of task structures
so
luti
on
qu
ali
ty
MultiStepLimitedSearchMultiStepThreeTryMultiStepTwoTryMultiStepOneTrySingleStep
30
Net negotiation gain
Assume that one negotiation step costs 0.5% of the overall utility of the negotiating agent’s schedules
Net negotiation utility gain = negotiation utility gain – negotiation effort
31
Dependence of net gain on complexity
88
90
92
94
96
98
100
102
0 5 10 15 20complexity of task structures
ne
t n
eg
oti
ati
on
ga
in
MultiStepLimitedSearchMultiStepThreeTryMultiStepTwoTryMultiStepOneTrySingleStep
32
Observations
• The Multi-step-One-Try protocol is much better than Single step in almost all situations(except for very simple ones)
• The Multi-step-Two-Try and Multi-step-Three-Try protocols are useful in moderately constrained situations
• The number of constraints can be used to choose a protocol that balances negotiation gain and effort for a certain situation