To overcome this, resource agents must be SBDO wrappers around a centralized optimization algorithm. The centralized algorithm uses partial knowledge of each person agent’s preferences to attempt to schedule treatments. When there is a conflict between two agents, A and B, it must elicit more preferences from the agents. To do so it constructs a proposal using A as support to send to B, and a proposal using B as support to send to A. If more than two agents conflict, the algorithm chooses as support the set of assignments that leads to the best utility. The person agent’s response (or lack thereof) indicates their preferences. While the resource agent retains the person agent as a neighbour it caches the latest utilities received from the person agent.
In the standard SBDO algorithm, when an agent is removed from the set of neighbours all the knowledge related to that agent is also removed. Such loss poses problems in this setting. When a patient agent changes the resource it plans to use, it adds the new resource agent to its neighbours and removes the old one. However it must remember the utility gained from using the previous resource, both to ensure that the change leads to a better solution, and to ensure that it doesn’t change back if it does not like the new solution. These saved utility values do not have to be kept up to date, they simply serve to inform the agent’s later choices. Only person agents need to retain this information.
For every resource agent that a person agent contacts, the person agent must record the most recent local utility gain from the schedule offered by that agent. In other words, the value of the objective functions that depend, either directly or indirectly, on a variable controlled by that agent. The agent can then periodically compare the estimated utility gain from other resource agents, either a best guess or the stored value, to decide if it is worthwhile changing. To influence how often person agents change between resources, objective functions can be defined that emulate stability constraints in other algorithms. These serve to provide an estimate of both the cost associated with changing to a different resource, and the probable utility gain.
5.3
Traffic Scheduling
Due to the popularity of cars, congestion on city roads is a major problem. There have been many attempts to improve the efficiency of traffic flow. Some approaches simply aim to make traffic lights ‘smarter’, while others identify congestion points and encourage drivers to take a different route. As many of these solutions do not plan ahead, they often just move the congestion point to another part of the road network. In many cases, the new part of the road network is not designed to handle as much traffic load, so the actual congestion is worse.
In this approach, each vehicle in the traffic network is an agent in a DynDCOP problem. Each vehicle communicates with the other vehicles to find the best solution. The problem with this approach is that two vehicles can not know that they share a constraint (plan to use the same road at the same time) until they are on the road. At this point it is too late to do any optimization.
It is infesiable for each vehicle to broadcast its planned route, so any one agent can not know when it will conflict with other agents. In order to overcome this problem we describe a hybrid system. This system combines DynDCOP with auctions. The auctions are used to identify constraints between vehicles and to produce a good solution which the DynDCOP solver can improve. This auction system will be controlled by a central authority, typically the government department that is responsible for road infrastructure. This also allows the central authority to dynamically adjust the capacity of each road, due to an accident or changing the number of lanes available.
5.3. Traffic Scheduling 57
In this hybrid system we combine the best attributes of both a distributed system and a centralized system. It maintains the privacy of all people using the system while still allowing traffic flow to be managed by the central authority.
For the DynDCOP solver we use SBDO, while for the auction system we use the Contract Net Protocol (CNP) [62]. We assume that every vehicle has a computerized device and is capable of two way wireless communication with other nearby devices and fixed infrastructure. This device also needs to know the road network and be capable of planning a route between two points. This could be a dedicated in car navigation system or a smart phone. The device will function as both an SBDO agent and a CNP bidder.
The protocol starts when a route is requested to a destination. The agent then computes a route to use and the time required. Once an initial route has been chosen the device contacts each of the auctioneer agents that control the roads it intends to traverse. First it registers its intention to traverse the road at a given time. After which the auctioneer agent informs the agent of all other vehicles intending to use the time slot. These other vehicle agents are added as the agent’s neighbours. It does not matter if one agent is not able to communicate with all of its neighbours, as the auction mechanism enforces the constraints.
When the auction for a time slot opens, all vehicles that registered their interest are notified. It is assumed they already know their local cost if they are granted privileges to traverse this road. To calculate their bid they must plan a different route, assuming they are not given privileges to traverse this road. They then submit their bid as the difference between the costs of the two routes. The auctioneer then selects the capacity highest bids and grants them the privilege to traverse this road during this time slot. Due to the DynDCOP, it is expected that the number of vehicles planning to use a given road segment does not exceed or only slightly exceeds the road’s capacity. Any leftover capacity is made available as per reserved capacity. The vehicles not granted privileges must change their route to a different route, normally the second route used for bidding.
Due to the small lead time, the vehicles that have to redirect will often have missed the auctions for their new route. They will have to attempt to claim privileges from the roads reserve capacity. Reserve capacity is allocated on a first come first served basis.
Whenever a vehicle changes its planned route, either because its planned route was not available or SBDO’s continuous optimization, it will be subscribed to auctions it no longer has an intention to bid in. If the time at which it intended to traverse that link has passed its subscription to the auction expires, otherwise it maintains the subscription. This is to ensure that the vehicle does not alternate between two different routes.
If a vehicle desires privacy it does not have to participate in the collective optimization provided by SBDO. In this case it informs each auctioneer that it desires privacy when it subscribes to the auction. None of the other subscribers will be informed about it and it is not informed about the other subscribers.
Each road has four parameters relating to the auctions, block time, lead time, capacity and reserve. Block time is the length of time that route traversal privileges are granted for. A vehicle must enter the road segment during this time window. Lead time is the amount of time between the close of an auction and the start of the block of time that was auctioned. Capacity is the maximum number of vehicles that are granted privileges for any block of time. Reserve is the percentage of the roads capacity that is kept for late arrivals. For major roads this will be low, 0-1%, while for minor roads