Cooperative multiagent systems In cooperative MAS agents strive

  • Slides: 32
Download presentation
Cooperative multi-agent systems • In cooperative MAS agents strive to reach a common goal

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 1

Contribution The proposed negotiation protocol: – Empirically shown to approach the utility of distributed

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 2

Assumptions • Agents possess local views of the task structures that define their functionality

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 3

Motivating example: task allocation The agent needs a certain non-local task to be performed

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. 4

Vocabulary 1 • Contractor – agent that has a non-local task NL that needs

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 5

Vocabulary 2 • Marginal utility gain (MUG) – local utility increment for the contractor

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 6

Motivating example: task structures TCR TCE sum Task 1 Task 2 sum M 2

Motivating example: task structures TCR TCE sum Task 1 Task 2 sum M 2 Task 2 sum enables M 1 Task 1 sum enables M 3 M 4 q: 10 c: 10 d: 9 q: 15 c: 0 d: 0 M 5 q: 10 c: 10 d: 9 deadline: 50 enables B 1 B 2 q: 10 c: 10 d: 9 deadline: 11 deadline: 21 B 3 q: 10 c: 10 d: 9 B 4 q: 10 c: 10 d: 9 deadline: 47 7

Contractor’s FSM rcv. Msg. Counter. Proposal always eval. Counter. Proposal build. Proposal snd. Msg.

Contractor’s FSM rcv. Msg. Counter. Proposal always eval. Counter. Proposal build. Proposal snd. Msg. Proposal Start Wait always rcv. Msg. Accept& Have. Enough snd. Msg. Finish Eval. Counter. Proposal Accept&Have. Enough snd. Msg. Finish Reject snd. Msg. Reject rcv. Msg. Accept& Get. Next Finish generate. New. Proposal snd. Msg. Proposal Accept&Get. Next New. Proposal 8

Contractee’s FSM rcv. Msg. Reject Wait rcv. Msg. Proposal eval. Proposal Start Eval. Proposal

Contractee’s FSM rcv. Msg. Reject Wait rcv. Msg. Proposal eval. Proposal Start Eval. Proposal Reject rcv. Msg. Finish build. Counter. Proposal snd. Msg. Counter. Proposal Accept Finish snd. Msg. Accept 9

Binary search approach Each next proposal is the midpoint between the contractor’s current proposal

Binary search approach Each 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. 10

Proposal/counterproposal information • EST - Earliest start time of the non-local task NL •

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 11

Protocol functions overview • build. Proposal: – Creates the initial contractor’s proposal including the

Protocol functions overview • build. Proposal: – 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 12

Protocol functions overview • generate. Counter. Proposal: – Creates the contractee’s counter proposals including

Protocol functions overview • generate. Counter. Proposal: – 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 13

Protocol functions overview • generate. Counter. Proposal: – Tries to increase combined utility by

Protocol functions overview • generate. Counter. Proposal: – 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 14

Protocol functions overview • generate. New. Proposal: – Creates the next contractor’s proposal based

Protocol functions overview • generate. New. Proposal: – Creates the next contractor’s proposal based on the preceding proposal or counter proposal 15

Protocol functions overview • generate. New. Proposal: – Tries to increase combined utility by

Protocol functions overview • generate. New. Proposal: – Tries to increase combined utility by doing multi-parameter heuristic-based search in quality and time range space 16

Protocol functions: build. Proposal • build. Proposal: – produces the initially requested earliest start

Protocol functions: build. Proposal • build. Proposal: – 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 17

Protocol functions: generate. Counter. Proposal • If no previous Counter Proposal exists: – produces

Protocol functions: generate. Counter. Proposal • 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) 18

Protocol functions: generate. New. Proposal 1 • If Previous Proposal is acceptable for the

Protocol functions: generate. New. Proposal 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 19

Protocol functions: generate. New. Proposal 2 • If Previous Proposal is not acceptable for

Protocol functions: generate. New. Proposal 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 20

Protocol functions: generate. New. Proposal 3 – If this is not first counter proposal

Protocol functions: generate. New. Proposal 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 21

Modified task structure New_TCE TCR sum TCE Task 1 Task 2 sum M 1

Modified task structure New_TCE TCR sum TCE Task 1 Task 2 sum M 1 M 2 Task 1 enables M 3 M 4 q: 10 c: 10 d: 9 q: 15 c: 0 d: 0 Task 2 sum deadline: 50 M 41 M 42 M 43 sum M 5 q: 10 c: 10 d: 9 exactly_one sum enables M 4 enables B 1 B 2 q: 10 c: 10 d: 9 deadline: 11 deadline: 21 B 3 q: 15 c: 0 d: 0 B 4 q: 10 c: 10 d: 9 deadline: 47 22

Protocol variants • Single step: the contractor sends a proposal PC to the contractee

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 23

Experiment task structures TCR TCE sum Task 1 Task 2 sum enables M 1

Experiment task structures TCR TCE sum Task 1 Task 2 sum enables M 1 enables M 3 M 4 q: 10 c: 10 d: 9 q: 15 c: 0 d: 0 est: 10 est: 24 M 5 q: 10 c: 10 d: 9 deadline: 50 Task 2 sum enables M 2 Task 1 enables B 1 sum B 2 q: 10 c: 10 d: 9 deadline: 11 deadline: 21 enables B 3 q: 15 c: 0 d: 0 B 4 q: 10 c: 10 d: 9 deadline: 47 24

Utility function • S – schedule Utility(S) = quality_gain(S)*quality_weight + cost_gain(S)*cost_weight + duration_gain(S)*duration_weight 25

Utility function • S – schedule Utility(S) = quality_gain(S)*quality_weight + cost_gain(S)*cost_weight + duration_gain(S)*duration_weight 25

Collected data • Negotiation outcome: success if the combined utility is increased • Utility

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). 26

Protocol comparison Success Average Gain Percentage Single-step ANNS Gain per Step Solution Quality 2850

Protocol comparison Success Average Gain Percentage Single-step ANNS Gain per Step Solution Quality 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 27

Complexity • • ir 1 – number of interrelationships in contractor’s task structure tr

Complexity • • ir 1 – number of interrelationships in contractor’s task structure tr 1 – number of temporal constraints in the contractor’s task structure ir 2 – number of interrelationships in contractee’s task structure tr 2 – number of temporal constraints in the contractee’s task structure Complexity of task structure = ir 1 + tc 1 + ir 2 + tc 2 + (ir 1*tc 1 + ir 2*tc 2 + ir 1*ir 2 + tc 1*tc 2 + ir 2*tc 1)/6 28

Dependence of SQ on complexity 29

Dependence of SQ on complexity 29

Net negotiation gain Assume that one negotiation step costs 0. 5% of the overall

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 30

Dependence of net gain on complexity 31

Dependence of net gain on complexity 31

Observations • The Multi-step-One-Try protocol is much better than Single step in almost all

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 32