# Mitigating Urban Congestion: A Cooperative Reservation Framework for Automated Vehicles
## 5. Arbitration Process  
The arbitration takes place within the infrastructure container by processing the set of _Tracking Nodes_ currently being executed. Depending on the information retrieved by the _Tracking Node_ and the current configuration of the _Clusters_ in use, the system tries to find a compatibility set, i.e., a group of clusters that can be simultaneously used without conflict, which contains the maximum number of compatible clusters available. To accomplish this, the arbitration algorithm employs a constrained cost function based on a first-come, first-served model, prioritizing vehicles by arrival time while considering velocity, proximity, and resource compatibility. The management system maximizes emplacement capacity by optimizing resource allocation based on these parameters and current resource utilization. A decision is then made in real time, limited by software at approximately 20 Hz, which follows this process:  
1. For each _Tracking Node_, find a compatibility set with other active nodes. 2. From the list of compatibility sets, select a set available. This selection can be based on priority or other information such as speed, type of vehicle, amount of waiting time, etc. Furthermore, useful prediction parameters such as the ones obtained from traffic forecasting models [47; 48; 49] can be used to improve the selection and cost function performance. For the moment, the selection is made by taking into account only the speed and position, but this can be adjusted by updating the selected cost function with relevant parameters such as the vehicle type, Time-To-Collision, waiting/estimated time, number of stops, or even the number of waiting vehicles at Entry. 3. For each _Tracking Node_ whose _Cluster_ is compatible, the entrance is allowed and the _Cluster_ is marked as used, which is a cluster currently assigned and actively traversed by a vehicle. Figure 6. Selection of a Cluster to Assign. For each node that is not compatible with the compatibility set chosen, place an Entry _ABP_ to define how those vehicles should approach the intersection. In both options, an Exit _ABP_ is also added to the mission in order to mark when the vehicle finishes the tracking. 5. For each _Tracking Node_ that is compatible but also mission-ready, i.e., a vehicle that was previously arbitrated and is in a state to act on the decision, check with the behavior execution status if it is approaching or waiting. If it is approaching, remove the Entry point to allow entrance. If it is waiting, release the waiting flag for the behavior to finish, and release the vehicle captured, allowing the vehicle to continue with its plan. 6. Once other _Tracking Nodes_ Exit the intersection, evaluate the compatibility set again, and restart the process. On the one hand, in Listing 2, an example of an Entry behavior can be found. Note that even though this behavior can be seen as simple, the idea is that it can be modified by adding more complex tasks that are able to automate the communication with the infrastructure and the process of approaching the intersection, such as adjusting the speed. Thanks to the possibilities of the operational environment of the behavior engine based on the behavior tree, this can be easily designed and implemented. Example of Connection Behavior. ```
1<rootBTCPP_format=\"4\">
2<BehaviTreeID=\"Entry\">
3<Sequence>
4<ApproachABPdist=\"1.5\"/>
5<WaitFlagtopic=\"enter\"/>
6</Sequence>
7</BehaviTree>
8</root>
```  
Listing 3, on the other hand, summarizes the behavior related to the Exit _ABP_ placed during the arbitration process to flag when the tracking process will stop. This specific behavior can be adjusted to implement any important activity to develop when Exiting the intersection. Furthermore, as per the fallback directive defined in the Connection Behavior, both Entry and Exit behaviors benefit from the model of execution provided by the behavior tree.