330 likes | 509 Views
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
E N D
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
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
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
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.
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
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
Motivating example: task structures TCR TCE sum sum Task1 Task2 Task1 Task2 sum sum sum sum enables enables enables M1 M2 M3 M4 M5 B1 B2 B3 B4 q:10 q:10 q:10 q:10 q:10 q:15 q:10 q:10 q:10 c:10 c:10 c:10 c:10 c:10 c:0 c:10 c:10 c:10 d:9 d:9 d:9 d:9 d:9 d:0 d:9 d:9 d:9 deadline:11 deadline:21 deadline:47 deadline:50
Contractor’s FSM rcvMsgCounterProposal always evalCounterProposal EvalCounterProposal buildProposal sndMsgProposal Accept&HaveEnough sndMsgFinish rcvMsgAccept& HaveEnough Start Wait Reject sndMsgFinish sndMsgReject rcvMsgAccept& GetNext Finish always generateNewProposal sndMsgProposal Accept&GetNext NewProposal
Contractee’s FSM rcvMsgReject Wait rcvMsgProposal evalProposal EvalProposal Start rcvMsgFinish Reject buildCounterProposal sndMsgCounterProposal Accept Finish sndMsgAccept
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.
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
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
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
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
Protocol functions overview • generateNewProposal: • Creates the next contractor’s proposal based on the preceding proposal or counter proposal
Protocol functions overview • generateNewProposal: • Tries to increase combined utility by doing multi-parameter heuristic-based search in quality and time range space
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
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)
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
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
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
Modified task structure New_TCE TCR sum sum TCE M4 exactly_one Task1 Task2 sum sum sum Task1 Task2 M42 M43 M41 enables enables sum sum M1 M2 M3 M4 M5 enables q:10 q:10 q:10 q:15 q:10 B1 B2 B3 B4 c:10 c:10 c:10 c:0 c:10 q:10 q:10 d:9 d:9 d:9 d:0 d:9 q:15 q:10 c:10 c:10 c:0 c:10 deadline:50 d:9 d:9 d:0 d:9 deadline:11 deadline:21 deadline:47
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
Experiment task structures TCR TCE sum sum Task1 Task2 Task1 Task2 sum sum sum sum enables enables enables enables enables enables M1 M2 M3 M4 M5 B1 B2 B3 B4 q:10 q:10 q:10 q:10 q:10 q:15 q:10 q:15 q:10 c:10 c:10 c:10 c:10 c:10 c:0 c:10 c:0 c:10 d:9 d:9 d:9 d:9 d:9 d:0 d:9 d:0 d:9 deadline:11 deadline:21 deadline:47 est:10 est:24 deadline:50
Utility function • S – schedule Utility(S) = quality_gain(S)*quality_weight + cost_gain(S)*cost_weight + duration_gain(S)*duration_weight
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).
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
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
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