# Internet of Vehicles Resource Scheduling Based on Blockchain and Game Theory

Authors: Jing Chen; Tong Li
Journal: Mathematical Problems in Engineering
 (2022)

---

## Abstract

With the popularity of on-board intelligent devices, the number of vehicle computing intensive applications is also increasing rapidly. Due to the high mobility and limited computing power of the vehicle, and the extensive and changing demand for computing resources of the vehicle terminal, the vehicle often has insufficient computing power. In order to meet the needs of intensive computing applications of vehicle terminals, the computing tasks of vehicles can be unloaded to edge cloud servers (ECSs) with rich resources and high performance to enhance the computing power of vehicle terminals. However, the resource charge of ECS is high, and the scheme needs to consider such issues as ECS signal coverage, long task transmission delay caused by network congestion, and insufficient computing capacity of ECS. Therefore, this study considers unloading the computing tasks of vehicles with insufficient computing resources to nearby vehicles with redundant computing capacity and proposes a resource scheduling method for the Internet of vehicles based on blockchain and game theory. The scheduling of computing resources can reduce the computing workload of buyers’ vehicles and improve the operation efficiency of the whole vehicle network.


---

## Body

## 1. Introduction

In recent years, the Internet of things (IOT) [1–4] has attracted great attention from academia and the industry. Its applications in life can be seen everywhere, such as smart phones, tablet computers, smart TVs, and smart vehicles. As a key branch of the Internet of things, the Internet of vehicles (IOV) [5–7] has also become a key research field and development direction concerned by all walks of life. The vigorous development of the Internet of vehicles has a strong foundation. It is safer, more environmentally friendly, and more convenient to drive. Functionally speaking, it can communicate and add more on-board entertainment, self-diagnosis, and repair, which are the necessary conditions for the realization of unmanned driving. On a deeper level, if the Internet of vehicles is used to realize driverless, the car is not only a vehicle, but also a mobile space. In addition, the Internet of vehicles can also realize vehicle to everything (V2X), where x can be an entity or nonentity [8, 9].However, with the rapid development of the Internet of vehicles, the data of the Internet of vehicles has also experienced a blowout growth in recent years [10–14]. Intel’s Research Report on the amount of data used by Internet of vehicles users a few years ago pointed out that, in 2020, the amount of data used by a car that realizes automatic driving will be 4000 GB [15]. At the same time, in the face of the huge and complicated number of vehicles and roads, plus the huge number of sensors, the Internet of vehicles puts forward high requirements for the processing delay of data tasks and network bandwidth resources.Although the resource scheduling of mobile vehicles in IOV has many advantages, the current resource scheduling scheme still has many problems [16]. Resource scheduling in IOV is mainly conducted through vehicle to vehicle (V2V) and vehicle to RSU (V2R). However, since V2V communication and V2R communication do not encrypt data, malicious nodes can intercept or even tamper with communication data in the process of data transmission [17]. On the other hand, the information between entities participating in resource scheduling is opaque, RSUs located on the roadside are vulnerable to external attacks, and there is a lack of an effective trust mechanism between entities participating in resource scheduling. For the sake of privacy and data security, vehicles may not be willing to participate in the resource scheduling of IOV [18, 19]. Most importantly, there is a lack of an efficient resource scheduling mechanism in IOV, which can not meet the needs of the rapidly changing IOV resource scheduling market. To sum up, the current IOV resource scheduling including data sharing and computing task unloading mainly faces the following three challenges.


### 1.1. Unsafe Data Transmission

During the process of data sharing and computing task unloading, the communication node does not encrypt the data, so the data is easy to be intercepted or even tampered by malicious nodes during transmission, which poses a serious threat to the data security of IOV.


### 1.2. Low Efficiency of the Centralized Dispatching System

In the traditional IOV, the resource scheduling between vehicles is centrally controlled by the authority. Today, with the increasing scale of IOV, the centralized scheduling time and energy consumption are relatively large. On the other hand, if the dispatching organization is attacked, large-scale data leakage may occur, resulting in a series of uncontrollable events.


### 1.3. Lack of Efficient Resource Scheduling Mechanism

The resource scheduling in IOV involves multiple entities involved in scheduling, which makes the process of resource scheduling very complex. This requires us to design an efficient resource scheduling strategy for the two resource scheduling scenarios of data sharing and computing task unloading to meet the needs of the IOV resource scheduling market.In recent years, blockchain technology [20–23] has developed rapidly. Due to its characteristics of decentralization, anonymity, and trust, a large number of researchers have done more and more research work on the combination of blockchain and Internet of vehicles from different angles.Blockchain is a chained data structure. Consensus nodes package transaction records into blocks and link blocks to the blockchain according to the time sequence of block generation. In fact, blockchain can be regarded as a distributed database, which uses encryption technology to ensure that data cannot be tampered with and forged. When the distributed nodes share data, each node can verify the validity of the transaction signature based on the public key in the distributed network to ensure the authenticity of the shared data. In addition, smart contract is also an important technology in blockchain. It is a commitment in digital form, including the specific algorithm to be executed and the algorithm execution conditions. After the smart contract is deployed, it will be automatically executed by computer programs. Through the smart contract blockchain, various distributed applications can be supported to achieve more complex functions. In addition, the blockchain will distribute digital currency rewards to the consensus nodes that have obtained the bookkeeping right, which can motivate the nodes to provide computing power and resources.Blockchain can promote the establishment of a secure, mutual trust, and decentralized intelligent transportation network to solve the resource scheduling problem in IOV and help make better use of transportation infrastructure and resources.


## 1.1. Unsafe Data Transmission

During the process of data sharing and computing task unloading, the communication node does not encrypt the data, so the data is easy to be intercepted or even tampered by malicious nodes during transmission, which poses a serious threat to the data security of IOV.


## 1.2. Low Efficiency of the Centralized Dispatching System

In the traditional IOV, the resource scheduling between vehicles is centrally controlled by the authority. Today, with the increasing scale of IOV, the centralized scheduling time and energy consumption are relatively large. On the other hand, if the dispatching organization is attacked, large-scale data leakage may occur, resulting in a series of uncontrollable events.


## 1.3. Lack of Efficient Resource Scheduling Mechanism

The resource scheduling in IOV involves multiple entities involved in scheduling, which makes the process of resource scheduling very complex. This requires us to design an efficient resource scheduling strategy for the two resource scheduling scenarios of data sharing and computing task unloading to meet the needs of the IOV resource scheduling market.In recent years, blockchain technology [20–23] has developed rapidly. Due to its characteristics of decentralization, anonymity, and trust, a large number of researchers have done more and more research work on the combination of blockchain and Internet of vehicles from different angles.Blockchain is a chained data structure. Consensus nodes package transaction records into blocks and link blocks to the blockchain according to the time sequence of block generation. In fact, blockchain can be regarded as a distributed database, which uses encryption technology to ensure that data cannot be tampered with and forged. When the distributed nodes share data, each node can verify the validity of the transaction signature based on the public key in the distributed network to ensure the authenticity of the shared data. In addition, smart contract is also an important technology in blockchain. It is a commitment in digital form, including the specific algorithm to be executed and the algorithm execution conditions. After the smart contract is deployed, it will be automatically executed by computer programs. Through the smart contract blockchain, various distributed applications can be supported to achieve more complex functions. In addition, the blockchain will distribute digital currency rewards to the consensus nodes that have obtained the bookkeeping right, which can motivate the nodes to provide computing power and resources.Blockchain can promote the establishment of a secure, mutual trust, and decentralized intelligent transportation network to solve the resource scheduling problem in IOV and help make better use of transportation infrastructure and resources.


## 2. System Model

We mainly study the mobile vehicle computing task unloading problem in the resource scheduling of the Internet of vehicles. At present, there are many researches on mobile vehicle computing task unloading, but there are still many problems in the existing schemes, such as vehicle privacy and data leakage, low system operation efficiency, inability to provide an effective incentive mechanism, and so on. Therefore, we propose a scheme for mobile vehicle computing task unloading and build a system framework based on the alliance blockchain.


### 2.1. System Entities

Figure1 is the model diagram of the mobile vehicle computing task offloading system based on the alliance blockchain [20–23] designed in this paper. The model mainly includes three classes of entities: trusted Authority (TA), roadside unit (RSU), and mobile vehicles.Figure 1
System model.The details of the functions of each entity in the system are as follows.


#### 2.1.1. Trusted Authority (TA)

The function of the TA is the same as that of the TA introduced in Section3.1, both of which deal with the registration and authentication of entities in the system and send a digital certificate, public key, and private key to the entity to ensure the security of entity data transmission.


#### 2.1.2. Roadside Unit (RSU)

In the system model, the RSU acts as a vehicle computing task offloading agent responsible for hosting and directing the auction process to handle calculating resource scheduling problems. At the same time, RSU is also the consensus node of the alliance blockchain. A smart contract (Computation Offloading Smart Contract, COSC) that controls the offloading of vehicle computing tasks is deployed on the RSU. A copy of the alliance blockchain is saved on each RSU. There are multiple RSUs beside the road, and the coverage radius is defined as RSUR. Similarly, all RSUs are carried out through communication cables, and mobile vehicles can communicate with RSUs through V2R wireless communication.


#### 2.1.3. Mobile Vehicles

Mobile vehicles with compute-intensive applications waiting to be offloaded act as buyers of computing resources. Vehicle users with idle computing resources can be rented to buyers to act as computing resource suppliers, i.e., sellers. Vehicles can communicate with the RSU through V2R, and the vehicles communicate through V2V. The vehicle also has a wallet for storing resource coins and a virtual identity for privacy protection.As shown in the system model diagram in Figure1, the smart contract COSC divides each RSU and the mobile vehicles within its communication range into a network area according to the communication range RRSU of each RSU, and the network area is named regional computation offloading network (RCON). As the regional manager of an RCON, each RSU manages the offloading of vehicle computing tasks in the RCON and acts as a consensus node of the alliance blockchain on the other hand. RSU will package the transaction records into blocks and pass the corresponding consensus mechanism to link the block to the consortium blockchain. In addition, RCONs are connected by cable, and the same is true between RCONsand the edge server cloud, and they can all communicate with each other. Vehicles can offload computing tasks to other vehicles with spare computing resources in the same RCON through RSU scheduling or offload computing tasks to edge cloud servers through RSU. We focus on the case where a vehicle offloads computational tasks to a nearby moving vehicle.


### 2.2. Basic Assumptions of the Computing Task Offloading Model

The research on computing task offloading [24–26] of mobile vehicles will be based on the following assumptions:(1)
First, consider the communication between model entities. Figure1 shows that wired communication between RCONs and between RCONs and edge cloud servers will be carried out through cables. The communication between them does not need to consider the effect of communication range.The V2R communication between the RSU and the vehicle is affected by the communication range RSUR of the RSU. In contrast, the communication between them does not need to consider the effect of communication range. V2R communication between RSU and vehicle is affected by RSU’s communication rangeRRSU. At the same time, only when the reliability of data transmission can be guaranteed by one-hop V2V connection the calculation offload can be performed between the two vehicles; otherwise, there may be data loss during the transmission process.(2)
We also assume that time is time-slotted and studies the computing task offloading strategy of moving vehicles in a specific period.(3)
Assuming there is a lack of information in the computing task offloading market, the RSU and buyer cannot know the seller’s bid, and the seller cannot know the bids of other sellers. RSU manages the computing task offloading market through the smart contract COSC of the alliance blockchain. RSU will not favor any buyer or seller, nor can it refuse to help any vehicle that wants to participate in computing task offloading. In addition, due to the characteristics of the consortium blockchain system, various entities cannot collude with each other.(4)
In the process of computing task offloading, one buyer can only uninstall its application to one seller, but one seller can provide services for multiple buyers. At the same time, since the computing task offloading scheme proposed applies to all RCONs, to simplify the discussion, in the follow-up work, we will take an RCON as an example to study computing task offloading.(5)
It is assumed that a computing task can be divided into a computing program with fixed data size. This computing program is the smallest unit of computing task division.


## 2.1. System Entities

Figure1 is the model diagram of the mobile vehicle computing task offloading system based on the alliance blockchain [20–23] designed in this paper. The model mainly includes three classes of entities: trusted Authority (TA), roadside unit (RSU), and mobile vehicles.Figure 1
System model.The details of the functions of each entity in the system are as follows.


### 2.1.1. Trusted Authority (TA)

The function of the TA is the same as that of the TA introduced in Section3.1, both of which deal with the registration and authentication of entities in the system and send a digital certificate, public key, and private key to the entity to ensure the security of entity data transmission.


### 2.1.2. Roadside Unit (RSU)

In the system model, the RSU acts as a vehicle computing task offloading agent responsible for hosting and directing the auction process to handle calculating resource scheduling problems. At the same time, RSU is also the consensus node of the alliance blockchain. A smart contract (Computation Offloading Smart Contract, COSC) that controls the offloading of vehicle computing tasks is deployed on the RSU. A copy of the alliance blockchain is saved on each RSU. There are multiple RSUs beside the road, and the coverage radius is defined as RSUR. Similarly, all RSUs are carried out through communication cables, and mobile vehicles can communicate with RSUs through V2R wireless communication.


### 2.1.3. Mobile Vehicles

Mobile vehicles with compute-intensive applications waiting to be offloaded act as buyers of computing resources. Vehicle users with idle computing resources can be rented to buyers to act as computing resource suppliers, i.e., sellers. Vehicles can communicate with the RSU through V2R, and the vehicles communicate through V2V. The vehicle also has a wallet for storing resource coins and a virtual identity for privacy protection.As shown in the system model diagram in Figure1, the smart contract COSC divides each RSU and the mobile vehicles within its communication range into a network area according to the communication range RRSU of each RSU, and the network area is named regional computation offloading network (RCON). As the regional manager of an RCON, each RSU manages the offloading of vehicle computing tasks in the RCON and acts as a consensus node of the alliance blockchain on the other hand. RSU will package the transaction records into blocks and pass the corresponding consensus mechanism to link the block to the consortium blockchain. In addition, RCONs are connected by cable, and the same is true between RCONsand the edge server cloud, and they can all communicate with each other. Vehicles can offload computing tasks to other vehicles with spare computing resources in the same RCON through RSU scheduling or offload computing tasks to edge cloud servers through RSU. We focus on the case where a vehicle offloads computational tasks to a nearby moving vehicle.


## 2.1.1. Trusted Authority (TA)

The function of the TA is the same as that of the TA introduced in Section3.1, both of which deal with the registration and authentication of entities in the system and send a digital certificate, public key, and private key to the entity to ensure the security of entity data transmission.


## 2.1.2. Roadside Unit (RSU)

In the system model, the RSU acts as a vehicle computing task offloading agent responsible for hosting and directing the auction process to handle calculating resource scheduling problems. At the same time, RSU is also the consensus node of the alliance blockchain. A smart contract (Computation Offloading Smart Contract, COSC) that controls the offloading of vehicle computing tasks is deployed on the RSU. A copy of the alliance blockchain is saved on each RSU. There are multiple RSUs beside the road, and the coverage radius is defined as RSUR. Similarly, all RSUs are carried out through communication cables, and mobile vehicles can communicate with RSUs through V2R wireless communication.


## 2.1.3. Mobile Vehicles

Mobile vehicles with compute-intensive applications waiting to be offloaded act as buyers of computing resources. Vehicle users with idle computing resources can be rented to buyers to act as computing resource suppliers, i.e., sellers. Vehicles can communicate with the RSU through V2R, and the vehicles communicate through V2V. The vehicle also has a wallet for storing resource coins and a virtual identity for privacy protection.As shown in the system model diagram in Figure1, the smart contract COSC divides each RSU and the mobile vehicles within its communication range into a network area according to the communication range RRSU of each RSU, and the network area is named regional computation offloading network (RCON). As the regional manager of an RCON, each RSU manages the offloading of vehicle computing tasks in the RCON and acts as a consensus node of the alliance blockchain on the other hand. RSU will package the transaction records into blocks and pass the corresponding consensus mechanism to link the block to the consortium blockchain. In addition, RCONs are connected by cable, and the same is true between RCONsand the edge server cloud, and they can all communicate with each other. Vehicles can offload computing tasks to other vehicles with spare computing resources in the same RCON through RSU scheduling or offload computing tasks to edge cloud servers through RSU. We focus on the case where a vehicle offloads computational tasks to a nearby moving vehicle.


## 2.2. Basic Assumptions of the Computing Task Offloading Model

The research on computing task offloading [24–26] of mobile vehicles will be based on the following assumptions:(1)
First, consider the communication between model entities. Figure1 shows that wired communication between RCONs and between RCONs and edge cloud servers will be carried out through cables. The communication between them does not need to consider the effect of communication range.The V2R communication between the RSU and the vehicle is affected by the communication range RSUR of the RSU. In contrast, the communication between them does not need to consider the effect of communication range. V2R communication between RSU and vehicle is affected by RSU’s communication rangeRRSU. At the same time, only when the reliability of data transmission can be guaranteed by one-hop V2V connection the calculation offload can be performed between the two vehicles; otherwise, there may be data loss during the transmission process.(2)
We also assume that time is time-slotted and studies the computing task offloading strategy of moving vehicles in a specific period.(3)
Assuming there is a lack of information in the computing task offloading market, the RSU and buyer cannot know the seller’s bid, and the seller cannot know the bids of other sellers. RSU manages the computing task offloading market through the smart contract COSC of the alliance blockchain. RSU will not favor any buyer or seller, nor can it refuse to help any vehicle that wants to participate in computing task offloading. In addition, due to the characteristics of the consortium blockchain system, various entities cannot collude with each other.(4)
In the process of computing task offloading, one buyer can only uninstall its application to one seller, but one seller can provide services for multiple buyers. At the same time, since the computing task offloading scheme proposed applies to all RCONs, to simplify the discussion, in the follow-up work, we will take an RCON as an example to study computing task offloading.(5)
It is assumed that a computing task can be divided into a computing program with fixed data size. This computing program is the smallest unit of computing task division.


## 3. The Specific Process of Computing Task Offloading

The particular process of vehicle computing task offloading is shown as follows.


### 3.1. System Initialization

All entities must be registered with TA and submit a certain amount of resource coins as a deposit to the account under the supervision of TA. Then download the latest data information from the nearby alliance blockchain nodes’ storage pool to synchronize the entity system’s state, which will not be repeated here.


### 3.2. Both Buyers and Sellers Submit Relevant Information to RSU

In RCON, buyers and sellers of vehicles who intend to participate in the offloading of computing tasks will submit relevant information to RSU. The information submitted by the buyer’s vehiclebi can be described by vector Ibi=signiB,di,viB,liB, where signiB marks the vehicle bi as the buyer. That is, it needs external computing resources to unload its intensive computing tasks, di is the data amount of computing tasks that need to be unloaded by vehicle bi, and viB and liB are the current speed and position of vehicle bi; on the other hand, the information vector submitted by the seller’s vehicle sj can be expressed as Isj=signjS,cj,vjS,ljS,pj,rj, where signjS represents that the vehicle sj is the seller. That is, the vehicle sj has redundant computing resources and is willing to provide computing task offloading services for other vehicles, cj is the computing power of the vehicle sj, described by the number of CPU cycles per second of the vehicle, vjS and ljS are the current speed and position of the vehicle sj, and pj is the bid of the vehicle sj to process the application data of one computing task. rj represents the idle computing resources of vehicle sj virtualized as resource blocks (CPU cycles).In addition, it should be noted that all buyers and sellers participating in the offloading of computing tasks are within the communication rangeRRSU of RSU. Therefore, their information can be sent to RSU through V2R. At the same time, it is assumed that the RCON contains n buyers B=b1,b2,…,bn and m sellers S=s1,S2,…,sm; these vehicles have the same communication range RV.


### 3.3. RSU Calculates the Scheduling Results and Publishes the Results to Both Buyers and Sellers

After receiving the relevant information about the buyer’s vehicle and the seller’s vehicle, the RSU will extract and integrate the information, and then according to the reverse auction mechanism proposed in this chapter, the RSU will match buyers and sellers and send the best match results back to buyers and sellers.


### 3.4. Unloading and Payment of Computing Tasks

After receiving the scheduling result of RSU, the buyer’s vehicle will directly unload the computing task to the seller’s vehicle through one-hop V2V. After the seller’s vehicle completes the calculation, it will return the calculation result to the buyer. Since the data size of the application result is much smaller than the input data, the result feedback delay can be further ignored.After the buyer confirms the receipt of the calculation result, the buyer will forward a resource currency to the corresponding seller’s vehicle through its wallet as the cost of unloading the calculation task. At the same time, the buyer sends a transaction completion message to the RSU. When the seller receives the fee, a transaction completion message will also be sent to RSU, which represents that the transaction has been completed. The transaction record will be placed in the RSU memory pool and broadcast to the entire network, waiting to be added to the block.If there is any objection between the buyer and the seller during the transaction, for example, the buyer has not received the calculation result, the seller has not received the corresponding fee, etc., the objecting party can file a complaint with RSU, and RSU initiates verification of data transmission and wallet payment in the inspection network. For vehicles with cheating, RSU will deduct a part of the security deposit for the vehicle. This mechanism can restrain some vehicles from doing damage to the interests of other vehicles for their own interests during the unloading process of computing tasks and ensure the stability of the system operation.


### 3.5. Blocks Are Generated and Linked to the Blockchain

When generating the blockchain, this chapter proposes a new consensus mechanism based on the total amount of buyer computing task data received by all sellers in the RCON managed by each RSU node to elect the accounting node (Proof of Computation Resource, POCR). The RSU with the most significant amount of buyer computing tasks received by all sellers in the RCON area is elected as the accounting node within a block generation interval.It should be noted that when an RSU successfully obtains the accounting right and generates a block link to the blockchain, the system will also distribute a certain amount of resource coins to it as a reward. RSU will distribute resource coins proportionally to the seller as a reward according to the contribution of the seller’s vehicle’s computing resources in the process of computing task offloading to encourage them to continue to participate in computing tasks offloading. That is, the POCR consensus mechanism uses the total amount of buyer computing task data received by the seller to measure the seller’s computing resource contribution.


## 3.1. System Initialization

All entities must be registered with TA and submit a certain amount of resource coins as a deposit to the account under the supervision of TA. Then download the latest data information from the nearby alliance blockchain nodes’ storage pool to synchronize the entity system’s state, which will not be repeated here.


## 3.2. Both Buyers and Sellers Submit Relevant Information to RSU

In RCON, buyers and sellers of vehicles who intend to participate in the offloading of computing tasks will submit relevant information to RSU. The information submitted by the buyer’s vehiclebi can be described by vector Ibi=signiB,di,viB,liB, where signiB marks the vehicle bi as the buyer. That is, it needs external computing resources to unload its intensive computing tasks, di is the data amount of computing tasks that need to be unloaded by vehicle bi, and viB and liB are the current speed and position of vehicle bi; on the other hand, the information vector submitted by the seller’s vehicle sj can be expressed as Isj=signjS,cj,vjS,ljS,pj,rj, where signjS represents that the vehicle sj is the seller. That is, the vehicle sj has redundant computing resources and is willing to provide computing task offloading services for other vehicles, cj is the computing power of the vehicle sj, described by the number of CPU cycles per second of the vehicle, vjS and ljS are the current speed and position of the vehicle sj, and pj is the bid of the vehicle sj to process the application data of one computing task. rj represents the idle computing resources of vehicle sj virtualized as resource blocks (CPU cycles).In addition, it should be noted that all buyers and sellers participating in the offloading of computing tasks are within the communication rangeRRSU of RSU. Therefore, their information can be sent to RSU through V2R. At the same time, it is assumed that the RCON contains n buyers B=b1,b2,…,bn and m sellers S=s1,S2,…,sm; these vehicles have the same communication range RV.


## 3.3. RSU Calculates the Scheduling Results and Publishes the Results to Both Buyers and Sellers

After receiving the relevant information about the buyer’s vehicle and the seller’s vehicle, the RSU will extract and integrate the information, and then according to the reverse auction mechanism proposed in this chapter, the RSU will match buyers and sellers and send the best match results back to buyers and sellers.


## 3.4. Unloading and Payment of Computing Tasks

After receiving the scheduling result of RSU, the buyer’s vehicle will directly unload the computing task to the seller’s vehicle through one-hop V2V. After the seller’s vehicle completes the calculation, it will return the calculation result to the buyer. Since the data size of the application result is much smaller than the input data, the result feedback delay can be further ignored.After the buyer confirms the receipt of the calculation result, the buyer will forward a resource currency to the corresponding seller’s vehicle through its wallet as the cost of unloading the calculation task. At the same time, the buyer sends a transaction completion message to the RSU. When the seller receives the fee, a transaction completion message will also be sent to RSU, which represents that the transaction has been completed. The transaction record will be placed in the RSU memory pool and broadcast to the entire network, waiting to be added to the block.If there is any objection between the buyer and the seller during the transaction, for example, the buyer has not received the calculation result, the seller has not received the corresponding fee, etc., the objecting party can file a complaint with RSU, and RSU initiates verification of data transmission and wallet payment in the inspection network. For vehicles with cheating, RSU will deduct a part of the security deposit for the vehicle. This mechanism can restrain some vehicles from doing damage to the interests of other vehicles for their own interests during the unloading process of computing tasks and ensure the stability of the system operation.


## 3.5. Blocks Are Generated and Linked to the Blockchain

When generating the blockchain, this chapter proposes a new consensus mechanism based on the total amount of buyer computing task data received by all sellers in the RCON managed by each RSU node to elect the accounting node (Proof of Computation Resource, POCR). The RSU with the most significant amount of buyer computing tasks received by all sellers in the RCON area is elected as the accounting node within a block generation interval.It should be noted that when an RSU successfully obtains the accounting right and generates a block link to the blockchain, the system will also distribute a certain amount of resource coins to it as a reward. RSU will distribute resource coins proportionally to the seller as a reward according to the contribution of the seller’s vehicle’s computing resources in the process of computing task offloading to encourage them to continue to participate in computing tasks offloading. That is, the POCR consensus mechanism uses the total amount of buyer computing task data received by the seller to measure the seller’s computing resource contribution.


## 4. Modeling and Solution

### 4.1. Modeling of the Reverse Auction Scheme

Consider a computing task offloading scenario in an RCON. Since there are multiple buyers and sellers in the RCON, buyers will compete for the seller's computing resources to complete computing tasks faster. Therefore, this chapter will use the reverse auction method to match buyers and sellers to obtain the matching result that maximizes regional benefits. The actual meaning of the important parameters involved in the auction scheme is shown in Table1.Table 1
Parameter correspondence table.
ParameterDefinitiondijThe amount of task data unloaded by buyerbi to seller sjϕijThe benefit that buyerbi can get by offloading unit calculation data to seller sjTijData transfer speed between buyerbi and seller sjλiExpected benefit for reconciling buyerbi offloading unit dataηijUsed to calibrate whether buyerbi can offload computing tasks to seller sjγjRepresents the idle computing resources of sellersj virtualized into resource blocks (CPU cycles)δA bit to CPU cycle mappingTECData transfer rate between vehicle and edge serverθRCS response delay due to network congestion or insufficient ECS performanceUηijOverall regional benefits that RCON can achieveCj, CECThe computing power of sellersj and edge serverPj, PECBidding by sellersj and edge server for unit offload taskLRSU, LbiList of preferred options between RSU and buyerbiConsider first the benefits of offloading the buyer’s computing tasks. Since each seller’s computing power is different, the utility benefits provided by each seller to the buyer are different. The benefit that the buyerbi can get by offloading the unit calculation data to the seller sj can be expressed by the following function:(1)φij=δcEC+1TEC+θ−δcj+1Tij.In formula (1), δ/cEC+1/TEC+θ represents the time for the buyer ib to offload the unit computing task to the edge cloud server ECS, δ is the mapping of bits to CPU cycles, CEC is the computing power of the edge cloud server, TEC is the data transfer rate between the vehicle and the ECS, θ is the response delay due to network congestion or insufficient ECS performance, δ/cj+1/Tij represents the time for the buyer bi to offload the unit computing task to the seller sj, and Tij represents the data transmission speed between the buyer bi and the seller sj.To sum up, the time saved by the buyerbi offloading the unit computing task data to the seller sj compared to the time saved by the buyer bi offloading the unit computing task to the edge cloud server is the unit benefit of the buyer bi.Next, consider the overall benefit of RCON. Forn buyers set B=b1,b2,…,bn and m seller set S=S1,S2,…,Sm in RCON, the buyer’s demand vector is D=d1,d2,…,dn, and the seller’s bidding vector for unit resources is P=p1,p2,…,pm. Use Rbi to denote a seller within the coverage of the buyer’s bi communication. Use Rsj to represent buyers who are within the seller’s sj communication coverage. Then, in a time slot, through the calculation and offloading of buyers and sellers, the overall regional benefit that RCON can obtain can be expressed as(2)Uηij=∑j=1m∑i=1nλiφijdijηij−∑j=1m∑i=1npjdijηij=∑j=1m∑i=1nλiφij−pjdijηijs.t.ηij∈0,1∑j=1mηij∈0,1δ∑i=1ndijηij≤rj,dij=mindij,ΔtijTij.Here,ηij is used to the nature of the task of calibrating the buyer bi to the winning seller sj. When ηij=1, the buyer bi can unload its application data to the seller sj through a one-hop V2V communication; otherwise, it cannot be uninstalled. For example, when the seller sj is not within the communication coverage of the buyer bi, or the seller sj has exhausted its idle computing resources, the situation of ηij=0 will occur. dij represents the amount of task data unloaded by the buyer bi to the seller sj. λi is used to adjust the expected revenue of the buyer bi unloading unit data. When the importance of the calculation task or the timeliness requirement is high, the value of λi is larger; this represents that the buyers are willing to pay a higher price to complete the current computing task faster.Here, the limited value of constraintηij∈0,1 can only be 0 or 1; that is, the unloading of computing tasks from buyer bi to seller js has only two states of success and failure; ∑j=1mηij∈0,1 represents that a buyer can only offload tasks to one seller; δ∑i=1ndijηij≤rj is used to prevent the total workload offloaded from the buyer from exceeding the computing resources that the seller can provide; dij=mindij,ΔtijTij determines the actual uninstall data from buyer bi to seller sj based on the smaller value between the two data, where Δtij represents the real transmission time of the buyer bi offloading the computing task to the seller sj.


### 4.2. Reverse Auction Solution Schemes

We will use the reverse auction method to solve the proposed computing task offloading problem and, at the same time, prove the authenticity of the seller’s bid and the individual’s rationality to verify the proposed scheme’s rationality.First, define a list of preferred options from the perspective of the administrator RSU and the buyer, respectively. For the auction manager RSU in RCON, according to the size of the value of formula (3), a list of its preference schemes is defined, and the list can be expressed by formula (4):(3)λiφij−pjdij,bi∈B,sj∈S,(4)LRSU=bi,sj>RSUbi,Rbi∖sj|bi∈B,sj∈S,where >RSU in formula (4) means that RSU is biased to match the buyer bi with the seller sj, rather than matching the buyer bi with other sellers within its communication range; because scheme (bi, sj) can bring more benefits to RSU than other schemes, it maximizes the regional benefit of RCON.Next, define a list of preferred options from the buyer’s perspective. Also, according to the value of formula (3), the list of buyer’s preference schemes defined here is(5)Lbi=sj>bisk|sj,Sk∈Rbi,where >bi in formula (5) means that the buyer bi prefers to match the seller sj rather than other sellers within its communication range, because the scheme (bi, sj) can make the buyer bi obtain the maximum benefit.In the following, the listsLRSU and Lbi are sorted in descending order according to the value of formula (3). At the same time, a virtual seller sj′ is added at the end of the list Lbi as a critical indicator for the following algorithm to use. The virtual seller sj′ corresponds to the scheme of offloading computing tasks to ECS. The buyer bi unloads the unit computing task revenue set to ωi=λiφij−pECdij, where PEC refers to the unit computing resources ECS price. Here, we consider that all sellers’ vehicle bids are lower than PEC, so sellers can attract buyers to offload computing tasks. The value of ωi is smaller than λiφij−pjdij for all real solutions in the list Lbi. If no seller in the listing Lbi wins the auction, the buyer bi offloads its computation to ECS. On the other hand, when λiφij−pjdij≤0, it means that the buyer bi cannot benefit from the offloading of computing tasks. At this time, ηij=0, the buyer bi will not offload computing tasks to the seller sj.The reverse auction scheme proposed here consists of two parts, first, to determine the matching scheme of all buyers and sellers and, then, to determine the actual amount that the buyer should pay to the seller. In the matching process, the listLRSU plays a leading role; that is, the scheme will prioritize the matching scheme that can maximize the regional benefit in the actual operation process, although this may sacrifice the interests of some buyers.The auction algorithm is divided into three parts. The first is to set the algorithm’s parameters, create listsLRSU and Lbi, and sort the two lists in descending order according to the size of the λiφij−pECdij value. This is followed by the matching phase, where buyers are matched with suitable sellers in the case of maximizing regional interest, based on listing LRSU, until all buyers are matched, or sellers run out of free resources.The last is the payment stage. For the matching scheme (bi, sj), after determining the actual payment amount psj that the buyer bi should pay to the seller sj, the next seller s^j of sj in the list Lbi is selected as the critical reference payment indicator. At this time, the payment amount psj can be expressed as(6)psjfinal=∑bi∈Rsjλiφij−λiφ^ij−p^jd^ijdijηijdij.When the sellers^j is the last seller on the list Lbi, the seller s^j is the virtual seller sj′ at this time; we make λiφ^ij−p^jd^ij=ωi=λiφij−pECdij.This scheme includesn buyers and m sellers. So, the computational complexity of auction is On2m2. The complexity of the algorithm is low, and the convergence can be achieved in a short time even when the scale of the vehicle network is large.


### 4.3. Consortium Blockchain Reward Modeling

In generating the consortium blockchain, the RSU as the consensus node will compete for the accounting right through the POCR consensus mechanism proposed above. The RSU that has obtained the accounting right can not only package the transaction records into blocks and link them to the blockchain but also be rewarded with resource coins distributed by the blockchain system. After RSU is rewarded with resource coins, it will distribute resource coins to sellers according to the ratio of the total amount of computing task data unloaded by buyers within a block generation interval to the total amount received by all sellers in RSU. Here, the total amount of buyer computing task data received by the seller is used to measure the computing resource contribution of the seller.The generation of new blocks in the POCR consensus mechanism includes three stages: mining, consensus, and distribution of rewards. In this chapter, “mining” refers to how sellers provide computing resources to buyers for buyers to offload computing tasks. After the “mining” process, the system counts the buyers received by all sellers in the RCON area managed by each RSU. The total amount of unloaded computing task data and the RSU with the largest total amount are elected as the accounting node.The next step is to enter the “consensus” stage. At this time, the accounting node packages part of the computing task by offloading records into a block and sending them to other RSU nodes for verification. After the verification is passed, the accounting node links the block to the blockchain. Next, in the “Distribute Rewards” stage, the system will distribute a certain amount of resource coins to the accounting node RSU as a reward. After RSU receives the resource currency distributed by the system, it will distribute resource currency rewards to each seller according to the number of computing resources contributed by each seller in RCON under its control to encourage sellers to continue to participate in computing resource scheduling.The actual meanings of the important parameters are shown in Table2.Table 2
The actual meanings of the important parameters.
ParameterDefinitionτkpThe propagation delay of RSU numberedkτkvThe verification time of the block of RSU numberedkϵkThe number of things in a blockγParameters related to network sizeμAverage effective channel capacity per linkkParameters determined by network size and node verification speedfkRSUThe probability that the RSU numberedk successfully obtains the accounting rightPo (ϵk)The probability that a block generated by RSU numberk will be orphanedPkRSU (ϵk)The probability that the RSU numberedk is successfully elected as the accounting node and generates a blockUkRSUThe benefit function of the reward for the RSU numberedkUjvehicleThe reward function that sellerj should getThe blockchain “distribute rewards” phase is modeled below. Assuming that there arez RCON areas in the current system, there are z consensus nodes RSU, the number of sellers’ vehicles in the RSU numbered k, k∈1,z, is mk, the seller numbered j, j∈1,mk, in the RCON corresponding to this RSU at the amount of buyer calculation task data received in the current block generation time slot is dj. The probability that the RSU number k successfully obtains the accounting right is(7)fkRSU=∑j=1mkdj∑k=1z∑j=1mkdj,and there is ∑k=1zfkRSU=1 here; that is, the sum of the probabilities of all RSUs being successfully elected as accounting nodes is 1. After RSU obtains the accounting rights and generates a block, it will immediately propagate the block on the network for verification to complete the consensus process. If the propagation and verification time is too long, the mined block becomes an orphan block and is abandoned by the blockchain. Here, the propagation delay of RSU number k as a “miner” is set to τkP=εk/γ⋅μ, where ϵk is the number of transactions in a block, γ is a parameter related to network size, and μ is the average effective channel capacity per link. Since the verification of transactions requires a fixed amount of computation, this period is assumed to be linear with the number of transactions in the block; then this period can be expressed as τkv=κ∗εk, where κ is a parameter determined by the size of the network and the average verification speed of nodes. Considering that the generation of new blocks follows a Poisson process, the probability that a block generated by a “miner” RSUk is orphaned is approximate as(8)Poεk=1−e−λεk/γμ+κεk.In the formula, the process parameterλ represents the complexity of the mining block. The probability that the “miner” RSUk is successfully elected as a bookkeeping node and generates a block is(9)PkRSUεk=fkRSU×1−Poεk.Assuming that the remuneration (reward rate) per unit transaction in the alliance blockchain system isr resource coins, the reward obtained by generating a block with a transaction volume of εk is rεk. Then the benefit function of the reward obtained by the “miner” RSUk can be expressed as(10)UkRSU=rεk×PkRSUεk=rεk×fkRSU×1−Poεk=rεk×∑j=1mkdj∑k=1z∑j=1mkdj×e−λεk/γμ+κεk.For the resource currency reward obtained by the “miner”RSUk, the resource currency reward will be distributed to each seller according to the number of computing resources contributed by each seller in the RCON controlled by the RSU; then the seller j accepts the computing task unloading amount dj. Then the reward function that seller j should get is expressed as(11)Ujvehicle=dj∑j=1mkdj×UkRSU=rεk×e−λεk/γμ+κεk×dj∑j=1mkdj×∑j=1mkdj∑k=1z∑j=1mkdk.At this point, the blockchain reward model is established. In the next section, we will analyze the system’s performance through simulation.


## 4.1. Modeling of the Reverse Auction Scheme

Consider a computing task offloading scenario in an RCON. Since there are multiple buyers and sellers in the RCON, buyers will compete for the seller's computing resources to complete computing tasks faster. Therefore, this chapter will use the reverse auction method to match buyers and sellers to obtain the matching result that maximizes regional benefits. The actual meaning of the important parameters involved in the auction scheme is shown in Table1.Table 1
Parameter correspondence table.
ParameterDefinitiondijThe amount of task data unloaded by buyerbi to seller sjϕijThe benefit that buyerbi can get by offloading unit calculation data to seller sjTijData transfer speed between buyerbi and seller sjλiExpected benefit for reconciling buyerbi offloading unit dataηijUsed to calibrate whether buyerbi can offload computing tasks to seller sjγjRepresents the idle computing resources of sellersj virtualized into resource blocks (CPU cycles)δA bit to CPU cycle mappingTECData transfer rate between vehicle and edge serverθRCS response delay due to network congestion or insufficient ECS performanceUηijOverall regional benefits that RCON can achieveCj, CECThe computing power of sellersj and edge serverPj, PECBidding by sellersj and edge server for unit offload taskLRSU, LbiList of preferred options between RSU and buyerbiConsider first the benefits of offloading the buyer’s computing tasks. Since each seller’s computing power is different, the utility benefits provided by each seller to the buyer are different. The benefit that the buyerbi can get by offloading the unit calculation data to the seller sj can be expressed by the following function:(1)φij=δcEC+1TEC+θ−δcj+1Tij.In formula (1), δ/cEC+1/TEC+θ represents the time for the buyer ib to offload the unit computing task to the edge cloud server ECS, δ is the mapping of bits to CPU cycles, CEC is the computing power of the edge cloud server, TEC is the data transfer rate between the vehicle and the ECS, θ is the response delay due to network congestion or insufficient ECS performance, δ/cj+1/Tij represents the time for the buyer bi to offload the unit computing task to the seller sj, and Tij represents the data transmission speed between the buyer bi and the seller sj.To sum up, the time saved by the buyerbi offloading the unit computing task data to the seller sj compared to the time saved by the buyer bi offloading the unit computing task to the edge cloud server is the unit benefit of the buyer bi.Next, consider the overall benefit of RCON. Forn buyers set B=b1,b2,…,bn and m seller set S=S1,S2,…,Sm in RCON, the buyer’s demand vector is D=d1,d2,…,dn, and the seller’s bidding vector for unit resources is P=p1,p2,…,pm. Use Rbi to denote a seller within the coverage of the buyer’s bi communication. Use Rsj to represent buyers who are within the seller’s sj communication coverage. Then, in a time slot, through the calculation and offloading of buyers and sellers, the overall regional benefit that RCON can obtain can be expressed as(2)Uηij=∑j=1m∑i=1nλiφijdijηij−∑j=1m∑i=1npjdijηij=∑j=1m∑i=1nλiφij−pjdijηijs.t.ηij∈0,1∑j=1mηij∈0,1δ∑i=1ndijηij≤rj,dij=mindij,ΔtijTij.Here,ηij is used to the nature of the task of calibrating the buyer bi to the winning seller sj. When ηij=1, the buyer bi can unload its application data to the seller sj through a one-hop V2V communication; otherwise, it cannot be uninstalled. For example, when the seller sj is not within the communication coverage of the buyer bi, or the seller sj has exhausted its idle computing resources, the situation of ηij=0 will occur. dij represents the amount of task data unloaded by the buyer bi to the seller sj. λi is used to adjust the expected revenue of the buyer bi unloading unit data. When the importance of the calculation task or the timeliness requirement is high, the value of λi is larger; this represents that the buyers are willing to pay a higher price to complete the current computing task faster.Here, the limited value of constraintηij∈0,1 can only be 0 or 1; that is, the unloading of computing tasks from buyer bi to seller js has only two states of success and failure; ∑j=1mηij∈0,1 represents that a buyer can only offload tasks to one seller; δ∑i=1ndijηij≤rj is used to prevent the total workload offloaded from the buyer from exceeding the computing resources that the seller can provide; dij=mindij,ΔtijTij determines the actual uninstall data from buyer bi to seller sj based on the smaller value between the two data, where Δtij represents the real transmission time of the buyer bi offloading the computing task to the seller sj.


## 4.2. Reverse Auction Solution Schemes

We will use the reverse auction method to solve the proposed computing task offloading problem and, at the same time, prove the authenticity of the seller’s bid and the individual’s rationality to verify the proposed scheme’s rationality.First, define a list of preferred options from the perspective of the administrator RSU and the buyer, respectively. For the auction manager RSU in RCON, according to the size of the value of formula (3), a list of its preference schemes is defined, and the list can be expressed by formula (4):(3)λiφij−pjdij,bi∈B,sj∈S,(4)LRSU=bi,sj>RSUbi,Rbi∖sj|bi∈B,sj∈S,where >RSU in formula (4) means that RSU is biased to match the buyer bi with the seller sj, rather than matching the buyer bi with other sellers within its communication range; because scheme (bi, sj) can bring more benefits to RSU than other schemes, it maximizes the regional benefit of RCON.Next, define a list of preferred options from the buyer’s perspective. Also, according to the value of formula (3), the list of buyer’s preference schemes defined here is(5)Lbi=sj>bisk|sj,Sk∈Rbi,where >bi in formula (5) means that the buyer bi prefers to match the seller sj rather than other sellers within its communication range, because the scheme (bi, sj) can make the buyer bi obtain the maximum benefit.In the following, the listsLRSU and Lbi are sorted in descending order according to the value of formula (3). At the same time, a virtual seller sj′ is added at the end of the list Lbi as a critical indicator for the following algorithm to use. The virtual seller sj′ corresponds to the scheme of offloading computing tasks to ECS. The buyer bi unloads the unit computing task revenue set to ωi=λiφij−pECdij, where PEC refers to the unit computing resources ECS price. Here, we consider that all sellers’ vehicle bids are lower than PEC, so sellers can attract buyers to offload computing tasks. The value of ωi is smaller than λiφij−pjdij for all real solutions in the list Lbi. If no seller in the listing Lbi wins the auction, the buyer bi offloads its computation to ECS. On the other hand, when λiφij−pjdij≤0, it means that the buyer bi cannot benefit from the offloading of computing tasks. At this time, ηij=0, the buyer bi will not offload computing tasks to the seller sj.The reverse auction scheme proposed here consists of two parts, first, to determine the matching scheme of all buyers and sellers and, then, to determine the actual amount that the buyer should pay to the seller. In the matching process, the listLRSU plays a leading role; that is, the scheme will prioritize the matching scheme that can maximize the regional benefit in the actual operation process, although this may sacrifice the interests of some buyers.The auction algorithm is divided into three parts. The first is to set the algorithm’s parameters, create listsLRSU and Lbi, and sort the two lists in descending order according to the size of the λiφij−pECdij value. This is followed by the matching phase, where buyers are matched with suitable sellers in the case of maximizing regional interest, based on listing LRSU, until all buyers are matched, or sellers run out of free resources.The last is the payment stage. For the matching scheme (bi, sj), after determining the actual payment amount psj that the buyer bi should pay to the seller sj, the next seller s^j of sj in the list Lbi is selected as the critical reference payment indicator. At this time, the payment amount psj can be expressed as(6)psjfinal=∑bi∈Rsjλiφij−λiφ^ij−p^jd^ijdijηijdij.When the sellers^j is the last seller on the list Lbi, the seller s^j is the virtual seller sj′ at this time; we make λiφ^ij−p^jd^ij=ωi=λiφij−pECdij.This scheme includesn buyers and m sellers. So, the computational complexity of auction is On2m2. The complexity of the algorithm is low, and the convergence can be achieved in a short time even when the scale of the vehicle network is large.


## 4.3. Consortium Blockchain Reward Modeling

In generating the consortium blockchain, the RSU as the consensus node will compete for the accounting right through the POCR consensus mechanism proposed above. The RSU that has obtained the accounting right can not only package the transaction records into blocks and link them to the blockchain but also be rewarded with resource coins distributed by the blockchain system. After RSU is rewarded with resource coins, it will distribute resource coins to sellers according to the ratio of the total amount of computing task data unloaded by buyers within a block generation interval to the total amount received by all sellers in RSU. Here, the total amount of buyer computing task data received by the seller is used to measure the computing resource contribution of the seller.The generation of new blocks in the POCR consensus mechanism includes three stages: mining, consensus, and distribution of rewards. In this chapter, “mining” refers to how sellers provide computing resources to buyers for buyers to offload computing tasks. After the “mining” process, the system counts the buyers received by all sellers in the RCON area managed by each RSU. The total amount of unloaded computing task data and the RSU with the largest total amount are elected as the accounting node.The next step is to enter the “consensus” stage. At this time, the accounting node packages part of the computing task by offloading records into a block and sending them to other RSU nodes for verification. After the verification is passed, the accounting node links the block to the blockchain. Next, in the “Distribute Rewards” stage, the system will distribute a certain amount of resource coins to the accounting node RSU as a reward. After RSU receives the resource currency distributed by the system, it will distribute resource currency rewards to each seller according to the number of computing resources contributed by each seller in RCON under its control to encourage sellers to continue to participate in computing resource scheduling.The actual meanings of the important parameters are shown in Table2.Table 2
The actual meanings of the important parameters.
ParameterDefinitionτkpThe propagation delay of RSU numberedkτkvThe verification time of the block of RSU numberedkϵkThe number of things in a blockγParameters related to network sizeμAverage effective channel capacity per linkkParameters determined by network size and node verification speedfkRSUThe probability that the RSU numberedk successfully obtains the accounting rightPo (ϵk)The probability that a block generated by RSU numberk will be orphanedPkRSU (ϵk)The probability that the RSU numberedk is successfully elected as the accounting node and generates a blockUkRSUThe benefit function of the reward for the RSU numberedkUjvehicleThe reward function that sellerj should getThe blockchain “distribute rewards” phase is modeled below. Assuming that there arez RCON areas in the current system, there are z consensus nodes RSU, the number of sellers’ vehicles in the RSU numbered k, k∈1,z, is mk, the seller numbered j, j∈1,mk, in the RCON corresponding to this RSU at the amount of buyer calculation task data received in the current block generation time slot is dj. The probability that the RSU number k successfully obtains the accounting right is(7)fkRSU=∑j=1mkdj∑k=1z∑j=1mkdj,and there is ∑k=1zfkRSU=1 here; that is, the sum of the probabilities of all RSUs being successfully elected as accounting nodes is 1. After RSU obtains the accounting rights and generates a block, it will immediately propagate the block on the network for verification to complete the consensus process. If the propagation and verification time is too long, the mined block becomes an orphan block and is abandoned by the blockchain. Here, the propagation delay of RSU number k as a “miner” is set to τkP=εk/γ⋅μ, where ϵk is the number of transactions in a block, γ is a parameter related to network size, and μ is the average effective channel capacity per link. Since the verification of transactions requires a fixed amount of computation, this period is assumed to be linear with the number of transactions in the block; then this period can be expressed as τkv=κ∗εk, where κ is a parameter determined by the size of the network and the average verification speed of nodes. Considering that the generation of new blocks follows a Poisson process, the probability that a block generated by a “miner” RSUk is orphaned is approximate as(8)Poεk=1−e−λεk/γμ+κεk.In the formula, the process parameterλ represents the complexity of the mining block. The probability that the “miner” RSUk is successfully elected as a bookkeeping node and generates a block is(9)PkRSUεk=fkRSU×1−Poεk.Assuming that the remuneration (reward rate) per unit transaction in the alliance blockchain system isr resource coins, the reward obtained by generating a block with a transaction volume of εk is rεk. Then the benefit function of the reward obtained by the “miner” RSUk can be expressed as(10)UkRSU=rεk×PkRSUεk=rεk×fkRSU×1−Poεk=rεk×∑j=1mkdj∑k=1z∑j=1mkdj×e−λεk/γμ+κεk.For the resource currency reward obtained by the “miner”RSUk, the resource currency reward will be distributed to each seller according to the number of computing resources contributed by each seller in the RCON controlled by the RSU; then the seller j accepts the computing task unloading amount dj. Then the reward function that seller j should get is expressed as(11)Ujvehicle=dj∑j=1mkdj×UkRSU=rεk×e−λεk/γμ+κεk×dj∑j=1mkdj×∑j=1mkdj∑k=1z∑j=1mkdk.At this point, the blockchain reward model is established. In the next section, we will analyze the system’s performance through simulation.


## 5. Case Study

Here we will evaluate the performance of the proposed Internet of vehicles resource scheduling based on blockchain and game theory through simulation. First, we compare the proposed auction scheme with several types of baseline schemes to verify the scheme’s performance. Second, we conduct a simulation evaluation of the blockchain reward model to verify its effectiveness.


### 5.1. Simulation Setting

Since the calculation task offloading scheme using the reverse auction method applies to all RCONs, to simplify the discussion, we will first use an RCON as an example to conduct a simulation study on the reverse auction scheme. We use MATLAB2016A as the platform to simulate RCON with a network area of 500 m∗500 m, in which there are 5 roads in the east-west and north-south directions, and each road has 4 lanes. In RCON, an RSU is set up as the central broker, hosting and directing the auction process. On the other hand, this chapter also uses the blockchain open-source framework Hyperledger Fabric to write smart contracts to simulate the consortium blockchain system.To evaluate the performance of the reverse auction scheme, the mobile vehicle computation offloading scheme based on consortium clockchain (scheme 0) is compared with the following baseline schemes to evaluate the performance of scheme 0:(1)
The fastest process scheme (scheme 1): in this scheme, assuming all sellers bid reasonably, buyers are always matched with the seller who can complete the application and calculate the offload fastest. If this seller runs out of idle resources, the buyer will be forced to find another seller for fast processing or offload computing tasks to edge cloud servers.(2)
The lowest cost scheme (scheme 2): in this scheme, assuming that all sellers bid reasonably, buyers are always matched with the seller with the lowest asking price per unit calculation task. Similarly, when sellers run out of idle resources, buyers will be forced to find another low-priced seller or offload computing tasks to edge cloud servers.(3)
First-come-first-served service (scheme 3): in this scheme, assuming that all sellers make reasonable bids, the buyer is always matched with the first seller to provide an offer. If this seller runs out of idle resources, the buyer will be forced to offload computing tasks to the edge cloud. Since the vehicles are randomly distributed in the simulation area, FCFS can be regarded as a random unloading scheme.(4)
Offload to edge cloud scheme (scheme 4): buyers directly offload their computing tasks to edge cloud servers for processing.In addition, for the proposed scheme, the functionσj=acj+e is used here to represent the most reasonable bid of the buyer sj, where a and e are positive constants, and these two constants follow the unloading law of the market economy, which means that the buyer sj provides that the more the computing power, the greater the reasonable bid. The settings of the relevant simulation parameters are shown in Table 3.Table 3
Simulation parameter settings.
ParameterValuecj1∗109−3∗1010bit/scEC1∗1011−7∗1011bit/sri1.5∗1011−3∗1011CPU cyclea3∗10−19e1∗10−8δ1.8∗104Tij5–8 (MB/s)TEC5–6 (MB/s)λi0.7−0.9dij4−10MBLane-width4 mθ0.5−1sViB,VjS30−50km/hliB,ljSRandom distributionRRSU1200 mRV500 m


### 5.2. Simulation Analysis

#### 5.2.1. Vehicle Density Analysis

We first analyze the impact of vehicle density within the RCON region on the overall benefitUηij of the region and on the average computing time of a single computing program (assuming that the computing task can be divided into computing programs with a fixed data size).In the case of low and high vehicle flow levels, we simulated the scheme 50 times with different parameter values. We obtained the average value to cover various traffic conditions, making the conclusion more general.Figures2–5 show the changes of the average calculation time of a single calculation program and the regional overall benefit Uηij with the number of sellers under low vehicle density (18 buyers and 22 buyers).Figure 2
Change of average calculation time of a single calculation program with the number of sellers (18 buyers).Figure 3
Change of average calculation time of a single calculation program with the number of sellers (22 buyers).Figure 4
Change of average value of regional overall benefit with the number of sellers (18 buyers).Figure 5
Change of average value of regional overall benefit with the number of sellers (22 buyers).According to Figure2 of Figure 3, we find that the average computing time of a single computing program in scheme 4 is always the highest. This is because when it is offloaded to the edge cloud, the edge cloud receives too many requests, resulting in that it cannot process the task of vehicle unloading in time, which causes a large delay in unloading. The calculation time of a single calculation program of scheme 2 and scheme 3 gradually decreases with the increase of sellers because the buyer has more options at this time, and the buyer’s task can be uninstalled faster. But these two schemes are still less efficient than scheme 0 and scheme 1. For scheme 0 and scheme 1 solutions, with the increase in the number of sellers, the computing resources are gradually sufficient, and the completion time of the unit calculation program gradually decreases. The performance of scheme 0 is close to scheme 1 of the fastest processing scheme, which reflects the superiority of the time performance of scheme 0.According to Figures4 and 5, it is found that, with the increase of the number of sellers, the overall regional benefit Uηij of all schemes increases because with the rise in the number of sellers, more buyers can enjoy the calculation service and eventually reach relative stability where most buyers can be successfully matched to the right seller. At the same time, we found that, under low vehicle density, the Uηij value of scheme 0 is higher than other schemes, the buyer’s cost of scheme 1 is higher, and scheme 2 time cost is higher. However, the randomness of scheme 3 is high, and the performance level of these schemes is not high, which shows that scheme 0 can reasonably match buyers and sellers and maximize the regional benefits of RCON.Figures6–9 show the changes of the average calculation time of a single calculation program and the regional overall benefit Uηij with the number of sellers under higher vehicle density (38 buyers and 42 buyers).Figure 6
Change of average calculation time of a single calculation program with the number of sellers (38 buyers).Figure 7
Change of average calculation time of a single calculation program with the number of sellers (42 buyers).Figure 8
Change of average value of regional overall benefit with the number of sellers (38 buyers).Figure 9
Change of average value of regional overall benefit with the number of sellers (42 buyers).It can be seen from Figures6 and 7 that the average calculation time of a single calculation program of scheme 4 is always the highest for the same reason as in the low flow case. For scheme 3 and scheme 2, the curve decreases slightly as more buyers access computing services as sellers increase. Likewise, the performance of scheme 0 is close to the time-optimal scheme 1, which verifies the superiority of the temporal performance of scheme 0. At the same time, the average calculation time of a single calculation program for scheme 0, scheme 3, scheme 2, and scheme 1 decreased compared to the low-traffic case; as buyers had more offloading options at higher vehicle densities, the processing time of its task will be shortened.Figures8 and 9 compare the Uηij values under each scheme. Considering various factors, the efficiency of scheme 0 maintains the highest level among multiple schemes. At the same time, compared with low-traffic scenarios, due to the increase in the number of vehicles, the total amount of unloading tasks increases, and the total regional benefit also increases.To sum up, when considering the scenarios of low and high traffic flow, it can be seen that scheme 0 proposed in this chapter has a relatively high performance in the two performance indicators of task processing efficiency and overall regional benefit. This proves that the proposed reverse auction scheme can effectively match buyers and sellers.


#### 5.2.2. Verification of the Authenticity of the Seller’s Bid and the Rationality of the Individual

Here we will verify the authenticity and individual rationality of the seller’s bids proposed. To verify the authenticity of the seller’s bid, we simulate the behavior of the randomly selected sellerSrandom in reasonable and other unreasonable bids and calculate the graph of the seller’s Srandom revenue changing with its bid, as shown in Figure 10.Figure 10
Authenticity verification of seller’s bid.As shown in Figure10, when the seller’s Srandom bid is less than its reasonable bid, the seller’s Srandom can never get the maximum benefit. On the other hand, when the seller’s bid reaches a reasonable price, the benefit of the seller’s Srandom is maximized. Even if the seller’s bid is greater than the reasonable price, its benefit will not increase. Therefore, it can be proved that the seller will provide a reasonable price to the buyer according to the computing resources and will not provide other quotes; that is, the seller’s bid is authentic.


## 5.1. Simulation Setting

Since the calculation task offloading scheme using the reverse auction method applies to all RCONs, to simplify the discussion, we will first use an RCON as an example to conduct a simulation study on the reverse auction scheme. We use MATLAB2016A as the platform to simulate RCON with a network area of 500 m∗500 m, in which there are 5 roads in the east-west and north-south directions, and each road has 4 lanes. In RCON, an RSU is set up as the central broker, hosting and directing the auction process. On the other hand, this chapter also uses the blockchain open-source framework Hyperledger Fabric to write smart contracts to simulate the consortium blockchain system.To evaluate the performance of the reverse auction scheme, the mobile vehicle computation offloading scheme based on consortium clockchain (scheme 0) is compared with the following baseline schemes to evaluate the performance of scheme 0:(1)
The fastest process scheme (scheme 1): in this scheme, assuming all sellers bid reasonably, buyers are always matched with the seller who can complete the application and calculate the offload fastest. If this seller runs out of idle resources, the buyer will be forced to find another seller for fast processing or offload computing tasks to edge cloud servers.(2)
The lowest cost scheme (scheme 2): in this scheme, assuming that all sellers bid reasonably, buyers are always matched with the seller with the lowest asking price per unit calculation task. Similarly, when sellers run out of idle resources, buyers will be forced to find another low-priced seller or offload computing tasks to edge cloud servers.(3)
First-come-first-served service (scheme 3): in this scheme, assuming that all sellers make reasonable bids, the buyer is always matched with the first seller to provide an offer. If this seller runs out of idle resources, the buyer will be forced to offload computing tasks to the edge cloud. Since the vehicles are randomly distributed in the simulation area, FCFS can be regarded as a random unloading scheme.(4)
Offload to edge cloud scheme (scheme 4): buyers directly offload their computing tasks to edge cloud servers for processing.In addition, for the proposed scheme, the functionσj=acj+e is used here to represent the most reasonable bid of the buyer sj, where a and e are positive constants, and these two constants follow the unloading law of the market economy, which means that the buyer sj provides that the more the computing power, the greater the reasonable bid. The settings of the relevant simulation parameters are shown in Table 3.Table 3
Simulation parameter settings.
ParameterValuecj1∗109−3∗1010bit/scEC1∗1011−7∗1011bit/sri1.5∗1011−3∗1011CPU cyclea3∗10−19e1∗10−8δ1.8∗104Tij5–8 (MB/s)TEC5–6 (MB/s)λi0.7−0.9dij4−10MBLane-width4 mθ0.5−1sViB,VjS30−50km/hliB,ljSRandom distributionRRSU1200 mRV500 m


## 5.2. Simulation Analysis

### 5.2.1. Vehicle Density Analysis

We first analyze the impact of vehicle density within the RCON region on the overall benefitUηij of the region and on the average computing time of a single computing program (assuming that the computing task can be divided into computing programs with a fixed data size).In the case of low and high vehicle flow levels, we simulated the scheme 50 times with different parameter values. We obtained the average value to cover various traffic conditions, making the conclusion more general.Figures2–5 show the changes of the average calculation time of a single calculation program and the regional overall benefit Uηij with the number of sellers under low vehicle density (18 buyers and 22 buyers).Figure 2
Change of average calculation time of a single calculation program with the number of sellers (18 buyers).Figure 3
Change of average calculation time of a single calculation program with the number of sellers (22 buyers).Figure 4
Change of average value of regional overall benefit with the number of sellers (18 buyers).Figure 5
Change of average value of regional overall benefit with the number of sellers (22 buyers).According to Figure2 of Figure 3, we find that the average computing time of a single computing program in scheme 4 is always the highest. This is because when it is offloaded to the edge cloud, the edge cloud receives too many requests, resulting in that it cannot process the task of vehicle unloading in time, which causes a large delay in unloading. The calculation time of a single calculation program of scheme 2 and scheme 3 gradually decreases with the increase of sellers because the buyer has more options at this time, and the buyer’s task can be uninstalled faster. But these two schemes are still less efficient than scheme 0 and scheme 1. For scheme 0 and scheme 1 solutions, with the increase in the number of sellers, the computing resources are gradually sufficient, and the completion time of the unit calculation program gradually decreases. The performance of scheme 0 is close to scheme 1 of the fastest processing scheme, which reflects the superiority of the time performance of scheme 0.According to Figures4 and 5, it is found that, with the increase of the number of sellers, the overall regional benefit Uηij of all schemes increases because with the rise in the number of sellers, more buyers can enjoy the calculation service and eventually reach relative stability where most buyers can be successfully matched to the right seller. At the same time, we found that, under low vehicle density, the Uηij value of scheme 0 is higher than other schemes, the buyer’s cost of scheme 1 is higher, and scheme 2 time cost is higher. However, the randomness of scheme 3 is high, and the performance level of these schemes is not high, which shows that scheme 0 can reasonably match buyers and sellers and maximize the regional benefits of RCON.Figures6–9 show the changes of the average calculation time of a single calculation program and the regional overall benefit Uηij with the number of sellers under higher vehicle density (38 buyers and 42 buyers).Figure 6
Change of average calculation time of a single calculation program with the number of sellers (38 buyers).Figure 7
Change of average calculation time of a single calculation program with the number of sellers (42 buyers).Figure 8
Change of average value of regional overall benefit with the number of sellers (38 buyers).Figure 9
Change of average value of regional overall benefit with the number of sellers (42 buyers).It can be seen from Figures6 and 7 that the average calculation time of a single calculation program of scheme 4 is always the highest for the same reason as in the low flow case. For scheme 3 and scheme 2, the curve decreases slightly as more buyers access computing services as sellers increase. Likewise, the performance of scheme 0 is close to the time-optimal scheme 1, which verifies the superiority of the temporal performance of scheme 0. At the same time, the average calculation time of a single calculation program for scheme 0, scheme 3, scheme 2, and scheme 1 decreased compared to the low-traffic case; as buyers had more offloading options at higher vehicle densities, the processing time of its task will be shortened.Figures8 and 9 compare the Uηij values under each scheme. Considering various factors, the efficiency of scheme 0 maintains the highest level among multiple schemes. At the same time, compared with low-traffic scenarios, due to the increase in the number of vehicles, the total amount of unloading tasks increases, and the total regional benefit also increases.To sum up, when considering the scenarios of low and high traffic flow, it can be seen that scheme 0 proposed in this chapter has a relatively high performance in the two performance indicators of task processing efficiency and overall regional benefit. This proves that the proposed reverse auction scheme can effectively match buyers and sellers.


### 5.2.2. Verification of the Authenticity of the Seller’s Bid and the Rationality of the Individual

Here we will verify the authenticity and individual rationality of the seller’s bids proposed. To verify the authenticity of the seller’s bid, we simulate the behavior of the randomly selected sellerSrandom in reasonable and other unreasonable bids and calculate the graph of the seller’s Srandom revenue changing with its bid, as shown in Figure 10.Figure 10
Authenticity verification of seller’s bid.As shown in Figure10, when the seller’s Srandom bid is less than its reasonable bid, the seller’s Srandom can never get the maximum benefit. On the other hand, when the seller’s bid reaches a reasonable price, the benefit of the seller’s Srandom is maximized. Even if the seller’s bid is greater than the reasonable price, its benefit will not increase. Therefore, it can be proved that the seller will provide a reasonable price to the buyer according to the computing resources and will not provide other quotes; that is, the seller’s bid is authentic.


## 5.2.1. Vehicle Density Analysis

We first analyze the impact of vehicle density within the RCON region on the overall benefitUηij of the region and on the average computing time of a single computing program (assuming that the computing task can be divided into computing programs with a fixed data size).In the case of low and high vehicle flow levels, we simulated the scheme 50 times with different parameter values. We obtained the average value to cover various traffic conditions, making the conclusion more general.Figures2–5 show the changes of the average calculation time of a single calculation program and the regional overall benefit Uηij with the number of sellers under low vehicle density (18 buyers and 22 buyers).Figure 2
Change of average calculation time of a single calculation program with the number of sellers (18 buyers).Figure 3
Change of average calculation time of a single calculation program with the number of sellers (22 buyers).Figure 4
Change of average value of regional overall benefit with the number of sellers (18 buyers).Figure 5
Change of average value of regional overall benefit with the number of sellers (22 buyers).According to Figure2 of Figure 3, we find that the average computing time of a single computing program in scheme 4 is always the highest. This is because when it is offloaded to the edge cloud, the edge cloud receives too many requests, resulting in that it cannot process the task of vehicle unloading in time, which causes a large delay in unloading. The calculation time of a single calculation program of scheme 2 and scheme 3 gradually decreases with the increase of sellers because the buyer has more options at this time, and the buyer’s task can be uninstalled faster. But these two schemes are still less efficient than scheme 0 and scheme 1. For scheme 0 and scheme 1 solutions, with the increase in the number of sellers, the computing resources are gradually sufficient, and the completion time of the unit calculation program gradually decreases. The performance of scheme 0 is close to scheme 1 of the fastest processing scheme, which reflects the superiority of the time performance of scheme 0.According to Figures4 and 5, it is found that, with the increase of the number of sellers, the overall regional benefit Uηij of all schemes increases because with the rise in the number of sellers, more buyers can enjoy the calculation service and eventually reach relative stability where most buyers can be successfully matched to the right seller. At the same time, we found that, under low vehicle density, the Uηij value of scheme 0 is higher than other schemes, the buyer’s cost of scheme 1 is higher, and scheme 2 time cost is higher. However, the randomness of scheme 3 is high, and the performance level of these schemes is not high, which shows that scheme 0 can reasonably match buyers and sellers and maximize the regional benefits of RCON.Figures6–9 show the changes of the average calculation time of a single calculation program and the regional overall benefit Uηij with the number of sellers under higher vehicle density (38 buyers and 42 buyers).Figure 6
Change of average calculation time of a single calculation program with the number of sellers (38 buyers).Figure 7
Change of average calculation time of a single calculation program with the number of sellers (42 buyers).Figure 8
Change of average value of regional overall benefit with the number of sellers (38 buyers).Figure 9
Change of average value of regional overall benefit with the number of sellers (42 buyers).It can be seen from Figures6 and 7 that the average calculation time of a single calculation program of scheme 4 is always the highest for the same reason as in the low flow case. For scheme 3 and scheme 2, the curve decreases slightly as more buyers access computing services as sellers increase. Likewise, the performance of scheme 0 is close to the time-optimal scheme 1, which verifies the superiority of the temporal performance of scheme 0. At the same time, the average calculation time of a single calculation program for scheme 0, scheme 3, scheme 2, and scheme 1 decreased compared to the low-traffic case; as buyers had more offloading options at higher vehicle densities, the processing time of its task will be shortened.Figures8 and 9 compare the Uηij values under each scheme. Considering various factors, the efficiency of scheme 0 maintains the highest level among multiple schemes. At the same time, compared with low-traffic scenarios, due to the increase in the number of vehicles, the total amount of unloading tasks increases, and the total regional benefit also increases.To sum up, when considering the scenarios of low and high traffic flow, it can be seen that scheme 0 proposed in this chapter has a relatively high performance in the two performance indicators of task processing efficiency and overall regional benefit. This proves that the proposed reverse auction scheme can effectively match buyers and sellers.


## 5.2.2. Verification of the Authenticity of the Seller’s Bid and the Rationality of the Individual

Here we will verify the authenticity and individual rationality of the seller’s bids proposed. To verify the authenticity of the seller’s bid, we simulate the behavior of the randomly selected sellerSrandom in reasonable and other unreasonable bids and calculate the graph of the seller’s Srandom revenue changing with its bid, as shown in Figure 10.Figure 10
Authenticity verification of seller’s bid.As shown in Figure10, when the seller’s Srandom bid is less than its reasonable bid, the seller’s Srandom can never get the maximum benefit. On the other hand, when the seller’s bid reaches a reasonable price, the benefit of the seller’s Srandom is maximized. Even if the seller’s bid is greater than the reasonable price, its benefit will not increase. Therefore, it can be proved that the seller will provide a reasonable price to the buyer according to the computing resources and will not provide other quotes; that is, the seller’s bid is authentic.


## 6. Conclusions

With the rapid development of the automotive industry, vehicles equipped with a variety of intelligent on-board equipment need more and more resources. On the one hand, a large number of driving data will be generated during the driving process of vehicles, which are useful in traffic situation analysis, automatic driving training, and other scenarios. On the other hand, due to the high mobility of vehicles and because their own computing resources are limited and the real-time distribution of computing resources is irregular, it is easy to see that some vehicles have insufficient computing resources while others have spare computing resources.Through the scheduling of mobile vehicle data and computing resources, the data and computing resources can be shared to the subjects who need them, and both parties involved in the sharing can benefit. For the resource scheduling of Internet of vehicles based on blockchain and game theory, this paper proposes a mobile vehicle computing task unloading scheme based on alliance blockchain. In the simulation phase, the performance of the calculated unloading scheme and several baseline schemes under different traffic flows is compared. The results show that the scheme in this paper has better performance than other schemes.This research work still has many places that can be improved. For example, for the scheduling of data resources, artificial intelligence technology, big data, and other technologies can be used to filter vehicle data, reduce the proportion of duplicate or useless data in shared data, and improve the efficiency of data sharing. For the scheduling of computing resources, computing tasks can be unloaded to the edge cloud server and the surrounding mobile vehicles at the same time. How to reasonably control the amount of tasks unloaded to the edge cloud and mobile vehicles is also worth studying in the future.



---

*Source: 6891618-2022-07-30.xml*