Resource Allocation in Decentralized Vehicular Edge Computing Network

Abstract

Computation-intensive vehicle tasks sharply increase with the rapid growth of intelligent vehicles. The technology of Mobile Edge Computing (MEC) has the possibility of assisting vehicles with computation offloading. To solve the problem of computation resource management and guarantee the security of resource transaction, we jointly combine the MEC network and the blockchain networks to build a blockchain based MEC offloading model. The non-cooperative interactions between MEC server and vehicles formulate a two-stage Stackelberg game in an aim to maximize their benefits and information security. We theoretically demonstrate the unique existence of Nash equilibrium, which enables participants to decide their optimal strategies. Finally, the performance of the proposed model is analyzed by conducting simulation experiments. Our proposed model optimizes resource allocation and also improves the security of the whole network.

1. Introduction

The development of urban intelligent transportation incurs people’s convenient travel. Many innovative vehicle applications have emerged, such as intelligent driving control, on-board online multimedia, image assisted navigation, and so on. Related researchers have conducted a lot of studies and experiments on its main techniques (e.g., gait recognition, Spatial-temporal prediction, and pedestrian flow prediction) [1,2,3,4,5]. The implementation of these technologies not only requires significant computing and caching resources, but also presents the serious challenge on limited energy a vehicle can carry. It is difficult for a vehicle to support such a huge computational workload and energy consumption during driving [6]. For good Quality of Service (QoS), relevant researchers have conducted more detailed and in-depth studies [7,8,9,10,11], which to some extent alleviate the computational workload and energy consumption of vehicles. However, these studies focused on optimizing the models and algorithms for vehicle applications instead of offloading the overloaded computational tasks of vehicles. The development of mobile edge computing (MEC) has led to a significant role in urban smart mobility [12]. It is a promising technology that allows vehicles to offload their local computing tasks to nearby MEC servers. So, the vehicle’s own computational workload and energy consumption can be sharply reduced [13]. However, in order to maximize its revenue, the MEC server prefer to price the computing resources it provides to vehicles. According to MEC server’s pricing, the vehicles next decide the number of its offloading computation tasks for their cost minization. So, The MEC server and vehicles interact with each other to determine an optimal resource pricing and management for their interest maximization. Zeng et al. [14] analyzed the conflict of interest between MEC servers and vehicles using the Stackelberg game to cooperate MEC servers and vehicles. This approach effectively alleviates the problem of limited computing resources for vehicles, however, it fails to take security issues into account. There is a large amount of data exchange and transaction records in the MEC network. The entire network is likely to be vulnerable, which even leads to unacceptable errors. The authors in [15,16] introduced an economic computing resource management based on the Stackelberg game model, which also took into account blockchain for network security. However, these works employ proof-of-work (PoW) protocols to achieve consensus in the blockchain. Block mining and synchronization can lead to high energy costs and long latency, making it unsuitable for vehicles with limited computational resources. To address the above challenges, we utilize Stackelberg game to optimal the resource allocation and pricing model in an attempt to maximize each participant’s revenue. Moreover, we implement the blockchain by a POS mechanism to guarantee offloading safety, which consumes less energy in comparison with the POW mechanism [17]. Our main contributions are enumerated as follows.

• We introduce MEC to offload the computational tasks of vehicles for alleviating their computational and energy burdens. The security risks are also considered in the computational offloading process by integrating the blockchain network into the MEC network.
• In the blockchain network, the POS mechanism is used instead of the POW mechanism, avoiding the problem that POW will generate huge energy consumption.
• We analyze interactions between participants through the Stackelberg game and prove theoretically to achieve a unique Nash equilibrium. Conflicts of interest of participants are resolved by rationally allocating resource and pricing in the network.

2. Blockchain-Based MEC Network Architecture

In blockchain-based MEC network architecture, both MEC networks and blockchain are built based on computation resources and wireless communication [18]. The combination of blockchain technology into MEC networks can fully utilize their respective advantages. On the one hand, blockchain protects the accuracy, consistency and validity of data in a transparent way [19]. In the MEC network, the data generated by the vehicles and the MEC server during the computational offloading process are encrypted and stored on blocks of the blockchain. It is feasible for privacy protection and security without any third-party control mitigation. Blockchain technology has the practical availability in transaction market across different infrastructures and operators under insecure network conditions. On the other hand, the nodes in the blockchain need to have sufficient computing resources for generating blocks, broadcasting and verifing them through the network. The complete blockchain needs to be stored in all the blockchain nodes for ensuring the accuracy, consistency, and validity of their data. The servers deployed in the MEC network have enough computing and storage resources to meet these computation and caching demands of the blockchain [20,21].

Participants in the Blockchain-Based MEC Network Architecture

In this paper, the blockchain network is used as the backbone of the decentralized computing resource allocation network [22]. Each participant (the MEC server equipped in the base station, the requesting vehicle on the road) maps itself as a node in the blockchain network, as shown in Figure 1. The MEC server deployed in the base station has sufficient computing resources to offload their computing tasks of the nearby requesting vehicles. Meanwhile, the MEC servers are considered consensus nodes equipped with roughly synchronized clocks to perform the consensus process in the blockchain network. All recent transaction data are written into a block and stored, broadcast, and verified by the consensus node. Each block stores a certain number of transaction records generated at fixed intervals and connects to the previous block in the block list for forming an ordered blockchain. Due to the requesting vehicles are constrained by energy and computing resources [6], their computing tasks are offloaded to a nearby MEC server for task execution. In return, the MEC server obtains proper economic compensation from requesting vehicles. All requesting vehicles participate in the blockchain network as light nodes and only perform actions, such as requesting task offloading, transmitting computation tasks, and receiving computation results, as opposed to consensus nodes mapped by the MEC server.

3. System Model

This section presents the blockchain-based MEC model shown in Figure 1. The notations of frequently used symbols are explained in

Table 1. The main notation used in this paper.

Parameter	Meaning
$c_j$	The MEC server indexed by $j$ in the proposed model
$v_i,i\in N_j$	The requesting vehicle $v_i$ connected to MEC server $c_j$
$b_{i,j}$	The bandwidth between vehicle $v_i$ and MEC server $c_j$
$h_{i,j}$	The channel gain vehicle between vehicle $v_i$ and MEC server $c_j$
${\sigma }_{ij}$	The noise variances of vehicle $v_i$ to MEC server $c_j$
$w_i$	The total computational workload required for the task of vehicle $v_i$
$t_i$	The uplink transmission time of the task submitted by vehicle $v_i$
$X_i$	The computational workload required per unit of task data
$p_{i,j}$	The transmit power between vehicle $v_i$ and MEC server $c_j$
$s_j$	The computation resource pricing of MEC server $c_j$
$P_j$	The probability of selecting server $c_j$ as a block producer
$k_i,K_j$	The energy coefficient of vehicle $v_i$ and MEC server $c_j$
$f_i,F_j$	The CPU computing capability of of vehicle $v_i$ and MEC server $c_j$
$R_{i,j}$	The transmission rate between vehicle $v_i$ and MEC server $c_j$
$R_v,R_c$	The block generation reward and block consensus reward
$E_{i,j}$	The total energy consumed by vehicle $v_i,i\in N_j$
$E_j$	The total energy consumed by MEC server $c_j$

.

It is assumed that in this model, there are a total of $m$ MEC servers in the MEC network, and each server is deployed at the appropriate location. The collection of MEC servers is denoted as $\left\{c_1,c_2,\dots ,c_j,\dots ,c_m\right\}$. Each MEC server connects different number of requesting vehicles within its communication range. We use $N_j=\left\{v_1,v_2,\dots ,v_i,\dots ,v_{n_j}\right\}$ to denote the set of requesting vehicles, connecting to MEC server $c_j$. Assume that the computing task $A_i:\left(w_i,T_i,X_i\right)$ is generated by the requesting vehicle $v_i, i\in N_j$, where $w_i$ is the total workload to finish the task $A_i$, $T_i$ is the time delay that vehicle $v_i$ can tolerate, and $X_i$ is the computational workload required for per unit of task data.

3.1. Requesting Vehicle Model

3.1.1. Communication Model

Requesting vehicles and MEC server communicate via a wireless channel. Assume that $p_{i,j}$ is the transmit power of requesting vehicle $v_i$ on a subchannel of MEC server $c_j$. So, the wireless channel rate $R_{i,j}$ is defined as [23].

$$R_{i,j}=b_{i,j}{\log }_2\left(1+\frac{p_{i,j}{h}_{i,j}}{{\sigma }_{i,j}^2}\right)$$

(1)

where $b_{i,j}$ is the bandwidth of the subchannel between the requesting vehicle $v_i$ and MEC server $c_j$, $h_{i,j}$ and ${\sigma }_{i,j}$ represent the channel gain on the subchannel and the additional white Gaussian noise power, respectively [17].

3.1.2. Energy Consumption Model

We here neglect the downlink transmission time of a task since the the data size of task result is small. Assume that the uplink transmission time of task $A_i$ is $t_i$. It is easily seen that $t_i<T_i$. So, the size of the task $A_i$ is offloaded to MEC server $c_j$ for execution as $R_{i,j}{t}_i$ [24]. The energy cost of requesting vehicle $v_i$ to complete a computing task $A_i$ mainly consists of local computing energy consumption and uplink transmission energy consumption. Thus, the total energy consumption $E_{i,j}$ is

$$E_{i,j}=E_{i,j}^{local}+E_{i,j}^{trans}=k_i{f}_i^2\left(w-R_{i,j}{t}_i{X}_i\right)+p_{i,j}{t}_i$$

(2)

where $k_i$ is the energy coefficient that is dependent on the chip architecture of vehicle $v_i$, $f_i$ is the CPU computing capability of the vehicle $v_{\mathrm{i}}$, and $p_{i,j}$ is the transmit power from the vehicle $v_i$ to the MEC server $c_j$ [25]. $E_{i,j}^{local}$ represents the energy consumption generated by the local computation of the requesting vehicle $v_i$, and $E_{i,j}^{trans}$ represents the energy consumption generated by uplink data transmission from vehicle $v_i$ to MEC server $c_j$.

3.1.3. Payment Model

The requesting vehicle needs to pay the MEC server for the corresponding computational resources while submitting computational task to the MEC server for execution. It is supposed that $s_j$ is the unit cost of the resource in MEC server $c_j$, and $p_{i,j}$ can represent the processing power allocated by MEC server $c_j$ to the requesting vehicle $v_i$. Then, the $M_{i,j}$ is defined to represent the payment paid by requesting vehicle $v_i$ to MEC server $c_j$ [14],

$$M_{i,j}=s_j{p}_{i,j}$$

(3)

3.1.4. Cost Function

The cost function of the requesting vehicle $v_i$ can be is denoted as

$$U_i\left(p_{i,j}\right)={\lambda }_i{E}_{i,j}+{\phi }_i{M}_{i,j}$$

(4)

The total cost of the requesting vehicle $v_i$ consists of two terms in Equation (4). The first term is the energy consumption of requesting vehicle $v_i$ and the second term is the fee paid to the MEC server $c_j$. The parameter $s_j$ is the resource pricing of MEC server $c_j$. The parameters ${\lambda }_i$ and ${\phi }_i$ are the energy consumption decision weight and the payment cost decision weight, constrained by ${\lambda }_i+{\phi }_i=1$ [14]. When the requesting vehicle is concerned with its own energy consumption, the parameter ${\lambda }_i$ is set to a larger value and the parameter ${\phi }_i$ is set to a smaller value. Conversely, when the vehicle is concerned with the computation offloading, ${\phi }_i$ will set to a larger value and ${\lambda }_i$ is set to a smaller value.

To facilitate the subsequent work, we insert Equations (2) and (3) into Equation (4) and expand them to obtain a more detailed description of the cost function, which is

$$U_i\left(p_{i,j}\right)={\lambda }_i\left(k_i{f}_i^2\left(w_i-R_{i,j}{t}_i{X}_i\right)+p_{i,j}{t}_i\right)+{\phi }_i{s}_j{p}_{i,j}$$

(5)

3.2. MEC Server Model

3.2.1. Consensus Model

Considering the fact of the POW mechanism that nodes operates an irreversible hash function to derive the solution of the hash value of a particular block by a large number of calculations, it incurs excessive waste of resources in the blockchain network [26]. We thus choose the PoS consensus mechanism with low energy consumption to implement the blockchain network [27]. Without loss of generality, the choice of a block producer (MEC server) for a new block depends on the number of its “shares”. If the block is successfully added to the blockchain, the selected MEC server will be rewarded. Conversely, if the block producer has fraudulent transactions or blocking, it will lose future equity and rights to participate in the consensus process. To motivate MEC servers to provide computing services with the requesting vehicles, we calculate the “shares” of each MEC server by the service benefit it received in the most recent period. Thus, the probability of selecting a server as a block producer in the next period is determined by the ratio of its service reward to the total service reward of other servers in the current period, denoted as

$$P_j=\frac{S_j}{{{\displaystyle \sum }}_{k=1,k\ne j}^m{S}_k}$$

(6)

3.2.2. Block Reward Model

The blockchain nodes involved in block generation and consensus can all obtain certain rewards from the blockchain, which are the rewards $R_v$ for generating blocks and the rewards $R_c$ for verifying blocks, respectively. Since only one blockchain node can be elected as the block generator for each block, we are able to estimate the block generation probability of each blockchain node according to Equation (6). Accordingly, the reward expectation of MEC server $c_j$ as a blockchain node is denoted,

$$P_j{R}_v+\left(1-P_j\right)R_c$$

(7)

where $\left(1-P_j\right)R_c$ indicates that nodes fails to elect as the generator, and instead act as the block validator.

3.2.3. Energy Consumption Model

The total energy consumption generated by the MEC server $c_j$ in the process of providing computing services to the requesting vehicles in its communication range can be expressed as

$$E_j=\xi K_j{F}_j^2{{\displaystyle \sum }}_{i=1}^{n_j}{R}_{i,j}{t}_i{X}_i$$

(8)

where $\xi$ is the weight to balance the energy consumption and the service benefit, $K_j$ is the energy coefficient, and $F_j$ is the CPU computing capability of the MEC server $c_j$. ${{\displaystyle \sum }}_{i=1}^{n_j}{R}_{i,j}{t}_i{X}_i$ represents the total workloads from all requesting vehicles.

3.2.4. Utility Function

The utility function of the MEC server $c_j$ can be expressed as

$$U_j\left(s_j\right)={{\displaystyle \sum }}_{i=1}^{n_j}{s}_j{p}_{i,j}+P_j{R}_v+\left(1-P_j\right)R_c-\xi K_j{F}_j^2{{\displaystyle \sum }}_{i=1}^{n_j}{R}_{i,j}{t}_i{X}_i$$

(9)

${{\displaystyle \sum }}_{i=1}^{n_j}{s}_j{p}_{i,j}$ is the service benefit of providing computing resources to all of requesting vehicles.

4. Stackelberg Game Analysis

4.1. Description of the Problem

In the system model, a conflict of interest exists between the MEC server and the requesting vehicles. Participants will choose their own best strategies to maximize their interests. The details are described in the following two subsections.

4.1.1. Cost Minimization for Requesting Vehicles

The cost of requesting vehicles is shown in Equation (5). Each requesting vehicle decides an offloading strategy based on the resource pricing of the MEC server to minimize its cost while satisfying its requirements for QoS. So, the optimal problem of a requesting vehicle is described as

$$p_{i,j}^{*}=arg\underset{p_{i,j}>0}{\min }{U}_i\left(p_{i,j}\right)$$

(10)

4.1.2. Utility Maximization of MEC Servers

Since the offloading strategies of each requesting vehicle is determined on the basis of the MEC server’s resource pricing, the MEC server needs to set a reasonable resource price to increase its revenue and improve its competitiveness in block generation. Correspondingly, the optimal problem of the MEC server is described as

$$s_j^{*}=arg\underset{s_j>0}{\max }{U}_j\left(s_j\right)$$

(11)

4.2. Formulation of Two-Stage Stackelberg Game

Stackelberg game divides the players into leader and follower to model behaviors of the two types of players. Both sides make their decisions in stages. The leader first acts in a stage and then the followers should respond to the leader’s action in the other stage. Specially, the leader initiates a pricing strategy, on which the followers choose their response strategies and then submit their response strategies to the leader. Such strategy-making processes of both sides repeat until achieving Nash equilibrium.

We here build a two-stage Stackelberg game for describing the interactions of resource allocation and pricing among requesting vehicles and its connected MEC server. Equations (10) and (11) jointly formulate such game $\mathbb{G}=\left\{N_j,{\left\{p_{i,j}\right\}}_{i\in N_j},{\left\{U_i\left(p_{i,j}\right)\right\}}_{i\in N_j}\right\}$. The MEC server acts as the leader of requesting vehicles to decide the resource pricing. Requesting vehicles act as the followers to determine their resource allocation strategies. The backward induction is used to analyze such a Stackelberg game. While the requesting vehicle requests computing resources from the MEC server, the MEC server first announces its resource pricing. The requesting vehicle then decides the size of the task to be offloaded to MEC’s server. This process continues until Nash equilibrium reaches. The optimal strategies of leader and followers accord to the Nash equilibrium point [28,29].

Definition 1.

Nash equilibrium in $\mathbb{G}$: Suppose that the optimal strategies of the requesting vehicle $v_i$ and the MEC server $c_j$ are denoted as $\left\{p_{i,j}^{*},s_j^{*}\right\}$. Let ${\mathit{p}}_j^{*}=\left(p_{1,j}^{*},\dots ,p_{i,j}^{*},\dots ,p_{n_j,j}^{*}\right)$ represent the optimal strategy vector of requesting vehicles connecting to MEC server $c_j$. Nash equilibrium implies that neither the leader nor the follower can further increase their gains by unilaterally changing the strategy. Therefore, requesting vehicle and MEC server’s strategies always satisfy

$$U_i\left(p_{i,j}^{*},{\mathit{p}}_{-i,j}^{*},s_j^{*}\right)\le U_i\left(p_{i,j},{\mathit{p}}_{-i,j}^{*},s_j^{*}\right)$$

(12)

$$U_j\left(p_{i,j}^{*},s_j^{*}\right)\ge U_j\left(p_{i,j}^{*},s_j\right)$$

(13)

where ${\mathit{p}}_{-i, j}^{*}=\left(p_{1, j}^{*},\dots ,p_{i-1, j}^{*},p_{i+1, j}^{*},\dots ,p_{n_j, j}^{*}\right)$ is the optimal strategy vector of requesting vehicles except vehicle $v_i$.

4.2.1. Vehicle-Level Game Analysis

To efficiently complete the local computing tasks and minimize its energy consumption, the requesting vehicle decides how many computing tasks are offloaded to the MEC server based on its energy reserves and the MEC server’s resource pricing. In this section, we explore the optimal strategy for a requesting vehicle $v_i$. Substituting (1) into (5), the cost function is rewritten as

$$U_i\left(p_{i,j}\right)={\lambda }_i\left(k_i{f}_i^2\left(w_i-b_{i,j}{\log }_2\left(1+\frac{p_{i,j}{h}_{i,j}}{{\sigma }_{i,j}^2}\right)t_i{X}_i\right)+p_{i,j}{t}_i\right)+{\phi }_i{s}_j{p}_{i,j}$$

(14)

Ultimately, the cost function $U_i\left(p_{i,j}\right)$ of the requesting vehicle $v_i$ with respect to $p_{i,j}$ can be obtained,

$$U_i\left(p_{i,j}\right)={\lambda }_i{k}_i{f}_i^2{w}_i-{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{\log }_2\left(1+\frac{p_{i,j}{h}_{i,j}}{{\sigma }_{i,j}^2}\right)t_i{X}_i+{\lambda }_i{p}_{i,j}{t}_i+{\phi }_i{s}_j{p}_{i,j}$$

(15)

Then, we calculate the first derivative of $U_i\left(p_{i,j}\right)$ with respect to $p_{i,j}$,

$$\frac{\partial U_i\left(p_{i,j}\right)}{\partial p_{i,j}}=-\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i{h}_{i,j}}{\left({\sigma }_{i,j}^2+p_{i,j}{h}_{i,j}\right)\ln 2}+{\lambda }_i{t}_i+{\phi }_i{s}_j$$

(16)

Based on (16), the second derivative of $U_i\left(p_{i,j}\right)$ is obtained,

$$\frac{{\partial }^2{U}_i\left(p_{i,j}\right)}{\partial p_{i,j}^2}=\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i{h}_{i,j}^2}{{\left({\sigma }_{i,j}^2+p_{i,j}{h}_{i,j}\right)}^2\ln 2}$$

(17)

It is obviously find that $\frac{{\partial }^2{U}_i\left(p_{i,j}\right)}{\partial p_{i,j}^2}$ is always positive. Thus the cost function $U_i$ is strictly convex, which implies the uniqueness of optimal solution $p_{i,j}^{*}$. Let Equation (16) be equal to 0,

$$\frac{\partial U_i\left(p_{i,j}\right)}{\partial p_{i,j}}=-\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i{h}_{i,j}}{\left({\sigma }_{i,j}^2+p_{i,j}{h}_{i,j}\right)\ln 2}+{\lambda }_i{t}_i+{\phi }_i{s}_j=0$$

(18)

By solving (18), we obtain the optimal strategy of requesting vehicle $v_i$ as

$$p_{i,j}^{*}=\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i}{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)\ln 2}-\frac{{\sigma }_{i,j}^2}{h_{i,j}}$$

(19)

4.2.2. Server-Level Game Analysis

In order to rationally allocate the computational resources it holds and maximize its service revenue, the MEC server needs to adjust its resource pricing based on the amount of computational resources requested by the current requesting vehicle. In this subsection, we will explore the optimal strategy of the MEC server.

Based on the service benefit ${{\displaystyle \sum }}_{i=1}^{n_j}{s}_j{p}_{i,j}$ of the MEC server $c_j$, the probability of successfully selecting $c_j$ as a block generator is rewritten as

$$P_j=\frac{{{\displaystyle \sum }}_{i=1}^{n_j}{s}_j{p}_{i,j}}{{{\displaystyle \sum }}_{k=1,k\ne j}^m{{\displaystyle \sum }}_{i=1}^{n_k}{s}_k{p}_{i,k}}$$

(20)

Therefore, the utility function of the MEC server $c_j$ with POS mechanism is denoted as

$$\begin{array}{c}{U}_j\left(s_j\right)={{\displaystyle \sum }}_{i=1}^{n_j}{s}_j{p}_{i,j}+\frac{{{\displaystyle \sum }}_{i=1}^{n_j}{s}_j{p}_{i,j}}{{{\displaystyle \sum }}_{k=1,k\ne j}^m{{\displaystyle \sum }}_{i=1}^{n_k}{s}_k{p}_{i,k}}{R}_v+\left(1-\frac{{{\displaystyle \sum }}_{i=1}^{n_j}{s}_j{p}_{i,j}}{{{\displaystyle \sum }}_{k=1,k\ne j}^m{{\displaystyle \sum }}_{i=1}^{n_k}{s}_k{p}_{i,k}}\right)R_c\\ -\xi K_j{F}_j^2{{\displaystyle \sum }}_{i=1}^{n_j}{b}_{i,j}{\log }_2\left(1+\frac{p_{i,j}{h}_{i,j}}{{\sigma }_{i,j}^2}\right)t_i{X}_i\end{array}$$

(21)

Substituting $p_{i,j}^{*}$ into Equation (21), the utility function in (21) is rewritten as

$$\begin{array}{c}{U}_j\left(s_j\right)=\left(1+\frac{\left(R_v-R_c\right)}{{{\displaystyle \sum }}_{k=1,k\ne j}^m{{\displaystyle \sum }}_{i=1}^{n_k}{s}_k{p}_{i,k}}\right){{\displaystyle \sum }}_{i=1}^{n_j}{s}_j\left(\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i}{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)\ln 2}-\frac{{\sigma }_{i,j}^2}{h_{i,j}}\right)+R_c\\ -\xi K_j{F}_j^2{{\displaystyle \sum }}_{i=1}^{n_j}{b}_{i,j}{\log }_2\left(1+\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i{h}_{i,j}}{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right){\sigma }_{i,j}^2\ln 2}\right)t_i{X}_i\end{array}$$

(22)

We calculate the first derivative of $U_j\left(s_j\right)$ on $s_j$,

$$\begin{array}{cc}\hfill \frac{\partial U_j\left(s_j\right)}{\partial s_j}=(1+& \left.\frac{\left(R_v-R_c\right)}{{\sum }_{k=1,k\ne j}^m{\sum }_{i=1}^{n_k}{s}_k{p}_{i,k}}\right){\sum }_{i=1}^{n_j}\left(\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i}{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)ln2}-\frac{{\sigma }_{i,j}^2}{h_{i,j}}-s_j\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i{\phi }_i}{{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)}^{2}ln2}\right)\hfill \\ & +\xi K_j{F}_j^2{\sum }_{i=1}^{n_j}\frac{b_{i,j}{t}_i{X}_i{\phi }_i}{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)ln2}\hfill \end{array}$$

(23)

Moreover, the second derivative of $U_j\left(s_j\right)$ on $s_j$ is calculated as,

$$\frac{{\partial }^2{U}_j\left(s_j\right)}{\partial s_j^2}=-\left(1+\frac{\left(R_v-R_c\right)}{{{\displaystyle \sum }}_{k=1,k\ne j}^m{{\displaystyle \sum }}_{i=1}^{n_k}{s}_k{p}_{i,k}}\right){{\displaystyle \sum }}_{i=1}^{n_j}\left(\frac{2{\lambda }_i^2{k}_i{f}_i^2{b}_{i,j}{t}_i^2{X}_i{\phi }_i}{{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)}^3\ln 2}\right)-\xi K_j{F}_j^2{{\displaystyle \sum }}_{i=1}^{n_j}\frac{b_{i,j}{t}_i{X}_i{\phi }_i^2}{{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)}^2\ln 2}$$

(24)

Based on Equation (24), the second derivative of $U_j\left(s_j\right)$ is obviously negative. So, the utility function $U_j$ is strictly concave. Since the concave function has a unique global optimal solution, the equilibrium point of the game is $s_j^{*}$. In order to obtain the optimal strategy for the MEC server $c_j$, it is necessary to find the solution of the following equation,

$$\begin{array}{cc}\hfill \frac{\partial U_j\left(s_j\right)}{\partial s_j}=(1+& \left.\frac{\left(R_v-R_c\right)}{{\sum }_{k=1,k\ne j}^m{\sum }_{i=1}^{n_k}{s}_k{p}_{i,k}}\right){\sum }_{i=1}^{n_j}\left(\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i}{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)ln2}-\frac{{\sigma }_{i,j}^2}{h_{i,j}}-s_j\frac{{\lambda }_i{k}_i{f}_i^2{b}_{i,j}{t}_i{X}_i{\phi }_i}{{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)}^{2}ln2}\right)\hfill \\ & +\xi K_j{F}_j^2{\sum }_{i=1}^{n_k}\frac{b_{i,j}{t}_i{X}_i{\phi }_i}{\left({\lambda }_i{t}_i+{\phi }_i{s}_j\right)ln2}=0\hfill \end{array}$$

(25)

We see that $s_j^{*}$ and $p_{i,j}^{*}$ are the optimal strategies of the MEC server and the requesting vehicle, respectively. The Equations (16) and (23) guarantee the unique Nash equilibrium. It is feasible for each requesting vehicle to obtain its optimal strategy according to (19). However, because of the non-linearity of (25), it is difficult to directly obtain the optimal solution $s_j^{*}$. Instead, we employ the gradient descent method to iteratively approximate the optimal solution $s_j^{*}$ [30,31,32,33].

5. Simulation Experiments

In this paper, simulation experiments are conducted using python to evaluate our proposed scheme. We begin with the parameter setting and then display the numerical simulation results for illustration.

5.1. Parameter Setting

In this simulation scenario, 10 MEC servers are deployed in the system. Each server covers 60–100 requesting vehicles, and the delay tolerance interval for offloading tasks is 0.7–0.9 ms. The bandwidth of each subchannel is 5 MHz, the noise power of the subchannel is 60 dB, and the channel gain on the subchannel is 54–57 dBm. The resource pricing of the server is subject to 0.4–1.0. The weights ${\lambda }_i$ and ${\phi }_i$ are randomly generated, respectively, and their sum is 1. The main parameters we used in the simulation are shown in

Table 2. The simulation parameters. $m$ is the number of MEC servers, $n_j$ is the number of requesting vehicles covered by the jth server, $b_{i,j}$, $h_{i,j}$ and ${\sigma }_{ij}$ are used to describe the current wireless channel environment, $t_i$ is the time delay tolerated by the vehicle $v_i$, ${\lambda }_i$ and ${\phi }_i$ are the weight parameters used to balance the energy consumption and resource cost of the requesting vehicles, and $\xi$ is the weight parameter for the energy consumption of the MEC servers.

Parameter	Value	Parameter	Value
$m$	10	$t_i$	0.7–0.9 ms
$n_j$	60–100	${\lambda }_i$	0.5–0.65
$b_{i,j}$	5 MHz	${\phi }_i$	0.35–0.5
$h_{i,j}$	54–57 dBm	$\xi$	0.02
${\sigma }_{ij}$	60 dB

.

5.2. Analysis of Results

We use the gradient descent method to find the optimal strategy for the MEC servers. Figure 2a shows how to find the optimal resource pricing in the algorithm. Each MEC server decides the resource pricing based on its current network environment and the number of requesting vehicles. As the number of iterations increases, the prices set by MEC servers gradually approximate their own optimal strategies. It is seen from Figure 2a that the proposed algorithm converges to the optimal value. It indicates that each MEC server is able to find its optimal resource pricing for maximizing its revenue.

We next observe the effect of the number of requesting vehicles on the server’s utility. Figure 2b shows that the average effect of all servers increases with the increase in requests for vehicles. Besides, with the increasing energy consumption of requesting vehicles, it has more significant influence on the MEC server utility becomes more pronounced.

We are also exploring the effect of the MEC server’s resource price on its utility. Figure 2c shows the simulation results. It is found that the utility of the MEC server starts increasing while the resource price improves. However, its benefit then decrease as the resource price increases, exceeding the optimal strategy point of the Stackelberg game.

Lastly, we investigate the effect of the MEC server’s resource pricing on the transmit power of the requesting vehicle. The results are shown in Figure 2d. While the resource price gradually increases, the requested transmit power decreases. It indicates that a high resource price incurs a low computing resource allocation. As users attach importance to energy consumption, more computing tasks would be offloaded to the MEC server. Such behavior is aimed to reduce its own energy consumption.

6. Conclusions

To improve the resource utilization and security of the MEC network, this paper combines the MEC network with the blockchain network to propose a task offloading system. Especially, the PoS mechanism in the blockchain network is employed to ensure the data’s safety in the MEC network. The offloading interactions between MEC servers and requesting vehicles formulate a two-stage Stackelberg game to find their optimal strategies for revenue maximization. We also prove to achieve Nash equilibrium, which indicates the uniqueness of optimal strategies for MEC servers and requesting vehicles. The performance of our proposed system model is discussed by analyzing the variable factors in simulation experiments. Such system is built to assist MEC servers with their computation resource management. In the future work, we will furthermore explore the dynamic the computation offloading in the blockchain-based MEC network.