Hierarchical Resource Management Framework and Multi-hop Task Scheduling Decision for Resource-Constrained VEC Networks

Abstract

In urban vehicular edge computing (VEC) environments, one edge server always serves many task requests in its coverage which results in the resource-constrained problem. To resolve the problem and improve system utilization, we first design a general hierarchical resource management framework based on typical VEC network structures. Following the framework, a specific interacting protocol is also designed for our decision algorithm. Secondly, a greedy bidding-based multi-hop task scheduling decision algorithm is proposed to realize effective task scheduling in resource-constrained VEC environments. In this algorithm, the goal of maximizing system utility is modeled as an optimization problem with the constraints of task deadlines and available computing resources. Then, an auction mechanism named greedy bidding is used to match task requests to edge servers in the case of multiple hops to maximize the system utility. Simulation results show that our proposal can maximize the number of tasks served in resource constrained VEC networks and improve the system utility.

1. Introduction

With the development of the Internet of Vehicles (IoV), more and more onboard applications are provided by smart vehicles, such as active driving assistance, road traffic monitoring, automatic management, and entertainment applications. Some of these applications require intensive computation and tight delay constraints, which are beyond vehicles' capabilities. Mobile edge computing (MEC) is an emerging but attractive computation framework. Different from cloud computing, MEC makes the task computing adjacent to the requestor, so it meets the aforementioned requirements of IoV applications ^[1]. Vehicular edge computing (VEC) is the combination of IoV and MEC. VEC can boost the development of an intelligent transportation system (ITS). It is a promising technology to meet the needs of these emerging applications by making rational use of the computing resources of a vehicle and network edges ^[2].

In VEC networks, a MEC server services all the vehicles covered typically ^[3]. This will lead to competition for the limited computing resource of MEC servers within vehicles ^[4]. As a result, task scheduling and resource allocation decisions are widely studied.

A Roadside Unit (RSU) equipped with an edge server can service vehicles within its coverage area, reducing the computational and backhaul pressure on the resource management center. Therefore, a three-layer resource scheduling architecture based on vehicles, RSUs, and resource management centers is constructed for the IoV edge network. But the existing MEC resource scheduling literature rarely pays attention to the system utility problem. Referring to [5], the edge cloud resources are allocated by auction, and the winner transaction price principle is adopted. However, this method does not consider the multi-product, multi-regional combination problem and the uncertainty of user bidding and ignores the two-way benefits of users and edge systems. Reference [6] proposes a novel caching architecture for edge system caching to achieve the purpose of energy-saving. But this type of method mainly considers the performance of the user and not the revenue of the margin service provider. Reference [7] considers the use of genetic decision-making to implement migration strategies for computing tasks with different priorities in the case of an unbalanced computing resource load, thereby improving the migration rate of edge computing. However, the full utilization of edge computing resources is not considered. Although resource scheduling has received a lot of attention in recent years, it usually ignores the collaboration between edge servers.

MEC resource allocation is one of the most important issues in MEC research. The authors of [8] developed a distributed resource sharing scheme for vehicle networks, where multiple vehicle-to-vehicle (V2V) links can share and reuse the spectrum allocated to vehicle-to-infrastructure (V2I) links to improve the system capacity and reliability. In [9], a joint scheme for unstable V2V links is proposed by considering a joint optimization model of transmission mode selection and resource allocation. In [10], a computational offloading and resource allocation scheme for time-varying multi-user MEC systems is proposed, and an algorithm based on centralized double deep Q-learning (DDQL) is proposed. A MEC based on a vehicle network was studied in [11], and a software-defined network (SDN) controller was proposed to collect global information on the network state. They utilize an SDN-based system to improve the efficiency of vehicle networks by optimizing offload node selection and resource allocation.

Considering that many mobile vehicles have some computational tasks that need to be processed, however, these vehicles lack sufficient computational resources. Therefore, vehicles need to rent computing resources from nearby RSUs, and to guarantee the quality of service, the transmission delay of each task must be less than a deadline. In real life, there are multiple MEC servers on the real road. The resource management center needs to manage these servers reasonably and allocate MECs with insufficient resources to MECs with sufficient resources, which can not only improve network performance but also improve service quality [12].

For the resource allocation and pricing of edge computing systems, for edge providers, under limited resource conditions, users will bid for resources according to their budgets and costs to obtain better services, and resource providers will bid according to their bids^[13-16]. Select users, deliver resources to users with higher bids, ensure user performance experience, and improve the overall revenue of edge systems. From a system point of view, edge service providers get more benefits from limited resources; Reference [17] studies the optimal service provider to maximize revenue under the constraints of quality of service (QoS) for all mobile users' resource allocation problems. Reference [18] proposed the concept of network service module market, using the method of stochastic process, to transform the problem of network resource allocation into the problem of resource buying and selling. The deterministic bidding method assumes that the user's bid is known, and the uncertainty of the user's bid leads to information lag in the resource auction and pricing process, which makes the deterministic auction method limited. From the user's point of view, users can Free choice of resources is required, and the quality of service can be guaranteed^[19]. Therefore, the auction-based edge resource scheduling method adopted in this paper can effectively improve the overall system efficiency. There are many research results on system utility and resource management, which are well summarized in Reference [20].

There has been some research devoted to resource allocation and workload scheduling of edge cloud. Reference [21] applied the Markov approximation framework to solve the computational offload scheduling problem by using a distributed algorithm. Reference [22] proposes an iterative algorithm to solve joint communication and computational resource allocation problems. However, most of these studies do not address the problem of optimal matching between task scheduling and servers, and most studies on auction decision-making are concerned with maximizing benefits for service providers. Ignore the problem of maximizing system utility. For edge providers, under the condition of limited resources, users will bid for resources according to their budgets and costs to obtain better services. Resource providers select users based on their bids and deliver resources at higher prices. At the same time, it also ensures the user's performance experience and improves the overall revenue of the edge system. Reference [23] models computational offload scheduling as a mixed integer linear programming problem and designs quality of experience (QoE)-based node selection strategy based on the solution of the piecewise optimization problem. Referring to [24] to establish a global optimization problem, an uncertain offload scheduling algorithm is designed to minimize the expected delay. However, most of these studies study resource allocation from the perspective of workload scheduling, which is also different from considering resource competition from an economic perspective and ultimately achieves the goal of maximizing system utility. Referring to [25], a game-theoretic online algorithm is designed to solve the problem of offloading scheduling of computing tasks, and an online bin packing algorithm is used to calculate resource allocation. Although the literature [25] also designed a three-layer IoV model, uploading vehicle tasks to the cloud layer will cause a large delay, which is not suitable for the processing of delay-sensitive tasks. From a system perspective, edge service providers gain more benefits from limited resources; from a user perspective, users can freely choose the resources they need to ensure service quality. Since latency and server capacity constraints are important factors affecting user service quality, our goal is to optimize system utility under the constraints of task request latency and available computing resources of the MEC server.

In VEC, several recent works focus on multi-hop offloading strategies based on vehicle coordination and server coordination. Reference [26] uses a vehicle-coordinated multi-hop offloading method to handle the computational task and proposes a semi-definite relaxation method with an adaptive adjustment process to solve the proposed optimization problem to obtain the corresponding unloading decision. Reference [27] proposed a cluster-based cellular-vehicle to everything (C-V2X) network collaborative task offloading scheme. This scheme discusses the cooperation between the MEC server and the vehicles with idle computing resources. However, the above literature does not consider the cooperation with the surrounding MECs and does not fully utilize the abundant computing resources of the MECs, which will lead to the waste of the surrounding MEC resources. Reference [28] proposed a collaborative method for offloading services to cars in a vehicle network based on MEC and cloud computing. The cloud-MEC collaborative computing offloading problem is established by collaboratively optimizing computing offloading decisions and computing resource allocation. Reference [29] proposes a Fiwi-enhanced in-vehicle edge computing network architecture to support the coexistence of remote cloud centers and lightweight edge servers connected to RSUs. Reference [30] studies the multi-hop computing offloading problem of the edge cloud computing model of the Industrial Internet of Things, and adopts the game theory method to realize the computing offloading of distributed perception quality of service (QoS). However, the above work focuses on the offloading of the cloud server and MEC server, but this will lead to an increase in latency, which is not conducive to the offloading of low latency tasks and the full utilization of MEC server resources. In order to solve the above problems, and fully schedule MEC server resources, this paper proposes a multi-hop MEC task scheduling decision, which is different from the traditional two-layer edge network hierarchical structure. Firstly, based on a two-level cluster VEC network, a three-layer resource management structure model is constructed to realize efficient resource management and computing offloading. Secondly, the computing offloading tasks are balanced to adjacent indirect connecting MEC servers through a multi-hop RSU-to-RSU (R2R) path. Thirdly, a nearby management node manages the multi-hop R2R computing offloading in the cluster.

This paper constructs a hierarchical model of the VEC network based on cluster class. In the model, multiple vehicles move within the coverage area of the RSU, and multiple RSUs cooperate to serve the vehicle. Under the constraints of service execution delay and limited storage of the MEC server, this paper adopts the GBMTS algorithm to maximize the system utility while satisfying the constraints of task request delay and available computing resources of the MEC server. First, we model the system utility maximization problem as a many-to-one weighted bipartite graph matching problem with multiple knapsack constraints and then propose the GBMTS decision algorithm to solve this problem. The main contributions of this work are as follows.

The main contributions of our work are as follows.

1) A hierarchical resource management system for VEC is proposed, which consists of a framework and an interacting protocol. In the framework, the hierarchical resource management structure and the main functional modules of each layer are designed. Then these modules cooperate for resource management with the interacting protocol. It should be noted that this system can be easily extended and applied to other MEC environments.

2) Considering the benefit of vehicle users and the cost of the MEC server, the task scheduling problem is modeled as a multi-knapsack restricted multi-to-one weighted bipartite graph matching under the delay constraints of tasks and the resource constraints of MEC servers. Furthermore, to improve the utilization of resources and the success rate of computing requests, it’s a multi-hop matching based on the cluster-based hierarchical structure.

3) To solve the afore matching problem, a greedy bid-winning multi-hop task scheduling decision algorithm is proposed based on the auction mechanism.

2. The hierarchical resource management framework and protocol for VEC Networks

VEC network is a typical resource-constrained environment, so effective resource management is essential to make full use of resources and improve service capabilities. As a result, a hierarchical resource management framework and an interacting protocol are proposed in this section.

2.1 The hierarchical resource management framework

Considering the practical environments of IoV and MEC, a typical cluster-based hierarchical structure of VEC networks is concluded as in Fig. 1. In this structure, the main part is the two-level cluster, based on which effective network management can be implemented. As shown in Fig. 1, the 1st-level cluster contains one head, i.e., gNB node in 5G or other base station node, and many members, i.e., vehicles and RSUs combined with MEC servers. The 2nd-level cluster also contains one head, i.e., the RSU node, and many members, i.e., vehicles. Furthermore, one 1st-level cluster contains multiple 2nd-level clusters, and the bidirectional wireless links exist between every neighbor cluster head pair, neighbor cluster head and member pair, and neighbor cluster member pair.

Fig. 1. The typical cluster-based hierarchical structure of VEC networks

For realizing effective resource management in cluster-based VEC networks shown in Fig. 1, a hierarchical resource framework is designed. The detail of the framework is described in Fig. 2. The whole framework is divided into three layers, named layer0, layer1, and layer2, respectively.

Fig. 2. The hierarchical resource management framework

1) Layer0: Consists of vehicles that are the offloading requesters and the task executors and contains three main modules, i.e., a local resource monitoring module for monitoring the resource usage of the vehicle itself, a task processing decision module for task division and offloading, etc. and a task computing module for executing tasks.

2) Layer1: Consists of MEC servers which are the executors of the offloading computing and the task migration, and contains four main modules, i.e., a local resource monitoring module for monitoring the resource usage of the MEC server itself, a resource allocation decision module for allocating the necessary resources for tasks or giving a task migration decision with insufficient resources, a task migration module for executing task migration and a task computing for executing tasks.

3) Layer2: Consists of base stations, such as gNBs, which are the resource management centers (RMCs) for making task scheduling decisions, and contains three main modules, i.e., a cluster resource monitoring module for monitoring the resource usages of all nodes in the cluster, a task scheduling strategy module for adopting different task scheduling strategies and a task scheduling decision module for making scheduling decisions according to strategies.

2.2 The interacting protocol

The interacting protocol describes the interacting details among different modules of the framework. Therefore, the combination of the framework and the interacting protocol produces a workable hierarchical resource management system.

Next, we take the application of the system on VEC as an example to show the work process. However, it must be noted that this system can also be applied in other scenarios.

CASE 1: Pure Local Computing (PLC) on vehicles

STEP 1. A vehicle generates a task, and the local resource monitoring module of the vehicle tells the task processing decision module that the resource for computing the task is enough.

STEP 2. The task processing decision module decides to compute the task by the vehicle itself.

STEP 3. The task computing module of the vehicle computes the task locally.

CASE 2: Offloading Computing (OC) on MEC servers or vehicles

In CASE 2, there are two subcases named Pure Offloading Computing (POC) and Hybrid Offloading Computing (HOC).

STEP 1. (on vehicle): A vehicle generates a task, and the local resource monitoring module of the vehicle tells the task processing decision module that the resource for computing the task is not enough, so the task processing decision module chooses one mode between POC and HOC.

STEP 2. (on vehicle): The task processing decision module interacts with the resource allocation decision module of the registered MEC server to execute offloading computing. If HOC is chosen, the task processing decision module is also responsible for segmenting the task into multiple subtasks and decides which are computed locally and which are offloaded to the MEC server.

STEP 3. (on MEC server): The resource allocation decision module of the registered MEC server receives the request, so it asks the local resource monitoring module whether there are enough resources for the task. If YES, it accepts the offloading computing request and goes to STEP 4 for computing. Otherwise, it requests the task scheduling decision module of gNB to schedule the task and goes to STEP 5.

STEP 4. (on MEC server): The task computing module of the registered MEC server computes the task offloaded by vehicles and then feeds the results back to the task processing decision of the vehicle.

STEP 5. (on gNB): The task scheduling decision module of gNB receives the task scheduling request, then it makes the scheduling decision according to the resource information from the cluster resource monitoring module and the scheduling strategy from the task scheduling strategy module.

STEP 6. (on gNB): The scheduling decision is fed back to the involved MEC server.

STEP 7. (on MEC server): When a MEC server receives feedback from gNB, it updates the migration rules in its task migration module. If it isn't the destination of migration, its task migration module will migrate the task received continuously. Otherwise, a task request will send to the resource allocation decision module, and then the task computing module will compute the task.

STEP 8. (on MEC server): After the task has been computed, the MEC server will feed the results back to the requesting vehicle.

STEP 9. (on vehicle): The requesting vehicle receives the result fed back. If POC is used, the result is the final one. If HOC is used, the task processing decision module integrates the results of different subtasks to get a meaningful and complete result.

3. Greedy Bid-based Multi-hop Task Scheduling Decision Algorithm

Based on the hierarchical resource management framework, a Greedy Bid based Multi-hop Task Scheduling decision algorithm named GBMTS is proposed in this section.

3.1 The delay model

There are three computing models used in MEC which are known as local computing, full offloading computing, and partial offloading computing, respectively. Because our work is about the multi-hop task scheduling decision, it is sufficient to only consider the offloading computing model. As a result, for simplicity, full offloading computing is taken as the example in our discussion without loss of generality.

In the full offloading computing model, the full task is offloading from the vehicle to the MEC server selected, which may be with a multi-hop mode in our discussions. Therefore, the whole delay experienced by the vehicle consists of the multi-hop transmission delay of the task, the computing delay on the computing MEC server, and the transmission delay of the result mainly.

Without loss of generality, we consider that there is only one task on each vehicle needed to be offloaded for the simplicity of discussion. Let Task _i = < D_i, A_i, T_i > denotes the task offloaded by the vehicle i (represented as Veh_i), where D is the amount of the task, A is the CPU cycles for computing the task, and T is the deadline required by the task. Furthermore, we suppose that the channels used by any neighbor nodes are bidirectional, and vehicles and MEC servers each have the same transmission power.

In the beginning, Task_i is transmitted Veh_i to its neighbor MEC server x (represented as Serv_x) in one hop, then Task_i is retransmitted by MEC servers in multi-hop mode until it reaches Serv_j. Therefore, the multi-hop transmission delay of the task t_i,j^FTran is computed as

\(\begin{aligned}t_{i, j}^{\mathrm{FTran}}=\frac{D_{i}}{r_{i, x}^{\mathrm{V} 2 \mathrm{I}}}+\frac{D_{i}}{r_{x, y}^{\mathrm{I} 2 \mathrm{I}}} \cdot(h-1)\\\end{aligned}\)       (1)

where h is the hops from Veh_i to Serv_j, r_i,x^V2I and r_x,y^I2I are the wireless transmission rates used for V2I and I2I communications, respectively, which can be computed with Shannon's theorem as

\(\begin{aligned}r_{n, m}=B_{n, m} \log _{2}\left(1+\frac{p_{n} g_{n, m}}{\sigma^{2}}\right)\\\end{aligned}\)       (2)

where B_n,m is the channel bandwidth between two neighbor nodes <n, m>, p_n is the transmission power of the node n, g_n,m is the channel gain and σ² is the noise power.

When Serv_j receive Task_i, it allocates some computing resources a_ij to compute the task. So, the computing delay t_ij^Comp is computed as

\(\begin{aligned}t_{i j}^{\text {Comp }}=\frac{A_{i}}{a_{i j}}\\\end{aligned}\)       (3)

The computation result is transmitted back Veh_i through a reverse path, so the transmission delay of the result t_j,i^RTran is computed as

\(\begin{aligned}t_{j, i}^{\mathrm{RT} \mathrm{Tan}}=\frac{R_{i}}{r_{y, x}^{\mathrm{I} 2 \mathrm{I}}} \cdot\left(h^{\prime}-1\right)+\frac{R_{i}}{r_{x, i}^{\mathrm{I} 2 \mathrm{~V}}}\\\end{aligned}\)       (4)

where R is the amount of the result.

Finally, the total delay t_ij^Off of Task_i on Serv_j is computed as

t_ij^Off = t_i,j^FTran + t_ij^Comp + t_j,i^RTran       (5)

According to [31], the amount of the computation result is much smaller compared to the task for many applications, e.g., face recognition. As a result, t_j,i^RTran can be ignored. Then, (5) can be simplified to

t_ij^Off = t_i,j^FTran + t_ij^Comp       (6)

3.2 Problem formulation

In offloading computing, a MEC server with finite computation resources can’t afford all of the computation tasks of vehicles. It results in the rejections of some task requests. Then these requests are forwarded by the MEC servers to the RMC (i.e., gNB) based on our proposed hierarchical resource management framework. When the RMC receives these requests, it will make a task scheduling decision that matches these tasks to the MEC servers in its cluster.

The task scheduling decision is a solution to the competition of the tasks for the limit and shareable computing resources, so it is modeled as a multiple-to-multiple auction which is defined in Definition 1.

Definition 1. The auction for the task scheduling decision is a multiple-to-multiple auction. In the auction, the RMC acts as the auctioneer. The tasks act as the bidders and bid for the computation resources of the MEC servers managed by the RMC in the 1st-cluster. Furthermore, due to the tasks can’t be divided further, each task is matched to only one MEC server, but one MEC server can be matched by multiple tasks conversely.

It should be noted that different from the normal auction types, the auction in Definition 1 is a matching of multi-task to the multi-MEC server and have multiple different available auction results. Let B denote the bid set, which contains all the bids in the auction, b_ij( b_ij ∈ B ) denote the bid of Task_i for Serv_j and , S_ij = < b_ij, j > denote Task_i is successfully matched to Serv_j with b_ij, so any auction result is a matching set M which consists of all S_ij in the auction.

Definition 2. The utility of Serv_j is the profit earned by renting its computing resources to its matching tasks for offloading computing. Therefore, it can be computed as

\(\begin{aligned}U_{j}=\sum_{<b_{i j}, j \mid j>\in \mathrm{M} w}\left(b_{i j}-A_{i} \times C_{j}\right)\\\end{aligned}\)       (7)

where U_j and C_j denote the utility and the cost spent in one CPU cycle of Serv_j respectively.

Definition 3. The system utility is the total profit of all MEC servers involved in M .

Therefore, it can be computed as

\(\begin{aligned}U_{\text {system }}=\sum_{j \in \mathrm{M}} U_{j}\\\end{aligned}\)       (8)

Where U_system denotes the system utility.

By substituting (7) into (8), the specific computation U_system is given by (9) as follows system

\(\begin{aligned}U_{\text {system }}=\sum_{<b_{i j}, j>\in \mathrm{M} w}\left(b_{i j}-A_{i} \times C_{j}\right)\\\end{aligned}\)       (9)

Definition 4. The optimal auction is the auction that produces the maximum system utility and the result of which is the optimal matching set.

Because the multi-hop task scheduling decision is equivalent to finding the optimal auction, the problem is converted to find the optimal matching set to maximize U_system. Then based on (9), the optimal problem of GBMTS is defined as follows.

Definition 5. Optimal Problem (OP) is finding the optimal matching set to maximize U_system under the constraints of delay and computation resources which is formulated as follows

\(\begin{aligned}\begin{array}{c}O P(\mathrm{M})=\max \left\{\sum_{<b_{i j}, j>\in \mathrm{M} w}\left(b_{i j}-A_{i} \times C_{j}\right)\right\} \\ \text { s.t. } \mathrm{C} 1: \mathrm{M} \subseteq \mathrm{B} \\ \mathrm{C} 2: \sum_{<b_{i j}, j \mid j>\in \mathrm{M}} A_{i} \leq W_{j} \\ \mathrm{C} 3: t_{i j}^{\mathrm{Off}} \leq T_{i}\end{array}\\\end{aligned}\)       (10)

Where W_j denotes the available computation resources of Serv_j. In (10), C1 shows that the matching set is produced from the bid set, C2 shows that the total computation resources needed by all tasks matched to Serv_j must be less or equal to the available computation resources Serv_j, C3 shows that the offloading computing delay of Task_i must be less or equal to its deadline.

3.3 GBMTS algorithm

In this section, the GBMTS algorithm is designed to resolve the optimal problem described in (10). The GBMTS algorithm can be divided into two consistent phases named pruning phase and greedy matching phase, respectively.

1) Pruning Phase

In the auction, each task generates a bid for every MEC server, but some of the bids are meaningless for the computation resource or the offloading computing delay of the MEC server is unavailable for the task. Therefore, in the pruning phase, these meaningless bids are removed from B by the RMC, and the details of pruning are shown in Algorithm 1.

Algorithm 1. Pruning

Input: B

Output: B_pruned

1: Initialization: B_pruned = ϕ

2: For each b_ij∈B Do

3: If t_ij^Off ≤ T_i And A_i ≤ W_j

4: B_pruned = B_pruned ∪ {b_ij}

5: End If

6: End For

7: Return B_pruned

As the result of pruning, the OP can be simplified by removing the constraint C3 from (10) as follows.

\(\begin{aligned}\begin{array}{l} O P(\mathrm{M})=\max \left\{\sum_{<b_{i j}, j>\in \mathrm{M} w}\left(b_{i j}-A_{i} \times C_{j}\right)\right\} \\ \text { s.t. } \mathrm{C} 1: \mathrm{M} \subseteq \mathrm{B} \\ \mathrm{C} 2: \sum_{<b_{i j}, j \mid j>\in \mathrm{M}} A_{i} \leq W_{j}\end{array}\\\end{aligned}\)       (11)

2) Greedy Matching Phase

In the greedy matching phase, the RMC constructs a weighted bipartite graph G = (V, E) based on the results of pruning, as shown in Fig. 3. The vertex set V consists of two disjoint subsets: task subset V_task and MEC server subset V_server respectively. In the edge set E, for every b_ij ∈ B_pruned, the corresponding < Task_i, Serv_j > pair constructs an edge e_ij with the weight w_ij shown in (12).

Fig. 3. An example of the weighted bipartite graph constructed by RMC

w_ij = b_ij - A_i × C_j (12)

Greedy matching is an iterative greedy selection process. In each iteration, one edge with the maximum weight is selected. That is to say, one matching pair is found. When the greedy matching ends, all selected matching pairs construct a solution set which is the optimal matching set of OP. The details of greedy matching are shown in Algorithm 2.

Algorithm 2. Greedy Matching

Input: E

Output: Ω

1: Initialization: Ω = ϕ

2: While E ≠ ϕ Do

3: Select the edge with the maximum weight in E

4: If multiple edges are selected Then

5: Select an edge randomly

6: Let e_ij be the selected edge

4: If A_i ≤ W_j Then

5: Ω = Ω ∪ {b_ij}

6: W_j = W_j - A_i

7: Delete all edges related to Task_i from E

8: Else

9: E= E - {e_ij}

10: End If

11: End While

12: Return Ω

3.4 The computation efficiency of GBMTS algorithm

GBMTS algorithm consists of two sequential sub-algorithms: Algorithm 1 and Algorithm 2. Considering the case that there are n tasks needed to be matched to m servers by the RMC. In Algorithm 1, it will iterate every bid in β for pruning, so the time complexity of Algorithm 1 is O(nm). In Algorithm 2, there are nm edges in the worst case, and it will iterate every edge to match tasks to servers, so the time complexity of Algorithm 2 is O(nm) too. Therefore, the time complexity of GBMTS algorithm equals to O(nm)+O(nm)= O(nm), that is GBMTS algorithm can be conducted in polynomial time.

4. Simulation and Result Analysis

4.1 Simulation Parameter Setting

The proposed GBMTS algorithm is simulated with Matlab, and the specific simulation parameters are shown in Table 1.

Table 1. simulation parameters

4.2 Results and Analysis

In the simulation, a benchmark algorithm named HBMTS and a centralized heuristic greedy offloading (CHGO) algorithm [29] are used to verify the effectiveness of our GBMTS algorithm.

• The highest bid based multi-hop task scheduling (HBMTS) decision algorithm works in a distributed mode, each vehicle generates bids for every MEC server in three hops. When a MEC server receives the bids from vehicles, it sorts all requests, the delay constraint of which can be satisfied, in a descending order based on the bids. Then the request with the highest bid will be replied. If a vehicle receives one reply, it offloads the task directly, else it chooses a MEC server randomly to offload. This process iterates until all requests are accepted or the delay constraint of task expires. In HBMTS, all interchanges are process in multi-hop R2R mode.

• The centralized heuristic greedy offloading (CHGO) algorithm adopts a centralized management mode. The management center matches tasks to MEC servers based on the minimum processing delay. In each iteration, a task is matched and offloaded to the MEC server which can achieve the minimum processing delay through multi-hop R2R path. This process iterates until all the vehicles have made their offloading decisions.

Fig. 4 shows the situation in which the utility value of the system changes with the increase of the number of requesting vehicles in the three cases of the number of MEC servers M=5, M=10, and M=15. With the increase in the number of requesting vehicles and the number of MEC servers, the available system utility increases. When M=5 and M=10, as a result of the limitation of MEC server resources, along with the increase of the number of vehicles is competition for resources, get service vehicles, the less instead, when the number of vehicles is greater than 25, satisfy the constraint conditions of the request has been assigned to complete basic vehicle, even if the number of vehicles increases, the winner of the number basically remains unchanged, decision convergence.

Fig. 4. System utility vs. Number of requesting vehicles with different MEC servers.

Fig. 5 shows that the system service rate increases with MEC servers when L=10, L=20, and L=30. As shown in the figure, with the increase in the number of MEC servers and vehicles, the system service rates of the three algorithms will also increase accordingly. Among them, the GBMTS algorithm increases the fastest because the GBMTS algorithm can improve the system service by increasing the number of MEC servers. Speed, so that more vehicles can be served.

Fig. 5. System service rate vs. MEC servers with different vehicles.

Fig. 6 shows the changes in system utility caused by changes in the number of different MEC servers. As shown in the figure, as the number of edge servers increases, the available system utility values show an upward trend. Among them, the GBMTS decision is better than the lowest delay multi-hop task scheduling decision and the highest bid multi-hop task scheduling decision. Since the minimum delay decision only considers the optimal time delay and ignores the cost of the server, the system utility value is the lowest. The CHGO algorithm considers the delay and only needs to satisfy the CHGO decision. But it ignores the number of resources required by the vehicle itself. The HBMTS algorithm considers the optimal bidding, but it ignores the delay, so the system utility value is lower than that of GBMTS.

Fig. 6. System utility vs. MEC servers with different algorithms

Fig. 7 shows the variation of vehicle winners due to the different number of MEC servers. As shown in the figure, with the increase of MEC servers, the number of winning vehicles also increases. Set the request vehicles L=20 and the number of MEC servers M=10. With the increase in the number of edge servers, the available system utility values show an upward trend. Among them, the GBMTS decision is better than the lowest delay multi-hop task scheduling decision and the highest bid multi-hop task scheduling decision. The CHGO algorithm only selects the optimal delay, ignoring the service to most vehicles. The HBMTS algorithm only considers the bidding of vehicles and chooses to ignore the vehicles that do not meet the bidding because the number of services is less than GBMTS.

Fig. 7. Number of winning vehicles vs. MEC servers with different algorithms

Fig. 8 shows that when the number of requesting vehicles changes and the MEC server is fixed at M=10, the system utility values obtained by using different decisions are also different. With the increase in the number of requesting vehicles, the system utility values are increasing all the time. The decision proposed in this paper increases the fastest, and the system utility values obtained are also the most. When the number of requesting vehicles reaches 20, the system utility values obtained by using different multi-hop task scheduling decisions are the same, due to the limited capacity of resources, the system utility value increases slowly compared with before. However, after the number of vehicles reaches 20, the system utility value of the proposed decision also increases faster than the other two decisions. This is because the proposed decision can find the optimal node to serve the vehicles and realize the optimal allocation of resources under the condition of limited resources.

Fig. 8. System utility vs. Number of requesting vehicles with different algorithms.

Fig. 9 shows that when L=30, the average delay of all algorithms decreases as the number of MEC server increases, and HBMTS always has the largest delay for all scenes. Moreover, when the number of MEC servers is small (<4 in our simulations), CHGO has the smallest delay, but as it increases, GBMTS gets the smallest delay. This is because the matching mechanism of GBMTS can make use of the resources of MEC servers more effectively under the restriction of task deadlines.

Fig. 9. Average Delay vs. MEC servers with different algorithms.

Fig. 10 shows that when M=5, the average delay of all algorithms increases as the number of requesting vehicles increases, and HBMTS has the largest delay for all scenes. Moreover, when the number of requesting vehicles is more than 14, GBMTS gets the smallest delay for it can achieve more effective offloading decisions by considering the delay and available resources of MEC servers. This is further illustrated that GBMTS is more effective in an actual VEC network.

Fig. 10. Average Delay vs. Number of requesting vehicles with different algorithms.

5. Conclusion

In this paper, we consider the problem of scheduling tasks for time-sensitive vehicle users by auction mechanism and then allocating resources by multi-hop MEC matching the optimal MEC server so as to avoid overwork and waste of resources in any one MEC. This paper puts forward a kind of general applicable to large-scale car side end two-stage cluster at the edge of the network structure model. Within the cluster will task scheduling with MEC server model matching problem into multiple knapsack restrictions on a weighted binary map-matching problem, the GBMTS decision is proposed to solve the matching problem to achieve the rational allocation of resources, And the task scheduling path is planned to realize multi-hop offloading of the task. The simulation results show that the GBMTS decision can increase the number of serviced vehicles in the edge computing network of vehicle linkage and maximize the system utility under the condition of satisfying the time delay and capacity constraints.