## 5 Using MEC to Augment the Computing Capabilities of Vehicles
### Task Offloading  
In ref. [96], researchers investigated a system for IoV that utilizes a nearby EP to help with executing tasks and to reduce the network traffic load. They split tasks into two parts: one is carried out locally, and the other is sent to the EP via wireless channels. However, estimating channels accurately is tricky because of cars' mobility. To preserve user QoE despite inaccurate channel estimation and to reduce costs, they set up an optimization problem in the first phase. In the second phase, they use a smart approach combining DRL and Lagrange multipliers to solve that optimization problem. DRL predicts how to select the best way to handle tasks, and the Lagrange multipliers help manage bandwidth. In ref. [97], authors introduced a new method called Vehicular Edge Computing with Network Slicing and Load Balancing (VECSlic-LB) for handling computing tasks in connected vehicles. This approach combines network slicing and load balancing, aiming to efficiently distribute computation tasks among cars and RSUs or gNBs (5G base stations). Inspired by considering SDN features, VECSlic-LB manages these tasks in a centralized method, optimizing computing resources in RSUs and gNBs. To deal with the challenge of migrating tasks from vehicles to other locations, VECSlic-LB formulates an integer linear program. This method maximizes the number of tasks offloaded from vehicles. VECSlic-LB calculates these tasks for different network slicing setups, and it improves resource usage by up to 48% compared to existing approaches. The Combinatorial Multiarmed Bandits (CMAB) [98] concept was used in work [99], which learns the task-offloading strategy by selecting the task-offloading endpoints effectively in a distributed way. This strategy relies on replicating tasks at various end nodes, without squandering system resources and reducing the duration of the system as a whole. Replication increases reliability by reducing task failures and increasing the successful completion of tasks. However, it also causes network overhead and requires more computation resources. The inherent mobile nature of VNs causes additional issues in the IoV context. For instance, a mobile might move beyond the coverage area of the MEC host before its task is completely processed, making the implementation of an efficient offloading mechanism more challenging. In ref. [100], the path of the cars is defined in a fixed area. Consider the scenario where each vehicle is linked to a task that needs to be completed and that task can only be sent to the server that handles it during the task-offloading phase. If there is a lot of traffic in this fixed area [100], it is extremely likely that the same MEC server is processing all the tasks. Therefore, the probability of task overload and queueing latencies drastically increases, which diminishes users' QoE. The authors propose a method for migrating tasks to address this issue. Performing tasks can occur either locally or offsite. When handling tasks offsite, a server capable of offering the necessary services is chosen, which cuts down the average task completion delay. The method used in this work takes into account the network status and makes decisions dynamically, however, it does not consider available computation and storage resources. In ref. [101], authors suggest using a Double Deep Q-network (DDQN) to collaboratively offload tasks among vehicles, aiming to minimize the system delay, which includes the delay of performing tasks in vehicles, the delay of creating connection links among vehicles, and the latency of performing tasks at cooperative vehicles. Nearby cooperating vehicles are identified and tasks are divided among them according to an ideal proportion computed by the neural network of the DDQN structure. Additionally, a task-offloading approach using the DDQN algorithm is suggested to improve flexibility. However, due to the scarce power of computation units of the vehicles, this approach is useful for tasks with low resource requirements.