# A Distributed Token Passing Protocol for Time Constrained Data Gathering in VANETs
## 3 Proposed Approach
### Phase I: Token Processing
Accordingly, the TO discovers the nodes in its coverage radius. To this purpose, TO sends an NDB packet (shown in Figure 4) with its unique ID (its role is equal to a _source address_) and the duration time of the neighbor discovery phase. After sending NDB, the TO enters into a _waiting state_, waiting for neighbor responses within a predefined time. We assumed the presence of explicit Acknowledgment (ACK) messages, as it usually happens for commonly adopted medium access schemes. As explained in Section 3.3, the time duration is fixed by the red period of the traffic light. Upon receiving the NDB, every node sets a timer, and, if it does not send the NDR within this time, it aborts the transmission. Due to the limited coverage radius, we can consider the neighbors to be very close: this assumption allows for identically evaluating the NDB received time. All the nodes that received the NDB packet try to randomly access the medium in order to send their NDR within the ND duration time. Specifically, the NDR has the following fields as in Figure 5:

* _Vehicle ID_[2B]: this field contains the unique ID of the responding node. * _Token Owner ID (TO ID)_[2B]: this field contains the unique ID of the Token Owner. * _Queue arrival time_[2B]: this field contains the time (again, seconds since the epoch) at which a vehicle stops. * _Data length_[2B]: this field contains the length of the next field. * _Carried information_[variable length]: this field contains the information carried by the vehicle. As the waiting timer expires, TO selects the next TO based on the received NDR packets, according to the first phase in Algorithm 2. Whenever the TO does not receive any NDR, it re-triggers a new ND after some time. It is worth noticing that the time must be a multiple of the ND time duration and the TO must consequently increase the _Hop Counter_ field in the token. If after two ND attempts, the TO does not receive any NDR, it triggers the token to return to the TL. ### Phase III: Next TO Selection and Token Forwarding

The last phase is different if the token is in the discovery or return phase. In general, the TO modifies some fields: it increases or decreases the _Hop Counter_ field, it changes the _Next TO ID_ field and adds or removes its unique ID to the _Visiting Nodes ID_ field. In particular:

* If the \(L\) flag is set to 0 (i.e., discovery mode) the TO increases the _Hop Counter_ field, appends its ID to the _Visiting Nodes_ fields, puts the next TO ID in the related field and inserts the next TO data (carried information) by integrating the token context awareness, as explained in Section 3.1. It is worth noticing that the next TO could be a previous visited node and, as explained before, the inserted data are 0. Figure 4: Neighbor Discovery Broadcast packet structure. Figure 5: Neighbor Discovery Response packet structure. * If the \(L\) flag is set to 1 (i.e., return mode), the TO decreases the _Hop Counter_ field, removes its ID to the _Visiting Nodes_ field, does not add any information in the _Data_ field, and gets the first ID in _Visiting Nodes_ field, while it modifies the previous value in _Next TO ID_ field with this one. After this operation, the TO sends the token, while setting an _AckTime_. Any node receiving the token analyses the _Next TO ID_ field, and if it is not the selected TO, discards the packet. The next TO, instead, sends an _ACK_ message: if it is not received before the timer expires, the TO re-sends the token. ### Next TO Selection Algorithm

The next TO is selected according to the TT Algorithm 2. There are two different next TO selection Algorithms, depending on the path.