Computation Offloading Strategy Based on Improved Polar Lights Optimization Algorithm and Blockchain in Internet of Vehicles

Abstract

The rapid growth of computationally intensive tasks in the Internet of Vehicles (IoV) poses a triple challenge to the efficiency, security, and stability of Mobile Edge Computing (MEC). Aiming at the problems that traditional optimization algorithms tend to fall into, where local optimum in task offloading and edge computing nodes are exposed to the risk of data tampering, this paper proposes a secure offloading strategy that integrates the Improved Polar Lights Optimization algorithm (IPLO) and blockchain. First, the truncation operation when a particle crosses the boundary is improved to dynamic rebound by introducing a rebound boundary processing mechanism, which enhances the global search capability of the algorithm; second, the blockchain framework based on the Delegated Byzantine Fault Tolerance (dBFT) consensus is designed to ensure data tampering and cross-node trustworthy sharing in the offloading process. Simulation results show that the strategy significantly reduces the average task processing latency (64.4%), the average system energy consumption (71.1%), and the average system overhead (75.2%), and at the same time effectively extends the vehicle’s power range, improves the real-time performance of the emergency accident warning and dynamic path planning, and significantly reduces the cost of edge computing usage for small and medium-sized fleets, providing an efficient, secure, and stable collaborative computing solution for IoV.

1. Introduction

With the rapid development of automotive technology, the Internet of Vehicles (IoV), as a core component of intelligent transportation systems, is gradually changing people’s travel and traffic management modes with the aim to build an efficient, intelligent, and safe transportation ecosystem through the interconnectivity between vehicles and vehicles (V2V), vehicles and infrastructure (V2I), and vehicles and pedestrians (V2P) [1].

In IoV environments, vehicles are equipped with sensors and computing devices that generate large amounts of data and require complex computational task processing. However, the vehicles’ own computational resources are often relatively limited to meet the demands of these increasing tasks [2]. Mobile Edge Computing (MEC) [3], as an innovative technology, shows unique advantages in IoV scenarios. It enables vehicles to offload computing-intensive and latency-sensitive tasks to edge nodes for processing by deploying computing resources at base stations or local servers close to the vehicles. This not only effectively alleviates the dilemma of limited computing resources in the vehicle itself but also significantly reduces data transmission latency and energy consumption. However, in the complex and dynamically changing environment of IoVs, computation offloading faces many challenges. On the one hand, the high-speed mobility of vehicles leads to unstable network connections between them and edge servers, and frequent switching and fluctuations in channel quality make computation offloading decisions extremely difficult. On the other hand, since it involves the transmission of sensitive information and critical data of vehicles, it is also crucial to prevent data leakage, tampering, and malicious attacks.

To solve complex computational offloading decision optimization problems, traditional heuristic algorithms have been widely used in IoV; for example, Genetic Algorithm (GA) [4] and Ant Colony Optimization (ACO) [5] and its derivatives [6]. These algorithms search for a better computation offloading strategy through specific heuristic rules in a complex solution space to achieve optimization of task scheduling and resource allocation. However, these traditional algorithms often suffer from the defects of slow convergence and easily fall into local optimal solutions. In this regard, the literature [7] proposes an improved Artificial Bee Colony Algorithm (MGABC), which improves the problems of slow convergence and susceptibility to premature convergence in complex optimization problems. The literature [8] proposes a novel hybrid differential evolutionary algorithm with adaptive variance factors and crossover rates designed to balance the global and local search capabilities of the algorithm. While improved algorithms are being proposed, the development of MEC continues to accelerate. The literature [9] proposes an auxiliary architecture for the collaboration of MEC layer and cloud layer, which achieves complementary resource utilization, reduces service latency, and improves resource utilization through task migration mechanism. The literature [10] proposes a Vehicle Fog Edge Computing (VFEC) network architecture, which realizes the cooperation between the computing resources in the MEC layer and the idle resources of the vehicles in the fog layer and improves the system performance.

Blockchain technology, with its unique features of decentralization, non-tampering, and traceability, provides a potential solution to the security and trust issues in the IoV computing offloading process [11]. By constructing a distributed ledger structure, blockchain is able to record all the transaction information in the computation offloading process, realize the trusted interaction between vehicles and servers, and enhance the security of the whole system. In this regard, the literature [12] proposes a trust management system to address the reliability of vehicle messages in the Internet of Vehicles, using a specific consensus mechanism and smart contracts to effectively improve the accuracy of the vehicle’s judgment of events. The literature [13] proposes a roadside-unit-assisted authentication and key negotiation protocol, adopting a trusted organization network model, using blockchain to manage the vehicle information ledger, realizing cross-organization authentication, and moving the computational load to the roadside unit to improve efficiency. The literature [14] proposes a secure event information sharing protocol, which solves the single point of failure that exists in traditional IoV systems by designing a consensus mechanism and a smart contract to ensure that the information is not tampered with and securely shared. The literature [15] proposes a vehicle data sharing scheme based on federated blockchain, designs an enhanced delegated proof-of-interest consensus algorithm to balance security and efficiency, and introduces a trust score model to improve the reliability of data.

Although computational offloading and blockchain have been converged and achieved some milestones in IoV scenarios, the existing convergence schemes still have obvious deficiencies: on the one hand, there is still much room for improvement in reducing key performance indicators such as system latency, energy consumption, and overhead; on the other hand, the existing solutions do not guarantee system stability under dynamic changes in network topology, making it difficult to adapt to the demand for reliable services in the high-speed mobile environment of Telematics. These limitations seriously restrict the practical application of converged solutions in complex Telematics scenarios. In order to solve these problems, we propose a dynamic adaptive edge computing offloading architecture for Telematics, which deeply integrates a blockchain security mechanism and intelligent optimization algorithm. First, a blockchain-based single-vehicle multi-task computing offloading model is constructed; second, a novel polar lights optimization algorithm is designed for avoiding falling into the local optimum problem, which achieves significant improvement in key indicators such as system delay, energy consumption, overhead, and stability; finally, the blockchain consensus optimization mechanism with authorized Byzantine fault tolerance is used to ensure the security of the data in the transmission process. In summary, the core work carried out in this paper is as follows:

• A blockchain-based multi-vehicle multi-task computational offloading model for mobile scenarios is established that can accurately map the task computational demand, offloading the logic and blockchain consensus process generated by vehicles in the process of dynamic mobility;
• A new polar lights optimization algorithm is adopted to optimize the computational offloading strategy, which accelerates the convergence speed while reducing the risk of falling into the local optimal solution and is significantly better than the traditional optimization methods;
• An authorized Byzantine fault-tolerant consensus mechanism is adopted to dynamically select consensus nodes through stake vote election, which ensures transactions are tamperable;
• The impact of task load, number of vehicles, and data volume on system performance under different offloading strategies is demonstrated in simulation experiments, which verifies the stability of the proposed strategies in dynamic IoV environments and confirms the effectiveness of the strategies proposed in this paper.

2. System Model

2.1. Network Model

As shown in Figure 1, the network model in this paper consists of vehicles, roadside units (RSUs), edge servers, and blockchain network. Each RSU can act as a relay node to realize the information interaction between vehicles and edge servers within its communication coverage. The roadside has RSUs at equal distances, and an MEC server is deployed in each RSU, which are connected by fiber-optic wired links. The set of vehicles is defined as $m=\{\mathrm{1,2},\cdots ,m\}$. The set of RSUs is defined as $n=\{\mathrm{1,2},\cdots ,n\}$. Within the blockchain system, all RSUs constitute blockchain nodes, which can be divided into two categories. One category is ordinary nodes, which only undertake transmission and reception and do not participate in the consensus process; the other category is consensus nodes elected by virtue of voting, and such nodes are responsible for generating new blocks and implementing the consensus process. When the vehicle generates computationally intensive and delay-sensitive tasks to be processed, the system determines the offloading decision based on energy consumption, delay, and overhead. If the task is assigned to be processed locally, the vehicle will rely on its own computational resources to perform the computation, and after the end of the computation, the results will be transmitted to the RSU for on-chain storage and sharing; if the task is assigned to be processed by the MEC server, the computation results will be fed back to the RSU to realize on-chain storage and data sharing between the RSUs. Therefore, regardless of whether the task is offloaded to the local computing or edge server, the calculation results will not be tampered with, and safe and reliable data sharing between RSUs can be realized.

2.2. Mission Model

The tasks for vehicle generation follow the Poisson distribution law [16], and each vehicle has multiple computing tasks $P=\{D_m,C_m,T_m^{max},T_{cons}^{max}\}$, where $D_m$ is the data size of the task, $C_m$ is the CPU cycles required for the task, $T_m^{max}$ is the maximum delay tolerated for task completion, and $T_{cons}^{max}$ is the maximum time tolerated by the blockchain consensus process.

2.3. Communications Model

The vehicle offloads the computation task to the MEC server via RSU, and the server computes the results and then feeds them back to the vehicle via RSU. This process ignores channel interference [17]. According to the Shannon formula, the rate at which the vehicle transmits data to the RSU is defined as:

$$R_m=B_m{\mathit{log}}_2(1+{\displaystyle \frac{L_m{P}_m}{B_0}})$$

(1)

where, $B_m$ denotes the subchannel bandwidth between the vehicle and the MEC server, $L_m$ denotes the channel gain between the vehicle and the RSU, $P_m$ denotes the vehicle’s transmitter power, and $B_0$ denotes the power of the Gaussian channel white noise.

2.4. Computational Model

(1)

Local Computing

When a vehicle performs a computational task locally, the delay and energy consumption of the computation depend on the vehicle’s own computational capability, which is determined by the on-board unit (OBU, on board unit) [18] placed on the vehicle. Therefore, the energy consumption and latency of the task computed locally are, respectively:

$$E_m^{LOC}=\delta {\left(f_m^{LOC}\right)}^2{C}_m$$

(2)

$$T_m^{LOC}={\displaystyle \frac{C_m}{f_m^{LOC}}}$$

(3)

where $f_m^{LOC}$ denotes the computing power of vehicle $m$, $\delta {\left(f_m^{LOC}\right)}^2$ denotes the power consumed by the core computing of each vehicle, and $\delta$ denotes the effective open capacitance factor of the corresponding chip structure of the vehicle [19].

(2)

Edge Server Computing

When a vehicle performs a computationally intensive and delay-sensitive task and uses an edge server to process it, the delay and energy consumption of the results fed back to the vehicle are negligible because the size of the output data after computation at the edge server is much smaller than the size of the input data [20]. Therefore, the energy consumption and latency of the task computed at the edge server are:

$$E_m^{MEC}={\displaystyle \frac{D_m{P}_m}{R_m}}$$

(4)

$$T_m^{MEC}=T_m^{up}+T_m^{count}$$

(5)

where $R_m$ denotes the wireless transmission rate between the task vehicle and the edge server, and $T_m^{up}$ and $T_m^{count}$ denote the transmission delay of the task vehicle and the edge server and the processing delay of the task in the edge server, respectively, defined as:

$$T_m^{up}={\displaystyle \frac{D_m}{R_m}}$$

(6)

$$T_m^{count}={\displaystyle \frac{C_m}{f_m^{MEC}}}$$

(7)

2.5. Vehicle Mobility Model

The vehicle is traveling at a constant speed with speed $v$. To prevent the problem of interrupted task transmission due to RSU switching, the task should be completed within the range belonging to the current RSU as much as possible. Assuming that the vehicle is within the coverage range of the RSU, the expected dwell time [21] of the vehicle in this range is:

$$T_m^{stop}={\displaystyle \frac{R+r}{v}}$$

(8)

where $R$ is the radius of communication coverage of RSUs and $r$ is the horizontal distance between the vehicle and the RSU, denoted as:

$$\mathrm{r}=\left\{\begin{array}{c}-v\times t_m+R,t_m<{\displaystyle \frac{R}{v}}\\ v\times t_m-R,t_m\ge {\displaystyle \frac{R}{v}}\end{array}\right.$$

(9)

2.6. Blockchain Model

As shown in Figure 2, the Delegated Byzantine Fault Tolerance algorithm (dBFT) [22] is used as the consensus mechanism in this paper, which is mainly responsible for the distributed verification of the task scheduling scheme generated by the optimization algorithm, to ensure the credibility and consistency of scheduling decisions. In the selection of consensus nodes, voting is based on shares to determine the nodes participating in the next round of consensus, which can quickly reach consensus and tolerate a certain percentage of malicious nodes. In the consensus process, the number of consensus nodes is assumed to be $K\ge (3f+1)$ ($f$ is the maximum number of malicious nodes that can be tolerated), the master node (moderator) is responsible for broadcasting the new block, and the deputy nodes (participants) are responsible for voting on the new block. When the number of malicious nodes is less than $f$, the view switching mechanism can re-elect the master node even if there is a network outage to ensure that the consensus is finally reached and no error blocks are generated. However, if the number of malicious nodes exceeds $f$, the system will trigger the dynamic member group adjustment mechanism to restore system activity and security by adding or subtracting nodes [23]. Define $S_k$ as the size of a block and $S_p$ as the average size of a transaction. The consensus process is divided into four phases: preparation request, preparation reply, submission, and broadcast, where each consensus phase generates energy consumption and latency [24].

(1)

Preparation request:

The moderator will pull transactions from the memory pool to build a new block and then send a ready request message to the participants, thus starting a new consensus round. In this phase, the moderator generates one signature and $K-1$ message authentication codes (MACs). It is assumed that it takes $\alpha$ and $\beta$ central processing unit (CPU) cycles to generate and verify a signature and MAC, respectively. Therefore, the CPU cycles required by the moderator are denoted as:

$$C_n^{pr}=(K-1)\beta +\alpha$$

(10)

The energy consumption and latency generated in the preparation request phase are, respectively:

$$E_n^{pr}=P_{cons}{T}_n^{pr}$$

(11)

$$T_n^{pr}={\displaystyle \frac{C_n^{pr}}{f_{cons}}}$$

(12)

where$f_{cons}$ denotes the average computational power of the node and $P_{cons}$ denotes the average transmission power of the node.

(2)

Preparation reply:

The moderator receives the ready request message and verifies it. If the verification passes, it sends the ready reply message to all the consensus nodes. In this phase, the participant needs to verify the signature and MAC in the new block and then generate one signature with $K-1$ MACs for reply. Therefore, the CPU cycle required by the participant is denoted as:

$$C_n^{ps}=\alpha +\beta +{\displaystyle \frac{S_k(\alpha +\beta )}{S_p}}+\alpha +(K-1)\beta$$

(13)

The energy consumption and latency generated in the preparation reply phase are, respectively:

$$E_n^{ps}=\sum _1^k{P}_{cons}{T}_n^{ps}$$

(14)

$$T_n^{ps}={\displaystyle \frac{C_n^{ps}}{f_{cons}}}$$

(15)

(3)

Submission:

The consensus node starts verifying the legitimacy of each message if it obtains not less than $K-f$ other nodes’ ready replies and broadcasts them after passing the verification. In this phase, the consensus node has to verify $K-f$ signatures and MACs and generate one signature with $K-1$ MACs as a submit message. Therefore, the CPU cycle required by the consensus node is denoted as:

$$C_n^{com}=(K-f)(\alpha +\beta )+\alpha +(K-1)\beta$$

(16)

The energy consumption and latency generated in the submission phase are, respectively:

$$E_n^{com}=\sum _1^k{P}_{cons}{T}_n^{com}$$

(17)

$$T_n^{com}={\displaystyle \frac{C_n^{com}}{f_{cons}}}$$

(18)

(4)

Broadcast:

The consensus node broadcasts to all nodes if it obtains no less than $K-f$ submissions and verifies them. In this phase, the consensus node has to verify $K-f$ signatures and MACs. Therefore, the CPU cycles required by the consensus node are denoted as:

$$C_n^{bro}=(K-f)(\alpha +\beta )$$

(19)

The energy consumption and latency generated in the broadcast phase are, respectively:

$$E_n^{bro}=\sum _1^k{P}_{cons}{T}_n^{bro}$$

(20)

$$T_n^{bro}={\displaystyle \frac{f_n^{bro}}{f_{cons}}}$$

(21)

To summarize, the energy consumption and latency generated in the consensus process are:

$$E_n^{CONS}=E_n^{pr}+E_n^{ps}+E_n^{com}+E_n^{bro}$$

(22)

$$T_n^{CONS}=T_n^{pr}+T_n^{ps}+T_n^{com}+T_n^{bro}$$

(23)

2.7. Joint Optimization Problems

The task is determined, whether it is processed locally or offloaded to the MEC server for processing, by the offloading decision variable $\lambda$. When $\lambda =0$, it means that the task is computed locally, and when $\lambda =1$, it means that the task is offloaded to the MEC server for computation. Thus, for the offloading task of vehicle $m$, the total energy consumption incurred by the system is $E\left(m\right)=(1-\lambda )E_m^{LOC}+\lambda E_m^{MEC}+E_n^{CONS}$, and the total delay is $T\left(m\right)=(1-\lambda )T_m^{LOC}+\lambda E_m^{MEC}+T_n^{CONS}$.

In this paper, the minimum weighted sum of the energy consumption and delay incurred by joint task offloading and blockchain consensus is used as an optimization problem with the aim of minimizing the system overhead. The problem model is expressed as:

$$O\left(m\right)=\eta E\left(m\right)+\gamma T\left(m\right)$$

(24)

$$s.t.\left\{\begin{array}{c}{C}_1:\lambda \in \left\{0.1\right\}\\ C_2:T_m^{up}\le T_m^{stop}\\ C_3:S_k<S_p\\ C_4:T_m^{LOC}+T_m^{MEC}+T_n^{CONS}\le T_m^{max}\\ C_5:T_n^{CONS}\le T_{cons}^{max}\end{array}\right.$$

(25)

where $\eta$ and $\gamma$ denote the coefficients weighing energy consumption and delay, where $0\le \eta \le 1$, $0\le \gamma \le 1$, and $\eta +\gamma =1$. In practical applications, the selection of the weighing factors needs to be determined in the context of specific scenarios and requirements [25]. $C_1$ indicates that the vehicle can only choose one offloading decision: local offloading or MEC server offloading; $C_2$ indicates that it is ensured that the vehicle completes the offloading task before driving away from the coverage area of the RSUs; $C_3$ indicates that the size of the block has to be larger than the size of the total transaction, thereby ensuring that only one consensus process exists; $C_4$ means that the total delay in processing the offloading task must not exceed the maximum tolerable delay of the system; and $C_5$ means that the blockchain consensus process has to be completed within a specified time.

3. Computation Offloading Strategy Based on Improved Polar Lights Optimization Algorithm

3.1. Improved Polar Lights Optimization

Polar Lights Optimization Algorithm (PLO) is a meta-heuristic algorithm. The algorithm proposes a unique optimization strategy by simulating the trajectories and behaviors of energetic particles during the formation of aurora borealis [26]. However, the original algorithm may lose diversity by directly truncating the solution during boundary processing, which affects the global search ability of the algorithm. For this reason, this paper proposes an Improved Polar Lights Optimization algorithm (IPLO) that innovatively introduces the Bounce Boundary Handling Mechanism [27] to enhance the algorithm’s searching ability in the boundary region of the solution space, which no longer directly fixes the particles at the boundary value when their positions are beyond the boundary of the solution space but instead adjusts the direction of their motion through the Bounce mechanism. The three main forms of motion include gyration motion, aurora oval walk, and particle collision. As shown in Figure 3, the exploration of the problem space and the search for the optimal solution can be realized through these three kinds of motions.

3.2. Algorithm Design

(1)

Initializing the Population

In IPLO, a random initialization method is used to initialize the population, which is presented in the form of a matrix with the specification of N rows and D columns. By randomly generating a set of initial solutions in a given solution space based on the principle of uniform distribution, the algorithm is able to cover different potentially high-quality regions at the beginning and avoid prematurely falling into localized patterns. Thus, the method of initializing the population is denoted as:

$$X_{N,D}=rand\times (ub-lb)+lb=\left[\begin{array}{ccc}\begin{array}{c}\begin{array}{cc}{X}_{\mathrm{1,1}}& X_{\mathrm{1,2}}\end{array}\\ \begin{array}{cc}{X}_{\mathrm{2,1}}& X_{\mathrm{2,2}}\end{array}\end{array}& \dots & \begin{array}{c}{X}_{1,D}\\ X_{2,D}\end{array}\\ ⋮& \ddots & ⋮\\ \begin{array}{cc}{X}_{N,1}& X_{N,2}\end{array}& \dots & X_{N,D}\end{array}\right]$$

(26)

where $ub$ and $lb$ denote the upper and lower boundaries of the solution space, respectively, and $rand$ denotes a randomly taken value in the range $\left[\mathrm{0,1}\right]$.

(2)

Updating Population Locations

First, two adaptive weights $w_1$ and $w_2$ are precisely calculated to coordinate the global exploration and local exploitation of the algorithm. These two weights are dynamically adjusted with the evaluation process, denoted as:

$$w_1={\displaystyle \frac{2}{(e^{-2{(t/Mt)}^4}+1)}}-1$$

(27)

$$w_2=e^{-{(2t/Mt)}^3}$$

(28)

where the number of initialized adaptation evaluations $t=0$ and $Mt$ denotes the maximum number of evaluations. Then, gyration motion is carried out, denoted as:

$$LS(t)=C{e}^{{\displaystyle \frac{qB-\mu }{m}}\times t}$$

(29)

where the constant $C$ provides the basic physical reference for the motion, $q$ and $m$ represent the charge and mass of the point-bearing particles and affect the rotational momentum and direction, respectively, $B$ serves as an analog of the strength of the Earth’s magnetic field, which introduces an external guiding force for the particle motion, and the damping factor $\mu$ mimics the energy loss in the real environment, which effectively controls the amplitude of the rotation and prevents the convergence of the rotation too quickly. Subsequently, it enters the aurora oval walk phase, denoted as:

$$GS=levy(d)\times (X_{mean}(j)-X(i,j))+lb+{\displaystyle \frac{a_1\times (ub-lb)}{2}}$$

(30)

where $levy\left(d\right)$ is the global search step to guarantee the search efficiency of the algorithm in a large range, $X_{mean}\left(j\right)$ is the center of mass position of the energetic particle population, denoted as $X_{mean}(j)={\displaystyle \frac{\sum _{i=1}^{N}X\left(i\right)}{N}}$, and $a_1$ and $a_2$ are taken as the interference terms produced by the environment and other factors on the particles, which take the value in the interval of $\left[\mathrm{0,1}\right]$. Finally, based on the combined results of the rotational motion and elliptical walk motion, the position changes brought about by the two motions are fused to accurately calculate the final population update position, denoted as:

$$X_{new}(i,j)=X(i,j)+a_2\times (w_1\times LS(t)+w_2\times GS)$$

(31)

(3)

Population Variation

In order to strongly circumvent the dilemma of falling into the local optimum, high-energy particles need to carry out the mutation operation at the right time, in which an element of randomness is injected into the mutation process to ensure the unpredictability of the direction of the mutation, denoted as:

$$X_{new}\left(i,j\right)=X\left(i,j\right)+\sin (a_3\times \pi )\times \left(X\right(i,j)-X(n,j\left)\right)$$

(32)

where $a_3$, $a_4$, and $a_5$ are random values of $\left[\mathrm{0,1}\right]$, $Z=\sqrt{{\displaystyle \frac{t}{Mt}}}$ is the probability of variation, which needs to satisfy $a_4<Z$ and $a_5<0.05$, and $X(n,j)$ serves as an arbitrary particle in the cluster of particles, whose randomness of selected variations further enriches the diversity of the population.

(4)

Bounce Boundary Handling Mechanism

Traditional PLO algorithms usually adopt the truncation method when the particle positions exceed the solution space and directly set the transgression value as the boundary value. Although this method is simple, it may lead to a decrease in population diversity and fall into local optimization. For this reason, this paper uses bounce boundary handling: when the particle position crosses the boundary, the rebound phenomenon in the physical collision is simulated to adjust the position, which is expressed as:

$$X_{new}(i,j)=\left\{\begin{array}{c}2X_{min}\left(j\right)-X_{new}(i,j),X_{new}(i,j)<X_{min}\left(j\right)\\ 2X_{max}\left(j\right)-X_{new}(i,j),X_{new}(i,j)>X_{max}\left(j\right)\\ X_{new}(i,j),otherwise\end{array}\right.$$

(33)

where $X_{min}\left(j\right)$ denotes the lower value of the solution space in the $j$th dimension and $X_{max}\left(j\right)$ denotes the upper value of the solution space in the $j$th dimension.

3.3. The Overall Flow of the Algorithm

In summary, the overall flow of the IPLO algorithm is shown in Algorithm 1.

Algorithm 1. Computation offloading strategy based on IPLO algorithm

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

Input: X Initialize high-energy particle populations X[i](i = 1, 2, 3, ...); Initialize the number of iterations FEs; Initialize the maximum number of iterations MaxFEs; Initialization N, X_new, BestS, BestP, BestTotal; Calculation of adaptation values $\mathit{f}\left(\mathit{x}\right)$; While FEs <= MaxFEs do  Use Equation (27) to calculate ${\mathit{w}}_1$;  Use Equation (28) to calculate ${\mathit{w}}_2$;  For i = 0 to N do   Use Equation (29) to calculate $\mathit{L}\mathit{S}$;   Use Equation (30) to calculate $\mathit{G}\mathit{S}$;   Use Equation (31) to update $\mathit{X}\_\mathit{n}\mathit{e}\mathit{w}$;   If ${\mathit{a}}_4<\mathit{Z}$ and ${\mathit{a}}_5<0.05$ then    Use Equation (32) to update $\mathit{X}\_\mathit{n}\mathit{e}\mathit{w}$;    Use Equation (33) to update $\mathit{X}\_\mathit{n}\mathit{e}\mathit{w}$;   End if    Calculate the fitness value $\mathit{f}(\mathit{X}\_\mathit{n}\mathit{e}\mathit{w})$;    FEs = FEs + 1;  End for  If $\mathit{f}(\mathit{X}\_\mathit{n}\mathit{e}\mathit{w})<\mathit{f}\left(\mathit{X}\right)$ then    $\mathit{B}\mathit{e}\mathit{s}\mathit{t}\mathit{S}=\mathit{f}(\mathit{X}\_\mathit{n}\mathit{e}\mathit{w})$;  End if  Use Equation (22), Equation (23) to calculate BestP;  Calculate BestTotal from the sum of BestS and BestP; End While Output: BestTotal.

4. Simulation Experiments and Data Analysis

4.1. Simulation Parameters

In order to verify the efficiency and stability of the proposed optimization scheme, this paper simplifies the network model and limits the research scope to a small-scale environment; therefore, the following parameter settings are implemented. The setup scenario is a vehicle traveling at a speed $\mathit{v}$ at a uniform speed on a 2000-meter road, and the tasks generated by the vehicle can be randomly adjusted in the range between [20, 100]. An RSU is installed every 400 m along the road. Each RSU is equipped with an Intel Atom x7-E3950 (4-core) CPU, and each RSU is accompanied by an MEC server equipped with an AMD EPYC 9554P (64-core) processor. Five RSUs are set up as nodes in the blockchain, where the nodes participating in the consensus are set up as four. The simulation experiment is repeated for 20 independent trials to eliminate the effect of randomness. Other parameter settings in the simulation environment are shown in

Table 1. Simulation parameters.

Parameters

Numerical

Data size of the task ${\mathit{D}}_{\mathit{m}}$ CPU cycles required for the task ${\mathit{C}}_{\mathit{m}}$ Transmitting power of the vehicle ${\mathit{P}}_{\mathit{m}}$ [28] Computing power of the vehicles ${\mathit{f}}_{\mathit{m}}^{\mathit{L}\mathit{O}\mathit{C}}$ [29] Computing power of the MEC server ${\mathit{f}}_{\mathit{m}}^{\mathit{M}\mathit{E}\mathit{C}}$ [30] Radius of communication coverage of RSUs $\mathit{R}$ [31] Gaussian channel white noise ${\mathit{B}}_0$ [32] Subchannel bandwidth ${\mathit{B}}_{\mathit{m}}$ [33] Weighting of latency $\mathit{\eta }$ Weighting of energy $\mathit{\gamma }$ CPU cycles required for signature $\mathit{\alpha }$ [34] CPU cycles required for MAC $\mathit{\beta }$ [34] Average deal size ${\mathit{S}}_{\mathit{p}}$ [35] Average computing power of RSUs ${\mathit{f}}_{\mathit{c}\mathit{o}\mathit{n}\mathit{s}}$ [36] Average transmission power of RSUs ${\mathit{P}}_{\mathit{c}\mathit{o}\mathit{n}\mathit{s}}$ [37] Number of blockchain nodes $\mathit{n}$ Number of blockchain consensus nodes $\mathit{K}$ Constant speed $\mathit{v}$

[0.5–1.5] MB [1000–2000] Megacycles 46 dBm 2.0 GHz 8.0 GHz 500 m −147 dBm 2 MHz 0.8 0.2 1 Megacycles 10 Megacycles 200 B 3 GHz 1000 mW 6 4 40 Km/s

.

4.2. Analysis of Experimental Results

In order to verify the efficiency of the proposed algorithm, it will be compared with the traditional algorithms from three perspectives: the number of CPU cycles required for (average energy consumption, average delay, and average overhead) tasks, the amount of data, and the number of tasks.

Figure 4, Figure 5 and Figure 6 show the relationship curves between the number of CPU cycles required for the task and the average energy consumption, average latency, and average overhead in the system for five different schemes when processing the same task. It can be seen that all three metrics increase with the number of CPU cycles required for the task for all schemes. Due to the limited CPU resources of the local devices, the devices need to run at full capacity for a long time, resulting in a more significant increase in the curves for the locally executed scenarios. In contrast, the optimization scheme proposed in this paper has a relatively flat curve growth and, at the same time, yields lower energy consumption, latency, and overhead compared to the other schemes. The reason for this is that when the CPU cycle tasks are high, they are prioritized to be assigned to idle and efficient nodes, which achieves a globally optimal balance. When the number of CPU cycles required by a task reaches 1900 Megacycles, the average energy consumption obtained by the optimization scheme proposed in this paper is 81.1%, 48.2%, 24.8%, and 8.6% lower than the local execution scheme, average offloading scheme, FOX scheme [38], and PLO scheme, respectively; the average latency is 83.9%, 53.7%, 53.7%, 53.7%, 53.7%, 53.7%, 28.2%, and 9.7%, and the average overhead is reduced by 86.1%, 59.7%, 39.7%, and 24.6%, respectively. Therefore, this result shows that the scheme in this paper is able to maintain low energy consumption, latency, and overhead as the number of CPU cycles required for a task increases.

The effect of task data volume on average energy consumption, average delay, and average overhead under different scenarios is shown in Figure 7, Figure 8 and Figure 9. The average energy consumption, average delay, and average overhead within the system all show a linear growth trend with the increase in data volume. The relatively flat growth of the local execution scheme is due to the fact that the local scheme avoids the uncertainty associated with network communication, making the performance metrics dependent on the fixed parameters of the local device. Moreover, it can be observed that the proposed scheme in this paper is optimal in terms of reducing energy consumption, delay, and overhead. When the task data size reaches 2.0 MB, the average energy consumption obtained by the optimization scheme proposed in this paper is reduced by 60.9%, 23.9%, 10.3%, and 7.4% over the local execution scheme, the average offloading scheme, the FOX scheme, and the PLO scheme, respectively, while the average latency is reduced by 73.4%, 39.6%, 18.2%, and 13.3%, respectively, and the average overhead is reduced by 63.9%, 26.5%, 11.8%, and 7.1%. Therefore, the results show that the scheme in this paper can dynamically balance the utilization efficiency of computing resources according to the amount of task data and improve the overall performance.

Figure 10, Figure 11 and Figure 12 demonstrate the relationship between the number of tasks and the average energy consumption, average latency, and average overhead within the system. As the number of tasks increases, the local execution scheme has the least fluctuating metrics due to the fact that the local scheme processes the tasks in a fixed order and does not need to rely on optimization algorithms to assign tasks. However, its performance is the worst; in contrast, the FOX scheme, PLO scheme, and IPLO scheme all show better performance, among which the optimization scheme proposed in this paper performs the most outstandingly due to the fact that its optimization algorithm can effectively adapt to high-load scenarios and dynamically adjusts the task allocation strategy to reduce the system’s energy consumption, latency, and overhead. When the number of tasks reaches 100, the average energy consumption obtained by the optimization scheme proposed in this paper is reduced by 51.2%, 47.5%, 17.7%, and 13.8% compared with the local execution scheme, average offloading scheme, FOX scheme, and PLO scheme, respectively; the average latency is reduced by 57.7%, 54.7%, 17.2%, and 9.4%, respectively; and the average overhead is reduced by 75.5%, 50.7%, 15%, and 9.1%, respectively.

Regarding the IPLO scheme, the above experiments have fully confirmed its excellent and efficient performance. Compared with other schemes, the lower energy consumption can significantly extend the vehicle range, especially in long-distance transportation or high-load tasks to avoid overloading the battery; the lower latency can improve the response speed of the emergency tasks, which is usually applied to traffic accident warning and dynamic path planning scenarios; and the lower overhead can reduce the cost of computing resources for the vehicle, making it possible for small and medium-sized enterprises to use the IPLO scheme. The lower overhead can reduce the cost of computing resources for vehicles, making high-performance edge computing services affordable for small and medium-sized vehicles. At the same time, the dynamic decision thresholds of IPLO are determined through experimental data (1000 Megacycles of CPU cycles required for the task, 0.5 MB of data, and 20 tasks). Tasks below these thresholds are mostly simple tasks that can be handled locally by the vehicle (e.g., tire pressure monitoring, mileage counting), as they have low computational requirements and loose real-time requirements, while tasks above the thresholds usually involve complex scenarios (e.g., multi-vehicle cooperative obstacle avoidance). Tasks above the threshold usually involve complex scenarios (e.g., multi-vehicle cooperative obstacle avoidance, real-time rendering of high-definition maps) that must be dynamically allocated to the edge nodes through the IPLO algorithm to achieve global resource optimization. This design ensures that the algorithm strikes a precise balance between resource consumption and performance requirements. The solution can also be more highly applicable to variable networks, quickly adapting to network state changes through a dynamic task allocation mechanism. In scenarios such as signal fluctuations and bandwidth limitations in 5G networks, tasks can be assigned to more appropriate nodes in a timely manner, avoiding task backlogs and performance degradation caused by network instability.

In order to further compare the stability of the scheme, the FOX scheme, the Aurora optimization scheme, and the improved Aurora optimization scheme are tested under different constraints (fixed amount of data and number of tasks, fixed CPU cycles and number of tasks, fixed CPU cycles and amount of data).

Table 2. Standard deviations of algorithmic overhead under different conditions.

Arithmetic	Fixed Data Volume and Number of Tasks	Fixed CPU Cycles and Number of Tasks	Fixed CPU Cycles and Data Volume
FOX	0.022325712	0.121529847	0.084908155
PLO	0.006160379	0.120456452	0.086015252
IPLO	0.001792003	0.115658619	0.071276243

demonstrates the stability performance of the algorithm overhead under different conditions. From the results, it can be seen that the IPLO scheme has the smallest standard deviation in the test scenarios, indicating that the algorithm has high stability compared to the FOX scheme and PLO scheme, which have larger standard deviations. The reason is that the FOX scheme is prone to ineffective searching at the edges of the solution space due to the lack of a specialized design for the boundary problem; although the PLO scheme possesses better search capability, the boundary truncation processing leads to a rapid decline in population diversity at the later stage of the iteration. Therefore, the improved boundary processing strategy significantly improves the stability of the algorithm in complex optimization scenarios.

In order to analyze the sensitivity of the IPLO scheme, we systematically investigate the impact of different thresholds on the performance of the algorithm by controlling the probability of particle collision in the mutation operation. The probability of particle collision directly determines how often the algorithm introduces random perturbations during the search process, and by adjusting this threshold, we can explore the adaptive ability of the algorithm under different environmental conditions. Same as the constraints for testing the stability of the algorithm, we test the algorithm in terms of fixed data volume and number of tasks, fixed CPU cycles and number of tasks, and fixed CPU cycles and data volume, respectively.

Table 3. Average overhead of IPLO algorithm under different collision probabilities.

Collision Probability	Fixed Data Volume and Number of Tasks	Fixed CPU Cycles and Number of Tasks	Fixed CPU Cycles and Data Volume
0.01	0.450215907	0.40370882	0.615417646
0.03	0.451200618	0.397350783	0.619286688
0.05	0.451540167	0.400150143	0.616115548
0.07	0.450900238	0.399467543	0.618433646
0.1	0.45002346	0.403075415	0.616594892

demonstrates the sensitivity performance of the average overhead of the IPLO algorithm under different collision probabilities. The experimental results show that the average overhead of the algorithm does not show a significant difference when the collision probability threshold is varied in the range of 0.01 to 0.1. The reason is that IPLO is forced to keep the globally optimal particles in each generation during the iteration process, and the update of other particles is strictly guided by the optimal particles. Even if the collision probability threshold is high, newly generated randomized perturbation solutions that are inferior to the current optimal solution will be directly discarded. This low sensitivity ensures that the system can still maintain stable service quality under the dynamic environment of high-speed vehicle movement and frequent changes in network topology, and the algorithm can quickly restore stable scheduling based on the historical optimal solution even if there is a local communication interruption problem

5. Conclusions

In this paper, we propose a computing offloading strategy for IoV that integrates IPLO algorithm and blockchain technology, which realizes efficient allocation and safe control of computing resources in the IoV environment by establishing a single-vehicle multi-tasking computing offloading model and adopting an authorized Byzantine fault-tolerant consensus mechanism. Among them, the IPLO algorithm significantly reduces the system latency, energy consumption, and total overhead by introducing the bounce boundary processing mechanism, while demonstrating excellent stability in high-speed mobile scenarios, while the dBFT consensus mechanism based on the election of equity votes effectively prevents the risk of data tampering by dynamically selecting consensus nodes, providing a reliable foundation for trusting IoV. The scheme provides an efficient, stable, and secure edge computing solution for IoV through the co-design of algorithm optimization and security mechanisms.

The designed scheme demonstrates great practical value in IoV. In terms of performance improvement, it significantly enhances the real-time and economy of data processing in IoV by reducing system latency, energy consumption, and total overhead, providing a smoother operation environment for IoV applications. At the same time, lower latency can reduce the risk of traffic accidents and improve road safety. In terms of safety and security, the introduction of blockchain technology ensures the integrity of data transmission and effectively guards against the risk of malicious attacks and data leakage. In terms of system stability, the optimized algorithmic design allows the system to maintain reliable operation in scenarios of high-speed vehicle movement and frequent changes in network topology. Together, these advantages provide a solid technical foundation for IoV. In the future, this research will expand to frontier areas, such as quantum computing optimization and intelligent consensus mechanism, and is committed to breaking through the existing technical bottlenecks and helping the IoV technology to move to a higher level of development.