Mobility-Aware Task Offloading and Resource Allocation in UAV-Assisted Vehicular Edge Computing Networks

Abstract

The rapid development of the Internet of Vehicles (IoV) and intelligent transportation systems has led to increased demand for real-time data processing and computation in vehicular networks. To address these needs, this paper proposes a task offloading framework for UAV-assisted Vehicular Edge Computing (VEC) systems, which considers the high mobility of vehicles and the limited coverage and computational capacities of drones. We introduce the Mobility-Aware Vehicular Task Offloading (MAVTO) algorithm, designed to optimize task offloading decisions, manage resource allocation, and predict vehicle positions for seamless offloading. MAVTO leverages container-based virtualization for efficient computation, offering flexibility in resource allocation in multiple offload modes: direct, predictive, and hybrid. Extensive experiments using real-world vehicular data demonstrate that the MAVTO algorithm significantly outperforms other methods in terms of task completion success rate, especially under varying task data volumes and deadlines.

1. Introduction

The integration of Unmanned Aerial Vehicles (UAVs) into Vehicular Edge Computing (VEC) represents an innovative approach to enhancing the quality of service (QoS) within the Internet of Vehicles (IoV) landscape [1]. With UAV technology reaching higher maturity levels, drones can now possess communication and computational capabilities, enabling them to serve as mobile cellular base stations. UAVs can be deployed on demand to areas with high service demand to meet low-latency requirements while easing the burden on vehicular terminals. In regions with challenging terrains or insufficient ground infrastructure, UAVs provide an efficient and cost-effective option for task assistance. Unlike offloading tasks using a Roadside Unit (RSU), UAV deployment reduces substantial setup costs and offers greater flexibility. In addition, by circumventing remote cloud computing centers, UAVs help minimize transmission delays. This paradigm, where vehicles offload latency-critical tasks to proximate UAVs, significantly boosts vehicle capacity.

In this paper, we consider the problem of offloading tasks from bi-directional moving vehicles in UAV-assisted VEC. As depicted in Figure 1, the system comprises a vehicle layer and a UAV edge layer. We suppose that UAV/Vehicle and UAV/UAV can stably connect via dedicated U2V and U2U communication links. The edge layer involves multiple drones hovering above the roadway. Each UAV node is equipped with lightweight communication and computing capabilities, and their coverage is limited. A single vehicle can be within the range of several drones or at least one. Vehicles transmit and offload computing tasks to the connected drones. Vehicles within the drone coverage area can move in different directions. Vehicles may traverse several drone coverage zones while executing tasks. Consequently, the offloading node for a vehicle’s task is not limited to the currently engaged drone node; any drone node encountered before the task deadline qualifies as a potential offloading node. The primary challenge is assigning the most appropriate node for task offloading while considering factors such as task transmission cost, drone computing capability, and the sequence of tasks awaiting processing, with the goal of enhancing the quality of service.

Offloading tasks from bi-directional moving vehicles is a challenging issue: (a) Vehicles moving in both directions generate diverse offloading tasks that vary in urgency, data volume, and resource needs, making it difficult to prioritize tasks and establish an optimal offloading sequence. This is further complicated by the constant emergence of new tasks as vehicles move, which requires dynamic adjustments based on vehicle speed, proximity, and system load. (b) In bi-directional traffic environments, vehicles are constantly moving, often crossing the boundaries of different drones’ coverage zones during the task execution cycle. This movement makes it difficult to determine which drone should be assigned to offload a specific task. A single drone may not be able to serve a vehicle throughout the entire duration of its journey as the vehicle may quickly exit the drone’s operating range. Additionally, balancing the load among multiple drones and managing their limited computational capacity while ensuring they can still perform offloading without overloading any single drone requires sophisticated task scheduling and resource allocation mechanisms. (c) The computing power and storage capacity of drones in the connected vehicle are limited and require a flexible and efficient resource allocation approach to meet the needs of different tasks. Compared to heavyweight virtual machines (VM), using container-based virtualization technology for computation offloading is more suitable for the connected vehicle network. Containers have the advantages of fast startup time, less hardware overhead, and secure resource isolation, thus providing high flexibility in platform management and improving the task execution efficiency of UAV servers.

For the challenges mentioned above, we propose a heuristic scheduling algorithm referred to as MAVTO (Mobility Aware Vehicular Task Offloading) for the problem under study. The main contributions are as follows:

• Task Offloading Framework: The article proposes a novel task offloading and resource allocation framework for UAV-assisted VEC systems. This framework considers the mobility of vehicles, heterogeneous task requirements, and limited coverage of drones. It makes vehicle position predictions based on their motion information in order to optimize task offloading and resource allocation.
• MAVTO Algorithm: The article introduces the Mobility Aware Vehicular Task Offloading (MAVTO) algorithm, which dynamically adjusts task offloading decisions based on vehicle speed, task deadlines, and computational resources available in the UAV servers. MAVTO uses container-based virtualization to efficiently manage resources and improve task execution performance.
• Offloading Modes: The framework includes multiple offloading modes (direct, predictive, and hybrid), which provide flexibility in offloading tasks based on vehicle movement. The hybrid mode maximizes task success rates by selecting the optimal UAV nodes that vehicles will pass through within task deadlines.

The remainder of this paper is organized as follows. Section 2 reviews the existing literature on the problem under study. Section 3 represents the overview of the system and the model of our work. The MAVTO algorithm is proposed in Section 4. The numerical results are given in Section 5, followed by the conclusion in Section 6.

2. Related Work

Task offloading within VEC contexts has received considerable attention. However, most of the existing work focuses mainly on the traditional static way. These traditional methods involve using edge servers located at roadside units (RSUs) as UAV nodes, in collaboration with cloud computing servers to provide computing services for tasks. Traditional edge computing typically relies on static roadside units (RSUs) or stationary servers for offloading, which limits flexibility, especially in environments with highly dynamic vehicle movement. In contrast, UAV-assisted offloading offers several advantages, such as mobility, flexible deployment, and the ability to cover areas with insufficient infrastructure, which are particularly beneficial in high-mobility scenarios like vehicular networks.

In a traditional VEC environment, Bute et al. [2] design a task offloading scheme in which vehicles can transfer their tasks to other vehicles or the MEC server via the vehicle-to-network link (V2N). Cui et al. [3] propose a task offloading framework capable of dynamically managing network and computing resources. Liu et al. [4] present a mobility prediction model aimed at sustaining stable task offloading performance under a highly dynamic vehicular network. Xue et al. [5] formulate a framework in VEC task offloading and service caching scenario that can minimize the cumulative average task processing delay. Wang et al. [6] propose an imitation learning enabled task scheduling algorithm for online VEC. Bahreini et al. [7] design an energy-aware resource management framework for VEC systems that can share and coordinate computing resources among connected vehicles. Fan et al. [8] leverage for load balancing through RSU-RSU that a high-load edge server can be further offloaded to the other low-load edge servers. Ernest et al. [9] propose a multi-agent deep reinforcement learning-based (MADRL-based) energy efficiency maximization algorithm to attain maximum energy efficiency in the MEC-enabled IoV network. Some studies consider the mobility of vehicles. You et al. [10] considered an energy-efficient coordination offloading architecture for vehicular networks based on edge computing under vehicle mobility. This scheme decomposes tasks into multiple subtasks and offloads them to different roadside units. Tan et al. [11] considered an edge computing architecture for vehicle mobility scenarios and proposed a decentralized task offloading strategy, aiming to minimize the overall task response time and studied task offloading under both overlapping and non-overlapping RSU coverage architectures.

Few works have recently focused on task offloading in UAV-assisted VEC networks. For example, Dai et al. [12] developed a UAV-assisted offloading system where UAVs help manage the load of congested RSUs instead of directly servicing individual vehicles. Samir et al. [13] employed deep reinforcement learning (DRL) to devise a strategy for determining optimal paths for a UAV swarm to enhance vehicular coverage. He et al. [14] constructed a UAV-aided VANETs framework by integrating MEC selection, resource allocation, and task offloading, aiming to optimize task processing efficiency. Qi et al. [15] introduced a comprehensive optimization approach for content placement, spectrum usage, link pairing, and power management in UAV-supported vehicular networks to maximize long-term energy efficiency. Alkubeily et al. [16] crafted a schematic for enhancing UAV communication with VANETs to cater to the maximum number of ground vehicles. Yang et al. [17] suggested a learning-based channel allocation and task offloading method in temporary UAV-assisted VEC networks to boost data collection at reduced service costs. Li et al. [18] focused on a combined optimization of UAV routes and computing resources to curtail energy consumption in the UAV-assisted VEC offloading context. Liwang et al. [19] analyzed graph-based intensive task scheduling in air-to-ground integrated vehicle networks, aiming to jointly refine the mapping of task components to vehicles and the transmission power of UAVs.

The previously discussed studies did not explore the potential for task offloading using horizontal collaboration among multiple drones during the task offloading process. By utilizing UAVs, the proposed MAVTO can dynamically adjust to traffic pattern changes by repositioning UAVs or offloading tasks to UAVs closer to moving vehicles, thereby reducing latency and improving task success rates.

3. System Model and Problem Formulation

3.1. System Model

The scenario considered in this paper is a two-way road shown in Figure 1. The notations to be used in this paper are shown in

Table 1. Notations in this paper.

Notation	Description
$\mathcal{E}$	the set of UAV servers, $\mathcal{E}=\{1,\dots ,e,\dots ,E\}$, where $e=(R_e,P_e,r,{\mathbf{L}}_e)$
$R_e$	the U2V wireless link transmission rate of UAV node e
$P_e$	the CPU processing speed of UAV server e
r	radius of coverage zones of UAV server e
${\mathbf{L}}_e$	${\mathbf{L}}_e=(x_e,0)$, coordinates of UAV server e
W	the U2U wireless link transmission rate between UAV nodes
$\mathcal{V}$	the set of vehicles, $\mathcal{V}=\{1,\dots ,v,\dots ,V\}$, where $v=(v{s}_v,v{d}_v,{\mathbf{L}}_v)$
$v{s}_v$	speed of vehicle v
$v{d}_v$	direction of vehicle v
${\mathbf{L}}_v$	${\mathbf{L}}_v=(x_v,y_v)$, coordinates of vehicle v
K	the set of tasks generated, $K=\{1,\dots ,k,\dots ,K\}$, where $k=(v,I_k,O_k,C_k,T_k^{max})$, task generated by vehicle v
$I_k$	the input data volume of task k
$O_k$	the output data volume of task k
$C_k$	the computational workload of task k
$T_k^{max}$	the deadline of task k
$S_e$	the set of containers on UAV server e, $S_e=\{1,\dots ,s,\dots ,S\}$, where $s=({\theta }_s,P_s$)
${\theta }_s$	the instance startup time required for container s
$P_s$	the CPU processing speed of container s
$T_{k,e}$	the completion time of task k on UAV node e
$S{T}_{k,s}$	the start time of task k on container s
$T_{k,e}^{up}$	the time for uploading task k to UAV node e
$T_{k,e_1,e_2}^{trans}$	the time for transmitting task k between UAV node $e_1$ and $e_1$
$T_{k,e}^{com}$	the computation time of task k on UAV node e
$T_{k,e}^{down}$	the time for downloading results of task k to vehicles

. A set of UAVs (equipped with edge servers, denoted by $\mathcal{E}=\{1,...,e,...,E\}$) are uniformly stationed above this road. Each UAV has a certain communication coverage range. The coverage range between UAVs may overlap, and a vehicle may be covered by one or more UAVs. The UAV $e\in \mathcal{E}$ is characterized by a quadruple $e=(R_e,P_e,r,{\mathbf{L}}_e)$, where $R_e$ is the transmission rate for the U2V wireless link and $P_e$ represents the CPU processing speed of the UAV server. We project the UAV onto the center line of the road. r is the radius of the UAV’s coverage area and ${\mathbf{L}}_e=(x_e,0)$ represents the location of the UAV. The set of vehicles is given by $\mathcal{V}=\{1,...,v,...,V\}$, with the location of each vehicle v specified as ${\mathbf{L}}_v=(x_v,y_v)$. Connectivity is possible only if UAVs cover these vehicles, specifically when the Euclidean distance between any vehicle and a UAV satisfies $\left|\right|{\mathbf{L}}_e-{\mathbf{L}}_v\left|\right|\le r$. Tasks are resource-intensive and generated by vehicles. Let K be the set of tasks generated at the current time. The task $k\in K$ generated by vehicle v is characterized by $k=(v,I_k,O_k,C_k,T_k^{max})$, which represents the vehicle, input data volume, output data volume, computational workload, and deadline constraint, respectively.

In this study, it is assumed that vehicles travel at constant speed and direction. UAVs communicate by wireless links. Tasks that the vehicle terminal is unable to process must be offloaded via U2V links to the UAV layer for execution. Each UAV is equipped with a UAV server, but computing resources are limited. To optimize resource use and ensure effective load distribution among servers, it is possible to transfer task data between UAVs, thus allowing for computational tasks to be offloaded to and processed by other UAV servers. Consequently, each UAV server may manage tasks from directly connected UAVs as well as those offloaded by others. This scheme accounts for both vehicle mobility and server load status. As vehicles move, they consistently connect to varying UAVs. By considering multiple UAV servers as candidates for task offloading, the range of options for vehicles increases, mitigating the issue of overloading certain nodes. Integrating load balancing with task offloading serves to enhance system effectiveness.

3.2. Computing Model

The vehicles offload tasks to the UAV server for execution to reduce execution time and complete tasks as quickly as possible. However, this also results in an additional transmission time being used to transmit task data. The task computing process in UAV-assisted vehicular networks mainly includes the following stages:

• Task uploading: Vehicles upload tasks to the currently accessed UAV server via U2V upload links.
• Task transmission: When the computing power of the UAV node in use is insufficient, or if numerous tasks are queued with a significant load burden, it is advisable to consider offloading tasks to a UAV node when the vehicle is not currently busy. To optimize task execution or waiting times and alleviate the load on the UAV node, the task should be transmitted across the UAVs’ wireless links to the target UAV node for processing.
• Task execution: Once the task is uploaded to the destination UAV node, it is executed on the UAV server to retrieve the computational result. The waiting time for tasks should be taken into account.
• Result downloading: When the vehicle is within the UAV coverage range and the task has been calculated, the UAV server transmits the calculation result back to the vehicle through the download links.

(1) Task uploading

Let $R_e$ be the transmission rate of the U2V wireless link and $I_k$ be the input data volume of the task k. The uploading time $T_{k,e}^{up}$ for task k generated by vehicle v to be uploaded to UAV server e can be calculated as follows:

$$T_{k,e}^{up}={\displaystyle \frac{I_k}{R_e}}$$

(1)

(2) Task transmission

Both the input data and the output data of task k can be transmitted between UAV nodes $e_1$ and $e_2$. Let $hops$ be the number of hops experienced by the task between $e_1$ and $e_2$, and W be the transmission rate of the U2U wireless link between the UAV nodes. The task input or output data transmission time is defined as follows:

$$T_{k,e_1,e_2}^{trans}=hops\times {\displaystyle \frac{I_{k}or{O}_k}{W}}$$

(2)

(3) Task execution

The time required for a task to be processed on the UAV server includes three parts: the time it takes for the container instance to start, the time waiting in the task queue, and the time for actual computation. The container instance start time includes extracting the container image file and launching the container instance. In the problem studied in this article, it is assumed that the required container image files are all cached in the UAV node and do not need to be retrieved from a remote cloud. Therefore, only the time to launch the container instance is considered.

The UAV servers are heterogeneous, and each server has multiple container instances that can be used for task execution after startup. Let $S_e=\{1,\dots ,s,\dots ,S\}$ be the set of containers for UAV server e, where the containers are heterogeneous with different startup times ${\theta }_s$ and processing speeds $P_s$. Let $\varpi \left(s\right)$ be the decision variable whether container s has been started, and ${\xi }_{k,s}$ be the decision variable whether task k is assigned to container s.

$$\varpi \left(s\right)=\left\{\begin{array}{cc}1\hfill & containershasbeenstarted\hfill \\ 0\hfill & other\hfill \end{array}\right.$$

(3)

$${\xi }_{k,s}=\left\{\begin{array}{cc}1\hfill & taskkisassignedtocontainers\hfill \\ 0\hfill & other\hfill \end{array}\right.$$

(4)

Tasks can only wait to be processed by the UAV server after their data have been uploaded to the server and the container instance has been started. If the container is already running, it may be executing other tasks, so the current task needs to wait. Let $h_s$ denote the number of tasks that need to be processed on container s, and let ${\Psi }_s=({\psi }_1^s,\dots ,{\psi }_{h_s}^s)$ denote the processing order. Then, the starting execution time of task ${\psi }_p^s$ on container s is given by $S{T}_{{\psi }_p^s,s}$.

$$S{T}_{{\psi }_p^s,s}=max\{T_{{\psi }_p^s,e}^{up},EA{T}_s\}$$

(5)

where $EA{T}_s$ represents the earliest available time for the current container s. If the container has not been started, it equals the start time ${\theta }_s$. If the container has already been started, it equals the end time of all task sequences completed before the current task on the container.

$$EA{T}_s=\left\{\begin{array}{cc}{\theta }_s\hfill & \varpi \left(s\right)=0\hfill \\ T_{{\psi }_{h_s}^s,s}\hfill & \varpi \left(s\right)=1\hfill \end{array}\right.$$

(6)

where $T_{{\psi }_{h_s}^s,s}$ represents the completion time of task ${\psi }_{h_s}^s$ on container s.

The computation and completion time of task k on container s on the UAV node e is as follows:

$$\begin{array}{c}{T}_{k,s}^{com}={\displaystyle \frac{C_k}{P_s}}\end{array}$$

(7)

$$\begin{array}{c}{T}_{k,e}^{com}={\displaystyle \sum _{s\in S_e}}{\xi }_{k,s}{T}_{k,s}^{com}\end{array}$$

(8)

$$\begin{array}{c}{T}_{k,e}=S{T}_{k,s}+T_{k,e}^{com}\end{array}$$

(9)

(4) Result downloading

Let $O_k$ be the output data volume of task k. The time required to transmit the calculation result from the UAV node e to the vehicle via the U2V wireless link is defined as follows:

$$T_{k,e}^{down}={\displaystyle \frac{O_k}{R_e}}$$

(10)

3.3. Offloading Model

When tasks are offloaded to UAV nodes for execution, the task data need to be transferred to the node. There are three ways to offload tasks from vehicles to UAV nodes: direct offloading mode, predictive offloading mode, and hybrid offloading mode. The details of these three modes are discussed below.

3.3.1. Direct Offloading Model

When the vehicle v is within the coverage range of the UAV where server $e_1$ is located, the vehicle offloads the task k to the UAV server $e_1$ using U2V wireless link. While the UAV server $e_1$ is executing the computation task, the vehicle is moving at high speed and may have left the coverage range of the UAV when the task execution is completed. It enters the coverage range of the UAV where server $e_2$ is located. The computed result of the task needs to be transmitted from server $e_1$ to server $e_2$ through U2U wireless link between UAVs. This situation is depicted in Figure 2. The completion time of the task is computed as follows:

$$\begin{array}{c}{T}_{k,e_1}=T_{k,e_1}^{up}+T_{k,e_1}^{com}+T_{k,e_1,e_2}^{trans}+T_{k,e_2}^{down}\end{array}$$

(11)

where $T_{k,e_1}^{up}$ represents the time it takes for the task k to be offloaded to the UAV server $e_1$ via U2V wireless link. $T_{k,e_1}^{com}$ represents the time taken for the task computation. $T_{k,e_1,e_2}^{trans}$ represents the time it takes for the computed result of the task to be transmitted between UAVs. $T_{k,e_2}^{down}$ represents the time it takes to transmit the computed result back to the vehicle via the U2V wireless link.

3.3.2. Prediction Offloading Model

When the vehicle v is within the coverage range of the UAV where server $e_1$ is located, the vehicle utilizes a U2V wireless link to transmit the task k to the UAV server $e_1$. Based on the vehicle’s motion-sensing information, including the current speed and direction, the edge server estimates the task completion time and predicts the location where the vehicle will arrive. The task then offloads to the server $e_2$ at the predicted location in advance for execution. When the vehicle enters the coverage range of the server $e_2$, the task computation result is obtained directly. This scenario is depicted in Figure 3. The total completion time of the task $T_{k,e_2}$ is calculated as follows:

$$\begin{array}{c}{T}_{k,e_2}=T_{k,e_1}^{up}+T_{k,e_1,e_2}^{trans}+T_{k,e_2}^{com}+T_{k,e_2}^{down}\end{array}$$

(12)

3.3.3. Mixed Offloading Model

Based on the vehicle’s motion-sensing information, including the current speed and direction, the edge server predicts the changes in the vehicle’s position and the UAVs it will pass through within the deadline. The edge servers during the deadline are considered as candidate offloading nodes for the task, and one server $e_2$ is selected as the offloading node for task computation. The vehicle transmits the task through the currently accessed UAV node $e_1$, and after the task computation is completed, the computed result is transmitted to UAV node $e_3$, which is currently accessed by the vehicle and is returned to the vehicle through $e_3$. The scenario is illustrated in Figure 4. The total completion time of the task $T_{k,e_2}$ is calculated as follows:

$$\begin{array}{c}{T}_{k,e_2}=T_{k,e_1}^{up}+T_{k,e_1,e_2}^{trans}+T_{k,e_2}^{com}+T_{k,e_2,e_3}^{trans}+T_{k,e_3}^{down}\end{array}$$

(13)

3.4. Problem Formulation

In this paper, we consider a set K of tasks generated by vehicles entering the coverage range of a UAV at the current time. Let ${\mu }_{k,e}$ be the decision variable whether the task k is within the coverage range of UAV server e, and ${\eta }_{k,e}$ be the decision variable whether it is executed on server e. Each task $k\in K$ has a hard deadline $T_k^{max}$. With the consideration of deadline constraints, the objective is to maximize the task completion success ratio (SR), which represents the proportion of tasks completed within the deadline. Due to the limited resources of UAV servers, there is a time cost for each computation task, especially for UAV servers located in high-density and high-computation-demand areas, which may result in high server load, long task waiting time, and high task failure rate. Based on the three offloading mode schemes discussed above, adopting a hybrid offloading mode provides more options for task offloading and can achieve better optimization goals through reasonable offloading decisions. Therefore, we consider using the hybrid offloading mode, which predicts the vehicle’s location based on its motion-sensing information and selects the UAV nodes that the vehicle passes through within the deadline as candidate offloading nodes. The objective is to maximize the task completion success ratio in the task offloading and resource allocation problem within the framework of VEC:

$$maxSR={\displaystyle \frac{{\displaystyle \sum _{k\in K}}{F}_k}{\left|K\right|}}$$

(14)

s.t.

$$\begin{array}{c}{F}_k=\left\{\begin{array}{cc}1,\hfill & T_k\le T_k^{max}\\ 0,\hfill & T_k>T_k^{max}\end{array}\right.\end{array}$$

(15)

$$\begin{array}{c}{T}_k=S{T}_k+E{T}_k+D{T}_k\end{array}$$

(16)

$$\begin{array}{c}S{T}_k=max\{T{T}_k,ES{T}_k\}\end{array}$$

(17)

$$\begin{array}{c}T{T}_k={\displaystyle \sum _{e\in \mathcal{E}}}{\eta }_{k,e}{T}_{k,e}^{up}\end{array}$$

(18)

$$\begin{array}{c}{T}_{k,e}^{up}=\left\{\begin{array}{cc}{T}_{k,e_1}^{up},\hfill & e=e_1\&{\mu }_{k,e_1}=1\\ T_{k,e_1}^{up}+T_{k,e_1,e_2}^{trans},\hfill & e=e_2\&{\mu }_{k,e_1}=1\end{array}\right.\end{array}$$

(19)

$$\begin{array}{c}ES{T}_k={\displaystyle \sum _{e\in \mathcal{E}}}\left({\eta }_{k,e}{\displaystyle \sum _{s\in S_e}}\left({\xi }_{k,s}EA{T}_s\right)\right)\end{array}$$

(20)

$$\begin{array}{c}E{T}_k={\displaystyle \sum _{e\in \mathcal{E}}}\left({\eta }_{k,e}{\displaystyle \sum _{s\in S_e}}\left({\xi }_{k,s}{T}_{k,s}^{com}\right)\right)\end{array}$$

(21)

$$\begin{array}{c}D{T}_k={\displaystyle \sum _{e\in \mathcal{E}}}{\mu }_{k,e}{T}_{k,e}^{down}\end{array}$$

(22)

$$\begin{array}{c}{T}_{k,e}^{down}=\left\{\begin{array}{cc}{T}_{k,e_1}^{down},\hfill & e=e_1\&{\eta }_{k,e_1}=1\\ T_{k,e_2}^{down}+T_{k,e_1,e_2}^{trans},\hfill & e=e_2\&{\eta }_{k,e_1}=1\&{\eta }_{k,e_2}\ne 1\end{array}\right.\end{array}$$

(23)

$$\begin{array}{c}{\mu }_{k,e}=\left\{\begin{array}{cc}1,\hfill & \left|\right|{\mathbf{L}}_e-{\mathbf{L}}_v\left|\right|\le r\\ 0,\hfill & other\end{array}\right.\end{array}$$

(24)

$$\begin{array}{c}{\eta }_{k,e}=\left\{\begin{array}{cc}1,\hfill & taskkisexecutedonnodee\\ 0,\hfill & other\end{array}\right.\end{array}$$

(25)

Equation (14) represents the optimization objective, which is to maximize the success ratio of tasks completed within the deadline. Equation (15) indicates whether a task can be completed within the deadline, with a value of 1 for completion and 0 for non-completion. Equation (16) describes the completion time of a task under edge offloading, which is the sum of the task’s start execution time ($ST$), execution time ($ET$), and result transmission time ($DT$). Equations (18)–(20) describe the relationship between the task’s start execution time ($ST$) and the task’s transmission time, container startup time, and the earliest available time ($EAT$) of the container. Equation (21) describes the task execution time in relation to the allocated container. Equations (22) and (23) represent the result transmission time. Equations (24) and (25) are the two decision variables.

4. Mobility Aware Vehicular Task Offloading Algorithm

The MAVTO (Mobility Aware Vehicular Task Offloading) algorithm offers a mobility-focused approach to vehicular task offloading and resource distribution within the Internet of Vehicles framework. This method takes into account vehicle mobility and utilizes UAV servers equipped with containerization technology. Aiming to optimize the success rate of task execution, the algorithm uses a hybrid offloading mode to tackle the issue while adhering to resource limitations.

4.1. Algorithm Framework

The algorithm accepts three input sets: user vehicles V, tasks K, and UAV servers $\mathcal{E}$. It outputs the task offloading strategy $\mathcal{Y}$, resource allocation strategy $\pi$, and the task success rate $SR$. The framework of the algorithm is detailed in Algorithm 1. For task offloading requests from vehicles on the road, the algorithm initially segregates the tasks into a local execution sequence and an offloading sequence, considering deadline constraints and local computation abilities. It then forms a set of potential offloading nodes for each task. Following this, the algorithm uses the offloading sequence generation algorithm to arrange the offloading sequences according to travel direction and iteratively selects offloading directions to decide on task offloading. For every task, once the offloading node is chosen, an execution container is linked to it until all tasks are scheduled and finished. After obtaining the offloading decisions and resource allocation outcomes, the task success rate $SR$ is computed.

Algorithm 1: MAVTO (Mobility Aware Vehicular Task Offloading) Algorithm Framework

Input: The set of UAV servers $\mathcal{E}$; the set of vehicles $\mathcal{V}$; the set of tasks K; Output: Task Offloading Decision $\mathcal{Y}$; Resource Allocation $\Pi$; Success Rate of Task Completion $SR$

4.2. Generate the Candidate Group of Offloading Servers

According to the high-speed mobility of the user vehicle and the limited coverage range of UAVs, during the task offloading and execution process, the vehicle may move out of the coverage range of the offloading UAV node, passing through multiple UAVs. The UAV servers mounted on these UAVs can serve as candidate offloading nodes for the task. When the vehicle enters the coverage range of a UAV, it can directly communicate with the UAV, offloading the task to the UAV server for execution. However, due to the limited coverage range of UAVs, the vehicle currently cannot communicate directly with the upcoming UAVs, which are referred to as multi-hop UAVs. If the UAV server of a multi-hop UAV is selected as the offloading node, it can utilize the directly connected UAVs as relay nodes to perform multi-hop transmission of the offloaded task to the final destination UAV node, where the task is received and processed. Therefore, the candidate offloading group $G_k$ is obtained based on the driving speed $v{s}_v$, driving direction $v{d}_v$, and deadline constraint $T_k^{max}$ of the task k. The final candidate group $G_k$ is determined by the specific formulations (26). Equations (27)–(29) defines the minmal and maximal coordinates of vehicles and UAVs, respectively.

$$\begin{array}{c}{G}_k=\left\{e\right|e\in \mathcal{E},[x_v^{min},x_v^{max}]\cap [x_e^{min},x_e^{max}]\ne ⌀\}\end{array}$$

(26)

$$\begin{array}{c}{x}_v^{min}=\left\{\begin{array}{cc}{x}_v-T_k^{max}\times v{s}_v,\hfill & v{d}_v=WEST\\ x_v,\hfill & v{d}_v=EAST\end{array}\right.\end{array}$$

(27)

$$\begin{array}{c}{x}_v^{max}=\left\{\begin{array}{cc}{x}_v,\hfill & v{d}_v=WEST\\ x_v+T_k^{max}\times v{s}_v,\hfill & v{d}_v=EAST\end{array}\right.\end{array}$$

(28)

$$\begin{array}{c}{x}_e^{min}=x_e-\sqrt{r-y_v};x_e^{max}=x_e+\sqrt{r-y_v}\end{array}$$

(29)

4.3. Task Offloading Sequence Generation

For a given task, if the local processing capability of the vehicle terminal is sufficient to handle the task and meets the deadline constraint, the task can be executed locally, saving transmission time. However, most vehicle terminals have limited processing capabilities. If the local resources are not sufficient to handle the task or if the local processing queue is too long, the task can be offloaded to UAV servers, leveraging their stronger processing capabilities. This gives rise to the distinction between the local execution sequence and the offloading sequence. Regarding the offloading sequence, during the task offloading decision process, the tasks are first assigned different priorities according to certain rules. They are then sorted based on priority to generate the task offloading sequence. The tasks are then assigned to the server nodes in the order of the offloading sequence. Since bidirectional vehicles are considered in this paper, the tasks generated by vehicles traveling in different directions are ranked separately. Based on the task attributes and optimization goals, this paper proposes the Offloading Task Sequence Sorting (OTSS) method for sorting the task offloading sequence:

1.

OTSS1: MNCF (Minimum Number of Candidates First). The MNCF rule considers the candidate group count of the potential offloading servers for tasks, as mentioned in Section 4.2. For tasks with a limited selection range, they should be assigned offloading nodes with higher priority. On the other hand, for tasks with a wide selection range, they should be assigned offloading nodes later so that the offloading node assignment can be adjusted based on the current decision scheme. Otherwise, it would result in limited flexibility for tasks with a smaller selection range.

2.

OTSS2: MATF (Minimum Available Time First). The MATF rule considers not only the deadline constraint of tasks but also takes into account the characteristics of vehicle speed and position based on vehicle mobility information. The less time a vehicle spends driving within the current coverage range, the easier it is for the vehicle to leave the range of the current UAV. The available time for a vehicle v to handle task k is denoted as $T_v^{avail}$:

$$\begin{array}{c}\begin{array}{cc}& T_v^{avail}=min(T_k^{max},T_v^{stay})\hfill \\ & T_v^{stay}={\displaystyle \frac{RD}{v{s}_v}}\hfill \\ & R{D}_k=\sqrt{{\left(r\right)}^2-y_v^2}\pm |x_v-x_e|\hfill \end{array}\end{array}$$

(30)

where $T_v^{stay}$ is the remaining travel time of the vehicle within the coverage area of the current UAV node, and $RD$ is the remaining travel distance of the vehicle within the coverage area of the current UAV node. The $RD$ calculation is shown in the example in Figure 5.

3.

OTSS3: Maximum Local Execution Time First. For tasks that take a long time to execute locally, tasks are more likely to be completed beyond the deadline, resulting in a poor experience. Therefore, priority is given to offloading tasks that take a long time to execute locally.

4.

OTSS4: MWSDC (Minimum Weighted Sum of Data and Computation First). The MWSDC rule takes into account the input data volume and computational workload of a task. For a task k, its weighted sum $SU{M}_k$ is defined as follows:

$$SU{M}_k={\lambda }_1{C}_k+{\lambda }_2{I}_k$$

(31)

where ${\lambda }_1$ and ${\lambda }_2$ are used to balance the computational workload ($C_k$) and data volume ($I_k$) of the task, a smaller $SUM$ value indicates a lower resource demand for the task. Therefore, tasks with smaller SUM values have higher priority and are preferred for offloading decisions.

4.4. Offloading Decision

The task submits an offloading request to the VEC system, which first makes an offloading decision to assign a specific UAV node for each task execution. In this paper, we consider the multiple nodes that a high-speed moving vehicle passes through within the deadline as candidate offloading nodes for the vehicle’s tasks. From the candidate offloading node group, a target server is selected for offloading. The vehicle can directly offload the tasks to the currently connected UAV node for execution, or consider transferring the tasks to other UAV nodes through the currently connected UAV node. As we are dealing with a heterogeneous resource scenario, the processing capabilities of UAV servers may vary, and the processing capabilities of containers on the same UAV server may also differ. In addition, the distribution of UAV servers varies, leading to different costs for task transmission. Meanwhile, the task deadline constraint must be considered during the offloading decision, adding complexity to the problem. Therefore, it is necessary to consider the characteristics of UAV servers and task attributes, balance the contradiction between reducing execution time by task offloading and increasing transmission time by offloading to UAV nodes, and maximizing the task success rate. Consequently, the following Offloading Decision (OD) rules are formulated as the objective:

1.

OD1: MECTF (Minimum Estimated Completion Time First). When selecting offloading nodes for tasks, various factors such as uploading time, transmission time, waiting time, computation time, and result return time are taken into account. The estimated completion time of the task at each UAV node is assessed, and the destination node is chosen as the one that can complete the task earliest. The estimated completion time of the task is calculated using Equation (32).

$$\begin{array}{c}\widehat{EC{T}_{k,e}}=max(T{T}_{k,e},\widehat{EA{T}_e})+\widehat{E{T}_{k,e}}+\widehat{D{T}_{k,e}}\end{array}$$

(32)

$$\begin{array}{c}T{T}_{k,e}=\left\{\begin{array}{cc}{T}_{k,e_1}^{up},\hfill & e=e_1\\ T_{k,e_1}^{up}+T_{k,e_1,e_2}^{trans},\hfill & e=e_2\&e_1\ne e_2\end{array}\right.\end{array}$$

(33)

The estimated completion time $\widehat{EC{T}_k}$ of task execution on a UAV node is determined by a combination of factors, including the transmission time $T{T}_{k,e}$ from various nodes, the estimated earliest availability time of servers $\widehat{EA{T}_e}$, the estimated computation time $\widehat{E{T}_{k,e}}$, and the estimated task result return time $\widehat{D{T}_{k,e}}$. Transferring the task to an unconnected node $e_2$ incurs an additional transmission cost $T_{k,e_1,e_2}^{trans}$ compared to uploading it directly to the directly connected UAV node $e_1$. The value of $\widehat{E{T}_{k,e}}$ is calculated using the average processing speed of the UAV server, represented by $\overline{P_e}={\displaystyle \frac{{\displaystyle \sum _{s\in S_e}}{P}_s}{|S_e|}}$. The estimated earliest availability time of the server is calculated using the average startup time $\overline{\theta }$ of containers and the average wait time $\overline{W{T}_e}$ of tasks on the server. The task result return time is determined by the size of the computation result, the downstream transmission rate, and the location at which the vehicle arrives, specifically $\widehat{D{T}_{k,e}}={\displaystyle \frac{O_k}{R_e}}+hops\times {\displaystyle \frac{O_k}{W}}$. Based on the perception information of vehicle movement, the predicted location of the vehicle’s arrival is used to estimate the number of $hops$ that the computation result needs to traverse between UAVs.

2.

OD2: MCCF (Maximum Computing Capacity First). Taking into consideration the computational capabilities of UAV nodes, tasks executed on UAV servers with higher computational capabilities will have shorter execution times, maximizing the utilization of node processing capabilities. However, this approach directly ignores the task transmission cost and the node’s workload, which may result in an uneven distribution of tasks among UAV nodes. As a consequence, servers with higher processing capabilities may become overloaded, while servers with lower processing capabilities remain idle, leading to under-utilization of resources.

3.

OD3: LBF (Load Balance First). Balancing the processing capabilities and the number of pending tasks among UAV nodes to match their processing capacity with the workload is essential to achieve equilibrium among the nodes. In the task selection process, the UAV node with the minimum current load pressure is chosen as the offloading node. The load factor (LF) is defined as the ratio of the current workload of a UAV node to its maximum processing capacity:

$$L{P}_e={\displaystyle \frac{{\displaystyle \sum _{{\psi }_i\in {\Psi }_e}}{C}_{{\psi }_i}}{\overline{P_e}}}$$

(34)

Here, ${\Psi }_e$ represents the set of pending tasks for a UAV node. $LF$ is used as a comprehensive measure to assess the processing capabilities and the number of tasks being processed by a UAV node. The UAV node with the smallest $LF$ value is selected as the unload node for task computation.

4.5. Resource Allocation

After making the decision to offload each task, it is necessary to match the tasks with containers on the offloading node. This process takes into consideration the task’s own attributes and the resource situation on the UAV node. Through task scheduling, suitable containers are assigned to the tasks in order to achieve the optimization objective of maximizing task completion success rates. The following resource allocation (RA) strategy is proposed:

1.

RA1: EFTF (Earliest Finish Time First). The EFTF strategy takes into account both the processing capabilities of the containers and the queuing status of pending task sequences. It estimates the completion time of tasks on each container and assigns tasks to the container with the shortest completion time for processing. This approach ensures that tasks are assigned to the containers that can complete them in the shortest amount of time.

2.

RA2: Max–Min. The core idea of this strategy is to sort the task sequence in a non-increasing order of processing time and assign tasks to containers with shorter processing times. This maximizes resource utilization and minimizes task completion time, ultimately aiming to meet task deadlines. The strategy optimizes resource usage and increases the likelihood of completing tasks within their respective deadlines.

3.

RA3: Min-Variance. To improve the efficiency of task scheduling in a containerized environment, a strategy is proposed where tasks are sorted based on their processing time in ascending order. The tasks are then assigned to containers with the shortest processing time. An initial scheduling plan is obtained on the basis of this strategy. Subsequently, a failure sequence of tasks that exceed the deadline is recorded. To address these failures, a Min-Variance algorithm and a rescheduling algorithm are introduced. The Min-Variance algorithm sorts tasks in a non-decreasing order of their computational workload and assigns each task to a container with the minimum completion time. After obtaining the task-resource mapping sequence, the failed tasks are rescheduled onto other containers for execution. The pseudocode for the Min-Variance algorithm and the rescheduling algorithm is presented as Algorithm 2 and Algorithm 3, respectively.

Algorithm 2: The Framework of Min Variance

Input: The set of UAV servers $\mathcal{E}$ Output: The task-container matching sequence $\Pi$; success rate of task execution $SR$

   The rescheduling algorithm (Algorithm 3) sorts failed tasks based on increasing deadline constraints. It sequentially reschedules tasks by selecting previously unconsidered UAV nodes. If a new candidate node improves completion time and allows task completion within the deadline, it becomes the new target container. The algorithm keeps track of the maximum optimization space. After considering all candidate nodes, it recalculates task completion time and container availability and updates the unload decision and resource allocation plans. The Min-Variance algorithm first sorts the set of tasks $K_{q_e}$ on each UAV server e based on their computational requirements, with a time complexity of $O(|K_{q_e}|log(|K_{q_e}|))$. Then, it matches resources for each task one by one, with a time complexity of $O\left(\right|K_{q_e}|\times |S_e\left|\right)$. Finally, the algorithm calls Algorithm 3 for rescheduling the failed task sequence. Assuming the number of failed tasks is $n_1$, the time complexity of Algorithm 3 is $O(n_1\times |\mathcal{E}|\times |S\left|\right)$. Therefore, the total time complexity of the Min-Variance algorithm is $O\left(\right|K_{q_e}|log(|K_{q_e}\left|\right)+|K_{q_e}|\times |S_e|+n_1\times \left|\mathcal{E}\right|\times \left|S\right|)$, which simplifies to $O\left(\right|K_{q_e}|log(|K_{q_e}\left|\right))$.

Algorithm 3: TRS (Task Re-Scheduling)

Input: Set of failed tasks $K^{failed}$; Sequence of task-container matches $\Pi$; Number of successfully executed tasks $SN$ Output: Updated sequence of task-container matches $\Pi$; Updated number of successfully executed tasks $SN$

5. Experimental Results

5.1. Experimental Environment and Datasets

The dataset utilized for the experiments presented in this paper is sourced from the vehicle trajectory dataset associated with the Wu Yun Expressway in Shanxi, China [20]. These data include details such as the vehicle’s position, time of recording, speed, and travel direction. For the experiment, a typical two-way lane on the Wu Yun Expressway was chosen, and five sections were designated for UAV deployment. The actual vehicle trajectory data from 1 August 2021 were employed to represent the motion path of the vehicle performing the task.

In the process of fine-tuning algorithm parameters and evaluating performance, it is crucial to maintain fairness in the comparison of experimental outcomes. To achieve this, numerous examples must be created for testing. In this context, we consider vehicle counts of $\{60,70,80,90,100\}$. To assess how task data influence algorithm performance, experiments are compared across four data intervals: $\left\{\right[0.3,0.5],[0.5,0.8],[0.8,1],[1,1.5\left]\right\}\left(\mathrm{Mb}\right)$. Additionally, this study examines the effects of varying deadline constraints on algorithm performance by using four different deadline intervals: $\left\{\right[0.2,0.3],[0.3,0.5],[0.5,1],[0.5,1.5\left]\right\}\left(\mathrm{s}\right)$. For details on the experimental parameters, refer to [21], with the specific settings detailed in

Table 2. Experiment Parameters.

Parameter	Parameter Value
Number of UAV servers	5
U2V link transmission rate	$[2,6]\mathrm{Mbps}$
CPU processing speed of UAV servers	$[1,3](\times {10}^{11})\mathrm{GHz}$
Radius of coverage zones of UAVs r	$125\mathrm{m}$
Number of vehicles	$\{60,70,80,90,100\}$
Input task data volume	$\left\{\right[0.3,0.5],[0.5,0.8],[0.8,1],[1,1.5\left]\right\}\mathrm{Mb}$
Output task result data volume	$[0.25,0.35]\mathrm{Mb}$
Task computational workload	$[2,3](\times {10}^{10})\mathrm{CPU}\mathrm{cycles}$
Task deadline intervals	$\left\{\right[0.2,0.3],[0.3,0.5],[0.5,1],[0.5,1.5\left]\right\}\left(\mathrm{s}\right)$

. For each of the 5 vehicle counts, 4 task data volume intervals, and 4 deadline constraint intervals, 10 instances are generated, resulting in a total of $5\times 4\times 4\times 10=800$ instances. For parameter tuning, there are 4 OTSS strategies, 3 OD strategies, and 3 RA strategies, leading to 4 × 3 × 3 × 800 = 28,800 experiments in total. The optimal configuration is determined by evaluating the experimental data.

In order to evaluate the algorithm’s performance and parameter calibration, the RPD (Relative Percentage Deviation) is used as an evaluation metric in this paper. The RPD measures the deviation of the algorithm’s objective function value Z from the optimal solution $Z^{\ast }$, which represents the highest task completion success rate obtained by all algorithms under the same conditions. A smaller $RPD$ value indicates a better algorithm performance.

$$RPD(\%)={\displaystyle \frac{Z^{\ast }-Z}{Z^{\ast }}}\times 100\%$$

(35)

5.2. Parameter Calibration

In this paper, the proposed components are calibrated using ANOVA (Analysis of Variance) technique, and the performance of each component is analyzed.

1.

Task Offloading Sequence Generation

Figure 6 presents a comparison of four task offloading sequence ordering rules: OTSS1, OTSS2, OTSS3, and OTSS4. Among these, OTSS4, which gives precedence to workloads with the least data intensity, demonstrates superior performance. This rule takes into account both transmission and computation resource demands, thus enhancing the likelihood of tasks meeting their deadlines. Conversely, OTSS1 and OTSS2 focus solely on minimizing the number of candidate nodes and available time, respectively, thus evaluating only partial task characteristics and delivering inferior performance. OTSS3 acknowledges computation resource needs but overlooks bandwidth requirements and variations in processing capabilities. Therefore, OTSS4 is selected as the task offloading sequence ordering rule in this study.

2.

Offloading Decision Strategy

Figure 7 depicts a comparison of the performance of three task offloading strategies: OD1, OD2, and OD3. Of these, OD3, which implements a load balancing priority tactic, achieves superior performance compared to OD1 and OD2. OD3 takes into account both the processing capabilities of the UAV nodes and the order of pending task offloading when selecting nodes. Conversely, OD1 is based on a minimum estimated completion time priority strategy and considers the server’s processing capabilities and current load. However, it may result in suboptimal task allocation due to inaccurate estimates of task completion times, leading to inferior performance relative to OD3. On the other hand, OD2 employs a maximum processing capability priority strategy that focuses solely on the resource status of UAV nodes, causing uneven server loads and reduced task processing effectiveness. Consequently, OD2 delivers the least favorable performance. From the analysis and comparison, OD3, with its load balancing priority approach, is selected as the optimal task offloading decision rule.

3.

Resource Allocation

Figure 8 presents a comparative analysis of various resource allocation strategies within a 95% Tukey HSD confidence interval. The figure illustrates that among the three strategies evaluated, RA3 demonstrates superior performance. RA1, which prioritizes the earliest completion time, allocates tasks to containers with the earliest finishing capability but fails to account for resource contention among tasks, resulting in extended waits for other tasks. RA2, based on the Max–Min strategy, prioritizes large task scheduling by assigning them to the earliest available containers, which, in turn, possibly makes smaller tasks wait beyond their deadlines. Conversely, RA3 adopts the Min-Variance strategy, focusing on scheduling smaller tasks first, thereby minimizing their wait times. Post initial allocation, a secondary assignment is conducted to relocate tasks at risk of deadline breaches to containers that can further reduce their completion times, thereby enhancing overall task success rates. Ultimately, this study selects RA3 as the most effective resource allocation strategy.

5.3. Performance Comparison

To assess the effectiveness of the proposed MAVTO algorithm Source code: https://github.com/balldu/MAVTO/tree/master, (accessed on 11 November 2024). the TAVF [22], MONSA [23], and TFPVTO [24] algorithms serve as baseline algorithms. In this paper, a multifactor analysis of variance technique is used to compare the performance of the algorithms, considering factors such as the number of vehicles, task data volume, and deadline values.

Figure 9 shows the mean variation of RPD (Relative Percentage Deviation) for different numbers of vehicles in four data volume ranges: [0.3, 0.5] Mb, [0.5, 0.8] Mb, [0.8, 1.0] Mb, and [1.0, 1.5] Mb. In Figure 9a, for smaller task data volume and fewer vehicles, the performance of the MAVTO algorithm is similar to the TFPVTO algorithm. This is attributed to the fact that in scenarios with a small number of tasks, the advantage of load balancing techniques is not significant, and the load on different UAV nodes is not significantly different. However, as the number of vehicles increases, the performance gap between the MAVTO algorithm and the comparative algorithms widens due to the varying loads on different UAV nodes. The similarity between the MONSA algorithm and the TAVF algorithm is observed because, for lower data volumes, the MONSA algorithm selects UAV nodes other than the nearby ones, resulting in lower transmission costs and shorter task wait times. TAVF algorithm considers transmission costs and tends to select nearby UAV nodes more often, leading to relatively longer computation times and comparable completion times to the MONSA algorithm. Thus, there is not much difference in the success rates between the two algorithms. When the data volume increases, the transmission cost also increases. As shown in Figure 9d, the transmission cost of MONSA algorithm becomes larger, hence it performs slightly worse than TAVF algorithm. TFPVTO algorithm also employs a strategy of selecting nearby UAV nodes for offloading, but it optimizes resource allocation using the minimum-weight perfect matching algorithm based on a weighted bipartite graph. This results in a more optimal allocation scheme compared to the TAVF algorithm and MONSA algorithm. Overall, the proposed MAVTO algorithm outperforms the others. MAVTO algorithm considers the resource and load situation of each UAV node comprehensively, achieving a more balanced load distribution among the nodes. It prioritizes scheduling small tasks in resource allocation and readjusts the allocation scheme to optimize the results. From Figure 9, it can be observed that as the task data volume increases, the performance difference between the MAVTO algorithm and the other three algorithms gradually increases. MAVTO algorithm does not concentrate tasks on resource-rich nodes like the MONSA algorithm, nor does it adopt the nearby selection strategy of the TAVF algorithm and TFPVTO algorithm, which may cause high load pressure and longer task waiting times. Instead, the MAVTO algorithm evenly distributes tasks across different UAV nodes, reducing task wait times. In summary, under different task data volumes, the MAVTO algorithm outperforms the other three comparative algorithms in terms of maximizing the success rate of completing tasks within the deadline, especially in scenarios with a larger task data volume.

Figure 10 shows the mean variation of RPD (Relative Percentage Deviation) for different numbers of containers in four data volume ranges: [0.3, 0.5] Mb, [0.5, 0.8] Mb, [0.8, 1.0] Mb, and [1.0, 1.5] Mb. As shown in the figure, MAVTO consistently outperforms the other algorithms (MONSA, TAVF, and TFPVTO) by maintaining the lowest RPD, indicating that it provides the closest results to the optimal solution regardless of task data volume. As data volume increases, the RPD for MONSA, TAVF, and TFPVTO generally increases, especially at higher container numbers. This trend suggests that these algorithms struggle with higher data volumes, possibly due to increased resource contention or processing delays. MAVTO’s stability across data volumes shows that its hybrid offloading strategy and load balancing capabilities handle increased data volumes effectively. For each data volume interval, increasing the number of containers tends to increase the RPD for all algorithms, but this effect is notably less severe for MAVTO. In Figure 10a,b, MAVTO’s RPD remains relatively flat even as the number of containers increases, showing minimal impact from additional containers. This suggests that MAVTO’s resource allocation strategy effectively manages task distribution even when more containers are introduced. For MONSA, TAVF, and TFPVTO, the increase in RPD with more containers may reflect inefficiencies in these algorithms’ ability to allocate tasks efficiently when there are more resources. These algorithms could be encountering issues with load balancing or resource management as container numbers rise.

Figure 11 shows the mean variation of RPD (Relative Percentage Deviation) for different numbers of vehicles in four deadline ranges: [0.2, 0.3] s, [0.3, 0.5] s, [0.5, 1.0] s and [0.5, 1.5] s. In Figure 11a, it can be observed that as the number of vehicles increases, the difference in RPD values between the MAVTO algorithm and the other three algorithms also increases. Moreover, the TFPVTO, TAVF, and MONSA algorithms show an upward trend, while the proposed MAVTO algorithm remains stable. The RPD of the MONSA algorithm is higher than the other three algorithms because the MONSA algorithm selects the UAV node with the highest comprehensive evaluation value of bandwidth and computational resources during offloading decision-making, without considering the load of the UAV nodes. This may lead to a high load on certain UAV nodes, resulting in long waiting times for tasks and a decreased task completion success rate. Figure 11b–d show that as the task deadline increases, the performance gap between the algorithms gradually narrows. This is because as the deadline constraint of tasks becomes looser, more tasks can be completed within the deadline, and the total number of offloaded tasks remains constant. As a result, the optimization space of the MAVTO algorithm decreases. Therefore, as the deadline increases, the difference between the MAVTO algorithm and the other algorithms gradually reduces. From the performance comparison results, it can be concluded that the MAVTO algorithm outperforms the other three algorithms in different deadline ranges. The MAVTO algorithm is more suitable for application scenarios with smaller task deadline ranges when the goal is to maximize task completion success rate.

6. Conclusions

This paper addressed the problem of task offloading and resource allocation in high-speed VEC systems, particularly within UAV-assisted networks. The proposed MAVTO algorithm, which is based on vehicle mobility prediction and container-based virtualization, optimizes task offloading decisions to maximize the task completion success rate while considering vehicle mobility and resource constraints. The framework integrates direct, predictive, and hybrid offloading modes to improve the flexibility and efficiency of task execution. Simulation results show that MAVTO significantly outperforms traditional algorithms in terms of task success rates, especially in scenarios involving high data complexity and stringent deadline requirements. These results validate the effectiveness of using a multi-drone collaborative offloading strategy in VEC networks. Future work could explore further refinements in UAV coordination and load balancing for enhancing scalability and performance in even more complex vehicular environments.