A method for dynamic offloading of in-vehicle tasks

Abstract

The present invention provides 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, the offloading strategy indicating whether the corresponding task is to be executed by the task vehicle or the corresponding surrounding vehicle; performing strategy adjustment based on the initialized offloading strategy to obtain an offloading strategy with a better execution cost, where, when the CPU frequency corresponding to the surrounding vehicle cannot be directly obtained, an estimated value of the frequency of the corresponding CPU type is used to determine the execution cost; executing the corresponding task among the plurality of tasks for the task vehicle or the corresponding surrounding vehicle in the corresponding time slot according to the final offloading strategy; updating the estimated value of the frequency of the corresponding CPU type according to the execution delay of the corresponding task executed by the surrounding vehicle, and limiting the upper limit of the number of updates of the estimated value of the frequency of each CPU type.

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 dynamically offloading vehicle tasks. Background Art

[0002] With the rapid development of the Internet of Vehicles, numerous new vehicle Internet applications that are computationally intensive have emerged, such as autonomous driving, high-definition video transmission, etc. These computationally intensive applications often require low-latency responses. If all these computationally intensive applications are executed by the vehicle itself, it will pose a great challenge to vehicles with limited computing power. Cloud computing can make up for the lack of vehicle computing power by uploading the computationally intensive tasks of the vehicle to a cloud server with rich computing resources. However, since the task vehicle (TaV) is usually far from the cloud server, cloud computing has a problem of high transmission latency. Therefore, offloading vehicle tasks to the cloud server cannot well meet the low-latency requirements. 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 the VEC network, the computing tasks generated by the task vehicle can be offloaded to the 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 number of studies, 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 task offloading when the 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 dynamically offloading vehicle tasks.

[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, an estimated value of the frequency 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; updating the estimated value of the frequency of the CPU type corresponding to the surrounding vehicle according to the execution delay of the surrounding vehicle in executing the corresponding task, and limiting the upper limit of the update times of the estimated value of the frequency of each CPU type.

[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 estimated value of the frequency of the CPU of the corresponding CPU type according to the average value of the frequencies estimated for the CPU of the corresponding CPU type.

[0008] In some embodiments of the present invention, when the CPU frequency corresponding to the corresponding surrounding vehicle cannot be directly obtained and the frequency estimated value for the CPU type of the surrounding vehicle has not been calculated yet, a predetermined CPU frequency is used to calculate the delay 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.

[0009] In some embodiments of the present invention, the execution cost includes a delay cost and an energy consumption cost, and the execution cost is a weighted sum of the energy consumption cost and the delay cost, where 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.

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

[0011] In some embodiments of the present invention, the method further includes: obtaining an energy harvesting value and an 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 in executing the corresponding task.

[0012] In some embodiments of the present invention, the step of adjusting the offloading policy based on the initialized offloading policy 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.

[0013] 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 directly obtaining the CPU frequency and / or surrounding vehicles 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; and selecting a matching rule for matching the tasks from a variety of preset matching rules according to the number of tasks of the multiple 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.

[0014] In some embodiments of the present invention, a variety of 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 therein 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.

[0015] 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 according to the first aspect by executing the executable instructions.

[0016] Compared with the prior art, the advantages of the present invention are:

[0017] The present invention takes 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 offloading tasks in a vehicle movement scenario. Additionally, some surrounding vehicles may not send some privacy information, such as CPU frequency, to the task vehicle. When the CPU frequency corresponding to a 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 offloading when the CPU frequency cannot be obtained. Estimating the CPU frequency of vehicles can help optimize the decision-making for task offloading. Moreover, the present invention also updates the frequency estimation value of the CPU type corresponding to neighboring vehicles according to the execution delay of the surrounding vehicles in executing corresponding tasks, and limits the upper limit of the update times of the frequency estimation value of each CPU type, so as to improve the accuracy of calculating the execution cost of subsequent vehicle-mounted task offloading as much as possible while saving computing resources, and better reduce the execution cost of task processing. Description of the Drawings

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

[0019] Figure 1 It is a schematic flowchart of a method for vehicle-mounted task offloading according to an embodiment of the present invention;

[0020] Figure 2 It is a schematic diagram of an implementation scenario according to an embodiment of the present invention;

[0021] Figure 3 It is a schematic diagram of energy calculation for the next time slot in a scenario with energy consumption and collection according to an embodiment of the present invention;

[0022] Figure 4 It is an experimental result curve corresponding to an experiment according to an embodiment of the present invention. Detailed Embodiments

[0023] In order to make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below through specific embodiments with reference to the 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.

[0024] As mentioned in the background art section, there are still some problems in task offloading in vehicle-mounted edge computing, such as the problem of difficult dynamic offloading of vehicle-mounted 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, in the present invention, a time slot is used as the minimum time allocation unit for tasks. Within one time slot, the relative states between vehicles are relatively fixed, which can increase the probability of successful task offloading in the vehicle movement 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 with the frequency estimation value 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, the present invention also updates the frequency estimation value of the corresponding CPU type of the neighbor vehicle according to the execution delay of the surrounding vehicle in executing the corresponding task, and limits the upper limit of the update times of the frequency estimation value of each CPU type, so as to save computing resources while improving the accuracy of the execution cost calculation of subsequent vehicle-mounted task offloading as much as possible, and better reduce the execution cost of task processing.

[0025] 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.

[0026] To better understand the present invention, the following will separately describe each step in detail in combination with specific embodiments.

[0027] 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;

[0028] 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 ( )represents 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 the time slot as a unit 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: the amount of computation (used to determine the processing delay), the amount of data (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, a surrounding vehicle is a vehicle that can establish wireless communication with the task vehicle and can provide task offloading services for the task vehicle. A surrounding vehicle may also be referred to as a service vehicle, a neighbor vehicle, a surrounding service vehicle, etc.

[0029] 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.

[0030] 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:

[0031] 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;

[0032] 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 (such as: select according to the task volume or randomly) 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;

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

[0034] 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 multiple preset matching rules. Thus, according to the number of tasks of the multiple 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, 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 the number of surrounding vehicles with unknown CPU frequencies is large and the number of tasks is small, and when the number of surrounding vehicles with unknown CPU frequencies is small and the number of tasks is large, 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.

[0035] 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 to 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 an offloading quantity threshold (for example, 1 or 2, etc.).

[0036] 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.

[0037] According to an embodiment of the present invention, step S3 includes: randomly swapping the vehicles performing corresponding tasks in the offloading strategy multiple times, and updating the current offloading strategy to the offloading strategy after this 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 performs task 1 and the surrounding vehicle B performs task 2; if in this random swap, the surrounding vehicle A performs task 2 and the surrounding vehicle B performs 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.). 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 types corresponding to the surrounding vehicles can be allocated according to the information communicated with the surrounding vehicles, such as according to the wireless signal name during communication with the surrounding vehicles, the device number in the wireless information, or alternatively, according to the specified test data packets sent during communication establishment, and determining the CPU type of the surrounding vehicle according to the response of the surrounding vehicle to the test data packets; 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.

[0038] In order 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.

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

[0040] ;

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

[0042] ;

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

[0044] According to an embodiment of the present invention, 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 sent back to the task vehicle can be ignored. Therefore, the latency of task offloading can be expressed as:

[0045] ;

[0046] 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:

[0047] ;

[0048] 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 a Rayleigh distribution), and N0 represents the noise power. represents the large-scale fading gain following the 3GPP path loss model, which can be expressed as:

[0049]

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

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

[0052] ;

[0053] 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. 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: preset the conversion formula between the CPU frequency and the computing power, and estimate the computing power corresponding to the surrounding vehicles of the CPU with the corresponding frequency estimation value.

[0054] 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 has not been calculated for the CPU type of the surrounding vehicle, 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, set a default CPU frequency, and 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, and 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).

[0055] 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 has not been calculated for the CPU type of the surrounding vehicle, 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.

[0056] 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 restrictions on this.

[0057] 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.

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

[0059] Step S4: assigning corresponding tasks among the multiple tasks to the task vehicle for execution or unloading them to corresponding surrounding vehicles for execution in corresponding time slots according to the final unloading strategy.

[0060] According to one embodiment of the present invention, the final unloading strategy may indicate whether each task is executed by the task vehicle or unloaded to the corresponding surrounding vehicles for execution. For example, suppose a time slot has 3 tasks, namely task 1, task 2, and task 3; there are 3 surrounding vehicles of the task vehicle, namely surrounding vehicle 1, surrounding vehicle 2, and surrounding vehicle 3; the final unloading strategy, for example, indicates that task 1 is executed by surrounding vehicle 2, task 2 is executed by surrounding vehicle 1, and task 3 is executed by the task vehicle. Therefore, the time slot will unload task 1 to surrounding vehicle 2 and task 2 to surrounding vehicle 1 through wireless communication, and task 3 will be executed locally on the task vehicle.

[0061] Step S5: updating the frequency estimation values ​​of the CPU types corresponding to the surrounding vehicles according to the execution delays of the corresponding tasks of the surrounding vehicles, and limiting the upper limit of the number of updates of the frequency estimation values ​​of each CPU type.

[0062] According to one embodiment of the present invention, it is assumed that the upper limit of the number of updates predetermined for each CPU type is , the frequency of CPU type i is estimated the number of times , in satisfying When , the frequency estimation value of the CPU type corresponding to the surrounding vehicles is updated each time according to the execution delay of the corresponding task of the surrounding vehicles; if , then stop estimating the frequency of CPU type i and use the frequency estimation value of the last frequency estimation of CPU type i for determining the delay cost in the subsequent time slot. The technical solution of this embodiment can at least achieve the following beneficial technical effects: This embodiment updates the frequency of each CPU type a limited number of times. By setting an upper limit on the number of updates, the frequency estimation value corresponding to the frequency of each CPU type can reach a relatively stable state, improve the accuracy of the calculated delay cost, and reduce the waste of CPU computing resources caused by excessive frequency estimation, so that the CPU computing resources can be used more for other vehicle computing tasks, ensuring the execution efficiency of computing tasks.

[0063] According to an embodiment of the present invention, the frequency estimation value of the CPU type is obtained in the following manner: classifying the CPUs of 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, determining the frequency estimation value of the CPUs of the CPU type according to the average frequency estimated for the CPUs of the CPU type. Updating the previous frequency estimation value with the latest estimated frequency estimation value.

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

[0065] ;

[0066] 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 sum of the frequencies estimated for the CPUs of the surrounding vehicles belonging to the set that execute the corresponding tasks in time slot t. Thus, the frequency estimation value of the CPUs of the CPU type is determined based on the average frequency estimated for the CPUs of the CPU type.

[0067] According to an embodiment of the present invention, in the case of estimating the frequency of a certain CPU type multiple times, the average frequency is calculated in the following manner: .

[0068] 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 according to needs, and the present invention makes no restrictions on this.

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

[0070] Step K1: Constructing an on-vehicle edge computing system model framework, including a task generation and offloading model and a vehicle movement model, considering the task dynamic offloading when the task vehicles generate different tasks (number of tasks, task volume) in each time slot and the set of surrounding vehicles SuVs is different;

[0071] Step K2: Based on the system model constructed in Step K1, mathematically model the local execution and task offloading processes, and calculate the latency and power consumption generated by the vehicle tasks during local execution and edge execution respectively.

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

[0073] Step K4: Based on the different latency and energy consumption values obtained in Step K2, under the condition that the battery level of SuVs is greater than 0, an optimization problem is derived 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.

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

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

[0076] Step K1: Construct a system model:

[0077] This embodiment simulates a two-way highway model, as Figure 2 shown. Considering the vehicle-to-vehicle (V2V) task offloading problem in a vehicle-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 capabilities and can provide computing resources for task vehicles. Task vehicles can offload the 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.

[0078] K11: Define the processes of task generation and task offloading;

[0079] 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 ( )represents the label of a certain time slot. There are multiple available SuVs for task vehicles to perform task offloading in each time slot. The task vehicle is represented by label 0, and the set of vehicle labels within the communication range of the task vehicle is represented by . At the beginning of time slot t, the task vehicle generates multiple tasks, and is used to represent the set of task labels. The task vehicle 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.

[0080] K12: Establish a vehicle movement model;

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

[0082] (1)

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

[0084] (2)

[0085] (3)

[0086] where, represents the rate at which surrounding vehicles enter the communication range of the task vehicle, represents the rate at which surrounding vehicles leave the communication range of the task vehicle, represents the corresponding optional value, used to define the Poisson distribution, represents the corresponding optional value, used to define the Poisson distribution.

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

[0088] K21: Mathematically model the local execution process:

[0089] Define For the task vehicle to execute tasks locally The required computational load is the CPU frequency of the task vehicle, and the local execution delay is

[0090] (4)

[0091] Based on the execution delay, the execution energy consumption for local task execution is

[0092] (5)

[0093] Among them is the computing power of the task vehicle is an energy consumption conversion coefficient, and its value is related to the chip architecture

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

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

[0096] (6)

[0097] Among them is the data volume of the uploaded task is the vehicle that executes the task The CPU frequency of is the uplink transmission rate, which can be expressed as

[0098] (7)

[0099] Among them is the wireless channel bandwidth between the task vehicle and the vehicle is the transmission power of the task vehicle is the small-scale fading gain (assuming a Rayleigh distribution), N0 is the noise power is the large-scale fading gain following the 3GPP path loss model, which can be expressed as​

[0100] (8)

[0101] Among them, is the distance between the mission vehicle and the vehicle therebetween.

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

[0103] (9)

[0104] Among them, is the computing power of the vehicle thereof.

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

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

[0107] (10)

[0108] Among them, is the maximum capacity of the battery used to store the harvested energy, and the constraint is set here, and it is assumed that all missions satisfy . represents the energy value harvested by the SUV in time slot t, and the energy harvesting process is modeled as a Poisson process with parameter Poisson process.

[0109] Step K4: Formulate an optimization problem;

[0110] K41: Matching scheme between missions and vehicles:

[0111] This embodiment models the mission offloading problem in a multi-mission, multi-vehicle scenario as a many-to-many matching problem, and the rules of the matching scheme are as follows:

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

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

[0114] Rule 3: The mission vehicle itself can execute all the missions it generates.

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

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

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

[0118] According to Rule 3, there is .

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

[0120] K42: Determine the optimization goal:

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

[0122] (11)

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

[0124] (12)

[0125] The task vehicle selects the matching scheme , with the goal of minimizing 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:

[0126] (13)

[0127] The constraint here is to ensure that: according to the matching scheme After the uninstall task is completed, at time slot beginning, the battery power value of each SUV is greater than 0.

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

[0129] (14)

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

[0131] Step K5: Propose a dynamic offloading scheme for on-vehicle tasks based on the exploration and exploitation algorithm to solve the optimization problem;

[0132] To solve the sub-problem (14), the task vehicle must have prior knowledge of the CPU frequency of each SUV ( , ). However, since the CPU frequencies of the SUVs are private information, it is difficult to solve the optimization problem (14). Therefore, this embodiment proposes an explore-then-commit (ETC) scheme, which can estimate the CPU frequency of the SUV. Based on the estimated CPU frequency, the optimization problem (14) is solved, and then the optimal matching scheme is obtained.

[0133] 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.

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

[0135] (15)

[0136] In addition, this embodiment introduces a counter , 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 estimate value has been calculated for CPU type ).

[0137] Based on , ,this embodiment proposes an ETC 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 ETC algorithm is shown in Algorithm 1.

[0138] K51: Exploration stage:

[0139] In the exploration stage, the task vehicle preferentially offloads tasks to the 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 entering 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 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):

[0140] (16)

[0141] where , is expressed as:

[0142] (17)

[0143] 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 delay of executing the task ( ), and obtain according to formula (6). Considering that the CPU type of SUV belongs to CPU type , that is follows distribution , the present invention estimates by the obtained The expected value is based on:

[0144] (18)

[0145] where represents the set of the subset of SuVs whose CPUs belong to type (corresponding to the set of surrounding vehicles whose CPU types belong to CPU type i in the corresponding time slot). Additionally, based on , the mission vehicle can calculate using the following formula:

[0146] (19)

[0147] where , is obtained through formula (9). Finally, according to the optimal matching scheme , update .

[0148] K52: Utilization phase:

[0149] In the utilization phase, the CPU types of all 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 what is obtained in the exploration phase . Therefore, the optimization problem in the utilization phase is:

[0150] (20)

[0151] where is expressed as

[0152] (21)

[0153] where 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.

[0154] (22)

[0155] where , can be expressed as

[0156] (23)

[0157] 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 point estimation . In particular, if the CPU of the SuV belongs to the CPU type , then its estimated value is expressed as:

[0158] (24)

[0159] wherein, is the frequency estimated value of the CPU type .

[0160] By solving the optimization problem (20), an 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). According to the optimal matching scheme , update , which is expressed as:

[0161] (25)

[0162] wherein, in the numerator is the historical estimated value. Finally, update the counter .

[0163] K53: Exchange matching algorithm

[0164] Purpose of introducing the exchange 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 exchange matching algorithms to optimize the matching relationship between tasks and SuVs to obtain an optimal matching scheme

[0165] K531: Construct two exchange matching algorithms

[0166] In this embodiment, the exchange matching algorithm is divided into an exchange matching algorithm without power constraint and an exchange matching algorithm under power constraint

[0167] Exchange matching algorithm without power constraint: To solve the optimization problem (16), this embodiment proposes Algorithm 2 to obtain an 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 within the communication range of the task vehicle, that is, vehicles of CPU types that have not been selected, their = , and is greater than the energy consumed by tasks that process the maximum amount of data. Therefore, there is no need to impose power constraints during the exploration phase.

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

[0169] K532: Execute the process of exchange matching

[0170] ① Given a matching scheme ;

[0171] ② Select two task matching pairs and . After exchanging the matching objects of these two tasks, obtain an exchanged matching scheme ;

[0172] ③ Exchange matching occurs

[0173] a. Exchange matching without power constraints:

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

[0175] 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. This inequality is named Exchange Condition 1.

[0176] b. Exchange matching under power constraints:

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

[0178] 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. This inequality is named Exchange Condition 2.

[0179] ④ Exchange stability

[0180] 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 is reached. Of course, redundant or other judgment methods can also be set. For example, when there is no new swapped matching solution that meets the swapping conditions, it is considered that a stable matching state is reached between the tasks and the SuVs.

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

[0182] Algorithm 1: ETC algorithm

[0183] 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 , predetermined upper limit of the update times is .

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

[0185] Steps:

[0186] 1. Initialization:

[0187] 2. for do

[0188] 3. Set , and

[0189] 4. end for

[0190] 5. Set for all SuVs .

[0191] 6. Weigh exploration and exploitation:

[0192] 7. for do

[0193] 8. if do

[0194] 9. Enter the exploration phase:

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

[0196] 11. Obtain the optimal matching scheme between and by Algorithm 2 .

[0197] 12. Obtain the execution delay of each matching pair , and calculate according to Equation (6) , .

[0198] 13. Update and for the SuVs in according to Equations (18) and (19) respectively

[0199] 14. Update according to , .

[0200] 15. else

[0201] 16. Enter the utilization phase:

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

[0203] 18. for do

[0204] 19. if the number of times a certain CPU type is selected among the SuVs with task offloading satisfies then

[0205] 20. The algorithm continuously estimates the frequency of the corresponding type of CPU:

[0206] 21. Obtain the execution delay of the corresponding matching pair , and calculate according to Equation (6) , .

[0207] 22. Update and for the SuVs in according to Equations (25) and (19) respectively

[0208] 23. Update according to ,

[0209] 24. else

[0210] 25. The algorithm stops estimating the CPU frequency of the corresponding type:

[0211] 26. Update according to Equation (19) .

[0212] 27. end if

[0213] 29. end for

[0214] 30. end if

[0215] 31. end for

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

[0217] Line number 1: Initialization;

[0218] Line number 2: Preset S types of CPUs;

[0219] Line number 3: Set in the initial case 、 .

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

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

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

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

[0224] Lines number 10 - 15: Enter the exploration phase. Define the set of vehicles for which the CPU type has not been selected as , and perform matching according to the matching rules in Algorithm 2;

[0225] Lines number 17 - 31: 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 for which the CPU type has not been selected at 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 ​ ,The amount of data uploaded , maximum number of iterations (corresponding to the exchange number threshold).

[0228] Output: Uninstall Decision .

[0229] step:

[0230] 1. if then

[0231] 2. From vehicle collection Select the N closest to t SuVs;

[0232] 3. On selected SuVs and mission sets A random matching scheme is formed in ;

[0233] 4. Exchange matching:

[0234] 5. Set = 1.

[0235] 6.while do

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

[0237] 8. From the task collection Randomly swap two tasks , calculate the execution cost ;

[0238] 9.if < do

[0239] 10. Order ;

[0240] 11.end if

[0241] 12. .

[0242] 13.end while

[0243] 14. Get the best matching solution .

[0244] 15. else

[0245] 16. From the task collection Select the one with the largest amount of tasks tasks, forming a collection ;

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

[0247] 18. Return to steps 4 - 13 to 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 , obtain the optimal matching scheme in and ; ;

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

[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, 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 numbers 7 - 14: Corresponding to adjusting the strategy based on the initialized offloading strategy to obtain a more optimal offloading strategy in terms of execution cost;

[0259] The line numbers 2 - 14 correspond to the offloading strategies matched according to matching rule 1;

[0260] Line numbers 15 - 21: correspond to the offloading strategies matched according to matching rule 2.

[0261] Algorithm 3: Exchange Matching Algorithm under Power Constraint

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

[0263] Output: offloading 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 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 match is satisfied < , 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 task volume from the task set . tasks.

[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 inventor conducted experiments and performed MATLAB programming simulations using the method provided by the present invention (in this experiment, it is assumed 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, a task vehicle and multiple surrounding vehicles (SUVs) are considered to be 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 the 8 CPU frequencies are set to , and the weights of latency and energy consumption are set to respectively. The maximum number of swap and match operations is 10, and other parameter settings are shown in Table 1:

[0289] Table 1 Simulation Parameter Settings

[0290]

[0291] Verify the ETC (Z=n) scheme: Two comparison schemes are introduced to verify the performance of the ETC scheme proposed in this patent:

[0292] 1) Random Scheme: A random task offloading and matching scheme. In each time slot, the task vehicle randomly selects a vehicle from the set to perform task offloading;

[0293] 2) 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] The trend of the cumulative execution cost under different schemes changing with the time slot is as shown in Figure 4 . Among them, Figure 4 compares the trend of the cumulative execution cost under different schemes changing with the time slot. It can be observed from Figure 4 that the global optimal offloading scheme can achieve the lowest cumulative execution cost in each time slot, and the ETC algorithm proposed in this invention is superior to the random offloading scheme.

[0295] 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 in a different order, as long as the required functions can be achieved.

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

[0297] 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.

[0298] 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 technical field to understand the embodiments disclosed herein.

Claims

1. A method for vehicle-mounted task offloading, characterized in that, Including: 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 that directly obtain 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; according to the number of tasks of the multiple 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, select a matching rule for matching the tasks from multiple preset matching rules, and initialize 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 a more optimal execution cost, which includes: randomly swap the vehicles executing the corresponding tasks in the offloading strategy multiple times, and update the current offloading strategy to the offloading strategy after this swap when the execution cost corresponding to any offloading strategy after the swap is smaller than that before the swap. Among them, when the CPU frequency corresponding to the surrounding vehicle cannot be directly obtained, the execution cost is determined by the frequency estimation value of the corresponding CPU type; 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; 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, and limit the upper limit of the update times of the frequency estimation value of each CPU type.

2. The method according to claim 1, wherein The method further includes: Classify the CPUs of the 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, When the CPU frequency corresponding to a corresponding neighboring vehicle cannot be directly obtained and the CPU frequency estimate value for the CPU type of the neighboring vehicle has not been calculated yet, a predetermined CPU frequency is used or the execution cost related to the CPU frequency of the neighboring vehicle is ignored when calculating the latency cost related to the CPU frequency of the neighboring vehicle in the current execution cost.

4. The method according to claim 1, wherein The execution cost includes a latency cost and an energy consumption cost, and the execution cost is a weighted sum of the energy consumption cost and the latency cost. Among them, 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.

5. The method according to claim 4, characterized in that, The method further includes: adjusting the policy based on the execution cost and the energy constraint to make the remaining energy of the neighboring vehicle after executing the corresponding task in the corresponding time slot greater than or equal to the energy threshold while optimizing the execution cost.

6. The method according to claim 5, wherein The method further includes: Obtaining the energy harvesting value and the energy consumption value corresponding to the neighboring vehicle in the corresponding time slot, and determining the remaining energy of the neighboring vehicle after executing the corresponding task in the corresponding time slot according to the energy harvesting value and the energy consumption value. Among them, the energy consumption value includes the energy value consumed for executing the corresponding task.

7. A computer-readable storage medium, characterized in that, 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 6.

8. An electronic device, characterized in that, 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 according to any one of claims 1 to 6 by executing the executable instructions.

Images