# Agreement Technologies for Coordination in Smart Cities
## 3 Applications
### Coordination of Traffic Flows through Intelligent Intersections
#### 3.1.1 Mechanism for Single Intersection  
For a single reservation-based intersection, the problem that an intersection manager has to solve comes down to allocating reservations among a set of drivers in such a way that a specific objective is maximised. This objective can be, for instance, minimising the average delay caused by the presence of the regulated intersection. In this case, the simplest policy to adopt is allocating a reservation to the first agent that requests it, as occurs with the first-come first-served (FCFS) policy proposed by [PERSON] and [PERSON] in their original work. Another work in line with this objective takes inspiration from adversarial queuing theory for the definition of several alternative control policies that aim at minimising the average delay [PERSON] and [PERSON] (2015). However, these policies ignore the fact that in the real world, depending on people's interests and the specific situation that they are in, the relevance of travel time may be judged differently: a business person on his or her way to a meeting, for instance, is likely to be more sensitive to delays than a student cruising for leisure. Since processing the incoming requests to grant the associated reservations can be considered as a process of assigning resources to agents that request them, one may be interested in an intersection manager that allocates the disputed resources to the agents that value them the most. In the sequel, we designed an auction-based policy for this purpose. In line with approaches from mechanism design, we assumed that the more a human driver is willing to pay for the desired set of space-time slots, the more they value the good. Therefore, our policy for the allocation of resources relies on _auctions_. The first step is to define the resources (or items) to be allocated. In our scenario, the auctioned good is the use of the space inside the intersection at a given time. We modelled an intersection as a discrete matrix of space slots. Let \(S\) be the set of the intersection space slots, and \(T\) the set of future time-steps, then the set of items that a bidder can bid for is \(I=S\times T\). Therefore, differing from other auction-based approaches for intersection management (e.g., [26]), our model of the problem calls for a _combinatorial auction_, as a bidder is only interested in bundles of items over the set \(I\). As Figure 2 illustrates, in the absence of acceleration in the intersection, a reservation request implicitly defines which space slots at which time the driver needs in order to pass through the intersection. The bidding rules define the form of a valid bid accepted by the auctioneer. In our scenario, a bid over a bundle of items is implicitly defined by the reservation request. Given the parameters _arrival time_, _arrival speed_, _lane_, and _type of turn_, the auctioneer (i.e., the intersection manager) is able to determine which space slots are needed at which time. Thus, the additional parameter that a driver must include in its reservation request is the _value of its bid_, that is, the amount of money that it is willing to pay for the requested reservation. A bidder is allowed to withdraw its bid and to submit a new one. This may happen, for instance, when a driver that submitted a bid \(b\), estimating to be at the intersection at time \(t\), realises that, due to changing traffic conditions, it will more likely be at the intersection at time \(t^{\prime}>t\), thus making the submitted bid \(b\) useless for the driver. The rational thing to do in this case, as the driver would not want to risk being involved in a car accident, is resubmit the bid with the updated arrival time. However, we require the new bid to be greater than or equal to the value of the previous one. This constraint avoids the situation whereby a bidder \"blocks\" one or several slots for itself, by acquiring them early and with overpriced bids. Figure 3 shows the interaction protocol used in our approach. It starts with the auctioneer waiting for bids for a certain amount of time.