# Mitigating Urban Congestion: A Cooperative Reservation Framework for Automated Vehicles
## 4 Infrastructure Tracking Node  
Once the map is read, the system is able to process connection requests from incoming vehicles. For this interaction, the infrastructure container in Section 2.2 implements a _Tracking Node_, and the vehicle container implements the _Cooperation Manager_. The _Tracking Node_ represents a dynamically instantiated software module within the infrastructure container, designed to provide real-time monitoring services while ensuring good operational integrity and performance for each managed vehicle. On the other hand, the _Cooperation Manager_ generates a tunnel from which to share information between containers. Given an _ABP_ in the current vehicle road plan whose behavior aims to request an infrastructure connection, the _Mission Manager_ executes a vehicle container request, once the _ABP_ required distance is reached, making a connection to the infrastructure. At that point, a connection is created between the infrastructure container and the vehicle container, which, with the _Cooperation Manager_, sends a data package to the _Tracking Node_ of the infrastructure with some required information. This data package contains the following information:  
* Exposed Topics
* **GNSS Topic**: Data channel from which to listen to GNSS information. * **Mission Status Topic**: Data channel from which to listen to Mission status info. Used for the interaction process. * **Vehicle Control Topic*
* Data channel from which to listen to vehicle control information with the control variables of throttle, brake, speed, steering, etc. * Exposed Services
* **Remove/Add/Update****ABP**: Vehicle services to change mission _ABPs_. * **Get Mission**: Vehicle service to obtain the current mission of the vehicle. * **Get Plan**: Vehicle service to obtain the current road plan tracked by the vehicle, used to retrieve the vehicle plan and select a proper _Survey Cluster_. * **Waypoints**: Vehicle service to retrieve planning waypoint information in coordinates compatible with the vehicle operational coordinate frame. * **Map Origin**: Service to retrieve map origin for coordinate transformation between containers coordinates. * Exposed Variables
* **Coop****ABP**: ABP responsible for the cooperation interaction in vehicle local coordinates. This ABP is shared between the vehicle and infrastructure container. * **Vehicle Namespace**: Operational namespace of the automated system that is requesting a connection. This is restricted to the ROS environment. Once this information is received in the infrastructure container, the _Tracking Node_ requests the localization, mission and planning information of the vehicle. When this information is received, the _Tracking Node_ processes the planning, i.e., road plan, to find a suitable _Cluster_ for the incoming vehicle. If this search fails, a redundant method is deployed to find the cluster with the current mission of the vehicle, traversing each ABP in the mission to find a suitable one that can relate to Entry and Exit points. If both searches fail to find a cluster, a cluster cannot be assigned, and the fallback action defined is executed. This fallback action represents a fail-safe execution that is meant to be defined in the behavior tree of the ABP when an unexpected behavior leads to a failure. Depending on the emplacement, the fallback can execute assorted behaviors, such as a prudent approach while reconnecting. In the provided Listing 1, an example of such behavior can be found. ```
1<rootBTCPP_format=\"4\">
2<BehaviorTreeID=\"intersection_coop\">
3<Sequence>
4<BeforeABPdist=\"20.0\"abp=\"{abp}\"/>
5<Fallback>
6<RequestConnectionabp=\"{abp}\"/>
7<ApproachABPdist=\"3.0\"abp=\"{abp}\"/>
8<WaitFlagtopic=\"free_course\"/>
9</Fallback>
10</Sequence>
11</BehaviorTree>
12</root>
```  
**Listing 1** Example of Connection Behavior. As can be seen, the behavior follows a behavior tree XML format of Sequences and Fallbacks that spawn from a root.