A method for implementing resource pre-emptive offloading in a cloud edge system

Abstract

The application provides a resource preemption type unloading method implemented in a cloud edge system, which comprises the following steps: a cloud server acquires task information respectively sent by a plurality of user devices; the priority of a current subtask and each historical subtask is determined; a waiting queue information is maintained for each service facility to record the start and end execution time of each historical subtask waiting to be processed by the service facility; the start and end execution time is obtained by a preset timing model in the case of analyzing transmission delay, processing delay and additional delay caused by a preset resource preemption mode; the rule of the resource preemption mode is that a subtask with a higher priority can preoccupy the resource of a subtask with a lower priority in the case of overlapping execution time range; based on the data dependency relationship between the subtasks contained in the current task and the set of service facilities, a search space is determined; and a Monte Carlo tree search method is used to obtain an unloading strategy that makes the evaluation delay satisfaction degree of the current tasks optimal.

Description

Technical Field

[0001] This invention relates to the field of mobile communications, more specifically to the field of mobile edge computing, and more specifically to a method for implementing resource preemption offloading in a cloud-edge system. Background Technology

[0002] With more and more network infrastructure, such as base stations (BS), supporting the embedding of computing resources (such as CPU and RAM), mobile edge computing (MEC) has emerged. MEC is an extension of cloud computing, deploying computing resources close to the user's radio access network (RAN). Because tasks can be processed by nearby edge devices instead of cloud servers within the core network, transmission latency is significantly reduced. However, compared to cloud servers, the service range of edge devices deployed within the RAN is relatively limited. Considering service costs, service providers are unwilling to provide abundant computing resources for limited service ranges. Therefore, for computationally intensive tasks such as facial recognition, video processing, and virtual reality, MEC still lacks sufficient computing resources.

[0003] To meet the service demands of computationally intensive tasks, some studies have proposed the concept of Collaborative MEC (Multi-Edge MEC). This approach enables multiple edge devices to collaboratively process computationally intensive tasks by sharing information and computing resources. For example, a task can be divided into several subtasks and offloaded to different edge devices. Each edge device only needs to process a portion of the task in parallel. Parallel computing reduces the computational burden on edge devices while significantly reducing latency.

[0004] Furthermore, during task partitioning, a task cannot be arbitrarily divided; it typically consists of multiple interdependent subtasks, meaning the input of one subtask is the output of several other subtasks. A subtask only begins execution when it receives the outputs of other subtasks, leading to additional latency. Some existing technologies do not consider the dependencies between subtasks, resulting in a significant discrepancy between the actual and expected effects of offloading strategies. Therefore, some studies map task dependencies to a more general Directed Acyclic Graph (DAG), where each subtask can have multiple predecessor and successor subtasks to constrain the dependencies between them. However, these studies assume that the edge device's server can handle an unlimited number of subtasks and ignore resource contention between tasks, leading to a significant difference between the actual and expected effects of the offloading strategies.

[0005] In multi-user scenarios, task partitioning results in each edge device serving multiple subtasks from different users. Resource contention between users is inevitable. However, different users have different application types and different latency requirements. For example, augmented reality services typically require latency of less than 100 milliseconds, while 4K live video can tolerate latency as high as 500 milliseconds. Some studies have considered resource contention between tasks, but simplified it to a queuing problem under the First Come First Served (FCFS) method. For example, assume that an edge device processes only one subtask in a time slot. Under the constraint of task dependencies, a heuristic algorithm based on the FCFS method is designed to minimize task completion latency. Alternatively, consider that the queue capacity of each edge device is limited. When the queue of an edge device is full, newly arriving subtasks will be offloaded to other edge devices. However, the FCFS method ignores the differences in latency sensitivity between tasks, leading to a decrease in Quality of Service (QoS). This is because prioritizing the execution of low-latency-sensitive tasks may not improve the average QoS, while increasing the waiting time of high-latency-sensitive tasks may significantly reduce the average QoS. The existing technology considers resource contention, but it adopts a first-come, first-served queuing model, ignoring the latency sensitivity of tasks. Furthermore, its optimization objective is to minimize task completion latency, which will severely impact service quality. Therefore, improvements to the existing technology are needed. Summary of the Invention

[0006] Therefore, the purpose of this invention is to overcome the shortcomings of the prior art and provide a method for resource preemption and offloading in a cloud-edge system.

[0007] The objective of this invention is achieved through the following technical solution:

[0008] According to a first aspect of the present invention, a method for implementing resource preemptive offloading in a cloud-edge system is provided. The cloud-edge system includes a cloud server supporting the processing of user equipment offloading subtasks and multiple edge devices. In addition to user equipment serving as a service facility for its subtasks, the cloud server and edge devices also serve as service facilities for corresponding subtasks of the user equipment. The method includes the cloud server performing the following operations: acquiring task information issued by multiple user equipment, the task information including the estimated arrival time slot of the user's current task, data dependencies between subtasks, computational load of each subtask, data transmission volume between subtasks, and expected completion time of the task; determining the priority of the current subtask and each historical subtask using the expected times corresponding to the current tasks and the expected times corresponding to previous historical tasks; and maintaining a waiting queue for each service facility, each waiting queue including historical subtasks waiting to be processed by that service facility. The start and end execution times are determined by a preset timing model based on analysis of transmission latency, processing latency, and additional latency caused by a preset resource preemption mode. The resource preemption mode's rule is that, in cases of overlapping execution times, higher-priority subtasks can preempt resources from lower-priority subtasks for priority execution. A search space is determined based on the data dependencies between subtasks and the set of service facilities within each current task. Using a Monte Carlo tree search method, multiple iterative searches are performed in the search space based on a confidence upper bound function to obtain the offloading strategy that optimizes the overall latency satisfaction of each current task. After each iteration, based on the waiting queue information and the timing model under the resource preemption mode, the start and end execution times of each current subtask on the corresponding service facility under the corresponding offloading strategy are estimated to calculate the user's average latency satisfaction as a reward value.

[0009] In some embodiments of the present invention, the timing model is configured to: after the final unloading decision for each current task is determined, add the start and end execution times of each current subtask under the final unloading strategy to the waiting queue information corresponding to each service facility, and use the timing model to update the start and end execution times of historical subtasks affected by resource preemption mode in each waiting queue information.

[0010] In some embodiments of the present invention, the timing model is configured such that, under any offloading strategy, the sum of the start execution time of the current subtask in a service facility and the processing delay of the subtask in that service facility is used as the end execution time of the current subtask.

[0011] In some embodiments of the present invention, updating the start and end times of historical subtasks affected by resource preemption modes includes: for historical subtasks with lower priority but whose end times are greater than or equal to the start times of the current subtask, determining the maximum value among the end times of other subtasks with higher priority than or equal to the historical subtask in the waiting queue information and the start times of the historical subtask determined in the previous time slot, to update the start time of the historical subtask in the current time slot; and updating the end time of the historical subtask based on the sum of the start time of the historical subtask in the current time slot and the processing latency of the historical subtask in the service facility.

[0012] In some embodiments of the present invention, updating the start and end times of historical subtasks affected by resource preemption modes further includes: after the start and end times of a historical subtask are updated, updating the start and end times of related subsequent historical subtasks using a time-series model based on the data dependencies corresponding to the historical subtasks.

[0013] In some embodiments of the present invention, the average latency satisfaction of the user is the average latency satisfaction of each user corresponding to the plurality of user devices, wherein the latency satisfaction of a single user is determined as follows: if the completion execution time of the user's task does not exceed the expected completion time of the task, then the latency satisfaction is 1; otherwise, the latency satisfaction is the ratio of the expected completion time of the task to the completion execution time of the task, wherein the completion time of the task is determined based on the completion execution time of the last subtask of the task.

[0014] In some embodiments of the present invention, the method further includes: instructing, according to a final offloading strategy, to assign each subtask of the tasks of the plurality of user devices to a designated service facility for processing.

[0015] According to a second aspect of the present invention, an electronic device is provided, comprising: one or more processors; and a memory for storing executable instructions; wherein the one or more processors are configured to implement the steps of the method described in the first aspect by executing the executable instructions. Attached Figure Description

[0016] The embodiments of the present invention will be further described below with reference to the accompanying drawings, wherein:

[0017] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of the present invention;

[0018] Figure 2 A flowchart illustrating the resource preemptive offloading method in a cloud-edge system according to an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram illustrating the use of Monte Carlo tree search to implement a resource preemptive offloading method in a cloud-edge system according to an embodiment of the present invention.

[0020] Figure 4 This is a schematic diagram illustrating the allocation of subtasks after determining the final unloading strategy in a cloud-edge system according to an embodiment of the present invention.

[0021] Figure 5 This is a schematic diagram showing the comparison of average user latency satisfaction between the method of this embodiment and the FCFS scheme according to an embodiment of the present invention.

[0022] Figure 6 This is a schematic diagram showing the comparison results between the method of the present invention, derived from comparative experiments, and the latency satisfaction based on different selection algorithms.

[0023] Figure 7 This diagram illustrates the comparison of latency satisfaction between the method of this embodiment of the invention, the optimal algorithm BF, and other algorithms under the FCFS scheme, based on comparative experiments. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the invention.

[0025] As mentioned in the background section, existing technologies, considering resource competition, primarily employ a first-come, first-served queuing model, ignoring the latency sensitivity differences of different tasks. This makes it difficult to adapt to the differentiated needs of businesses, severely impacting actual service quality. To address this, this invention proposes considering the impact of resource preemption, data dependencies, and user average latency satisfaction on the offloading strategy. A waiting queue is maintained for each service facility on the cloud server. A timing model is established to obtain the historical start and end times of subtasks, taking into account processing latency, transmission latency, and additional latency caused by the preset resource preemption model. Furthermore, to reduce local optima and the neglect of latency sensitivity differences between tasks due to the use of total processing latency, a Monte Carlo tree search method is used to search the search space based on a confidence upper bound function, with user average latency satisfaction as the reward value. This yields a final offloading strategy that improves user average latency satisfaction. Based on this final offloading strategy, service facilities for processing each subtask are selected, improving system service quality.

[0026] To facilitate understanding, the collaborative offloading scenario of a multi-user, multi-service facility formed by the cloud-edge system and user devices in this embodiment of the invention will be introduced first. The cloud-edge system includes a cloud server and multiple edge devices, and can provide services to user devices to handle their offloading sub-tasks.

[0027] illustrative, see Figure 1 The architecture consists of three layers: cloud servers, edge devices, and user devices, which collaborate to complete user device tasks. The top layer is the cloud server, configured with abundant computing resources. Furthermore, the cloud server can act as a global controller to formulate offloading policies. The second layer comprises multiple (assuming S) edge devices, each co-located with a MEC (Mobile Edge Computing Server), typically with lower computing resources than the cloud server. Edge devices communicate with each other via wireless backhaul links and can connect to the cloud server via a wired core network. The third layer consists of multiple user devices (assuming M user devices, or local devices), each with a processing unit and very limited computing resources. Assume each user has computationally intensive tasks to process, where tasks from user devices m ∈ {1, 2, ..., M} are generated by N... m The subtasks are simplified by using numbers m to identify tasks or user devices (e.g., user device m, task m). Data dependencies between subtasks are represented using a directed acyclic graph (DAG), denoted as […]. in, This represents the set of subtasks of user device m. For an adjacency matrix representing the data dependencies between subtasks, the binary element e m,i,j This represents the dependency relationship between subtasks i and j of user device m. Illustratively, if subtask v... m,j It is v m,i The successor subtask, e m,i,j =1, otherwise 0. The cloud server assigns a value of 1 to each subtask v. m,j Selecting a target service facility is represented as follows:

[0028]

[0029] Among them, s b ∈{0,1,...,S+1} represents a service facility. Specifically, s b =0 indicates user equipment, s b =S+1 represents the cloud server, s b When equal to the others 1,...,S, they represent the 1-S edge devices respectively. Since each subtask can only be offloaded to one service facility, that is:

[0030]

[0031] Note that the first subtask is generally processed locally by the user equipment, and the last subtask is processed back on the user equipment. According to an embodiment of the present invention, the method may include: configuring the first and last subtasks of all tasks to be processed by the user equipment to which the task belongs, as shown below:

[0032]

[0033] It should be understood that this is only a preferred implementation method. In principle, the first or last subtask may not specify a default processing facility.

[0034] According to one embodiment of the present invention, see Figure 2 This invention provides a method for implementing resource preemptive offloading in a cloud-edge system, the method comprising steps S1-S5 executed by a cloud server. To better understand this invention, each step is described in detail below with reference to specific embodiments.

[0035] Step S1: Obtain task information sent by multiple user devices. The task information includes the expected arrival time slot of the user's current task, the data dependencies between the subtasks of the task, the computational amount of each subtask, the amount of data transmitted between the subtasks, and the expected completion time of the task.

[0036] According to one embodiment of the present invention, each user sends task information to the cloud server in advance through the user device. For example, the task information is represented by a quintuple. It means that, where τ m This represents the estimated arrival time slot of the current task m. This represents the data dependency between subtasks, assuming that all subtasks of task m arrive in the same time slot; d represents the computational cost of each subtask in task m. m,j This represents the computational cost of the j-th subtask in task m. Indicates the amount of data transferred between subtasks, l m,i,j E represents the amount of data transferred between the i-th subtask and the j-th subtask in task m. m This represents the expected time for task m to be completed, that is, the expected time for task m to be processed.

[0037] Step S2: Determine the priority of the current subtask and each historical subtask by using the expected time corresponding to each current task and the expected time corresponding to each historical task.

[0038] It should be understood that the current subtask belongs to the task information obtained in step S1, while the historical subtasks are subtasks of previous tasks. That is, the historical subtasks are subtasks of historical tasks obtained in time slots before step S1. The historical tasks already have corresponding final unloading strategies, but some historical subtasks may not have been processed in the current time slot. The unloading strategy for the current task needs to be formulated based on the historical subtasks. Therefore, the implementation of this invention needs to determine the priority of the current subtask and each historical subtask. There are multiple ways to determine the priority of subtasks.

[0039] According to one embodiment of the present invention, the priority of the current subtask and each historical subtask can be directly represented by the expected time of the corresponding task, with a smaller expected time indicating a higher priority for the subtask. This embodiment achieves at least the following beneficial technical effects: by directly representing the subtask priority by the expected time, it avoids some historical subtasks with lower priority being repeatedly delayed in extreme cases, thus ensuring service quality.

[0040] According to another embodiment of the present invention, the priorities of the current subtask and each historical subtask are determined as follows: the earliest time among the expected time corresponding to the current task and the expected time corresponding to the previous historical task is used as the base time; multiple numerical ranges corresponding to priorities are preset, and the priority of the corresponding subtask is determined by the numerical range to which the value obtained by subtracting the base time from the expected time corresponding to the current task or the expected time corresponding to the previous historical task belongs. For example, [0, a) corresponds to priority 1, [a, b) corresponds to priority 2, [b, c) corresponds to priority 3, and [c, +∞) corresponds to priority 4, where the relative priority is: priority 1 > priority 2 > priority 3 > priority 4. Of course, the priority level 4 here is only illustrative, and the implementer can adjust it as needed or adopt other methods to determine the priority of the subtask; the present invention does not limit this.

[0041] Step S3: Maintain a waiting queue for each service facility. Each waiting queue includes the start and end times of each historical subtask waiting to be processed by that service facility. The start and end times are obtained by a preset timing model after analyzing transmission latency, processing latency, and additional latency caused by a preset resource preemption mode. The rule of the resource preemption mode is that when execution time ranges overlap, higher priority subtasks can preempt the resources of lower priority subtasks for priority execution.

[0042] It should be understood that the waiting queue information for each service facility is maintained by the cloud server, but the cloud server does not execute the individual waiting subtasks in the waiting queue. It is only maintained to support the start and end times of historical subtasks required in the resource preemption mode. These historical subtask start and end times are obtained by taking into account transmission latency, processing latency, and additional latency caused by the preset resource preemption mode.

[0043] The additional latency caused by preemption needs to be calculated in conjunction with the current task's unloading strategy; however, when step S3 is executed, the corresponding final unloading strategy has not yet been generated for the task information in step S1. Therefore, it should be understood that the execution time of step S3 needs to consider the additional latency caused by preemption, but not the additional latency caused by the task corresponding to the task information obtained in the current step S1 preempting the resources of historical tasks. For illustration, assume that the current time slot for executing step S3 is τ. m Assume the time slot of the final unloading strategy executed in the previous iteration is τ. m -1, then in time slot τ m Before -1, there might be subtasks from earlier historical tasks that haven't been processed; therefore, in time slot τ... m -1 When executing step S3, the sub-task of the final unloading strategy executed previously will preempt time slot τ. m Resources from subtasks prior to -1 are used, thus requiring the calculation of corresponding execution times based on the additional latency caused by the preset resource preemption mode. Additionally, overlapping execution time ranges refer to the overlap between the start and end execution times of two subtasks.

[0044] Since it is more intuitive to explain transmission delay, processing delay and additional delay in terms of the current task, but the additional delay caused by the current task is not involved in step S3, in order to avoid misunderstanding, how the preset timing model considers transmission delay, processing delay and additional delay caused by the preset resource preemption mode will not be explained in detail here. It will be explained in step S5 later.

[0045] Step S4: Determine the search space based on the data dependencies and service facilities among the subtasks contained in each current task.

[0046] According to one embodiment of the present invention, step S4 includes: adding a commonly connected predecessor virtual node before the data dependencies corresponding to all tasks, forming a dependency tree, wherein the computational cost and data transmission volume of the predecessor virtual node are 0; defining the search space using the dependency tree and the set of service facilities selectable by each node of the dependency tree; and creating a ready queue, adding the direct successor subtasks of the predecessor virtual node to the ready queue. Each node of the search tree corresponds to an action, used to represent the unloading decision of a subtask. The unloading decisions of all subtasks constitute the unloading strategy. Figure 3 For example, suppose there are three tasks. Task 1 includes four nodes, corresponding to subtasks v. 1,1 v 1,2 v 1,3 v 1,4 Task 2 includes five nodes, corresponding to subtasks v. 2,1 v 2,2 v 2,3 v 2,4 v 2,5 Task 3 includes three nodes, corresponding to subtasks v. 3,1 v 3,2 v 3,3 Step 4 corresponds to the initialization stage, and the added predecessor virtual node is the root node v. root During the initialization phase, v root All direct successor subtasks are added to Λ, due to the root node v root The direct successor subtasks include v 1,1 v 2,1 and v 3,1 Then the current Λ contains (v 1,1 ,v 2,1 ,v 3,1 ).

[0047] Step S5: Using the Monte Carlo tree search method, perform multiple iterative searches in the search space based on the confidence upper bound function to obtain the unloading strategy that optimizes the overall latency satisfaction of each task. After obtaining the unloading strategy in each iteration, estimate the start and end times of each subtask in the corresponding service facility under the resource preemption mode based on the waiting queue information and the timing model to calculate the user's average latency satisfaction as the reward value.

[0048] According to one embodiment of the present invention, the Monte Carlo Tree Search (MCTS) algorithm requires selection, expansion, simulation, and backpropagation to update the reward values ​​and visit counts of all nodes on the search path involved in the current iteration in each iteration. Each iteration yields an unloading strategy, and the optimal unloading strategy during the tree search process is recorded using Q. MAX and χ MAX These represent the current optimal average latency satisfaction and the corresponding offloading strategy, respectively. The following illustrative explanation covers the four steps of selection, expansion, simulation, and backpropagation.

[0049] (1) Selection

[0050] The selection step involves choosing the node in the search tree that you want to expand further.

[0051] According to one embodiment of the present invention, selection involves building a search tree based on a dependency tree, and then selecting nodes to be further expanded based on the search tree. To avoid local optima, a balance needs to be maintained between selecting utilized nodes (known optimal nodes) and selecting explored nodes (nodes that have not been selected or have been selected less frequently). To guide the MCTS algorithm in making selections, an Upper Confidence Bounds (UCB) function is introduced so that at each selection, the selection is made based on the UCB value of each candidate node evaluated by the UCB function. The UCB function is expressed as:

[0052]

[0053] Where i represents the current iteration round, υ represents the candidate node, and Q j (υ) represents the reward value obtained by selecting υ as a node in the search path in round j, and N(υ) represents the cumulative number of times the candidate node υ has been selected. p N(υ) represents the parent node of υ in the search tree. p The parent node of candidate node υ is cumulatively selected, and c is a constant parameter. c is used to balance the weight between selection utilization and selection exploration. Therefore, This represents the cumulative reward obtained at candidate node υ over the past i-1 rounds. The UCB function introduced in this embodiment of the invention avoids local optima by weighing the current optimal search path against previously unsearched paths. Through the UCB function, the proposed algorithm can utilize historically observed UCB values ​​and currently predicted UCB values ​​to converge the tree search space from a global perspective and obtain the optimal path.

[0054] Indicatively, based on the UCB function, the search starts from the root node and recursively selects the node with the largest UCB value until an scalable node υ is reached.s Note that an expandable node definition refers to a node that still has at least one leaf node that has not yet been added to the decision tree. Then, remove node υ from the waiting queue Λ. s The corresponding subtask, and its direct successor subtask added to the end of the Λ queue. See again. Figure 3 From the root node υ root Start the search, in Λ=(v 1,1 ,v 2,1 ,v 3,1 Select the subtask and the corresponding target service facility as υ. root The node. Assuming that according to the UCB function, the subtask v is selected... 1,1 Uninstall to s k In other words, υ root The action corresponding to the node is {v 1,1 ,s k}. Because v 1,1 Selected, v 1,1 Remove from queue Λ and v 1,1 subtask v 1,2 ,v 1,3 Add to the end of the Λ queue. At this point, Λ is updated to (v 2,1 ,v 3,1 ,v 1,2 ,v 1,3 Assume that the final action is {v}. 1,2 ,s p leaf node υ s Selected, Λ updated to (v 2,1 ,v 3,1 ,v 1,3 ,v 1,4 ).

[0055] (2) Expansion

[0056] After selecting a leaf node, if the current leaf node is not the terminal node, then create one or more child nodes for that leaf node and select one of them to expand.

[0057] For example, expand the previously selected leaf node υ s First, arbitrarily select one subtask and target service facility from Λ as the new child node υ. c The action. Then, the child node υ c Added to the search tree T as node υ s The leaf nodes. Initially, υ c Reward value and number of selections Q i (υ c ) and N(υ c All values ​​are set to 0. Simultaneously, node υ is deleted from Λ.c Add the corresponding subtask and its direct successor subtask to the end of the queue.

[0058] (3) Simulation

[0059] Starting from the expanded node, run a simulation process to select an optimal action for each of the remaining subtasks that have not yet been selected.

[0060] For example, consider simulating the unloading decision for remaining subtasks. First, select a service facility as the unloading decision for the first subtask v in queue Λ. This requires estimating the start and end times of v on each service facility using a pre-defined timing model, and then selecting the optimal service facility. For a single subtask, since satisfaction cannot be evaluated, the service facility with the earliest end time is chosen as the optimal service facility for that individual subtask during simulation. After each simulation, an unloading strategy is obtained, which involves estimating the start and end times of each subtask on the corresponding service facility under the resource preemption mode based on the waiting queue information and the timing model.

[0061] To illustrate this, the following section uses specific formulas to demonstrate the illustrative calculation process of execution time. For clarity, assume subtask v... m,i and its direct successor subtask v m,j Assigned to s respectively a and s b Processing. When v m,i The processed result data is transferred from s a Transmit to s b At this time, transmission delay will occur. Note that if v m,i and v m,j They are unloaded to the same service facility, namely s a =s b The transmission latency is 0. Considering that cloud servers use wired links while others use wireless links, the transmission latency between different service facilities needs to be discussed separately. In addition, the processing of subtasks by service facilities also involves processing latency. The current subtask may preempt the resources of the previous subtask, which also involves additional latency caused by preemption. The following is an illustrative explanation of transmission latency (3.1), processing latency (3.2), and additional latency (3.3). Then, the start execution time and end execution time (3.4) will be explained based on these three types of latency.

[0062] 3.1 Transmission delay

[0063] Transmission latency is divided into transmission latency between edge devices, transmission latency between user devices and edge devices, transmission latency between edge devices and cloud servers, and transmission latency between user devices and cloud servers, among which:

[0064] (a) Transmission latency between edge devices or between user equipment and edge devices, which is the latency of transmitting data based on the wireless link, is described below:

[0065] If s a and s b For edge devices or user devices, i.e., s a ,s b ∈{0,1,2,...,S},s a The data results will be transmitted to s via a wireless link. b The corresponding transmission delay is:

[0066]

[0067] Among them, l m,i,j This represents the amount of data transferred between the i-th subtask and the j-th subtask in task m. s b Available channel bandwidth, It is s a Transmission power, It is s a With s b The channel gain of the inter-link, where N represents the background noise variance.

[0068] (b) The transmission latency between edge devices and cloud servers is the latency for transmitting data over a limited link, as described below:

[0069] If service facilities a It is a cloud server and service facilities. b Are they edge devices, or conversely, service facilities? a =S+1,s b ∈{1,2,...,S+1} or s a ∈{1,2,...,S+1},s b =S+1, service facilities s a The data results will be transmitted to the service facility via a wired link. b The corresponding transmission delay is expressed as:

[0070]

[0071] Among them, l m,i,j This represents the amount of data transferred between the i-th subtask and the j-th subtask in task m. Indicates service facilities s a With s b The transmission rate of the wired backhaul link between them.

[0072] (c) Transmission latency between user equipment and cloud server

[0073] If service facilities a It is a user equipment and s b It is a cloud server, i.e., s a =0,s b =S+1,s a Data will be transmitted to nearby edge devices via a wireless link. The data is then transmitted to the cloud server via a wired link. The corresponding transmission latency is expressed as:

[0074]

[0075] Similarly, if service facilities s a It is a cloud server and service facilities. b It is user equipment, i.e., s a =S+1,s b =0, the corresponding transmission delay is expressed as:

[0076]

[0077] Based on formulas (4), (5), (6) and (7), the transmission delay is expressed as:

[0078]

[0079] 3.2 Processing delay

[0080] Let the frequency be calculated Indicates the corresponding service facilities s b The computing power, assuming that subtask j is handled by service facility s b During processing, the corresponding processing latency is expressed as follows:

[0081]

[0082] 3.3 Additional latency

[0083] According to the waiting queue information, if the priority of a current subtask (a lower priority subtask) is lower than the priority of some historical subtasks, the resources required by the current subtask are unlikely to be obtained on time and will be preempted by these historical subtasks, resulting in additional delays due to waiting for the required resources.

[0084] Alternatively, based on the waiting queue information, if the priority of a current subtask (a higher-priority subtask) is lower than the priority of some historical subtasks (lower-priority subtasks), the current subtask will preempt the resources of these historical subtasks. Similarly, the resources required by these historical subtasks may be difficult to use as scheduled and will be preempted by the current subtask, resulting in additional latency due to waiting for the required resources. This embodiment of the invention considers the impact of additional latency caused by resource preemption, which can more accurately estimate task completion time, thereby making the calculation of user latency satisfaction more accurate and better guaranteeing service quality.

[0085] 3.4 Start and end execution times

[0086] The cloud server pre-determines the selection of the target service facility based on task information (i.e., the quintuple) before the task arrives. Each offloading decision... All are composed of subtasks v m,j In s b The start and end times of execution are determined by this. Illustratively, the current subtask v... m,j In s b The conditions for the subtask to begin execution are: 1) Subtask v m,j 1) Service facility has been reached; 2) Current subtask v m,j All predecessor subtasks have completed execution and transmitted the data results to the service facility. b ;3) Service facilities b Is it idle, or is the current service facility s b In the waiting queue information, the priority of the corresponding historical subtasks is lower than that of the current subtask v. m,j This is because the current subtask v m,j Arrival Service Facilities b After, v m,j It can preempt lower-priority historical subtasks, meaning they can be processed before these historical subtasks. In other words, v m,j We only need to wait for the higher-priority subtasks in the queue to complete and be processed. The τth... m Time slot estimation v m,j In s b The start time of execution is:

[0087]

[0088] in, This indicates the current subtask v according to the uninstallation strategy. m,j In service facilities b The value at τ m Indicates the current subtask v m,j The expected arrival time slot, Subtask v m,j All data results from the preceding subtasks have been offloaded to the service facility. b At the moment, where pre(v m,j ) represents v m,j A collection of precursor subtasks, v m,i Indicates the current subtask v m,j The precursor sub-task. Represents τ m Precursor subtask v for time slot recording m,i In its service facilities a The end execution time on Indicates the service facilities from the precursor sub-mission sa The data results are transmitted to the service facility s of the current subtask. b Transmission delay, Indicates service facilities s b All subtasks with higher priority than the current subtask v in the waiting queue m,j The maximum execution time of the historical subtasks, p(u) represents the priority of the corresponding historical subtask, and p(m) represents the current subtask v. m,j priority, Subtasks representing history v u,l The corresponding uninstallation strategy includes historical subtasks v u,l In service facilities b The value at that location, Indicates the previous time slot τ m -1 A defined subtask of history v u,l The completion execution time is τ. To simplify the calculation, we can assume that all subtasks of the current task are expected to complete within τ. m Time slot arrived.

[0089] The timing model is configured such that, under any offloading strategy, the sum of the start execution time of the current subtask in a service facility and the processing latency of the subtask in that service facility is used as the end execution time of the current subtask. (Illustratively, the τth...) m Time slot recording v m,j In service facilities b The execution end time is expressed as:

[0090]

[0091] in, Indicates v m,j In service facilities b Processing delay.

[0092] Considering v m,jPreemption may delay the start time of other historical subtasks in the system. By analyzing the additional latency caused by preemption to other subtasks, the cloud server transfers the execution status of subtasks from the previous time slot to the next time slot to update the start and end execution times of these tasks. That is: for historical subtasks with lower priority but whose end execution time is greater than or equal to the start execution time of the current subtask, the maximum value among the end execution times of other subtasks with higher or lower priority than that historical subtask in the waiting queue information and the start execution time of that historical subtask determined in the previous time slot is used to update the start execution time of that historical subtask in the current time slot. Illustratively, if the k-th subtask v of task n, which has a lower priority than task m... n,k (Hereafter referred to as the subtasks of history v) n,k ) at the τ m Enter service before time slot b The waiting queue information and its completion time is later than the current subtask v m,j The start time of execution, then v n,k Will be affected by v m,j The impact of resource contention will delay the start of its implementation. Note that service facilities s b Not all historical subtasks with a priority lower than task m in the waiting queue need to have their execution times updated, because v m,j Arrival time τ m Or the time to wait for the precursor sub-task This may be later than the completion time of these historical subtasks. Therefore, considering v m,j Resource grabbing against v n,k The impact of start execution time, in τ m time slot s b Sub-task v n,k The update expression for the start time is:

[0093]

[0094] in, Indicates service facilities s b Historical subtasks v in the waiting queue information n,k The completion time of the previous subtask. Subtasks representing history v n,k The execution end time determined before the current time slot, Indicates the current subtask v m,j The start time of execution; This indicates that under conditions other than the first term of the formula, in time slot τ m -1 The subtask of calculating the history v n,k The start time of execution can be retained.

[0095] Additionally, the end time of the historical subtask is updated based on the sum of the start time of the historical subtask in the current time slot and the processing latency of the historical subtask at this service facility. For example: τ m Subtasks for time slot updates v n,k The end time can be obtained by referring to formula (11).

[0096] Considering the dependencies between subtasks, once the historical subtask v... n,k The start and end execution times of the task are updated, as are the start and end execution times of its direct successor subtasks. It also needs to be updated. That is, after the start and end times of a historical subtask are updated, the start and end times of related subsequent historical subtasks are updated using a time-series model based on the data dependencies corresponding to the historical subtasks. Next, if... Then it needs to be updated. direct successor subtask The start and end execution times, until Updates will stop at that time. Therefore, there are

[0097]

[0098] in, Represents τ m Successor subtasks of time slot history In its service facilities d The start time in the waiting queue information. Indicates the previous time slot τ m -1 The successor subtask of a defined history The start time of execution. Indicates the successor subtask Precursor missions in its service facilities c The processing latency and the data transmission of the processed results to the service facility are also considered. d The sum of transmission delays, N n This represents the number of subtasks of task n.

[0099] Similarly, τ m Subtasks for time slot updates End time This can be obtained from formula (11). Furthermore, since... The update may affect the state of other subtasks, so repeat formulas (12) and (13) until τ. m The state of time slots without subtasks needs to be updated. For subtasks whose state remains unchanged, there are... and

[0100] Let Y represent the time slot when the last task in the M tasks arrives. From formulas (12) and (13), it can be seen that the start and end times of each subtask may be updated in the next time slot or remain unchanged. Therefore, the final start and end times of each subtask are expressed as... and Considering that each user's first subtask has no predecessor subtask and is processed locally on the user's device (Equation (3)), then Represented as

[0101]

[0102] Finally, the execution time of task m is expressed as:

[0103] Combining formula (10), the estimated start time for subtask v at service facility s is:

[0104]

[0105] Expected completion time Represented as

[0106]

[0107] As can be seen from formula (3), if v is the first or last subtask of the user equipment, then it is processed by the user equipment, i.e. Otherwise, v will be handled by the service facility that completes its execution earliest, i.e. Once determined, subtask v will be removed from Λ. Next, the target service facility for the first subtask in Λ is determined using formulas (15) and (16) until... At this point, we have obtained the set of unloading decisions for all subtasks in this round, i.e., the unloading strategy, denoted as χ. i .

[0108] Based on χ i With the preemption mechanism, the actual execution time of each subtask can be obtained by formulas (10)-(13).

[0109] Then, the latency satisfaction of each user is calculated according to the unloading strategy. The latency satisfaction of a single user is determined as follows: if the completion execution time of the user's task does not exceed the expected completion time of the task, the latency satisfaction is 1; otherwise, the latency satisfaction is the ratio of the expected completion time of the task to the completion execution time of the task, where the completion time of the task is determined based on the completion execution time of the last subtask of the task. Correspondingly, the completion execution time is converted into the user's latency satisfaction based on formula (17) and used as a newly added node υ in T.c Reward value Q i (υ c ):

[0110]

[0111] Among them, E m Let m represent the expected time for task m. This indicates the completion time of task m. If the actual completion time of the task... No more than E m The corresponding latency satisfaction =1, otherwise Equal to E m and The ratio.

[0112] After converting the execution time into user latency satisfaction based on formula (17), the user's average latency satisfaction can be calculated as the reward value and added as a new node υ in the search tree T. c Reward value Q i (υ c The illustrative calculation method for users' average latency satisfaction is as follows:

[0113]

[0114] Where M represents the number of current tasks. This indicates the end time of the current task m.

[0115] The objective of this invention is to design a service facility selection offloading strategy under limited computing and communication resources to maximize average latency satisfaction. The problem can be formulated as follows:

[0116]

[0117] st(1),(2),(3),(10),(11),(12),(13),(14).

[0118] (4) Backpropagation

[0119] After the simulation is complete, it is necessary to backtrack along the search path from the expanded nodes to the root node to update the reward value and visit count of all nodes on the search path. For illustration, obtain node υ. c Reward value Q i (υ c After that, it needs to be done by υ c Backtracking to the root node υ root This updates the reward values ​​and visit counts for all nodes along the search path. Specifically, from υ c Back to υroot The number of visits to node υ on the path becomes N(υ) = N(υ) + 1 and the reward value becomes Q. i (υ)=Q i (υ c Note that if Q i (υ c ) greater than Q MAX This means that compared to previous rounds, this round found a better unloading strategy. Then, Q... MAX Updated to Q i (υ c And the selection strategy χ MAX Updated to χ i At this point, the algorithm has completed the i-th iteration, and Λ has returned to its initial state.

[0120] The algorithm iterates continuously until the search tree T becomes unscalable or the preset number of iterations I is reached. threshold When the upper limit is reached, the optimal average delay satisfaction Q is obtained. MAX and the corresponding uninstallation strategy χ MAX Optimal average delay satisfaction Q MAX Corresponding uninstallation strategy χ MAX This is the final uninstallation strategy.

[0121] According to one embodiment of the present invention, the method further includes: instructing, based on a final offloading policy, to allocate each subtask of the tasks of the plurality of user devices to designated service facilities for processing. In this case, the cloud server can transmit the final offloading policy to the relevant service facilities, so that each service facility can process the corresponding subtask according to the final offloading policy and transmit the result data of the subtask to the corresponding service facility. See also Figure 4 For example, a task information record shows a task containing subtasks 1-7. According to the unloading strategy, subtasks 1-7 are assigned to corresponding service facilities for processing. The solution in this embodiment of the invention fully considers the impact of resource preemption and dependency relationships on the unloading decision. It establishes a dynamic time-series model (or time-series state update model) to describe changes in the task service state (i.e., changes in the start and end times of corresponding subtasks within the task). Based on the updated service state, it optimizes the selection of the unloading target service facility, resulting in a final unloading strategy that achieves optimal average latency satisfaction and improves the system's service quality.

[0122] In each iteration, when an unloading strategy is obtained, only the possible start and end times of the current subtask are estimated using a timing model; no actual additions are made to the corresponding waiting queue information. After obtaining the final unloading strategy, the start and end times of the current subtask are added to the corresponding waiting queue information, and the start and end times of affected historical subtasks are updated. This serves as a reference for determining the unloading strategy for subsequent tasks. According to an embodiment of the present invention, the method includes: after the final unloading decision for each current task is determined, adding the start and end times of each current subtask under the final unloading strategy to the waiting queue information corresponding to each service facility, and using the timing model to update the start and end times of historical subtasks affected by resource preemption patterns in each waiting queue information. Preferably, updating the start and end times of historical subtasks affected by resource preemption includes: for historical subtasks with lower priority but an end time greater than or equal to the start time of the current subtask, determining the maximum value among the end times of other subtasks with higher priority than the historical subtask in the waiting queue information and the start time of the historical subtask determined in the previous time slot, to update the start time of the historical subtask in the current time slot; and updating the end time of the historical subtask based on the sum of the start time of the historical subtask in the current time slot and the processing latency of the historical subtask in the service facility. Furthermore, updating the start and end times of historical subtasks affected by resource preemption also includes: after the start and end times of a historical subtask are updated, updating the start and end times of related subsequent historical subtasks using a time-series model based on the data dependencies corresponding to the historical subtask.

[0123] To verify the effectiveness of the embodiments of the present invention, the inventors also conducted relevant comparative experiments.

[0124] This comparative experiment assumes a three-tier MEC architecture with a range of 1km × 1km, consisting of a cloud server, multiple edge devices (BSs), and multiple mobile devices (as user equipment). The cloud server covers all BSs, and the mobile facilities are randomly distributed. The CPU frequencies of the cloud server, BSs, and mobile devices follow a uniform distribution of [15,20]GHz, [4,5]GHz, and 1GHz. According to the IEEE 802.3 protocol, the wired transmission rate between the cloud server and BSs is... Mbps. The bandwidth of each BS follows a uniform distribution between [20, 25] MHz, and the bandwidth of the mobile device is set to 5 MHz. The transmission power of the BS and the mobile device are 20 W and 0.2 W, respectively. The channel modeling between the BSs and the user is 127 + 30 log ... 10 (d) Gaussian noise N = 1 × 10 -13 w. Referring to DAGs used in practical tasks such as facial recognition and virtual reality, the construction method of a DAG is as follows:

[0125] 1. The number of subtasks |V| takes a random value between [1, 20].

[0126] 2. The computational cost d for each subtask m,j Randomly selected values ​​between 900 Megacycles and 1000 Megacycles;

[0127] 3. Data transfer volume between subtasks m,i,j The value depends on the Communication to Computation Ratio (CCR) of the task. CCR is defined as the ratio of the sum of the transmission delays to the sum of the processing delays of all subtasks in the DAG, and this ratio is set to a random number between [0.1, 5]. If the task is computationally intensive, the CCR value will be smaller. m,i,j It is obtained by multiplying the computational cost by the CCR.

[0128] 4. The number of direct predecessors and successors for each subtask is generated by a random integer between [1, |V|-2]. The dependency of the DAG is represented by the average of the sum of the number of direct predecessors and successors in the DAG;

[0129] 5. For each task m, the expected task completion delay is generated according to a normal distribution with a mean of 0.5 (seconds) and a standard deviation of 1.2 (seconds). Correspondingly, the expected delay of the task is the sum of the task's arrival time slot and the task completion delay.

[0130] In the proposed PDO-MCTS (Priority and Dependency-based Offloading with Monte Carlo Tree Search) algorithm (i.e., the method of this invention), the constant parameter c of the UCB function is set to 10. The PDO-MCTS algorithm is compared with the following baseline algorithms:

[0131] Brute Force (BF): Obtains the optimal choice by exhaustive search.

[0132] Earliest Finish Time (EFT) Algorithm: The EFT algorithm first designs a sorting mechanism to determine the selection order of each subtask. Based on the selection order, a greedy algorithm is used to assign the subtasks to the current best service facility in turn, minimizing its completion time.

[0133] The Centralized Earlist Finish-time Offloading (CEFO) algorithm, similar to the BF algorithm, assigns subtasks to the optimal service facility through exhaustive search. The difference is that the CEFO algorithm assigns subtasks from the same user to the same service facility to reduce time complexity.

[0134] Online Offloading Framework (COFE) Algorithm: The COFE algorithm first estimates the completion time of each subtask on each service facility and designs a matching scheme for allocation.

[0135] The Queuing-MCTS algorithm, unlike the PDO-MCTS algorithm, adopts a strategy based on the FCFS scheme.

[0136] The performance gains of PDO-MCTS mainly come from the resource preemption scheme and the MCTS algorithm. First, the effectiveness of resource preemption is verified by comparing the priority-based preemption scheme and the FCFS scheme under the MCTS algorithm. Based on this, the effectiveness of the proposed MCTS algorithm is verified by comparing the cumulative distribution function (CDF) of the performance of different baseline algorithms under different preemption schemes. Finally, the effectiveness of PDO-MCTS is verified through overall performance comparison. To evaluate CDF performance, network sizes with a uniformly distributed number of edge service facilities (S) between [1-5] and a uniformly distributed number of users (M) between [1-10] are randomly generated. For each value of M and S, 500 DAGs are randomly generated according to the DAG construction rules, generating a total of 25,000 test cases to evaluate the performance of all algorithms.

[0137] The following is through Figures 5-7 To visually demonstrate the effect, including:

[0138] Figure 5A comparison of the CDF curves for user latency satisfaction under the preemptive and FCFS schemes of the MCTS algorithm is presented, corresponding to PDO-MCTS and FCFS-MCTS respectively. It can be seen that PDO-MCTS has better user latency satisfaction performance than FCFS-MCTS. For example, in 60% of the test cases, the user latency satisfaction based on PDO-MCTS is about 10% higher than that based on FCFS-MCTS. This is because PDO-MCTS can allocate different resources to tasks with different QoS requirements. Therefore, to ensure the satisfaction of high latency-sensitive tasks, PDO-MCTS can prioritize the use of limited high bandwidth, high CPU frequency, and other resources for these tasks. FCFS-MCTS, on the other hand, ignores the differences in QoS requirements between tasks, which may reduce the satisfaction of high latency-sensitive tasks.

[0139] Figure 6 A comparison of latency satisfaction (CDF) based on different selection algorithms under preemption schemes was conducted. Among all algorithms, PDO-MCTS performed best. For example, in 60% of the test cases, the latency satisfaction of PDO-MCTS was approximately 11%, 12%, and 8% higher than CEFO, HEFT, and COFE, respectively. The performance difference between PDO-MCTS and other algorithms mainly stems from the fact that when other algorithms determine the offloading decision for a subtask, they only search the current state of all service facilities and select the optimal solution based on the current state. Therefore, the search is prone to getting trapped in local optima. PDO-MCTS, on the other hand, can simulate future search steps and then back-evaluate the current selection decision. PDO-MCTS will select a potentially optimal solution to escape the local optimum trap.

[0140] To demonstrate the effectiveness of PDO-MCTS, its performance was compared with the optimal algorithm BF. Furthermore, to prove that the performance gains of the preemptive scheme and the MCTS algorithm are jointly effective, the CDF of PDO-MCTS and other algorithms under the FCFS scheme was also compared. Figure 7 As shown, the satisfaction performance of PDO-MCTS is close to that of the optimal algorithm BF, and its performance exceeds that of other algorithms by 20%.

[0141] In summary, simulation results demonstrate that the method proposed in this invention can effectively reduce the waiting latency of high-latency-sensitive tasks. Furthermore, compared to existing offloading schemes, the average latency satisfaction of tasks is improved by more than 20%.

[0142] Finally, it should be noted that although the above embodiments describe the calculation methods of some data using formulas, it should be understood that the above calculation methods are not the only methods. Some equivalent methods can be used instead, or some sub-items in the formula can be multiplied by preset weights, or adjustment factors can be added to form other implementation methods. The present invention does not limit these methods.

[0143] It should be noted that although the steps are described in a specific order above, 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 function can be achieved.

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

[0145] Computer-readable storage media can be tangible devices that hold and store instructions for use by an instruction execution device. Computer-readable storage media can be, for example, including but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.

[0146] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for implementing resource preemptive offloading in a cloud-edge system, wherein the cloud-edge system includes a cloud server supporting the processing of user device offloading subtasks and multiple edge devices, wherein, In addition to user equipment serving as a service facility for its subtasks, cloud servers and edge devices can also serve as service facilities for corresponding subtasks of user equipment. The method is characterized by the cloud server performing the following operations: Obtain task information sent by multiple user devices, including the expected arrival time slot of the user's current task, the data dependencies between the subtasks of the task, the computational amount of each subtask, the amount of data transmitted between the subtasks, and the expected time to complete the task. By utilizing the expected times corresponding to each current task and the expected times corresponding to previous historical tasks, the priorities of the current subtasks and each historical subtask are determined. Each service facility maintains a waiting queue, which includes the start and end times of each historical subtask waiting to be processed by that service facility. The start and end times are obtained by a preset timing model after analyzing transmission latency, processing latency, and additional latency caused by a preset resource preemption mode. The rule of the resource preemption mode is that when execution time ranges overlap, higher priority subtasks can preempt the resources of lower priority subtasks to execute first. The search space is determined based on the data dependencies and service facilities among the subtasks contained in each current task; Using the Monte Carlo tree search method, multiple iterative searches are performed in the search space based on the confidence upper bound function to obtain the unloading strategy that optimizes the overall latency satisfaction of each task. After obtaining the unloading strategy in each iteration, the start and end times of each subtask under the corresponding service facility are estimated based on the waiting queue information and the timing model under the resource preemption mode to calculate the user's average latency satisfaction as the reward value.

2. The method according to claim 1, characterized in that, The time series model is configured as follows: After the final unloading decision for each current task is determined, the start and end times of each subtask under the final unloading strategy are added to the waiting queue information of each service facility. The timing model is then used to update the start and end times of historical subtasks affected by resource preemption in each waiting queue.

3. The method according to claim 2, characterized in that, Under any unloading policy, the start time of the current subtask in a service facility is determined as follows: in, This indicates the current subtask v according to the uninstallation strategy. m,j In service facilities b The value at τ m Indicates the current subtask v m,j The expected arrival time slot, Subtask v m,j All data results from the preceding subtasks have been offloaded to the service facility. b At the moment, where pre(v m,j ) represents v m,j A collection of precursor subtasks, v m,i Indicates the current subtask v m,j The precursor sub-task. Represents τ m Precursor subtask v for time slot recording m,i In its service facilities a The end execution time on Indicates the service facilities s from the precursor sub-task a The data results are transmitted to the service facility s of the current subtask. b Transmission delay, Indicates service facilities s b All subtasks with higher priority than the current subtask v in the waiting queue m,j The maximum execution time of the historical subtasks, p(u) represents the priority of the corresponding historical subtask, and p(m) represents the current subtask v. m,j priority, Subtasks representing history v u,l The corresponding uninstallation strategy includes historical subtasks v u,l In service facilities b The value at that location, Indicates the previous time slot τ m -1 A defined subtask of history v u,l The completion execution time.

4. The method according to claim 2, characterized in that, The timing model is configured such that, under any offloading strategy, the sum of the start execution time of the current subtask in a service facility and the processing latency of the subtask in that service facility is used as the end execution time of the current subtask.

5. The method according to claim 4, characterized in that, The start and end times of the subtasks that update the history affected by the resource preemption mode include: For historical subtasks with lower priority but whose end execution time is greater than or equal to the start execution time of the current subtask, determine the maximum value among the end execution times of other subtasks with higher priority than or equal to the historical subtask in the waiting queue information and the start execution times of the historical subtask determined in the previous time slot, so as to update the start execution time of the historical subtask in the current time slot. Update the end time of the historical subtask based on the sum of the start time of the historical subtask in the current time slot and the processing latency of the historical subtask in the service facility.

6. The method according to claim 5, characterized in that, The start and end times of the subtasks that update the history affected by the resource preemption mode also include: After the start and end times of a historical subtask are updated, the start and end times of related subsequent historical subtasks are updated using a time-series model based on the data dependencies corresponding to the historical subtasks.

7. The method according to claim 1, characterized in that, The average latency satisfaction of the users is the average of the latency satisfaction of each user corresponding to the multiple user devices, wherein the latency satisfaction of a single user is determined in the following manner: If the completion time of a user's task does not exceed the expected completion time of the task, the latency satisfaction is 1; otherwise, the latency satisfaction is the ratio of the expected completion time of the task to the completion execution time of the task, wherein the completion time of the task is determined based on the completion execution time of the last subtask of the task.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Based on the final offloading strategy, instructions are given to assign each subtask of the tasks of the multiple user devices to designated service facilities for processing.

9. A computer-readable storage medium, characterized in that, It contains a computer program that can be executed by a processor to implement the steps of the method according to any one of claims 1 to 8.

10. An electronic device, characterized in that, include: One or more processors; as well as 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 8 by executing the executable instructions.

Images