An edge-cloud collaborative task scheduling method and system based on stability theory

Abstract

The present invention discloses an edge-cloud collaborative task scheduling method based on stability theory for an edge computing system, including: the edge server receives tasks uploaded by corresponding Internet of Things terminals; the edge server calculates a migration strategy and executes the migration strategy; the edge server processes the unmigrated tasks received by itself and the migrated tasks of neighbor edge servers; wherein, the migration strategy is to minimize the sum of the Lyapunov drift function and the penalty function of the edge computing system on the premise of ensuring the latency requirements of the tasks. Based on the Lyapunov stability theory, the present invention determines the task migration strategy, so that on the premise of meeting the task latency requirements, the energy consumption and system stability are balanced at the same time, which not only meets the differentiated latency service requirements of Internet of Things applications but also reduces the system energy consumption, realizing green and high-performance mobile edge computing.

Description

Technical Field

[0001] The present invention relates to the field of edge computing, and more particularly, to an edge-cloud collaborative task scheduling method and system based on stability theory. Background Art

[0002] Emerging Internet of Things applications such as virtual reality, autonomous driving, and drones have generated a huge amount of data. In order to quickly and efficiently mine and utilize the information in the data, it is necessary to perform high-performance computing on the huge amount of data in a timely manner. The traditional cloud computing paradigm needs to transmit the huge amount of data from distributed data sources to a remote cloud data center, and after being processed by the cloud data center server, it is returned to the user. In this paradigm, tasks often experience network transmission delays of dozens to hundreds of milliseconds or even longer, and cannot meet the low-latency requirements of Internet of Things applications. For example, autonomous driving requires an end-to-end latency of no more than 1 millisecond, otherwise the risk factor will increase exponentially. It is difficult to meet the latency requirements of autonomous driving by uploading the data of the autonomous driving vehicle and the surrounding environment perception to the cloud data center for driving decision-making.

[0003] Edge computing is an extension of the cloud computing paradigm. The main idea is to deploy edge servers with certain computing capabilities at the network edge to reduce network transmission delays by sinking tasks from the cloud to the network edge for processing, so as to improve the response speed of tasks. However, compared with the cloud data center, the computing resources at the edge are distributed, and the capabilities of individual edge nodes are limited. They cannot quickly respond to sudden large amounts of computing requirements, easily causing backlogs of edge server services and resulting in unbearable queuing delays for tasks. In addition, when the business load on the edge side is too high, the energy consumed by edge computing will be much higher than that of cloud computing, which is contrary to the vision of green communication and green computing.

[0004] Therefore, it is necessary to coordinate resources such as bandwidth and computing on the edge side and the cloud data center, and effectively schedule edge tasks to meet the low-latency and high-performance computing requirements of a huge amount of Internet of Things applications, reduce the overall energy consumption of the system, and achieve the vision goals of green communication and computing.

[0005] However, the dynamics and hybrid nature of IoT application services, as well as the bandwidth and heterogeneous computing resources of the edge-cloud computing system, pose numerous challenges to edge-cloud collaborative task scheduling. First, IoT applications generate both large tasks with strict latency requirements and tasks with soft latency requirements (no strict latency requirements, but the lower the latency, the better). Coupled with the randomness of task generation, offline optimization algorithms are difficult to make precise optimization scheduling decisions because they cannot accurately describe the arrival characteristics of tasks. Second, the computing resources of edge servers are generally limited, and task backlogs are likely to occur during business bursts, resulting in queuing delays. Edge-cloud task scheduling needs to consider the balance between the queuing delays of edge computing and the transmission delays of cloud computing. In addition, making full use of the collaborative processing capabilities of edge services can improve system performance. How to schedule tasks among edge servers is also an important issue to be considered in edge-cloud collaboration. Finally, the transmission and processing of computing tasks both consume energy, and the same task may consume different amounts of energy on different network links and different computing nodes. How to reduce system energy consumption while meeting the latency requirements of services is also a key problem that needs to be solved in edge-cloud collaborative task scheduling. Summary of the Invention

[0006] The present invention aims to overcome at least one defect (shortcoming) of the above-mentioned prior art, and provides an edge-cloud collaborative task scheduling method and system based on stability theory, which is used to solve the problem of how to reduce system energy consumption while meeting the latency requirements of services in optimizing edge-cloud collaborative task scheduling.

[0007] The technical solution adopted by the present invention is an edge-cloud collaborative task scheduling method based on stability theory, which is used for an edge computing system. The edge computing system includes a plurality of edge servers and a cloud data center, and the method includes:

[0008] The edge server receives tasks uploaded by corresponding IoT terminals;

[0009] The edge server calculates a migration strategy and executes the migration strategy. Specifically, executing the migration strategy means determining whether to migrate the task according to the migration strategy, and when it is determined to migrate the task, further determining to migrate the task to a neighboring edge server or the cloud data center of the edge server, so that the neighboring edge server or the cloud data center processes the migrated task;

[0010] The edge server processes the un-migrated tasks received by itself and the migrated tasks of neighboring edge servers;

[0011] Among them, the migration strategy is to minimize the sum of the Lyapunov drift function and the penalty function of the edge computing system on the premise of ensuring the latency requirement of the task. The Lyapunov drift function is calculated according to the task load queue of the edge computing system, and the penalty function is calculated according to the energy consumption of task migration in the edge computing system.

[0012] The Lyapunov stability theory was founded by the Russian mathematician and mechanician A.M. Lyapunov in 1892 for analyzing the stability of systems. It can be applied to analyze the stability of linear systems and nonlinear systems, time-invariant systems and time-varying systems, and is a commonly used method for stability analysis. The Lyapunov function is a function used to demonstrate the stability of a system and plays an important role in stability and control theory. In a system with multiple queues, the Lyapunov function is usually represented by the sum of the squares of the backlogs of the queues over time. The change of the Lyapunov function from one time slot to the next is called the Lyapunov drift. The Lyapunov drift is mainly used in the optimal control of queuing networks, aiming to stabilize the created network queues and optimize the required performance objectives. For the present invention, it aims to balance energy consumption and system stability while meeting the strict latency requirements of high-priority tasks. Therefore, based on the Lyapunov stability theory, through calculation, a migration strategy that minimizes the Lyapunov drift function of the system task load queue plus the system energy consumption as a penalty function can effectively reduce system energy consumption and improve system stability, achieving the technical effects of the present invention.

[0013] Further, the tasks include first-class tasks and second-class tasks, and the latency requirement of the first-class tasks is higher than that of the second-class tasks;

[0014] The edge server processes the un-migrated tasks received by itself and the migrated tasks of neighbor edge servers, specifically including:

[0015] The edge server sets a first queue and a second queue for storing tasks;

[0016] The edge server sequentially puts the received first-class tasks at the tail of the first queue and the received second-class tasks at the tail of the second queue;

[0017] The edge server determines a task scheduling strategy and sequentially schedules the first-class tasks from the head of the first queue for processing or sequentially schedules the second-class tasks from the head of the second queue for processing according to the task scheduling strategy.

[0018] In the task queue of the edge server, when there is a backlog of tasks in the first queue for storing the first type of tasks or the second queue for storing the second type of tasks, it is necessary to reasonably schedule the tasks in the queue to ensure that the queue tasks are efficiently processed while meeting the service quality requirements. Different from the second type of tasks, the first type of tasks has strict latency requirements, so usually a higher priority is provided for the first type of tasks. However, if the high-priority scheduling strategy is continuously adopted, when the first type of tasks keep arriving, the low-priority second type of tasks in the second queue will be severely backlogged due to the inability to obtain computing resources in time, resulting in system instability. Therefore, to solve this problem, the edge server sets a task scheduling strategy based on dynamic weights. When there are task backlogs in both queues, by calculating the cumulative service weight η of the first queue, and then selecting the tasks in the first queue with a probability of η, or selecting the tasks in the second queue with a probability of 1 - η for processing, flexible dynamic task scheduling is achieved, further maintaining system stability.

[0019] Further, the edge server calculates a migration strategy and executes the migration strategy. According to the migration strategy, it is determined whether to migrate the task, which specifically includes:

[0020] When the task received by the edge server is the first type of task, the edge server calculates the first migration strategy, simultaneously calculates the task splitting strategy, splits the task according to the splitting strategy, and determines whether to migrate the split task according to the first migration strategy;

[0021] When the task received by the edge server is the second type of task, the edge server calculates the second migration strategy and determines whether to migrate the task according to the second migration strategy.

[0022] In practical applications, the computing tasks generated by IoT terminals are generally divided into two categories. Among them, the first type of tasks are mainly tasks that are relatively complex, have a large amount of data, and have strict latency requirements, while the second type of tasks are mainly tasks that are relatively simple, have a moderate amount of data, and do not have strict latency requirements. To meet the service quality requirements of the tasks, for the first type of tasks, if they are processed on the edge server, the tasks need to be split so that they can be calculated on two distributed edge servers simultaneously, reducing the high computing latency caused by the large amount of data of the first type of tasks and the small computing resources of the edge server. However, if they are processed in the cloud data center, splitting is not required; but for the second type of tasks, whether on the edge server or in the cloud data center, they are calculated and processed as a whole task.

[0023] Further, the first migration strategy and the task splitting strategy satisfy:

[0024]

[0025]

[0026]

[0027] where t represents a time slot, represents the set of edge servers, m, u, represents the set of Internet of Things terminals corresponding to the edge server m, V represents the Lyapunov control parameter, and E(t) represents the system energy consumption, represents the load of the first queue in the edge server u, represents the migration policy variable, represents the task splitting policy variable, χ represents the number of CPU cycles required to process one byte of task, S m,n (t) represents the task data volume, k represents the computing node, represents the set of computing nodes, represents that the task is migrated to the cloud data center for processing, d T1 represents the first type of task delay threshold, represents the end-to-end delay of the first type of task in the edge server g, represents the set of edge servers that meet the delay requirements of the first type of task;

[0028] The second migration policy satisfies:

[0029]

[0030]

[0031] Furthermore, the edge server determines a task scheduling policy, and schedules the first type of tasks for processing in sequence from the head of the first queue or schedules the second type of tasks for processing in sequence from the head of the second queue according to the task scheduling policy, specifically including:

[0032] The edge server obtains the length of the first queue and the length of the second queue

[0033] When the length of the first queue and the length of the second queue at this time, the following rules are used to determine the cumulative service weight η of the first queue in the edge server:

[0034]

[0035] Determine the task scheduling policy variable π according to the cumulative service weight η by the following rules m (t) value:

[0036]

[0037] wherein, represents the load of the first queue in the edge server u, represents the load of the second queue in the edge server u, Pr{π m (t)=0} represents the probability that π m (t)=0, Pr{π m (t)=1} represents the probability that π m (t)=1;

[0038] When the length of the first queue and the length of the second queue at this time, the task scheduling policy variable π m (t)=0;

[0039] When the length of the second queue and the length of the first queue at this time, the task scheduling policy variable π m (t)=1;

[0040] When the task scheduling policy variable π m (t)=0, it means that the edge server schedules and processes the first type of tasks in sequence from the head of the first queue according to the task scheduling policy;

[0041] When the task scheduling policy variable π m (t)=1, it means that the edge server schedules and processes the second type of tasks in sequence from the head of the second queue according to the task scheduling policy.

[0042] On the other hand, another technical solution adopted by the present invention is a cloud-edge collaborative task scheduling system based on stability theory for a mobile edge computing system. The mobile edge computing system includes several edge servers and a cloud data center, and includes:

[0043] A task receiving module, configured to receive tasks uploaded by corresponding Internet of Things terminals by the edge server;

[0044] A migration module, which is used to calculate a migration policy for edge server computing and execute the migration policy. Specifically, when executing the migration policy, it determines whether to migrate the task according to the migration policy, and when it is determined to migrate the task, it further determines to migrate the task to a neighbor edge server or a cloud data center of the edge server, so that the neighbor edge server or the cloud data center processes the migrated task;

[0045] A task processing module, which is used for an edge server to process the unmigrated tasks received by itself and the migrated tasks of neighbor edge servers;

[0046] Wherein, the migration policy is to minimize the sum of the Lyapunov drift function and the penalty function of the edge computing system on the premise of ensuring the latency requirement of the task. The Lyapunov drift function is calculated according to the task load queue of the edge computing system, and the penalty function is calculated according to the energy consumption of task migration in the edge computing system.

[0047] Further, the task includes a first type of task and a second type of task, and the latency requirement of the first type of task is higher than that of the second type of task;

[0048] In the task processing module, when the edge server processes the unmigrated tasks received by itself and the migrated tasks of neighbor edge servers, it specifically includes:

[0049] The edge server sets a first queue and a second queue for storing tasks;

[0050] The edge server sequentially puts the received first-type tasks at the tail of the first queue, and sequentially puts the received second-type tasks at the tail of the second queue;

[0051] The edge server determines a task scheduling policy, and sequentially schedules the first-type tasks from the head of the first queue for processing or sequentially schedules the second-type tasks from the head of the second queue for processing according to the task scheduling policy.

[0052] Further, in the migration module, when the edge server calculates the migration policy and executes the migration policy, and determines whether to migrate the task according to the migration policy, it specifically includes:

[0053] When the task received by the edge server is a first-type task, the edge server calculates a first migration policy, simultaneously calculates a task splitting policy, splits the task according to the splitting policy, and determines whether to migrate the split task according to the first migration policy;

[0054] When the task received by the edge server is a second - type task, the edge server calculates a second migration strategy and determines whether to migrate the task according to the second migration strategy.

[0055] On the other hand, another technical solution adopted by the present invention is a computer device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the above - mentioned edge - cloud collaborative task scheduling method is implemented.

[0056] On the other hand, another technical solution adopted by the present invention is a computer - readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the above - mentioned edge - cloud collaborative task scheduling method is implemented.

[0057] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0058] Based on the Lyapunov stability theory, the present invention analyzes the mathematical relationship between queue stability, strict delay requirements, and system optimization objectives, determines the task migration strategy, so that while meeting the task delay requirements, the energy consumption and system stability are balanced at the same time, which not only meets the differentiated delay service requirements of Internet of Things applications but also reduces the system energy consumption, realizing green and high - performance mobile edge computing. Description of the Drawings

[0059] Figure 1 It is a model diagram of the edge - computing system in the present invention.

[0060] Figure 2 It is a flowchart of the edge - cloud collaborative task scheduling method in the present invention.

[0061] Figure 3 It is a model diagram of the task queue in the present invention.

[0062] Figure 4 It is a graph of the optimization results of the average system delay and energy consumption of the edge - cloud collaborative task scheduling method in the present invention under different control parameters V.

[0063] Figure 5 It is a graph of the experimental results of the performance comparison of different methods at different task rates in the present invention (where DGEM represents the edge - cloud collaborative task scheduling method in the present invention). Figure a is a graph of the change in the delay guarantee rate of the first - type task, Figure b is a graph of the change in the average end - to - end delay, Figure c is a graph of the change in the task completion rate, and Figure d is a graph of the change in the system energy consumption.

[0064] Figure 6Experimental result graph of performance comparison of different methods under different task sizes in the present invention (where DGEM represents the edge-cloud collaborative task scheduling method in the present invention). Figure a is the graph of the change in the delay guarantee rate of the first type of task, Figure b is the graph of the change in the average end-to-end delay, Figure c is the graph of the change in the task completion rate, and Figure d is the graph of the change in the system energy consumption.

[0065] Figure 7 Experimental result graph of performance comparison of different methods under different delay bounds in the present invention (where DGEM represents the edge-cloud collaborative task scheduling method in the present invention). Figure a is the graph of the change in the delay guarantee rate of the first type of task, Figure b is the graph of the change in the average end-to-end delay, Figure c is the graph of the change in the task completion rate, and Figure d is the graph of the change in the system energy consumption.

[0066] Figure 8 Schematic structural diagram of the edge-cloud collaborative task scheduling system in the present invention.

[0067] Explanation of reference numerals: Task receiving module 100, migration module 200, task processing module 300. Detailed implementation manners

[0068] The attached drawings of the present invention are only for illustrative purposes and cannot be construed as limitations on the present invention. To better illustrate the following embodiments, some components in the attached drawings will be omitted, enlarged, or reduced, which do not represent the dimensions of the actual product; for those skilled in the art, it is understandable that some well-known structures and their descriptions in the attached drawings may be omitted.

[0069] As Figure 1 shown, the methods and systems in the embodiments of the present invention are all applied to an edge computing system. The edge computing system includes several edge servers and a cloud data center. Each edge server is deployed near a base station, that is, one edge server is configured for one base station. The base stations are connected by a wired network. It is assumed that the edge servers are neighbors to each other, that is, they can directly communicate with each other through the base stations where they are located. There is a bottleneck link between the edge servers and the cloud data center, and all communications between the edge servers and the cloud data center converge to this bottleneck link. A limited number of Internet of Things terminals are randomly distributed within the coverage areas of the base stations. Each base station, the Internet of Things terminals covered by the base station, and the edge server configured by the base station form an edge subsystem. The edge server within the same subsystem is called the primary edge server of the Internet of Things terminals within the subsystem, and the edge servers of other edge subsystems are called the neighbor edge servers of the terminal.

[0070] Each IoT terminal randomly generates computing tasks. The generated tasks are first sent to the main edge server, which decides whether to perform local computing, migrate to a neighboring edge server for computing, or migrate to the cloud data center for processing. To avoid the ping-pong effect and reduce the multiple migrations of tasks in the edge subsystem, for tasks from other edge servers, this edge server will no longer forward them to other neighboring edge servers or migrate them to the cloud data center.

[0071] Let \(t\) represent the time slot and \(M\) represent the number of edge servers. denote the set of edge servers. N m denote the number of IoT terminals of the \(m\)-th edge server, then the total number of IoT terminals in the system can be expressed as Let and denote the corresponding sets respectively. Let denote the computing power (the rate of processing computing tasks) of the \(m\)-th edge server, and \(f\) C denote the computing rate allocated by the cloud data center to each task. Assume that

[0072] Embodiment 1

[0073] As Figure 2 shown, this embodiment provides an edge-cloud collaborative task scheduling method based on stability theory for an edge computing system. The edge computing system includes several edge servers and a cloud data center, and it includes:

[0074] S1. The edge server receives the tasks uploaded by the corresponding IoT terminals.

[0075] In this embodiment, the tasks include the first type of tasks and the second type of tasks. The latency requirement of the first type of tasks is higher than that of the second type of tasks. Among them, the first type of tasks are mainly complex, have a large amount of data, and have strict latency requirements, while the second type of tasks are mainly simple, have a moderate amount of data, and have no strict latency requirements. To meet the quality of service requirements of the tasks, for the first type of tasks, if they are processed on the edge server, the tasks need to be split so that they can be computed simultaneously on two distributed edge servers, reducing the high computing latency caused by the large amount of data of the first type of tasks and the small computing resources of the edge server. However, if they are processed in the cloud data center, no splitting is required. But for the second type of tasks, whether on the edge server or in the cloud data center, they are computed and processed as a whole task.

[0076] S2. The edge server calculates the migration policy and executes the migration policy. Specifically, when executing the migration policy, it determines whether to migrate the task according to the migration policy. When it is determined to migrate the task, it further determines whether to migrate the task to the neighboring edge server or the cloud data center of the edge server, so that the neighboring edge server or the cloud data center processes the migrated task;

[0077] Among them, the migration policy in step S2 is to minimize the sum of the Lyapunov drift function and the penalty function of the edge computing system on the premise of ensuring the latency requirement of the task.

[0078] Specifically, let represent the task load queue vector of the system at time slot t, and let L(t) represent the Lyapunov function of the task load queue, which is defined as:

[0079]

[0080] Then the further Lyapunov drift function of Qω(t) is defined as:

[0081] ΔL(t) = E[L(t + 1) - L(t)|Qω(t)]

[0082] The system energy consumption E(t) per time slot is added as a penalty function to the Lyapunov drift function of the system task load queue, that is, the Lyapunov drift plus penalty function of the system task load is defined as ΔL(t) + VE[E(t)|Qω(t)], where V > 0 represents the Lyapunov control parameter.

[0083] According to the Lyapunov stability theory, if ΔL(t) + VE[E(t)|Qω(t)] can be controlled to change in the negative direction, the queue Qω will be stable and the optimized system energy consumption E[E(t)] can be obtained. Therefore, in this embodiment, the determined migration policy can minimize the sum of the Lyapunov drift function and the penalty function ΔL(t) + VE[E(t)|Qω(t)] on the premise of ensuring the latency requirement of the first type of task.

[0084] Further, step S2 specifically includes:

[0085] When the task received by the edge server is the first type of task, the edge server calculates the first migration policy, and at the same time calculates the task splitting policy, splits the task according to the splitting policy, and determines whether to migrate the split task according to the first migration policy;

[0086] When the task received by the edge server is a second - type task, the edge server calculates a second migration policy and determines whether to migrate the task according to the second migration policy.

[0087] Further, the first migration policy and the task splitting policy satisfy:

[0088]

[0089]

[0090]

[0091] where t represents a time slot, represents the set of edge servers, m, u, represents the set of Internet of Things terminals corresponding to edge server m, V represents the Lyapunov control parameter, and E(t) represents the system energy consumption, represents the load of the first queue in edge server u, represents the migration policy variable, represents the task splitting policy variable, χ represents the number of CPU cycles required to process one - byte of the task, S m,n (t) represents the task data volume, k represents a computing node, represents the set of computing nodes, represents that the task is migrated to the cloud data center for processing, d T1 represents the delay threshold of the first - type task, represents the end - to - end delay of the first - type task in edge server g, represents the set of edge servers that meet the delay requirements of the first - type task;

[0092] The second migration policy satisfies:

[0093]

[0094]

[0095] S3. The edge server processes the unmigrated tasks received by itself and the migrated tasks of neighbor edge servers;

[0096] Further, step S3 specifically includes:

[0097] The edge server sets a first queue and a second queue for storing tasks;

[0098] The edge server sequentially places the received first - type tasks at the tail of the first queue and the received second - type tasks at the tail of the second queue;

[0099] The edge server determines a task scheduling policy and schedules the first - type tasks for processing sequentially from the head of the first queue or schedules the second - type tasks for processing sequentially from the head of the second queue according to the task scheduling policy.

[0100] Furthermore, the edge server determines a task scheduling policy and schedules the first - type tasks for processing sequentially from the head of the first queue or schedules the second - type tasks for processing sequentially from the head of the second queue according to the task scheduling policy, which specifically includes:

[0101] The edge server obtains the length of the first queue and the length of the second queue

[0102] When the length of the first queue and the length of the second queue At this time, the following rules are used to determine the cumulative service weight η of the first queue in the edge server:

[0103]

[0104] The following rules are used to determine the task scheduling policy variable π m (t) value:

[0105]

[0106] Among them, represents the load of the first queue in the edge server u, represents the load of the second queue in the edge server u, Pr{π m (t)=0} represents the probability that π m (t)=0, Pr{π m (t)=1} represents the probability that π m (t)=1;

[0107] When the length of the first queue and the length of the second queue At this time, the task scheduling policy variable π m (t)=0;

[0108] When the length of the second queue and the length of the first queue At this time, the task scheduling policy variable π m (t)=1;

[0109] When the task scheduling policy variable π mWhen (t) = 0, it means that the edge server schedules and processes the first type of tasks sequentially from the head of the first queue according to the task scheduling policy;

[0110] When the task scheduling policy variable π m (t) = 1, it means that the edge server schedules and processes the second type of tasks sequentially from the head of the second queue according to the task scheduling policy.

[0111] In the specific implementation process, the following dynamic service model is adopted: (1) Each IoT terminal randomly generates a task per time slot, and this task is one of the first type or the second type of tasks; (2) For each edge subsystem, the probability of generating each type of task per time slot follows an independent and identical distribution; (3) The size of each type of task follows the same distribution among all edge subsystems.

[0112] Let S represent the data volume of a certain task, then the CPU cycles required for this task are

[0113] W = χS, #(1 - 1)

[0114] where χ represents the number of CPU cycles required to process one byte of the task;

[0115] Let Task m,n (t) represent the task generated by the nth IoT terminal of the mth edge subsystem at time slot t, and let X m,n (t) represent the task type indication variable. When X m,n (t) = 0, it means that this task is the first type of task; when X m,n (t) = 1, it means that this task is the second type of task. Then the number of the first type of tasks generated by the edge subsystem m at time slot t can be expressed as

[0116]

[0117] The long - term average task rate can be expressed as

[0118]

[0119] The average task rate of the total first type of tasks in the system is

[0120]

[0121] The number of the second type of tasks generated can be expressed as

[0122]

[0123] The long - term average task rate can be expressed as

[0124]

[0125] The average task rate of the first type of tasks in the system is

[0126]

[0127] The total task generation rate of the system is the sum of the rates of the first type of tasks and the second type of tasks, that is

[0128] λ = λ T1 + λ T2 #(1 - 8)

[0129] Let represent the computing migration strategy vector of task Task m,n (t), and the binary variable indicates whether to migrate to the cloud data center for processing. When it is decided to migrate to the cloud data center for processing, otherwise The binary variable indicates whether to compute on the edge server shown in the superscript. For example, indicates computing on the k-th edge server, otherwise

[0130] Since the first type of tasks need to be split into two subtasks when computing on the edge server, but do not need to be split when processed in the cloud data center, so if task Task m,n (t) belongs to the first type of tasks, there should be

[0131]

[0132] In the above formula, represents the set of computing nodes.

[0133] If task Task m,n (t) belongs to the second type of tasks, there is no need to split the task. Therefore, there is

[0134]

[0135] Let S m,n (t) be the size (in bits) of task Task m,n (t). If the task belongs to the first type of tasks, if it is processed on the edge server, the task also needs to be split. Therefore, let represent the splitting ratio of the task. When , it means that the task belongs to the second type of tasks, does not need to be split, and is computed on computing node k; when , when a ∈ (0, 1), it means that the task belongs to the first type of tasks, and the proportion of the task diverted to edge server k is a, that is, the size is Then the size allocated to another edge server is

[0136] In addition, since all tasks generated by IoT terminals need to be uploaded to the main edge server before making a computing migration decision, the present embodiment mainly focuses on the task scheduling of edge-cloud collaboration. Therefore, the latency and energy consumption of task transmission from the terminal to the main edge server are not considered here for the time being. Instead, the latency and energy consumption generated during task processing on a single edge server, multiple edge servers, or a cloud data center, as well as task transmission from the main edge server to the cloud data center, are mainly considered.

[0137] Since the first type of tasks need to be segmented when processed on the edge server, while the second type does not, this embodiment intends to establish a computing migration mathematical model for these two types of tasks respectively, and analyze the latency and energy consumption of tasks processed on each edge server and in the cloud data center.

[0138] (1) The first type of tasks

[0139] Assume that task Task m,n (t) is the first type of task, then it may be migrated to the cloud data center for processing, or be segmented into subtasks and processed on the edge server.

[0140] 1) Cloud computing model

[0141] When the main edge server (edge server m) determines to migrate this task to the cloud data center for processing, this task will generate a transmission latency from the main edge to the cloud data center and a computing latency in the cloud data center.

[0142] Let B C represent Figure 1 the bandwidth of the bottleneck link between the edge server and the cloud data center in m,n . The weighted fair bandwidth scheduling strategy is adopted to allocate link bandwidth resources, that is, the bandwidth obtained by each task competing for the bottleneck link bandwidth resource is the ratio of the size of this task to the total size of competing tasks. Thus, the bandwidth weight of task Task

[0143]

[0144] can be expressed as m,n . Further, the transmission latency of task Task

[0145]

[0146] can be expressed as C . Since the computing rate allocated to each task by the cloud data center is f m,n , the computing latency of task Task

[0147]

[0148] Among them, W m,n (t) represents the CPU cycles required for the task.

[0149] Therefore, the end-to-end latency for task Task m,n (t) to be migrated to the cloud data center for processing can be expressed as

[0150]

[0151] Since the transmission energy consumption is proportional to the data transmission duration and the computing energy consumption is directly related to the task size, the transmission energy consumption and computing energy consumption of this task can be expressed as

[0152]

[0153] and

[0154]

[0155] Among them, γ C,Tx represents the energy consumption factor of the bottleneck link in the cloud data center, and γ C,CPU and θ represent the energy consumption factors for the cloud data center server to process the task.

[0156] Therefore, the total energy consumption for task Task m,n (t) to be migrated to the cloud data center for processing is

[0157]

[0158] 2) Edge computing model

[0159] When the main edge server (edge server m) determines to split and allocate this task to edge servers u, for processing, this task will incur task migration latency from the main edge to neighbor edge servers u and z, including transmission latency and queuing and computing latency of the task at these two edge servers.

[0160] Let B E represent the bandwidth of the adjacent base station link as shown in Figure 1 and the weighted fair bandwidth scheduling strategy is also adopted to allocate link bandwidth resources. Therefore, the bandwidth weight of task Task m,n (t) can be expressed by the following formula

[0161]

[0162] Thus, the latency for the task to be transmitted from edge server m to edge server u can be expressed as

[0163]

[0164] Compared with the cloud data center, the capabilities of edge servers are limited. Therefore, when the burst traffic is large, there is task accumulation on edge servers, that is, tasks need to experience queuing delays. To provide differentiated services for type-1 and type-2 tasks, the computing scheduling queue of each edge server is proposed to be divided into two virtual queues: the Type-1 queue and the Type-2 queue, corresponding to type-1 and type-2 tasks respectively.

[0165] Let denote the length of the Type-1 queue of edge server u when task Task m,n (t) arrives at edge server u. Then the queuing delay of this task on edge server u can be expressed as

[0166]

[0167] where denotes the sum of the CPU cycles of all tasks in the queuing queue, denotes the proportion of task Task k migrated to edge server u, denotes the computing resources allocated by edge server u to the Type-1 queue.

[0168] The computing delay of task Task m,n (t) on edge server u is

[0169]

[0170] Therefore, the end-to-end delay of task Task m,n (t) migrating from edge server m to edge server u for computing is the sum of the transmission delay, queuing delay, and computing delay, that is

[0171]

[0172] Since the waiting energy consumption is much lower than the transmission energy consumption and computing energy consumption, this embodiment only considers the transmission energy consumption and computing energy consumption of migrated tasks. Therefore, the energy consumption of task Task m,n (t) migrating from edge server m to edge server u is the sum of the transmission energy consumption from server m to server u and the computing energy consumption of the task on server u, which can be expressed as

[0173]

[0174] where the transmission energy consumption is

[0175]

[0176] The computing energy consumption is

[0177]

[0178] Similarly, for task Task m,n the end - to - end delay for migrating task Task(t) from edge server m to edge server z for processing is

[0179]

[0180] wherein, represents the transmission delay, represents the queuing delay, represents the computing delay.

[0181] For task Task m,n the energy consumption for migrating task Task(t) from edge server m to edge server z for processing is

[0182]

[0183] wherein, represents the transmission energy consumption, represents the computing energy consumption.

[0184] Due to the integrity of the task and the parallelism of subtask execution, for task Task m,n (t), the end - to - end delay is the maximum delay experienced by its subtasks, that is

[0185]

[0186] And for task Task m,n (t), the energy consumption is the sum of the energy consumptions of the two subtasks, that is

[0187]

[0188] Note that when u = m or z = m, the transmission delay and transmission energy consumption of the corresponding subtask are zero.

[0189] 3) Unified description

[0190] According to the above analysis, the end - to - end delay of task Task m,n (t) as the first - type task can be uniformly expressed as

[0191]

[0192] wherein, is determined by (1 - 14), is determined by (1 - 26).

[0193] The corresponding energy consumption can be uniformly described as

[0194]

[0195] Among them, is determined by (1-17), is determined by (1-27).

[0196] (2) The second type of task

[0197] Assume that the task Task m,n (t) is the second type of task. Whether the second type of task is processed on the edge server or in the cloud data center, the task does not need to be split.

[0198] 1) Cloud computing model

[0199] Similar to the first type of task, when the main edge server (edge server m) determines to migrate the task to the cloud data center for processing, the task will generate a transmission delay from the main edge to the cloud data center and a computing delay of the task in the cloud data center.

[0200] The task transmission delay and the computing delay model in the cloud data center are similar to the cloud computing model of the first type of task. Therefore, (1-14) and (1-17) can be used to represent the end-to-end delay and the total energy consumption of migrating the task to the cloud data center respectively.

[0201] 2) Edge computing model

[0202] Different from the first type of task, the second type of task does not need to be split when processed on any edge server. Assume that the main edge server m determines to assign the task to the neighbor edge server u for processing. At this time, there is

[0203] The end-to-end delay of the task is mainly the task migration delay from the main server m to the neighbor server u, that is

[0204]

[0205] Among them, can be determined by (1-22), but since the second type of task enters the Type-2 queue, the queuing delay and computing delay models of the task are different from those of the first type of task.

[0206] Let the computing resource assigned by the edge server u to the second type of task be Let represent the length of the Type-2 queue when the task arrives. Therefore, as the second type of task, the task Task m,n (t)'s queuing delay and computing delay are respectively

[0207]

[0208] and

[0209]

[0210] Task m,n (t)'s energy consumption is mainly the energy consumption during its migration from the main server m to the neighbor server u for processing, mainly including transmission energy consumption and computing energy consumption, that is

[0211]

[0212] Among them, can be determined by (1 - 23) (as the second type of task,

[0213] 3) Unified description

[0214] According to the above analysis, Task m,n (t)'s end - to - end delay as the second type of task can be uniformly expressed as

[0215]

[0216] Among them, is determined by (1 - 14), is determined by (1 - 30).

[0217] The corresponding energy consumption can be uniformly described as

[0218]

[0219] Among them, is determined by (1 - 17), is determined by (1 - 33).

[0220] In summary, for Task m,n (t), its end - to - end delay can be uniformly expressed as

[0221]

[0222] Then the average end - to - end delay of the system at time slot t can be defined as

[0223]

[0224] Task m,n (t), the energy consumed can be uniformly expressed as

[0225]

[0226] The energy consumption of the system at time slot t is the energy consumption of the system for processing all tasks in this time slot, so it can be defined as

[0227]

[0228] As can be seen from the above analysis, the computing migration decision of the task and the priorities of the edge server for scheduling the first type and the second type of tasks have a direct impact on the end-to-end delay of the task and the system energy consumption. Therefore, this embodiment mainly studies how to minimize the system energy consumption on the premise of meeting the end-to-end delay differentiated service requirements of the task by optimizing the computing migration decision and resource configuration strategy of the distributed edge server. Thus, the optimization objective equation of this embodiment can be constructed as

[0229] Minimize:

[0230]

[0231] Constraints:

[0232]

[0233]

[0234]

[0235]

[0236]

[0237]

[0238] Among them, and t = 0,..., ∞ are decision variables. Constraints (1 - 41) indicate that the end-to-end delay of the first type of task cannot exceed the threshold d T1 ; Condition (1 - 42) is the computing power limit condition of the edge server; Constraints (1 - 43) - (1 - 46) are the stability conditions of edge server u, where (1 - 43) and (1 - 44) respectively represent the stability conditions of the Type-1 queue and the Type-2 queue of this edge server from the perspective of the number of tasks, and are defined as

[0239]

[0240] and

[0241]

[0242] Evolve over time as

[0243]

[0244] Among them, Denote the number of Type-1 tasks processed by edge server u in time slot t.

[0245] The evolution over time is

[0246]

[0247] where Denote the number of Type-2 tasks processed by edge server u in time slot t.

[0248] (1-45) and (1-46) respectively represent the stability conditions of the Type-1 queue and Type-2 queue of this edge server from the perspective of task load, and the definitions are as follows

[0249]

[0250] and

[0251]

[0252] The evolution over time is

[0253]

[0254] The evolution over time is

[0255]

[0256] This embodiment analyzes the stability of the system based on the Lyapunov stability theory. The Lyapunov stability theory was founded by the Russian mathematician and mechanician A.M. Lyapunov in 1892 for analyzing the stability of systems. It can be applied to analyze the stability of linear systems and nonlinear systems, time-invariant systems and time-varying systems, and is a commonly used stability analysis method. The Lyapunov function is a function used to demonstrate the stability of the system and plays an important role in stability and control theory. In a system with multiple queues, the Lyapunov function is usually represented by the sum of the squares of the backlogs of the queues evolving over time. The change of the Lyapunov function from one time slot to the next is called the Lyapunov drift. The Lyapunov drift is mainly used in the optimal control of queuing networks, aiming to stabilize the created network queues and optimize certain performance objectives.

[0257] Let represent the task load queue vector of the system in time slot t, and let L(t) represent the Lyapunov function of the task load queue, which is defined as:

[0258]

[0259] Then, the further Lyapunov drift function of \(Q_{\omega}(t)\) is defined as:

[0260] \(\Delta L(t)=E[L(t + 1)-L(t)|Q_{\omega}(t)]\)

[0261] Since the purpose of this embodiment is to find an optimized computing migration strategy The task splitting strategy of the first type of tasks in edge computing and the computing resources allocated to the Type-1 queue and Type-2 queue in the edge server, on the premise of meeting the strict end-to-end delay of the first type of tasks, minimize the system energy consumption. Therefore, the system energy consumption \(E(t)\) per time slot is added as a penalty function to the Lyapunov drift function of the system task load queue, that is, the Lyapunov drift plus penalty function of the system task load is defined as \(\Delta L(t)+VE[E(t)|Q_{\omega}(t)]\), where \(V>0\) represents the Lyapunov control parameter.

[0262] According to the Lyapunov stability theory, if \(\Delta L(t)+VE[E(t)|Q_{\omega}(t)]\) can be controlled to change in the negative direction, then the queue \(Q_{\omega}\) will be stable and an optimized system energy consumption \(E[E(t)]\) can be obtained. Therefore, in the edge-cloud collaborative task scheduling method described in this embodiment, the optimized migration strategy The task splitting strategy of the first type of tasks in edge computing and the computing resources of the Type-1 queue and Type-2 queue in the edge server and the configuration strategy can minimize \(\Delta L(t)+LE[E(t)|Q_{\omega}(t)]\) on the premise of ensuring the delay requirements of the first type of tasks.

[0263] In this embodiment, a queue model as Figure 3 shown is adopted. The IoT terminals of each edge subsystem upload tasks to the main server. The main edge server performs a computing migration strategy according to the type of tasks and the system state to determine whether to migrate, where to migrate, and how much to migrate, that is, to determine and Then, if migration is determined, the main edge server transmits the task to the corresponding neighbor edge subsystem or cloud data center according to the migration strategy. After the migrated task arrives, the corresponding edge subsystem puts the task into the corresponding queue. The first type of computing tasks enter the Typye-1 queue, and the second type of tasks enter the Type-2 queue. When the edge server is idle, it executes task processing scheduling to decide which queue's task to process, that is, to determine and and dequeue the head task of the queue for processing.

[0264] In addition, this embodiment also evaluates the performance of the edge-cloud collaborative task scheduling method based on stability theory through experiments. First, the experimental parameters are introduced, then the influence of the Lyapunov control parameter V on energy consumption and system stability is evaluated, and then the performance of the edge-cloud collaborative task scheduling method based on stability theory in terms of ensuring strict delay requirements for the first type of tasks and reducing system energy consumption is evaluated by comparing it with other algorithms.

[0265] To evaluate the effectiveness of the edge-cloud collaborative task scheduling method based on stability theory described in this embodiment, this method is intended to be compared with three algorithms, namely Cloud-greedy, Edge-greedy, and EnergyMin-greedy. The working principles of these three algorithms are as follows.

[0266] Cloud-greedy: In the computing migration decision of the main edge server, whether it is the first type of task or the second type of task, it is migrated to the cloud data center for processing. That is,

[0267] Edge-greedy: The following computing migration decision is adopted: (1) For the first type of task, let represent the set of edge servers that meet the delay requirements of the first type of task. Then, the task is migrated to the edge servers with the minimum and the second minimum energy consumption for processing; (2) For the second type of task, the task is migrated to the edge server with the minimum energy consumption for processing. The scheduling of Type-1 and Type-2 queue tasks on the edge server is the same as that of the method in this embodiment.

[0268] EnergyMin-greedy: The following computing migration decision is adopted: (1) For the first type of task, let represent the set composed of all edge servers or cloud data centers that meet the delay requirements of the first type of task. If the cloud data center in it can provide the minimum energy consumption, then the task is migrated to the cloud data center for processing; otherwise, the task is migrated to the edge servers with the minimum and the second minimum energy consumption in the set G for processing; if the set is empty, then the task is migrated to the node with the minimum energy consumption for processing. For example, if the cloud data center has the minimum energy consumption, it is migrated to the cloud data center; otherwise, it is split and migrated to the edge servers with the first and the second lowest energy consumption for processing; (2) For the second type of task, select the edge server or cloud data center with the minimum energy consumption and migrate the task to this service node for processing. The task scheduling of Type-1 and Type-2 queues on the edge server also adopts the scheduling method in this embodiment.

[0269] The edge computing system used in the experiment consists of three edge subsystems and one cloud data center, as Figure 1As shown. A base station, an edge server, and several Internet of Things terminals are deployed in each edge subsystem; the edge servers of all edge subsystems are neighbor nodes to each other; all tasks forwarded by the edge servers to the cloud data center for processing are transmitted through the bottleneck link between the unified router and the cloud data center. Other experimental parameters are shown in Table 1.

[0270] Table 1 Simulation Experiment Parameters

[0271]

[0272] (1) Influence of Control Parameter V on Performance

[0273] First, evaluate the influence of the value of control parameter V on the performance of the method in this embodiment. The tasks in the queue of this embodiment are processed in the first-come-first-served manner. The average delay of the system tasks can be represented by the ratio of the queue length (total cumulative load of tasks) to the average service capacity of the system (CPU rate), and the average service capacity of the system is constant. Therefore, the change in the average delay of the system tasks actually reflects the change in the system queue length and can be used as a performance indicator to measure the system stability. Therefore, in the simulation experiment, this embodiment uses the average delay as the performance indicator to measure the system stability and the average service quality of tasks. The optimization results of the edge-cloud collaborative task scheduling method in this embodiment for the system average delay and energy consumption under different control parameters V are as Figure 4 shown.

[0274] From Figure 4 it can be intuitively seen that the system energy consumption increases with the increase of the V value, while the average delay decreases with the increase of the V value, indicating that the energy consumption optimization problem under the delay (queue stability) constraint is a non-convex optimization problem. The decrease in energy consumption is at the cost of the increase in average delay, and the decrease in average delay is at the cost of the increase in energy consumption. When V is greater than a certain value (in this experiment, when V > 60), the energy consumption and delay change slowly and gradually tend to be stable, indicating that by controlling the value of parameter V, the edge-cloud collaborative task scheduling method in this embodiment can achieve an equilibrium between minimizing energy consumption, guaranteeing the delay of the first type of tasks, and minimizing the average delay.

[0275] (2) Comparison of Algorithm Performance under Different Task Rates

[0276] First, evaluate the adaptability of the algorithm to the task generation rate. Keeping other parameters unchanged, change the generation rate of the first type of tasks in the simulation experiment, and then observe the changes in the delay guarantee rate, average end-to-end delay, task completion rate, and system energy consumption of the above four algorithms. The experimental results are as Figure 5 shown.

[0277] In Figure 5In (a), the first-class task delay guarantee rate (the ratio between the number of tasks with actual delay lower than the delay bound and the total number of tasks) of the four algorithms all decreases as the generation rate of the first-class tasks increases. In particular, when all IoT terminals of all edge subsystems only generate first-class tasks (each IoT terminal generates 1 first-class task per time slot), the first-class task delay guarantee rate of the Cloud-greedy algorithm drops to zero. In other words, the actual end-to-end delay of all tasks exceeds the delay requirement.

[0278] The EnergyMin-greedy algorithm is superior to the Cloud-greedy and Edge-greedy algorithms in terms of the first-class task delay guarantee rate. This is because the Cloud-greedy algorithm ignores the delay requirements of the first-class tasks and migrates all tasks to the cloud data center for processing. Under the bottleneck link resource constraints, the tasks experience a long communication delay. Although the Edge-greedy algorithm is a delay-aware algorithm, since it only makes decisions between edge servers and aims to minimize energy consumption, when the load of the first-class tasks is high (for example, λ T1 > 0.2), the Type-1 queue will have backlogs, causing the waiting time delay of the tasks to increase rapidly, resulting in a rapid decline in the first-class task delay guarantee performance. Although the EnergyMin-greedy algorithm also aims to minimize energy consumption, since it makes computing migration decisions between edge servers and the cloud data center, the first-class task delay guarantee rate performance is superior to the Cloud-greedy and Edge-greedy algorithms.

[0279] The first-class task delay guarantee rate of the edge-cloud collaborative task scheduling method in this embodiment is significantly better than the other three algorithms. In particular, under various different task rates, the edge-cloud collaborative task scheduling method in this embodiment can always ensure that the first-class task delay guarantee rate is close to 1. This is because the edge-cloud collaborative task scheduling method in this embodiment always makes migration decisions for the first-class tasks on the premise of delay guarantee, and through the setting of the control parameter V, it achieves a balance between energy consumption and system stability.

[0280] It is precisely because the edge-cloud collaborative task scheduling method in this embodiment needs to balance the energy consumption and stability of the system on the premise of ensuring that the system delay meets the requirements, so in Figure 5In the energy consumption change curve shown in (d), the energy consumption of the edge-cloud collaborative task scheduling method in this embodiment is not the lowest, but it is still lower than the Edge-greedy and EnergyMin-greedy algorithms. Among these four algorithms, the algorithm with the lowest energy consumption is the Cloud-greedy algorithm. This is because the unit energy consumption value of the cloud data center is lower than that of the edge server, and the processing duration of tasks in the cloud data center is shorter. In addition, the energy consumption of wired network transmission is not very high. Therefore, the energy consumption of this algorithm is relatively low. However, migrating tasks to the cloud data center for processing requires long-distance transmission and a long transmission delay. Therefore, the Cloud-greedy algorithm cannot provide strict delay guarantees for the first type of tasks. For example, under the Cloud-greedy algorithm, the delay guarantee rate of the first type of tasks decreases linearly as the generation rate of the first type of tasks increases (as shown in Figure 5 (a)).

[0281] As the rate of the first type of tasks increases, the average end-to-end delay of the edge-cloud collaborative task scheduling method in this embodiment is significantly lower than that of the other three algorithms (as shown in Figure 5 (b)). This is because the average end-to-end delay is directly affected by the queue length. The longer the queue length, the greater the delay, and vice versa. The edge-cloud collaborative task scheduling method in this embodiment reduces the average end-to-end delay of tasks by controlling the queue length. However, since the other three algorithms do not control the queue length, some tasks may be migrated to edge servers with longer queues for execution, thus experiencing longer queuing delays.

[0282] In terms of the task completion rate, under various generation rates of the first type of tasks, the edge-cloud collaborative task scheduling method and the Cloud-greedy algorithm in this embodiment can ensure that all tasks generated during the simulation can be processed during the simulation. However, the Edge-greedy and EnergyMin-greedy algorithms cannot. This is because the Cloud-greedy, Edge-greedy, and EnergyMin-greedy algorithms are all non-queue-length-aware algorithms. Since there is sufficient cloud resources, the Cloud-greedy algorithm can ensure that all tasks can be processed during the simulation. However, the Edge-greedy and EnergyMin-greedy algorithms will migrate tasks to queues with long lengths, resulting in serious backlogs in the queues of some edge servers and "starving" low-priority tasks that arrive later. Therefore, these two algorithms cannot ensure that all tasks generated during the simulation can be processed during the simulation. The edge-cloud collaborative task scheduling method in this embodiment is a queue-length-aware algorithm. The computing migration decision in each time slot takes into account the queue length of the system and takes system stability as one of the decision optimization goals. Therefore, it can make the system stable, that is, make the queue length finite, and thus can provide a 100% task completion rate.

[0283] (3) Algorithm performance comparison under different task sizes

[0284] Next, evaluate the adaptability of the algorithm to task sizes. Keeping other parameters unchanged, change the size of the second type of tasks in the simulation experiment, and then observe and analyze the changes in the Type-1 task delay guarantee rate, average end-to-end delay, task completion rate, and system energy consumption of the edge-cloud collaborative task scheduling method in this embodiment and the other three algorithms. The experimental results are as Figure 6 shown.

[0285] When other parameters remain unchanged, increasing the task size of the second type of tasks is equivalent to increasing the system's traffic load and increasing the competition for resources such as bandwidth and computing between the first type of tasks and the second type of tasks. Therefore, in the experimental results shown in Figure 6 (a), the Type-1 task delay guarantee rate of all algorithms decreases as the size of the second type of tasks increases. In particular, when the size of the second type of tasks reaches 1 Mb / task, the Type-1 task delay guarantee rate of the Cloud-greedy algorithm drops to 0, which means that the end-to-end delay of all Type-1 tasks exceeds the delay bound. This is because in the Cloud-greedy algorithm, as the size of the second type of tasks increases, the bandwidth resources of the bottleneck link of the cloud data center allocated to each task decrease, resulting in an increase in the transmission delay of the task with the task size (as shown in Figure 6 (b)), which is likely to cause the delay to exceed the delay bound.

[0286] Since the Edge-greedy algorithm only makes computing migration decisions among edge servers and aims to minimize energy consumption, its performance in terms of latency is lower than that of the edge-cloud collaborative task scheduling method and the EnergyMin-greedy algorithm in this embodiment. In Figure 6 (a), when the task size is greater than 1 Mb / task, the latency guarantee rate of the Edge-greedy algorithm also starts to decline rapidly. After the task size reaches 4 Mb / task, the latency guarantee rate also drops to 0. From Figure 6 (b), it can also be seen that the average end-to-end latency of the Edge-greedy algorithm is lower than that of the above two algorithms. Moreover, since the Edge-greedy algorithm does not consider the stability of the system, the queue length increases rapidly with the increase of the task size, resulting in a rapid decline in the task completion rate (the ratio between the number of tasks processed and completed and the total number of tasks) during the simulation (see Figure 6 (c)). Not only that, since the unit computing energy consumption of edge servers is higher than that of cloud computing, and the services are all processed at the network edge, with the increase of the Type-2 task size, its energy consumption also increases rapidly. Especially when the task size is greater than 1.5 Mb / task, its energy consumption and the rising rate are significantly higher than those of the other three evaluation algorithms (see Figure 6 (d)).

[0287] Under various task sizes, the edge-cloud collaborative task scheduling method and the EnergyMin-greedy algorithm in this embodiment have similar performance in terms of average end-to-end latency (see Figure 6 (b)), task completion rate (see Figure 6 (c)) and energy consumption (see Figure 6 (d)). However, in terms of the strict latency guarantee for the first type of tasks, the edge-cloud collaborative task scheduling method in this embodiment is superior to the EnergyMin-greedy algorithm, mainly reflected in the fact that the edge-cloud collaborative task scheduling method in this embodiment is more stable. For example, in the experimental results shown in Figure 6 (a), when the task size is between 1 Mb / task and 2 Mb / task, due to the emergence of abnormal services, the latency guarantee rate of the first type of tasks of the EnergyMin-greedy algorithm suddenly drops to 0.2, but the edge-cloud collaborative task scheduling method in this embodiment can still ensure that the latency guarantee rate of the first type of tasks is higher than 0.9.

[0288] From as shown in Figure 6From the experimental results shown in (a), when the size of Type-2 tasks is less than 1 Mb / task, the system load is light, which means the load on the edge server is also light. At this time, the edge server has sufficient resources to ensure the strict latency requirements of the first type of tasks. Therefore, the Edge-greedy algorithm, the EnergyMin-greedy algorithm, and the edge-cloud collaborative task scheduling method in this embodiment can all provide a 100% latency guarantee rate for the first type of services. However, as the size of the second type of tasks continues to increase, the system load becomes heavier, and the computing resources of the edge server and the bottleneck link resources of the cloud data center can no longer meet the service requirements of all tasks. Therefore, when the size of the second type of tasks is greater than 1 Mb / task, the latency guarantee rate of the Edge-greedy algorithm for the first type of tasks drops rapidly and gradually reaches zero. However, the EnergyMin-greedy algorithm and the DGEM algorithm will migrate more tasks to the cloud data center for processing to reduce the system energy consumption (EnergyMin-greedy algorithm) or balance the system energy consumption and latency (the edge-cloud collaborative task scheduling method in this embodiment). Therefore, when the size of the second type of tasks is 1.5 Mb / task, the computing migration strategies of these two algorithms are adjusted significantly, resulting in mutations in their average end-to-end latency, latency guarantee rate, and energy consumption performance. However, because the edge-cloud collaborative task scheduling method in this embodiment can balance between system energy consumption and latency, it can always provide a latency guarantee rate of more than 90% for the first type of tasks, proving the effectiveness of this algorithm.

[0289] (4) Performance comparison of algorithms under different latency bounds

[0290] Finally, evaluate the adaptability of the algorithm to the latency bounds of the first type of tasks. Similarly, keeping other parameters unchanged, change the size of the latency bounds in the simulation experiment, and then observe and analyze the changes in the latency guarantee rate, average end-to-end latency, task completion rate, and system energy consumption of the edge-cloud collaborative task scheduling method in this embodiment and the other three algorithms for Type-1 tasks. The experimental results are as Figure 7 shown.

[0291] From the experimental results shown in Figure 7 (a), it can be seen that when the latency bound changes from 1 ms to 10 ms, the edge-cloud collaborative task scheduling method in this embodiment can still make the latency guarantee rate always close to 1 by dynamically adjusting the computing migration strategy and the task scheduling algorithm. The latency guarantee rate of Cloud-greedy increases as the latency bound increases. This is mainly due to the statistical characteristics of the latency bound. In fact, the computing migration decision does not change with the change of the latency bound, and from Figure 7As can also be seen from FIGS. 7(d) and 7(b), the system energy consumption and the average end-to-end delay remain consistent under different delay bounds, further verifying this view.

[0292] Although the Edge-greedy and EnergyMin-greedy algorithms can also automatically adjust the computing migration strategy according to the change of the delay bound, since they both target energy consumption, their delay guarantee capabilities and average delay performances are lower than those of the edge-cloud collaborative task scheduling method in this embodiment.

[0293] In terms of task completion rate, similarly, the edge-cloud collaborative task scheduling method and Cloud-greedy in this embodiment can almost ensure that all tasks generated during the simulation can be processed during the simulation. However, the Edge-greedy and EnergyMin-greedy algorithms cannot (as shown in Figure 7 FIG. 7(c)), further verifying the effectiveness of the edge-cloud collaborative task scheduling method in this embodiment in terms of ensuring queue stability.

[0294] Embodiment 2

[0295] As Figure 8 shown, this embodiment provides an edge-cloud collaborative task scheduling system based on stability theory for a mobile edge computing system. The mobile edge computing system includes a plurality of edge servers and a cloud data center, and includes:

[0296] A task receiving module 100, configured to receive tasks uploaded by corresponding Internet of Things terminals by an edge server;

[0297] A migration module 200, configured to calculate a migration strategy for an edge server and execute the migration strategy. Specifically, executing the migration strategy means determining whether to migrate a task according to the migration strategy, and when it is determined to migrate the task, further determining to migrate the task to a neighbor edge server or a cloud data center of the edge server, so that the neighbor edge server or the cloud data center processes the migrated task;

[0298] A task processing module 300, configured to process the un-migrated tasks received by the edge server itself and the migrated tasks of the neighbor edge servers;

[0299] Wherein, the migration strategy is to minimize the sum of the Lyapunov drift function and the penalty function of the edge computing system on the premise of ensuring the task delay requirement. The Lyapunov drift function is calculated according to the task load queue of the edge computing system, and the penalty function is calculated according to the energy consumption of task migration in the edge computing system.

[0300] Specifically, let Let \(Q_{\omega}(t)\) denote the task load queue vector of the system at time slot \(t\), and let \(L(t)\) denote the Lyapunov function of the task load queue, which is defined as:

[0301]

[0302] Then the further Lyapunov drift function of \(Q_{\omega}(t)\) is defined as:

[0303] \(\Delta L(t)=E[L(t + 1)-L(t)|Q_{\omega}(t)]\)

[0304] Add the system energy consumption \(E(t)\) per time slot as a penalty function to the Lyapunov drift function of the system task load queue, that is, define the Lyapunov drift plus penalty function of the system task load as \(\Delta L(t)+VE[E(t)|Q_{\omega}(t)]\), where \(V>0\) represents the Lyapunov control parameter.

[0305] According to the Lyapunov stability theory, if \(\Delta L(t)+VE[E(t)|Q_{\omega}(t)]\) can be controlled to change in the negative direction, then the queue \(Q_{\omega}\) will be stable and an optimized system energy consumption \(E[E(t)]\) can be obtained. Therefore, in this embodiment, the determined migration strategy can minimize the sum of the Lyapunov drift function and the penalty function \(\Delta L(t)+VE[E(t)|Q_{\omega}(t)]\) of the edge computing system on the premise of ensuring the delay requirements of the first type of tasks.

[0306] Furthermore, the tasks include the first type of tasks and the second type of tasks, and the delay requirements of the first type of tasks are higher than those of the second type of tasks;

[0307] In the task processing module 300, the edge server processes the un - migrated tasks received by itself and the migrated tasks of the neighbor edge servers, specifically including:

[0308] The edge server sets a first queue and a second queue for storing tasks;

[0309] The edge server sequentially puts the received first - type tasks at the tail of the first queue and the received second - type tasks at the tail of the second queue;

[0310] The edge server determines a task scheduling strategy and sequentially schedules the first - type tasks from the head of the first queue for processing or sequentially schedules the second - type tasks from the head of the second queue for processing according to the task scheduling strategy.

[0311] Furthermore, the edge server determines a task scheduling strategy and sequentially schedules the first - type tasks from the head of the first queue for processing or sequentially schedules the second - type tasks from the head of the second queue for processing, specifically including:

[0312] The edge server obtains the length of the first queue and the length of the second queue

[0313] When the length of the first queue and the length of the second queue at this time, the following rules are used to determine the cumulative service weight η of the first queue in the edge server:

[0314]

[0315] The following rules are used to determine the task scheduling policy variable π according to the cumulative service weight η m (t) value:

[0316]

[0317] wherein, represents the load of the first queue in the edge server u, represents the load of the second queue in the edge server u, Pr{π m (t)=0} represents the probability that π m (t)=0, Pr{π m (t)=1} represents the probability that π m (t)=1;

[0318] When the length of the first queue and the length of the second queue at this time, the task scheduling policy variable π m (t)=0;

[0319] When the length of the second queue and the length of the first queue at this time, the task scheduling policy variable π m (t)=1;

[0320] When the task scheduling policy variable π m (t)=0, it means that the edge server schedules and processes the first type of tasks in sequence from the head of the first queue according to the task scheduling policy;

[0321] When the task scheduling policy variable π m (t)=1, it means that the edge server schedules and processes the second type of tasks in sequence from the head of the second queue according to the task scheduling policy.

[0322] Furthermore, in the migration module 200, the edge server calculates the migration policy and executes the migration policy. According to the migration policy, it determines whether to migrate the task, specifically including:

[0323] When the task received by the edge server is a type-1 task, the edge server calculates the first migration strategy, calculates the task splitting strategy at the same time, splits the task according to the splitting strategy, and determines whether to migrate the split task according to the first migration strategy;

[0324] When the task received by the edge server is a type-2 task, the edge server calculates the second migration strategy and determines whether to migrate the task according to the second migration strategy.

[0325] Furthermore, the first migration strategy and the task splitting strategy satisfy:

[0326]

[0327]

[0328]

[0329] where t represents a time slot, represents the set of edge servers, m, u, represents the set of Internet of Things terminals corresponding to edge server m, V represents the Lyapunov control parameter, E(t) represents the system energy consumption, represents the load of the first queue in edge server u, represents the migration strategy variable, represents the task splitting strategy variable, χ represents the number of CPU cycles required to process one byte of the task, S m,n (t) represents the task data volume, k represents a computing node, represents the set of computing nodes, represents that the task is migrated to the cloud data center for processing, d T1 represents the delay threshold of the type-1 task, represents the end-to-end delay of the type-1 task in edge server g, represents the set of edge servers that meet the delay requirements of the type-1 task;

[0330] The second migration strategy satisfies:

[0331]

[0332]

[0333] Embodiment 3

[0334] This embodiment provides a computer device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the edge-cloud collaborative task scheduling method in Embodiment 1.

[0335] Embodiment 4

[0336] This embodiment provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the edge-cloud collaborative task scheduling method in Embodiment 1.

[0337] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the technical solutions of the present invention, rather than limitations on the specific implementation manners of the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the claims of the present invention shall be included within the protection scope of the claims of the present invention.

Claims

1. A method for edge-cloud collaborative task scheduling based on stability theory, which is used for an edge computing system. The edge computing system includes a number of edge servers and a cloud data center. Characterized in that, It includes: The edge server receives tasks uploaded by corresponding Internet of Things terminals. The tasks include first-class tasks and second-class tasks, and the latency requirement of the first-class tasks is higher than that of the second-class tasks. The edge server calculates the migration policy and executes the migration policy. Specifically, when executing the migration policy, it determines whether to migrate the task according to the migration policy. When the task received by the edge server is a first type of task, the edge server calculates the first migration policy, calculates the task segmentation policy at the same time, segments the task according to the segmentation policy, and determines whether to migrate the segmented task according to the first migration policy; the first migration policy and the task segmentation policy Satisfy: Among them, represents a time slot, represents a set of edge servers, , represents an edge server corresponding to a set of Internet of Things terminals, , represents a Lyapunov control parameter, represents the system energy consumption, represents an edge server in the load of the first queue, represents a migration policy variable, represents a task splitting policy variable, represents the number of CPU cycles required to process one byte of task, represents the task data volume, represents a computing node, represents a set of computing nodes, represents that the task is migrated to the cloud data center for processing, represents the first type of task delay threshold, represents an edge server in the end-to-end delay of the first type of task, represents a set of edge servers that meet the delay requirements of the first type of task; And when it is determined to migrate the task, it is further determined to migrate the task to a neighbor edge server or the cloud data center of the edge server, so that the neighbor edge server or the cloud data center processes the migrated task. The edge server processes the un-migrated tasks received by itself and the migrated tasks of the neighbor edge servers. Among them, the migration strategy is to minimize the sum of the Lyapunov drift function and the penalty function of the edge computing system on the premise of ensuring the latency requirement of the task. The Lyapunov drift function is calculated according to the task load queue of the edge computing system, and the penalty function is calculated according to the energy consumption of task migration in the edge computing system.

2. A method for edge-cloud collaborative task scheduling based on stability theory according to claim 1, Characterized in that, When the edge server processes the un-migrated tasks received by itself and the migrated tasks of the neighbor edge servers, it specifically includes: The edge server sets a first queue and a second queue for storing tasks. The edge server sequentially puts the received first-class tasks at the end of the first queue and the received second-class tasks at the end of the second queue. The edge server determines a task scheduling strategy and sequentially schedules the first-class tasks from the head of the first queue for processing or sequentially schedules the second-class tasks from the head of the second queue for processing according to the task scheduling strategy.

3. A method for edge-cloud collaborative task scheduling based on stability theory according to claim 2, Characterized in that, When the task received by the edge server is a second-class task, the edge server calculates a second migration strategy and determines whether to migrate the task according to the second migration strategy.

4. A method for edge-cloud collaborative task scheduling based on stability theory according to claim 3, Characterized in that, The second migration strategy Satisfies: 。 5. A method for edge-cloud collaborative task scheduling based on stability theory according to claim 2, Characterized in that, When the edge server determines a task scheduling strategy and sequentially schedules the first-class tasks from the head of the first queue for processing or sequentially schedules the second-class tasks from the head of the second queue for processing, it specifically includes: The edge server obtains the first queue length and the second queue length ; When the length of the first queue and the length of the second queue are as follows, the cumulative service weight of the first queue in the edge server is determined according to the following rules : Determine the value of the task scheduling policy variable according to the following rules based on the cumulative service weight as follows: Among them, represents the load of the first queue in the edge server u, represents the load of the second queue in the edge server u, represents the probability of represents the probability of; When the first queue length and the second queue length the task scheduling policy variable ; When the second queue length and the first queue length the task scheduling policy variable ; When the task scheduling policy variable is satisfied, it means that the edge server schedules and processes the first type of tasks in sequence from the head of the first queue according to the task scheduling policy; When the task scheduling policy variable is in this state, it means that the edge server schedules and processes the second type of tasks in sequence from the head of the second queue according to the task scheduling policy.

6. An edge-cloud collaborative task scheduling system based on stability theory, which is used for a mobile edge computing system. The mobile edge computing system includes a number of edge servers and a cloud data center. Characterized in that, It includes: A task receiving module, which is used for the edge server to receive tasks uploaded by corresponding Internet of Things terminals; the tasks include first-class tasks and second-class tasks, and the latency requirement of the first-class tasks is higher than that of the second-class tasks; A migration module, which is used for the edge server to calculate a migration strategy and execute the migration strategy. Specifically, executing the migration strategy means determining whether to migrate the task according to the migration strategy, and when it is determined to migrate the task, further determining to migrate the task to a neighbor edge server or a cloud data center of the edge server, so that the neighbor edge server or the cloud data center processes the migrated task; Among them, when the task received by the edge server is a first-class task, the edge server calculates a first migration strategy, simultaneously calculates a task splitting strategy, splits the task according to the splitting strategy, and determines whether to migrate the split task according to the first migration strategy; The first migration strategy and the task splitting strategy satisfy: Among them, represents a time slot, represents a set of edge servers, , represents an edge server corresponding to the set of Internet of Things terminals, , represents the Lyapunov control parameter, represents the system energy consumption, represents the edge server load of the first queue in, represents the migration policy variable, represents the task splitting policy variable, represents the number of CPU cycles required to process one byte of task, represents the task data volume, represents a computing node, represents a set of computing nodes, represents that the task is migrated to the cloud data center for processing, represents the first type of task delay threshold, represents the edge server end-to-end delay of the first type of task in, represents the set of edge servers that meet the delay requirements of the first type of task; A task processing module, which is used for the edge server to process the un-migrated tasks received by itself and the migrated tasks of the neighbor edge servers; Among them, the migration strategy is to minimize the sum of the Lyapunov drift function and the penalty function of the edge computing system on the premise of ensuring the latency requirement of the task. The Lyapunov drift function is calculated according to the task load queue of the edge computing system, and the penalty function is calculated according to the energy consumption of task migration in the edge computing system.

7. A edge-cloud collaborative task scheduling system based on stability theory according to claim 6, characterized in that, In the task processing module, when the edge server processes the un-migrated tasks received by itself and the migrated tasks of the neighbor edge servers, it specifically includes: The edge server sets a first queue and a second queue for storing tasks; The edge server sequentially puts the received first-class tasks at the tail of the first queue, and sequentially puts the received second-class tasks at the tail of the second queue; The edge server determines a task scheduling strategy, and schedules the first-class tasks in sequence from the head of the first queue for processing or schedules the second-class tasks in sequence from the head of the second queue for processing according to the task scheduling strategy.

8. A edge-cloud collaborative task scheduling system based on stability theory according to claim 7, characterized in that, When the task received by the edge server is a second-class task, the edge server calculates a second migration strategy and determines whether to migrate the task according to the second migration strategy.

9. A computer device, including a memory and a processor, the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the edge-cloud collaborative task scheduling method according to any one of claims 1 to 5.

10. A computer-readable storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by a processor, it implements the edge-cloud collaborative task scheduling method according to any one of claims 1 to 5.

Images