A Distributed Token Passing Protocol for Time Constrained Data Gathering in VANETs

Abstract

This paper proposes a novel approach for time constrained information gathering in a typical Vehicular Ad Hoc Network (VANET), based on a token passing scheme, adapted to wireless communications by creating a virtual ring where nodes are connected to a predecessor and a successor node. To address the typical fast topology changes of VANETs, we proposed a specific approach, called Tom Thumb that is a distributed protocol that node-by-node circulates a special packet, called token, which collects the information stored in each vehicle until returning to the first unit within a specified time constraint. The protocol has been properly designed in terms of (i) the more effective hop-by-hop and distributed heuristic implementing the objective function (ii) the token packet format, i.e., the syntax and semantics of its fields. Finally, the performance of the proposed approach is validated for different time constraints and numbers of vehicles, always pointing out a remarkable gain, especially in the presence of severe constraints, i.e., in terms of time deadline, collected information amount and success probability.

1. Introduction

Vehicular Ad Hoc Networks (VANETs) are a Mobile Ad Hoc Networks (MANETs) special case, typically allowing both Vehicle to Vehicle (V2V) or Vehicle to Infrastructure (V2I) wireless communications [1,2], to support complex Intelligent Transportation System (ITS) applications [3,4]. The main feature of VANETs is represented by the constrained and correlated node mobility patterns, which in turn implies an extremely time-varying network topology, with network partitioning and merging. Despite this drawback, a VANET is expected to give rise to an intelligent and cooperative eco-system in order to improve the driving experience, with special regard to safety applications [5].

A commonly referenced implementation of the VANETs paradigm is represented by the IEEE 802.11p protocol [6], which is complemented by the IEEE 1609 protocol suite [7,8]. The set of IEEE 802.11p and IEEE 1609 is usually referred to as Wireless Access in Vehicular Environments (WAVE) in the U.S., while in Europe the corresponding is the cooperative-ITS (C-ITS) based on ITS-G5. In 2017, 3GPP introduced the Vehicular-to-everything (V2X) communications in the Long Term Evolution (LTE) Release 12 standard, considering a new direct device-to-device (D2D) communication mode as a way to effectively support both public safety services and for Proximity Services (ProSe). D2D, indeed, introduces direct single-hop communications between two devices, with limited or even without any Base Station (BS) support [9,10]. These direct (or proximity) communications can achieve high data rates with low end-to-end delay, whilst they are time- and energy-consuming, due to the use of beaconing signals and scanning for direct user discovering. Moreover, as D2D communications usually use unlicensed bands like Wi-Fi, they have the drawback that coverage and number of discovered devices are limited due the stochastic nature of interference over these bands. On the other hand, if a cellular network supports D2D communications (the so-called in band D2D communications), it is also in charge of discovering D2D candidates and managing time-frequency resources, which could overload the cellular infrastructure [11,12].

This paper considers a VANET-aided D2D discovery scenario for data gathering that offloads part of the signaling network traffic to the VANET for allowing low-rate D2D communications as in [13]. In the literature, broadcast approaches are commonly addressed mainly to deliver messages to the desired destinations, additionally via intermediate nodes. However, this approach can increase the traffic volume leading to the well-known data storm effect.

As a consequence, an open issue is represented by the design of a protocol, as an alternative to the classic store-and-carry routing paradigm that manages the data gathering and dissemination, together with the on-the-way information processing. To this purpose, in [14], the authors aimed at introducing the Token Ring (TR) approach in an IEEE 802.11 wireless network, which is referred to as Wireless Token Ring Protocol (WTRP). WTRP is a Media Access Control (MAC) designed for Ad Hoc network with dynamic topology and stringent requirements (i.e., band, latency and failure recovery). In particular, it arranges the network topology as a unique ring, in which every node has a predecessor and a successor, which are a priori known before any transmission occurs. Despite WTRP soon being patented [15], the principle behind it has been investigated with reference to the MANET domain [16] and, in particular, it has been adopted in VANET for information collection and dissemination [17,18].

In this paper, we propose a protocol inspired by WTRP seminal work [14], where significant differences have been introduced: (i) a token circulates in a network that is dynamically and step-by-step formed, i.e, the initial unit (for example the traffic light) starts the process of the token packet sending it to only one neighbor node (i.e., the one with higher information), which in turn selects in the next round only one vehicle and so on until the time deadline is reached, (ii) there is no a priori or proactive neighbors discovery, while it is in-path performed, (iii) in every step, after possibly locally storing and processing, data are passed to the best next hop in order to perform a distributed information gathering, thus this approach is close to a token passing, (iv) the number of visited devices can change dynamically according to the traffic conditions and mobility patterns, (v) the token is delivered to the initial unit creating a virtual ring within a time deadline, and (vi) the token packet format, i.e, syntax and semantics of its fields, and the protocol phases are tailored to this specific use case.

Specifically, we characterize a novel protocol, called Tom Thumb (TT), suitable for information gathering and sharing within a VANET, by adopting D2D communications among vehicles in an urban environment. The proposed approach can be adopted to support typical smart cities missions such as an improvement of traditional infrastructure through Information and Communications Technology (ICT), enhancing the quality of life for citizenship, companies and institutions [19]. In this context, each vehicle, which can be conveniently assumed to be paired with a smartphone used by drivers or passengers, shares its local context awareness with its neighbors belonging to a VANET group. In particular, our proposal resorts to a token passing protocol scheme initiated and terminated in the same device (e.g., the traffic light) creation, which iteratively discovers the nearby vehicles and collects information for traffic monitoring and controlling applications, as expected in a typical smart city scenario. The selection of the best closed path is a typical non polynomial (NP)-hard optimization problem, as it could analyse all the possible paths among vehicles, to select the one maximizing data gathering while matching a predefined time constraint; in particular, this problem is unaffordable at the increase of the number of vehicles [18]. In addition, in the presence of vehicles mobility, a centralized approach requires the instantaneous and ideal knowledge of vehicles’ positions, which can be achieved at the expense of a prohibitive signaling overhead. To this purpose, the proposed TT adopts a sub-optimal approach by hop-by-hop selecting the best path and then concatenating local optima, instead of evaluating the global one. In particular, it does not visit all the nodes, but, driven by in path processing, it selects the path collecting an information quantity close to the optimum. However, TT is close to the optimum approach in terms of data gathering, as it has been validated by numerical results with different time constraints. The rest of this paper is structured as follows: Section 2 discusses some related works, in Section 3, the system model and the proposed protocol are described, Section 4 validates our method by means of numerical results, and, finally, in Section 5, the conclusions are drawn.

2. Related Work

Intelligent Transport System (ITS) covers a wide range of applications for vehicles, such as driving safety and warning, up to automated driving, information exchanges among vehicles and Internet applications. VANETs [20], a special class of MANETs [21], is a key component for developing current ITS. As in MANETs, the VANET network paradigm has no fixed infrastructure and, instead, the members of the network themselves, i.e., the vehicles, provide network services. VANETs devices are classified into two categories: Road Side Unit (RSU) (e.g., traffic lights) and On-Board Unit (OBU) (e.g., wireless device embedded in a vehicle) [22]. In general, communications in VANETs typically allow vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) wireless interfaces. VANET is a consolidated research topic because it has shown to be an excellent element to improve vehicle and road safety and traffic congestion avoidance. In order to implement these kinds of services, cooperative awareness plays a crucial role. WiFi-based Vehicle-to-everything (V2X) communications technology represents a mature candidate, whose capabilities have already been tested. Presently, IEEE 802.11p and the corresponding ITS-G5 in Europe are the current standards. As an alternative, 3GPP considers the support to the V2X feature in cellular networks (i.e., LTE and the next generation 5G). Recently, D2D communications (or Proximity services) are introduced to avoid the control signalling overhead to register and synchronize all the vehicles with the cellular infrastructure. Indeed, D2D communications allow autonomous device discovery and the exchange of data without the presence (or with limited presence) of the cellular infrastructure (i.e., the eNodeB). An overview of standardisation directions for vehicular communications can be found in [23]. Furthermore, in the literature, several works presented the join use of IEEE 802.11p and infrastructured LTE, as in [24,25].

Several medium access control (MAC) layer protocols are designed for V2X for an efficient coordination among the nearby vehicles and for reliable transmission mechanism of safety message. Among these different proposals, the Token Ring (TR) protocol [26] has also been considered to arrange node topology in a ring. However, our proposal avoids the network formation, while a token passing scheme is instead adopted. In this section, the state-of-the-art MAC protocols based on the token ring principle, which may be adopted in VANET communications, are given an overview.

2.1. Token-Based Medium Access Control Protocols for VANET

One of the most challenging research topics in VANET is to efficiently design a scheme for accessing the network medium. There has been some effort in the research community to adapt the classical wired-based medium access TR protocols to wireless communications. The reliable neighbor-cast protocol (RNP) [27] uses a token as an acknowledgment message to deliver reliable multicast among nearby vehicles selected by a a voting scheme as a neighbouring group. Wireless TR protocol (WTRP) has been presented in [14] as a novel protocol for a wireless environment designed for an ad hoc network with dynamic topology and stringent requirements (i.e., band, latency and failure recovery). The aim of WTRP was to guarantee the quality of service (QoS) in terms of bounded latency and reserved bandwidth. Additionally, this protocol improved the access efficiency by reducing the number of retransmissions due to collisions. This was done by creating a virtual ring where nodes, upon joining a network, are required to be connected to a predecessor and a successor node. However, WRT is applied to ITS for guaranteeing QoS and recovering from multiple failures, but this protocol does not react to the typical fast topology changes of VANETs.

Since the WTRP protocol was proposed, some other improved versions of this protocol have been published in literature. In [28], an enhanced version of the WTRP token passing-based MAC protocol is presented (EWTRP). The improvements in comparison to WTRP include a preemption mechanism, a hibernation mechanism and a contention mechanism. A comparison between EWTRP and WTRP was carried out through analyses. Results show that EWTRP produces higher throughput while it consumes less power and is more suitable to operate in small-scale wireless ad hoc networks.

Additionally, the Ripple protocol is presented as a wireless token passing-based protocol especially designed for wireless mesh networks in [29]. This protocol improves existing random-access approaches by proposing a decentralized controlled-access protocol to protect nodes from unintentional packet collisions and to enhance the throughput of the network.

In [30], the authors of this study propose a token ring-based protocol for multi-channel routing to improve the performance of mesh networks. This performance is obtained by defining delay-guaranteed rules for the actions of joining a ring and creating new rings. The authors present a state machine to define their protocol. Analytical results on bounded delay are presented and show a good performance when compared to state-of-the-art approaches.

Furthermore, Sun et al. propose an automatic adjustment of the token path w.r.t. to the subnet’s dynamic topology which is not always arranged in a ring shape [31]. Furthermore, the operation of token path maintenance is simplified and the channel efficiency is increased also in WDTP.

In [32], Bi et al. propose a multi-channel TR media access control protocol (MCTRP) for inter-vehicle communications. By means of an adaptive ring coordination and a channel scheduling, vehicles are autonomously managed into different rings, operating on diverse service channels. The authors show that this topology management allows special messages, such as emergency messages, to be disseminated with a limited delay. Additionally, they present a token based data exchange protocol that improves the network throughput for non-safety multimedia applications.

In the Overlay Token Ring Protocol (OTRP) [33], vehicles are arranged into multiple overlapped virtual rings, where a unique token performs the control functions. The ring architecture dynamically follows the traffic condition to provide data transmission with QoS and reliable safety messages’ exchange.

In this paper, differently from the OTRP scheme, the ring is not formed a priori, but the neighbours’ discovery is carried out hop-by-hop without a complete list of nearby devices, such that the resulting ring does not have a specific size, i.e., it is just a virtual ring originated in the initial unit (e.g., the traffic light), connecting the visited vehicles, and reaching again the initial unit in order to gather the collected information within a time deadline. In addition, in the OTPR scheme, only a few devices (about six) can be grouped together to form overlapped rings; as a consequence, this is more suited for dynamic traffic conditions, rather than for an emergency scenario, where it is needed to exchange messages among a high number of vehicles.

In the literature, several research papers are mainly focused on dissemination protocol as shown in recent surveys [34,35]. Blind data flooding is the simplest dissemination way but has limited performance due to a high percentage of redundant data and packet collisions which lead to the broadcast storm problem. Indeed, Geocast data dissemination protocols consist of sending data only to vehicles inside a specific geographical area [36]. Recently, there are in particular novel and efficient proposals identifying a small group of vehicle for re-broadcasting the messages [37].

Data dissemination is more stringent for Vehicle Delay Tolerant Networks (VDTN) with intermittent and opportunistic connections among vehicles than VANET. For example, in [38], the D${}^2$NFCE algorithm determines the node forwarding capability for data dissemination first by evaluating the effective connection time period then building a predictive traffic model based on wavelet neural network and, finally, fitting the historical and predictive throughputs of vehicles.

On the contrary, data gathering schemes have recently been proposed for VANET. Data collection protocol can be organized with a centralized node, e.g., a cluster head (CH) which collects the data of its vehicles and delivers it to the initial unit (e.g., the RSU) using a flooding technique, as in TrafficGather protocol [39]. The centralized node can be the eNodeBs of LTE network in an urban environment that creates several clusters of vehicles. The cluster topology is broadcasted to the vehicles by eNodeB. Each cluster head delivers the aggregate data to the eNodeB, which deletes redundant and undesired data, as shown in LTE4V2X [40].

A centralized medium access technique based on space division multiple access (SDMA) is also used in the Clustered Data Gathering Protocol (CDGP) organizing the data collection with the election of a cluster head among the various segments in which the road is divided. The CH assigns a slot to the vehicle and, if data are not available, the entire slot will be lost. The use of a token is considered by the same authors to reduce the loss of slots in the new versions: (i) the token based cluster data gathering protocol (TCDGP) and (ii) its enhanced version Distributed Data Gathering Protocol (DDGP) [17]. Both proposed protocols consider the election of a vehicle as a CH within a specific area of a highway to collect data, while Baiocchi et al. [41] extend this protocol towards an urban environment. Specifically, a sub-set of vehicles is selected to act as relay nodes (RNs), thus creating a temporary backbone network that can be used for data dissemination and collection. In the discovery phase, the selection of vehicles traveling in the region of interest is achieved by broadcasting a request message from the RSU, which is in turn forwarded across the formed network in a multi-hop way. In a different way, according to our proposal, each selected vehicle is responsible for iteratively selecting the best neighbour node (i.e., the one with more data stored on board), thus forming a truly self-organized VANET, without HELLO messages broadcasting.

Other protocols are based on a random medium access scheme, such as the Clustered Gathering Protocol (CGP) [42]. In this case the road is organised in virtual segments of the same length. In each segment, a geographical cluster is formed and a CH is elected to collect and aggregate data from vehicles present in that segment, before sending these data to the next segment or to the base station (BS). However, CGP is specifically designed only for a one-way road and, for a larger region, a greater overhead is expected due to the flooding approach adopted to forward the collected data towards the initiating unit, i.e, the BS. In addition, CGP suffers due to the high number of collisions. In particular, this protocol has been assumed as a benchmark for performance comparison with our proposed protocol where an acknowledgement packet is used for the correct receipt of data packets, as shown in Section 4.

3. Proposed Approach

3.1. System Model

This paper deals with a distributed message passing-and-processing protocol to support intelligent traffic management systems. In particular, according to the 5G vision, we adopted the V2X communication mode properly mapped to the existing IEEE 802.11p air interface. In this way, vehicles are allowed to directly communicate with each other, without involving the eNodeB scheduling. In addition, we refer to a particular communication pattern, i.e., one-to-many-to-one scheme, according to which mobile devices (i.e., OBUs) process and collect information in a cooperative way, once they have been triggered by one RSU. It can be noticed that the RSU can act as a gateway sending the collected information to its own eNodeB, which in turn can transfer it to a Big Data Cloud for data analytics and a decision-making process.

Following the approach proposed in [14], we rely on a message passing scheme among VANET devices, namely TT, where the message is denoted as token. The typical use case we referred to, depicted in Figure 1, consists of a group of vehicles in the proximity of a traffic light. As soon as they stop, for instance when the red light turns on, the procedure of data collecting is started, involving the cars being temporarily queued, until the red light turns off. The first step is carried out by the RSU associated with the traffic light that discovers the surrounding cars that selects the best one and passes the token to it, waiting for its return within a time deadline (typically the red light period). Then, the token is iteratively passed among devices, where each one stores and possibly refines the carried information in order to improve their collective context awareness. Finally, the token has to be sent to the initial RSU, before the timeout (i.e., closing the virtual ring); otherwise, it is considered lost and no information is eventually gathered. The proposed scenario can be generalised in order to take into account a limited mobility pattern which models a road segment affected by traffic congestion or a large and saturated roundabout, where information gathering is even more important.

Denoting with ${\mathbf{P}}_{i,j}$ the set of all the possible communications paths connecting the i-th and j-th generic couple of devices in the VANET, and with $e_k$ the local information available at the k-th vehicles, we can formulate the objective of collecting the largest information in a limited amount of time through the following constrained optimization problem:

$$\begin{array}{ll}\left(\mathrm{OPT}\right)\hfill & \underset{\pi \in {\mathbf{P}}_{\alpha ,\alpha }}{\max }\mathcal{F}\left({\mathbf{e}}_{\pi }\right),\hfill \\ & \mathrm{subject}\mathrm{to}:|\tau \left(\pi \right)-{\tau }^{*}|=0,\hfill \end{array}$$

(1)

where $\alpha$ conventionally represents the first RSU initiating the protocol, ${\mathbf{e}}_{\mathcal{J}}$ is the set of information associated with the vehicles belonging to the path $\pi$, $\mathcal{F}\left(\right)$ is function modelling the join information processing and distribution, $\tau \left(\pi \right)$ is the cumulative latency associated with the path $\mathcal{J}$ and ${\tau }^{*}$ the considered time deadline. The constraint means that the delay $\tau \left(\mathcal{J}\right)$ associated with the path $\mathcal{J}$ needs to match the time deadline (${\tau }^{*}$) exactly (This constraint could be further relaxed, assuming that the difference is lower than a small time value $ϵ>0$.).

For the sake of model simplicity, we assumed that the distributed information processing consists of a data gathering, i.e.,

$$\mathcal{F}\left({\mathbf{e}}_{\pi }\right)\dot{=}\sum _{i\in \pi }^{}{e}_i,$$

(2)

this meaning that every involved device (except the initial RSU) sums its local information to the received one, as explained in Section 3.5. In addition, it is worth noting that, if the j-th device is visited more than one time (e.g., in the presence of a loop), the provided information is null. In some specific applications, known as consensus sensing, it is further required that the provided cumulative information ${\sum }_{i\in \pi }^{}{e}_i$ was greater than a threshold value $E^{*}$, as we will discuss in Section 4.

It can be finally noticed that the optimization procedure solving Equation (1) with the additive information processing model of Equation (2) analyzing all the possible multiple paths among vehicles in order to maximize the data gathered presents an NP-hard complexity, which is particularly burdensome upon the increasing of the number of vehicles. On the contrary, the proposed TT approach is a sub-optimal heuristic that does not visit all the nodes, but only a small subset depending on the selected vehicles and the adopted in-path processing. However, the amount of collected information is close to the optimum value, as shown by numerical results performed in Section 4.

3.2. Proposed Protocol

The proposed protocol consists of two main phases and an optional one, the latter executed only under specific conditions, as shown in Figure 2:

• token processing,
• neighbor discovery,
• next Token Owner (TO) selection and token forwarding.

In the following, we characterize each phase in terms of exchanged messages and sequence diagram.

3.3. Phase I: Token Processing

We start the protocol design by illustrating the token packet structure, as shown in Figure 3 along with its fields. We define each field and its length (in bit [b] or Byte [B]). There are three possible packets that have a common field (Type (Tp)) formed by two bits, which identifies the current packet. In particular, if this value is 00, the packet is the token; if it is 01, the packet is a Neighbour Discovery Broadcast (NDB) message, while, if it is 10, the packet is a Neighbour Discovery Response (NDR) message. The 11 value is not yet assigned. In addition, a PADDING field is inserted: it is either 30 bits for NDB and NDR packets or eight bits for the token. In both cases, this field is set to 0. When nodes receive a packet, parsing the first two bits, they identify the message and can perform the correct operation.

Regarding the token packet, we set the following fields:

• Link (L) [1b]: this field contains the token route. If it is 0, the token is in the Discovery Path (DP), if it is 1, the token is in Return Path (RP). In the DP mode, the token discovers the route and searches the best next TO, while in the RP mode the token returns to the Traffic Light (TL) following an optimised route evaluated in the discovery mode.
• Token ID (TID) [5b]: this field contains the token unique identifier (ID).
• Traffic light ID [2B]: this field contains the RSU traffic light unique identifier.
• Max Available Hop (MAH) [2B]: this field contains the maximum number of hops in discovery mode. This value is given by Algorithm 1. The TL evaluates the maximum hop number divided the amount of time for the neighbour discovery (ND). If the evaluated time to perform the discovery path and the estimated return path (the RP hops number is less than or equal to the DP hops number) (We assume that in the discovery path the ND time duration is much bigger than the transmission time.) is bigger than the amount of time, it decreases the MAH by one and re-calculates the time.
• Hop Counter (HC) [2B]: this field contains the token hop number. When a node receives the token, it increases this field by one if the token is in DP mode, while it decreases this field by one if the token is in RP mode.
• Time Token Emission (TTE) [2B]: this field contains the seconds that have elapsed since an epoch (For example, we can define an our own reference data, i.e., Monday, 1 January 2019, 00:00:00 UTC.).
• ND time duration [2B]: this field contains the time (in ms) used for the ND.
• Next TO ID [2B]: this field contains the next TO identifier.
• Amount Time (AmTime) [1B]: this field contains the amount of time to perform token passing (in seconds). Within this time, the token must return to the TL. It is worth noticing that TTE could be different with respect to the red time start to allow the vehicles queue to be formed.
• Visiting Nodes ID (VNsID) [variable length]: this field contains all the nodes visited in DP mode, or all the nodes that will be visited in RP mode. The field length is extracted by the Hop Counter field. The queue is managed according to the last in first out (LIFO) discipline in DP mode and first in first out (FIFO) in RP mode. In other terms, in the discovery mode, the first ID is the first node visited by the token, in return mode, the first ID is the next TO.
• Data [variable length]: this field contains the data processed by the devices visited by the token.

Within this phase, the device selected as the actual TO checks the L field and, according to Algorithm 2, it enters the correct phase.

Algorithm 1 Max Available Hop selection.

1: Max Hop = floor(AmTime / ND time duration) 2: repeat 3:     if AmTime - (Max Hop×ND time duration + (Max Hop - 1)×TX time duration) then 4:         exit 5:     else 6:         Max Hop ← Max Hop - 1 7: untilMax Hop is 0 8: Set Max Hop in token packet

3.4. Phase II: Neighbor Discovery

This phase is performed only under specific conditions, i.e., if the token is in Discovering Mode. 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.

3.5. 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.
• 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.

3.6. 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.

Algorithm 2 Tom Thumb algorithm.

1: ifL is 0 then 2:     if Hop Counter is not Max Hop then 3:         repeat 4:            finds($\max \left({ϵ}_i\right)$) 5:            if i not in VNsID then 6:                NextTO $\leftarrow i$ 7:                ${NextTO}_{information}\leftarrow {ϵ}_i$ 8:                exit 9:            else 10:                remove i from Neighbors 11:         until len(Neighbors) is not 0 12:         if len(Neighbor) is 0 then 13:            NextTO ← last arrived 14:            ${NextTO}_{information}\leftarrow 0$ 15:         adds its ID in VNsID 16:         HC ← HC + 1 17:     else 18:         L $\leftarrow 1$ 19:         create return path 20:         changes VNsID and Hop Counter 21:         ${NextTO}_{information}\leftarrow 0$ 22:         NextTO ←VNsID[0] 23: else 24:     ${NextTO}_{information}\leftarrow 0$ 25:     Remove ID from VNsID 26:     NextTO ←VNsID[0] 27:     HC ← HC - 1

If the token is in discovery mode (L field sets to 0), after waiting for timer expiration, the actual TO checks all the received NDR packets and, if it still has some time remaining (i.e., the Hop Counter lower than Max Available Hop), it searches for the next TO.

It basically selects the neighbor that carries more information and, if it is not yet visited, it becomes the next TO. If the best neighbor has already been visited, it is discarded. This process repeats until a next TO. is found or there are no available neighbors (i.e., all the neighbors have been discarded). In the latter case, the next TO becomes the last vehicle coming in the queue, while, in the former case, the next TO is a previously visited device and the added information is 0.

If a TO verifies that the Hop Counter becomes equal to the Max Available Hop, it triggers the Return Mode (changes to 1 the L field) and it becomes responsible for evaluating the return path. It analyses the Visiting Nodes ID field and performs an optimisation: if loops are present (i.e., nodes are visited more than one time), they are deleted. Furthermore, it appends all the visiting nodes in a FIFO queue (the first ID becomes the next TO) and it changes the Hop Counter (equal to the length of the modified Visiting Nodes ID). It can be noticed that henceforth the added information is 0. If a node receives the token in return mode, it removes its ID in the Visiting Nodes ID field, sets the following ID as the next TO, decreases the Hop Counter field, and sends the token.

4. Numerical Results

The proposed TT protocol has been validated by performing numerical simulations on ${\mathrm{Python}}^{\mathrm{TM}}$ based framework integrating both networkx and numpy to set up and analyse the network features. We investigate the performance in terms of the amount of collected information within a predefined time constraint, as expressed in Equation (2); in addition, the probability of token recovering has also been derived. Specifically, the following algorithms are compared:

• Drunkard Random Walk (DrkRdnWlk), i.e., a special case of the well-known random walk with a finite time horizon, where TO randomly forwards the token packet to one of its neighbours. As a consequence, it is a lower bound for the performance.
• Heuristic 1 (Heu1). In this approach, the next TO is selected as in Algorithm 2. The main difference with respect to the proposed TT scheme is that Heu1 does not save the path and, when the return to the TL is triggered, the neighbours’ discovery procedure is still performed and the token packet is forwarded the best neighbour, which becomes TO. The trigger is based on a time value $\tau$ which represents the amount of available time to explore the network normalised to the deadline. As soon as this threshold is exceeded, the token is triggered back. In performing our simulations, we selected $\tau$ as equal to $3/5$, since it represents a good trade-off. This parameter is a priori set by the TL within the PADDING field of the token packet (Figure 3). When a node receives the token at the current time t, it checks the elapsed time and, if $t-TTE>AmTime\times \tau$, it changes the L field and sends the token to the next selected TO.
• The proposed TT approach is previously characterised in Section 3.
• The CGP protocol is already addressed in Section 2.1.
• The optimal solution is, however, affordable for a limited number of involved vehicles.

The simulation campaign is performed according to a Monte Carlo approach, where ${10}^5$ runs are repeated for each of the two investigated scenarios, whose parameters are listed in

Table 1. Parameters adopted for Scenarios 1 and 2.

Parameter	Scenario 1	Scenario 2
number of cars ($N_c$)	15	120
number of lanes ($N_l$)	3	3
time deadline	3 [s]	10 [s]
token transmission time	0.1 [s]	0.1 [s]
neighbours discovery time ($\mathit{ND}$)	[0.3–0.7] [s]	[0.3–0.7] [s]
mean coverage radius	10 [m]	10 [m]

. Moreover, the information is available at each vehicle modelled as a normalised uniform random variable in the (0–1) interval.

To address the behaviour of the proposed approach, in Figure 6, we preliminarily presented a snapshot of the token passing process, by depicting the information gathered by the optimum, TT, Heu1 and DrkRdnWlk approaches as a function of the round (i.e., hops) for $N_c=24$ and $\mathit{ND}=0.3$ [s]. The gathered information has been normalised to the maximum amount available in the scenario. It can be noticed that optimal values are closely approached by the proposed TT method, which instead performs better than DrkRdnWlk and Heu1 techniques.

In Figure 7 and Figure 8, the normalised collected information and the collection probabilities achieved by the different approaches are, respectively, sketched for the Scenario 1 and different ND timer durations, i.e., $0.3$, $0.5$ and $0.7$ [s]. It can be preliminarily pointed out that DrkRdnWlk protocol is the worst algorithm among the considered algorithms in terms of both collected information and collection probability. As a consequence, whenever the token is returned back to the TL, the collected information is extremely low. Conversely, if it does not return to the TL within the time constraint, it is considered lost and the gathered information is null. In addition, Heu1 and TT are able to return the token to TL, while respecting the time deadline. The percentage of gathered information depends on the ND time duration: the greater time spent for ND, the shorter the path the token travels within the network and the less information it is able to collect. Moreover, it can be pointed out that the proposed TT protocol is close enough to the optimum approach and always performing better than the other alternatives, except for the case of high ND timer duration, where CGP achieves almost equivalent performance because of the limited number of vehicles.

Finally, the same investigation is repeated for Scenario 2, as reported in Figure 9 and Figure 10, where the higher number of vehicles makes the pursuit of the optimal path unaffordable. However, despite the performance degradation w.r.t. Scenario 1, TT performs better than all the other considered alternatives for any ND values. In addition, in the same figures, we also considered the presence of a low mobility pattern where the road segment under investigation is affected by traffic congestion with an average vehicle speed equal to 50 [m/s]. It can be pointed out that the impact of mobility on TT is very limited with a relative performance decrease of about 7%.

5. Conclusions

This paper deals with the proposal of a novel distributed protocol for information gathering and sharing within a VANET, by adopting D2D communications among vehicles. In particular, we characterise the case study in terms of a time constrained protocol, where the objective function is represented by the collected information, which allows the system to be context-aware, within a constrained time interval. In order to afford this problem, we propose a heuristic sub-optimal approach, i.e., TT protocol. In addition to this, it has been designed in terms of packet format, while the related sequence diagrams have been properly characterised. By resorting to accurate numerical simulations in a couple of scenarios, we validated the effectiveness of the proposed approach in terms of token recovering probability and the collected information by further comparing it with the optimal solution and an alternative one already proposed in the literature. As a consequence, the TT approach can be successfully applied for traffic monitoring and control applications expected in a typical smart city scenario.