Mobility and Deadline-Aware Task Scheduling Mechanism for Vehicular Edge Computing

Vehicular Edge Computing (VEC) is a promising paradigm that provides cloud computing services closer to vehicular users. In VEC, vehicles and communication infrastructures can form pools with computational resources to meet vehicular services with low-latency constraints. These resource pools are known as Vehicular Cloud (VC). The usage of VC resources requires a task scheduling process. In this case, depending on its complexity, a vehicular service can be divided into different tasks. An efficient task scheduling needs to orchestrate where and for how long such tasks will run, considering the available pools, the mobility of nodes, and the tasks deadline constraints. Thus, this article proposes an efficient VC task scheduler based on an approximation heuristic and resources prediction to select the best VC for each task, called MARINA. MARINA aims to analyze the behavior of vehicles that share their computational resources with the VC and make scheduling decisions based on the mobility (VC availability) of these vehicles. Simulation results under a realistic scenario demonstrate the efficiency of MARINA compared to existing state-of-the-art mechanisms in terms of the number of tasks scheduled, monetary cost, system latency, and Central Processing Unit (CPU) utilization.

instance, self-driving vehicles, real-time learning, and artificial intelligence-oriented applications are expected to be largely deployed, producing lots of data with low latency requirements [5], [6].
Vehicular Edge Computing (VEC) emerged as a promising paradigm to move communication, computing, and storage resources closer to vehicular users [7], [8].In this sense, VEC aims to reduce latency while decreasing the heavy traffic from the network core [9].VEC considers a set of Vehicular Cloud (VC) to allow users to request resources to meet application/service demands that require computational power above the locally supported ones.A VC group shares computational resources, such as processing units and storage capacity, available in a set of vehicles (i.e., either moving or parked vehicles) and infrastructure (i.e., Roadside Unit (RSU), 5G Base Stations (BSs), network controllers, and Remote Server (RS) in the Internet cloud) nodes to provide cloud services, such as the Infrastructure-as-a-Service (IaaS) [10].
In this VEC scenario, each network controller, called VEC controller, is responsible for coordinating a predefined city region, such as a neighborhood, for forming the VCs based on the regional knowledge about the vehicle and infrastructure nodes through the Vehicle-to-Infrastructure (V2I) communication.Hence, the VEC controller can be responsible for two main processes, namely, VC formation and task scheduling [11], [12], [13].The VC formation process concerns an efficient grouping and management of computational resources available by the network entities to form a VC [4], [9].On the other hand, the task scheduling process concerns the efficient use VC resources, i.e., the tasks will be scheduled to be processed in a given VC.Therefore, these two processes are crucial to group computational resources and provide cloud services closer to vehicular users.Advance the state-of-the-art in the task scheduling process is essential to the success of connected autonomous vehicle ecosystems.New approaches to efficiently select and decide where and when tasks will be scheduled in dynamic and mobile vehicular environments are required.At least three key issues need to be addressed for developing an efficient task scheduling mechanism to meet users' demands in VEC scenarios, namely (1) Vehicular Mobility; (2) Deadline Constraints; and (3) Monetary Costs.
The Vehicular Mobility is one of the main challenging factors for the efficient performance of vehicular scenarios with support to VEC applications since vehicle mobility causes several changes in network topology and (including intermittent connections) [14].For instance, vehicular mobility This work is licensed under a Creative Commons Attribution 4.0 License.For more information, see https://creativecommons.org/licenses/by/4.0/Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
causes an unexpected disconnection between VC members and the VEC controller, leading to a fluctuation in terms of the number of available resources in the VC and/or causing the task processing results loss, impacting the system efficiency.Hence, the mobility of vehicles has a high impact in the number of tasks attended/scheduled [15].In this sense, it is essential to consider vehicular mobility information to estimate vehicles' location, which can be used to estimate the future resource availability in each VC.This aims in selecting stable VCs to run the tasks, where VC's stability refers to its low rate of resource variability over time.However, how to predict these vehicular dynamics accurately and explore their spatiotemporal correlation is still an open issue [16].In this sense, Recurrent Neural Network (RNN) can use in vehicular mobility estimates due to their high accuracy rates in general form predictions [17], [18], [19].
The Deadline Constraints represent the time that tasks can wait to be served.In other words, it is important that the obtained result must be returned to the requesting entity before a hard deadline.Otherwise, this result becomes useless [20], [21].Therefore, the tasks' deadline constraints can be better observed and considered from a resource availability estimation in the VCs, making it possible to infer the processing time and the service probability to increase the scheduled and completed tasks rate.Also, the system latency is minimized by prioritizing tasks with less processing time.The system latency represents the waiting time and the time that a task will remain running in a given processing configuration.
Finally, Monetary Cost refers to the price of using computational resources, such as the pay-as-you-go basis commonly used in cloud computing IaaS architectures [1].For instance, the monetary cost can be minimized by knowing the task processing time, making using computational resources less costly for the end users.In addition to task deadline constraints, the tasks often have high processing requirements.Scheduling tasks with high computational power requirements, such as traffic image processing or real-time learning, is a challenging issue in a highly dynamic vehicular environment [22].In other words, the task scheduling mechanisms must make accurate decisions considering all the tasks' computational requirements, regardless of the variability of these requirements in different classes of applications.Besides, scheduling mechanisms must always minimize costs for end-users.
To the best of our knowledge, a unique solution that considers mobility-awareness, deadline constraints, and monetary costs for decision-making in a task scheduling process is still an open issue and remains a challenge.Thus, this article proposes MARINA (Mobility and deAdline-awaRe task schedulIng mechaNism for vehiculAr edge computing) to maximize the number of tasks scheduled while minimizing the monetary costs of utilizing VC's resources.The MARINA runs on VEC controllers to coordinate the task scheduling in multiple VCs.In MARINA's operation, a vehicle without enough computational resources to run a specific task can forward this task to be processed somewhere in the vehicle ecosystem.In this sense, MARINA selects a set of tasks to be scheduled in real-time in each available VC based on the Pareto Optimality and Bin Covering Problem (BCP).Pareto optimality allows the joint minimization between the deadline and estimated processing time.Besides, the BCP makes it possible to find the best fit for the minimization provided by Pareto, always seeking to maximize the number of scheduled tasks.MARINA also considers a Long Short-Term Memory (LSTM) to predict resource availability in each VC based on vehicular mobility information.Hence, MARINA prioritizes scheduling tasks in VCs with more available resources to maximize the fulfillment of demands in as few rounds as possible.Simulation results show that, compared to state-ofthe-art solutions, MARINA can schedule more tasks while minimizing monetary cost and system latency.
The main contributions of this article are the following: • The use of vehicular mobility information and an LSTM architecture to predict the available resources in each VC with high accuracy.
• An efficient task scheduling mechanism that considers the task deadline, mobility-awareness, and monetary costs in its decision-making process.Thus, it schedules a high number of tasks without increasing the monetary cost of using VC's computational resources.
• A combined approach that leverages low-computational complexity techniques to minimize the monetary cost and maximize the number of scheduled tasks.
• A detailed performance evaluation with a realistic mobility trace, showing the benefits of vehicular mobility information for the task scheduling process compared to other state-of-the-art approaches.The remainder of this article is structured as follows.Section II describes key related works.Section III introduces the system model, problem definition, and mobility prediction model.Section IV presents the MARINA's operation.Section V discusses the performance evaluation and results obtained.Finally, Section VI presents the conclusions and future works direction.

II. RELATED WORK
This section presents state-of-the-art research regarding task scheduling in VCs.In general, scheduling approaches can be classified into three perspectives.(1) Centralized, where an entity has a scenario holistic view and makes more accurate decisions.This approach has the advantage of an environment global view, but maintaining this knowledge is a challenge for system scalability; (2) Decentralized, which has different agents that make decisions based on local knowledge.This approach does not need to maintain global knowledge, but the accuracy of decisions is compromised in some cases; and (3) Hybrid, which combines the advantages of two previous techniques to increase system efficiency [31].Observing the advantages of each scheduling approach, we consider only the Centralized and Hybrid approaches due to the essential role the 5G network can play in these specific scenarios [32].
Pereira et al. [24] proposed FORESAM, a policy for scheduling tasks in VCs based on the fog computing paradigm for urban environments.Specifically, vehicles cooperate with the set of BSs to create a pool of resources for vehicular services.FORESAM decides whether resources are available based on Analytic Hierarchy Process (AHP) mathematical method.However, FORESAM employs greedy decisionmaking, where in case a task does not fit into the VC, it is discarded, impacting the overall system efficiency.Some works consider optimization algorithms for decisionmaking.Da Costa et al. [13] introduced CRATOS, a combinatorial optimization-based mechanism for task scheduling in VCs.CRATOS considers the arrival of tasks in real-time and regardless of each other following a Poisson process.The VEC controller located at a higher level in the network receives the resource requests (which are the tasks) and schedules them in the available VCs. 0/1 Knapsack Problem is used to schedule tasks optimally given the contextual configuration (tasks' input size and VC's available computational resources).However, CRATOS does not consider tasks with deadlines higher than 1s in its decision process.Also, the user defines how much it will cost to process his task.Hence, CRATOS would not fit into an actual application, as the monetary cost model used by cloud providers is different.
Dai et al. [25] presented a probabilistic algorithm for cooperative task scheduling in VCs.The authors formulate Cooperative Computing Offloading (CCO) problem by modeling the procedure for uploading, migrating, and scheduling tasks based on queuing theory to minimize the delay in the system.The BS makes online scheduling based on the calculated probability provided by a probabilistic offloading algorithm.Three aspects are considered for computing the offloading probability: the time that vehicles will stay in BS's coverage range; the density of vehicles; and resources available in the BS.However, this computation is offline, which means it is executed on a high-performance server in the Internet cloud.The probability that the BS will meet demand is computed before the process of task arrival, which can degrade the system's performance in a highly dynamic environment.Finally, VCs considers only the resources available in the BSs.
Luo et al. [7] presented a detailed analysis of the delay and cost of task offloading for VCs.The authors first establish an offloading framework with communication and computation for VC, considering tasks with different requirements.In this sense, a multi-objective optimization problem is formulated to joint minimization the delay and the monetary cost.A Particle Swarm Optimization (PSO)-based computation offloading (PSOCO) algorithm is proposed to obtain the Pareto-optimal solutions.However, due to its bio-inspired approach, its convergence time can impact the algorithm's performance.
Some works use queuing theory to model the vehicular scenario.Hattab et al. [23] proposed a polynomial time algorithm for task scheduling in VCs with different resources.First, the algorithm classifies tasks according to the completion and wait times.Afterward, it selects a subset of tasks with the lowest proportion and then solves a sequence of Linear Programs.They formulate the bottleneck assignment problem, where the goal is to minimize the completion time of the scheduled tasks in the available VCs.However, this work does not consider the vehicle mobility for VC formation, i.e., VCs are stationary, and the proposed algorithm considers only one VC.Some approaches use Machine Learning (ML) techniques for the scheduling decision process.Kazmi et al. [30] proposed a task scheduling mechanism for mobile vehicular networks using a Deep Reinforcement Learning (DRL)-based approach.The approach considers electric vehicles in task processing.The focus is to make energy consumption more efficient.Mobility information considers the relative mobility and kinematic equations to estimate the communication phase between two vehicles.However, an evaluation comparing the solution with state-of-the-art is still necessary.Furthermore, the BS does not cooperate in task processing, decreasing system efficiency.Gao et al. [27] present a solution for task scheduling that aims to minimize service delay and energy consumption.The authors use a Deep Q-Network (DQN) approach for scheduling decision-making and a Gradient Descent (GD) method for Central Processing Unit (CPU) frequency allocation.However, the work needs to discuss the solution convergence time, which depending on the scenario, can make it unfeasible for more dynamic environments.
Chen and Xu [21] presented an RL-based algorithm for task scheduling in VC, called DATE-V, which provides resources for scheduling tasks with deadline constraints in the VCs.DATE-V is based on a contextual and combinatorial Multi-Armed Bandit (MAB) learning framework.The algorithm uses vehicle contextual data (i.e., speed, location, and computational resources available) to infer the probability of completing a task replication under random vehicles.DATE-V also replicates the task received in the BS and sends such replications to different vehicles to ensure service attendance and increase its success rate.However, these replications potentially lead to a costly solution, given that defining the number of replications is challenging.Liu et al. [26] proposed a vehicle-assisted task scheduling approach for mobile users, considering delay constraints.The authors formulate an optimization problem to maximize the long-term usefulness of VC's resources.Considering stochastic vehicle traffic, dynamic computation requests, and time-varying communication conditions, the problem is later formulated as a Semi-Markov Decision Process (SMDP).Two reinforcement learning methods are proposed to obtain the optimal computation offloading and VC's resource allocation, namely (i) Q-learning based and (ii) Deep Reinforcement Learning (DRL) methods.However, given the nature of DRL approaches, it is necessary to train the model in advance.Thus, the solution depends on the offline phase for its execution, which can negatively impact highly dynamic scenarios.
Some works consider mobility prediction to estimate vehicle positions and ensure reliability in the task scheduling process.For example, Misra and Bera [28] proposed a mobilityaware task scheduling scheme named Soft-VAN, which aims to minimize task computation delay in a software-defined vehicular network.Soft-VAN consists of two phases, fog node selection and task scheduling.An Integer Linear Program (ILP) is solved in the first phase to get the optimal number of fog nodes required for a given network.In the second phase, the authors formulate an optimization problem to minimize the delay in task computation and consider the vehicle's mobility and the parameters associated with the scheduling decisions.However, the algorithm depends on an offline phase to identify fog nodes to assist the delivery process of the tasks performed.Also, they do not consider the vehicles' dynamics to make the processing decisions for the task, only to send the final result.
Wu et al. [29] investigate the task scheduling and resource allocation optimization problem by considering the vehicular mobility effect in the VEC environment.Specifically, the authors formulate the joint optimization problem from a Min-Max perspective to reduce the overall task latency.Then they decompose the non-convex problem into two sub-problems, one-to-one matching and bandwidth resource allocation.Also, considering a vehicle's relatively stable moving patterns in a short period, the authors further introduce mobility prediction to design a mobility prediction-based scheme to obtain a better solution.However, the mobility model is unrealistic since vehicles need constant acceleration during the task scheduling.
Table I summarizes the main characteristics of reviewed studies considering system design, the entities forming the VCs, the approach used in the task scheduling process, and vehicular mobility information.Based on the state-of-theart analysis, we conclude that centralized approaches allow the constructed knowledge to be global and more accurate.However, the network's overload levels can be high and overload the centralized entities, raising the monetary costs of using computational resources [13], [23], [28], [29].In another direction, some works consider hybrid architectures, enabling to build on regional knowledge without burdening a central entity and the network's core with high message exchange [7], [21], [24], [25], [26].A VEC architecture allows the cooperation of computational resources among vehicles and BSs for VCs creation, allowing resources to be always available.For instance, considering only vehicles, the approaches are limited to regions with high vehicle flows to maintain the high resource availability.On the other hand, considering BS as an entity that composes the VCs enables more effective management both in forming VCs and using resources, making the processes more stable and reliable [7], [24], [26], [29].
In this sense, the techniques used should be less computationally complex, and thus their decision time does not negatively impact the system's overall efficiency.Furthermore, creating knowledge about the dynamics of computational resources through vehicular mobility is essential to estimate future resource availability.In this sense, approaches can make better decisions, relating task requirements, such as deadlines, and computational resources available in the future, reducing the task scheduling interruptions and the monetary cost employed by this process.However, only a few studies consider vehicular mobility information in their decisionmaking processes [28], [29], [30].To the best of our knowledge, only MARINA considers every critical characteristic previously mentioned not provided by existing task scheduling mechanisms in a VEC environment.In other words, MARINA considers a hybrid architecture to avoid network overload, VCs formed by vehicles and BSs to increase resource availability, a polynomial-time heuristic for decision making, and vehicle mobility information to estimate future computational resources in each VC.

III. SYSTEM MODEL
This section introduces the MARINA task scheduling in VEC scenarios, which considers available resources, tasks' deadline constraints, and vehicular mobility for decisionmaking.We first overview the designed system and then illustrate the VCs formation process, mobility prediction approach, and monetary cost model.Finally, we formulate the problem.Table II summarizes the key notations used in this work.

A. Overview
Figure 1 shows the system architecture composed of vehicles, BSs, VEC controllers, and an RS in the Internet cloud.We consider a scenario composed of x moving vehicles, denoted as u i ∈ U = {u 1 , u 2 , . . ., u x }.Also, we consider a set of BSs deployed in the city, denoted as b y ∈ B = {b 1 , b 2 , . . ., b m }, where m is the total number of BSs.Each BS has wired communication (e.g., optical fiber) with the RS and could provide processing power and storage capacity  on the network edge, decreasing response time for some applications [26].Also, each BS on the 5G network has an Xn interface, which allows the information exchange between neighboring BSs and assists in the handover process [33].Each vehicle has an On-Board Unit (OBU) that allows communication with the neighbor devices through Vehicle-to-Everything (V2X) communication.For instance, vehicles can associate with a BS and communicate with an RS to access the Internet, request resources for data processing, and share their resources.
We used a BS-UE (Base Station-User Equipment) method based on the maximum signal to interference plus noise ratio (SINR) for this association process.In this case, a vehicle will associate with a BS which provides the Max-SINR [34].The Max-SINR ensures that the vehicle is associated with only one BS [35].After the association between vehicle and BS, the BS sends the vehicle' information to RS.
In this scenario, we consider the city divided into R regions (neighborhoods), and each region has at least one BS.We also consider that each VEC controllers cover a given region R, and it is randomly deployed in a given BS of such region.It is important to mention that VEC controllers are randomly deployed in the scenario, since this is not our research focus.We denote the set of VEC controllers as , where e = |R| is the total number of controllers, and directly related to the number of regions R. Vehicular Cloud (VC) formation process -from Base Station (BS) association to scheduling -based on a prediction approach using Long Short-Term Memory (LSTM).
Each controller is responsible for managing the BSs in its city region, where this management includes the VC formation and task scheduling processes.
In the VC formation process, the VEC controller requests to the RS the information about BSs and vehicles to build their regional knowledge.In this case, the Publish/Subscribe paradigm is considered to obtain the relevant information without inserting unwanted traffic on the network.The VEC controller subscribes to BSs' updates in its region.Thus, the RS plays the role of Publisher, and the regional VEC controllers play the role of Subscribers.Based on the information about the BSs, the VEC controllers could starts the VCs formation process.In this sense, VCs can be classified in different regions according to BSs' positions in the city.Considering that the number of VCs is the same number of BSs in the scenario, we can denote a set of VCs by v j ∈ V = {v 1 , v 2 , . . ., v m }, where m is the total number of VCs.A VC consists of a set of nodes (i.e., vehicles and BS) that can share two types of computational resources ω and φ, namely CPU-cycle frequency (processing power) and storage capacity, respectively.
In this context, ω u i denotes the vehicle's CPU-cycle frequency, φ u i denotes the vehicle's storage capacity, ω b y denotes the BS's CPU-cycle frequency, and φ b y denotes the BS's storage capacity.Therefore, each VC is represented by a tuple {id, resources vehicles , resources bs , resources total }, where id is the VC's unique identification, resources vehicles is the total resources of vehicles (ω u i and φ u i ), resources bs is the total resources of BS (ω b y and φ b y ), and resources total is the sum of resources in the VC ( j and j ), calculated as In short, the total amount of processing power resources j and j of each VC v j is the sum of the shared resources from each vehicle u i and BS b y belonging to a given VC v j .Figure 2 depicts the VCs formation process based on a spatial layer to add temporal information about vehicle mobility and their computational resources.We assume that BS is aware of vehicle mobility to add the temporal layer in the VC formation, which is possible to take advantage of beacons already exchanged by vehicles to obtain the vehicles' Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.information, avoiding extra overhead.Specifically, each vehicle transmits periodic beacons containing its id, computational resources, speed, positioning, and route.In this sense, the BS receives such information and forwards it to the RS.Based on the information requested by the VEC controller to the RS, the VC formation process begins with mapping which BS holds which vehicles in its coverage (Label 1 in Figure 2).Given the history of associations in the BSs, it is possible to decompose this information into time series representing the time variation of vehicles in each VC (Label 2 in Figure 2).Spatiotemporal information on the dynamics of resources in each VC is created and stored in the regional VEC controller.Considering the importance of estimating the resources available in a VC to make task scheduling decisions with high precision, an LSTM-based prediction model is used in this step.With this, we can define a time window and estimate the resources available in each VC (Label 3 in Figure 2).Finally, a resource repository stores the predicted information, and the MARINA consults such spatiotemporal information for decision-making (Label 4 in Figure 2).Therefore, it is possible to estimate resources available in each VC in k time slots by considering the spatiotemporal information.In this sense, we can represent the resources available at VC in each k ∈ K by jk and jk .

B. Mobility Prediction Model
We consider a mobility prediction process to add a temporal layer to the spatial information about vehicle mobility and their computational resources, which is essential in task scheduling scenarios for VCs environments.In this sense, we need to estimate the vehicles' dwell time in each VC, enabling to obtain information on the VCs' computational capacity in a predefined time window.
Several works consider Markov models, Extended Kalman Filter (EKF), Support Vector Regression (SVR), and Autoregressive Integrated Moving Average (ARIMA) models to predict vehicular mobility [36], [37].However, neural networks have gained increasing attention from academia and industrial groups for the accurate predictions offered by their various models.In this scenario, an RNN is a deep learning approach that extends the traditional feed-forward networks with internal cycles [38].These internal cycles allow tracking information sequences to create spatiotemporal knowledge through current and past inputs.LSTM is an advanced version of the RNN architecture developed to model chronological sequences and their long-term dependencies with greater precision [39].
In this sense, to employ an RNN in MARINA, we need to build a dataset containing resources available information in each VC.The model learns from past dynamics and accurately estimates the available resources in a given time window.To this end, the information about user association in a given BS is stored in the RS.In this way, when the VEC controller starts the VC formation process, it is easier to aggregate and create each VC's resources time series.Let Z = {z 0 , z 1 , . . ., z k } be a vector that represents the dataset, in which each element consist of a tuple z k = {timestamp, resources} representing a simulation step and resources available in this step, for each VC, as shown in Figure 3.
In summary, the predictor model is defined as f = ϒ • , where • indicates applying function ϒ on function 's output.The feature learning machine (•), which converts inputs into features, is utilized to process the input data first.After that, the next step involves the representation function ϒ(•), which maps features into a prediction [17].In this sense, the prediction process of the next available resources for each VC is given according to where z k+1 j represents the next available resources of the VC j considering its previous observations z k j .Figure 4 shows how the RNN employed by MARINA works.In summary, the RNN receives an input z k representing a set of tuples, and for each VC, it employs an LSTM as a recurrent layer.The dynamic employed by LSTM is to store past information in long-term memory to explore the internal relationships between each prediction.The information persists across the network and is used in comparisons to improve prediction estimates [40].Finally, the output represents the future resources available in each VC given a time window k.

C. Problem Definition
Each task t l ∈ T = {t 1 , t 2 , . . ., t n } is denoted by a tuple {id t l , s t l , w t l , D t l } where id t l means the unique task identification, s t l denotes the size of task input data, w t l is the numbers of CPU cycles required to complete the task, and D t l is the deadline constraint.In this way, the scheduling mechanism aims to optimize scheduling a set of tasks T ′ ⊂ T to be processed in the available VCs without increasing monetary costs and scheduling as many tasks as possible.
The computational resources of the same VC are shared among different tasks scheduled in that cloud.Thus, j for calculating the computation delay for a given task must be updated according to the degree of sharing of that resource within the VC, represented by j .The value of j is divided by the number of tasks |T ′ j | that have been scheduled for this Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
VC, according to According to the literature, all processes that add delay must be considered to compute the computing delay for a task scheduling in VC, [20], [21], [41].For example, the transmission delay of the resource request, the scheduling delay between BS and VC, the task computation delay in the VC, and the entire reverse path until the requesting obtains the result of its task.However, this article only considers the task computation delay in the VC.This is because this metric simplifies the understanding of the efficiency of task scheduling solutions, given that the entire network infrastructure is the same for all approaches.The computation delay d t l j can be obtained based on the required CPU cycle w t l divided by the CPU-cycle j of the server (VC), according to As noted, each task has deadline constraints in its configuration, represented by D t l .Therefore, scheduling solutions must consider this metric to ensure that these restrictions are respected and tasks are successfully processed in the VCs.In this scenario, if d t l j ≤ D t l , the task was successfully scheduled and executed in the v j VC.Also, when a task is scheduled and starts to be processed, there is a cost associated with this execution.The monetary cost is modeled as where d t l j is the t l processing time in v j ∈ V and w t l is its CPU cycles required.Price(t l ) is the resource price, calculated as Price(t l ) = 11.444 if t l uses b y 's proc.resources, 5.016 if t l uses u i 's proc.resources.
These costs are based on instances with GPU capacity available on Amazon EC2, 1 such as g4ad and g3 for BS and vehicle, respectively.When a task arrives in the system, the VEC controller must select the best VC to process this task.This selection must consider the monetary cost of using VC's resources.In this case, we must first apply a Pareto optimization for a joint minimization between processing time and task deadline.These metrics are directly related to monetary costs.Thus, the Pareto set allows us to find, among the queued tasks in the system, a set P that jointly minimizes the processing time and the deadline.With the Pareto set P defined, which has the tasks that imply a lower monetary cost, we can select from this set the tasks that will be processed in the VCs, represented by T ′ .
To coordinate this selection, we can reduce this problem as a Bin Covering Problem (BCP).BCP solves the items' packaging problem with different weights in a finite set of bins.Given a set of items, the BCP decides how many items can be stored in the same bin.The algorithm aims to maximize the number of items stored.However, given that BCP is a 1 https://aws.amazon.com/ec2/dedicated-hosts/pricing/combinatorial NP-hard problem, we use an approximation heuristic First-Fit Decreasing (FFD) to find a solution to our problem instances in polynomial time [42].With the FFD heuristic, they are sorted in non-increasing order of sizes before placing the items in bins.Each item attempts to be placed in the first bin that can accommodate this item.If no bin is found, a new bin is observed, and the item is put in this new bin.FFD can be implemented to have a running time of at most O(n log n), where n is the number of items (tasks).
In this context, we formulate a task scheduling problem by maximizing the number of tasks served while minimizing the cost monetary of VC's resources used in this process.It should be noted that minimizing the monetary cost is provided by the step that finds the Pareto set P. Furthermore, maximization is performed by selecting tasks in the given Pareto set.In this way, we can define the problem as follows: subject to d t l j ≤ D t l , j ∈ V, l ∈ P, The (9) guarantees that the task deadline is respected, avoiding rescheduling.The (10) and (11) ensures that VCs' storage and processing limits are respected during the k required processing time intervals.

IV. EFFICIENT TASK SCHEDULING MECHANISM
FOR VEC ENVIRONMENTS This subsection describes an efficient task scheduling mechanism for VEC, called MARINA.We consider a scenario composed of multiple VCs coordinated by regional VEC controllers, which runs MARINA for task scheduling.MARINA finds the Pareto set to ensure monetary cost minimization and considers the BCP to resolve the problem in P1 of equations (8 et seq.).

A. MARINA's Operations
In short, MARINA first searches for the Pareto set P using the joint minimization of task processing times and task deadlines as a criterion, creating a vector for each criterion (processing time and deadline).Therefore, the vectors are arranged in a 2-dimensional plane, and the Pareto set is found.Figure 5 presents an example of searching for the Pareto set in a queue with 24 tasks.We can obtain a Pareto solution set in 2-dimensional in polynomial time O(n log n) [43].This step ensures that the tasks selected to be verified with BCP already have joint minimization of estimated processing times and deadline constraints.In this case, this directly impacts the overall monetary cost.As discussed earlier, the VEC environment is highly dynamic due to vehicular mobility.Therefore, many works model VEC environments as an M/M/1 queue to bring the system's dynamics closer to the real world [20], [44].However, in realistic scenarios, several entities can process existing requests.Also, it is essential to consider that the service time of the queued tasks is defined by the task requirements, such as size, required number of CPU cycles, and deadline constraints [20].Thus, we consider that our VEC environment works as an M/G/z queue.The tasks arrive in the system following a Poisson process (M).The service time of the tasks is defined by their characteristics (that is, it follows a general distribution G).Finally, the system has more than one server (z) to attend to requests, which are the various VCs formed in the scenario.
When tasks arrive in the system, they are queued.Traditional approaches schedule tasks based on the organization in that queue.However, as the processing time and deadline of the tasks are crucial factors, MARINA prioritizes the minimization of these aspects in its decision-making process.That is, if a scheduling choice returns a lower processing time than another, the use of resources will also be minimized.In the same way, the monetary cost associated with the lower processing time will also be minimized.However, to perform this selection, MARINA needs to know the processing time of all queued tasks.In this step, Equation ( 5) estimates the processing time since it is unknown how many tasks will be scheduled in this VC.
Algorithm 1 shows how our VEC system works over time.Initially, the data structures that store the tasks in the system, the tasks in execution, and the VCs of the scenario are created (Lines 1 and 2).In a dynamic environment, tasks are generated independently, following an arrival rate that can be defined after observing the system's behavior.Thus, each time slot k ∈ K and following a Poisson process, a set of tasks arrives in the system to be executed (Line 3).The task set is queued and goes on standby to be scheduled and executed (Line 4).For the task scheduling process to occur, it is necessary to know the VCs available in the scenario.Thus, if k is equal to the VC formation interval, the formation process occurs, and the VC information is maintained until the next interval (Lines 5 and 6).If the Q queue is not empty (Line 7), the queued tasks and the set of VCs are passed to the task scheduling mechanism (Lines 8 and 9) presented in Algorithm 2. After the scheduling process, verification is performed at each time slot k if the tasks in the R queue (run queue) reached their If the task has completed its execution, the monetary cost is calculated, and the task is removed from Q and R queues (Lines 12 and 13 and 14 and 15).Otherwise, the task execution estimate is updated, as other tasks may have left the system, and more resources may be available at the corresponding VC (Line 16 and 17).We emphasize that Algorithm 1 is executed in the VEC controllers.After a VC formation process, task scheduling is triggered, and information such as available VCs and the set of tasks is provided to the MARINA.In summary, Algorithm 2 describes the MARINA's operations in a VEC controller.In this sense, the controller gets the VC set V and task set T , which gives the T ′ task scheduling set as an output.The set V is sorted non-increasing, so VCs with more available resources are prioritized (Line 1).Two vectors are created based on T , the first P T for the estimated processing time, and the second D for deadlines (Lines 3 and 4).MARINA calls the procedure PARETOSET with configuration for joint minimization of vectors P T and D (Line 5).The procedure returns a set P containing the ID of the tasks that are part of the minimal Pareto set.With the Pareto set defined, the BCP uses this task subset to schedule tasks, considering other computational requirements of each task (Line 6).In this step, BCP returns a subset of candidate tasks S ′ .Also, the total number of resources needed for this returned set is calculated (Line 7).After that, for each task in the set, it is verified if the VC will have available resources until its deadline D t l (Lines 8 and 9).If not, that task is removed from the set S ′ and its required resources are removed from the total resource estimate (Lines 10 and 11).If so, its actual processing time is calculated (Line 13).If the processing time is longer than its deadline, the task is removed from S ′ and will be rescheduled in the Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Algorithm 2 Abstraction of MARINA
Input: task set T and VC set V Output: scheduled tasks T ′ 1 V ← decreasing order of available resources

B. Computational Complexity
The MARINA's time complexity is analyzed as follows.MARINA has three main stages.The first stage runs in time O(n log n) in the worst case, which is the time complexity to find Pareto set [43].In the same direction, the BCP algorithm needs O(n log n) to sort non-increasing order of items by sizes (CPU cycles) and to cycle through all the items to be checked.Also, the number of tasks decreases based on the select VC with maximum resources available, where the number of VCs is represented by m.In the worst case, the second and third stages have linear O(n) complexity to check the deadline and computation delay constraints for each temporarily scheduled task S ′ .Finally, a constant F is added that represents the computational complexity of the prediction step, which may vary according to the technique used.In summary, the algorithm's time complexity can be described as O(max{m} + n log n + F) in the worst case, with m being the number of VCs and n the number of tasks.In this context, MARINA is a polynomial-time algorithm.

V. EVALUATION
This section describes the methodology and metrics used to evaluate MARINA performance in a VEC environment.First, we show the simulation environment, including implementation, parameters, and evaluation metrics.Second, to better understand the resource prediction model used, we present LSTM results compared to other models in the literature.Finally, we present and discuss the results of task scheduling using the prediction model employed and the main insights.

A. Simulation Environment
The experiments were carried out with the Simulator of Urban Mobility (SUMO), in version 1.11.0.The algorithms were implemented in Python 3.8 and connected to SUMO through the TraCI interface.We considered a deterministic realistic mobility trace from TAPAS Cologne2 project, which reproduces vehicle traffic in the city of Cologne, Germany, as shown in Figure 6(a).The trace contains vehicular mobility from 6 to 8 AM on a typical working day and covers a region of 400 km 2 .However, only a city submap with 114 km 2 was picked for our simulation experiments because it contains a greater variability of vehicles over time and up to 700 vehicles at peak times.The simulation time was 700 s, with 100 initial seconds of warm-up, as shown in Figure 6(c).The simulations were run 33 times to obtain a 95 % confidence interval.
The Bag-of-Tasks (BoT) applications were considered since they have no dependence on each other and can be executed out of the submission order.The tasks' deadline varies between 3, 5, and 7 seconds.This is important to generalize the representation of possible application classes.The VC formation interval was defined in 5 seconds.The scenario considers different task arrival rates (i.e., 1, 3, and 5 tasks/second) following a Poisson distribution [20], [25], [41].Also, the size s t l of each task is [1,10] MByte.The number of CPU cycles w t l required to complete the task is fixed in [1, 30] Million of Instructions (MI).We consider that a vehicle u i makes available resources (CPU-cycle capacity and storage capacity) in 1 unit/vehicle, the number of CPU cores ω u i (CPU-cycle capacity in Million of Instructions Per Second (MIPS)), which without loss of generality is proportional to the storage capacity φ u i (1 MByte).In this way, we can get an idea of the impact that sharing lower resource units employ on the system.The communication ranges of vehicles and BSs were 250 m and 2000 m, respectively.
In addition, we consider 14 BSs, and each one is capable of sharing processing and storage resources, where such values were configured at 15 MIPS and 15 MByte, respectively.We deployed 4 VEC controllers, and each can manage up to 4 neighboring BSs.We deployed the BSs in the city following positioning information provided by the TAPAS Cologne project, as shown in Figure 6(b).Moreover, we used the TensorFlow framework version 2.8.2 to implement the RNN [45].We also consider a Graphics Processing Unit (GPU) NVIDIA(R) Tesla V100 with 5120 CUDA cores and 32 GB of VRAM to train the ML models.Table III summarizes the main simulation parameters.
We considered three scheduling mechanisms to compare their performance with MARINA, namely: (i) UNC [23] task scheduling scheme is a classic queuing theory algorithm that is widely used as a policy for scheduling tasks

TABLE III
SIMULATION PARAMETERS in computational systems.It is similar to First-Come-First-Serve (FCFS) scheme, but the UNC scheme is free to select any task in the task queue for scheduling during the current time.(ii) FORESAM [24] considers a multi-criteria analytical method to select the most appropriate VC to receive the task.FORESAM considers all task requirements.(iii) CRATOS [13] considers a combinatorial optimization approach to schedule tasks in the available VCs.The algorithm was adapted for our scenario.The value of each task was defined as 1, given that, by default, the tasks have no value associated with them.
We consider the following evaluation metrics: • Root Mean Square Error (RMSE): quantifies the difference between ground-truth and predicted data regarding resource availability in each VC.This metric is widely used to measure the performance of predictors.In our case, it was used to evaluate and decide the best model for predicting vehicular resources for the proposed task scheduling mechanism.
• Scheduled tasks (%): percentage of successfully scheduled tasks.We consider successful scheduling when a task is scheduled in a VC and can be executed respecting its deadline constraint.• Monetary Cost ($/time): represents the monetary cost of using VC's computational resources for k units of time.
As defined in Section III-C, a VC comprises vehicles and BS, each of which has a different monetary cost.
• System latency (s): refers to the processing time of the task in a given computational configuration plus the queue waiting time.That is, this metric shows how efficient the decisions made by the mechanisms are.
• CPU time (s): represents the sum of the execution time of all the processes involved in the mechanism.This time may vary depending on the machine's configuration used in the evaluation.For this evaluation, we used an Intel(R) Xeon(R) CPU X5650 (24×2.66GHz)with Linux architecture x86_64.

B. Results: Mobility Prediction
We used 85 % of the samples of the data for training and 15 % for testing to analyze the RNN performance in our scenario.The prediction performance of the RNN was measured in terms of RMSE compared to Dense Neural Network (DNN) and Support Vector Regression (SVR), which are two approaches widely used in state-of-the-art to predict time series.Figure 7 shows an example of a time series built for VC with ID number 4. As can be seen, most of the time series (85 %) is used for model training, with the remainder (15 %) being used to test the predictions.Given the characteristics of the mobility trace, records from 6000 s were disregarded as they only contain the dynamics of removing vehicles from the simulation.
Figure 8 compares the RMSE obtained in the predictions with the considered models.This assessment considers the  average RMSE among the 14 VCs in the scenario in different time horizons for prediction.At this stage, we performed an exploratory assessment of the size of the prediction window.This is important to show the degradation of the prediction as the prediction window increases, which is expected in this type of evaluation.Thus, for each VC, we consider the prediction windows 5,10,15,20,25,30,60,120,180,240, and 300 seconds.In summary, the hyperparameters for training the LSTM model are: number of epochs = 100, batch size = 64, and number of LSTM cells = 128.
In this sense, we can see that the predictions provided by LSTM achieve an average RMSE of about 0.1 in most prediction windows, while the predictions provided by DNN and SVR suffer more significant degradations as the prediction window increases.LSTM is generally more efficient than other models at considering past events to provide predictions closer to dataset ground truth.Thus, this type of RNN proved ideal for helping our task scheduling mechanism.Based on the results, the LSTM proved to be more robust in resource prediction phase.Thus, we chose to use it to help our task scheduling process with the time window setting equal to 5 s.

C. Results: Task Scheduling
Figure 9 shows the behavior of the waiting queue Q over the simulation time considered if no scheduling mechanism is used.Different arrival rates significantly increase the difficulty of orchestrating the task schedule process.For example, at the highest arrival rate (λ = 5), 4500 tasks are queued at the end of the simulation run.In other words, it is a challenging scenario, considering that task sizes and deadline constraints also vary according to their arrival in the system.Figure 10 shows the difference in packets sent on the network, considering the centralized and hybrid architectures.In this sense, in a centralized architecture, where one entity makes all the decisions and builds its global knowledge, all vehicles must maintain communication with that entity.Thus, the number of packets sent per time unit is directly related to the number of vehicles communicating with the central entity.However, in a hybrid architecture, intermediary entities aggregate the messages of vehicles in their coverage and send this information to the remote server in a single data stream.The number of data messages transiting the network core is significantly reduced.In this evaluation, we can observe an average reduction of 50 % in the number of sent packets on the network when the hybrid architecture is considered.
Figure 11 displays the percentage of successfully scheduled and executed tasks with different maximum delay constraints 3, 5, and 7 seconds, respectively.We can check the behavior of the mechanisms when the system receives a high load of requests.All mechanisms improve their performance as the deadline increases.However, we can see that they all have difficulty scheduling as the task arrival rate increases.In all configurations MARINA performs better than other mechanisms.Also, when the arrival rate is equal to 1, MARINA can schedule over 91 % of the tasks in the configurations with the largest maximum deadline constraint, as shown in Figure 11(a).Both FORESAM and UNC operate similarly in this configuration.CRATOS has the worst performance when the deadline increases.This is due to its selection strategy, which is only concerned with the task size, not considering fundamental aspects such as deadline and computation delay.The tasks scheduled with CRATOS have processing restrictions that are not considered in its decision-making  process.In the configuration with a task arrival rate equal to 3, MARINA already starts to have difficulty scheduling when the deadline grows, as shown in Figure 11(b).However, the MARINA still manages to schedule up to 90 % of tasks in scenarios with the highest deadline constraints.In this configuration, we see a more significant difference between FORESAM and UNC due to UNC applying the simple greedy policy.In this scenario, MARINA is superior in all configurations considered.Finally, when the task arrival rate is 5, MARINA maintains its results closer to 88 %.FORESAM has results close to MARINA in this scenario.In FORESAM's setup, the main factor taken into account in its decision process was the task deadline, so when the deadline increase, its scheduling choices cannot relate to all the problem restrictions well.Even applying a simple scheduling method, the UNC can handle many requests compared to CRATOS.
Figure 12 shows the monetary cost of using the computational resources of the VCs.As mentioned in Section III-C, the cost of the vehicle's resources is less than that of the BS.Therefore, to minimize this cost, the approaches choose to select the resources of the vehicles for the scheduling first.We can see that MARINA minimizes the monetary cost in all evaluations.In this case, it is natural for the performance of all mechanisms to fall due to the percentage of scheduled tasks that also decreases in more challenging scenarios, as shown in Figure 11.The best performance of MARINA occurs due to the selection of the tasks considering the VC's predicted available resources and the joint minimization provided by the Pareto set approach.Applying BCP allows a more significant number of tasks to be scheduled out in the same VC, prioritizing that such resources come from vehicles and not from BS.In addition, the more challenging the scenario (increasing the task arrival rate) becomes, the more costly the scheduling process becomes.More computational resources need to be used to run the existing tasks.MARINA reduces the monetary cost by up to 80 % in all scenarios.CRATOS proves to be more costly because its decision process involves only the amount of computational resources available.In this way, many tasks are rescheduled during the mechanism's operation, thus increasing its final monetary cost.The UNC maintains its expected behavior of increasing the monetary cost as deadline constraints increases.The application of Pareto set and BCP by MARINA allows the best task set to be scheduled in the same VC with minimum processing time and deadline constraints.
Figure 13 depicts the system latency results, including the computational delay and queue time.This metric is important because it shows the impact of scheduling tasks in a given processing configuration and is directly associated with how the scheduling approach selects VCs.We can see, in all evaluations, that MARINA reduces the computation delay of the tasks in the VCs.Hence, it is mainly due to selecting the VCs employed by MARINA, filtering based on the VC's processing rate considering the task deadline constraint.In addition to selecting the VC with greater computational capacity, selecting tasks based on the joint minimization of processing time and deadline helps reduce system latency.In addition, CRATOS and UNC employ a higher computation delay in all assessments due to their decision strategy that considers only  the order in which tasks arrive in the system.Specifically, in the configuration with a tasks arrival rate equal to 3 and 5, MARINA and FORESAM stabilize their performance due to the absence of considerable variation in the number of tasks scheduled, as shown in Figure 13(b) and 13(c).In summary, MARINA has better managed VC's resources when considering aspects of both tasks and VCs in its decisionmaking process.In other words, an efficient task scheduling approach should maximize the number of scheduled tasks while minimizing the time that such tasks await their schedule.
Finally, Figure 14 presents the CPU time by the VEC controllers that run the scheduling approaches.This metric is directly related to the approach's computational complexity.Also, an approach that manages to schedule more tasks has more overall CPU time, even with less computational complexity.In all evaluations, UNC has lower CPU time because its selection method is simple, selecting the task to be scheduled based on its order of arrival in the system, operating with time complexity O(n 2 ), where n is the total number of tasks.CRATOS has the second-lowest CPU time, but this can be justified by the number of tasks scheduled and successfully executed, even having pseudo-polynomial complexity (O(max{m} + n × W ), where m is the set VC, n is the number of tasks, and W is the size of the VC considered in each round).FORESAM has a high CPU time because it iteratively selects one task at a time given a VC, making a more significant number of checks for each VC considered in the round.FORESAM uses the AHP technique in its decision process, and the time complexity of AHP is O(min{mn 2 , m 2 n}), where m is alternatives, and n is criteria.Finally, MARINA has CPU time statistically close to FORESAM.This is also true of its iterative decision-making process.In certain rounds, the returned Pareto set may be small, requiring further rounds to fill the VC.A 2-dimensional set is constructed at each decision round, and the algorithm searches for the Pareto optimal set, taking O(n log n) time.

VI. CONCLUSION
This article introduced MARINA, an efficient task scheduling for VEC environments.MARINA divides its scheduling process into three stages.The first step is finding the Pareto set based on a joint minimization of processing time and deadline constraints.After that, it applies BCP with the FFD heuristic to select a set of tasks for a given VC, aiming to maximize the number of tasks scheduled and minimize the monetary cost of this processing.The second step selects the tasks based on the correlation between the tasks' deadline constraint and predicted information about the computational resources available in each VC.Finally, the third step verifies the processing time of these tasks in the selected VC to reduce the computation delay and, consequently, the monetary cost of using the computational resources.MARINA employs an RNN architecture to predict vehicular resources in VCs and assist in its decision-making process.
Simulation results in a realistic vehicular scenario show that, compared to other solutions, MARINA has high performance in scheduling a higher number of tasks at lower monetary cost of using resources and lower overall system latency.It also keeps the CPU usage time around 10 ms in the regional VEC controllers.
During the task scheduling process, the system only has a macroscopic view of the VCs, so our objective is to have a microscopic view of the task management within each VC and increase the fault tolerance from MARINA.Besides, it is essential to highlight that the proposed solution can be extended to consider different metrics, such as energy consumption, load balancing, and reward for sharing resources.As future work, in addition to the different decision metrics, we plan to consider a more heterogeneous environment, including electric vehicles and their specific energy consumption models and mobile devices such as Unmanned Aerial Vehicles (UAVs).Also, we plan to consider load balancing in the task scheduling process to distribute available resources evenly.Additionally, we could consider migrating computational resources to increase reliability in maintaining the task scheduling process.Finally, we intend to consider a network environment where other applications use the VEC controller to verify the impact of the task scheduling in a shared resources environment.

Fig. 1 .
Fig. 1.The architecture employed by MARINA, presenting its main components; in particular, Vehicular Clouds (VCs) and Vehicular Edge Computing (VEC) controllers.

Fig. 2 .
Fig. 2.Vehicular Cloud (VC) formation process -from Base Station (BS) association to scheduling -based on a prediction approach using Long Short-Term Memory (LSTM).

Fig. 3 .
Fig. 3. Time series created by the system for a Vehicular Cloud (VC).

11 foreach r ∈ R do 12 if r has completed its execution then 13 compute 17 Update
r computation estimation processing time in each VC (Lines 10 and 11).

Fig. 7 .
Fig. 7. Example of the data used for the training and prediction processes.

Fig. 9 .
Fig. 9. Example of task queue Q over the simulation time considered.

Fig. 10 .
Fig. 10.Total sent packets on the network considering different system architectures.

Fig. 11 .
Fig. 11.Results of the scheduled tasks with different maximum deadline constraints and task arrival rates.

Fig. 12 .
Fig. 12. Results of the monetary cost with different maximum deadline constraints and task arrival rates.

Fig. 13 .
Fig.13.Results of the system latency with different maximum deadline constraints and task arrival rates.

Fig. 14 .
Fig. 14. Results of the CPU time with different maximum deadline constraints and task arrival rates.

TABLE I SUMMARY
OF RELATED WORKS HIGHLIGHTING THEIR CHARACTERISTICS AND LIMITATIONS

TABLE II SUMMARY
OF KEY NOTATIONS