Layered resource management and multi-hop task scheduling method and device based on Internet of Vehicles edge computing and medium

Abstract

The invention discloses a hierarchical resource management and multi-hop task scheduling method and device based on Internet of Vehicles edge computing, and a medium, belongs to the technical field of Internet of Vehicles and mobile edge computing, and aims to solve the technical problem of how to efficiently schedule and allocate resources of other edge nodes, improve the resource utilization rate and improve the resource utilization rate. According to the technical scheme, a hierarchical resource management framework is constructed on the basis of a VEC network structure, and on the basis of the hierarchical resource management framework, an interaction protocol is adopted to achieve local calculation of a vehicle and unloading of the vehicle to an MEC server for calculation or mixing of MEC resources and unloading of vehicle local resources for calculation, and results of different tasks are obtained; in a resource-limited VEC environment, effective task scheduling is realized based on a greedy bidding multi-hop task scheduling decision; and a task request is matched to an edge server by adopting an auction mechanism of greedy bidding, so that multi-hop unloading of the task is realized.

Description

Technical Field

[0001] The present invention relates to the field of vehicle networking and mobile edge computing technology, and specifically to a hierarchical resource management and multi-hop task scheduling method, device and medium based on vehicle networking edge computing. Background Art

[0002] With the deep integration of the Internet of Vehicles and mobile networks, emerging applications such as autonomous driving, virtual reality, and real-time traffic control have been proposed to improve driving safety and traffic efficiency. However, due to the limited computing power of the vehicle itself and the high latency of traditional cloud computing, the real-time nature of these applications is difficult to meet. To this end, vehicle-connected edge computing, which combines mobile edge computing technology with the Internet of Vehicles, has become an important solution. In the vehicle-connected edge network, the node types and node resources vary greatly, the tasks have different resource requirements, and the network topology changes dynamically. Therefore, effective resource management is required to better leverage the advantages and capabilities of edge computing. At this stage, the technical solutions to solve the limited resources at the edge of the network are as follows:

[0003] ① Taking priority order as the primary factor in resource allocation, applications can be scheduled according to their priority. The scheduler first checks the computing resources available on the edge server. If the currently available resources meet the processing requirements of the task, the corresponding virtual machine is allocated to perform task calculations. If the currently available resources are in short supply, the central cloud will schedule the available resources in a unified manner.

[0004] ② The solution can be unloaded by using predicted multi-hop task scheduling. By estimating parameters such as the task data volume, channel status, and vehicle speed, the task can be unloaded in advance to the RSU / MEC server in front of the vehicle. When the task calculation is completed, the result can be directly transmitted back to the vehicle, eliminating the wireless backhaul line transmission process between RSUs.

[0005] Although the above two solutions solve the problem of limited network edge resources, resource complementarity cannot be achieved between networks. Multi-node computing resource management is an effective way to solve network load imbalance.

[0006] In the urban vehicle-to-vehicle edge computing environment, an edge server always serves multiple task requests within its coverage area, which leads to resource constraints and makes it impossible to process all tasks within the coverage area in a timely manner. Therefore, how to efficiently schedule and allocate resources of other edge nodes and improve resource utilization is a technical problem that needs to be solved urgently. Summary of the invention

[0007] The technical task of the present invention is to provide a hierarchical resource management and multi-hop task scheduling method, device and medium based on vehicle-connected edge computing to solve the problem of how to efficiently schedule and allocate resources of other edge nodes and improve resource utilization.

[0008] The technical task of the present invention is achieved in the following manner. A hierarchical resource management and multi-hop task scheduling method based on vehicle-edge computing, and the method is as follows:

[0009] Based on the VEC network structure, a hierarchical resource management framework is constructed. On the basis of the hierarchical resource management framework, an interaction protocol is adopted to enable the vehicle to perform calculations locally and offload to the MEC server for calculations, or a hybrid of MEC resources and vehicle local resources is offloaded for calculations, and the results of different tasks are obtained;

[0010] In a resource-constrained VEC environment, effective task scheduling is achieved based on a greedy bidding-based multi-hop task scheduling decision;

[0011] A greedy bidding-based auction mechanism is used to match task requests to edge servers, realizing multi-hop offloading of tasks.

[0012] Preferably, the hierarchical resource management framework includes two levels of clusters;

[0013] Among them, the first-level cluster includes a cluster head and several cluster members; the cluster head is the gNB node in the base station node, and the cluster members are RSUs and all vehicle members within the coverage range;

[0014] The cluster head of the second-level cluster is the RSU node, and the cluster members of the second-level cluster are vehicle members within the coverage range of the RSU;

[0015] A first-level cluster includes multiple second-level clusters, and there are multiple bidirectional wireless links between each adjacent cluster head pair, adjacent cluster head and cluster member pair, and neighbor cluster member pair.

[0016] More preferably, the VEC network structure includes three layers, namely layer0 layer, layer1 layer, and layer2 layer;

[0017] Among them, the layer0 layer is composed of an offloading requester and a task executor; the layer0 layer includes a vehicle local resource monitoring module, a task processing decision module, and a vehicle task calculation module; the vehicle local resource monitoring module is used to monitor the resource usage of the vehicle itself; the task processing decision module is used for task division and offloading; the vehicle task calculation module is used for calculating and returning tasks;

[0018] Layer 1 consists of MEC servers, which are the executors of offloading computing and task migration; Layer 1 includes the MEC server local resource monitoring module, the resource allocation decision-making module, and the task migration module; The MEC server local resource monitoring module is used to monitor the resource usage of the MEC server itself; The resource allocation decision-making module is used to allocate necessary resources for tasks or give task migration decisions when resources are insufficient; The task migration module is used to execute task migration;

[0019] Layer 2 consists of base stations (such as gNBs), which act as Resource Management Centers (RMCs) for making task scheduling decisions; Layer 2 includes the cluster resource monitoring module, the task scheduling strategy module, and the task scheduling decision-making module. The cluster resource monitoring module is used to monitor the resource usage of all nodes in the cluster; The task scheduling strategy module is used to provide different task scheduling strategies for different tasks according to the task situation; The task scheduling decision-making module is used to make scheduling decisions according to different task scheduling strategies.

[0020] Preferably, the vehicle performs calculations locally as follows:

[0021] The vehicle generates a task, and the vehicle local resource monitoring module informs the task processing decision-making module that the resources for calculating the corresponding task are sufficient;

[0022] The task processing decision-making module decides that the vehicle calculates the task by itself;

[0023] The vehicle task calculation module performs local calculations on the task.

[0024] Preferably, offloading to the MEC server for calculation or hybrid offloading of MEC resources and vehicle local resources for calculation is as follows:

[0025] The vehicle generates a task, and the vehicle local resource monitoring module informs the task processing decision-making module that the resources for calculating the task are insufficient. The task processing decision-making module selects one of the two modes: offloading to the MEC server and hybrid offloading of MEC resources and vehicle local resources:

[0026] If offloading to the MEC server is selected, the task processing decision-making module interacts with the resource allocation decision-making module of the registered MEC server to perform offloading calculation;

[0027] If hybrid offloading of MEC resources and vehicle local resources is selected, the task processing decision-making module is also used to divide the task into multiple subtasks and determine the tasks to be calculated locally and the tasks to be offloaded to the MEC server;

[0028] After receiving the request, the resource allocation decision module of the registered MEC server asks the local resource monitoring module of the MEC server whether there are sufficient resources to complete the task:

[0029] If so, it accepts the offloading calculation request. The task calculation module of the registered MEC server calculates the tasks offloaded by the vehicle and feeds back the results to the task processing decision module of the vehicle;

[0030] If not, it requests the task scheduling decision module of the gNB to schedule the task. The task scheduling decision module of the gNB receives the task scheduling request and makes a scheduling decision according to the resource information provided by the cluster resource monitoring module and the scheduling policy provided by the task scheduling policy module;

[0031] The scheduling decision is fed back to the relevant MEC server.

[0032] When the MEC server receives the feedback from the gNB, the MEC server updates the migration rules in the task migration module and judges whether it is the destination of task migration:

[0033] If it is not the destination of task migration, the task migration module will continuously migrate the received tasks;

[0034] If it is the destination of task migration, the task request will be sent to the resource allocation decision module, and then the task calculation module will calculate the task;

[0035] After the task calculation is completed, the MEC server feeds back the results to the requesting vehicle;

[0036] The requesting vehicle receives the feedback results:

[0037] If the offloading to the MEC server method is used, the result is the final result;

[0038] If the hybrid offloading is used, the task processing decision module integrates the results of different subtasks to obtain meaningful and complete results.

[0039] Preferably, in a resource-constrained VEC environment, the multi-hop task scheduling decision based on greedy bidding realizes effective task scheduling as follows:

[0040] During the offloading calculation process, for the rejected task requests, the MEC server forwards them to the RMC. When the RMC receives the rejected task requests, it matches the rejected task requests with the MEC servers in the response cluster through task scheduling decisions;

[0041] Model the task scheduling decision as a many-to-many auction model in Definition 1; where the content of Definition 1 is that the auction for task scheduling decision is a many-to-many auction; in the auction, the RMC acts as the auctioneer, and the rejected task requests act as bidders, bidding for the computing resources of the MEC servers managed by the RMC in the first cluster; each task can only be matched to one MEC server, but one MEC server is reverse-matched by multiple tasks; it should be noted that different from the normal auction types, the auction in Definition 1 is the matching of multiple tasks and multiple MEC servers, with multiple different available auction results; without loss of generality, for the simplicity of discussion, only one task needs to be offloaded on each vehicle, in the form of: Task i = <D i , A i , T i >; Task i represents the task offloaded by vehicle i (Veh i ); D i is the task volume of Veh i , Veh i represents the vehicle with vehicle number i, i = 1, 2, 3 ······; A i represents the CPU cycles required to compute the corresponding task; T i represents the deadline of the corresponding task; assume that the channels used by any adjacent nodes are bidirectional, represents the set of bids, including all bids in the auction process, b ij represents the bid of Task i for Serv j ; S ij = <b ij , j> represents the successful matching of Task i and Serv j ; Serv j represents the MEC server identified as j, j = 1, 2, 3, ······; that is, any auction result is a matching set and

[0042] Definition 2: The utility of Serv j is the profit obtained by renting out the computing resources of Serv j to the matched tasks for offloading computing, expressed as: where, U j and C j respectively represent the utility and cost of Serv j in one CPU cycle; the system utility is the total profit of all MEC servers involved in the set , and the system utility is calculated as: Will Bring in The specific system utility is expressed as:

[0043] Definition 3: The best auction is the auction that produces the maximum system utility. The auction result that produces the maximum system utility is the optimal matching set. Since the multi-hop task scheduling decision is equivalent to finding the optimal auction, the problem is transformed into finding the optimal matching set so that U system Maximize; then according to The optimal problem of the greedy bidding-based multi-hop task scheduling decision algorithm (GBMTS) is defined as follows:

[0044] Definition 4: The optimal problem OP is to find the optimal solution that makes U system The formula for maximizing the optimal matching set is as follows:

[0045]

[0046] Among them, W j Indicates Serv j Available computing resources;

[0047] Indicates that the matching set is generated by the bidding set; Indicates Serv j The total computing resources required by the matching tasks are less than or equal to the available computing resources; Represents Task i The offloading calculation delay is less than or equal to the deadline delay;

[0048] Preferably, in the auction, each task generates a bid for each MEC server. If some of the bids are meaningless for computing resources or the offload computing delay of the MEC server is not available for the corresponding task, then RMC removes the meaningless bids from the bid set in the initial stage. Remove from

[0049] The input of the preprocessing algorithm used in the initial stage is the bid set The output is in, Indicates to remove the bid set The bid collection after the meaningless bid in the bid is as follows:

[0050] Initialization: Create

[0051] Iterating over the input Each bid in b ij ;

[0052] judge and A i ≤W j ;

[0053] If so, then make

[0054] End condition judgment;

[0055] End the loop;

[0056] Return the processed

[0057] where t ij Off represents the latency of unloading vehicle i to server j, and T i is the maximum latency allowed for vehicle i. Since each MEC server has a radiation range (similar to a base station), if it exceeds T i the vehicle will drive out of the radiation range of the MEC server and the unloading fails; A i is the amount of computing resources required for the i-th vehicle; W j is the computing resource amount of the j-th server.

[0058] Preferably, a greedy bidding auction mechanism is adopted to match the task request to the edge server, and the multi-hop unloading of the task is realized as follows:

[0059] RMC constructs a weighted bipartite graph G=(V,E) according to the preprocessing result; the vertex set V consists of two disjoint subsets V task and the MEC server subset V server ; in the edge set E, for each there is a corresponding <Task i ,Serv j > pair to construct the edge e ij , and the weight w ij of the edge set E is expressed as: w ij =b ij -A i ×C j ;

[0060] Greedy matching is an iterative greedy selection process. In each iteration, an edge with the maximum weight is selected as the locally optimal matching set; when the greedy matching ends, all the selected matching pairs construct a solution set, and the solution set is the optimal matching set of OP.

[0061] An electronic device, comprising: a memory and at least one processor;

[0062] wherein, a computer program is stored on the memory;

[0063] The at least one processor executes the computer program stored in the memory, so that the at least one processor executes the hierarchical resource management and multi-hop task scheduling method based on vehicle-edge computing as described above.

[0064] A computer-readable storage medium stores a computer program, and the computer program can be executed by a processor to implement the hierarchical resource management and multi-hop task scheduling method based on vehicle-edge computing as described above.

[0065] The hierarchical resource management and multi-hop task scheduling method, device and medium of the present invention have the following advantages:

[0066] (1) Based on the typical VEC network structure, the present invention designs a general hierarchical resource management framework. On the basis of the hierarchical resource management framework, a specific decision algorithm interaction protocol is designed, and a multi-hop task scheduling decision algorithm based on greedy bidding is proposed to achieve effective task scheduling in a resource-constrained VEC environment, realize the load balancing of the network, solve the problem that a single MEC server cannot provide computing resources for multiple vehicle task requests within its coverage area, and improve the resource utilization rate of the system;

[0067] (2) The present invention proposes a general vehicle-edge two-level cluster network structure model. Within the cluster, the problem of matching task scheduling with the MEC server model is transformed into a weighted bipartite graph mapping matching problem with multi-knapsack constraints. The GBMTS decision algorithm is proposed to solve the matching problem, realize the reasonable allocation of resources, and plan the task scheduling path to achieve multi-hop offloading of tasks;

[0068] (3) The present invention performs task scheduling for time-sensitive vehicle users through an auction mechanism, and then allocates resources by matching the best MEC server through multi-hop offloading to avoid the problems of overtime work and resource waste in any MEC;

[0069] (4) Combining the network environment of the Internet of Vehicles and MEC, the present invention designs a hierarchical resource management framework, and using this framework can achieve effective network management;

[0070] (5) Since the computing resources of a single MEC server in the edge environment are limited, during the peak period of vehicle requests, the MEC may have insufficient computing resources and cannot process task requests in time. A multi-hop task scheduling decision algorithm based on greedy bidding is proposed to balance the network load and improve the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] The present invention will be further described below with reference to the drawings.

[0072] Appendix Figure 1Schematic diagram of the hierarchical resource management framework;

[0073] Appendix Figure 2 Schematic diagram of the hierarchical structure of the cluster-based VEC network;

[0074] Appendix Figure 3 Schematic diagram of an example of the weighted bipartite graph constructed by RMC;

[0075] Appendix Figure 4 Schematic diagram of the relationship between the number of requesting vehicles and the system utility when the number of MEC servers is different;

[0076] Appendix Figure 5 Schematic diagram of the relationship between the requested MEC servers and the system service rate when the number of L is different;

[0077] Appendix Figure 6 Schematic diagram of the relationship between the number of MEC servers and the system utility value. Detailed implementation method

[0078] The hierarchical resource management and multi-hop task scheduling method, device, and medium based on vehicle-edge computing of the present invention will be described in detail below with reference to the accompanying drawings of the specification and specific embodiments.

[0079] Embodiment 1:

[0080] This embodiment provides a hierarchical resource management and multi-hop task scheduling method based on vehicle-edge computing, and the method is as follows:

[0081] S1. Construct a hierarchical resource management framework based on the VEC network structure, and on the basis of the hierarchical resource management framework, use an interaction protocol to enable the vehicle to perform calculations locally and offload to the MEC server for calculation or a hybrid of MEC resources and vehicle local resources for offloading and calculation, and obtain the results of different tasks;

[0082] S2. In a resource-constrained VEC environment, implement effective task scheduling based on a greedy bidding-based multi-hop task scheduling decision;

[0083] S3. Use a greedy bidding-based auction mechanism to match task requests to edge servers and achieve multi-hop offloading of tasks.

[0084] As shown in the appendix Figure 1 The hierarchical resource management framework in step S1 of this embodiment includes two levels of clusters;

[0085] Among them, the first-level cluster includes a cluster head and several cluster members; the cluster head is the gNB node in the base station node, and the cluster members are RSUs and all vehicle members within the coverage range;

[0086] The cluster head of the secondary cluster is an RSU node, and the cluster members of the secondary cluster are vehicle members within the coverage of the RSU;

[0087] A primary cluster includes multiple secondary clusters, and there are multiple bidirectional wireless links between each pair of adjacent cluster heads, between each pair of adjacent cluster heads and cluster members, and between neighbor cluster members.

[0088] As shown Figure 2 in the figure, the VEC network structure in this embodiment includes three layers, namely layer0, layer1, and layer2;

[0089] Among them, layer0 is composed of offloading requesters and task executors; layer0 includes a vehicle local resource monitoring module, a task processing decision-making module, and a vehicle task calculation module; the vehicle local resource monitoring module is used to monitor the resource usage of the vehicle itself; the task processing decision-making module is used for task division and offloading; the vehicle task calculation module is used to calculate and return tasks;

[0090] Layer1 is composed of MEC servers, and the MEC server is the executor of offloading calculation and task migration; layer1 includes an MEC server local resource monitoring module, a resource allocation decision-making module, and a task migration module; the MEC server local resource monitoring module is used to monitor the resource usage of the MEC server itself; the resource allocation decision-making module is used to allocate necessary resources for tasks or give a task migration decision when resources are insufficient; the task migration module is used to execute task migration;

[0091] Layer2 is composed of base stations (such as gNBs), which serve as Resource Management Centers (RMCs) for task scheduling decision-making; layer2 includes a cluster resource monitoring module, a task scheduling strategy module, and a task scheduling decision-making module. The cluster resource monitoring module is used to monitor the resource usage of all nodes in the cluster; the task scheduling strategy module is used to provide different task scheduling strategies for different tasks according to the task situation; the task scheduling decision-making module is used to make scheduling decisions according to different task scheduling strategies.

[0092] The vehicle in step S1 of this embodiment performs local calculation as follows:

[0093] S1-101. The vehicle generates a task, and the vehicle local resource monitoring module notifies the task processing decision-making module that the resources for calculating the corresponding task are sufficient;

[0094] S1-102. The task processing decision-making module decides that the vehicle calculates the task by itself;

[0095] S1-103. The vehicle task calculation module performs local calculation on the task.

[0096] In the step S1 of this embodiment, the offloading to the MEC server for calculation or the hybrid offloading of MEC resources and vehicle local resources for calculation is specifically as follows:

[0097] S1-201. The vehicle generates a task. The vehicle local resource monitoring module notifies the task processing decision module that the resources for the calculation task are insufficient. The task processing decision module selects one of two modes: offloading to the MEC server and hybrid offloading of MEC resources and vehicle local resources:

[0098] If offloading to the MEC server is selected, the task processing decision module interacts with the resource allocation decision module of the registered MEC server to perform offloading calculation;

[0099] If hybrid offloading of MEC resources and vehicle local resources is selected, the task processing decision module is also used to divide the task into multiple subtasks and determine the tasks to be calculated locally and the tasks to be offloaded to the MEC server;

[0100] S1-202. After receiving the request, the resource allocation decision module of the registered MEC server asks the MEC server local resource monitoring module whether there are sufficient resources to complete the task:

[0101] If so, it accepts the offloading calculation request. The task calculation module of the registered MEC server calculates the task offloaded by the vehicle and feeds back the result to the task processing decision module of the vehicle;

[0102] If not, it requests the task scheduling decision module of the gNB to schedule the task. The task scheduling decision module of the gNB receives the task scheduling request and makes a scheduling decision according to the resource information provided by the cluster resource monitoring module and the scheduling policy provided by the task scheduling policy module;

[0103] S1-203. The scheduling decision is fed back to the relevant MEC server;

[0104] S1-204. When the MEC server receives the feedback from the gNB, the MEC server updates the migration rules in the task migration module and determines whether it is the destination of task migration:

[0105] If it is not the destination of task migration, the task migration module will continue to migrate the received tasks;

[0106] If it is the destination of task migration, the task request will be sent to the resource allocation decision module, and then the task calculation module will calculate the task;

[0107] S1-205. After the task calculation is completed, the MEC server feeds back the result to the requesting vehicle;

[0108] S1-206. The requesting vehicle receives the feedback result:

[0109] If the method of offloading to the MEC server is used, the result is the final result;

[0110] If hybrid offloading is used, the task processing decision module integrates the results of different subtasks to obtain a meaningful and complete result.

[0111] In the resource-constrained VEC environment in step S2 of this embodiment, the multi-hop task scheduling decision based on greedy bidding realizes effective task scheduling as follows:

[0112] S201. During the offloading calculation process, for the rejected task requests, the MEC server forwards them to the RMC. When the RMC receives the rejected task requests, it matches the rejected task requests with the MEC servers in the response cluster through task scheduling decision;

[0113] S202. Model the task scheduling decision as the many-to-many auction model in Definition 1; where the content of Definition 1 is that the auction of task scheduling decision is a many-to-many auction; in the auction, the RMC plays the role of the auctioneer, and the rejected task requests act as bidders to bid for the computing resources of the MEC servers managed by the RMC in the first cluster; each task can only be matched to one MEC server, but one MEC server is reverse-matched by multiple tasks; it should be noted that different from the normal auction type, the auction in Definition 1 is the matching of multiple tasks and multiple MEC servers, with multiple different available auction results; without loss of generality, for the sake of simplicity of discussion, only one task needs to be offloaded on each vehicle, in the form of: Task i = <D i ,A i ,T i >; Task i represents the task offloaded by vehicle i (Veh i ); D i is the task volume of Veh i , Veh i represents the vehicle with vehicle number i, i = 1, 2, 3 ······; A i represents the CPU cycles required to calculate the corresponding task; T i represents the deadline of the corresponding task; assume that the channels used by any adjacent nodes are bidirectional, represents the set of bids, including all bids in the auction process, b ij

[0114] represents the bid of Task i for Serv j , Sij = < b ij , j > represents Task i successfully matches with Serv j and j = 1, 2, 3, ······; that is, any auction result is a matching set and

[0115] Definition 2: Serv j The utility is the profit obtained by renting out the computing resources of Serv j to the matched tasks for offloading computing, expressed as: where U j and C j respectively represent the utility and cost of Serv j in one CPU cycle; the system utility is the total profit of all MEC servers involved in the set and the system utility is calculated as: Substitute into The specific system utility is expressed as:

[0116] Definition 3: The optimal auction is the auction that generates the maximum system utility, and the auction result that generates the maximum system utility is the optimal matching set; since the multi-hop task scheduling decision is equivalent to finding the optimal auction, the problem is transformed into finding the optimal matching set to maximize U system ; then, according to define the optimal problem of the greedy bidding-based multi-hop task scheduling decision algorithm (GBMTS) as follows:

[0117] Definition 4: The optimal problem OP is to find the optimal matching set that maximizes U system under the constraints of delay and computing resources, and the formula is as follows:

[0118]

[0119] where W j represents the available computing resources of Serv j ; indicates that the matching set is generated by the bidding set; represents that the total computing resources required by the tasks matched by Serv j are less than or equal to the available computing resources; represents that the offloading computing delay of Task i is less than or equal to the deadline;

[0120] In this embodiment, in the auction, each task generates a bid for each MEC server. If a part of the bids are meaningless for computing resources or the offloading computing delay of the MEC server is unavailable for the corresponding task, then at the initial stage, RMC will remove the meaningless bids from the bid set ;

[0121] Among them, the input of the preprocessing algorithm adopted in the initial stage is the bid set and the output is Among them, represents the bid set after removing the meaningless bids from the bid set ; specifically as follows:

[0122] Initialization: Create

[0123] Traverse each bid b in the input ij ;

[0124] Judge and A i ≤W j

[0125] If so, then make

[0126] End condition judgment;

[0127] End the loop;

[0128] Return the processed

[0129] Among them, t ij Off represents the delay of offloading vehicle i to server j, T i is the maximum delay allowed for vehicle i. Since each MEC server has a radiation range (similar to a base station), if it exceeds T i the vehicle will drive out of the radiation range of the MEC server and the offloading fails; A i is the amount of computing resources required for calculating the i-th vehicle; W j is the computing resource amount of the j-th server.

[0130] The key code of the preprocessing algorithm is as follows:

[0131]

[0132] As shown in the appendix Figure 3 In the auction mechanism adopting greedy bidding in step S3 of this embodiment, the task requests are matched to the edge servers to realize multi-hop offloading of tasks specifically as follows:

[0133] S301. The RMC constructs a weighted bipartite graph G = (V, E) according to the preprocessing result; the vertex set V consists of two disjoint subsets V task and the MEC server subset V server ; in the edge set E, for each there is a corresponding <Task i , Serv j > pair to construct the edge e ij , and the weight w ij of the edge set E is expressed as: w ij = b ij - A i × C j ;

[0134] S302. The greedy matching is an iterative greedy selection process. In each iteration, an edge with the maximum weight is selected as the locally optimal matching set; when the greedy matching ends, all the selected matching pairs construct a solution set, and the solution set is the optimal matching set of OP.

[0135] The key code of the greedy matching algorithm is as follows:

[0136]

[0137]

[0138] Finally, a simulation experiment is carried out, and the effectiveness of the algorithm is verified by detailed analysis according to the simulation effect.

[0139] In the simulation, the multi-hop task scheduling algorithm based on the highest bid (HBMTS) and the centralized heuristic greedy offloading algorithm (CHGO) are compared with the GBMTS algorithm proposed in this embodiment to verify the effectiveness of the GBMTS algorithm.

[0140] (1) HBMTS algorithm: It works in a distributed mode. Each vehicle generates a bid for each MEC server within three hops. When the MEC server receives the vehicle's bidding request, it sorts all the requests that can meet the delay constraint in descending order of the bidding request. Then the request with the highest bid will be replied. If the vehicle receives a response, it directly offloads the task, otherwise it randomly selects an MEC server to offload. This process will iterate until all requests are received or the delay constraint of the task expires.

[0141] (2) CHGO algorithm: It adopts a centralized management mode. The management center matches the tasks to the MEC servers according to the minimum processing delay. In each iteration, the tasks are matched and offloaded to the MEC servers through multi-hop R2R (RSU-to-RSU) paths, and the MEC servers can achieve the minimum processing delay. This process iterates until all vehicles have made offloading decisions.

[0142] The performance of the proposed scheme in this chapter is verified through the following experiments.

[0143] Experiment 1: Relationship between the number of requesting vehicles and system utility when the number of MEC servers is different

[0144] As shown in the appendix Figure 4 and 5 When the number of MEC servers is M = 5, M = 10, and M = 15 respectively, the system utility value changes with the increase in the number of requesting vehicles. As the number of requesting vehicles and the number of MEC servers increase, the system utility also increases. When M = 5 and M = 10, due to the limitation of MEC server resources, as the number of vehicles increases, the competition for resources becomes more intense, and fewer served vehicles are obtained. When the number of vehicles is greater than 25, the requests that meet the constraint conditions have been allocated, and even if the number of vehicles increases, the number of winners basically remains unchanged, and the decision converges.

[0145] Experiment 2: Relationship between MEC servers and system service rate when the number of vehicle requests is different

[0146] As shown in the appendix Figure 5 When the number of tasks L = 10, L = 20, and L = 30, the system service rate increases with the increase in MEC servers. As the number of MEC servers and vehicles increases, the system service rates of the three algorithms will also increase accordingly. Among them, the system service rate is the highest when L = 10 because the GBMTS algorithm can improve the system service speed by increasing the number of MEC servers to serve more vehicles.

[0147] Experiment 3: Relationship between the number of MEC servers and system utility value

[0148] As shown in the appendix Figure 6 As the number of edge servers increases, the system utility value shows an upward trend. Among them, the GBMTS decision is better than the minimum latency multi-hop task scheduling decision and the highest bid multi-hop task scheduling decision. Since the minimum latency decision only considers the optimal latency and ignores the server cost, the system utility value is the smallest. The CHGO algorithm considers latency and only needs to meet the CHGO decision, but it ignores the amount of resources required by the vehicle itself. The HBMTS algorithm considers the optimal bid but ignores latency, so its system utility value is lower than that of the GBMTS algorithm.

[0149] The simulation results show that under the conditions of meeting latency and capacity constraints, the GBMTS algorithm can increase the number of served vehicles in the vehicle-linked edge computing network and maximize the system utility.

[0150] Example 2:

[0151] This embodiment also provides an electronic device, including: a memory and at least one processor;

[0152] Wherein, the memory stores computer-executable instructions;

[0153] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the hierarchical resource management and multi-hop task scheduling method based on vehicle-edge computing in any embodiment of the present invention.

[0154] The processor may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0155] The memory can be used to store computer programs and / or modules. The processor realizes various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by calling the data stored in the memory. The memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function, etc.; the data storage area can store data created according to the use of the terminal, etc. In addition, the memory may also include high-speed random access memory, and may also include non-volatile memory, such as a hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one magnetic disk storage period, flash device, or other volatile solid-state storage devices.

[0156] Embodiment 3:

[0157] This embodiment also provides a computer-readable storage medium, in which multiple instructions are stored. The instructions are loaded by the processor, so that the processor executes the hierarchical resource management and multi-hop task scheduling method based on vehicle-edge computing in any embodiment of the present invention. Specifically, a system or device equipped with a storage medium may be provided. Software program codes for implementing the functions of any one of the above embodiments are stored on the storage medium, and the computer (or CPU or MPU) of the system or device reads and executes the program codes stored in the storage medium.

[0158] In this case, the program code read from the storage medium itself can realize the functions of any one of the above embodiments. Therefore, the program code and the storage medium storing the program code constitute a part of the present invention.

[0159] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Optionally, the program code can be downloaded from a server computer via a communication network.

[0160] In addition, it should be clear that not only can the actual operations be completed in part or in whole by executing the program code read by the computer, but also by means of instructions based on the program code, the operating system operating on the computer, etc., so as to realize the functions of any one of the above embodiments.

[0161] In addition, it can be understood that the program code read from the storage medium is written into the memory provided in the expansion board inserted into the computer or into the memory provided in the expansion unit connected to the computer, and then based on the instructions of the program code, the CPU, etc. installed on the expansion board or the expansion unit are made to execute part and all of the actual operations, so as to realize the functions of any one of the above embodiments.

[0162] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing, characterized in that: The method is as follows: A hierarchical resource management framework is built based on the VEC network structure. Based on the hierarchical resource management framework, an interactive protocol is used to enable vehicles to perform calculations locally and offload them to the MEC server for calculations or to mix MEC resources and vehicle local resources for offloading calculations to obtain the results of different tasks. In the resource-constrained VEC environment, multi-hop task scheduling decision based on greedy bidding achieves effective task scheduling; A greedy bidding auction mechanism is used to match task requests to edge servers to achieve multi-hop task offloading.

2. The hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing according to claim 1 is characterized in that: The hierarchical resource management framework includes two levels of clusters; Among them, the first-level cluster includes a cluster head and several cluster members; the cluster head is the gNB node in the base station node, and the cluster members are RSUs and all vehicle members within the coverage area; The cluster head of the secondary cluster is the RSU node, and the cluster members of the secondary cluster are the vehicle members within the coverage of the RSU; A primary cluster includes multiple secondary clusters, and multiple bidirectional wireless links exist between each pair of adjacent cluster heads, pairs of adjacent cluster heads and cluster members, and pairs of neighboring cluster members.

3. The hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing according to claim 1 or 2 is characterized in that: The VEC network structure consists of three layers, namely layer0, layer1 and layer2; Among them, layer0 is composed of offloading requesters and task executors; layer0 includes vehicle local resource monitoring module, task processing decision module and vehicle task calculation module; vehicle local resource monitoring module is used to monitor the resource usage of the vehicle itself; task processing decision module is used for task division and offloading; vehicle task calculation module is used to calculate and return tasks; The layer 1 layer is composed of MEC servers, which are the executors of offloading calculations and task migration. The layer 1 layer includes the MEC server local resource monitoring module, the resource allocation decision module, and the task migration module. The MEC server local resource monitoring module is used to monitor the resource usage of the MEC server itself. The resource allocation decision module is used to allocate necessary resources to tasks or make task migration decisions when resources are insufficient. The task migration module is used to perform task migration. The layer2 layer is composed of base stations, which serve as the resource management center and are used to make task scheduling decisions. The layer2 layer includes a cluster resource monitoring module, a task scheduling strategy module, and a task scheduling decision module. The cluster resource monitoring module is used to monitor the resource usage of all nodes in the cluster. The task scheduling strategy module is used to provide different task scheduling strategies for different tasks according to the task situation. The task scheduling decision module is used to make scheduling decisions according to different task scheduling strategies.

4. The hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing according to claim 1 is characterized in that: The vehicle performs the following calculations locally: The vehicle generates a task, and the vehicle local resource monitoring module informs the task processing decision module that the resources for calculating the corresponding task are sufficient; The task processing decision module decides whether the vehicle will calculate the task by itself; The vehicle mission calculation module performs local calculations on the mission.

5. The hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing according to claim 1 is characterized in that: Offloading to the MEC server for calculation or offloading mixed MEC resources and vehicle local resources for calculation is as follows: The vehicle generates a task, and the vehicle local resource monitoring module informs the task processing decision module that the resources for computing the task are insufficient. The task processing decision module selects one of the two modes: offloading to the MEC server and offloading with mixed MEC resources and vehicle local resources: If offloading to the MEC server is selected, the task processing decision module interacts with the resource allocation decision module of the registered MEC server to perform the offloading calculation; If hybrid MEC resource and vehicle local resource offloading is selected, the task processing decision module is also used to divide the task into multiple subtasks and decide the tasks to be calculated locally and the tasks to be offloaded to the MEC server; After receiving the request, the resource allocation decision module of the registered MEC server asks the local resource monitoring module of the MEC server whether there are enough resources to complete the task: If yes, the offloading calculation request is accepted, and the task calculation module of the registered MEC server calculates the task to be offloaded by the vehicle and feeds the result back to the task processing decision module of the vehicle; If not, the task scheduling decision module of the gNB is requested to schedule the task. The task scheduling decision module of the gNB receives the task scheduling request and makes a scheduling decision based on the resource information provided by the cluster resource monitoring module and the scheduling policy provided by the task scheduling policy module. The scheduling decision is fed back to the relevant MEC server. When the MEC server receives feedback from the gNB, it updates the migration rules in the task migration module to determine whether it is the destination of the task migration: If it is not the destination of task migration, the task migration module will continue to migrate the received tasks; If it is the destination of task migration, the task request will be sent to the resource allocation decision module, and then the task calculation module will calculate the task; After the task calculation is completed, the MEC server feeds the result back to the requesting vehicle; Request the vehicle to receive feedback results: If the method of offloading to the MEC server is used, the result is the final result; If hybrid offloading is used, the task processing decision module integrates the results of different subtasks to obtain meaningful and complete results.

6. The hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing according to claim 1 is characterized in that: In the resource-constrained VEC environment, the multi-hop task scheduling decision based on greedy bidding realizes effective task scheduling as follows: During the offloading computing process, the rejected task requests are forwarded by the MEC server to the RMC. When the RMC receives the rejected task requests, it matches the rejected task requests with the MEC servers in the response cluster through task scheduling decisions. The task scheduling decision is modeled as the many-to-many auction model in Definition 1; where Definition 1 states that the auction for task scheduling decisions is a many-to-many auction; in the auction, the RMC plays the role of the auctioneer, and the rejected task requests act as bidders to bid for the computing resources of the MEC server managed by the RMC in the first cluster; each task can only be matched to one MEC server, but one MEC server is reversely matched by multiple tasks; the auction in Definition 1 is a match between multiple tasks and multiple MEC servers, with multiple different available auction results; without loss of generality, only one task needs to be unloaded from each vehicle, in the form of: Task i = <D i ,A i ,T i >Task i Represents vehicle i (Veh i )Uninstalled tasks; D i For Veh i The amount of tasks, Veh i represents the vehicle i, i = 1, 2, 3, etc.; A i Indicates the CPU cycles required to calculate the corresponding task; T i represents the deadline delay of the corresponding task; assuming that the channels used by any adjacent nodes are bidirectional, Represents a bid set, which contains all bids during the auction. Represents Task i Serv j The bid price, S ij =<b ij ,j> indicates Task i With Serv j Successful matching, j = 1, 2, 3, ...; that is, any auction result is a matching set and Definition 2: Serv j The utility is to connect the Serv j The profit obtained by renting computing resources to matching tasks to offload computing is expressed as: Among them, U j and C j Respectively represent Serv j The utility and cost in a CPU cycle; the system utility is the sum of The total profit of all MEC servers involved in the system utility is calculated as: Will Bring in The specific system utility is expressed as: Definition 3: The best auction is the auction that produces the maximum system utility. The auction result that produces the maximum system utility is the optimal matching set. Since the multi-hop task scheduling decision is equivalent to finding the optimal auction, the problem is transformed into finding the optimal matching set so that U system Maximize; then according to The optimal problem of the multi-hop task scheduling decision algorithm based on greedy bidding is defined as follows: Definition 4: The optimal problem OP is to find the optimal solution that makes U system The formula for maximizing the optimal matching set is as follows: Among them, W j Indicates Serv j Available computing resources; Indicates that the matching set is generated by the bidding set; Indicates Serv j The total computing resources required by the matching tasks are less than or equal to the available computing resources; Represents Task i The offloading calculation delay is less than or equal to the deadline delay.

7. The hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing according to claim 1 is characterized in that: In the auction, each task generates a bid for each MEC server. If some of the bids are meaningless for computing resources or the offload computing delay of the MEC server is not available for the corresponding task, then RMC will remove the meaningless bids from the bid set in the initial stage. Remove from The input of the preprocessing algorithm used in the initial stage is the bid set The output is in, Indicates to remove the bid set The bid collection after the meaningless bid in the bid is as follows: Initialization: Create Iterating over the input Each bid in b ij ; judge And A i ≤W j ; If so, make End condition judgment; End the loop; Return the processed Among them, t ij Off represents the delay of unloading vehicle i to server j, T i is the maximum delay allowed by vehicle i, because each MEC server has a radiation range (similar to a base station). If it exceeds T i The vehicle leaves the radiation range of the MEC server and the uninstallation fails; A i is the amount of computing resources required to calculate the i-th vehicle; W j is the computing resource of the jth server.

8. The hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing according to claim 1 is characterized in that: The greedy bidding auction mechanism is used to match task requests to edge servers to achieve multi-hop offloading of tasks as follows: RMC constructs a weighted bipartite graph G = (V, E) based on the preprocessing results; the vertex set V is composed of two disjoint subsets V task and MEC server subset V server Composition; in the edge set E, for each There are corresponding <Task i ,Serv j >To construct edge e ij , the weight w of edge set E ij Expressed as: w ij =b ij -A i ×C j ; Greedy matching is an iterative greedy selection process. In each iteration, an edge with the maximum weight is selected as the local matching optimal set. When the greedy matching ends, all selected matching pairs construct a solution set, which is the optimal matching set of OP.

9. An electronic device, characterized in that: include: memory and at least one processor; Wherein, the memory stores a computer program; The at least one processor executes the computer program stored in the memory, so that the at least one processor executes the hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which can be executed by a processor to implement the hierarchical resource management and multi-hop task scheduling method based on vehicle-connected edge computing as described in any one of claims 1 to 8.

Images