A Vehicle Task Dynamic Offloading and Matching Method for VEC Networks

Abstract

The present invention provides a vehicle task dynamic offloading and matching method for a VEC network, including: obtaining task information of multiple tasks to be processed by a task vehicle in a corresponding time slot and information of surrounding vehicles of the task vehicle; initializing an offloading strategy corresponding to the time slot according to the task information and the surrounding vehicle information, where the offloading strategy indicates whether the corresponding task is to be executed by the task vehicle or offloaded to the corresponding surrounding vehicle for execution; adjusting the strategy based on the initialized offloading strategy to obtain an offloading strategy with a better execution cost, where the execution cost includes a delay cost, and when the CPU frequency of the surrounding vehicle cannot be directly obtained, the delay cost is determined using the frequency estimate of the corresponding CPU type; executing the corresponding task among the multiple tasks by the task vehicle or offloading it to the corresponding surrounding vehicle in the corresponding time slot according to the final offloading strategy; and updating the frequency estimate of the CPU type corresponding to the surrounding vehicle each time according to the execution delay of the surrounding vehicle for executing the corresponding task.

Description

Technical Field

[0001] The present invention relates to the field of vehicle edge computing, specifically to the technical field of offloading vehicle tasks, and more specifically, to a method for dynamic offloading and matching of vehicle tasks for a VEC network. Background Art

[0002] With the rapid development of the Internet of Vehicles, various new vehicle-mounted applications that are computationally intensive and latency-sensitive (such as autonomous driving, automatic navigation, etc.) have been widely applied. These applications usually require a large amount of computing resources. If these new vehicle-mounted applications are completely executed by the vehicle itself, it will pose a great challenge to vehicles with limited computing power. Therefore, in order to meet the requirements of a large number of new vehicle-mounted applications for latency, computing power, etc., vehicle edge computing (VEC) has been proposed as a feasible technology. In a VEC network, computing tasks generated by a task vehicle (TaV) can be offloaded to roadside units (RSUs) or surrounding vehicles (SuVs) for execution to reduce the latency of task processing. Regarding task offloading in vehicle edge computing, researchers at home and abroad have conducted a large amount of research, but there are still some problems at present, such as the problem of difficult dynamic offloading of vehicle tasks caused by vehicle mobility and the problem of difficult offloading tasks when vehicle privacy information (such as the CPU frequency of SuVs) is unknown.

[0003] Therefore, it is necessary to improve the existing technology. Summary of the Invention

[0004] Therefore, the purpose of the present invention is to overcome the above-mentioned defects of the existing technology and provide a method for vehicle task offloading.

[0005] The purpose of the present invention is achieved by the following technical solutions:

[0006] According to a first aspect of the present invention, there is provided a method for in-vehicle task offloading, including: obtaining task information of a plurality of tasks to be processed by a task vehicle in a corresponding time slot and information of surrounding vehicles of the task vehicle, where the information of surrounding vehicles includes CPU frequency; initializing an offloading strategy corresponding to the corresponding time slot according to the task information and the information of surrounding vehicles, where the offloading strategy indicates whether the corresponding task is to be executed by the task vehicle or offloaded to the corresponding surrounding vehicle for execution; performing strategy adjustment based on the initialized offloading strategy to obtain an offloading strategy with a more optimal execution cost, where when the CPU frequency corresponding to the surrounding vehicle cannot be directly obtained, the frequency estimate of the corresponding CPU type is used to determine the execution cost; executing the corresponding task among the plurality of tasks by the task vehicle or offloading it to the corresponding surrounding vehicle in the corresponding time slot according to the final offloading strategy; and updating the frequency estimate of the CPU type corresponding to the surrounding vehicle each time according to the execution delay of the corresponding task executed by the surrounding vehicle.

[0007] In some embodiments of the present invention, the method further includes: classifying the CPUs of the surrounding vehicles whose CPU frequencies cannot be directly obtained into the corresponding CPU types among a predetermined plurality of CPU types; when estimating the frequency of the CPU of the corresponding CPU type, determining the frequency estimate of the CPU of the corresponding CPU type according to the average frequency estimated for the CPU of this CPU type.

[0008] In some embodiments of the present invention, the method further includes: for each CPU type, respectively calculating the number of times the CPUs of the surrounding vehicles have been classified into this CPU type historically and the number of times the frequency estimates have been calculated for this CPU type; when estimating the frequency of the CPU of the corresponding CPU type, determining the frequency estimate of the CPU of the corresponding CPU type according to the average frequency estimated for the CPU of this CPU type and a correction parameter, where the correction parameter is determined according to the latest number of classification times, the number of estimation times corresponding to this CPU type, and the CPU frequency of the task vehicle.

[0009] In some embodiments of the present invention, the correction parameter is determined in the following manner:

[0010] ;

[0011] where represents the correction parameter corresponding to the CPU type , represents the CPU frequency corresponding to the task vehicle, represents the number of times the CPUs of the surrounding vehicles have been classified into the CPU type historically, represents the number of times the frequency estimates have been calculated for the CPU type .

[0012] In some embodiments of the present invention, when the CPU frequency corresponding to a corresponding surrounding vehicle cannot be directly obtained and the frequency estimation value for the CPU type of the surrounding vehicle has not been calculated, a predetermined CPU frequency is used to calculate the latency cost related to the CPU frequency of the surrounding vehicle in the current execution cost, or the execution cost related to the CPU frequency of the surrounding vehicle is ignored.

[0013] In some embodiments of the present invention, the execution cost includes a latency cost and an energy consumption cost, the latency cost includes a communication latency and an execution latency, and the energy consumption cost includes a communication energy consumption and an execution energy consumption.

[0014] In some embodiments of the present invention, the method further includes: performing policy adjustment based on the execution cost and the energy constraint, so that the remaining energy of the surrounding vehicle after executing the corresponding task in the corresponding time slot is greater than or equal to the energy threshold while optimizing the execution cost.

[0015] In some embodiments of the present invention, the method further includes:

[0016] Obtaining the energy harvesting value and the energy consumption value corresponding to the surrounding vehicle in the corresponding time slot, and determining the remaining energy of the surrounding vehicle after executing the corresponding task in the corresponding time slot according to the energy harvesting value and the energy consumption value, where the energy consumption value includes the energy value consumed for executing the corresponding task.

[0017] In some embodiments of the present invention, the step of initializing the offloading policy corresponding to the corresponding time slot according to the task information and the surrounding vehicle information includes: constructing a first set of surrounding vehicles with known CPU frequencies according to the surrounding vehicle information, which includes surrounding vehicles that directly obtain the CPU frequency or for which the frequency estimation value has been calculated; constructing a second set of surrounding vehicles with unknown CPU frequencies according to the surrounding vehicle information, which includes surrounding vehicles whose CPU frequencies cannot be directly obtained and for which the frequency estimation value has not been calculated; selecting a matching rule for matching the tasks from a variety of preset matching rules according to the number of tasks to be processed, the number of vehicles in the first set of surrounding vehicles, and the number of vehicles in the second set of surrounding vehicles, and initializing the offloading policy according to the selected matching rule.

[0018] In some embodiments of the present invention, the multiple preset matching rules include: Matching rule 1: When the number of vehicles in the second set of surrounding vehicles is greater than or equal to the number of tasks, select multiple surrounding vehicles with the shortest distances from the second set of surrounding vehicles to execute each task, and the number of selected surrounding vehicles is equal to the number of tasks; Matching rule 2: When the second set of surrounding vehicles is not empty and the number of vehicles therein is less than the number of tasks, select some tasks from the multiple tasks to be processed for execution by the vehicles in the second set of surrounding vehicles, and the remaining tasks are executed by the task vehicle and / or the vehicles in the first set of surrounding vehicles; Matching rule 3: When the second set of surrounding vehicles is empty, the multiple tasks to be processed are executed by the task vehicle and / or the vehicles in the first set of surrounding vehicles.

[0019] In some embodiments of the present invention, the step of adjusting the unloading strategy based on the initialized unloading strategy to obtain a more optimal execution cost unloading strategy includes: randomly swapping the vehicles executing the corresponding tasks in the unloading strategy multiple times, and updating the current unloading strategy to the unloading strategy after the current swap when the execution cost corresponding to any unloading strategy after the swap is smaller than that before the swap.

[0020] According to a second aspect of the present invention, there is provided an electronic device, including: one or more processors; and a memory, where the memory is used to store executable instructions; the one or more processors are configured to implement the steps of the method described in the first aspect by executing the executable instructions.

[0021] Compared with the prior art, the advantages of the present invention are as follows:

[0022] The present invention uses a time slot as the minimum time allocation unit for tasks. Within one time slot, the relative states of vehicles are relatively fixed, which can increase the probability of successfully unloading tasks in a vehicle movement scenario; in addition, some surrounding vehicles may not send some privacy information, such as CPU frequency, to the task vehicle. When the CPU frequency corresponding to the surrounding vehicle cannot be directly obtained, the present invention also determines the delay cost using the frequency estimation value of the corresponding CPU type, which can avoid the problem of difficult task unloading when the CPU frequency cannot be obtained, and estimating the CPU frequency of the vehicle can help optimize the decision-making of task unloading; moreover, after each surrounding vehicle finishes processing the unloading task, the frequency estimation value of the CPU type corresponding to the surrounding vehicle in the present invention is updated based on the execution delay of the task to improve the accuracy of calculating the execution cost of subsequent in-vehicle task unloading and better reduce the execution cost of task processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The following further describes embodiments of the present invention with reference to the drawings, where:

[0024] Figure 1 It is a schematic flowchart of a method for in-vehicle task unloading according to an embodiment of the present invention;

[0025] Figure 2 Schematic diagram of an implementation scenario according to an embodiment of the present invention;

[0026] Figure 3 Schematic diagram of energy calculation for the next time slot in a scenario with energy consumption and harvesting according to an embodiment of the present invention;

[0027] Figure 4 Experimental result curve corresponding to an experiment according to an embodiment of the present invention. Detailed implementation manners

[0028] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below through specific embodiments with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0029] As mentioned in the background art section, there are still some problems in task offloading in vehicle - edge computing, such as the problem of difficult dynamic offloading of vehicle tasks caused by vehicle mobility and the problem of difficult offloading tasks when vehicle privacy information (such as the CPU frequency of surrounding vehicles) is unknown. Therefore, the present invention uses a time slot as the minimum time allocation unit for tasks. Within one time slot, the relative states of vehicles are relatively fixed, which can improve the probability of successful task offloading in a vehicle - moving scenario; in addition, some surrounding vehicles may not send some privacy information, such as the CPU frequency, to the task vehicle. When the CPU frequency corresponding to the surrounding vehicle cannot be directly obtained, the present invention also determines the delay cost using the estimated value of the frequency of the corresponding CPU type, which can avoid the problem of difficult task offloading when the CPU frequency cannot be obtained. Estimating the CPU frequency of the vehicle can help optimize the decision - making of task offloading; moreover, after each surrounding vehicle completes the offloading task processing, the estimated value of the frequency of the corresponding CPU type of the surrounding vehicle in the present invention will be updated based on the execution delay of the task to improve the accuracy of the execution cost calculation for subsequent vehicle - mounted task offloading and better reduce the execution cost of task processing.

[0030] According to an embodiment of the present invention, as Figure 1 shown, a method for vehicle - mounted task offloading is provided, including steps S1, S2, S3, S4, and S5.

[0031] To better understand the present invention, the following will specifically describe each step in detail with reference to specific embodiments.

[0032] Step S1: Obtain the task information of multiple tasks to be processed by the task vehicle in the corresponding time slot and the information of the surrounding vehicles of the task vehicle, where the information of the surrounding vehicles includes the CPU frequency;

[0033] According to an embodiment of the present invention, a time slot refers to a time slice divided into a specified time length. For example, a continuous period of time is divided into T time slots, and let t ( ) represent the label of a certain time slot. When the time slot is divided into smaller time lengths (the specific time length can be determined according to the implementation scenario, and the present invention does not impose any restrictions on this), the relative states between vehicles are relatively fixed. Thus, by taking time slots as units to offload multiple tasks in each time slot, within one time slot, the relative states between vehicles are relatively fixed, which can increase the probability of successfully offloading tasks in the vehicle movement scenario. According to an embodiment of the present invention, the task information includes the number of tasks corresponding to multiple tasks to be processed in this time slot (such as: 5 tasks, 8 tasks, or 10 tasks, etc.) and the task volume corresponding to each task (such as: computing volume (used to determine the processing delay), data volume (used to determine the communication delay)). The surrounding vehicle information includes: CPU frequency, the number of surrounding vehicles. It should be understood that in the present invention, surrounding vehicles are vehicles that can establish wireless communication with the task vehicle and can provide task offloading services for the task vehicle. Surrounding vehicles may also be referred to as service vehicles, neighbor vehicles, surrounding service vehicles, etc.

[0034] Step S2: Initialize the offloading strategy corresponding to the corresponding time slot according to the task information and the surrounding vehicle information, where the offloading strategy indicates whether the corresponding task is to be executed by the task vehicle or offloaded to the corresponding surrounding vehicle for execution.

[0035] According to an embodiment of the present invention, step S2 includes: constructing a first set of surrounding vehicles with known CPU frequencies according to the surrounding vehicle information, which includes surrounding vehicles that directly obtain the CPU frequency or have calculated the frequency estimation value; constructing a second set of surrounding vehicles with unknown CPU frequencies according to the surrounding vehicle information, which includes surrounding vehicles whose CPU frequencies cannot be directly obtained and have not calculated the frequency estimation value; selecting a matching rule for matching the tasks from multiple preset matching rules according to the number of tasks to be processed, the number of vehicles in the first set of surrounding vehicles, and the number of vehicles in the second set of surrounding vehicles, and initializing the offloading strategy according to the selected matching rule. According to an embodiment of the present invention, the multiple preset matching rules include:

[0036] Matching rule 1: When the number of vehicles in the second set of surrounding vehicles is greater than or equal to the number of tasks, select the nearest multiple surrounding vehicles from the second set of surrounding vehicles to execute each task, and the number of selected surrounding vehicles is equal to the number of tasks;

[0037] Matching rule 2: When the set of second surrounding vehicles is not empty and the number of vehicles in it is less than the number of tasks, select some tasks from the multiple tasks to be processed (for example: select according to the task volume or randomly) to be executed by the vehicles in the set of second surrounding vehicles, and the remaining tasks are executed by the task vehicle and / or the vehicles in the set of first surrounding vehicles;

[0038] Matching rule 3: When the set of second surrounding vehicles is empty, the multiple tasks to be processed are executed by the task vehicle and / or the vehicles in the set of first surrounding vehicles.

[0039] According to an embodiment of the present invention, when initializing the offloading strategy, it is determined which matching rule to use to determine the surrounding vehicles matched by the tasks in the initialized offloading strategy according to the above-mentioned various preset matching rules. Thus, according to the number of tasks of the multiple tasks to be processed, the number of vehicles in the set of first surrounding vehicles, and the number of vehicles in the set of second surrounding vehicles, the offloading strategy can be constructed according to the corresponding matching rules of matching rule 1, matching rule 2, or matching rule 3. The technical solution of this embodiment can at least achieve the following beneficial technical effects: The present invention initializes the offloading strategy in the above manner, which can efficiently explore the frequency estimation values of the CPUs of the surrounding vehicles when there are many surrounding vehicles with unknown CPU frequencies and few tasks, and when there are few surrounding vehicles with unknown CPU frequencies and many tasks, comprehensively utilize the surrounding vehicles with known CPU frequencies (such as directly obtaining the CPU frequency or estimating the frequency estimation value in the previous time slot) to determine the matching rule, so that there are more optional surrounding vehicles for the offloading strategy, better reducing the execution cost and improving the task processing efficiency.

[0040] To ensure the efficiency of task offloading and execution, the number of tasks offloaded to a single surrounding vehicle in a time slot can be limited. According to an embodiment of the present invention, the method further includes: adding a constraint condition in the offloading strategy so that the number of tasks offloaded by the task vehicle to a surrounding vehicle in a time slot is less than or equal to the offloading quantity threshold (for example, 1 or 2, etc.).

[0041] Step S3: Based on the initialized offloading strategy, perform strategy adjustment to obtain an offloading strategy with a more optimal execution cost, where when the CPU frequency corresponding to the surrounding vehicle cannot be directly obtained, the frequency estimation value of the corresponding CPU type is used to determine the execution cost.

[0042] According to an embodiment of the present invention, step S3 includes: randomly swapping the vehicles executing corresponding tasks in the offloading strategy multiple times, and updating the current offloading strategy to the offloading strategy after the current swap when the execution cost corresponding to any offloading strategy after the swap is smaller than that before the swap. According to an embodiment of the present invention, in the previous offloading strategy, it is indicated that the surrounding vehicle A executes task 1 and the surrounding vehicle B executes task 2; if in the current random swap, the surrounding vehicle A executes task 2 and the surrounding vehicle B executes task 1; and after this swap, if the calculated execution cost is lower than the execution cost calculated before this swap, then update the offloading strategy to the offloading strategy after this swap. Thus, the execution cost is optimized. According to an embodiment of the present invention, a swap count threshold can be preset (such as 3 times, 5 times, or 8 times, etc.), and when the swap count reaches the swap count threshold, the offloading strategy with the optimal current execution cost is used as the final offloading strategy. According to an embodiment of the present invention, the CPU type corresponding to the surrounding vehicle can be allocated according to the information communicated with the surrounding vehicle, such as according to the wireless signal name during communication with the surrounding vehicle, the device number in the wireless information, or alternatively, according to the specified test data packet sent during communication establishment, and determining its CPU type according to the response of the surrounding vehicle to the test data packet; it should be understood that this is only for illustration, and the implementer can determine according to the implementation needs, and the present invention does not make any restrictions on this.

[0043] To comprehensively consider energy consumption and optimize the execution cost in terms of time and energy consumption, according to an embodiment of the present invention, the execution cost includes a delay cost and an energy consumption cost. The delay cost includes a communication delay and an execution delay, and the energy consumption cost includes a communication energy consumption and an execution energy consumption.

[0044] According to an embodiment of the present invention, define as the amount of computation required for the vehicle to execute the task and as the CPU frequency of the task vehicle. The local execution delay is:

[0045] ;

[0046] Based on the execution delay, the execution energy consumption for locally executing the task is:

[0047] ;

[0048] where is the computing power of the task vehicle, is an energy consumption conversion coefficient, and its value is related to the chip architecture.

[0049] According to an embodiment of the present invention, the task is offloaded to the surrounding vehicle The latency of execution includes: 1) the task uploaded from the task vehicle to the surrounding vehicles in the uplink transmission latency; 2) the task processing latency of the surrounding vehicles ; 3) the downlink transmission latency of the task result from the surrounding vehicles back to the task vehicle. In this embodiment, considering that the data volume of the task result is usually very small, the latency of the task result being backhauled to the task vehicle can be ignored. Therefore, the latency of task offloading can be expressed as:

[0050] ;

[0051] where, is the data volume of the uploaded task, is the CPU frequency of the vehicle executing the task ; is the transmission rate of the uplink, which can be expressed as:

[0052] ;

[0053] where, is the wireless channel bandwidth between the task vehicle and the surrounding vehicles ; represents the transmit power of the task vehicle, represents the small-scale fading gain (following Rayleigh distribution), N 0 represents the noise power, represents the large-scale fading gain following the 3GPP path loss model, which can be expressed as:

[0054]

[0055] where, represents the distance between the task vehicle and the surrounding vehicles .

[0056] Based on the task offloading latency, the energy consumption of task offloading can be expressed as:

[0057] ;

[0058] where, represents the transmit power of the task vehicle, is the data volume of the uploaded task, is the transmission rate of the uplink, is the computing power of the surrounding vehicles ; is for executing the task required computing volume, is the surrounding vehicle executing the task CPU frequency of the surrounding vehicles If the computing power of the surrounding vehicles cannot be directly obtained, it can be determined according to the frequency estimation value. For example, a conversion formula between the CPU frequency and the computing power is preset in advance, and the computing power corresponding to the surrounding vehicles of the CPU with the corresponding frequency estimation value is estimated.

[0059] According to an embodiment of the present invention, when the CPU frequency corresponding to the corresponding surrounding vehicle cannot be directly obtained and the frequency estimation value of the CPU type for the surrounding vehicle has not been calculated, a predetermined CPU frequency is adopted when calculating the delay cost related to the CPU frequency of the surrounding vehicle in the current execution cost (for example, a default CPU frequency is set. When the CPU frequency corresponding to each CPU type has not been estimated, this default CPU frequency is adopted when calculating the execution cost to adjust the offloading strategy; or, a default CPU frequency is set for each CPU type. When the CPU frequency corresponding to the corresponding CPU type has not been estimated, the default CPU frequency corresponding to this CPU type is adopted when calculating the execution cost to adjust the offloading strategy).

[0060] According to another embodiment of the present invention, when the CPU frequency corresponding to the corresponding surrounding vehicle cannot be directly obtained and the frequency estimation value of the CPU type for the surrounding vehicle has not been calculated, the execution cost related to the CPU frequency of the surrounding vehicle is ignored. For example, the execution delay in the delay cost and the execution energy consumption in the energy consumption cost are the execution costs related to the CPU frequency. In this case, the execution delay and / or the execution energy consumption in the execution cost can be ignored.

[0061] According to an embodiment of the present invention, the method further includes: adjusting the strategy based on the execution cost and the energy constraint, so that the remaining energy of the surrounding vehicle after executing the corresponding task in the corresponding time slot is greater than or equal to the energy threshold while optimizing the execution cost. For example, in an extreme case, the energy threshold can be set to 0. However, in order for the vehicle to have energy to drive after executing the task, the energy threshold can be set to a larger value, which can be specifically set according to the actual application scenario, and the present invention does not make any limitation on this.

[0062] In some scenarios, the influence of energy harvesting can also be considered. According to an embodiment of the present invention, the method further includes: obtaining the energy harvesting value and the energy consumption value corresponding to the surrounding vehicle in the corresponding time slot, and determining the remaining energy of the surrounding vehicle after executing the corresponding task in the corresponding time slot according to the energy harvesting value and the energy consumption value, where the energy consumption value includes the energy value consumed for executing the corresponding task. For example, consider the energy recovered by the regenerative braking of braking and / or the energy collected by the solar panel. Determine the remaining energy of the surrounding vehicle after executing the corresponding task in the corresponding time slot at least according to the corresponding energy harvesting value.

[0063] According to an embodiment of the present invention, the method further includes: when calculating the execution cost, calculating the weighted sum of the energy consumption cost and the latency cost according to the weights set for the energy consumption cost and the latency cost respectively, to obtain the corresponding execution cost. By setting the weights, the corresponding weight values can be set according to the specific scenario, and while ensuring that the comprehensive execution cost is relatively optimal, more emphasis can be placed on reducing the cost in terms of energy consumption cost or latency cost.

[0064] Step S4: According to the final offloading strategy, execute the corresponding task among the multiple tasks by the task vehicle or offload it to the corresponding surrounding vehicle in the corresponding time slot.

[0065] According to an embodiment of the present invention, in the final offloading strategy, it can be indicated whether each task is to be executed by the task vehicle or offloaded to the corresponding surrounding vehicle. For example, assume that there are 3 tasks in a time slot, namely Task 1, Task 2, and Task 3; and there are 3 surrounding vehicles of the task vehicle, namely Surrounding Vehicle 1, Surrounding Vehicle 2, and Surrounding Vehicle 3; in the final offloading strategy, for example, it is indicated that Task 1 is to be executed by Surrounding Vehicle 2, Task 2 is to be executed by Surrounding Vehicle 1, and Task 3 is to be executed by the task vehicle. Therefore, in this time slot, Task 1 will be offloaded to Surrounding Vehicle 2 through wireless communication, Task 2 will be executed by Surrounding Vehicle 1, and Task 3 will be executed locally by the task vehicle.

[0066] Step S5: Each time, update the frequency estimation value of the CPU type corresponding to the surrounding vehicle according to the execution latency of the surrounding vehicle for executing the corresponding task.

[0067] According to an embodiment of the present invention, the frequency estimation value of the CPU type is obtained in the following manner: divide the CPUs of the surrounding vehicles whose CPU frequencies cannot be directly obtained into the corresponding CPU types among a predetermined variety of CPU types; when estimating the frequency of the CPUs of the corresponding CPU type, determine the frequency estimation value of the CPUs of this CPU type according to the average frequency estimated for the CPUs of this CPU type. Update the previous frequency estimation value with the latest estimated frequency estimation value.

[0068] According to an embodiment of the present invention, the corresponding frequency estimation value of CPU type i is calculated in the following manner:

[0069] ;

[0070] wherein, represents the set of surrounding vehicles whose CPU types belong to CPU type i in the corresponding time slot, represents the set the number of surrounding vehicles in, represents the execution of the corresponding task in time slot t belonging to the set The frequencies estimated by the CPUs of the surrounding vehicles are summed up. Thus, the frequency estimate of the CPU of this CPU type is determined based on the average value of the frequencies estimated by the CPUs of this type.

[0071] To avoid the estimated frequency being too high and affecting the actual processing efficiency, further, according to an embodiment of the present invention, for each CPU type, the number of times the CPUs of the surrounding vehicles have been classified into this CPU type in history and the number of times the frequency estimates have been calculated for this CPU type are calculated respectively; when estimating the frequency of the CPU of the corresponding CPU type, the frequency estimate of the CPU of this CPU type is determined according to the average value of the frequencies estimated by the CPU of this type and a correction parameter, and the correction parameter is determined according to the latest classification number, the number of estimates corresponding to this CPU type, and the CPU frequency of the task vehicle. The technical solution of this embodiment can at least achieve the following beneficial technical effects: In this embodiment, the average value of the estimated frequencies is corrected by the correction parameter to avoid estimating too high a frequency, resulting in the difficulty of efficiently executing the offloaded tasks after unloading, thereby ensuring the efficiency of task execution. According to an embodiment of the present invention, after each calculation of the average value of the frequencies estimated by the CPU of the corresponding CPU type, the average value of the frequencies is subtracted by the correction parameter to obtain the frequency estimate of the CPU of this CPU type, and the correction parameter is based on the CPU frequency of the task vehicle. The magnitude of the correction parameter is positively correlated with the classification number and negatively correlated with the number of estimates. The technical solution of this embodiment can at least achieve the following beneficial technical effects: The present invention is based on the classification number and the number of estimates statistically in the early stage (equivalent to a statistical interval). Based on the interval estimation method, the CPU frequency of the task vehicle is used as a reference. When the number of estimates is certain, if the classification number is relatively larger, the correction parameter is relatively larger (positively correlated); when the classification number is certain, if the number of estimates is relatively larger, the correction parameter is relatively smaller (negatively correlated). According to an embodiment of the present invention, the correction parameter is determined in the following manner:

[0072] ;

[0073] wherein, represents the correction parameter corresponding to the CPU type ; represents the CPU frequency corresponding to the task vehicle, represents the number of times the CPUs of the surrounding vehicles have been classified into the CPU type ; represents the number of times the frequency estimates have been calculated for the CPU type The estimated number of times the frequency estimate has been calculated. The technical solution of this embodiment can at least achieve the following beneficial technical effects: Based on the correction parameters of the partitioning times and the estimation times, the present invention can better correct the frequency estimate of the corresponding type of CPU in a manner of interval estimation based on the previous statistical interval, so as to better optimize the execution cost.

[0074] According to an embodiment of the present invention, in the case of estimating the frequency of a certain type of CPU multiple times, the frequency average value is calculated in the following manner: According to an embodiment of the present invention, if the correction parameter is considered, then for the surrounding vehicles belonging to the CPU type the frequency estimate is expressed as: .

[0075] The following uses a schematic scenario to illustrate the technical solution of the present invention. It should be noted that, for the convenience of explaining some technical principles of the present invention, some places are exemplified by some hypothetical scenarios and probability distributions. In actual application scenarios, implementers can adjust specifically according to needs, and the present invention makes no restrictions on this.

[0076] According to an embodiment of the present invention, a method for vehicle-mounted task offloading is proposed, or a method for dynamic vehicle-mounted task offloading in a vehicle-mounted edge computing network, to minimize the weighted sum of the latency and energy consumption of the entire system. The method includes:

[0077] Step K1: Construct a vehicle-mounted edge computing system model framework, including a task generation and offloading model and a vehicle movement model, and consider the dynamic task offloading of task vehicles when generating different tasks (number of tasks, task volume) in each time slot and different sets of surrounding vehicles SuVs;

[0078] Step K2: Based on the system model constructed in Step K1, perform mathematical modeling on the local execution and task offloading processes, and calculate the latency and power consumption generated by the vehicle-mounted tasks when executed locally and at the edge respectively;

[0079] Step K3: Based on Step K2 and energy harvesting technology, construct an energy harvesting model for the surrounding vehicles SuVs;

[0080] Step K4: Based on the different latency and energy consumption values obtained in Step K2, and under the condition that the battery level of SuVs is greater than 0, an optimization problem is obtained with the goal of minimizing the weighted sum of latency and energy consumption. To solve this optimization problem, the optimization problem is decomposed into sub-problems of minimizing the weighted sum of latency and energy consumption in a single time slot.

[0081] Step K5: To solve the optimization problem of minimizing latency and energy consumption, an EEOM algorithm is proposed. By learning, the privacy information of vehicles (corresponding to the frequency estimation value) is obtained, and then the optimal offloading strategy is obtained.

[0082] The following is a detailed introduction step by step. Among them, the serial numbers of some formulas are marked so that the serial numbers can be used to refer to the corresponding formulas in the subsequent pseudocode, making the pseudocode more concise and easy to understand:

[0083] Step K1: Build a system model:

[0084] In this embodiment, a two-way highway model is simulated. As Figure 2 shown, considering the vehicle-to-vehicle (V2V) task offloading problem in a vehicular edge computing system (hereinafter referred to as the VEC system), the vehicles involved in task offloading can be divided into two categories: task vehicles (TaV) that generate and offload computing tasks (corresponding to multiple tasks to be processed); multiple surrounding vehicles (abbreviated as SuVs, and a single surrounding vehicle is abbreviated as SuV). The SuVs have spare computing power and can provide computing resources for task vehicles. Task vehicles can offload corresponding computing tasks to SuVs for processing. For the vehicle-to-vehicle task offloading in the VEC system and the scenario where vehicle positions change at all times, the present invention models task offloading and vehicle movement.

[0085] K11: Define the process of task generation and task offloading;

[0086] In the VEC system, task vehicles can offload tasks to surrounding vehicles SuVs to reduce the computing burden of task vehicles. Based on the mobility characteristics of vehicles, the present invention characterizes the dynamics of the VEC system with time slots. The present invention divides the continuous time line into T time slots, and let t ( ) represent the label of a certain time slot. Task vehicles have multiple available SuVs to perform task offloading in each time slot. Use label 0 to represent the task vehicle, and use the set of vehicle labels within the communication range of the task vehicle as represented. At the beginning of time slot t, the task vehicle will generate multiple tasks, and use to represent the set of task labels. Task vehicles can choose to execute some or all of the multiple tasks locally or choose to offload some or all of the multiple tasks to the SuVs within the communication range for execution.

[0087] K12: Establish a vehicle movement model;

[0088] Due to the inherent mobility of vehicles, the vehicles within the communication range of the mission vehicle change with time slots. This embodiment proposes a vehicle mobility model to model the mobility of vehicles. At the beginning of time slot t, use to represent the number of vehicles entering the communication range of the mission vehicle, to represent the number of vehicles leaving the communication range of the mission vehicle. Therefore, the number of vehicles within the communication range of the mission vehicle can be expressed by the following formula:

[0089] (1)

[0090] where, is the initial number of SuVs, which is a known value. Assume and respectively follow Poisson distributions with parameters and and can be expressed by the formula:

[0091] (2)

[0092] (3)

[0093] where, represents the rate at which surrounding vehicles arrive within the communication range of the mission vehicle, represents the rate at which surrounding vehicles leave the communication range of the mission vehicle, represents the corresponding optional value used to define the Poisson distribution, represents the corresponding optional value used to define the Poisson distribution.

[0094] Step K2: Mathematically model the local execution and task offloading processes;

[0095] K21: Data model the local execution process:

[0096] Define as the amount of computation required for the mission vehicle to locally execute task and as the CPU frequency of the mission vehicle. The local execution delay is:

[0097] (4)

[0098] Based on the execution delay, the execution energy consumption of locally executing task is:

[0099] (5)

[0100] where, is the computing power of the mission vehicle, is an energy consumption conversion coefficient, and its value is related to the chip architecture.

[0101] K22: Perform data modeling on the task offloading process:

[0102] Task is offloaded to the SuV The latency for execution includes: 1) Task uploaded from the mission vehicle to the SuV uplink transmission latency (corresponding to communication latency); 2) Task processing latency of the SuV (corresponding to execution latency); 3) Downlink transmission latency of the task result from the SuV back to the mission vehicle. Considering that the data volume of the task result is usually very small in the present invention, the latency of the task result back to the mission vehicle can be ignored. Therefore, the latency of task offloading can be expressed as:

[0103] (6)

[0104] wherein, is the data volume of the uploaded task, is the CPU frequency of the vehicle executing the task, is the transmission rate of the uplink, which can be expressed as:

[0105] (7)

[0106] wherein, is the wireless channel bandwidth between the mission vehicle and the vehicle , is the transmission power of the mission vehicle, is the small-scale fading gain (assuming a Rayleigh distribution), and N0 is the noise power. is the large-scale fading gain following the 3GPP path loss model, which can be expressed as:

[0107] (8)

[0108] wherein, is the distance between the mission vehicle and the vehicle .

[0109] Based on the task offloading latency, the energy consumption of task offloading can be expressed as:

[0110] (9)

[0111] wherein, is the vehicle Calculated power.

[0112] Step K3: Construct an energy harvesting model;

[0113] Considering the application of energy harvesting technology, this embodiment designs an energy harvesting model, as Figure 3 shown. Assume that each SUV has the ability to harvest energy. An SUV can harvest a unit of energy and store it in the battery at time slot t for use in subsequent time slots. That is, the energy available for processing offloading tasks at time slot t + 1 is:

[0114] (10)

[0115] Where, is the maximum capacity of the battery used to store the harvested energy. Here, the constraint is set, and it is assumed that all tasks satisfy . represents the energy value harvested by the SUV at time slot t. The energy harvesting process is modeled as a Poisson process with parameter Poisson process.

[0116] Step K4: Formulate an optimization problem;

[0117] K41: Matching scheme between tasks and vehicles:

[0118] This embodiment models the task offloading problem in a multi-task, multi-vehicle scenario as a many-to-many matching problem. The rules of the matching scheme are as follows:

[0119] Rule 1: Each task must be executed locally or offloaded to an SUV for execution;

[0120] Rule 2: The number of tasks offloaded from a task vehicle to an SUV in a time slot is less than or equal to 1;

[0121] Rule 3: A task vehicle can execute all the tasks it generates by itself.

[0122] Based on the above three rules and matching theory, the present invention defines the matching strategy for time slot as where is a matching pair, which means that task can be executed by vehicle .

[0123] According to Rule 1, there is where ;

[0124] According to Rule 2, there is where ;

[0125] According to Rule 3, there is .

[0126] Based on the above rules, there is .

[0127] K42: Determine the optimization objective:

[0128] Given a matching scheme , considering the latency and energy consumption generated by the task, the execution cost corresponding to this matching scheme is defined as the weighted sum of latency and energy consumption:

[0129] (11)

[0130] Among them, and are the weight factors of execution latency and energy consumption respectively. , according to different task requirements, different weight factors can be set to adjust the impact of latency and energy consumption on the execution cost. For example, when the task is a latency-sensitive task, a large can be set, and when the task is an energy consumption-sensitive task, a large can be set. It can be expressed as:

[0131] (12)

[0132] The task vehicle selects a matching scheme , aiming to minimize the cumulative execution cost of the VEC system. In addition, there is a constraint that the battery power value of each SUV is greater than 0. Therefore, the optimization problem can be expressed as:

[0133] (13)

[0134] The constraint here is to ensure that: after the offloading tasks are completed according to the matching scheme , at the beginning of time slot , the battery power value of each SUV is greater than 0.

[0135] According to the Oracle criterion, the optimization problem (13) can be decomposed into T independent sub-problems, expressed as:

[0136] (14)

[0137] By independently solving the T sub-problems, the optimal solution of the optimization problem (13) can be obtained as the set .

[0138] Step K5: Propose a task offloading and matching scheme based on exploration and exploitation;

[0139] To solve sub - problem (14), the task vehicle must have prior knowledge of the CPU frequencies ( , ) of each SUV. However, since the CPU frequencies of SUVs are private information, it is difficult to solve the optimization problem (14). Therefore, this embodiment proposes an Exploration - Exploitation Based Task Offloading and Matching Scheme (EEOM). This scheme can estimate the CPU frequencies of SUVs. Based on the estimated CPU frequencies, the optimization problem (14) is solved, and then the optimal matching scheme is obtained.

[0140] Considering the diversity of CPUs, the present invention assumes that there are a total of S types of CPUs. If some SUVs have the same type of CPU, their CPU frequencies will follow the same distribution. In particular, if the CPU type of SUV belongs to CPU type , then its CPU frequency follows distribution.

[0141] To represent whether the CPU of SUV belongs to CPU type , the present invention defines a two - dimensional array:

[0142] (15)

[0143] In addition, this embodiment introduces counters and , representing the number of times the CPU of type appears up to time slot (corresponding to the number of times the CPUs of surrounding vehicles in history are classified into CPU type ), representing the number of times the CPU of type appears and is selected up to time slot (corresponding to the number of estimation times for which the frequency estimation value has been calculated for CPU type ).

[0144] Based on , and , this embodiment proposes an EEOM algorithm, which includes two stages: exploration and exploitation. If there are vehicles with unselected CPU types within the communication range of the task vehicle, the algorithm enters the exploration stage; otherwise, the algorithm enters the exploitation stage. The description of the EEOM algorithm is shown in Algorithm 1.

[0145] K51: Exploration stage:

[0146] In the exploration stage, the task vehicle preferentially offloads tasks to SuVs with unselected CPU types. Among them, it is defined that is the set of SuVs with unselected CPU types at time slot t. Since the CPU frequencies of SuVs are unknown, it is difficult to obtain a matching scheme by solving the optimization problem (14). Therefore, in this stage, the optimization objective is obtained by deleting the polynomial related to in the optimization problem (14); on the other hand, the task vehicle may also have no prior knowledge of the battery levels of each SuV. The present invention assumes that at time slot t, for all vehicles that enter the communication range of the task vehicle, their = (It should be understood that in the actual scenario, if the feedback on the battery level of the surrounding vehicles can be directly obtained, the actual value can be used). Therefore, the present invention formulates the following optimization problem without battery constraints based on the optimization problem (14):

[0147] (16)

[0148] where , is expressed as:

[0149] (17)

[0150] Since the CPU frequency of each SuV belongs to only one CPU type, so . By solving the optimization problem (16), the optimal matching scheme can be obtained. According to after the task offloading is completed, the task vehicle can observe the latency of executing the task ( ), and obtain according to formula (6). Considering that the CPU type of SuV belongs to CPU type , that is, obeys distribution , the present invention estimates the expected value of obtained through according to:

[0151] (18)

[0152] Among them, represents the set in which the CPUs of the SuVs belong to the type , and the mission vehicle can calculate according to the following formula :

[0153] (19)

[0154] Among them, , is obtained through formula (9). Finally, according to the optimal matching scheme , update .

[0155] K52: Utilization phase:

[0156] In the utilization phase, the CPU types of all the SuVs within the communication range of the mission vehicle have been selected. Although the mission vehicle still does not know the exact CPU frequency of the SuVs, the mission vehicle can estimate through the obtained in the exploration phase. Therefore, the optimization problem in the utilization phase is:

[0157] (20)

[0158] Among them, is expressed as

[0159] (21)

[0160] Among them, is related to the estimated CPU frequency . In addition, the power values of each SuV can be obtained, and the energy of the SuV in the next time slot can be calculated according to the following method.

[0161] (22)

[0162] Among them, , can be expressed as

[0163] (23)

[0164] To solve the optimization problem (20), it is necessary to estimate the CPU frequency of the SuV. The present invention estimates it by means of interval estimation . In particular, if the CPU of the SuV belongs to the CPU type , then its estimated value is expressed as:

[0165] (24)

[0166] where is the frequency estimated value of the CPU type , and is the confidence interval (corresponding to the correction parameter).

[0167] By solving the optimization problem (20), the optimal matching scheme can be obtained , according to After the task offloading is completed, the task vehicle can observe the time delay of executing the task ( ), and obtain it according to formula (6) . According to the optimal matching scheme , update , which is expressed as:

[0168] (25)

[0169] where in the numerator is the historical estimated value. Finally, update the counter .

[0170] K53: Swap matching algorithm

[0171] Purpose of introducing the swap matching algorithm: Since the optimization problems (16) and (20) are many-to-many matching problems, in order to solve these problems, the present invention proposes two swap matching algorithms to optimize the matching relationship between tasks and SuVs to obtain the optimal matching scheme.

[0172] K531: Construct two swap matching algorithms

[0173] In this embodiment, the swap matching algorithm is divided into a swap matching algorithm without power constraint and a swap matching algorithm under power constraint.

[0174] Swap matching algorithm without power constraint: To solve the optimization problem (16), this embodiment proposes Algorithm 2 to obtain the optimal matching scheme. In the exploration stage, the task vehicle offloads the task to the vehicle whose CPU type has not been selected. In this embodiment, it is assumed that at time slot t, all vehicles whose CPU types enter the communication range of the task vehicle, that is, vehicles whose CPU types have not been selected, their = , and The energy consumed by tasks greater than the maximum data volume to be processed, so there is no need to impose power constraints during the exploration phase.

[0175] Exchange matching algorithm under power constraints: To solve the optimization problem (20), this embodiment proposes Algorithm 3 to obtain the optimal matching scheme.

[0176] K532: Execute the process of exchange matching

[0177] ① Given a matching scheme ;

[0178] ② Select two task matching pairs among them and , after exchanging the matching objects of these two tasks, obtain an exchanged matching scheme ;

[0179] ③ Exchange matching occurs

[0180] a. Exchange matching without power constraints:

[0181] Initialization: Generate a random matching scheme and calculate the corresponding execution cost according to the matching scheme .

[0182] Compare the execution cost after exchange matching with the execution cost before exchange. When and only when < , the task vehicle will update the matching scheme to the exchanged matching scheme, and this inequality is named exchange condition 1.

[0183] b. Exchange matching under power constraints:

[0184] Initialization: Generate a random matching scheme and calculate the corresponding execution cost according to the matching scheme .

[0185] Compare the execution cost after exchange matching with the execution cost before exchange. When and only when < and , the task vehicle will update the matching scheme to the exchanged matching scheme, and this inequality is named exchange condition 2.

[0186] ④ Exchange stability

[0187] In each iteration, the existing matching is updated if and only if there is a swapped matching solution that satisfies swapping condition 1 or 2. When the number of swaps reaches the preset swap count threshold, it is considered that a stable matching state has been reached. Of course, redundant or other judgment methods can also be set. For example, when there is no new swapped matching solution that satisfies the swapping condition, it is considered that a stable matching state has been reached between the tasks and the SuVs.

[0188] According to an embodiment of the present invention, the possible implementation manners are further described below through the pseudocodes of three algorithms:

[0189] Algorithm 1 EEOM algorithm

[0190] Input: CPU frequency of the task vehicle , two-dimensional array , number S of CPU types, set of vehicle labels within the communication range of the task vehicle , set of task labels , SuV Energy value collected in time slot t , maximum capacity of the battery for storing the collected energy .

[0191] Output: offloading decision (corresponding to the final offloading strategy).

[0192] Steps:

[0193] 1. Initialization:

[0194] 2. for do

[0195] 3. Set , and .

[0196] 4. end for

[0197] 5. Set .

[0198] 6. Weigh exploration and exploitation:

[0199] 7. for do

[0200] 8. Update according to .

[0201] 9. if do

[0202] 10. Enter the exploration phase:

[0203] 11. Define the set of vehicles for which the CPU type has not been selected as .

[0204] 12. Obtain the optimal matching scheme between and by Algorithm 2 .

[0205] 13. Obtain the execution delay of each matching pair , and calculate according to formula (6) , .

[0206] 14. Update and for the SuVs in respectively according to equations (18) and (19).

[0207] 15. else

[0208] 16. Enter the exploitation phase:

[0209] 17. Obtain the optimal matching scheme between and by Algorithm 3 .

[0210] 18. Obtain the execution delay of each matching pair , and calculate according to formula (6) , .

[0211] 19. Update and for the SuVs in respectively according to equations (25) and (19).

[0212] 20. end if

[0213] 21. Update according to , .

[0214] 22. end for

[0215] In Algorithm 1, the meanings corresponding to the respective line numbers are:

[0216] Line number 1: Initialization;

[0217] Line number 2: Preset S CPU types;

[0218] Line number 3: Set in the initial situation , .

[0219] Line number 5: Assume that the battery levels of all surrounding vehicles are at the maximum value initially, and the surrounding vehicles belong to the set .

[0220] Line number 6: Weigh exploration and exploitation;

[0221] Line number 7: Divide into T time slots;

[0222] Line number 8: Update according to the CPU type corresponding to the surrounding vehicles ;

[0223] Line number 9: If there is a CPU type for which the frequency has not been estimated, go to line number 10; otherwise, go to line number 15;

[0224] Line numbers 10 - 14: Enter the exploration stage. Define the set of vehicles with CPU types not yet selected as , and perform matching according to the matching rules in Algorithm 2;

[0225] Line numbers 15 - 22: Perform matching according to the matching rules in Algorithm 3.

[0226] Algorithm 2 Swap Matching Algorithm without Battery Constraints

[0227] Input: Set of labels of SuVs with CPU types not selected in time slot t , set of task labels , set of labels of vehicles within the communication range of the task vehicle , distance between the task vehicle and vehicle , data volume of the uploaded task , maximum number of iterations (corresponding to the swap count threshold).

[0228] Output: Offloading decision .

[0229] Steps:

[0230] 1. if then

[0231] 2. Select the N nearest SuVs from the vehicle set t ;

[0232] 3. Form a random matching scheme among the selected SuVs and the task set ; ;​

[0233] 4. Exchange matching:

[0234] 5. Let = 1.

[0235] 6. while do

[0236] 7. Calculate the execution cost according to formula (17) ;

[0237] 8. Randomly exchange two tasks from the task set , and calculate the execution cost ; ;

[0238] 9. if < do

[0239] 10. Let ;

[0240] 11. end if

[0241] 12. .

[0242] 13. end while

[0243] 14. Obtain the optimal matching scheme .

[0244] 15. else

[0245] 16. Select the tasks with the largest task volume from the task set , and form a set ; ;

[0246] 17. Form a random matching scheme in the task set and the vehicle set ; ;

[0247] 18. Return to steps 4 - 13, and obtain the optimal matching scheme in the task set and the vehicle set ; ;

[0248] 19. According to Algorithm 3, by changing the vehicle set and the task set input to Algorithm 2 to and , in and Obtain the optimal matching scheme ;

[0249] 20. In the task set and Obtain the optimal matching scheme ;

[0250] 21. end if

[0251] In Algorithm 2, the meanings corresponding to the respective line numbers are as follows:

[0252] Line number 1: If holds, then go to line number 2; otherwise, go to 16;

[0253] Line number 2: Select the Nt closest SUVs from the vehicle set ;

[0254] Line number 3: Form a random matching scheme between the selected SUVs and the task set (corresponding to the initial offloading strategy);

[0255] Line number 4: Exchange the matching (corresponding to randomly exchanging the vehicles performing the corresponding tasks in multiple random offloading strategies).

[0256] Line number 5: Let = 1, that is, the initial number of exchange times is 1;

[0257] Line number 6: When the number of exchange times is less than or equal to the exchange times threshold, go to 7 - 13; otherwise, go to 14;

[0258] Line number 7 - 14: Corresponding to adjusting the strategy based on the initialized offloading strategy to obtain a more optimal offloading strategy for the execution cost;

[0259] Lines 2 - 14 correspond to the offloading strategy that performs matching according to matching rule 1;

[0260] Lines 15 - 21 correspond to the offloading strategy that performs matching according to matching rule 2.

[0261] Algorithm 3 Exchange Matching Algorithm under Power Constraint

[0262] Input: Set of task labels , Set of vehicle labels within the communication range of the task vehicle , Power available for processing offloading tasks in time slot t + 1 , Number of occurrences of the CPU of type up to time slot ; , Number of occurrences of the CPU of type up to time slot The number of times a type of CPU appears and is selected , the maximum number of iterations maxIterations.

[0263] Output: Uninstallation decision .

[0264] Steps:

[0265] 1. Select the SuVs that meet the power condition , and define the set of these vehicle labels as .

[0266] 2. if then

[0267] 3. Form a random matching scheme in and . .

[0268] 4. Exchange the matching:

[0269] 5. Let = 1.

[0270] 6. while do

[0271] 7. Calculate the execution cost according to formula (21) .

[0272] 8. Randomly exchange two tasks from the task set , and calculate the execution cost . .

[0273] 9. if After the exchange of matching meets < , do

[0274] 10. Let .

[0275] 11. end if

[0276] 12. .

[0277] 13. end while

[0278] 14. Obtain the optimal matching scheme in the task set and the vehicle set . .

[0279] 15. else

[0280] 16. Select the task with the largest amount of tasks from the task set .

[0281] 17. Form a random matching scheme in the selected tasks and the vehicle set .

[0282] 18. Return to steps 4 - 13, and obtain the optimal matching scheme in the selected tasks and the vehicle set .

[0283] 19. Match the remaining tasks with the task vehicles to form a matching scheme .

[0284] 20. Obtain the optimal matching scheme in the task set and .

[0285] 21. end if

[0286] Algorithm 3 corresponds to the offloading strategy that performs matching according to matching rule 3.

[0287] To verify the effectiveness of the present invention, the inventors conducted experiments and performed MATLAB programming simulations using the method provided by the present invention (assuming that the method provided by the present invention cannot directly obtain the CPU frequencies of all surrounding vehicles SuVs) and the method of the prior art respectively. The simulation parameters are set as follows:

[0288] In the simulation, it is considered that a task vehicle and multiple surrounding vehicles SuVs are driving on a two - way road. The communication range of the task vehicle is 0.2 kilometers. There are a total of 8 types of CPU for the SuVs, and the expected values of setting these 8 CPU frequencies are , and the time delay and energy consumption weights are set as respectively, and the maximum number of exchange matches is 10. Other parameters are set as shown in Table 1:

[0289] Table 1 Simulation parameter settings

[0290]

[0291] Verify the EEOM scheme: Three comparison schemes are introduced to verify the performance of the EEOM scheme proposed by the present invention:

[0292] 1) Random Scheme: A random task offloading and matching scheme. In each time slot, the task vehicle is in the set Randomly select vehicles to perform task offloading;

[0293] 2) Global Optimal Scheme (Oracle Scheme): The task vehicle knows the CPU frequencies of each SUV. Therefore, the task vehicle can obtain the optimal offloading and matching scheme in each time slot, achieving the lowest cumulative execution cost.

[0294] 3) Explore-then-commit scheme (ETC): A scheme based on point estimation. In the previous time slots, the task vehicle randomly selects SUVs to perform task offloading, explores the true values of the CPU frequencies of the selected SUVs. When the number of each CPU type explored reaches a threshold (Z = n), the task vehicle will use the estimated values of the CPU frequencies of the SUVs obtained by point estimation during the exploration phase, always select the optimal SUVs for task offloading, and no longer update the estimated values.

[0295] The trend of the cumulative execution cost under different schemes changing with time slots is as Figure 4 shown. Among them, Figure 4 compares the cumulative execution costs of multiple schemes in different time slots. First, it can be observed that the Oracle scheme can achieve the lowest cumulative execution cost in each time slot, and the Random scheme has the highest cumulative execution cost. Secondly, as the time slot label increases, the scheme proposed by the present invention is superior to the ETC scheme and is close to the Oracle scheme.

[0296] It should be noted that although the above steps are described in a specific order, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently or even the order can be changed as long as the required functions can be achieved.

[0297] The present invention can be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium having thereon computer-readable program instructions for causing a processor to implement various aspects of the present invention.

[0298] A computer-readable storage medium can be a tangible device that retains and stores instructions for use by an instruction execution device. A computer-readable storage medium may include, for example, but is not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card or raised structures in grooves having instructions stored thereon, and any suitable combination of the foregoing.

[0299] The embodiments of the present invention have been described above. The above description is exemplary and not exhaustive, and is also not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art in the technical field without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, the practical application, or the improvement of the technology in the market, or to enable other ordinary skill in the art in the technical field to understand the embodiments disclosed herein.

Claims

1. A method for in-vehicle task offloading, characterized in that, it includes: Obtain the task information of multiple tasks to be processed by the task vehicle in the corresponding time slot and the information of surrounding vehicles of the task vehicle, where the information of surrounding vehicles includes CPU frequency; According to the task information and the information of surrounding vehicles, initialize the offloading strategy corresponding to the corresponding time slot. Among them, the offloading strategy indicates whether the corresponding task is executed by the task vehicle or offloaded to the corresponding surrounding vehicle for execution. The process of initializing the offloading strategy corresponding to the corresponding time slot includes: constructing a first set of surrounding vehicles with known CPU frequencies according to the information of surrounding vehicles, which includes surrounding vehicles directly obtaining CPU frequencies and / or surrounding vehicles for which frequency estimation values have been calculated, constructing a second set of surrounding vehicles with unknown CPU frequencies according to the information of surrounding vehicles, which includes surrounding vehicles whose CPU frequencies cannot be directly obtained and for which frequency estimation values have not been calculated, and selecting a matching rule for matching tasks from multiple preset matching rules according to the number of tasks to be processed, the number of vehicles in the first set of surrounding vehicles, and the number of vehicles in the second set of surrounding vehicles, and initializing the offloading strategy according to the selected matching rule; the multiple preset matching rules include: Matching rule 1: When the number of vehicles in the second set of surrounding vehicles is greater than or equal to the number of tasks, select the nearest multiple surrounding vehicles from the second set of surrounding vehicles to execute each task, and the number of selected surrounding vehicles is equal to the number of tasks; Matching rule 2: When the second set of surrounding vehicles is not empty and the number of vehicles in it is less than the number of tasks, select some tasks from the multiple tasks to be processed to be executed by the vehicles in the second set of surrounding vehicles, and the remaining tasks are executed by the task vehicle and / or the vehicles in the first set of surrounding vehicles; Matching rule 3: When the second set of surrounding vehicles is empty, the multiple tasks to be processed are executed by the task vehicle and / or the vehicles in the first set of surrounding vehicles; Based on the initialized offloading strategy, perform strategy adjustment to obtain an offloading strategy with better execution cost. Among them, when the CPU frequency corresponding to the surrounding vehicle cannot be directly obtained, the frequency estimation value of the corresponding CPU type is used to determine the execution cost; According to the final offloading strategy, execute the corresponding task among the multiple tasks by the task vehicle or offload it to the corresponding surrounding vehicle in the corresponding time slot; Each time, update the frequency estimation value of the CPU type corresponding to the surrounding vehicle according to the execution delay of the surrounding vehicle executing the corresponding task.

2. The method according to claim 1, characterized in that, the method further includes: Classify the CPUs of surrounding vehicles whose CPU frequencies cannot be directly obtained into the corresponding CPU types among a predetermined multiple CPU types; When estimating the frequency of the CPU of the corresponding CPU type, determine the frequency estimation value of the CPU of the corresponding CPU type according to the average frequency estimated for the CPU of this CPU type.

3. The method according to claim 1, characterized in that, the method further includes: For each CPU type, calculate the number of times the CPUs of surrounding vehicles have been classified into this CPU type in history and the number of times the frequency estimation values have been calculated for this CPU type respectively; When estimating the frequency of a CPU of a corresponding CPU type, the frequency estimate value of the CPU of the CPU type is determined according to the average frequency value estimated for the CPU of the CPU type and a correction parameter, and the correction parameter is determined according to the latest division times, estimation times corresponding to the CPU type, and the CPU frequency of the task vehicle.

4. The method according to claim 3, wherein, the correction parameter is determined in the following manner: ； Among them, represents the CPU type corresponding correction parameter, represents the CPU frequency corresponding to the task vehicle, represents the number of times the CPUs of surrounding vehicles in history have been classified into the CPU type of classification, represents the number of times of estimation for which the frequency estimation value has been calculated for the CPU type already calculated.

5. The method according to claim 1, wherein, when the CPU frequency of a corresponding surrounding vehicle cannot be directly obtained and the frequency estimate value has not been calculated for the CPU type of the surrounding vehicle, when calculating the latency cost related to the CPU frequency of the surrounding vehicle in the current execution cost, a predetermined CPU frequency is used or the execution cost related to the CPU frequency of the surrounding vehicle is ignored.

6. The method according to claim 1, wherein, the execution cost includes a latency cost and an energy consumption cost, the execution cost is a weighted sum of the energy consumption cost and the latency cost, wherein the latency cost includes a communication latency and an execution latency, and the energy consumption cost includes a communication energy consumption and an execution energy consumption.

7. The method according to claim 6, wherein, the method further includes: performing policy adjustment based on the execution cost and energy constraints so that the remaining energy of the surrounding vehicle after executing the corresponding task in the corresponding time slot is greater than or equal to the energy threshold while optimizing the execution cost.

8. The method according to claim 7, wherein, the method further includes: obtaining the energy harvesting value and energy consumption value corresponding to the surrounding vehicle in the corresponding time slot, and determining the remaining energy of the surrounding vehicle after executing the corresponding task in the corresponding time slot according to the energy harvesting value and energy consumption value, wherein the energy consumption value includes the energy value consumed for executing the corresponding task.

9. The method according to any one of claims 1-8, wherein, the step of performing policy adjustment based on the offloading policy obtained by initialization to obtain an offloading policy with a better execution cost includes: randomly swapping the vehicles executing the corresponding tasks in the offloading policy multiple times, and updating the current offloading policy to the offloading policy after the current swap when the execution cost corresponding to any offloading policy after the swap is smaller than that before the swap.

10. A computer-readable storage medium, wherein, a computer program is stored thereon, and the computer program can be executed by a processor to implement the steps of the method according to any one of claims 1 to 9.

11. An electronic device, wherein, comprising: one or more processors; and a memory, wherein the memory is used to store executable instructions; the one or more processors are configured to implement the steps of the method according to any one of claims 1 to 9 by executing the executable instructions.

Images