Abstract
This paper proposes a novel Internet of Vehicles (IoV) practical Byzantine fault tolerance (PBFT) consensus mechanism suitable for the distributed vehicle-to-vehicle (V2V) scenario and the V2V collaborative congestion avoidance mechanism based on blockchain. Compared with the traditional PBFT consensus mechanism, the proposed IoV-PBFT consensus mechanism has been improved in three aspects. (1) The authenticated vehicles are divided into three types including common nodes, production nodes, and verification nodes. The vehicles in the same congestion road section are used as the consensus participation nodes, which are divided into the production node and verification node. Since the vehicles in this section are moving slowly or even stopping and the number of newly added and departing nodes are less, the identity of the previous nodes is verified before each round of consensus, which ensures the dynamic tolerance with less additional delay. (2) The verification nodes are grouped based on path loss, and the nodes with good channel quality are selected as the leader nodes. (3) The main node in traditional PBFT is omitted, and the two-stage process is used instead of the traditional three-stage process, which effectively reduces the consensus delay and communication complexity. The theoretical derivation and simulation results show that the proposed IoV-PBFT has greatly improved the V2V link quality compared with traditional PBFT, and the success ratio of links between nodes can reach more than 93%, which has met the requirements of establishing blockchain in IoV.
1. Introduction
With rapid urban development, the number of vehicles around the world continues to increase. The roads are getting more and more crowded, and congestion leads to a series of social and environmental problems, such as increased travel time, fuel consumption, and air pollution [1]. For example, the monthly congestion cost in Beijing, China, has been over 1000 yuan, while the time cost caused by congestion accounts for 12.4% of the average monthly wage. Thus, an enormous amount of efforts have been put into developing procedures to congestion detection in recent years.
With the development of wireless communication, artificial intelligent, big data, etc., vehicles are becoming smarter and more autonomous or semiautonomous than before [2, 3]. Internet of Vehicles (IoVs) [4–7] has emerged. In IoV, a large number of vehicles are interconnected with each other and connected to the Internet to support the realization of the intelligent transportation system (ITS). Traffic information is automatically collected, disposed, and broadcasted through IoVs for congestion detection, road condition prediction, and efficient service delivery. Now, IoV has become one of the measures to ease traffic congestion in cities.
Since drivers are able to perceive tiny but essential traffic information compared with detection devices, vehicles often generate and broadcast messages about traffic information, which brings advantages to intelligent transportation. However, the privacy of vehicle, authenticity of shared data, existence of malicious users, and deliberately false and missing information have been important issues in IoV in recent years.
Bitcoin is the first invention of blockchain launched in 2008 by Satoshi Nakamoto as a digital distributed ledger for the purpose of addressing the double-spending problem of the cryptocurrency [8, 9]. A blockchain is a tamper-resistant data chain ordered by data blocks and contains a data area and a pointer to a previous block. And as a distributed ledger, blockchain can record transactions in a trusted and credible environment without central authority.
Blockchain is an effective solution to the problem of collecting, transferring, storing, and protecting data and has received more attention as an emerging technology in recent years [10–12] and has great potential in various areas such as finance, energy trading, supply chain management, and Internet of Things (IoT) [13].
Blockchain is considered an innovative approach for IoV because of its inherent properties of decentralization, transparency, traceability, and immutability. Secure data exchange mechanisms are introduced in IoV together with blockchain technology [14].
Modern vehicles share their data about the road congestion and store them on the blockchain. Blocks are distributed over all vehicles, which makes it difficult to change the original data stored on the blocks and keeps the series of blocks logically consistent. Thus, significant research is needed regarding the combination of road congestion and blockchain.
The consensus mechanism is an important part of blockchain that mainly solves the problem of who creates the block and how to maintain the unity of the block data in the peer-to-peer network. A number of consensus mechanisms including proof of work (PoW), Paxos, Raft, and practical Byzantine fault tolerance (PBFT) have been proposed and applied in different blockchain scenarios.
PoW is one of the most popular consensus mechanisms, in which all nodes attempt to find a solution to a hash puzzle. PoW is widely used in bitcoin and other public chains [14]. The core idea of the PoW consensus mechanism is to ensure the consistency of data and the security of consensus by introducing the computing power competition to the distributed nodes. The PoW mechanism is relatively simple and easy to implement. There is no need to exchange additional information between nodes to reach a consensus. However, the average generation time of each block is 10 minutes, and the final transaction confirmation time takes 1 hour, which is not suitable for the high requirements of IoV for low delay.
Paxos [15–17] and Raft [18, 19] improve consistency and security by restricting permissions and setting a trusted environment. Even under a fully asynchronous model, Paxos and Raft preserve safety thanks to its balloting and anchoring system. Paxos variants have been deployed ubiquitously in many cloud computing and web applications to provide distributed coordination nowadays. However, Paxos and Raft mechanisms are considered as consensus mechanisms for private blockchain [18] and cannot be applied to the scenarios with malicious nodes.
The PBFT consensus mechanism [20–22] was originally developed as one method to ensure the integrity of a distributed network. In PBFT mechanism, all nodes are required to participate in the voting process to add the next block and exchange messages to reach consensus. In PBFT, the consensus time is reduced to seconds, which is applicable to the consortium blockchain. The PBFT is suitable for IoV scenario because of its high throughput and ability to negotiate message validity [23, 24]. However, on the one hand, it requires a fixed number of nodes and suffers from a lack of dynamic tolerance. On the other hand, the number of communications between nodes increases sharply with the increasing number of nodes. For the scenario with a large number of nodes, it will lead to network congestion and significant reduction of the consensus efficiency.
However, designing the consensus mechanism of blockchain for IoV is extremely challenging. The main distinguishing features of IoV different from other scenarios are shown as follows: (1)Vehicles are moving, so the number of vehicles in the certain area continuously varies and the network topology changes dynamically(2)The line of sight (LOS) of V2V communication is prone to be blocked by large vehicles such as trucks and buses because of the low height of vehicle-mounted antenna, which leads to poor reliability of V2V communication(3)A car can move more than 10 meters every second, so it requires consensus mechanism with low delay. However, very few researchers have focused on the consensus mechanisms applicable to IoV
Among the classical consensus mechanisms, PBFT has short delay and can tolerate malicious nodes to a certain extent. Therefore, this paper proposes a blockchain consensus mechanism based on PBFT with consideration of dynamic tolerance, low delay requirement, and poor reliability of V2V communication of IoV.
The major contributions of this paper are summarized as follows: (1)The road congestion model and related derivation based on mathematical theories such as stochastic process are presented(2)The IoV-PBFT consensus mechanism with two stages is presented, which mainly considers the low delay requirements of IoV(3)We designed a grouping algorithm for vehicles, which mainly considers error-prone wireless link between vehicles and can help to reduce communication load(4)We present a blockchain-based collaborative congestion avoidance mechanism and carry out the evaluation that the proposed scheme is more practical in comparison with the former method
The remainder of the paper is organized as follows. The description of the system model and main assumptions are illustrated in Section 2. Section 3 presents the IoV-PBFT consensus mechanism with two stages and discusses its performance. The grouping algorithm for vehicles is also provided in this section. Section 4 gives the theoretical analysis of two collaborative congestion avoidance mechanisms. Simulation results and related analysis are discussed in Section 5. Finally, Section 6 concludes the paper.
2. System Model
In the paper, we focus on the urban transportation scenario. When there is a local congestion because of traffic accidents or other reasons, how to alleviate the current congestion through V2V distributed collaborative congestion avoidance mechanism in order not to result in more serious secondary accidents becomes an important issue [25]. In this part, we first give some reasonable assumptions to simplify the research scenario for the follow-up work and then put forward the theoretical system model.
2.1. Assumptions
Similar to reference [26], some reasonable assumptions are adopted in this paper: (1) In order to achieve short-range wireless communication, each vehicle is equipped with a wireless transceiver, which can realize V2V and V2I communication through direct connection or multihop transmission. (2) Each vehicle knows about its position, moving direction and speed through GPS and ground support units. (3) The vehicle-mounted wireless transceiver can continuously provide power supply, but not unlimited energy. So it is desirable to have a reasonable energy consumption mechanism. (4) IoV is mainly composed of RSUs (road side units), vehicles, and other different types of nodes. The infrastructures such as RSUs are placed at some core intersections in the city, and the network of them has not yet reached seamless coverage. In order to improve blockchain efficiency in IoV, only the wide-range and serious-impact congestion events are reported to the main chain composed of RSU nodes. The small-scale congestions discussed in this paper are solved by regional collaborative congestion avoidance mechanism through V2V communication in side chain.
2.2. System Model
The above assumptions give the basic configuration of IoV. In this part, we first put forward the description of the specific scenario we study on. Secondly, we give the derivation and analysis based on mathematical theories such as stochastic process in order to provide a basis for the performance analysis of the blockchain-based collaborative congestion avoidance mechanism that are put forward in the following chapters.
2.2.1. Scenario Description
In the urban transportation scenario shown in Figure 1, Road 1, 2, 3... 8 are straight roads in four directions connected to the same intersection. Some key notations used in the model are shown in Table 1. It is assumed that each road has a single lane in one direction, and the width of each road is . Suppose that on Road 1, vehicle A which located meters away from the intersection moves very slowly or even stops for a period due to traffic accidents or other reasons. Vehicle A immediately broadcasts the local traffic congestion information to its surrounding vehicles within the communication radius of . Then, the surrounding vehicles start cooperation with the evacuation to avoid more serious congestion.
Could hundreds of surrounding vehicles be mobilized to change their original planning route and start the evacuation cooperation just relying on the broadcast alarm of vehicle A? What if vehicle A makes a wrong judgement? Or, if it is a malicious node with the intention of interfering with traffic order? The traditional mechanism that broadcasts alarm information through flooding is indeed so credulous, so we propose a more rational judgment scheme which put forward in Section 3 in detail.
When we confirm that there is an extreme congestion around vehicle A as shown in Figure 1, how could we conduct coordinated evacuation to avoid further and more serious congestion? It is usually to notify the vehicles in the relevant driving directions to help carry and forward the alarm information and inform the vehicles about to travel to the congested road section to make fine-tuning of the planning route in advance, which is carried out from the following aspects: (a)Inform the vehicles in the same Road 1 moving behind vehicle A to slow down or even stop due to the traffic congestion ahead if there is a single lane. The nearby vehicles in the same moving direction should take part in the consensus mechanism(b)It is important for the vehicles in the opposite moving direction which is Road 2 to carry and transmit the congestion alarm information to inform the vehicles that have entered Road 4, 6, and 8 connected with the same intersection. It is forbidden for vehicles from Road 4, 6, and 8 to enter the congested Road 1. Please divert to the other three directions connected with the same intersection
2.2.2. Vehicle Encounter Model for Road 2
First, let us talk about the probability of encountering a vehicle in the opposite direction on the opposite road. It is assumed that vehicles arrive at the entrance of Road 2 at the rate of in the Poisson process. Since the density of traffic varies at different times of the day, for example, the traffic density is high in the morning and evening for employees rush hours and low at night.pt?>
However, it takes only 3 minutes for the fastest site cleaning of a traffic accident which is one of the main congestion reasons. In such short time, it is considered that the Poisson arrival rate is a constant variable expressed as . Hence, we consider it as a homogeneous Poisson process , whose arrival rate is .
Therefore, the arrival time interval between vehicle and vehicle is set to . The sequence of arrival time interval is the sequence of random variables which is an independently identically distribution. And it is an exponential distribution with the same mean .
A new vehicle enters the communication coverage of vehicle A in every time interval. It receives the alarm message sent by vehicle A and continue moving at the speed of . The vehicle will (i)turn right and enter Road 3 with the probability of after the time of (ii)go straight ahead and enter Road 5 with the probability of after the time of (iii)turn left and enter Road 7 with the probability of after the time of
where represents the maximum communication coverage of vehicle A on Road 2. , , and and , , and represent the probability of turning right, going straight, and turning left at the intersection and the time it takes, respectively.
2.2.3. Vehicle Source Model for Road 1
New vehicles entering Road 1 all come from Road 4, Road 6, or Road 8. In order to simplify the two-step analysis method of initial distribution and dynamic motion, the following specific analysis is made from the entrance of the straight road before the vehicle arrives: (a)It is assumed that there are vehicles arrived at Road 4 at the intersection according to the Poisson distribution whose arrival rate is . These vehicles are about to pass through the intersection in front of it upon arriving. After a vehicle from Road 2 carrying the congestion alarm information of Road 1 arrives at Road 3, all vehicles passing through the intersection from Road 4 know about the congestion information. Therefore, a vehicle from Road 4 will(i)turn right and enter Road 5 with the probability of after the time of (ii)go straight and enter Road 7 with the probability of after the time of (b)It is assumed that there are vehicles arrived at Road 6 at the intersection according to Poisson distribution whose arrival rate is . These vehicles are about to pass through the intersection in front of it upon arriving. After a vehicle from Road 2 carrying the congestion alarm information of Road 1 arrives at Road 5, all vehicles passing through the intersection from Road 6 know about the congestion information. Therefore, a vehicle from Road 6 will(i)turn right and enter Road 7 with the probability of after the time of (ii)turn left and enter Road 3 with the probability of after the time of (c)It is assumed that there are vehicles arrived at Road 8 at the intersection according to the Poisson distribution whose arrival rate is . These vehicles are about to pass through the intersection in front of it upon arriving. After a vehicle from Road 2 carrying the congestion alarm information of Road 1 arrives at Road 7, all vehicles passing through the intersection from Road 8 know about the congestion information. Therefore, a vehicle from Road 8 will(i)go straight and enter Road 3 with the probability of after the time of (ii)turn left and enter Road 5 with the probability of after the time of
2.2.4. Traffic Flow Model on Straight Road with Constant Speed for Road 2
It is assumed that vehicles are moving at a constant speed of on the road without congestion. And the distance between the two vehicles is determined by initial arrival interval . That is, where, as shown in Figure 2, denotes the distance between vehicle and vehicle .
The two vehicles are in the communication coverage of each other, when
According to formula (2),
Problem 1. The probability that vehicle i is the first one in the queue of members.
Analysis: Since the sequence of arrival time interval {} is an independently identically distribution, the distance sequence of each two adjacent vehicles {} is also an independently identically distribution. Since D is much smaller compared with , we regard that . Here, we assume that the 0th vehicle arrives at time of 0.
Problem 2. The number of vehicles on the road in meters away.
Analysis: It takes the time of to move though meters on the road with the constant speed of .
In fact, it is equivalent to solve the problem of how many vehicles arrive in the period of .
It is assumed that all vehicles on the road move at the same speed of . So, there is no catch-up propagation of alarm information in the same direction, but only sweeping propagation on Road 2, Road 3, Road 5, and Road 7 and vehicles on the opposite road such as Road 1, Road 4, Road 6, and Road 8 receiving their information, respectively.
3. Consensus Mechanism for IoV
In the last section, the reasonable assumptions of urban transportation scenario and a brief mathematical derivation are carried out. However, traditional flood alarm notification scheme is short of authenticity judgment mechanism, which is the defect, will be modified in this chapter.
In the vehicle cooperation mechanism, congestion alarm information will directly affect the driving route of hundreds of cars, so it is very important to confirm the authenticity and reliability of congestion alarm information. The traditional congestion determination mechanism is highly dependent on ground infrastructure. In this paper, we propose a consensus scheme for IoV, which achieves the consensus among vehicles and judges congestion information under V2V communication without relying on any infrastructure. This mechanism fully considers the characteristics of vehicle networking including limited V2V communication distance and unreliable link.
3.1. Problems and Analyses for Consensus Mechanism in IoV
According to the specific requirements of consensus mechanism in the abovementioned IoV scenario, a modified PBFT mechanism is proposed in this section.
3.1.1. Target 1: Shorter Consensus Latency
Problem description: Traditional PBFT consensus mechanism is not sensitive to delay, while the Internet of vehicles scenario has high requirement for delay.
Solution: Traditional PBFT consensus mechanism has three main stages including pre-prepare, prepare, and commit as shown in Figure 3(a). In order to reduce consensus delay, we adopt two-stage consensus instead of three and cut the role of master replica node. Figure 3(b), the whole process including (1) prepare: the client sends a require message to Replica 1, Replica 2, and Replica 3; (2) commit: Replica 1, Replica 2, and Replica 3 send the commit message to other nodes, respectively. Each node gives a result according to the commit message, and replies to the client node.
(a) PBFT consensus
(b) IoV-PBFT consensus
3.1.2. Target 2: Better V2V Wireless Link Quality
Problem description: the V2V communication is not always stable. The specific reasons are as follows: (1)The communication distance is limited by transmission power. The transmission power of vehicle-mounted transceiver is strictly limited in IoV. For example, according to 3 GPP, the transmission power does not exceed 23 dBm and the communication distance does not exceed 100 meters generally(2)The V2V link quality is not stable. The vehicles are in motion in IoV. And the wireless link quality varies randomly at different times. For example, the signal may be blocked with the low height of the vehicle antenna when there are large vehicles between them
Therefore, the V2V communication link regulation is always like this: (1) The received signal intensity for vehicles traveling in the same direction may be low because of signal blocking caused by large vehicles such as large buses and trucks. (2) Vehicles in opposite lanes travel in opposite directions, so the duration of reliable communication between vehicles on Road 2 and Road 1 is not long.
Solution: the vehicles with good link quality are divided into a group for intragroup consensus. Select one leader vehicle in each group to make the leader nodes also have better link quality between each other, and then make an inter-group consensus. This ensures that all nodes can participate in the consensus.
3.1.3. Target 3: Save the Extra Process for Node List Updating
Problem description: the most important difference between IoV and other traditional scenarios that PBFT consensus are commonly used is the dynamic of nodes. There are vehicles entering and leaving the communication coverage in each period of consensus round.
Solution: most papers maintain a list that record all the nodes in the communication coverage. Adding new comers and removing the nodes just leave away. However, process of updating the list needs an extra time cost, which often leads to a specific break between two consensus rounds. However, the indeed need for IoV-PBFT is that we should know the number of nodes in every round actually. In this paper, we get the nodes number information in the process of grouping in the first round and group fine-tuning in other rounds, which can save the delay for extra process of node list updating.
3.2. Identity Model for Consensus
Each vehicle in IoV acts as a peer node and is connected in any way to form a consortium blockchain. According to their different functions, the identity of each vehicle node is not the same. Each node has a certain identity and an account number and independently owns public-private key pairs and digital certificates. With the cooperation of different identity nodes, new blocks are generated and uploaded to the chain orderly, and the consistency of node data in the network is guaranteed. In the consensus design of this paper, as shown in Figure 4, nodes are classified into three roles: (1)Common node: all vehicles added to IoV should be authenticated firstly with their license numbers, owners and other information. A vehicle can pass the authentication if its identity information is valid. A node that has passed the identity authentication becomes an ordinary node and participates in various services and applications in IoV. Nodes in this role cannot participate in the process of consensus and block generation, but can only participate in the process of block distribution and sharing(2)Production node: the nodes in the same congestion lane with the same moving direction and adjacent to vehicle A can compete for production nodes. Common nodes with good communication link quality not only between themselves but also with most vehicles on the congestion road are selected as production nodes. One production node is responsible to generate and package a new block. And another production node is selected before next new block generation. The production node that has correctly generated a block will be rewarded, which encourages nodes to actively participate in the work in IoV(3)Verification node: all nodes around the congestion area of the Genesis block and moving in the same direction within the communication coverage of each other can become verification nodes. The verification node has the right to vote for the block information, verify its correctness, and evaluate the production node
The relationship and conversion logic between the three identities of nodes are shown in Figure 4. The production node and verification nodes take part in the consensus mechanism, while common nodes such as vehicles on Road 2 do not do anything in consensus process.
The production node gives the information of new block to verification nodes for information consensus. And the verification nodes score the block quality of production node and its links. The scores and link qualities of different verification nodes help them become production node in next round of voting.
In addition, the production node records and scores the contribution of each voting result of the verification node to the block generation in order to find malicious nodes and eliminate them regularly, which improves the efficiency of subsequent consensus and fault tolerance performance, and enhances the security of system.
3.3. Consensus Process
In this part, the whole consensus process is put forward as shown in Figure 5.
3.3.1. Initiate Congestion Beacon
If the average speed of vehicle is below within a certain period of time , it reaches the congestion threshold. At this moment, the vehicle activates the broadcast process of congestion beacon in its communication coverage with the information of “is the average speed of nearby vehicles moving in the same direction as me below v0 in the latest period of t0?” And the beacon information carries the channel detection parameter.
3.3.2. Select Production Node
Assuming that a congestion occurs on a certain section of Road 1, multiple vehicles in the area will successively reach the congestion threshold and broadcast congestion beacons as shown in Figure 1. The vehicle that first receives congestion beacons broadcast by neighbor nodes will be declared as the production node in this round of consensus and then broadcasts this information around. The parameter of should be reasonably set or adaptively defined according to the current number of lanes and vehicle speed in the same direction, for example, . Because the channel quality between the vehicle that receives the most traffic congestion beacons in the shortest time and other vehicles is better with great probability according to the channel reciprocity.
Select a node with the best current communication quality as the production node every other period of time. On the one hand, the communication quality of the production node is guaranteed to be the best. On the other hand, since a production node generates only one block, the role of replica main node for sorting the block packaging can be omitted.
3.3.3. Group Verification Nodes
The most important difference between IoV and other scenarios is the V2V wireless link, which directly affects the performance of consensus and blockchain mechanism. The wireless channel characteristics of urban roads are investigated by ray tracing (RT) simulation technology in [27]. The RT simulation results show that the LoS path may be blocked by large vehicles, e.g., trucks and buses, as shown in Figure 6. Especially the link between small vehicles, since the vehicle-mounted antenna is generally installed on the roof with low height, therefore, the farther the transceiver distance, the lower the LoS probability and the greater the path loss caused by occlusion.
Base on the RT simulation, the path loss model in 5.9 GHz band, which is the most promising band for V2V, is derived as shown in
where is the interception, is the distance between transmitter and receiver whose unit is meter, is the path loss exponent, and and are the additional losses in the LOS and nonline-of-sight (NLOS) conditions, respectively.
By data fitting, the parameters are set as follows: is 47.55, is 1.937, follows Weibull distribution with mean about 0 dB, and follows multimodal Gaussian distribution with mean about 18 dB per obstacle.
The wireless link between two small vehicles may be blocked by large vehicles, which results in high path loss. When the path loss is more than the threshold , the received signal is too low to be correctly received. Thus, it is very difficult for all nodes to achieve consensus through direct communication in V2V scenario.
Furthermore, the vehicle density is high in congestion road, and a large number of vehicles communicating with each other cause broadcast storm, high packet collision, computing complexity, and delay.
Therefore, nodes should be grouped appropriately. In [28], nodes are grouped according to their physical fuzzy distance. However, in most cases in V2V scenario, the obstacle instead of distance between transmitter and receiver is the key factor of path loss. And the grouping algorithm based on distance does not work well when there are many large vehicles.
In this paper, a node grouping algorithm based on path loss is presented to ensure that the path loss between group leader nodes and the path loss between nodes in each group are lower than the path loss threshold, and ensure that as many nodes as possible participate in the consensus process.
Some assumptions are made in the grouping algorithm as follows: (1)Each vehicle node has a unique ID, which contains the information of vehicle type. That is to say, large and small vehicles can be distinguished by their IDs(2)The transmitting power of each vehicle is the same(3)Each vehicle can identify the signals of other vehicles and measure the received signal power(4)The channel has reciprocity, that is, the path loss from the th vehicle to the th vehicle is equal to the path loss from the th vehicle to the th vehicle(5)The path loss between two vehicles keeps static throughout the consensus process
As shown in Figure 7, the grouping procedure based on path loss has following6 stages. (i)Stage 1: the production node selects nodes from the nodes that have transmitted the alarm information to production node successfully as the preparatory group leader nodes and broadcasts the preparatory group leader list to all nodes. And large vehicles have higher priority than small ones(ii)Stage 2: the preparatory group leader nodes broadcast their own IDs and measure the path loss with other leader nodes by the receiving signals from other leader nodes(iii)Stage 3: when the path loss between two group leader nodes is greater than the threshold of path loss , the leader node will report it to the production node(iv)Stage 4: according to the feedback messages from preparatory group leader nodes, the production node deletes as few preparatory group leader nodes as possible from the group leader node list to ensure that the path loss between all group leader nodes does not exceed the threshold . Then, the production node broadcasts the formal group leader node list to all nodes(v)Stage 5: other nodes act as group member nodes and measure the path loss between themselves and all formal group leader nodes according to the broadcasting messages from the group leader node and add the group leader node to the application list when the path loss between the leader node to itself is less than the (vi)Stage 6: the group leader node determines whether to accept the group member node according to the following rules:(1)The group leader node is the unique node in the application list of the group member node (2)The group leader node has the least path loss with the group member node in all leader nodes(3)The number of member nodes in this group is not more than , which is the upper limit of group size
In the presented grouping algorithm based on path loss, there may be a small number of nodes that are not accepted by any group, and these nodes will not participate in the consensus. But the simulation results in Section 5 show that the probability is very low. Moreover, there is no significant difference in the number of nodes in each group due to the upper limit of group size , which ensures fairness.
The verification nodes are grouped into different groups, and a node with relatively good link quality is selected as the leader node. As shown in Figure 8, we firstly conduct intragroup consensus among verification group member nodes (VGM) and then conduct intergroup consensus among the verification group leader nodes (VGL). In this way, the consensus of the entire V2V network can be achieved only when the link quality between the verification nodes in each group and the link quality between the leader nodes are good. Therefore, the problems of limited V2V communication distance and poor link quality caused by occlusion are solved.
In addition to the production node, the node that receives the most information in the previous round of consensus is selected as the production node in the next round of consensus. Then, the grouping of verification nodes is fine tuned. In the process of fine tuning, you can know the number of nodes in the coming round of verification.
3.4. Performance Analysis of Consensus
Researchers usually expect the ideal consensus mechanism to have higher security, faster verification speed, less storage, and link resource consumption on the basis of ensuring the correctness of the consensus. According to the goal, we have made efforts in these aspects and made some breakthroughs.
3.4.1. Consensus Correctness
In this scheme, each verification group leader node sends the consensus result that how many Y (Yes) and N (No) are there among the total number of nodes in its own group to all other group leader nodes. The group leader node judges whether a consensus can be reached by the proportion of Y received in the total number of all verification nodes from all group leader nodes. So, the same correctness as the traditional PBFT consensus without grouping can be achieved.
If the probability of one vehicle is in congestion when it is moving below v0 in the latest period of is , the probability of this area is in congestion when one vehicle received congestion beacon for 10 times is
The correctness of this judgement is improved by
Take for example, the correctness of congestion judgement after consensus is
The correctness of this judgement is improved by 24.9%.
3.4.2. Consensus Security
The nodes with objective opinions against the consensus result are recorded in each round of consensus. Once the production node has not generated block successfully or the verification nodes have not given the same opinion as consensus result for more than 3 times, they will be added to the blacklist and will not be selected for production node in the following rounds of cycle. Thanks to this method, the fault tolerance rate of the system is gradually improved and then the security is improved.
3.4.3. Consensus Delay
This scheme improves the verification speed of consensus mechanism from three aspects.
Firstly, the two-stage PBFT consensus process is adopted to replace the three-stage consensus process including prepreparation, preparation, and commit adopted by the traditional PBFT, so as to reduce the consensus delay.
Secondly, the role of replica main node is deleted, and the functions of replica main node and client node are transferred to the production node together. Therefore, the related processes of require distribute from the client node and reply to the client node are saved.
Thirdly, since the verification nodes are vehicles in the same direction on the same road, their relative positions are pretty much the same. And there is no need to bring frequent topology changes due to the high-speed movement of nodes, including the frequent updating of the verification node list caused by newly added nodes and elimination of leaving nodes. Omitting the updating stage of list can avoid the interruption of consensus caused by frequent updating of list, which ensures the overall verification speed of the consensus mechanism.
3.4.4. Communication Resource Consumption
The number of communication in a round of consensus is often regarded as the index for algorithm complexity.
(1) Classical Scheme. Traditional PBFT consensus process has classic three-stages including the prepreparation stage, preparation stage, and committing stage, as shown in Figure 3(a). Assuming that the total number of nodes participating in the consensus process is (), let us research on the total number of communication in a classical consensus process: (i)Prepreparation stage: the replica main node sends the processed request broadcast to the other replica nodes, and the number of communication is ()(ii)Preparation stage: the other replica node sends the verified message to all nodes participating in the consensus excluding itself, and the number of communication is (iii)Committing stage: all nodes participating in the consensus confirm each other, and the number of communication is
Therefore, the sum which is the total number of communication in classical scheme satisfies the formula:
(2) Reference Scheme. The two-stage consensus process of MLPBFT [29] includes the preparation stage and verification stage. Assuming that the total number of nodes participating in the consensus process is also (), then (i)Preparation stage: the master node sends the query message to the supervision nodes, and the number of communication is ()(ii)Verification stage: the supervision nodes send valid messages to each other for confirmation and verification, and the number of communication is
After the consensus process is completed, the supervision node needs to send the consensus result committing message to the client node and the master node. At this time, the number of communication should be .
Therefore, the sum which is the total number of communication in reference scheme satisfies the formula:
(3) IoV-PBFT Scheme. The two-stage consensus process of grouping PBFT proposed in this paper includes the preparation stage and verification stage, as shown in Figure 7. Assuming that the total number of nodes participating in the consensus process is also (), and all verification nodes are divided into g groups, which the th group has member nodes and the total number of groups is . Therefore, . (i)Request stage: the production node first sends the query message to the verification group leader nodes, and the number of communication is (ii)Preparation stage: verify that the group leader node forwards the query message to its group member nodes, respectively, and the number of communication is (iii)Intragroup verification: each verification group member node sends messages to all other nodes in the group, and its number of communication is (iv)Intergroup verification: verification group leader nodes send valid messages to each other for confirmation and verification, and the number of communication is (v)Reply: after the consensus process is completed, the verification group leader node needs to send the consensus result committing message to the current production node. At this time, the number of communication is
Therefore, the sum which is the total number of communication in IoV-PBFT scheme satisfies the formula:
It is difficult to directly compare Formula (15) with the previous classical PBFT and MLPBFT. To analyze it deeply, we find that the number of communication is the largest when each verification group has only one node, while the total number of communication is the smallest when each verification group has 4 nodes. These two situations are analyzed in detail in the following: (i)The upper limit
It is assumed that every verification group has only one leader without any member. Therefore,
So, the number of communication achieves the largest value which is (ii)The lower limit
According to Formula (15) and methods of optimization, we find that the number of communication achieves the smallest value which is
subject to:
All in all,
Comparison among the above three methods according to formula (13), (14), and (17).
Because , the results of the above two formulas (20) and (21) are always greater than 0, that is, is always true. Therefore, on the premise of the same number of vehicles participating in the consensus process, the number of communication in the IoV-PBFT proposed in this paper is smaller than those in two-stage MLPBFT and traditional three-stage PBFT. The scheme proposed in this paper has a lower number of communication.
This section describes how vehicles reach a consensus on the congestion status information of the current road section by V2V communication, which is the basis for them to make consistent cooperation avoidance actions later.
4. Blockchain System and Delay Performance Analysis
Based on the modeling of urban transportation scenario in Section 2 and the V2V group consensus in Section 3, we put forward a scheme in this section for vehicles to cooperate for congestion avoidance by establishing a blockchain system for congestion in partial area, which can reduce the impact of vehicle congestion on public travel, personal safety, and avoid secondary accidents. Based on the following theoretical analysis and simulation, we find that the blockchain scheme proposed in this section can effectively improve the autonomous vehicle participation, reduce the effective delay, and improve the system reliability.
As shown in Figure 1, it is assumed that the congestion occurs on Road 1 at a distance from the intersection, the radius of the communication range of each vehicle is , and the width of each lane is . Given the scenario established in Section 2, the cooperation avoidance scheme based on blockchain is carried out and the effective delay is analyzed in the following.
Now, we research on the broadcast function of vehicles moving on Road 2, which have given in (b) part of Section 2. Assume that vehicles arriving at Road 2 at a rate of may turn right, go straight or turn left at the next intersection with the probability of , respectively, where .
The probability of vehicles successively arriving at Road 2 in the period of is
Suppose that vehicle A perceives its surrounding congestion and starts the consensus mechanism for the Genesis block. The time when it starts to send collaborative congestion avoidance information to surrounding vehicles is recorded as time 0, and the time when the congestion ends is recorded as time . The road congestion is mainly the vehicles driving from Road 4, Road 6, and Road 8 to Road 1 from time 0 to time . Here,
The parameters indicate the moment when vehicle from Road 2 is turning right, going straight or turning left and entering the Road 3, Road 5, and Road 7 for the first one, respectively. The number of vehicles blocked in the congestion of Road 1 is no longer increase from the moment {}: (i)If vehicle in the 1st fleet is the first vehicle to turn right on Road 2, then (ii)If vehicle in the 1st fleet is the first vehicle to go straight on Road 2, then (iii)If vehicle in the 1st fleet is the first vehicle to turn left on Road 2, then
where donates the time that the th arriving vehicle on Road 2 takes to arrive at the intersection. Assuming that .
It is assumed that the congestion road section of the research problem is only a small part of the whole city map, and the urban road map is infinite. Whether each vehicle turns right, goes straight or turns left at the next intersection is an independent event. Suppose there are totally vehicles arrived at the intersection from time 0 to .
4.1. The Number of Vehicles Blocked behind Vehicle A on Road 1
(1)The probability that the last vehicle is the first one turning left on Road 2 is
In this case, the time delay for completing the notification of Road 4, Road 6, and Road 8 is .
If the 1st one is the first turning right vehicle and the th one is the first going straight vehicle, the number of vehicles blocked behind vehicle A in the same direction on Road 1 is
According to Formula (8), the number of vehicles on a road of length meters is
The number of vehicles from Road 4 to Road 1 arrived later is
So, (2)The probability that the last vehicle is the first one going straight on Road 2 is
In this case, the time delay for completing the notification of Road 4, Road 6, and Road 8 is . (3)The probability that the last vehicle is the first one turning right on Road 2 is
In this case, the time delay for completing the notification of Road 4, Road 6, and Road 8 is: .
4.2. Analysis of Effective Delay
In this part, the effective delay in the proposed blockchain scheme and the traditional flooding scheme is compared.
4.2.1. Analysis of Effective Delay in Traditional Flooding Broadcast Scheme
In the pure flood information broadcast scheme, when vehicle A is in congestion, the congestion information is broadcast to the vehicles within its communication coverage range. After receiving the congestion information, the vehicles moving on Road 2 in the coverage of vehicle A will carry and forward the congestion information of Road 1 to all the vehicles within their communication range, especially the vehicles on Road 4, Road 6, or Road 8 while the information-received vehicles are moving to Road 3, Road 5, or Road 7 afterward, respectively. In pure flooding scheme, broadcasting information will be forwarded to every vehicle encountered once again regardless of whether the future movement direction of the vehicle is related to Road 1 that is in congestion.
Because the pure flood mode leads to serious information congestion and wastes a lot of communication resources, it is often limited in practical application. For example, the information about collaborative congestion avoidance can be forwarded to the vehicles about to drive to the relevant road, such as Road 1 in this modeling scenario. Such targeted form of communication, known as limited flood information broadcast scheme, can reduce the waste of communication resources.
Combined with Formula (24), (29), and (30), in the limited flood information broadcast collaborative congestion avoidance scheme, the total delay for all notification to Road 4, Road 6, and Road 8 is calculated as follows:
4.2.2. Analysis of Effective Delay in Blockchain-Based Cooperative Broadcasting Scheme
The operation principle of the collaborative congestion avoidance scheme based on blockchain proposed in this paper is as follows: When vehicle A confirms that there is a congestion around it under the IoV-PBFT consensus mechanism, it will create a blockchain and package and agree on the surrounding congestion information every once in a while and generate a block. The vehicle on the opposite Road 2 will store all blocks locally and carry and forward to share the blocks with other vehicles. After all vehicles on the surrounding relevant roads meet the vehicles with local storage blocks, they exchange the blocks list with each other and then receive, download, and store the blocks that are not available locally, read the block information in time, and make corresponding moving plan changes.
The th vehicle receiving the first congestion block on Road 2 is turning right to Road 3 at the intersection, and the moment it reaches Road 3 is . It is assumed that this moment is the initial time of vehicle distribution on Road 4, which according to Poisson distribution. And the distance between the th vehicle and the intersection is . The th vehicle will (i)turn right and enter Road 5 after the period of with the probability of (ii)go straight and enter Road 7 after the period of with the probability of
Assuming that the 1st vehicle on Road 4 will drive to Road 5 and the th vehicle is the first one to drive to Road 7, the probability of this situation is . In this case, the delay when the genesis block has reached all other three directions around the intersection is .
Suppose that the 1st vehicle on Road 2 turns right, the th one is the first vehicle going straight, and the last vehicle which is the th vehicle is the first one turns left. The probability of the situation is .
In this case, the delay when the genesis block has reached all other three directions including Road 3, Road 5, and Road 7 around the intersection is where represents the time that the th vehicle in the communication range of vehicle A on Road 2 will take to arrive at the intersection.
represents the time that the th vehicle on Road 4 will take to arrive at the intersection, which is the first vehicle to go straight to Road 7, when the 1st vehicle turns right on Road 2 and reaches Road 3.
represents the time that the th vehicle on Road 6 will take to arrive at the intersection, which is the first vehicle to turn right to Road 7, when the 1st vehicle turns right on Road 4 and reaches Road 5.
In order to analyze conveniently, it is assumed that the time relationship of right turn, straight going, and left turn through the intersection is
Because the right turn only takes up one grid at the intersection, the conflict waiting time is the minimal. However, straight going takes up 2 grids and left turn takes up 3 grids, where , .
Let represents the distance between vehicle A and the last vehicle behind A which still can communicate with A at time 0, .
Assuming that the first vehicle in the area of on Road 2 is moving and located at away from the intersection at time 0. Assuming this vehicle is the th vehicle in its fleet, which means there are another vehicles ahead available to communicate with each other.
According to Formula (7), the probability of the fleet is
So, the first vehicle in the fleet is the first one received alarm information on Road 2 at time 0, which is located at away from the intersection. And the second vehicle in the same fleet is located at away from the intersection. Therefore, the th vehicle in the same fleet is located at away from the intersection.
The time that the th vehicle reach the intersection is
Then, the effective delay can be simplified to
Different from the traditional flooding method, the first possibility of delay in blockchain mechanism is given when
The second possibility of delay in blockchain is given when the vehicle from Road 4 is the first one arriving at Road 7, that is,
The third possibility of delay in blockchain is given when the vehicle from Road 6 is the first one arriving at Road 7, that is,
The final delay take the smallest of (37), (38), (40), and (41).
Comparing the two schemes, it is found that the effective delay of the blockchain-based collaborative congestion avoidance scheme is lower than that of the limited flooding scheme. As the limited flooding scheme has reached the situation that Road 4, Road 6, and Road 8 have been notified, it is required that vehicles with alarm information on Road 2 have reached Road 3, Road 5, and Road 7, respectively. Under blockchain scheme, vehicles downloaded congestion information blocks on Road 4 may arrive at Road 5 and Road 7 ahead of vehicles from Road 2. Or the vehicle downloaded the congestion information block from Road 5 arrives at Road 7 ahead of the vehicle from Road 2. Therefore, the blockchain-based collaborative congestion avoidance scheme proposed in this paper will reduce the effective delay of collaborative congestion avoidance to a certain extent.
5. Simulation and Analysis
In this section, we evaluate performance of the proposed IoV-PBFT consensus mechanism and blockchain-based collaborative congestion avoidance mechanism. In this part, we use the software of MATLAB for simulation and analysis, which is widely used in data analysis, wireless communication, deep learning, control systems, and other fields. In the simulation process, we first simulate the different numbers of intragroup and intergroup links and the ratio of success links with and without grouping in three different cases. Secondly, we simulate and analyze the delay from congestion is detected to the moment when the number of congestion vehicles is no longer increase behind vehicle A in three different congestion avoidance mechanisms. This part is based on the simulation of Road 1 to Road 8 around an intersection in Figure 1, and the vehicles randomly arrive at the road entrance according to the Poisson distribution and mobility model of cellular automata.
5.1. The Communication Link Quality Improved by IoV-PBFT
In this section, we simulates the performance of node grouping. In the simulation, it is assumed that there are vehicles, which are randomly distributed on the road, and the spacing between two vehicles follows the uniform distribution on . The proportion of large vehicles in the total vehicles is . The path loss threshold is . The simulation parameters and results are shown in Table 2.
The initial distribution of vehicles is randomly generated and simulated for 10 times. Figures 9–11 show the link quality improved by IoV-PBFT with different parameters such as , , , and in case 1 ~ 3, respectively. It is shown from each figure that the number of intergroup links is small, most of the links are intragroup links. Figure 9(b) shows that the ratio of success link in traditional PBFT is fluctuating from 48.8% to 62.5%, which is mainly because of the bad channel link quality sheltered by other vehicles. However, after grouping method of IoV-PBFT, the ratio of success link can be improved to almost bigger than 90%, sometimes even up to 100%, owing to the valuable IoV-PBFT consensus mechanism, which is able to guarantee the good communication in a blockchain system. The general trend of Figures 10 and 11 is almost the same with Figure 9. But the ratio of success link in Figure 10(b) fluctuates drastically than Figure 9(b) because of 5% less proportion of large vehicles. In addition, the ratio of success link of IoV-PBFT in Figure 11(b) fluctuates gently than Figures 9(b) and 10(b) because of more verification nodes with less spacing between two vehicles. We find that this IoV-PBFT method has a good applicability in dense vehicle scenario.
(a) The number of intergroup links, intragroup links, and total links
(b) The ratio of success link
(a) The number of intergroup links, intragroup links, and total links
(b) The ratio of success link
(a) The number of intergroup links, intragroup links, and total links, respectively
(b) The ratio of success link
Some important performance results in simulation are shown in Table 2. The reduction of total link numbers is 78.8%, 75.5%, and 81.4%. It means the less occupied communication resources and reduction of the time duration in consensus mechanism.
With the increase of proportion of large vehicles, the link success rate decreases when there is no grouping process in PBFT. After grouping, large vehicles tend to be selected as group leader nodes, so the link success rate after grouping is improved, which is shown in Figures 9(b), 10(b), and 11(b).
From Figures 10 and 11 and Table 2, it is shown that the number of vehicles increases with the decrease of spacing between vehicles. The number of links in Figure 11 increases by 127% than that of Figure 10. After grouping, the number of links decreases to 18.6% of the original method. Moreover, the link success rate after grouping is also much higher than that without grouping. The ratio of success link in PBFT is 63% and 97% in IoV-PBFT, which is improved by 53.97%. The ratios of success link in IoV-PBFT are 97%, 93%, and 97%, respectively, which can satisfy the requirement of link quality for blockchain system in IoV.
5.2. The Effective Delay in Different Collaborative Congestion Avoidance Mechanisms
In this section, the effective delay which is the most important performance in IoV of classic flooding, limited flooding, and blockchain-based collaborative congestion avoidance mechanism is simulated and compared. The simulation parameters are listed in Table 3.
Figure 12 shows that the effective delay decreases with the increase of traffic density in all of the three different collaborative congestion avoidance mechanism. There has been a time delay for the vehicles find themselves are in congestion, and the congestion alarm information is sent and arrived at the three directions after passing the intersection, that is, the effective delay of congestion avoidance.
The simulation result is derived from 10 times of simulation. The classical flooding mechanism has minimal delay because any vehicle can receive the alarm information and forward it to any other vehicle, which creates extremely redundant copies, leads to communication congestion, and occupies a lot of communication resources. Therefore, this method is difficult to be applied in practical engineering scenarios. Instead, limited flooding is commonly used. In limited flooding mechanism, vehicles coming from Road 2 only receive first-hand alarm information and forward the alarm information to any vehicle. But other vehicles only receive the alarm information from vehicles from Road 2 and do not forward it. The effective delay in limited flooding mechanism is twice even bigger than that in classical flooding. The delay of proposed blockchain mechanism is a little bigger than delay in classical flooding. Because it is also unlimited transmission as a classical one. But there is a little delay from extra consensus process, which is set to 2 seconds in the simulation. Therefore, the proposed collaborative congestion avoidance mechanism based on blockchain is best with relative lower delay and fewer copies.
6. Conclusion
In this paper, we have proposed a consensus mechanism for IoV and a blockchain-based collaborative congestion avoidance method. Theoretical performance of proposed consensus is evaluated by the saved communication resources consumption and the improved of correctness for congestion judgement. Moreover, it is theoretically analyzed that the blockchain-based collaborative congestion avoidance method can reach a shorter effective delay in some probability regardless of consensus delay compared with the limited flooding mechanism.
According to the simulation analysis, the ratio of success links can reach 93%, which can ensure the operation of blockchain in the Internet of vehicles. The proposed blockchain-based collaborative congestion avoidance method has relative less delay with ideal copies.
In future work, we aim to work on the research of consensus mechanism and the blockchain-based collaborative congestion avoidance method for large-scale area or drastic congestion with the help of RSU.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that there is no conflict of interest regarding the publication of this paper.
Acknowledgments
This work was supported by the Fundamental Research Funds for the Central Universities 2022JBMC016 and 2022JBQY004, State Key Laboratory of Rail Traffic Control and Safety RCS2021ZT008, Natural Science Foundation of China under Grant U21A20445, and China Postdoctoral Science Foundation 2021TQ0028.