Task-aware migration-based dynamic allocation method for cloud edge-end cooperative computing resources

Abstract

The invention relates to the technical field of cloud side end computing, and discloses a cloud side end cooperative computing resource dynamic allocation method based on task-aware migration. The method comprises the following steps: acquiring real-time load characteristics and resource demand characteristics of calculation tasks in a cloud side end system, and dividing task priority queues in combination with task type identifiers; extracting historical execution records of tasks at cloud, edges and terminal nodes, constructing a task execution feature library, and generating a resource demand prediction model in combination with real-time load features; analyzing network transmission time delay characteristics of a cloud end and edge nodes, measuring real-time calculation capability fluctuation data of terminal equipment, and establishing an inter-node resource collaboration degree evaluation matrix; generating an initial migration strategy according to the prediction model and the evaluation matrix, monitoring actual resource occupancy deviation of the task, forming a final decision in combination with a node resource state correction strategy, triggering cross-node migration, and synchronously updating the priority queue and the evaluation matrix.

Description

Technical Field

[0001] This invention relates to the field of cloud-edge-device computing technology, specifically a method for dynamic allocation of cloud-edge-device collaborative computing resources based on task-aware migration. Background Technology

[0002] With the rapid development of technologies such as the Internet of Things (IoT) and artificial intelligence (AI), the number of terminal devices is exploding, and various computing tasks, such as data acquisition, real-time analysis, and intelligent control, are constantly emerging, leading to increasingly diversified demands for computing resources. Traditional cloud-based centralized computing, while possessing powerful computing capabilities, has significant limitations when facing the real-time data processing needs generated by massive numbers of terminal devices. Long-distance data transmission between terminal devices and the cloud is easily affected by factors such as network bandwidth and transmission distance, resulting in increased data transmission latency and making it difficult to meet the latency-sensitive requirements of tasks such as industrial control and autonomous driving.

[0003] To address this issue, edge computing technology has emerged, offloading some computing tasks to edge nodes closer to terminal devices, effectively shortening data transmission distances and reducing latency. However, edge nodes typically have limited computing resources, and resource configurations vary between different edge nodes. Furthermore, the computing power of terminal devices fluctuates depending on factors such as device model, operating status, and battery level. Relying solely on edge nodes or terminal devices makes it difficult to meet the complex and ever-changing demands of computing tasks.

[0004] Against this backdrop, cloud-edge-device collaborative computing architecture has gradually become a research hotspot. It optimizes the allocation of computing resources by integrating the massive computing power of the cloud, the near-field advantages of edge nodes, and the local processing capabilities of terminal devices. However, current cloud-edge-device collaborative computing resource allocation methods still have many shortcomings. Most methods fail to fully consider the real-time load characteristics and resource requirements of computing tasks when allocating resources, relying solely on task submission order or fixed rules. This leads to high-priority tasks potentially being delayed due to insufficient resources, while low-priority tasks consume excessive resources, resulting in waste.

[0005] Existing methods lack in-depth analysis of task execution characteristics and effective utilization of historical execution records, making it difficult to accurately predict resource requirements at different nodes and thus affecting the rationality of resource allocation. Regarding inter-node collaboration, most methods simply consider the computing power of nodes, neglecting factors such as network transmission latency variations between cloud and edge nodes, connection stability between edge nodes and terminal devices, and resource complementarity between different nodes. This results in an imperfect node collaboration mechanism that fails to achieve efficient collaborative resource utilization.

[0006] Current resource allocation strategies are mostly static. During task execution, if the node resource status changes, such as a sudden failure of an edge node, a sharp drop in the computing power of a terminal device, or a large deviation between the actual resource utilization rate of the task and the predicted value, the resource allocation scheme cannot be adjusted in time. This can easily lead to problems such as task execution interruption and decreased resource utilization, which seriously affects the overall performance of the cloud-edge-device collaborative computing system. Summary of the Invention

[0007] The purpose of this invention is to provide a dynamic allocation method for cloud-edge-device collaborative computing resources based on task-aware migration, so as to solve the problems mentioned in the background art.

[0008] To achieve the above objectives, this invention provides a method for dynamic allocation of cloud-edge-device collaborative computing resources based on task-aware migration, the method comprising: Obtain the real-time load characteristics and resource requirement characteristics of computing tasks in the cloud-edge-device system, and divide the task priority queue according to the task type identifier of the computing task; Extract historical execution records of computing tasks on cloud nodes, edge nodes, and terminal devices, construct a task execution feature library, and generate a resource demand prediction model by combining real-time load characteristics. Analyze the network transmission latency characteristics between cloud nodes and edge nodes, measure the real-time computing power fluctuation data of terminal devices, and establish a resource synergy evaluation matrix between nodes; Based on the resource demand prediction model and the resource synergy evaluation matrix, an initial migration strategy for computing tasks in the cloud-edge-device three-layer architecture is generated. By monitoring the deviation between the actual resource utilization rate of the computing task and the predicted value, and combining the characteristics of resource status changes between nodes, the initial migration strategy is dynamically revised to form the final migration decision. The cross-node migration operation of the computing task is triggered based on the final migration decision, and the task priority queue and resource synergy evaluation matrix are updated synchronously.

[0009] Preferably, obtaining the real-time load characteristics and resource requirement characteristics of computing tasks in the cloud-edge-device system includes: Identify the computational task type identifier corresponding to the computationally intensive or latency-sensitive characteristics; Collect peak CPU utilization data, memory usage fluctuation data, and baseline network bandwidth requirements of computing tasks within a preset time window; The peak CPU utilization data and memory usage fluctuation data are normalized to generate a real-time load feature vector for the computing task. Resource requirement feature labels are generated by overlaying task type identifiers onto the baseline of network bandwidth requirements.

[0010] Preferably, the construction of the task execution feature library includes: Extract the average response latency data of computing tasks on cloud nodes, the task interruption frequency data on edge nodes, and the energy consumption curve of terminal devices from historical execution records; The average response latency data and the task interruption frequency data are time-aligned to form a task execution stability feature set. The energy consumption curve is segmented and integrated to generate a set of energy efficiency characteristics for terminal devices. By integrating the task execution stability feature set and the terminal device energy efficiency feature set, a multi-dimensional task execution feature library is constructed.

[0011] Preferably, the establishment of the inter-node resource synergy evaluation matrix includes: Measure round-trip time jitter data in the network transmission latency characteristics from cloud nodes to edge nodes; Collect data on the number of times the CPU frequency drops and the threshold of available memory capacity of the terminal device during task execution; The round-trip time jitter data is weighted and aggregated with the number of times the CPU frequency is reduced to generate a communication quality score between nodes. The communication quality score is revised based on the available memory capacity threshold data to form an initial version of the resource synergy evaluation matrix.

[0012] Preferably, the initial migration strategy for the generated computing task in the cloud-edge-device three-layer architecture includes: Compare the predicted resource demand output by the resource demand forecasting model with the available resource quantity of each node in the resource synergy evaluation matrix; When the predicted resource demand exceeds the available resources on the edge node, the computing task is marked as a candidate task for cloud migration. When the predicted resource demand is lower than the real-time computing power of the terminal device, the computing task is marked as a candidate task for local execution. By combining the priority queue order of candidate migration tasks in the cloud and candidate execution tasks in the local environment, an initial migration strategy with weighted identifiers is generated.

[0013] Preferably, the dynamic modification of the initial migration strategy to form the final migration decision includes: Obtain the absolute value of the difference between the actual CPU utilization and the predicted CPU utilization of the computing task during the migration process; Monitor the incremental memory usage data of edge nodes during task migration; When the absolute value of the difference exceeds the preset threshold and the incremental data of memory usage continues to grow, the migration strategy correction condition is triggered. Based on the revised conditions, some cloud migration candidate tasks are reassigned to idle terminal devices to form the final migration decision.

[0014] Preferably, the cross-node migration operation triggered by the final migration decision includes: Based on the weight identifiers of the candidate cloud migration tasks in the final migration decision, a batch migration instruction sequence is generated; For candidate tasks to be executed locally, send resource reservation instructions to the terminal device and receive confirmation feedback from the device; During the execution of the migration instruction sequence, real-time data on changes in bandwidth utilization of edge nodes is collected; When the bandwidth utilization change data reaches a critical value, subsequent migration instructions are paused and the system waits for a resource release signal.

[0015] Preferably, the synchronization update task priority queue includes: Record the actual execution latency data and energy consumption reduction rate of the computing tasks that have completed the migration operation; Adjust the sorting weight of similar computing tasks in the priority queue based on actual execution latency data; The benchmark energy consumption reference value of the terminal equipment energy efficiency feature set is corrected based on the energy consumption reduction ratio; The updated sorting weights and baseline energy consumption reference values ​​will be written into the new version of the task execution feature library.

[0016] Preferably, the updated resource synergy evaluation matrix includes: The average load decrease of edge nodes and the percentage of remaining resources of cloud nodes were calculated after the migration operation was completed. The latency jitter weighting coefficient in the inter-node communication quality score is recalculated based on the average load drop rate. Replace the initial available resource data in the resource synergy evaluation matrix with the percentage of remaining resources. Generate an evaluation matrix update log containing the latest latency jitter weighting coefficients and available resource quantities.

[0017] Preferably, the method further includes: Establish a migration strategy backtracking index in the task execution feature library, and associate the version numbers of the initial migration strategy with the final migration decision; When a change in the task type identifier of a computing task is detected, a historical strategy comparison and verification process is triggered based on the backtracking index. The comparative verification process outputs strategy correction suggestions and automatically updates them to the training dataset of the resource demand prediction model.

[0018] Compared with the prior art, the beneficial effects of the present invention are: In the task prioritization stage, this method acquires the real-time load and resource requirement characteristics of computing tasks and divides task priority queues based on task type identifiers, enabling differentiated treatment of computing tasks with different needs. High-priority tasks that are latency-sensitive and involve large amounts of data can receive priority resource support, avoiding execution delays caused by resource contention. For ordinary tasks with lower resource requirements, resources are allocated rationally based on actual conditions, reducing resource idleness and waste, making the overall system's task execution order more rational, and significantly improving the matching degree between resource allocation and task requirements.

[0019] In terms of resource demand prediction, this method extracts historical execution records of computing tasks on cloud nodes, edge nodes, and terminal devices to construct a task execution feature library, and generates a resource demand prediction model by combining real-time load characteristics. Through in-depth mining of historical data, it is possible to fully understand the resource consumption patterns of different types of tasks on different nodes. Combined with real-time load conditions, it is possible to more accurately predict the amount of resources required for task execution on each node, providing a scientific basis for subsequent resource allocation and avoiding over-allocation or under-allocation of resources due to inaccurate resource prediction, making resource allocation more forward-looking and rational.

[0020] In evaluating inter-node resource collaboration, this method analyzes the network transmission latency characteristics between cloud nodes and edge nodes, measures real-time computing power fluctuations of terminal devices, and establishes an inter-node resource collaboration evaluation matrix. This design breaks away from the limitations of traditional methods that only focus on node computing power, comprehensively considering key factors affecting node collaboration such as network transmission performance and terminal device status. Through the resource collaboration evaluation matrix, the collaborative capabilities of different node combinations can be clearly understood, such as which node combinations are more advantageous in terms of transmission latency and complementary computing power. This allows for the selection of the node combination with the best collaborative effect during task allocation, achieving efficient integration of resources across the cloud-edge-device three-layer architecture and improving the overall system's collaborative computing capabilities.

[0021] In the migration strategy generation and dynamic correction phase, this method generates an initial migration strategy based on a resource demand prediction model and a resource synergy evaluation matrix. Simultaneously, it monitors the deviation between the actual resource occupancy rate and the predicted value, and dynamically corrects the strategy based on the characteristics of node resource status changes. The initial migration strategy ensures the initial rationality of task allocation, while the dynamic correction mechanism can cope with various changes during task execution. When there is a significant deviation between the actual resource consumption and the prediction, or when nodes experience resource fluctuations or failures, the migration strategy can be adjusted promptly to ensure that the task always executes in an optimal resource environment, avoiding task interruption or efficiency degradation, and improving the stability and reliability of task execution.

[0022] This method synchronously updates the task priority queue and resource synergy evaluation matrix after triggering a cross-node migration operation for a computing task. This dynamic update mechanism ensures that task priority information and node synergy information are always up-to-date, providing accurate data support for resource allocation and migration strategy formulation for subsequent new tasks, forming a virtuous cycle. Whether a new task is added or the status of an existing task changes, the system can respond quickly based on the latest information, continuously optimize resource allocation schemes, and further improve the resource utilization and task processing efficiency of the cloud-edge-device collaborative computing system. It is applicable to various scenarios such as industrial control, intelligent transportation, and smart homes, and has broad application value. Attached Figure Description

[0023] Figure 1 This is a schematic diagram illustrating the working principle of the cloud-edge-device collaborative computing resource dynamic allocation method based on task-aware migration described in this invention. Figure 2 A flowchart for extracting real-time load and resource demand characteristics; Figure 3 A flowchart for constructing the resource synergy evaluation matrix between nodes. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Please see Figure 1This invention provides a method for dynamic allocation of cloud-edge-device collaborative computing resources based on task-aware migration. The method includes: continuously collecting real-time operational data of computing tasks through a monitoring module in the cloud-edge-device system. Real-time load characteristics include peak CPU utilization and memory usage fluctuations, while resource demand characteristics involve baseline network bandwidth requirements and task type identifiers. The system divides computing tasks into different priority queues based on task type identifiers, such as compute-intensive or latency-sensitive tasks, allocating resources to higher-priority tasks first. Subsequently, task execution records are extracted from historical logs of cloud nodes, edge nodes, and terminal devices to construct a task execution feature library. This feature library integrates indicators such as average response latency and task interruption frequency, and trains a resource demand prediction model based on real-time load characteristics. This model uses machine learning algorithms such as regression analysis to predict future resource demands. Simultaneously, the system measures network transmission latency characteristics between cloud nodes and edge nodes, including round-trip latency jitter, and monitors real-time computing power fluctuations of terminal devices, such as CPU frequency changes. Based on these data, a resource synergy evaluation matrix is ​​established, which quantifies the communication quality and resource availability between nodes. Based on the output of the resource demand prediction model and the resource synergy evaluation matrix, the system generates an initial migration strategy, which identifies which computing tasks are suitable for migration to the cloud or local execution. During strategy execution, the system monitors the deviation between the actual resource utilization and the predicted value in real time, and dynamically adjusts the initial migration strategy based on changes in node resource status, such as memory usage increments, to form the final migration decision. The final migration decision triggers cross-node migration operations for computing tasks. During the migration process, the system synchronously updates the task priority queue order and the data in the resource synergy evaluation matrix to ensure continuous optimization of resource allocation.

[0026] Example 1: See Figure 2The system acquires real-time load and resource requirement characteristics of computing tasks in cloud-edge-device systems. This process begins with a deep identification of the inherent attributes of the computing tasks. The system identifies the task type by parsing the metadata tags attached to the task submission. This identifier clearly distinguishes whether the task is compute-intensive or latency-sensitive. Compute-intensive tasks typically require continuous and high-intensity processor computing power, such as large-scale scientific computing or batch data processing, while latency-sensitive tasks have strict constraints on response time, such as real-time video analysis or interactive control commands. Within a preset time window, such as a sliding window of 5 minutes, the system continuously collects peak CPU utilization data generated during the execution of computing tasks. This data is acquired in real time through performance counters provided by the operating system kernel, recording the highest proportion of processor resources used by the task within the window period. Simultaneously, memory usage fluctuation data is also collected, reflecting the dynamic changes in the working set size during task execution. The fluctuation amplitude is quantified by monitoring the rate of memory page allocation and release. The network bandwidth requirement baseline is derived from the historical communication patterns of the task. The system analyzes the rate at which the task sends and receives data packets via the network interface during past execution cycles, and calculates a representative average bandwidth requirement value. The collected peak CPU utilization data and memory usage fluctuation data, due to differences in their original dimensions and numerical ranges, require normalization to eliminate scaling effects. The processing employs a min-max scaling method to linearly transform the original values ​​to the [0,1] interval, thereby generating a structured real-time load feature vector. This vector, as a multi-dimensional numerical point, comprehensively characterizes the resource consumption intensity of the task at the current moment. The generation of resource requirement feature labels is an information fusion step. The system overlays the calculated network bandwidth requirement baseline with the task type identifier. For example, a high-bandwidth task identified as latency-sensitive will be assigned a feature label, which will be used for rapid matching and classification of subsequent resource allocation strategies.

[0027] Building a task execution feature library is a process that relies on the accumulation and fine processing of historical data. The system extracts the average response latency data of computing tasks in the cloud data center from persistently stored historical logs. This data is obtained by calculating the average length of time from when the task request is received by the cloud scheduler to when the final result is returned, reflecting the stability of cloud processing capabilities. At the same time, the system extracts task interruption frequency data when the same task is executed on edge nodes. This frequency counts the number of abnormal task terminations caused by insufficient node resources, network interruptions, etc., revealing the reliability challenges of the edge environment. At the terminal device level, the system collects the energy consumption curve of the entire task execution cycle. This curve is obtained through the device's built-in power consumption sensors or model estimation, recording the instantaneous power consumption changes from the start to the end of the task. To perform effective correlation analysis, average response latency data and task interruption frequency data need to undergo time-series alignment. The system uses task identifiers and execution timestamps as association keys to match and synchronize data entries scattered across different log sources and time points. This ensures that latency and interruption data from the same task instance correspond precisely on the time axis. After alignment, a task execution stability feature set is formed, which includes reliability measures of the task at different execution positions with respect to the time dimension. The processing of energy consumption curves focuses on the energy accumulation effect. The system performs piecewise integration on the continuous power consumption curve, dividing the task execution duration into several equally or unequally spaced time periods. The power consumption value within each time period is integrated to calculate the total energy consumption for that period, thereby generating a terminal device energy efficiency feature set. This feature set reveals the impact pattern of task execution on device battery life or energy efficiency. Ultimately, the task execution stability feature set and the terminal device energy efficiency feature set are integrated together through data fusion technology to form a multi-dimensional task execution feature library. This feature library not only records the details of "how to do" the task, but also contains the contextual information of "under what conditions" the task is executed, providing rich training materials for subsequent prediction models.

[0028] The construction of the task execution feature library is not a one-time event, but a dynamic process requiring continuous maintenance and updates. The system periodically scans new task execution records, extracts fresh data such as average response latency and task interruption frequency, and performs the same time-series alignment and segmented integration processing as historical data on this new data. This process generates new feature subsets. These newly generated feature subsets do not directly overwrite existing data in the feature library; instead, they are incrementally incorporated into the feature library through a versioning management mechanism. The system evaluates the consistency between the new and historical data and progressively updates the statistics (such as mean and variance) in the feature library. This mechanism allows the task execution feature library to evolve over time, gradually reflecting the system's current operational status. During the feature library update process, the system also needs to handle data inconsistencies or conflicts, such as significant differences in the performance of the same task across different executions. In such cases, a data quality assessment step is introduced to detect and smooth out outliers, or to add confidence labels to conflicting data, ensuring the validity and reliability of the data in the feature library. Through continuous updates and maintenance, the task execution feature library has become a knowledge base that can accurately reflect the historical task execution performance of cloud-edge-device systems, providing a solid data foundation for resource demand prediction models.

[0029] The generation of real-time load feature vectors and the construction of the task execution feature library are two closely coupled processes. Newly generated real-time load feature vectors are matched against historical features stored in the feature library to find historical task execution records with similar load characteristics. This matching operation helps the system quickly identify possible execution patterns or potential risks. The matching process is typically based on a vector space model, calculating the distance between the real-time load feature vector and historical feature vectors in the feature library in a multi-dimensional space. The execution results (such as actual resource consumption and whether an interruption occurred) corresponding to the closest historical record can provide valuable references for resource prediction of the current task. This rapid retrieval mechanism based on historical similarity enhances the system's ability to handle unknown tasks or sudden loads, enabling it to make relatively reasonable preliminary judgments even in the absence of sufficient prior knowledge. This provides crucial contextual information support for subsequently generating more accurate resource demand prediction models.

[0030] Accurate task type identification is fundamental to the entire process. The system requires a reliable identification resolution mechanism. This mechanism may be based on predefined fields in the task description file, or it may automatically infer the type by analyzing the resource access patterns or system call sequences of the task code. Automatic inference mechanisms are typically more complex but more adaptable, as they do not rely on manual user annotation. When inferring the task type, the system monitors the resource usage patterns during the initial execution phase of the task. For example, if a task immediately initiates a large number of floating-point operations with few I / O operations after startup, it is likely to be identified as computationally intensive; conversely, if a task frequently engages in network communication and is sensitive to clock interrupts, it may be identified as latency-sensitive. Accurate identification points the way for subsequent feature processing and behavior prediction, serving as the starting point for the entire dynamic resource allocation logic chain.

[0031] Example 2: See Figure 3The establishment of an inter-node resource synergy evaluation matrix begins with precise measurement of network transmission channel performance. The system measures network transmission latency characteristics from cloud nodes to edge nodes by continuously sending a series of standardized probe packets to the target edge nodes, paying particular attention to round-trip latency jitter data. These probe packets are sent at fixed intervals, and the time difference between the sending time of each packet and the time of receiving the acknowledgment response is recorded, thereby calculating a series of round-trip latency samples. The calculation of jitter data does not simply rely on the average value, but analyzes the variance of the differences between these consecutive latency samples, quantifying the stability of the transmission path through statistical methods. High jitter variance usually indicates network congestion or routing instability. At the same time, the system delves into the terminal device to collect the number of times the CPU clock frequency is reduced during task execution. This data is obtained by reading the change log of the processor performance status register, recording events of passive degradation of computing power caused by excessive temperature or activation of power management policies. The memory available capacity threshold data is obtained by monitoring the operating system's memory management module, which indicates the lower limit of memory that can be safely used by the task without excessively affecting other processes in the system. Weighted aggregation of round-trip latency jitter data and CPU frequency throttling counts is a process of assigning different importance to different metrics. The system assigns a weight coefficient to latency jitter (e.g., 0.7) and another weight coefficient to CPU frequency throttling counts (e.g., 0.3) based on a predefined policy file. Weighted aggregation is not a simple addition; instead, it multiplies the normalized value of each metric by its weight and then sums the results to generate a comprehensive inter-node communication quality score. This score initially characterizes the reliability of the data transmission path and the computational stability of the terminal device, but it does not yet consider the real-time constraints of memory resources. Therefore, the score needs to be corrected based on available memory capacity threshold data. The correction logic is typically expressed as a conditional function. If the real-time available memory of the device is detected to be lower than its set safety threshold, a discount factor is applied to the communication quality score, for example, multiplying the score by 0.8, to reflect the potential risks posed by memory bottlenecks. After correction, an initial version of the resource synergy evaluation matrix is ​​formed. This matrix stores the synergy values ​​between cloud nodes, multiple edge nodes, and terminal devices in a data structure.

[0032] The initial migration strategy for generating computing tasks in the cloud-edge-device three-layer architecture relies on the output results of the prior model and matrix. The system first performs a comparison operation, comparing the predicted resource requirements output by the resource demand prediction model for a specific computing task with the current available resources of each node recorded in the resource synergy evaluation matrix. The predicted resource requirements typically include the number of CPU cores, memory size, and bandwidth estimates, while the available resources of a node are dynamic values ​​obtained in real time from the resource monitor. The comparison process generates a judgment on resource sufficiency or scarcity. When the system finds that the predicted resource requirements of a computing task consistently exceed the available resources of the target edge node at the current moment, it marks the task as a candidate task for cloud migration. This marking means that, from a resource capacity perspective, the task is more suitable to be scheduled for execution in a cloud data center with a larger resource pool. Conversely, when the system identifies that the predicted resource requirements of a task are significantly lower than the real-time computing capabilities reported by the terminal device that initiated the task, it marks the task as a candidate task for local execution. This indicates that processing the task locally on the device can avoid unnecessary network transmission overhead. The generation of the initial migration strategy requires comprehensive consideration of the above-mentioned labeling results and the order of the task priority queue. The system scans the entire task queue, identifies all tasks marked as cloud migration candidates and local execution candidates, and then sorts these candidate tasks according to the inherent priority order of the queue. High-priority tasks (such as latency-sensitive tasks) will receive priority scheduling rights. Based on the sorting, the system assigns a weight identifier to each candidate task. This weight identifier is a quantified value, which may be calculated by the task's priority level, the ratio of the predicted resource demand to the node's available resources, and the corresponding node's coordination score in the resource coordination evaluation matrix. A higher weight identifier usually indicates a higher urgency of migration. The final generated initial migration strategy is a structured decision list, which clearly specifies the suggested execution location (cloud, edge, or terminal) for each candidate task, the planned migration batch, and its associated weight identifier, providing a clear action plan for subsequent dynamic adjustments.

[0033] The initial version of the resource synergy evaluation matrix is ​​not a static snapshot but a continuously updated view. The system periodically re-executes network measurement and terminal device data acquisition processes, recalculating the inter-node communication quality score using newly acquired round-trip latency jitter data and CPU frequency throttling counts, and correcting it with the latest available memory capacity threshold data. This update mechanism allows the evaluation matrix to reflect the dynamic changes in network conditions and device status between nodes in near real-time. For example, when a network traffic surge causes increased latency jitter, the synergy score of the corresponding node pair will decrease in the next update cycle. This dynamism provides a data foundation for the adaptability of migration strategies. The matrix update frequency is a configurable parameter that needs to be balanced between timely reflection of changes and avoiding excessive measurement overhead.

[0034] The initial migration strategy generation process also includes conflict detection and resolution logic. When the system detects multiple high-weight cloud migration candidate tasks simultaneously competing for limited cloud egress bandwidth, or when the available resources of an edge node are at a critical level, leading to ambiguity in migration decisions, the conflict resolution mechanism is activated. This mechanism may introduce finer-grained rules, such as prioritizing the migration of tasks with higher computational density (more computational operations per unit of data) to reduce network load, or initiating a short-term exploratory execution phase for tasks at a critical level, making a final migration decision based on their actual resource consumption. This logic ensures the rationality of the initial strategy in complex scenarios. The weighted aggregation of inter-node communication quality scores may also be an adaptive process. The system may fine-tune the weighting of latency jitter and CPU throttling based on the success rate of historical migration decisions. For example, if historical data shows that CPU throttling has a higher weighting on task failures than expected, the system may appropriately increase its weighting in the next configuration cycle. This self-adjusting mechanism allows the evaluation model to gradually adapt to the actual characteristics of a specific deployment environment. The final generated initial migration strategy with weighted identifiers is passed to the strategy execution engine in the form of a task list. This list not only includes migration direction suggestions, but may also include time window hints and rollback condition descriptions. This rich strategy information provides sufficient basis and flexibility for subsequent dynamic corrections and final decision execution.

[0035] Example 3: The process of dynamically revising the initial migration strategy to form the final migration decision is a closed-loop control process based on real-time feedback. Immediately after the initial migration strategy begins execution, the system starts a monitoring program. This program continuously acquires the actual CPU utilization data of the computing task during the migration process. This data is obtained through a performance acquisition agent deployed on the target node at a high frequency (e.g., once per second). Simultaneously, the system calls the resource requirement prediction model to review the previously predicted CPU utilization value for the task and calculates the absolute value of the difference between the two. This absolute value directly reflects the instantaneous accuracy of the prediction model. Monitoring the incremental memory usage data of edge nodes during task migration is another parallel key activity. The system records the baseline memory usage of the edge nodes before the migration operation begins and continuously tracks the difference between the current usage and the baseline value during the migration process, thereby obtaining the net increase in memory usage directly or indirectly caused by this migration. The system has a pre-defined set of configurable thresholds, which includes thresholds for the absolute value of the difference in CPU utilization and judgment conditions for the continuous growth trend of memory usage increment. When the system detects that the absolute value of the difference in CPU utilization of a certain task exceeds the threshold of its corresponding type (for example, the threshold for compute-intensive tasks is set to 15%), and the memory usage increment data of the associated edge node shows a monotonically increasing trend over several consecutive monitoring periods, it determines that the migration strategy correction conditions are met and triggers the corresponding correction logic.

[0036] Upon triggering the correction conditions, the system does not immediately reject the initial strategy entirely. Instead, it initiates a strategy reassessment process. This process first re-examines the real-time resource status of all nodes within the system, particularly scanning idle terminal devices that were not fully utilized by the initial strategy. These devices may have released resources after completing tasks, or their computing power may have been underestimated in the initial assessment. The reassessment process calculates the feasibility of reallocating some cloud migration candidate tasks to these idle terminal devices. The feasibility assessment includes checking whether the devices have the necessary operating environment for the tasks and whether the latency constraints of the tasks are met after reallocation. The final migration decision is a trade-off. It may adjust some cloud migration candidate tasks that are not sensitive to latency but have inaccurate resource demand predictions to migrate to idle terminal devices, thereby reducing the population pressure on the cloud and the relay burden on edge nodes. This adjustment decision is immediately updated in the migration task list, forming the final executable migration plan. Cross-node migration of computing tasks triggered by the final migration decision is a fine-grained scheduling and execution process. The system first parses the final migration decision, identifying all tasks marked as cloud migration candidates. These tasks are then sorted according to their associated weights; tasks with higher weights typically indicate more urgent resource needs or higher business priority. Based on this sorting, the system generates a batch migration instruction sequence, which clearly defines the order and timing of task migrations, preventing network congestion caused by simultaneous large-scale migrations. For locally executable candidate tasks identified in the final decision, the system does not immediately initiate the task itself. Instead, it first sends a resource reservation instruction to the target terminal device. This instruction details the required CPU cores, memory size, and other resource quotas for the task and waits for confirmation from the device. Only after receiving confirmation from the device that it has the necessary resources is the task officially scheduled for execution on that device.

[0037] During the batch execution of migration instructions, the system does not remain passive but closely monitors the status of the network infrastructure, particularly by collecting real-time data on bandwidth utilization changes at network interfaces on critical edge nodes. This data is obtained by reading the network device's MIB library or through traffic probes. The system sets a bandwidth utilization threshold, typically lower than the theoretical upper limit of the physical interface, to provide a buffer for network fluctuations (e.g., setting the threshold to 75% of the physical bandwidth). When the monitoring system detects that the bandwidth utilization of an edge node reaches or exceeds this threshold while migration data flows through it, it automatically pauses the issuance of subsequent batches of migration instructions and enters a waiting state. During this waiting period, the system continuously monitors the network status until it receives a resource release signal, at which point it restarts the execution of subsequent instructions. This interrupt-recovery mechanism effectively prevents network overload. The correction logic for the migration strategy can be quantified using a weight adjustment function, which recalculates the priority weights of migration tasks after a correction condition is triggered. This function can be expressed as:

[0038] in: This represents the new weight value generated after the correction. It is the initial weight identifier for the task. This represents the normalized value of the absolute value of the difference between the actual CPU utilization and the predicted value. It reflects the magnitude of the instantaneous error in the prediction model. (Symbol) It is a configurable coefficient, usually with a negative sign, indicating that the urgency (weight) of the task based on the original prediction should be appropriately reduced when the prediction error increases. This represents the rate of change of memory usage increment over time, i.e., the growth rate of memory consumption. It is an indicator that measures how quickly the memory pressure on a node accumulates. This is another configurable coefficient, usually negative, indicating that the faster memory consumption increases, the lower the task migration priority should be to avoid potential memory exhaustion risks. This function converts real-time monitored system stress indicators into dynamic adjustments to the weights, allowing the migration strategy to adaptively respond to the actual operating state of the system.

[0039] The entire migration operation is designed as an interruptible and rollback process. The system maintains a state machine for each migration task, recording its current state such as "waiting to migrate," "migrifying," "paused," or "completed." When a migration task is paused due to bandwidth thresholds, the system records its breakpoint information and can resume execution from the breakpoint after a resource release signal arrives, rather than restarting, thus reducing network resource waste. For tasks that have been migrated to the cloud but need to be reassigned to terminal devices based on the final decision, the system triggers a rollback operation, first withdrawing the task status and data from the cloud, and then re-initiating the migration process to the terminal devices. The entire process must ensure the consistency and transactionality of task data. The execution effect of the final migration decision is fed back to the policy generation module in real time. The system records the final actual migration path of each task, resource usage during the migration process, and whether pauses or rollbacks occurred. This feedback information is stored in historical logs for subsequent analysis of the differences between the initial policy and the final decision, thus providing data support for optimizing resource demand prediction models and adjusting the thresholds of policy correction conditions, forming a complete closed loop from execution to learning. This mechanism, based on real-time monitoring and dynamic feedback, enables the cloud-edge-device collaborative computing resource allocation system to better cope with uncertainties and dynamic changes in the actual operating environment.

[0040] Example 4: Synchronously updating the task priority queue is a crucial mechanism for the system to continuously optimize its scheduling strategy. This process begins immediately after a computational task completes its cross-node migration operation according to the final migration decision. The system first records the actual execution data of the migrated tasks. For example, a video stream analysis task originally planned for migration to the cloud might be dynamically corrected and eventually scheduled to an idle edge node. The system extracts the actual execution latency data from the edge node's logs, from the start of data reception to the output of analysis results (e.g., 350 milliseconds). Simultaneously, it calculates the energy consumption of the task executed on this edge node and compares it with the theoretical energy consumption assumed for cloud execution, determining a reduction in energy consumption, such as a 20% reduction. This actual execution data becomes a crucial basis for adjusting the task priority queue. Based on the newly collected actual execution latency data, the system adjusts the ranking weights of similar computational tasks (i.e., other video stream analysis tasks) in the task priority queue. For instance, if the actual latency after migration is significantly better than expected, the system may increase the weight of such tasks, giving them a higher priority in the queue; conversely, if the latency performance is poor, its weight may be appropriately reduced. The energy consumption reduction rate is used to revise the baseline energy consumption reference value in the terminal device energy efficiency feature set. The old baseline value may be based on historical averages, while new actual data shows that performing such tasks on specific edge nodes is more energy efficient. Therefore, the reference value needs to be updated to make more accurate predictions of task energy consumption in the future. All these updated ranking weights and baseline energy consumption reference values ​​are written into a new version of the task execution feature library, thereby realizing the iterative evolution of the knowledge base.

[0041] The resource synergy evaluation matrix and priority queue are updated concurrently, but the focus is on changes in the overall resource status of the node cluster. The system calculates the average load decrease of relevant nodes after a batch of migration operations. For example, after migrating ten computing tasks from an overloaded edge node A to the cloud and idle terminal devices, node A's average CPU utilization drops from 90% to 65%—this 25% decrease is the average load decrease. Simultaneously, the system calculates the percentage of remaining resources of the cloud node (the migration destination) after receiving these tasks; for example, the cloud node's remaining CPU resources decrease from 40% to 15%. These macro-level statistics are used to reassess the synergy between nodes. Based on the calculated average load decrease, the system recalculates the latency jitter weighting coefficient in the inter-node communication quality score. Initially, latency jitter might have been assigned a fixed weight, but now it's found that with a significant load reduction, the impact of network latency stability on task execution may change. Therefore, this weighting coefficient needs adjustment, for example, from 0.6 to 0.5, slightly reducing its importance. More directly, the system uses the latest collected percentage of remaining resources for each node to directly replace the initial available resource data for the corresponding node in the resource synergy evaluation matrix, ensuring the matrix reflects the latest resource allocation status. Each update operation generates an evaluation matrix update log containing the latest latency jitter weight coefficient and the latest available resource amount. This log records the version number, update timestamp, and changes for easy traceability and auditing. See Table 1 for a simplified example illustrating the data changes involved in updating the task priority queue: Table 1: Task Priority Queue Update Table

[0042] The update process is not a simple replacement but involves complex data consistency maintenance. When the system writes the updated ranking weights and baseline energy consumption reference values ​​into a new version of the task execution feature library, it needs to ensure a smooth transition with the old version. The system may adopt a gradual update strategy; for example, the new baseline energy consumption reference value may be a weighted average of the old value and the latest observation, rather than a complete replacement. This can prevent drastic fluctuations in the reference value due to outliers in a single observation. Simultaneously, when updating the ranking weights of the priority queue, the system needs to consider the historical performance of all similar tasks and conduct a comprehensive evaluation, rather than making major adjustments based solely on a single migration result. This is to avoid overly frequent and drastic changes in the scheduling strategy and maintain the overall stability of the system. The update of the resource synergy evaluation matrix also requires careful handling. Directly replacing the old values ​​in the matrix with the new remaining resource percentages, while reflecting the latest state, may introduce noise due to the transient nature of the data. Therefore, when updating the matrix, the system may smooth the collected node remaining resource percentage data, for example, using a sliding window averaging method, taking the average of the most recent sampled values ​​to update the matrix, so that the matrix data can both track trends and avoid overreacting to transient fluctuations.

[0043] Generating evaluation matrix update logs not only serves as a record but also facilitates rollback operations in case of problems after updates. If new weight coefficients or resource data are found to degrade the quality of subsequent migration decisions, the system can quickly revert to the previous stable version based on the logs. The synchronous update mechanism establishes a closed loop from execution feedback to strategy optimization. Updates to the task priority queue directly affect the scheduling order of subsequent similar tasks, making them more inclined to choose migration paths or execution locations that have historically performed better. Updates to the resource synergy evaluation matrix keep the system's understanding of the resource status between nodes up-to-date, providing more accurate input for the generation of the next initial migration strategy. These two update processes work together: the adjustment of the task priority queue focuses more on the characteristics and historical performance of the tasks themselves, while the update of the resource synergy evaluation matrix focuses on changes in the infrastructure environment, jointly driving the entire cloud-edge-device collaborative computing system towards a more efficient and adaptive direction.

[0044] Example 5: Establishing a migration strategy backtracking index in the task execution feature library forms a crucial foundation for the system's self-evolution. This index is not a simple timestamp list, but a structured mapping table that precisely associates the unique version identifier of each generated initial migration strategy (e.g., "ISP_20240929_001") with the version identifier of the final migration decision formed after dynamic modification of this strategy (e.g., "FMD_20240929_001"). Each index entry not only records the correspondence between strategy versions but also saves the fingerprint information of the input data snapshots relied upon when generating the strategy, such as the version number of the resource synergy evaluation matrix used at that time, the hash value of the task priority queue, and the iteration number of the resource demand prediction model. This design enables the system to completely reproduce the historical context of a specific strategy. For example, when analyzing a failed migration decision, the backtracking index can quickly pinpoint the node load information and task characteristics upon which the initial judgment was made. The index itself exists as an independent module of the task execution feature library, and is persistently stored in the form of a database table, supporting efficient queries based on task ID, time range, or policy version number.

[0045] When a change in the task type identifier of a computing task is detected, the system activates an automated historical strategy comparison and verification process. This change may stem from manual reconfiguration by the user or be automatically triggered by the system's learning module based on significant changes in task behavior patterns. For example, a data backup task originally identified as "offline computing" might be re-identified as "near real-time processing" due to changes in business requirements necessitating the addition of real-time verification functionality. Upon detecting this change, the system immediately queries the migration strategy backtracking index using the task's historical ID as the key, retrieving a list of initial and final migration strategy versions related to all past execution instances of the task. The comparison and verification process then begins. The system loads the complete definitions of these historical strategies and their execution context data from the task execution feature library, while simultaneously obtaining the resource requirement prediction results for the task under the latest identifier. The core of the verification lies in applying the historical strategies to a virtual, current environment to analyze what resource conflicts, performance bottlenecks, or latency exceedances might occur if the old strategies are used to handle new types of tasks.

[0046] Through a comparative verification process, the system outputs a structured policy correction suggestion report. This report is not a simple conclusion but includes a detailed analysis of discrepancies. For example, the report might state: "For task T_78, after its type changed from 'offline computing' to 'near real-time processing,' the historical strategy of scheduling it to the cloud no longer meets the new latency constraints due to data transmission latency. It is recommended to prioritize scheduling such tasks to edge nodes." These correction suggestions are directly actionable, and the system automatically converts and updates them to the training dataset of the resource demand prediction model. The update process is incremental rather than overwrite-based. New data samples (i.e., the characteristics of the changed tasks and their correction suggestions) are labeled and added to the training set, subsequently triggering an incremental learning or fine-tuning process for the prediction model. This allows the model to gradually adapt to dynamic changes in task types, improving its predictive ability and decision-making accuracy for similar changes in the future.

[0047] The maintenance mechanism of the backtracking index ensures the accessibility and consistency of historical data. Whenever a new initial migration strategy version is generated, the index management module synchronously creates a new index entry and waits for the corresponding final migration decision before associating and binding it. If a task is permanently deleted, its related index entries are not immediately physically deleted but are marked as archived and moved to the historical archive to meet potential auditing or in-depth analysis needs. The index itself also supports version backtracking, allowing queries to determine which strategy versions were active at a specific historical point in time and their derivative relationships, providing the possibility of analyzing the evolution path of system strategies. The generation logic for strategy correction recommendations includes multi-dimensional evaluation. The system not only compares the matching degree between historical strategies and current requirements but also assesses the potential chain reactions caused by strategy changes. For example, if a type of task is changed from cloud scheduling to edge scheduling, it is necessary to assess whether the target edge cluster has sufficient long-term resource reserves to handle these new tasks and whether it will disrupt the existing load balancing state. Therefore, correction recommendations may be a set of conditional recommendations rather than a single absolute instruction, such as "It is recommended to schedule task A to an edge node, provided that the load on node B is below 70%." This detailed advice provides richer reference information for subsequent automated or manual decision-making. The final output of the entire process—updating the training dataset of the resource demand prediction model—is the closed loop for the system's continuous learning. Updating the training dataset is not a simple appending of records, but rather involves data cleaning and feature reweighting. The system evaluates the consistency between the newly added sample data, which originates from changes in task type, and the original data distribution. If necessary, it rescales features or adjusts the weight ratio of different features in the model to ensure that the model's generalization ability does not decrease after incremental learning. This process is silent and automated, enabling the entire dynamic resource allocation system to gradually adapt to the evolution of business needs without human intervention, demonstrating a certain degree of autonomous evolution capability.

[0048] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0049] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for dynamic allocation of cloud-edge-end collaborative computing resources based on task-aware migration, characterized in that, The method comprises the following steps: Obtain the real-time load characteristics and resource demand characteristics of the computing task in the cloud-edge-terminal system, and divide the task priority queue according to the task type identification of the computing task; Extract the historical execution records of the computing task on the cloud nodes, edge nodes and terminal devices, construct a task execution feature library, and generate a resource demand prediction model combined with the real-time load characteristics; Analyze the network transmission delay characteristics between the cloud nodes and the edge nodes, measure the real-time computing capacity fluctuation data of the terminal device, and establish a node-to-node resource collaboration degree evaluation matrix; According to the resource demand prediction model and the resource collaboration degree evaluation matrix, generate the initial migration strategy of the computing task in the cloud-edge-terminal three-layer architecture; Monitor the deviation data of the actual resource occupancy rate of the computing task from the predicted value, combine the node-to-node resource state change characteristics, dynamically correct the initial migration strategy to form the final migration decision; Based on the final migration decision, trigger the cross-node migration operation of the computing task, and synchronously update the task priority queue and the resource collaboration degree evaluation matrix.

2. The cloud-edge-fog collaborative computing resource dynamic allocation method based on task-aware migration according to claim 1, characterized in that, The method comprises the following steps: Identify the computing-intensive characteristics or delay-sensitive characteristics corresponding to the task type identification of the computing task; Collect the CPU occupancy peak data, memory occupancy fluctuation data and network bandwidth demand baseline of the computing task within a preset time window; Normalize the CPU occupancy peak data and the memory occupancy fluctuation data to generate the real-time load characteristic vector of the computing task; According to the network bandwidth demand baseline and the task type identification, generate the resource demand characteristic label.

3. The method of claim 2, wherein, The method comprises the following steps: Extract the average response delay data of the computing task on the cloud nodes, the task interruption frequency data on the edge nodes and the energy consumption curve of the terminal device from the historical execution records; Align the average response delay data and the task interruption frequency data in time sequence to form the task execution stability feature set; Integrate the energy consumption curve to generate the terminal device energy efficiency feature set; Fuse the task execution stability feature set and the terminal device energy efficiency feature set to construct a multi-dimensional task execution feature library.

4. The cloud-edge-fog collaborative computing resource dynamic allocation method based on task-aware migration according to claim 3, characterized in that, The method comprises the following steps: Measure the round-trip delay jitter data in the network transmission delay characteristics from the cloud nodes to the edge nodes; Collect the CPU frequency reduction frequency and memory available capacity threshold data of the terminal device during task execution; Weight and aggregate the round-trip delay jitter data and the CPU frequency reduction frequency to generate the node-to-node communication quality score; According to the memory available capacity threshold data, correct the communication quality score to form the initial version of the resource collaboration degree evaluation matrix.

5. The cloud-edge-fog collaborative computing resource dynamic allocation method based on task-aware migration according to claim 4, characterized in that, The method comprises the following steps: Compare the predicted resource demand output by the resource demand prediction model with the node available resource amount in the resource collaboration degree evaluation matrix; When the predicted resource demand exceeds the available resource amount of the edge node, mark the computing task as a cloud migration candidate task; When the predicted resource demand is lower than the real-time computing capacity of the terminal device, mark the computing task as a local execution candidate task; The priority queue order of the cloud migration candidate task and the local execution candidate task is integrated to generate an initial migration strategy with a weight identifier.

6. The cloud-edge-fog collaborative computing resource dynamic allocation method based on task-aware migration according to claim 5, characterized in that, The dynamic correction of the initial migration strategy forms a final migration decision, which includes: An absolute value of a difference between an actual CPU occupancy rate and a predicted CPU occupancy rate of the computing task in the migration process is obtained. Memory occupancy increment data newly added by the edge node during the task migration is monitored. When the absolute value of the difference exceeds a preset threshold and the memory occupancy increment data continues to grow, a migration strategy correction condition is triggered. According to the correction condition, part of the cloud migration candidate task is re-assigned to an idle terminal device to form a final migration decision.

7. The method of claim 6, wherein the method further comprises: The cross-node migration operation of the computing task triggered based on the final migration decision includes: According to the weight identifier of the cloud migration candidate task in the final migration decision, a batch migration instruction sequence is generated. For the local execution candidate task, a resource reservation instruction is sent to the terminal device and a device confirmation feedback is received. Bandwidth utilization change data of the edge node is collected in real time during the execution of the migration instruction sequence. When the bandwidth utilization change data reaches a critical value, the subsequent migration instruction is paused and a resource release signal is waited for. 8.The method of claim 7, wherein, The synchronous update of the task priority queue includes: Actual execution delay data and energy consumption reduction ratio of the computing task after the completed migration operation are recorded. According to the actual execution delay data, the sorting weight of the same type of computing task in the priority queue is adjusted. The benchmark energy consumption reference value in the terminal device energy efficiency feature set is corrected in combination with the energy consumption reduction ratio. The updated sorting weight and the benchmark energy consumption reference value are written into a new version of the task execution feature library. 9.The method of claim 8, wherein, The update of the resource coordination degree evaluation matrix includes: The average load drop amplitude of the edge node and the remaining resource percentage of the cloud node after the migration operation is completed are counted. According to the average load drop amplitude, the time delay jitter weight coefficient in the inter-node communication quality score is recalculated. The remaining resource percentage is used to replace the initial available resource amount data in the resource coordination degree evaluation matrix. An evaluation matrix update log containing the latest time delay jitter weight coefficient and the available resource amount is generated. 10.The method of claim 9, wherein, The method further includes: A migration strategy backtracking index is established in the task execution feature library, and the version number of the initial migration strategy and the final migration decision is associated. When the task type identifier of the computing task is changed, a historical strategy comparison and verification process is triggered according to the backtracking index. Through the comparison and verification process, a strategy correction suggestion is output and automatically updated to the training data set of the resource demand prediction model.

Images