Trustful Resource Management for Service Allocation in Fog-Enabled Intelligent Transportation Systems

A fog-enabled intelligent transportation system is constructed using Vehicle-to-Everything (V2X) communications towards the Internet of Vehicles (IoV). In this system, the road side unit (RSU) and vehicle correspond to the fog server and fog device, respectively. In practice, the RSU offers instant infotainment services (e.g., video streaming and traffic assistance) to vehicles. However, the vehicles are considered untrustworthy and could possibly be exploited to attack the system, thereby compromising the service stability and data integrity. To address this problem, this article proposes truthful service allocation using a Vickrey–Clarke–Groves (VCG) auction mechanism. The RSU leads the proposed auction as a seller who sells their computing resources, and the vehicles participate as buyers who purchase these computing resources for the offered services. Consequently, the RSU generates a transaction whenever a service allocation is assigned. To secure the service transactions, we utilize a distributed blockchain system that implements Hyperledger Fabric framework among RSUs for transaction verification. The simulation results demonstrate that the proposed system provides service stability while ensuring service trustfulness.


I. INTRODUCTION
With the expansion of the Internet of Things (IoT) in recent years, devices connected to networks are expected to be the primary generators of data. Transferring data from existing data centers in cloud environments can entail bottlenecks owing to network overload [1]. Additionally, the latency due to bandwidth limitations between the user and a cloud-based data center has increased, thereby inconveniencing users. Fog computing has emerged to overcome these problems of cloud-network systems; it provides a physical distribution of the computing resources and contents of a cloud-based data center [2]. A fog computing system is composed of a cloud-based data center, fog servers, and fog devices. Fog services provided at the fog server can be hosted to nearby users. Therefore, such a system can reduce the service delay, avoid The associate editor coordinating the review of this manuscript and approving it for publication was Chakchai So-In . the use of unnecessary bandwidth, and provide users with higher quality of service (QoS) [3], [4]. These fog-computing concepts can be combined with intelligent transportation systems (ITSs) to increase the benefits significantly.
The Internet of Vehicles (IoV) includes wireless communication using Vehicle-to-Things (V2X) communication and can store computing resources (i.e., CPU power, data storage) with the on-board unit (OBU) [5]- [7]. This study involved the development of a V2X communication architecture with a fog computing system. Road side units (RSUs) and vehicles are considered to be fog servers and fog devices, respectively. The combination of fog computing with V2X communication enables data from various environments and the traffic information pertaining to the area in which a vehicle is located to be processed effectively. It is desirable for the vehicle to process real-time cumulative information using limited computational resources. To support the vehicle, each RSU can pre-process local information and transmit it to VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ all surrounding vehicles [8]. Furthermore, vehicles can utilize services from the fog server and the cloud data center, thereby reducing their computational overhead. To offload task results to RSUs, we utilize an auction-based resource assignment scheme. In addition, the blockchain technique is employed to record the results of the auction scheme. If an untruthful vehicle tries to gain access to utilities, the system becomes unstable and the safety of the vehicle is jeopardized. In particular, a resource-assignment scheme inspired by a Vickrey-Clarke-Groves (VCG) auction is proposed. The proposed scheme is a one-shot sealed-bid auction for truthful resource assignment. The VCG auction is a special case of the Vickrey auction, wherein the optimal bid for each bidder is the true value that guarantees its utility [9]. Any auction scheme involves the concepts of cost and payment. In our case, the RSU performs the task using its computing resources. The cost and the received incentive correspond to the spent resource and the payment from the vehicles, respectively.
A blockchain is a technique that uses a distributed ledger based on a hash function, enabling transactions between untrustworthy nodes even in the absence of a trusted third party [10]. Currently, blockchain technology is primarily used in the field of cryptocurrency, but it is being considered for application to society in its entirety. In particular, active research is being carried out on its application in the field of authentication and in the form of a contract known as a smart contract [11]- [14]. Based on the hash values contained in the block and by maintaining the same ledger for all nodes, the blockchain can prevent forgery in untrustworthy relationships. In a fog-enabled ITS, the vehicles being considered are untrustworthy, but the RSU nodes are trusted. The proposed blockchain is a private blockchain, which is shared by the RSUs, and which guarantees consistency via the use of an ordering service at the data center. The proposed ordering service is inspired by Hyperledger Fabric, 1 which is a blockchain platform for a business model. Recording transactions generated by untrustworthy IoV vehicles in the blockchain ensures the consistency and the security of the transaction, even if there is lack of trust between the RSUs and the IoV vehicles.
In this article, we propose an auction-based scheme for truthful resource assignment that incorporates a blockchain mechanism to ensure consistent results in the auction. The main advantages of the proposed scheme are as follows.
• A fog-enabled ITS model is considered. In the system, vehicles in the IoV network are able to utilize services provided by RSUs, and these services are defined to entail data with unique addresses.
• To ensure truthful resource assignment, a VCG-based auction mechanism is proposed. In such a set-up, the auctioneer decides the relevant IoV vehicles and payments based on the bids. It is optimal for the IoV vehicles to bid truthfully for their utilities. This truthful behavior 1 https://www.hyperledger.org/projects/fabric on the part of the vehicles is verified and illustrated by simulating the results. The proposed auction guarantees resource assignment fairness when all the vehicles bid truthfully.
• The blockchain model is jointly utilized to record the auction results reliably. Excessive consumption of computing resources for proof-of-work (PoW) and validation is avoided by executing an ordering service at the data center with Hyperledger Fabric platform.
The remainder of this article is organized as follows. Related work is surveyed and summarized in section II. Section III presents an overview of the fog computing model with V2X communication. Section IV and Section V contain details of the truthful resource assignments and the proposed blockchain system, respectively, for RSUs and IoV vehicles in a mobile fog computing environment. Section VI presents the system performance evaluation and the results of the numerical analysis. Finally, Section VII concludes this article.

II. RELATED WORK
Auctions contribute to resource distribution in a mobile edge environment in several ways. A multi-user computation offloading game that takes into account both communicationand computation-related aspects of mobile edge cloud computing was considered [15]. A feasible and truthful incentive mechanism (TIM) was proposed to coordinate the resource consuming a double auction between mobile devices, as service users (buyers), and cloud, as service providers (sellers) [16]. The aforementioned resource allocation methods [15], [16] were proposed for general cloud computing environments. Several recent studies were concerned with fairness in supply and demand for fog resources in auction-based resource assignment [17], [18]. However, these approaches remain vulnerable owing to selfish buyer behavior. As a result, individual buyers either have a monopoly or engage in inefficient resource consumption.
A blockchain cloud architecture based on software-defined networking (SDN), in which the blockchain technique ensures transparent transactions between service providers and users in the cloud architecture, was introduced [19].
A blockchain-SDN-enabled architecture for IoV and fog computing was proposed [20]. By avoiding frequent handovers, the proposed system improves the transmission latency and packet delivery rate. Furthermore, a blockchain system that provides security and privacy for smart homes was proposed [21]. The authors configured the smart home environment using IoT devices in three primary layers consisting of cloud storage, overlay, and the smart home. They eliminated the concept of PoW and the coin, and chose to apply blockchain to the smart home, where the miner is an Internet-connected device that audits and controls all internal and external communications to the home. However, rather than strengthening security via maintaining distributed ledgers among the nodes, the miner manages the chain in a centralized manner based on the operator positions. Therefore, this approach lacks the basic concept of decentralization, which is fundamental to the blockchain.
In current blockchain technologies, PoW and proof-ofstake (PoS) are the primarily used consensus algorithms, where PoW is the most widely used consensus algorithm. It is also implemented in the Bitcoin system [10]. In PoW, a miner finds a hash value smaller than a certain given value in the problem (the target value); furthermore, it generates a block by changing the nonce into the input value of the hash function. PoW is a secure and powerful method of consensus that prevents double payments by allowing miners to engage in intensive computer calculations. However, the energy resources consumed by this process accumulate over time when the difficulty of the search increases and the computing power of the nodes decreases. Further, as nodes form a pool, decentralization is weakened, and most of the mining is carried out at the large mining pools.
PoS, on the other hand, is an energy-saving consensus algorithm in which each node has a specific probability of generating a block. This probability is proportional to the amount of assets (i.e., stakes) that a node currently holds. This method does not require a high-performance mining tool, and is capable of penalizing the miner if the block is created maliciously. It is economical and eco-friendly as it does not need to compute a number of hash calculations. Furthermore, it provides a decentralized approach of consensus where all the nodes with a certain amount of coins can generate blocks. However, nodes may pretend to hold coins for a longer time to receive greater incentives. This has the effect of decreasing the circulation of coins in the market. Research regarding the application of blockchain in a vehicular environment is at its early stages. This article proposes a novel blockchain system based on ordering services for mobile resource management in the IoVs domain.

III. FOG COMPUTING MODEL WITH V2X COMMUNICATION
As in the case of a typical fog computing architecture, the network model consists of a cloud data center, RSU-Fog nodes as the fog servers, and IoV vehicles as the fog devices. OBU-equipped IoV vehicles collect real-time traffic data from their sensors and transmit these data to the adjacent RSU-Fog servers wirelessly via the uplink (e.g., wireless access vehicular environment (WAVE)). Following that, the RSU-Fog nodes process real-time traffic data and communicate useful information to the cloud data center via the uplink. The RSU-Fog nodes are capable of caching data or files from the cloud data center to provide file streaming services to the IoV vehicles. Further, each RSU-Fog node is capable of communicating with adjacent RSU-Fog nodes. Transferring data via pairs of RSU-Fog nodes may be faster than transmission through the cloud data center in certain cases.
As illustrated in Figure 1, the proposed VCG-based auction is performed between the RSU-Fog nodes and the  IoV vehicles. After the auction, RSU-Fog nodes compile a list of all transactions that took place during the auction and transmit the list to the cloud-based data center. Based on the list, the cloud-based data center constructs a new block by applying the ordering service. Finally, all RSU-Fog nodes receive the newly constructed block from the cloud-based data center. Further, if the RSU-Fog nodes are unable to receive the block from the data center, the block can be transmitted via adjacent RSU-Fog nodes.
Several modules are contained in each RSU and OBU at a RSU-Fog node and an IoV, respectively. Such modules include the auction module, the blockchain module, the communication module, and the central module, as depicted in Figure 2. Each RSU-Fog node communicates with other RSU-Fog nodes and with the data center using the Ethernet protocol. The specific mode of communication depends on users' preferences and was not addressed in this study. The central modules of both the RSU and IoV fog nodes are responsible for computational operations. When an IoV node wishes to participate in the auction, the relevant bid is calculated by the central module using the auction information available at the auction module. The most important component in this system architecture is the blockchain module. Section V provides details on the blockchain-related issues. VOLUME 8, 2020

IV. TRUTHFUL AUCTION SCHEME FOR MOBILE FOG COMPUTING RESOURCE ASSIGNMENT
The IoV vehicles can offload tasks that are computationally demanding to the more powerful RSU-fog node to save their relatively limited computing capabilities. Assuming that the computing resources of the RSU can be divided into several computing units that can execute tasks in parallel, it is necessary to optimally match the requirements of offloaded tasks with the capabilities of these computing units. IoV vehicles are expected to compensate the RSU to use its computational resources and the RSU requires a policy to maximize this price. Thus, an auction mechanism is proposed for price determination and efficient allocation of computational resources. From the perspective of the auction, IoV nodes willing to buy resources from the RSU-Fog nodes can be considered as the buyers and the RSU-Fog node can be considered as the seller who sells their computing resources to the buyer IoV vehicles. In the proposed auction scheme, the seller collects bids from the buyers. Following that, the seller chooses the best buyers to whom to sell its computing resources. The seller acts as an auctioneer who selects the buyer with the highest bid. Therefore, hereafter, the terms ''seller'' and ''auctioneer'' are used interchangeably.
The auction is conducted in three phases: 1) launching the auction, 2) calculating the winning bid and payment, and 3) announcing the result. Before execution of the auction scheme, the cloud-based data center and the adjacent RSU-Fog nodes are assumed to have information of the expected route and duration of the journey of each IoV node. In Section IV-B, we describe the proposed truthful auction algorithm in detail.

A. PROBLEM FORMULATION
Before we present the truthful auction algorithm, this subsection defines a related problem formulation. When an IoV node i has a task to be offloaded to an auctioneer (e.g., the seller), the set containing the workloads of all the tasks is denoted as follows.
where the workload of the i-th task is denoted by w i . The auctioneer (e.g., RSU-Fog) possesses J computing units, and each computing unit may have different computing capabilities (e.g., CPU cycles). Suppose that computing unit g j operates at f j cycles per second. (2) Each buyer (e.g., IoV node) i who is willing to participate in the auction submits their set of bids as follows.
where the bids are calculated in accordance with the task workload w i .
The buyer can either submit the bids directly to the auctioneer or can submit the bids via the adjacent RSU-Fog node. Therefore, a buyer i is expected to include the ID of the adjacent RSU-Fog node with its submission of the bid information as follows.
where a i is the size of the transmitted data in bits.
After each buyer submits their bids, all the submitted bids sent to the auctioneer are denoted as follows.
where I denotes the total number of participating buyers.
In the proposed auction scheme, the bid is calculated based on the cost incurred to perform the task. The cost function should reflect the time taken to perform the task, including the transmission time of the data, as follows.
where f j denotes the cycles of the computing processor, = w i f j is the expected computation time, t TR j is the time required for data transmission from the buyer to the auctioneer, and C V i is the unit cost of computation when the task is executed by the vehicle. Each task has a predefined priority and corresponding unit cost according to its priority. Further, C is a defined set of coefficients under the assumption that can be formulated as follows: where a i is the total amount of data transmitted r i , which can also be formulated as where W , N 0 W , p * i,j , and h denote the channel bandwidth, noise in the air (which is proportional to W ), received power at the adjacent RSU-Fog node from the IoV I , and channel gain between I and the adjacent RSU-Fog node, respectively. Therefore, in the proposed auction, the bid is determined by the expected cost incurred, as follows: A bid, submitted by a buyer, that is equal to the cost incurred, such as (11), can be regarded as a truthful bid, but an untruthful buyer may submit a bid different from the indicated cost function.
The objective of the auctioneer is to maximize the total payment while processing the offloading tasks. Let x i,j be the indicator variable, which takes the value 1 or 0 based on whether or not b i,j is a winning bid, respectively. Therefore, the objective function of the auction can be defined as follows.
subject to Constraints (13) and (14) are defined to ensure one-to-one correspondence between the computing units at the RSU and the task workload.

B. TRUTHFUL AUCTION ALGORITHM
The auctioneer should select the highest bid and determine the payment via the VCG-based auction. In addition, the VCG auction provides truthful bidding according to [22]. This subsection presents details on the proposed VCG auction-based resource assignment scheme, which comprises three phases: 1) launching the auction, 2) calculating the winning bid and payment, and 3) announcing the result. The scheme is presented in Algorithm 1. The details of each phase are as follows.

1) Launching the Auction:
The auctioneer initiates the auction by broadcasting auction-related information, including the ID of the auctioneer RSU-Fog node, the bid submission deadline, and the CPU cycles of the computing units. This information can be denoted as follows: where T denotes the bid submission deadline determined by the auctioneer. The adjacent RSU-Fog nodes receiving the auction information broadcast the information to the associated IoV vehicles. The vehicles check the RSU ID , the bid submission deadline, and travelling route to determine whether they can reach the auctioneer. Following that, when an IoV wishes to offload a task to the initial RSU-Fog node, it participates in the auction by submitting a bid, which is calculated as a cost using Equation (7).

2-1) Calculation of Winning Bid:
The auctioneer aims to match the buyer with a computing unit that maximizes the bid to process the offloading task as represented in the objective function in Equation (12). In this case, the value of β, which is the bid per computation processing time, can be used instead of b i,j to maximize the profit over unit time. The proposed auction algorithm uses the Hungarian method to match the buyer with a computing unit. This is a well-known method for optimizing the solution in an assignment problem, and ensures one-to-one matching.
where I denotes the total number of participating buyers. The complexity of the Hungarian method is O(I 3 ) with I IoV agents. Fortunately, in the V2X environment considered in this study, tens of IoV vehicles are typically served by a RSU.

2-2) Calculation of Payment:
In the VCG auction, the bidder that bids the overbid value (bid with the highest cost) is determined to be the winner and payment is determined correspondingly. In the proposed VCG-based auction, the payment is determined by the value of β for using the computing unit per unit of time rather than the original bid.
Finally, the payment in the proposed auction scheme is formulated as follows: where S G B is the maximum total value of the beta set. The time complexity of the VCG algorithm depends on the number of participating IoV users and the number of processing units. Suppose that I users participate in the auction and each RSU is equipped with J processing units. Accordingly, the complexity of the proposed mechanism is O(IJ ).

3) Announcement of Result:
The calculated payment for the winning seller is conveyed secretly to the corresponding IoV. It is also transmitted to the neighboring RSU-Fog nodes and the cloud-based data center to record the payment as a transaction in the transaction list. Details of the transaction model are provided in Section V.

V. BLOCKCHAIN MODEL FOR MOBILE FOG COMPUTING RESOURCE ASSIGNMENT
In the proposed blockchain model, the duration for which the winning IoV is allowed to use the service provided by the RSU-Fog node is analogous to a coin in the bitcoin system [10]. Further, the RSU-Fog node acts as the publisher who issues coins. The proposed blockchain system replaces the classic PoW process with an ordering service at the cloud-based data center. The term ''coin publisher'' is used to refer to RSU-Fog nodes that issue coins to the IoV vehicles. RSU-Fog nodes conduct transactions by themselves according to the result of the auction or collect the transactions from IoV vehicles, compile their respective transactions into lists, and transmit their transaction list to the cloud-based data center periodically. The cloud-based data center conducts the ordering service and constructs the new block. Finally, the cloud-based data center broadcasts the new block, which is shared by the RSU-Fog nodes. It is assumed that RSU-Fog nodes can recognize the new block by the time stamp and the serial number of the block. It is assumed that the cloud-based data center can be trusted with each block, including its signature. IoV vehicles can transact at an RSU-Fog node and simply refer to its account through the wallet. Furthermore, it is assumed that each IoV, RSU-Fog node, and the cloud-based data center that wish to participate in the blockchain system need to connect to the network to VOLUME 8, 2020 Algorithm 1 VCG Auction-Based Resource Allocation 1: Phase 1: Launching the Auction 2: The RSU-Fog node broadcasts task information as an auctioneer 3: for i = 1 → I do 4: for j = 1 → J do 5: buyer i computes b i,j using cost function C i,j (w) 6: end for 7: buyer i submits the bid information B i 8: end for 9: Phase 2: Calculation of Winning Bid and Payment 10: The auctioneer calculates the winning bids by the Hungarian method 11: if b i,j is selected then 12: x i,j ← 1 13: end if 14: for i = 1 → I do 15: for j = 1 → J do 16: if x i,j = 1 then 17: Calculate P i,j with (18); 18: end if 19: end for 20: end for 21: for i = 1 → I do 22: for j = 1 → J do 23: if x i,j = 0 then  create new pairs of public and private keys. Key pairs are generated using the elliptic curve digital signature algorithm (ECSDA). After generating key pairs, device IDs and public keys are shared, following which it is assumed that all nodes are aware of the public keys and device IDs of each other. Further, the proposed scheme makes use of the SHA256 hash function.

A. TRANSACTION
A transaction occurs in two cases: 1) when a coin is issued, and 2) when a coin is transmitted. The coin is generated when the RSU-Fog node offers an incentive to the IoV vehicles, which is determined by the truthful auction scheme explained above. Further, IoV vehicles can buy the corresponding coin to use the service provided by the RSU-Fog node for a certain duration via an existing payment process (e.g., via the card billing system). After the auction procedure that involves the bidding, the RSU-Fog and IoV vehicles have to exchange a transaction message, which is stored in a distributed ledger. Hyperledger Fabric manages the private and public keys to distinguish the V2X group and enable safe trading. In the proposed system, RSU-Fog provides incentives, such that it becomes a publisher that creates coins. Fig. 3 shows the main components of the transaction structure. When a coin is issued, the public key of the IoV is concatenated to the total payment content to be paid by the IoV, and this content is signed with the publisher's private key. The IoV can refer to the payment with its public key during its subsequent transactions. When using a coin or sending one coin to another IoV, the recipient's public key is added to the transaction content and signed with its private key. Validation of the transaction confirms that the publisher of the initial coin is a valid RSU-Fog node. A coin equipped with a hash pointer can identify the first transaction of the coin being used and decipher the publisher's signature. It should be verified that the publisher is one of the RSU-Fog nodes. The other nodes can validate the publisher on the basis of the signature included in the initial coin.
Once a transaction occurs, another transaction can be conducted immediately at the same RSU-Fog node. If other RSU-Fog nodes validate the usable coin, the current RSU-Fog node conducts this transaction and updates the time stamp. The RSU-Fog nodes compile the valid transaction lists and transmit them to the cloud-based data center periodically.

B. BLOCKCHAIN
Blocks are written in a programmable script language. A block contains the transaction list, the hash value of the previous block, relevant serial number, and the signature of the cloud-based data center. This signature is the association of its secret key with the specific block being discussed, which enables other nodes to validate the block. The chain is synchronized using P2P communications between nearby RSU-Fog nodes. Further, before an auction starts, an RSU-Fog node can synchronize by requesting data regarding the latest block from the cloud-based data center.
Additionally, we propose a transaction filtering scheme to ensure an efficient blockchain system [23]. The RSU-Fog nodes possess more powerful storage and computing capabilities than the IoV vehicles. However, it is not efficient to permanently store all transactions and blocks that occur on the actual network. Therefore, transactions in the proposed system are structured in a way that they can be created and destroyed to remove them from the system anytime. Once a transaction has been created, it may consume all available computing capabilities. For example, an IoV that purchased a coin for video streaming may destroy the coin after the video ends. Subsequently, the coin may not be available again on the network. Therefore, the flags of the transaction and all corresponding referenced transactions are changed to have the value ''0'' to prevent transactions from being reused. When a transaction is generated by an IoV, the associated RSU-Fog node changes the value of the flag during validation of the transaction. The value corresponding to the flag of the transaction is set to 0 and reported to nearby RSU-Fog nodes and data centers. As the RSU-Fog nodes and the data center maintain ledgers, all past transactions referenced by the transaction can be accessed, and the flags corresponding to all referenced transactions are changed.

C. CONSENSUS ALGORITHM
Our proposed blockchain system is based on a novel consensus algorithm that uses the ordering service concept of Hyperledger Fabric. The algorithm enables the RSU-Fog node to issue a coin and the cloud-based data center generates a block after ordering. In this manner, the RSU-Fog nodes can be considered to be trusted endorsers. As mentioned previously, transactions are generated either by the RSU-Fog nodes or the IoV vehicles. Once a transaction is generated, a notification is sent to the nearest RSU-Fog nodes, where the RSU-Fog node verifies the validity of the transaction. Upon verification of the validation of the transaction, the transaction is conducted immediately and the wallets of the related IoV vehicles are updated. Following this, the RSU-Fog node compiles the transaction list by including the signature. RSU-Fog nodes maintain transaction lists and report to the cloud-based data center periodically within time period T . The transactions reported to the cloud-based data center have already been verified by the RSU-Fog nodes, and the data center does not need to verify them again. The cloud-based data center verifies the signatures of the RSU-Fog nodes, and synthesizes the valid transaction lists into an aggregate list. The cloud-based data center generates the block on the basis of the sorted transaction lists and its signature, and broadcasts the block to the RSU-Fog nodes. If any transactions were removed by filtering, the data center broadcasts the modified ledger.

VI. PERFORMANCE EVALUATION
A simulation environment consisting of IoV vehicles and RSU-Fog nodes is set up to verify the feasibility of the proposed auction. The communication latency of the entire auction procedure is measured. Further, the truthfulness and individual rationality on the part of the bidders, promised by the auction, are verified experimentally. The auction itself is considered as a rational entity when all of the individual bidders' utilities are non-negative [9]. A blockchain system is simulated to measure the mean latency of block propagation and the mean number of transactions contained in each block.

A. SIMULATION SETUP
To illustrate the truthfulness and individual rationality of the buyers in the auction, the detailed auction algorithm was implemented using MATLAB. For the simulation, each bid was set to take place in a range of (10, 100) minutes randomly. The ns-3 simulator was used to set the wireless communication environment between IoV vehicles and RSU-Fog nodes. The IoV vehicles communicated with the nearest RSU-Fog node using the IEEE 802.11p and TCP protocols. The IEEE 802.11p module is installed in the RSU to provide wireless connections to IoV users [8]. Hyperledger Fabric platform supports both TCP and UDP protocols. Without loss of generality, a TCP environment was designed in this work to ensure a reliable transmission environment. The IoV vehicles generate bidding packets at intervals of 10 seconds. The data rate of the IoV vehicles was set to 500 Kbps. During the auction, wireless communication takes place using the following process: 1) The RSU-Fog node sends a broadcast message to the IoV vehicles, notifying them of the auction information and the beginning of the auction. 2) IoV vehicles bid on the RSU-Fog node via unicasting.
3) The RSU-Fog node unicasts the auction result to the winning IoV. In the simulation, the number of winning IoV vehicles was set to 1. Ten auctions were conducted at the RSU-Fog node in intervals of 10 seconds, and the average latency was evaluated in each case. The proposed RSU-Fog node was structured in a manner that is similar to that of the endorser in Hyperledger Fabric. Therefore, the simulation was performed using the settings of Hyperledger Fabric. In the simulation, the number of endorsers was set to 10 and the number of clients creating transactions was set to 40. Each client generated a transaction every 20 seconds, and the block was generated every 2 seconds. When a P2P network was constructed randomly, simulation was performed by increasing the number of RSU-Fog nodes that participate in the propagation of the block.

B. SIMULATION RESULT
In the proposed auction, the bidders' utility is the difference between the payment offered and the cost incurred. The utility for any bidder other than the winner of the auction is 0 because both the payment and cost are 0. The truthfulness was verified by using the bid per cost and utility [9]. A bid submitted by a dishonest bidder may be lower or higher than the cost incurred. This utility was measured when one node alters the bid per cost ratio. There were 30 bidders and 10 winning bids. The average utility was calculated after conducting the auction 30 times with each bid per cost. Based on Figure 4, the utility is the highest when the bid per cost is 1.   The statement ''The bid per cost is 1'' means that the buyer node placed an honest bid, equal in value to the cost incurred.
As shown in Fig 5, we compared the winner's utilities obtained with the proposed algorithm, the normal round-robin (RR) method, and the time slice priority-based round-robin method (TSPBRR). Because the buyers conduct bidding with the dominant strategy, the proposed algorithm stabilizes the utility even when the IoV increases bidding. On the other hand, RR and TSPBRR determine the computing resources trough ways that distribute the RSU to the IoV in accordance with the order of the requests simultaneously.
The payment and the cost of the winning bidders is shown in Figure 6 for all honest nodes. As the bidders that failed to win in the auction have zero payment and cost, they are not represented in Figure 6. The payment is always higher than the cost incurred for each winning bidder. Therefore, individual bidders have positive utility in all cases and the proposed auction is individually rational.
As illustrated in the Figure 7, the number of IoV vehicles is directly proportional to the average latency, and their relationship is almost linear. The overall communication latency is less than 0.1 seconds for 90 IoV vehicles. This is negligible and demonstrates that auctions can be conducted in a wireless communication environment. Further, the auction algorithm   takes less than 1 second to run when 100 nodes are used in the MATLAB simulation and demonstrates that the auction method can be fully realized.
The block propagation latency is defined as the time taken between transaction generation at a certain RSU-Fog node and the verification of the block containing this transaction by the same RSU-Fog node. Even if the number of nodes was increased to 300, the block would be transmitted within 3 seconds according to Figure 8. As the number of nodes increases, the average relay time also increases. The reason for the low latency even when 300 nodes are involved, is considered to be the effect of the randomly connected P2P network. Therefore, the average latency is generally expected to increase as the number of nodes increases, although the influence of the network structure is significant. Figure 9 shows that seven transactions are included in one block on average, irrespective of the number of nodes in the system. This is probably because of the number of clients creating a transaction, which is the same in all cases. Therefore, it can be concluded that the inclusion of transactions in a block depends on the total number of created transactions rather than the performance of the network.

VII. CONCLUDING REMARKS
A truthful VCG-based auction scheme is proposed for managing the computing resources in a fog-enabled intelligent transportation system. The auction decides the allocation of tasks offloaded by the IoV to RSU-Fog nodes and calculates the corresponding payments. An IoV participating in the auction bids honestly for its own utility, and the payment is calculated reasonably according to the auction policy. We introduced a blockchain system to record the results of these auctions and the purchased service times. The proposed blockchain system includes an ordering service as a consensus algorithm. This helps to save energy and computing power compared with the PoW method.