## 4 Procedures for VTL and Platoon Management over the Virtual Nodes
### VTL Leader Election  
In the pioneering works of [14; 32], the operation of a VTL requires one of the vehicles approaching an intersection to be chosen as the VTL leader. From that moment on, that vehicle is responsible for VTL coordination and dissemination, until it leaves the intersection and a new cycle starts. Since we rely on a network of virtual nodes placed around each intersection, it is straightforward to decide which vehicles are candidates for the role of VTL leader. Hereafter, we will use the term _\"VTL area\"_ to mean the aggregate of the regions covered by the L1 VN placed at a given intersection and the L2 VNs adjacent to it. The inclusion of the L2 VNs is intended to start the VTL processes early enough to get the VTL information before arriving to the intersection. The process to grant the role of leader/non-leader to each one of the PNs in the VTL area is driven by a finite state machine controlled by events of message receipts, timeouts and region changes. Each PN can be in one out of the six following states:  
* _OUT OF INTERSECTION_: the PN is not taking part in the VTL action. * _REQUEST_: the PN is requesting VTL leadership. * _ASCERTAINMENT_: this is an intermediate state, needed to avoid problems of duplicate leadership that would result in contradictory VTL signals (The problem of duplicate leadership was analyzed in [32], concluding that VTLs are still feasible if it occurs from time to time. We preferred minimizing the probability, at the expense of a few milliseconds in the VTL operation). * _LEADER_: the PN is VTL leader for the intersection. * _NOT LEADER_: the PN is waiting for the VTL leader to inform of VTL schedule. * _GREEN LIGHT_: the PN has received the green light and aims to cross the intersection. The protocol defines eight types of messages:  
* _M_LeaderRequest_: used to request leadership. * _M_LeaderResponse_: sent by a leader to decline a leader request or a leader ascertainment, and by a PN in the _ASCERTAINMENT_ state to reply to another PNs that reached that state later. * _M_VTL_: used by the leader to periodically disseminate the VTL schedule. * _M_LeaderAnnouncement_: used by a PN in the _ASCERTAINMENT_ state to announce that it is going to become VTL leader. * _M_IntersectionLeft_: sent by any vehicle leaving an intersection. * _M_LeaderDesignation_: sent by a leader when it finally gets the green light, to start the next leader election cycle. The leader can fill in a given field in this message to indicate the ID of a candidate to become the next leader (a PN that is known to stay within the VTL area long enough) to speed up the process. * _M_CancelVTL_: used by a PN that accidentally assumed leadership after realizing there was a standing leader; the message reports the incident to the vehicles that received the green light in the last _M_VTL_ from the duplicate leader. * _M_Hello_: sent periodically by every vehicle since it enters the VTL area, indicating its distance to the intersection, its intended path, and whether it is interested in joining a given platoon. There are also four different timers:  
* _T_RequestWait_: used by a PN in the _REQUEST_ state to discard the existence of a standing VTL leader after sending an _M_LeaderRequest_ message. * _T_Ascertainment_: used by a PN in the _ASCERTAINMENT_ state to discard the existence of a standing VTL leader after sending an _M_LeaderAnnouncement_ message. * _T_VTLWait_: used by leaders and non-leaders to control when to send or expect _M_VTL_ messages. * _T_Hello_: used by every PN to control when to send _M_Hello_ messages. The behavior of the protocol is represented in the graph of Figure 4:  
* Every vehicle starts in the _OUT OF INTERSECTION_ state. When it enters the VTL area, it switches to _REQUEST_, changes its VTL signal to amber and broadcasts an _M_LeaderRequest_ message, starting the _T_RequestWait_ timer.