VaNetChain: A Framework for Trustworthy Exchanges of Information in VANETs Based on Blockchain and a Virtualization Layer

Featured Application

A framework to enable data integrity, traceability and reliability in the information exchanges between vehicles and roadside units, relying on blockchain technology and a virtualization layer.

Abstract

Vehicular ad hoc networks (VANETs) face challenges related to the reliability of the data exchanged and the unstability of the communication links. These shortcomings have hampered the development of the long-awaited applications that would turn roads into a smart environment. We present a framework to deploy such services, in which a virtualization layer ensures means to efficiently deliver messages between vehicles and roadside units (RSUs) and, on top of that, blockchain technology is used to enable features of data integrity, traceability, and reliability that cannot be furnished by existing consensus and reputation mechanisms. A simulation experiment is included to determine the optimal number of RSUs to be installed as supporting infrastructure in a city.

1. Introduction

The automotive industry is undergoing a revolution, driven by the advances in information and communication technologies and microelectronics, towards the deployment of intelligent transportation systems [1,2]. Vehicular ad hoc networks (VANETs) are highly dynamic and self-organizing networks, formed by vehicles equipped with on-board units (OBUs) for direct short-range communications (DSRC) with other vehicles and roadside units (RSUs) [3]. DSRC standards were recently adopted by the European Parliament—to the detriment of the alternative model of cellular vehicle-to-everything (C-V2X) [4]—to enable specific solutions for increased road safety, traffic efficiency, driving assistance, crowdsensing, infotainment, and many others [5,6,7,8,9,10,11,12,13,14,15,16,17].

Managing the information required by these new services often goes beyond the capabilities and/or the incumbency of individual vehicles, e.g., because the amount of data exceeds the memory and CPU power of the OBUs, because a peer-to-peer model is not suitable for a given task, or due to privacy concerns. For example, in dealing with traffic accidents, insurance companies use as much information as possible about the circumstances to determine responsibilities and execute the contracts. Thus, they are interested in gathering telemetry data sensed by nearby nodes in the VANET, which they can consolidate and analyze in the cloud, and thereupon make the decision of whether to pay for the damages [18]. In general, it is necessary to create solutions in which the vehicles can collaborate to effectively augment their capabilities, by sharing processing/storage/sensing resources with other vehicles and establishing reliable communication paths to fixed RSUs, which may act as gateways to the Internet [19,20] or carry out some processing in an edge computing fashion [21,22].

For the new services to work properly, it is necessary to address two challenges inherent to the vehicular environment: the instability of the communication links and the trustworthiness of the data generated/provided by the vehicles [23]. On the one hand, the rapid mobility and the variations of vehicle density lead to breakages of the communication links between pairs of vehicles, affecting any multi-hop communication paths established through them [19,24]. On the other hand, due to the nature and sensitivity of the information exchanged in some services (e.g., geographic locations, license plates or any other form of identity, etc.), there must be ways to prevent or hamper malicious behavior, dealing at least with data integrity and traceability, and assessing the reliability of the data sources according to consensus and reputation mechanisms [25,26,27,28]. The notions of information quality and criticality described in [29] emerge, too, in order to quantify the importance level of the information that each source may contribute.

In this paper, we present a framework that enables the desired VANET services by combining two technologies:

• First, a virtualization layer sits on top of the TCP/IP protocol stack to have the vehicles emulate a reliable network of static virtual nodes for the communications. In particular, we use the VaNetLayer system [30], which has been shown to improve the performance of VANET communications in simulations of urban scenarios [31].
• Second, blockchain technology is used to enable features of data integrity, traceability, and reliability that cannot be furnished by the consensus and reputation mechanisms that have shown up in the literature of VANETs in recent years. Specifically, we adopt the principles of Ethereum because its widely supported implementation of smart contracts provides suitable means for the definition of a range of service conditions.

In our framework, called the VaNetChain, the entwining of these technologies turns the RSUs into entities responsible for executing an improved consensus and validation protocol. In turn, the virtual nodes give maximum priority to the packets that imply adding/verifying information to/from the blockchain. Besides, they perform a pre-validation of the reputation of the vehicles involved in any exchange of messages, avoiding the propagation of false data and the waste of resources in the VANET.

The paper is organized as follows. Section 2 provides an overview of the state-of-the-art in routing protocols that attempt to reduce link breakages in VANETs, as well as previous approaches to improving the management of data in this context. Section 3 explains the architecture and the operating principles of the VaNetChain, focusing on the entwining between the VaNetLayer and blockchain technology. Section 4 presents an experiment aimed at determining the number of RSUs needed as fixed infrastructure in a city, focusing on latencies as a critical performance parameter. Finally, Section 5 contains conclusions and future work.

2. Related Work

The problems that the VaNetChain seeks to solve have been studied in the literature. On the one hand, a number of routing protocols have been designed and implemented to improve the stability of the communications in VANETs. On the other hand, several approaches have been proposed to enable reliable and traceable data exchanges against various types of defective or malicious behavior [32,33]. In the following subsections, we describe some of the most relevant works in relation to each topic.

2.1. Routing Protocols in VANETs

The dynamism, rapid mobility, and variable node densities that characterize the VANET environment hamper the collection and sharing of data, especially when high latencies are not tolerated [24]. Protocols based on geographic routing and clustering are currently seen as the most efficient choices, due to their efficient use of control messages. Geographic protocols use the nodes’ positions to make routing decisions. Among the best known, IGRP [34] focused on selecting sequence of intersections for the packets to reach fixed gateway nodes (GWs). The GWs maintain an up-to-date view of the network topology. Therefore, every time a vehicle moves away from its current position a distance greater than its transmission range, it sends the nearby GWs a report with its updated location. This information allows the calculation of a set of routes to maximize the QoS parameters. An alternative approach was presented in [35], based on a data dissemination scheme to perform intelligent forwarding, by selecting the next hop according to the stability of the connection and the link durations.

In clustering-based protocols, the idea is to introduce a hierarchy to handle manageable amounts of control messages, by arranging the moving vehicles in groups (typically, on the grounds of geographical proximity and relative movement) and designating one of them as the cluster head to channel the communications with the neighboring groups. An interesting analysis of approaches to form clusters was presented in [36], while the work in [37] enumerated parameters relevant for the selection of the cluster heads. New combinations of approaches for both tasks keep appearing, achieving significant performance improvements in simulation experiments [38]. As the routing protocol between cluster heads, it is still common to find variations of classical algorithms—such as AODV or OLSR—to use the most reliable routes from source to destination. For example, in [39] the traditional system for the detection of route breakages (based on the loss of HELLO messages) was replaced by a forecasting indicator that used information about errors in the decoding of OFDM packets. The authors of [40], in turn, developed a framework that analyzes network resources in order to adjust the relationship between topology changes and QoS needs, aiming to decrease the load on the VANET and thereby improve scalability. Other authors have attained improvements by incorporating machine learning techniques that allow the prediction of vehicle mobility [41].

Finally, there are dedicated protocols running on the same idea of a layer of virtual nodes that supports the proposal in this paper, such as VNAODV+ [42] and VNIBR [43]. On the one hand, VNAODV+ maintains the reactive essence of AODV, including route discovery, packet types, and the configuration of most parameters. The main difference has to do with the changes required to send data through virtual nodes, starting from the fact that routing entities are not identified by IP addresses but by region. On the other hand, VNIBR is an intersection-based geographical protocol in which all routing decisions are made at road intersections, where the virtual nodes maintain routing tables as persistent state information.

2.2. Reliability and Traceability of Data in VANETs

As explained in [26], VANET communications may be affected by nodes that alter the content of the messages that they should simply relay, or that generate false data. Some authors have proposed trust models as a first facility to address this problem, which can be classified into three categories:

• Some approaches assess the reliability of the vehicles through a reputation system that relies on a centralized entity, which collects the opinions of neighboring nodes [44,45,46,47]. In scenarios of high mobility, these approaches struggle to collect sufficient information to calculate the reputation scores for each node; furthermore, the centralized entity represents a single point of failure.
• Other approaches resort to the cooperation among several sources of information to assess the reliability of the data they receive [48,49,50]. The need to replicate packets onto several nodes increases the communication overhead and the latencies, and in cases of high mobility it is hard to ensure the necessary levels of collaboration.
• Some proposals have combined the entity-centric and data-centric approaches, to jointly assess privacy and trust [51,52].

The literature of VANETs is rich in methods for authentication [53,54], including privacy- preserving techniques [55] which are highly needed for the kind of services advocated in this paper. On top of these, blockchain technology comes as a way to achieve traceability of the data, due to the introduction of a public, decentralized, hardly corruptible, and practically immutable ledger [56]. The recorded transactions, after being validated and added to the ledger, can be consulted at any time, but they cannot be deleted or modified [57]. The following are some remarkable proposals for the integration of blockchain in VANETs.

• The authors of [58] presented a reputation mechanism inspired by Bitcoin, in which unique cryptographic identifiers, known as the Intelligent Vehicle Trust Points (IV-TP), are created and delivered by authorized dealers. The higher the IV-TP achieved by a node, the more trustworthy it is considered.
• An anonymous blockchain-based reputation system was presented in [26], with two blockchains handled in parallel: the first one to store the certificates issued by a certification authority, together with the reputation scores of the corresponding nodes, and the second one to keep track of revoked public keys. When a communication is initiated between vehicles and/or roadside units, the validity of their certificates and public keys is checked by searching in the two blockchains. A similar approach was presented in [59], based on a lightweight blockchain protocol to keep track of all certificates (issued and revoked), whereas the authors of [60] made a proposal to speed up the authentication and revocation processes.
• The authors of [61] proposed a new type of blockchain to address aspects of security and reliability in the dissemination of emergency messages, which are relevant within a certain distance from the location of an incident. In order to validate the disseminated messages, the vehicles use certificates provided by the closest RSU, which guarantees that they were in a location close to the incident they are reporting.

In all of these approaches, the integration of blockchain in VANETs has been seen as a separate problem from the reliable transmission of data packets through one-hop or multi-hop routes. However, latencies and packet losses represent a persistent problem that cannot be diminished to an extent that does not impinge heavily on the performance of the blockchain protocols above [4]. Our approach to solve this inconvenience is to architecturally entwine a virtualization layer (which addresses the problems of the communications) and the blockchain protocol (which deals with the properties of the data). Our proposal is described in detail in the next section.

3. VaNetChain: Architecture

Figure 1 shows the difference between the protocol stacks of a traditional use of blockchain technology in VANETs and our proposal in this paper: VaNetChain. The key ideas of the latter are (i) to introduce the virtualization layer to support the operation of the routing algorithms (variations of the non-virtualized counterparts) and (ii) to entwine the operation of the blockchain protocols with the virtualization constructs.

The virtualization layer that supports our approach is called the VaNetLayer, introduced in [30] as an evolution of the VNLayer, a foundational proposal from the MIT [62]. The VaNetLayer defines procedures by which the moving vehicles collaborate to emulate fixed virtual nodes (VNs) that altogether cover the whole area of the VANET. The layout of the VNs is defined by first placing one VN at each intersection, and then covering the road segments with as many VNs as needed, depending on the maximum distance for one-hop communications. Figure 2 shows one example with 11 VNs, colored differently depending on whether they are covering one intersection, they are neighboring one intersection, or they are placed elsewhere on a road segment.

The emulation of the VNs is supported by one-hop communications among the vehicles that happen to be within the corresponding region at any given moment. These physical nodes can have three different roles: leader nodes, backup nodes, and regular nodes. As we will explain in Section 4, these roles are relevant at the blockchain level, too. Essentially, leaders are in charge of receiving/forwarding packets from/to neighboring VNs, as well as storing the persistent information state (PSI) kept in the region to support the operation of the protocols at higher layers. Backups, in turn, keep copies of the PSI as a mechanism to fight failures, and they support the leader’s work in cases of intense traffic. Finally, the regular nodes listen to the dynamics of leader and backup appointments to replace them whenever needed.

At the blockchain layer, VaNetChain implements mining as a proof of work (PoW), designating RSUs as miners (mRSUs) that try to solve the block hash calculation by applying the Keccak (https://keccak.team/keccak.html) or SHA-3 algorithm. This idea goes hand in hand with the proposals that rely on RSUs to perform different computing tasks, taking advantage of computer and connectivity benefits [63]. The number of zeros required at the beginning of the hash is set so that an mRSU takes around 10 seconds to add a new block to the blockchain. If the time decreases for whichever reason, the number of zeros will increase accordingly, in order to ensure the immutability of the ledger. Likewise, if the time increases (e.g., due to periods of excessive work), mRSUs can choose to merge blocks of transactions and reduce the number of zeros in order to speed up things. The mRSUs set their gas limit (“gas” is the cost of making a transaction or executing a contract in Ethereum) to 1M. For the propagation of the new blocks (needed to achieve distributed consensus among the mRSUs and thus keep a unique record of transactions), the virtual nodes give the second greatest priority to the corresponding data packets —only second to the control packets of the VaNetLayer.

We assume that all VaNetChain participants can execute smart contracts and verify that their terms have been met. Reputation scores and a blacklist of MAC addresses are recorded in the blockchain along with the completed transactions. Thus, for any new transaction started by a vehicle (i.e., for any action to keep track of in the blockchain), the virtual node covering its current location can check its reputation and discard the transaction straight away if the value is too low or the vehicle has been blacklisted, thus helping to avoid waste of resources.

The behavior of the virtual nodes in VaNetChain has been extended with regard to the VaNetLayer in order to support the transient states while some transactions have not been added to the blockchain yet. This is summarized in the state diagram of Figure 3.

• In an INITIAL state, the VN waits for a physical node to initiate a transaction, which takes it to REQUEST state and sets to 0 the counters used thereafter: requestCount and validationCount.
• Within REQUEST, the t_RequestValidators timer is activated and an m_RequestValidators message is sent, incrementing the requestCount by 1. The objective is to request the presence of at least 3 local nodes in the region to pre-validate the transaction. If t_RequestValidators expires without reaching the minimum number of validators, the REQUEST is reactivated once, and if it fails again the VN evolves to CHANGE state. Otherwise, the state becomes VALIDATION.
• The CHANGE state denotes that the region does not have enough vehicles to pre-validate the transaction. In response to that, a neighboring VN is asked to take over by transmitting an m_changeCVN message.
• In VALIDATION state, the VN confirms the participation of the validators and responds with an m_InitValidation message, which activates the t_WaitValidation timer and increases the validationCount. This process is repeated up to 3 times, remaining in VALIDATION until it receives the requested verifications through m_ValidatedTransactions messages. If validationCount rises to 4, it automatically moves to CHANGE, otherwise it can fall into DROP or PROPAGATE.
• The DROP state means that positive validations were not sufficient, so the transaction is discarded. Then, an m_DropTransaction message is broadcast and the state becomes VIRTUAL NODE.
• Having got the minimum number of positive validations, the PROPAGATE state is reached, where the VN sends the validated transaction to the nearest mRSUS accompanied by the message m_confirmMRSU, which activates the t_WaitMRSU timer. While the timer is active, it waits for the confirmation message m_StatusMRSU==true. If this is not received, the process is repeated indefinitely in order to guarantee that the information has reached the mRSU.

4. Simulation Experiments

With the finished design of the VaNetChain, we proceeded to evaluate its performance through simulations under different conditions. In the specialized literature, there are no pre-established metrics on the use of blockchain in VANETs, as the diversity of uses, protocols, optimizations and cryptocurrencies prevent the standardization of parameters that could be considered optimal. Nonetheless, we could look at the consumption of gas in the Ethereum framework to assess the amount of work invested in the transactions. Prior to that, we analyzed the packet delivery ratios and the latencies incurred in the deployment of mRSUs, in order to understand the interrelationships between traffic densities, data volumes generated/transmitted in the VANET and fixed infrastructure needs.

4.1. Performance of the Communications

In the simulation experiments, we compared the latencies and the packet delivery ratios attained by three implementations of blockchain in VANETs:

• A non-virtualized configuration with a protocol stack like the one on the left hand side of Figure 1, with IGRP as the routing protocol.
• A VaNetChain configuration with a protocol stack like the one on the right hand side of Figure 1, with VNAODV+ as routing protocol (reactive).
• Another VaNetChain configuration with a protocol stack like the one on the right hand side of Figure 1, with VNIBR as routing protocol (geographic, intersection-based).

Latencies were measured as the time elapsed since a m_ConfirmMRSU message is sent until the m_StatusMRSU confirmation is received in the state machine of Figure 3. The consensus or mining time of a transaction is not part of this analysis, as the difficulty of the PoW is constantly adjusted to maintain a 10 seconds average.

The simulation scenario comprised a two-lane, 800 × 800 m Manhattan-type urban scenario with 64 intersections, 100 m away from one other. In the virtualized configurations, the road segments were always covered by 3 VNs (421 overall).

Regarding the simulation software, three tools were used: ns-3, 30th release (https://www.nsnam.org/releases/ns-3-30/), SUMO (https://sumo.dlr.de/docs/), and SimBlock (https://dsg-titech.github.io/simblock/). In ns-3, all the procedures followed by the VaNetLayer to achieve the emulation of VNs over PNs were defined; in addition, VaNetChain packets are given top priority thanks to the concept of cVN. SUMO is an urban mobility simulator that provides traces of node mobility. Finally, SimBlock is one good choice to implement a blockchain network, as its parameters can be modeled to model the behavior of any specific technology.

The parameters that are considered key to the simulations are summarized in

Table 1. The main parameters of our simulations.

Parameter	Value
Simulator	ns-3, SimBlock
Blockchain framework	Ethereum
Consensus algorithm	Proof of Work
Routing protocol	VNIBR-VNAODV+-IGRP
Simulation scenario	Manhattan type urban area
Propagation model	Hybrid buildings propagation loss model
Intersections number	64
Intersections separation	100 m
Number of PNs (vehicular density)	128-256-512
Number of VNs	421
mRSUs number	8-16-32
VaNetChain transactions	100-1000-10,000-100,000
VaNetChain packet size	1 MB
Transmission rate	6 Mbps
MAC	IEEE 802.11p
Transport protocol	UDP

.

In the first experiment, aiming to measure packet delivery ratios, we varied the vehicular density (128, 256 or 512 vehicles) in a scenario where 10,000 transactions had to be recorded. The results are shown in Figure 4. It can be seen that the VaNetLayer in conjunction with VNIBR yields the best results at low/medium density. The non-virtualized configuration with IGRP outperforms the virtualized one of VNAODV+, because the reactive nature of the latter fails to properly handle scenarios of high mobility. When comparing VNIBR and IGRP at high traffic densities, the differences are small differences because the mobility of the vehicles is reduced and, therefore, the environment is less challenging.

To assess end-to-end delays, we set the number of vehicles to 256 and progressively increased the number of transactions: 100, 1000, 10,000, and 100,000. The results can be seen in Figure 5. The curves of the three configurations exhibit similar dynamics, but VNIBR attains the best performance in all cases. VNAODV+ delivers packets more slowly, mainly because its route maintenance algorithms commonly lead to longer multi-hop paths. IGRP often makes the packets go through fewer hops, but it is less effective than VNIBR in dealing with route breakages, which causes retransmissions from the source and, thereby, additional delays.

Finally, because the mRSUs play a key role in mining and validating new blocks, we considered varying their number and checking how this affects the responsiveness of the VaNetChain. According to the criteria set out in [64], we found that the optimal number of mRSUs was 16; therefore, we changed it to 8 and 32 to establish a point of comparison. For this scenario, owing to the results of the previous experiments, VNIBR was established as a routing protocol. The vehicle density was set at 256 and the number of transactions was varied. The results are shown in Figure 6.

To begin with, it is interesting to note the stability shown by the curve corresponding to 8 mRSUs: although the number of transactions increases, the measured times range between 386 and 394 ms. The explanation lies in the fact that a lower density of mRSUs implies the participation of a greater number of virtual nodes in the transactions. Moreover, as the number of transactions increases, a small increase in the latency curve is due to the queuing caused by the pre-validation mechanisms.

When using 16 and 32 mRSUs, similar results were obtained up to 1000 transactions (around 350 ms), representing an improvement over 8 mRSUS, and therefore fewer virtual nodes involved in the retransmissions. From that point on, the delays with 16 mRSUs start to fall, reaching 308 ms with 100,000; in constrast, the delays increase progressively with 32 mRSUs, reaching 407 ms. An excessive density of miners, therefore, can have a detrimental effect because it implies more mRSUs wasting resources in hash computation races won by others.

4.2. Cost of the Transactions

In order to assess the prospects for implementation in a real environment, we looked at the amount of gas involved in the execution of the intelligent contracts that support the VaNetChain. In

Table 2. Cost of intelligent contract execution (Gas price = 2 Gwei, 1 Ether = 395.02 USD, Date: October 2020).

Smart Contract	Gas Used	Actual Cost [Ether]	USD
Whitelist	70254	0.000140508	0.056
Blacklist	77100	0.0001542	0.061
Announcement	34041	0.000068082	0.027
Verification	94375	0.00018875	0.075
Acceptance	95863	0.000191726	0.076
Valuation	164100	0.0003282	0.13

, it can be noted that the valuation was the operation that entailed the greatest expenditure of gas, because it involves mathematical operations to calculate reputation based on the average of the responses. On the other hand, verifications and acceptances implied an average expense, due to the participation of at least three nodes to verify an event. Something similar happened with the blacklist operations, which incurred an average expense by adding a node and at the same time deleting it from the whitelist. Finally, the whitelist and the announcement operations caused the lowest expenses, as their execution only imply registering one variable.

Overall, the computational cost implied by these figures is not significant, given that Ethereum sets a limit of 8 M of gas [65] to avoid excessive expenses for the deployment of poorly-optimized contracts. This, added to the monetary values demanded in the different transactions (see Table 2), shows that the implementation of our proposal is feasible.

5. Conclusions and Future Work

With the VaNetChain, we have presented a solution to allow robust, reliable, and traceable communications in VANETs, which can provide foundations for the development of new applications that depend on ensuring certain properties for the data generated and transmitted by the vehicles. This is achieved by entwining the blockchain protocols with the architecture and the procedures of a virtualization layer. On the one hand, this serves to overcome the limitations of the consensus and reputation mechanisms presented in the past. On the other, it is the key to guaranteeing proper operation of blockchain technology, whereas previous approaches failed to cope with the challenging environment of VANETs.

The simulation experiments demonstrate the feasibility of the proposal, while reflecting the optimal number of mRSUs to deploy. The effort due to emulating a network of virtual nodes pays off in terms of packet delivery ratios and end-to-end delays. The findings about the density of mRSUs suggest that the mRSUs can be turned on or off depending on the traffic conditions observed at any given moment.

Currently, we are investigating the adoption of the IEEE 802.11bd standard (an evolution of IEEE 802.11p) in our simulation environment, in order to study the impact on VaNetChain performance of having connections with better spectral efficiency, greater reliability and a wider range [66].