Fault-tolerant perception task unloading method in end-side cloud collaborative environment

Abstract

The invention provides a fault-tolerant perception task unloading method in an end-side cloud cooperative environment, which relates to the technical field of wireless communication networks and comprises the following steps: receiving tasks generated by a plurality of mobile devices; calculating a fault recovery time expected value of a node and a task processing total cost model based on an edge server, and independently determining a distributed unloading strategy of a task for each mobile device by using a deep cycle Q network algorithm; in a task execution process, monitoring whether a computing node of the edge server has a fault or not; when it is detected that the computing node of the edge server has a fault, fault recovery is carried out by adopting a fault-tolerant technology; according to the fault recovery condition, the execution strategy of the influenced task is dynamically adjusted, it is ensured that the task is completed before the maximum tolerance time delay, the total task processing cost is minimized, and the total task processing cost is the weighted sum of task execution time delay and energy consumption. It is ensured that the task can still be completed at a certain success rate before the maximum allowable deadline when a fault occurs, and the user experience quality is improved.

Description

Technical Field

[0001] This invention relates to the field of wireless communication network technology, and in particular to a fault-tolerant sensing task offloading method in an edge-cloud collaborative environment. Background Technology

[0002] Currently, with the rapid development of the Internet of Things (IoT) and cloud computing, the number of mobile devices is surging, and the amount of data generated is growing exponentially. As a mainstream computing paradigm, cloud computing can provide powerful on-demand computing capabilities for various applications.

[0003] However, cloud computing faces significant challenges in meeting the low latency and privacy requirements of real-time applications such as autonomous driving, real-time video analytics, and telehealth. Transferring data to the cloud for processing not only leads to uncontrollable latency but also increases the risk of privacy breaches, severely impacting the quality of user experience.

[0004] To address these issues, mobile edge computing has emerged, which effectively reduces data transmission latency and energy consumption and improves task processing efficiency by deploying computing nodes close to users.

[0005] However, existing technologies have shortcomings: edge servers, due to resource constraints and task heterogeneity, may fail due to hardware or software malfunctions during task execution. Many current studies primarily focus on latency and energy consumption optimization in fault-free scenarios, neglecting the impact of fault recovery time on task performance. This results in proposed scheduling models and algorithms that fail to accurately reflect the realities of edge-cloud collaborative computing. Summary of the Invention

[0006] The purpose of this invention is to provide a fault-tolerant and task offloading method in an edge-cloud collaborative environment to solve the problems mentioned in the background art.

[0007] This invention provides a fault-tolerant, cloud-based collaborative environment task offloading method, comprising:

[0008] Receive tasks generated by multiple mobile devices, each task including data size, required number of CPU cycles, and maximum tolerable latency;

[0009] Based on the expected value of fault recovery time and the total cost model of task processing of edge server computing nodes, a distributed offloading strategy for tasks is independently determined for each mobile device using the deep recurrent Q network algorithm. The offloading strategy includes: executing the task locally on the mobile device, offloading to the edge server for execution, or offloading to the cloud server for execution.

[0010] During task execution, monitor whether the edge server computing nodes fail.

[0011] When a failure is detected in an edge server computing node, fault-tolerant technology is used for fault recovery.

[0012] Based on the fault recovery status, the execution strategy of the affected tasks is dynamically adjusted to ensure that the tasks are completed before the maximum tolerable delay and to minimize the total task processing cost, which is the weighted sum of task execution delay and energy consumption.

[0013] The expected value of the fault recovery time is calculated based on a model in which the occurrence of edge server faults follows a Poisson distribution and the fault repair time follows an exponential distribution.

[0014] Optionally, fault-tolerant techniques for fault recovery include:

[0015] Rollback technology is used to allow tasks to continue execution from the state before the failure after the failure is recovered.

[0016] Optionally, performing tasks locally on the mobile device includes:

[0017] Add the task to the local computing queue of the mobile device;

[0018] The waiting time of the computation task in the local computation queue and the processing time on the local device;

[0019] Based on the waiting time, processing time, and energy consumption parameters of the mobile device, calculate the energy consumption required for the task to be executed locally and the total cost of task processing.

[0020] Optionally, offloading the task to an edge server or cloud server for execution includes:

[0021] Transmit the task from the mobile device to the base station, and calculate the transmission latency and energy consumption required for the task transmission.

[0022] According to the offloading strategy, tasks are allocated from the base station to the edge server computing queue or forwarded to the cloud server computing queue through the core network.

[0023] Optionally, performing tasks on the edge server includes:

[0024] Add the task to the compute queue allocated to the mobile device on the edge server;

[0025] Considering the potential failures of edge server computing nodes and their expected recovery time, the expected time slot for the computing task to begin processing on the edge server, the expected processing latency, and the expected execution energy consumption are as follows:

[0026] Update the status of the edge server computing queue, including queue length and information on dropped tasks.

[0027] Optionally, performing tasks on a cloud server includes:

[0028] Add the task to the computing queue allocated to the mobile device on the cloud server;

[0029] The time slot, processing latency, and execution energy consumption of the computing task when it begins processing on the cloud server;

[0030] Update the status of the cloud server computing queue, including queue length and information on dropped tasks;

[0031] Calculate the idle power consumption of mobile devices while tasks are waiting to be processed by the cloud server.

[0032] Optionally, minimizing the total cost of task processing and ensuring that the task is completed before the maximum tolerable latency to optimize user experience quality includes:

[0033] User experience quality is defined as follows: if the task is successfully completed within the maximum tolerable latency, the user experience quality is equal to the reward constant minus the total task processing cost; otherwise, the user experience quality is equal to the negative total task processing cost.

[0034] The unloading strategy is optimized by using a deep recurrent Q-network algorithm to maximize the expected quality of user experience.

[0035] Optionally, the distributed offloading strategy can be determined using a deep recurrent Q-network algorithm, including:

[0036] Construct a state space, which includes the local queue state of the mobile device, the channel state, the task attributes, the edge server fault state, and the queue state information.

[0037] Construct an action space, which corresponds to the selection of the unloading strategy;

[0038] Define a reward function based on user experience quality;

[0039] Deploy a DRQN ​​agent on each mobile device to select actions based on locally observed state information;

[0040] The DRQN ​​agent is trained using reinforcement learning to learn the optimal offloading strategy.

[0041] Optionally, fault-tolerant and task offloading methods in an edge-cloud collaborative environment also include:

[0042] Real-time monitoring of task execution status, edge server failure events, and system performance metrics;

[0043] Based on the monitored historical data, adjust the parameters of the fault-tolerant technology and / or the training parameters of the deep recurrent Q-network algorithm.

[0044] Optionally, the method can be applied to scenarios that are sensitive to latency and require high reliability, including real-time health monitoring, online games, or social networks.

[0045] The present invention has achieved the following beneficial effects:

[0046] This invention proposes a latency and energy consumption model that considers the impact of edge server computing node failure recovery time on task execution. By optimizing overall system overhead through reasonable offloading decisions, it ensures that tasks can still be completed within the maximum allowable timeframe with a certain success rate even in the event of a failure, thereby improving user experience. Furthermore, the invention designs a distributed fault-tolerant task offloading scheme based on a deep recurrent Q-network. Simulation verification shows that compared to other baseline algorithms, this scheme achieves a superior offloading strategy, effectively reducing system overhead and improving task execution success rate. This technology can be widely applied in real-time health monitoring, online games, social networks, and other fields, significantly improving user satisfaction.

[0047] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0048] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0049] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0050] Figure 1 This is a schematic diagram of a fault-tolerant and cloud-based task offloading method in an end-edge-cloud collaborative environment, as described in an embodiment of the present invention.

[0051] Figure 2 This is a schematic diagram of a scenario for edge-cloud collaborative computing in an embodiment of the present invention;

[0052] Figure 3 This is a comparison chart of the convergence performance of the method of this application with three other distributed deep reinforcement learning-based schemes in this embodiment of the invention. Detailed Implementation

[0053] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0054] Example 1:

[0055] Figure 1 This application provides a flowchart of a fault-tolerant, cloud-based collaborative task offloading method, as illustrated in the embodiments of this application. Figure 1 As shown, the method includes:

[0056] 101. Receive tasks generated by multiple mobile devices, each task including data size, required number of CPU cycles, and maximum tolerable latency;

[0057] 102. Based on the expected value of fault recovery time and the total cost model of task processing of edge server computing nodes, a distributed offloading strategy for each mobile device is independently determined using the deep recurrent Q-network algorithm. The offloading strategy includes: executing the task locally on the mobile device, offloading to the edge server for execution, or offloading to the cloud server for execution.

[0058] 103. During task execution, monitor whether the edge server computing nodes malfunction;

[0059] 104. When a failure is detected in an edge server computing node, fault-tolerant technology is used for fault recovery.

[0060] 105. Based on the fault recovery status, dynamically adjust the execution strategy of the affected tasks to ensure that the tasks are completed before the maximum tolerable delay and minimize the total task processing cost, which is the weighted sum of task execution delay and energy consumption.

[0061] The expected value of the fault recovery time is calculated based on a model in which the occurrence of edge server faults follows a Poisson distribution and the fault repair time follows an exponential distribution.

[0062] Cloud servers have abundant resources and can handle tasks with large data volumes, but they struggle with latency-sensitive tasks. Edge servers, deployed at base stations near user devices, can handle latency-sensitive tasks, but their resources are relatively scarce. Therefore, an edge-cloud collaborative computing system is considered. This system would determine whether a task is executed locally or offloaded from the base station to an edge server or cloud server for execution through offloading decisions. Figure 2 The image shows a scenario of edge-cloud collaborative computing according to this application.

[0063] This invention addresses edge-cloud collaborative computing by considering edge server compute node failures and task offloading. It modifies existing edge-cloud collaborative computing models to better reflect real-world scenarios. Key innovations include a proposed model for task execution latency and energy consumption considering compute node failures, along with a corresponding optimization objective: average user QoE. Modeled as a Markov decision, a DRQN-based distributed fault-tolerant task offloading algorithm is proposed.

[0064] Consider an edge-cloud collaborative computing offloading architecture, consisting of a remote cloud server, a base station (BS) equipped with a Mobile Edge Computing (MEC) server, and several randomly distributed mobile devices (MDs). The base station is connected to the cloud server via a core network. Using a set... Let I represent the set of all mobile devices, where I is the total number of devices. To simulate the dynamics of the system, time is divided into T discrete time slots of equal length, denoted as . Each time slot lasts for τ seconds. For each mobile device i, two independent First-In-First-Out (FIFO) queues are set up for local processing and scheduling to the MEC server, respectively; similarly, the MEC server and the cloud server each contain I FIFO computation queues. This represents the index of the task generated by device i in time slot t, where each task is represented by a triple {D}. i (t),C i (t),T max} constitutes, where D i (t), C i (t) and T max These represent the data size (Mbit), the number of CPU cycles required per Mbit, and the maximum tolerable latency (in time slots), respectively. If device i does not generate a task in a certain time slot t, the data size of the corresponding task is set to 0; tasks that are not completed after exceeding the maximum tolerable latency will be discarded. Assuming all tasks are indivisible, three binary decision variables are introduced. and Let represent the offloading decision of the t-th time slot device for the ith task, denoted as local execution, execution on the MEC server, and execution on the cloud server, respectively. Since tasks are indivisible, each task can only be assigned to one computing mode per time slot, therefore, the following constraints must be satisfied.

[0065] Due to external or internal factors, MEC servers may fail, causing the virtual machines (VMs) deployed on them to malfunction. Assume that all MEC server failures can be detected instantly, and that after a recovery process, system components can return to their original runnable state and continue execution. Existing research indicates that the frequency of node failures follows a Poisson distribution, a statistical model widely used in reliability analysis. To model the task execution problem considering MEC server failures in an edge-cloud collaborative environment, assume that during time slot t, the time intervals between two MEC server failures are independent and follow an exponential distribution with parameter λ(t) (λ(t)>0); all failures are repairable, and the repair time for each failure is independent and follows an exponential distribution with parameter μ(t) (μ(t)>0). Let NF(t) be the total number of MEC server failures within the time interval t, a random variable. The probability of taking the value NF(t) = k is given by the following formula:

[0066]

[0067] Where Pr represents probability and e is the natural constant. Then, the expected value of the number of failures NF(t) is:

[0068] Exp[NF(t)]=λ(t)t (2)

[0069] Similarly, using RT (k) (k = 1, 2, 3, ...) represents the recovery time for the k-th failure of the MEC server, and the expected recovery time is:

[0070]

[0071] Furthermore, let T re (t) represents the total repair time for all faults within the time slot, and its expectation can be written as:

[0072]

[0073] Example 2:

[0074] In one embodiment, fault recovery using fault-tolerant techniques includes:

[0075] Rollback technology is used to allow tasks to continue execution from the state before the failure after the failure is recovered.

[0076] During a failure, fault-tolerant techniques such as rollback are employed. By using appropriate offloading methods, tasks are guaranteed to complete within the maximum allowable execution period with a certain success rate during the failure period, thus ensuring the quality of user experience.

[0077] Example 3:

[0078] In one embodiment, performing a task locally on a mobile device includes:

[0079] Add the task to the local computing queue of the mobile device;

[0080] The waiting time of the computation task in the local computation queue and the processing time on the local device;

[0081] Based on the waiting time, processing time, and energy consumption parameters of the mobile device, calculate the energy consumption required for the task to be executed locally and the total cost of task processing.

[0082] Local execution is modeled using a system consisting of a compute queue and a mobile device processor. Each mobile device i is equipped with a compute queue. Let... This represents the CPU computing power of device i (cycles / second). If the task... It is assigned to local execution at the beginning of time slot t, and This indicates the number of time slots the task is waiting in the computation queue. It can be represented as:

[0083]

[0084] in[·] + =max(0,·) and This represents the time interval required for the previous task to be processed. From equation (5), we obtain the queuing delay for the task... The processed time slot can be represented as the sum of the delay of the current time slot waiting for the preceding task to be processed and the time slot required for local processing. This indicates the task being executed locally. In the The time slot is processed (i.e., completed or discarded). This can be defined by equation (6):

[0085]

[0086] in This indicates rounding up, where τ is the duration of a time slot. This represents the number of waiting time slots before the task is processed. Therefore, based on the task's data volume D... i (t) and the number of CPU cycles required per Mbit C i (t). Task of device i Latency generated during local execution Possible forms:

[0087]

[0088] Task The energy consumption of execution is determined by the utilization of CPU, memory, and disk resources. Let... The energy consumption for performing this task locally is as follows:

[0089]

[0090] Where κ is the effective switched capacitor energy coefficient.

[0091] Example 4:

[0092] In one embodiment, offloading the task to an MEC server or cloud server for execution includes:

[0093] Transmit the task from the mobile device to the base station, and calculate the transmission latency and energy consumption required for the task transmission.

[0094] According to the offloading strategy, tasks are allocated from the base station to the MEC server computing queue or forwarded to the cloud server computing queue through the core network.

[0095] If the task is offloaded from mobile device i to BS, it can be executed on the MEC server. According to Shannon's formula, the uplink data transmission rate (in bits per second) between mobile device i and BS can be expressed as:

[0096]

[0097] Where B / I represents the transmission bandwidth between mobile device i and BS, p i Indicates the transmission power, h i σ represents the channel power gain of device i between time slot t and the base station. 2 This represents the Gaussian noise power. Since the MEC server is deployed close to the base station, the time required for data transmission to the MEC server is negligible.

[0098] Similar to the local computing model, suppose each mobile device i has a dedicated transmission queue between itself and the base station. When a task begins to be offloaded to the base station in time slot t, To represent the number of remaining time slots required before entering the transmission queue, we have:

[0099]

[0100] It is important to note that Values ​​and Closely related. Here Defined as a task The time slot index that is completed or dropped through the valid wireless channel transmission queue of device i is expressed as:

[0101]

[0102] in D represents the number of waiting time intervals required before task processing. i (t) represents the size of the task data, R i (t) represents the transmission rate. The transmission time interval of a task is the difference between its completion time slot and its start time slot. Therefore, the task... The required number of transmission time slots can be calculated using the following formula:

[0103]

[0104] make This indicates the energy consumption required for task transmission. Let represent the transmit power of the communication link between mobile device i and the base station, then:

[0105]

[0106] Example 5:

[0107] In one embodiment, performing a task on an edge server includes:

[0108] Add the task to the compute queue allocated to the mobile device on the edge server;

[0109] Considering the potential failures of edge server computing nodes and their expected recovery time, the expected time slot for the computing task to begin processing on the edge server, the expected processing latency, and the expected execution energy consumption are as follows:

[0110] Update the status of the edge server computing queue, including queue length and information on dropped tasks.

[0111] To model the execution process on the edge server, each mobile device i is allocated a dedicated computation queue on the MEC server. When a task... After arriving at the MEC server via the transmission queue within a certain time interval, it will be added to the corresponding computation queue at the start of the next time interval. (Using variables) and These represent the tasks in the i-th queue, respectively. The queue is defined as having an index, task size (bits), and required CPU cycles. A queue is defined as active if at least one task remains unfinished, or if a new task is received in the current time slot. (Unit: bit) represents the queue length of the i-th edge queue at the end of time slot t. Let B M (t) represents the set of all valid queues on the MEC server, which can be represented by the following formula:

[0112]

[0113] Let b M (t)=|B M (t) represents the number of valid queues on the MEC server within time slot t. This paper assumes that the MEC server's computing resources are evenly distributed among all valid queues within each time slot. Let f... M This represents the total computing resources available to the MEC server. Since the set of effective compute queues on the MEC server changes in real time, the resources allocated to each task also change dynamically. However, considering that server failures may cause virtual machine interruptions, the actual computing resources allocated to each effective task queue within time slot t are... It should be noted that if a task fails to complete within the maximum tolerable delay, it will be discarded. (Unit: bit) represents the number of task bits discarded in the i-th queue at the end of time slot t. The length of the edge computing queue associated with device i can then be expressed by equation (15):

[0114]

[0115] When mobile device i's task When slot t begins to be placed into the corresponding queue on the MEC server, similar to a local processing queue, let Indicates task The time slots that are completed or discarded on the MEC server. Due to the uncertainty of computing resource allocation on the MEC server, the specific completion time slot of a task cannot be accurately predicted. Indicates task The time slots that begin to be processed on the MEC are:

[0116]

[0117] It should be particularly pointed out that the task The execution time slot should begin neither earlier than the time slot in which the task arrives at the MEC server's compute queue, nor later than the time slot in which the task begins execution. The time slot that is completed or discarded. To ensure that the computing resources allocated to each task offloaded to the MEC server are exactly sufficient to complete the task processing, the following constraints must be met:

[0118]

[0119] make Indicates task The number of time slots required to complete processing on the MEC server. Its expected value can then be calculated using equation (19) as follows:

[0120]

[0121] definition The energy consumed by a task during execution on the MEC server can be calculated using the following formula:

[0122]

[0123] Among them, P M This represents the power consumption of the MEC server under full load, and is a constant.

[0124] It's important to note that mobile devices consume energy while waiting for tasks to be processed, even when idle. Therefore, in addition to the energy consumption of the MEC server, the energy consumption of mobile devices in the idle state must also be considered. Let the power consumption of mobile device i in the idle state be... Then its energy consumption during the waiting period It can be represented as:

[0125]

[0126] Example 6:

[0127] In one embodiment, performing a task on a cloud server includes:

[0128] Add the task to the computing queue allocated to the mobile device on the cloud server;

[0129] The time slot, processing latency, and execution energy consumption of the computing task when it begins processing on the cloud server;

[0130] Update the status of the cloud server computing queue, including queue length and information on dropped tasks;

[0131] Calculate the idle power consumption of mobile devices while tasks are waiting to be processed by the cloud server.

[0132] If the task The data is offloaded to the cloud server for processing. First, it is transmitted from the mobile device to the browser / base (BS) via a transmission queue, and then forwarded to the remote cloud server through the core network. The transmission rate of the core network is denoted as R. C .make Let represent the number of time slots required for the task to be transmitted in the core network. Then:

[0133]

[0134] Similar to the discussion in edge computing, each mobile device *i* also has its own dedicated computing queue on the cloud server. When a task arrives at the cloud server in a given time slot, it will be added to the queue to await execution in the next time slot. Let the variable... and Let B represent the task index, task size (in bits), and number of CPU cycles required for the i-th queue, respectively. The effective queue set B on the cloud server... C (t) can be defined as:

[0135]

[0136] At the end of time slot t, the queue length of the corresponding computing queue for the i-th device on the cloud server. (In bits) can be calculated using formula (24) as follows:

[0137]

[0138] Where f represents C The total computing resources of the cloud server and have b C (t)=|B C (t)|. Additionally... (Unit: bit) represents the number of task bits discarded in the i-th queue at the end of time slot t. Definition For the task The time slots where tasks are completed or discarded on the cloud server. The time slots where tasks begin processing. It can be represented as:

[0139]

[0140] The same task still satisfies the constraints on a cloud server:

[0141]

[0142] make Let represent the number of time slots required to process the task on the cloud server. Then:

[0143]

[0144] Because cloud servers are connected to a stable power source, their energy consumption is typically negligible. Therefore, the energy consumption of tasks offloaded to cloud servers includes only the energy consumed by mobile devices while they are idle and awaiting processing. Definition The energy consumed during the waiting period is calculated using the following formula:

[0145]

[0146] in Power of mobile device i in idle state.

[0147] Quality of User Experience (QoE) reflects a measure of user satisfaction and is closely related to task success and processing costs. This is based on the local unloading decision in the aforementioned model analysis. Local task execution completion time interval and energy consumption Edge server offloading decision Time interval for task completion Transmission power consumption Server power consumption and device standby power consumption Cloud server uninstallation decision Time interval for task completion Transmission power consumption device standby power consumption Use T i (t) and E i (t) represents the total time interval and total energy consumption consumed in processing the task, respectively. Then we have:

[0148]

[0149] Since each user has different preferences, a weighting factor α is introduced to balance the time and energy consumption required for task processing. i (t). This factor is used to balance user preferences for latency and energy consumption. (Using cost...) i (t) represents the total cost for user i to process tasks, which can be expressed as:

[0150] cost i (t)=α i (t)T i (t)+(1-α i (t))E i (t) (32)

[0151] Finally, let z i (t) represents the Quality of Experience (QoE) for user i; the lower the processing cost, the higher the QoE. Furthermore, the system model expects the task to be completed within the maximum tolerable latency. If the task is successfully completed before the deadline, a reward ε will be awarded, where ε is a constant greater than the processing cost. Therefore, QoE can be defined as:

[0152]

[0153] The optimization objective is:

[0154]

[0155] st

[0156]

[0157] C3:

[0158] C4:T i (t)≤T max

[0159] C5:Eq.(17),(18),(26),(27) (34)

[0160] Where T is the total number of time slots and I is the total number of users. Constraint C1 indicates that the task execution mode of mobile device i can be selected from three options: local, MEC server, and cloud server. Constraint C2 indicates that each mobile device i can only select one execution mode. Constraints C3 and C4 stipulate that for each task, the local execution latency, transmission latency, MEC server execution latency, cloud server execution latency, and total processing latency must all be less than the maximum tolerable time of the task. Equations (17), (18), (26), and (27) in constraint C5 indicate that sufficient computing resources are allocated to the task.

[0161] Example 7:

[0162] In one embodiment, minimizing the total cost of task processing and ensuring that the task is completed before the maximum tolerable latency to optimize user experience quality includes:

[0163] User experience quality is defined as follows: if the task is successfully completed within the maximum tolerable latency, the user experience quality is equal to the reward constant minus the total task processing cost; otherwise, the user experience quality is equal to the negative total task processing cost.

[0164] The unloading strategy is optimized by using a deep recurrent Q-network algorithm to maximize the expected quality of user experience.

[0165] Example 8:

[0166] In one embodiment, determining the distributed offloading strategy using a deep recurrent Q-network algorithm includes:

[0167] Construct a state space, which includes the local queue status of the mobile device, the channel status, the task attributes, the fault status and queue status information of the edge server, and the queue status of the cloud server.

[0168] Construct an action space, which corresponds to the selection of the unloading strategy;

[0169] Define a reward function based on user experience quality;

[0170] Deploy a DRQN ​​agent on each mobile device to select actions based on locally observed state information;

[0171] The DRQN ​​agent is trained using reinforcement learning to learn the optimal offloading strategy.

[0172] Example 9:

[0173] In one embodiment, the fault-tolerant and task offloading method in an edge-cloud collaborative environment further includes:

[0174] Real-time monitoring of task execution status, edge server failure events, and system performance metrics;

[0175] Based on the monitored historical data, adjust the parameters of the fault-tolerant technology and / or the training parameters of the deep recurrent Q-network algorithm.

[0176] Figure 3 The figure shows a comparison of the convergence performance of the proposed algorithm with three other distributed deep reinforcement learning (DRL) schemes under the condition of 20 mobile devices (MDs). As shown in the figure, all four algorithms can learn effective policies through continuous interaction with the simulation environment and eventually achieve stable convergence. Among them, the schemes based on IDDQN and IPPO show faster convergence speeds, stabilizing around 500 rounds. In contrast, the FTTO scheme based on the distributed DRQN ​​algorithm and the scheme based on the IDDQN algorithm begin to converge around 750 rounds and then tend to stabilize. Furthermore, although the IDDQN and IPPO methods have excellent convergence speeds, their terms of final average reward are significantly lower than those of the FTTO scheme. Specifically, the average reward values ​​of IDDQN, IPPO, and IDDQN fluctuate around 24.1, 26.9, and 28.2 after convergence, respectively, while the proposed FTTO method achieves a higher reward value, fluctuating around 29.2.

[0177] Example 10:

[0178] In one embodiment, the method is applied to scenarios that are sensitive to latency and require high reliability, including real-time health monitoring, online gaming, or social networking.

[0179] Example 11:

[0180] In one embodiment, fault-tolerant techniques are employed for fault recovery and dynamic adjustment of the execution strategy of affected tasks, specifically including:

[0181] When a failure is detected on an edge server computing node, the checkpoint fault tolerance mechanism for the affected tasks deployed on that node is immediately activated; this mechanism utilizes checkpoint status information and task context data that are periodically saved during task execution.

[0182] The system selects the optimal target recovery node from the available edge server computing node resource pool based on the current load, network distance from the faulty node, and the ability to meet the remaining computing needs of the affected tasks and the maximum tolerable latency.

[0183] Quickly migrate the status and context data of the most recent valid checkpoint of the affected task to the selected target recovery node;

[0184] On the target recovery node, resume task execution from the saved checkpoint state;

[0185] Based on the new state after task migration recovery (including: remaining required CPU cycles, remaining data volume, estimated execution time on the new node after migration, additional network latency and energy consumption caused by migration, and remaining maximum tolerable latency window);

[0186] Combine the updated edge server node availability status (failed nodes are offline, target recovery nodes have increased load) with the total task processing cost model;

[0187] Using the deep recurrent Q-network algorithm, the optimal distributed offloading strategy is recalculated for each affected task; the offloading strategy options include:

[0188] Continue execution on the current target recovery node;

[0189] Migrate to other available edge nodes for execution (if better);

[0190] Migrate back to the mobile device for local execution (if the remaining computing power is small and local resources allow);

[0191] Unload to a cloud server for execution (as a last resort, especially when edge resources are scarce or the remaining latency window is extremely small);

[0192] Based on the recalculated optimal unloading strategy, the execution path of the affected tasks is switched in real time;

[0193] Ensure that tasks are completed within the remaining maximum tolerable latency, and minimize the additional total task processing cost (latency + energy consumption) caused by fault recovery and policy adjustments.

[0194] The scheme first uses a deep recurrent Q-network algorithm to comprehensively consider task characteristics (data volume, computational requirements, latency constraints), edge node reliability (expected fault recovery time), and execution cost (weighted sum of latency and energy consumption) to generate an initial distributed offloading decision (local, edge, or cloud execution) for each mobile device task.

[0195] During task execution, the system continuously monitors the status of edge nodes; once a node failure is detected, the pre-set checkpoint fault tolerance mechanism is immediately activated, and the affected task is quickly migrated to the selected optimal available edge recovery node to resume operation using the recently saved task status and context data.

[0196] Subsequently, the core dynamic adjustment mechanism is activated: based on the remaining computational load, remaining tolerable latency, new node environment, and updated global resource view of the migrated task, the system again calls the deep recurrent Q network algorithm to recalculate the optimal unloading strategy for the affected task in real time (which can be continued on the recovery node, migrated to other edge nodes, rolled back locally, or unloaded to the cloud), and immediately switches the execution path to ensure that the task is completed within the remaining time limit, while minimizing the additional total cost brought about by fault recovery and strategy adjustment, thereby achieving high fault tolerance, strong adaptability, and continuous cost optimization in the edge-cloud collaborative environment.

[0197] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A fault-tolerant and cloud-based task offloading method in an edge-cloud collaborative environment, characterized in that, include: Receive tasks generated by multiple mobile devices, each task including data size, required number of CPU cycles, and maximum tolerable latency; Based on the expected value of fault recovery time and the total cost model of task processing of edge server computing nodes, a distributed offloading strategy for tasks is independently determined for each mobile device using the deep recurrent Q network algorithm. The offloading strategy includes: executing the task locally on the mobile device, offloading to the edge server for execution, or offloading to the cloud server for execution. During task execution, monitor whether the edge server computing nodes fail. When a failure is detected in an edge server computing node, fault-tolerant technology is used for fault recovery. Based on the fault recovery status, the execution strategy of the affected tasks is dynamically adjusted to ensure that the tasks are completed before the maximum tolerable delay and to minimize the total task processing cost, which is the weighted sum of task execution delay and energy consumption. The expected value of the fault recovery time is calculated based on a model in which the occurrence of edge server faults follows a Poisson distribution and the fault repair time follows an exponential distribution.

2. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, Fault recovery using fault-tolerant techniques includes: Rollback technology is used to allow tasks to continue execution from the state before the failure after the failure is recovered.

3. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, Performing tasks locally on a mobile device includes: Add the task to the local computing queue of the mobile device; The waiting time of the computation task in the local computation queue and the processing time on the local device; Based on the waiting time, processing time, and energy consumption parameters of the mobile device, calculate the energy consumption required for the task to be executed locally and the total cost of task processing.

4. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, Offloading tasks to edge servers or cloud servers for execution includes: Transmit the task from the mobile device to the base station, and calculate the transmission latency and energy consumption required for the task transmission. According to the offloading strategy, tasks are allocated from the base station to the edge server computing queue or forwarded to the cloud server computing queue through the core network.

5. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, Performing tasks on the edge server includes: Add the task to the compute queue allocated to the mobile device on the edge server; Considering the potential failures of edge server computing nodes and their expected recovery time, the expected time slot for the computing task to begin processing on the edge server, the expected processing latency, and the expected execution energy consumption are as follows: Update the status of the edge server computing queue, including queue length and information on dropped tasks.

6. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, Performing tasks on a cloud server includes: Add the task to the computing queue allocated to the mobile device on the cloud server; The time slot, processing latency, and execution energy consumption of the computing task when it begins processing on the cloud server; Update the status of the cloud server computing queue, including queue length and information on dropped tasks; Calculate the idle power consumption of mobile devices while tasks are waiting to be processed by the cloud server.

7. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, Minimizing the total cost of task processing and ensuring task completion before the maximum tolerable latency to optimize user experience quality includes: User experience quality is defined as follows: if the task is successfully completed within the maximum tolerable latency, the user experience quality is equal to the reward constant minus the total task processing cost; otherwise, the user experience quality is equal to the negative total task processing cost. The unloading strategy is optimized by using a deep recurrent Q-network algorithm to maximize the expected quality of user experience.

8. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, The distributed offloading strategy determined using the deep recurrent Q-network algorithm includes: Construct a state space, which includes the local queue state of the mobile device, the channel state, the task attributes, the edge server fault state, and the queue state information. Construct an action space, which corresponds to the selection of the unloading strategy; Define a reward function based on user experience quality; Deploy a DRQN ​​agent on each mobile device to select actions based on locally observed state information; The DRQN ​​agent is trained using reinforcement learning to learn the optimal offloading strategy.

9. The fault-tolerant and cloud-based collaborative task offloading method as described in claim 1, characterized in that, Also includes: Real-time monitoring of task execution status, edge server failure events, and system performance metrics; Based on the monitored historical data, adjust the parameters of the fault-tolerant technology and / or the training parameters of the deep recurrent Q-network algorithm.

10. The fault-tolerant, cloud-based collaborative task offloading method as described in any one of claims 1-9, characterized in that, The method is applicable to scenarios that are sensitive to latency and require high reliability, including real-time health monitoring, online games, or social networks.

Images