A reliable edge network cloud collaborative task scheduling method, system and device for computing power endogenous scenarios and a storage medium

Abstract

The application discloses a reliable edge network cloud cooperative task scheduling method and system for computing power endogenous scene, equipment and storage medium, and relates to the field of mobile communication. Including: for the first scheduling period, according to the total CPU core number of the base station and the CPU core number occupied by the communication task, the endogenous available CPU core number and the time delay reservation coefficient of the base station are determined; according to the single CPU core computing capacity of the base station, the time delay reservation coefficient, the queuing delay estimation value and the task parameter value of each received task, the effective schedulable time limit and the required minimum CPU core number of each task are determined; according to the required minimum CPU core number and the endogenous available CPU core number, the base station local task set and the remote network cloud node task set are determined; the base station uses the endogenous available CPU core number to execute the base station local task set and schedule the remote network cloud node to execute the remote network cloud node task set, so as to form an efficient cooperative closed loop among the three of "cloud-edge-end".

Description

Technical Field

[0001] This invention relates to the field of mobile communications, and in particular to a reliable edge-network-cloud collaborative task scheduling method, system, device, and storage medium for scenarios with inherent computing power. Background Technology

[0002] As the intelligence level of terminals continues to increase, various low-latency and high-real-time services are rapidly growing in wireless access scenarios. When many terminal devices run services such as video analysis, industrial inspection, real-time recognition, augmented reality, and edge inference, they are often limited by local computing power, power consumption, and storage capacity, making it difficult to complete task processing independently. Therefore, it is necessary to offload the tasks to computing nodes closer to the access side or cloud-side nodes further away for execution.

[0003] While traditional cloud computing offers powerful computing capabilities, its long transmission path and high propagation latency between the terminal and the remote cloud center make it unsuitable for latency-sensitive tasks. Edge computing alleviates this problem to some extent by offloading computing resources to the network edge. However, in real-world deployments, the number and resource capacity of ordinary edge nodes are limited, and the load, link status, and processing capabilities of different nodes vary significantly. This makes task offloading and resource allocation highly dynamic, hindering the formation of an efficient collaborative closed loop between the cloud, edge, and terminal. Summary of the Invention

[0004] Based on the above-mentioned technical problems, the present invention provides a reliable edge-network-cloud collaborative task scheduling method, system, device and storage medium for computing power endogenous scenarios, aiming to overcome the above problems or at least partially solve the above problems.

[0005] The first aspect of this invention provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, the method comprising: The number of endogenously available CPU cores of the base station in the first scheduling period is determined based on the total number of CPU cores of the base station and the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period. The latency reservation coefficient of the base station in the first scheduling period is determined based on the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period and the total number of CPU cores of the base station. Based on the computing power of a single CPU core of the base station, the latency reservation coefficient and queuing latency estimate of the base station in the first scheduling period, and the task parameter values ​​of each task received by the base station in the first scheduling period, determine the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the first scheduling period. Based on whether the minimum number of CPU cores required is greater than the number of endogenously available CPU cores of the base station in the first scheduling period, for each task received by the base station in the first scheduling period, determine the base station local task set and the remote network cloud node task set for the first scheduling period. The base station uses its own inherent available CPU cores within the first scheduling period to execute each task in the base station local task set of the first scheduling period, and the base station schedules remote network cloud nodes to execute each task in the remote network cloud node task set of the first scheduling period.

[0006] A second aspect of the present invention provides a reliable edge-network-cloud collaborative task scheduling system for scenarios with inherent computing power, the system comprising: The intrinsic determination module is used to determine the number of intrinsically available CPU cores of the base station in the first scheduling period based on the total number of CPU cores of the base station and the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period. The coefficient determination module is used to determine the delay reservation coefficient of the base station in the first scheduling period based on the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period and the total number of CPU cores of the base station. The minimum number of cores determination module is used to determine the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the first scheduling period based on the computing power of a single CPU core of the base station, the delay reservation coefficient and queuing delay estimate of the base station in the first scheduling period, and the task parameter values ​​of each task received by the base station in the first scheduling period. The set determination module is used to determine the base station local task set and the remote network cloud node task set for each task received by the base station in the first scheduling period, based on whether the minimum number of CPU cores required is greater than the number of endogenously available CPU cores of the base station in the first scheduling period. The task scheduling module is used by the base station to execute each task in the base station local task set of the first scheduling period using its own internally available CPU cores within the first scheduling period, and by the base station to schedule remote network cloud nodes to execute each task in the remote network cloud node task set of the first scheduling period.

[0007] A third aspect of the present invention provides an electronic device, the electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein when the program or instructions are executed by the processor, the steps of the reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios as described in the first aspect of the present invention are implemented.

[0008] A fourth aspect of the present invention provides a readable storage medium storing a program or instructions, wherein when the program or instructions are executed by a processor, the program or instructions implement the steps of the reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios as described in the first aspect of the present invention.

[0009] In the reliable edge-cloud collaborative task scheduling method for scenarios with inherent computing power proposed in this invention, the resource dynamism of the base station with inherent computing power is considered. In scenarios where the base station simultaneously undertakes communication processing and general computing tasks, the inherent available computing power (i.e., resource quantity) that can be used for general task processing is dynamically represented by the difference between the total number of CPU cores of the base station and the number of CPU cores occupied by communication tasks (i.e., the number of inherently available CPU cores). This allows the scheduling decision to adapt to the communication load changes in each scheduling cycle. Furthermore, based on the number of CPU cores occupied by communication tasks and the total number of CPU cores of the base station, this invention determines the latency reservation coefficient of the base station. Based on the computing power of a single CPU core of the base station, the latency reservation coefficient of the base station, the estimated queuing latency, and the task parameter values ​​of each task received by the base station, the minimum number of CPU cores required for each task received by the base station is determined. Then, based on the minimum number of CPU cores required for the task and the number of inherently available CPU cores of the base station, the local task set of the base station and the task set of the remote network cloud node are determined and executed. This ensures that the received tasks are executed locally at the base station as much as possible, thereby improving the efficiency of near-end resource utilization while forming an efficient collaborative closed loop among the cloud, edge, and terminal. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating the steps of a reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios, as shown in an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the dynamic change of endogenous available computing power with communication load according to an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the implementation process of a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, as shown in an embodiment of the present invention. Figure 4 This is a flowchart illustrating a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, as shown in an embodiment of the present invention. Figure 5This is a schematic diagram illustrating an implementation scenario of reliable edge-network-cloud collaborative task scheduling for computing power-inherent scenarios, as shown in an embodiment of the present invention. Figure 6 This is a flowchart illustrating the steps of a reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios, as shown in an embodiment of the present invention. Figure 7 This is a schematic diagram illustrating another implementation scenario of reliable edge-network-cloud collaborative task scheduling for computing power-inherent scenarios, as shown in one embodiment of the present invention. Figure 8 This is a flowchart illustrating the steps of another reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios, as shown in one embodiment of the present invention. Figure 9 This is a schematic diagram illustrating a process for allocating remote tasks based on a hybrid discrete optimization method, as shown in an embodiment of the present invention. Figure 10 This is a structural block diagram of a reliable edge-network-cloud collaborative task scheduling system for computing power-inherent scenarios, provided by an embodiment of the present invention. Figure 11 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0012] 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, not all, of the embodiments of the present invention. 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.

[0013] Regarding current cloud-edge-device collaborative technologies, this invention has found that with the development of virtualized wireless access networks, general-purpose server base stations, and hardware-software decoupling technologies, base stations no longer merely perform communication access functions but possess the fundamental conditions to run general-purpose computing tasks. Since base station equipment is typically configured according to peak communication service capacity, a certain proportion of computing resources remain idle during off-peak periods. These resources can be scheduled to execute terminal tasks, thereby forming intrinsic computing power. Compared to ordinary network cloud nodes, base stations are closer to terminals and have shorter transmission links, theoretically making them more suitable for handling latency-sensitive tasks.

[0014] Furthermore, this invention takes into account that the general computing resources of a base station are not fixed. The base station must first ensure the processing of communication services, and changes in communication load directly affect the amount of computing resources available for general tasks. When communication services surge, the resources previously available for general tasks may rapidly decrease. If task scheduling is still performed from a static resource perspective, it can easily lead to widespread timeouts for local tasks. Simultaneously, if a large number of tasks are simply forwarded to remote network cloud nodes when resources are scarce, it may cause link congestion and queuing at remote nodes, further reducing the task latency constraint satisfaction rate.

[0015] Based on this, in order to at least partially solve one or more of the above-mentioned problems and other potential problems, this invention proposes a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. This method, in scenarios where base stations simultaneously undertake communication processing and general computing tasks (i.e., scenarios with inherent computing power at the base station), considers the dynamic sharing of computing and communication resources at the base station. For each scheduling cycle, the method dynamically represents the inherent available computing power (i.e., resource quantity) available for general task processing by the difference between the total number of CPU cores at the base station and the number of CPU cores occupied by communication tasks in the current scheduling cycle (i.e., the number of inherently available CPU cores). This allows the scheduling decision to adapt to changes in communication load in each scheduling cycle. Furthermore, this invention... Based on the number of CPU cores occupied by communication tasks and the total number of CPU cores of the base station, the latency reservation coefficient of the base station is determined. Based on the computing power of a single CPU core of the base station, the latency reservation coefficient of the base station, the estimated queuing latency, and the task parameter values ​​of each task received by the base station, the minimum number of CPU cores required for each task received by the base station is determined. Then, based on the minimum number of CPU cores required for the task and the number of endogenously available CPU cores of the base station in the current scheduling period, the local task set of the base station and the task set of the remote network cloud node in the current scheduling period are determined and executed. This is to place the received tasks locally at the base station as much as possible, thereby improving the efficiency of near-end resource utilization under the premise of forming an efficient collaborative closed loop among the "cloud-edge-device".

[0016] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating the steps of a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, as shown in an embodiment of the present invention. Figure 1 As shown, the reliable edge-network-cloud collaborative task scheduling method for computing power-endogenous scenarios provided in this embodiment includes at least the following steps: Step S11: Determine the number of endogenously available CPU cores of the base station in the first scheduling period based on the total number of CPU cores of the base station and the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period.

[0017] This embodiment proposes an end-base station-network cloud collaborative architecture to receive, filter, allocate, and control the execution of computing tasks among terminal devices, base stations, and remote network cloud nodes. The terminal device generates tasks to be processed; it is a device that generates computing tasks and connects to the base station via a wireless access link. The base station is a radio transceiver station that transmits and receives wireless communication signals through a mobile communication switching center within a certain radio coverage area, ensuring normal communication for mobile devices. In this embodiment, the base station performs both wireless access and communication processing functions and possesses general computing capabilities, making it an endogenous computing power node. Endogenous computing power can be viewed as a concept that organically integrates computing power into various aspects of the system architecture, making computing power exist naturally within the system as if it were inherent, achieving efficient allocation and utilization of computing resources. The remote network cloud node connects to the base station through a bearer network and is used to undertake remote tasks offloaded by the base station.

[0018] In one embodiment, the terminal device includes any one or more of the following: a wireless terminal, an industrial terminal, a video acquisition terminal, or other terminals with access capabilities.

[0019] In this embodiment, the first scheduling period can be any scheduling period, such as the current scheduling period. The scheduling period is a discrete time window for periodically executing task reception, status awareness, sorting, node selection, and resource allocation. The base station can read the total number of CPU cores of the base station and the number of CPU cores occupied by communication tasks within the first scheduling period. Based on the total number of CPU cores of the base station and the number of CPU cores occupied by communication tasks within the first scheduling period, the base station determines the number of intrinsically available CPU cores within the first scheduling period. This allows the base station to obtain its resource status within the current scheduling period before scheduling, thus providing input for subsequent local filtering and remote allocation.

[0020] In this embodiment, the total number of CPU cores in the base station remains constant, but the number of CPU cores occupied by the base station's communication tasks changes dynamically in different scheduling periods. Therefore, the number of intrinsically available CPU cores in the base station also changes dynamically in different scheduling periods. In other words, the intrinsically available computing power of the base station is not a fixed value, but changes dynamically with the communication load.

[0021] In one optional example, the number of intrinsically available CPU cores of the base station during the first scheduling period is the difference between the total number of CPU cores of the base station and the number of CPU cores occupied by communication tasks of the base station during the first scheduling period. For example, the number of intrinsically available CPU cores of the base station during scheduling period t. for: ;in, This represents the total number of CPU cores in the base station. This represents the number of CPU cores used by the base station for communication tasks within the scheduling period t. For example... Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the dynamic change of endogenously available computing power with varying communication load, as shown in an embodiment of the present invention. Figure 2 In this context, the base station can monitor communication load, specifically for a scheduling period t, by analyzing the total number of CPU cores in the base station. The number of CPU cores used by communication tasks with base stations (i.e., the number of cores used by communication tasks). The number of natively available CPU cores in the base station is calculated. Then, the available computing power is read through the scheduling module.

[0022] Step S12: Determine the latency reservation coefficient of the base station in the first scheduling period based on the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period and the total number of CPU cores of the base station.

[0023] In this embodiment, to improve scheduling robustness, a delay reservation coefficient is introduced to reserve safe time during scheduling. This delay reservation coefficient can be determined based on the total number of CPU cores of the base station and the number of CPU cores occupied by the base station's communication tasks within the first scheduling period. It is understood that the delay reservation coefficient in this embodiment also changes dynamically with the number of CPU cores occupied by the base station's communication tasks in different scheduling periods.

[0024] In another optional example, the delay reservation factor can be a fixed value or can be adaptively set according to communication load, link status, or historical timeout rate.

[0025] Step S13: Based on the computing power of a single CPU core of the base station, the latency reservation coefficient and queuing latency estimate of the base station in the first scheduling period, and the task parameter values ​​of each task received by the base station in the first scheduling period, determine the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the first scheduling period.

[0026] In this embodiment, one or more terminal devices send tasks to be processed to the base station via a wireless access link. The base station receives task requests uploaded by each terminal device within a first scheduling period, parses the task requests, and obtains each task received by the base station within the first scheduling period, as well as the task parameter values ​​of each task received by the base station within the first scheduling period. The base station can read the computing power of a single CPU core of the base station and the estimated queuing delay value of the base station within the first scheduling period.

[0027] For each task received by the base station within the first scheduling period, the base station can determine the effective schedulable time limit for that task within the first scheduling period based on the base station's latency reservation coefficient within the first scheduling period and the task parameter values ​​received by the base station within the first scheduling period. This effective schedulable time limit represents the maximum allowable latency of the task with sufficient safety time reserved.

[0028] Furthermore, the base station can determine the minimum number of CPU cores required for a task received by the base station within the first scheduling period based on the computing power of a single CPU core, the latency reservation coefficient of the base station within the first scheduling period, the estimated queuing latency of the base station within the first scheduling period, and the task parameter values ​​of the task received by the base station within the first scheduling period. This minimum number of CPU cores represents the minimum computing power resources required to ensure that the task meets its corresponding effective schedulable time limit when executed locally at the base station. Therefore, for each task received by the base station within the first scheduling period, the effective schedulable time limit of each task and the minimum number of CPU cores required for each task are obtained.

[0029] Step S14: Based on whether the minimum number of CPU cores required is greater than the number of endogenously available CPU cores of the base station in the first scheduling period, determine the base station local task set and the remote network cloud node task set for each task received by the base station in the first scheduling period.

[0030] In this embodiment, the minimum number of CPU cores required for each task received by the base station in the first scheduling period can be compared with the number of internally available CPU cores of the base station in the first scheduling period to determine whether the minimum number of CPU cores required for the task is greater than the number of internally available CPU cores of the base station in the first scheduling period, so as to determine the base station local task set and the remote network cloud node task set in the first scheduling period.

[0031] Specifically, if the minimum number of CPU cores required for a task is not greater than (i.e., less than or equal to) the number of internally available CPU cores of the base station in the first scheduling period, it can be determined that the task meets the basic conditions for entering the base station's local task set. The task is then included in the base station's local task set for the first scheduling period, so that the received tasks are executed locally at the base station as much as possible. If the minimum number of CPU cores required for a task is greater than the number of internally available CPU cores of the base station in the first scheduling period, it can be determined that the task does not meet the basic conditions for entering the base station's local task set. The task is then included in the remote network cloud node task set for the first scheduling period. Thus, for each task received by the base station in the first scheduling period, the base station's local task set and the remote network cloud node task set for the first scheduling period are determined based on whether the minimum number of CPU cores required is greater than the number of internally available CPU cores of the base station in the first scheduling period.

[0032] Step S15: The base station uses its own intrinsic available CPU cores in the first scheduling period to execute each task in the base station local task set of the first scheduling period, and the base station schedules remote network cloud nodes to execute each task in the remote network cloud node task set of the first scheduling period.

[0033] In this embodiment, for the base station local task set in the first scheduling period, the base station can use its own internally available CPU cores in the first scheduling period to execute each task in the base station local task set in the first scheduling period; for the remote network cloud node task set in the first scheduling period, the base station schedules the remote network cloud node to execute each task in the remote network cloud node task set in the first scheduling period, thereby completing the task allocation and execution in the first scheduling period.

[0034] It should be noted that, for each scheduling cycle, this embodiment can complete the task allocation and execution of the task cycle according to the above steps S11-S15, so as to realize the efficient collaborative closed loop among the "cloud-edge-device" in each scheduling cycle.

[0035] In this embodiment, considering the dynamic nature of the base station's inherent computing power resources, in scenarios where the base station simultaneously undertakes communication processing and general computing tasks, the inherent available computing power for general task processing is dynamically represented by the difference between the total number of CPU cores of the base station and the number of CPU cores occupied by communication tasks (i.e., the number of inherently available CPU cores). This allows scheduling decisions to adapt to changes in communication load during each scheduling cycle. Furthermore, based on the number of CPU cores occupied by communication tasks and the total number of CPU cores of the base station, the base station's latency reservation coefficient is determined. Based on the computing power of a single CPU core of the base station, the base station's latency reservation coefficient, the estimated queuing latency, and the task parameter values ​​of each task received by the base station, the minimum number of CPU cores required for each task received by the base station is determined. Then, based on the minimum number of CPU cores required for the task and the base station's inherently available CPU cores, the base station's local task set and the remote network cloud node task set are determined and executed. This ensures that the received tasks are executed locally at the base station as much as possible, thereby improving the efficiency of near-end resource utilization while forming an efficient collaborative closed loop among the "cloud-edge-device" triad.

[0036] In conjunction with the above embodiments, in one implementation, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. In this method, step S12 may specifically include the following steps: Determine the ratio of the number of CPU cores used by the communication tasks of the base station in the first scheduling cycle to the total number of CPU cores of the base station. If the ratio is less than the first threshold, the delay reservation coefficient of the base station in the first scheduling period is determined as the first delay reservation coefficient; When the ratio is between the first threshold and the second threshold, the delay reservation coefficient of the base station in the first scheduling period is determined as the second delay reservation coefficient, the second delay reservation coefficient is greater than the first delay reservation coefficient, and the second threshold is greater than the first threshold; If the ratio is greater than the second threshold, the delay reservation coefficient of the base station in the first scheduling period is determined as the third delay reservation coefficient, and the third delay reservation coefficient is greater than the second delay reservation coefficient.

[0037] In this embodiment, to improve scheduling robustness under dynamic load scenarios, an adaptive latency reservation coefficient setting method is adopted. Specifically, this embodiment sets the latency reservation coefficient in segments according to the communication occupancy ratio. In this embodiment, a first threshold and a second threshold are preset, and the second threshold is greater than the first threshold; the specific values ​​of the two thresholds are not limited. In this embodiment, the higher the communication occupancy ratio, the larger the experimental reservation coefficient.

[0038] For example, in a specific example, the first threshold can be 0.4, the second threshold can be 0.6, and the first delay reservation coefficient, the second delay reservation coefficient, and the third delay reservation coefficient can be 0.08, 0.12, and 0.18, respectively.

[0039] In conjunction with the above embodiments, in one implementation, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. In this method, step S14 may specifically include steps S21 to S25: Step S21: For each task received by the base station in the first scheduling period, if the minimum number of CPU cores required for the task is not greater than the number of endogenously available CPU cores of the base station in the first scheduling period, then add the task to the local candidate task set of the base station.

[0040] In this embodiment, for each task received by the base station during the first scheduling period, if the minimum number of CPU cores required for the task is not greater than the number of internally available CPU cores of the base station during the first scheduling period, then the task is determined to meet the basic conditions for entering the base station's local task set, and the task is added to the base station's local candidate task set. Conversely, if the minimum number of CPU cores required for the task is greater than the number of internally available CPU cores of the base station during the first scheduling period, then the task is determined not to meet the basic conditions for entering the base station's local task set, and the task is directly added to the remote network cloud node task set.

[0041] Step S22: Determine the priority score of each task based on the maximum allowable latency, input data volume, and difficulty of each task in the local candidate task set of the base station.

[0042] In this embodiment, after the base station obtains the local candidate task set, in order to further determine the priority among the tasks that meet the basic conditions, it can determine the priority score of each task in the local candidate task set based on the maximum allowable latency of the task, the amount of input data of the task, and the difficulty of the task, thereby obtaining the priority score of each task in the local candidate task set.

[0043] In one optional example, for tasks in the local candidate task set of the base station Maximum allowable latency of the task Characterizes the task The urgency, the amount of input data for the task This indicates the task. Workload, tasks Difficulty It can be expressed as the number of CPU cycles required per unit of data in the task. This embodiment can combine the maximum allowable latency of the task, the amount of input data of the task, and the difficulty of the task to obtain the priority score of the task.

[0044] In an optional specific example, determine the normalized metric for task workload. for:

[0045] Normalized indicators for determining task urgency for:

[0046] Normalized index for determining task difficulty for:

[0047] in, Represents the set of all tasks. This represents the index of any task other than task k in set K.

[0048] Define a task Priority rating for:

[0049] Step S23: Add the tasks in the local candidate task set of the base station to the local task set in order of priority score from high to low.

[0050] In this embodiment, the base station can add tasks from the local candidate task set to the local task set in descending order of priority score.

[0051] Step S24: After each task is added to the base station's local task set, determine the remaining number of internally available CPU cores of the base station. If the minimum number of CPU cores required for the next task is less than the remaining number of internally available CPU cores of the base station, then add the next task to the base station's local task set until the number of internally available CPU cores of the base station in the first scheduling period is fully allocated.

[0052] In this embodiment, during the process of adding tasks from the local candidate task set to the local task set in descending order of priority score, the remaining number of internally available CPU cores of the base station is determined after each task is added. The remaining number of internally available CPU cores of the base station is equal to the number of internally available CPU cores of the base station in the first scheduling period before the task was added, minus the minimum number of CPU cores required for the task. For example, after adding the task with the highest priority score to the local task set, the remaining number of internally available CPU cores of the base station after adding the first task is equal to the number of internally available CPU cores of the base station in the first scheduling period, minus the minimum number of CPU cores required for the task with the highest priority score; after adding the task with the second highest priority score to the local task set, the remaining number of internally available CPU cores of the base station after adding the second task is equal to the number of internally available CPU cores of the base station after adding the first task, minus the minimum number of CPU cores required for the task with the second highest priority score; and so on.

[0053] After each task is added to the base station's local task set, it is determined whether the minimum number of CPU cores required for the next task is less than the determined number of remaining intrinsically available CPU cores of the base station. If the minimum number of CPU cores required for the next task is less than the number of remaining intrinsically available CPU cores of the base station, the next task is added to the base station's local task set. If the minimum number of CPU cores required for the next task is not less than the number of remaining intrinsically available CPU cores of the base station, the addition of the next task to the base station's local task set is stopped, and it is determined that the number of intrinsically available CPU cores of the base station in the first scheduling period has been allocated, thus obtaining the final base station local task set.

[0054] Step S25: Add each task that has not been added to the base station local task set to the remote network cloud node task set.

[0055] In this embodiment, tasks that were not added to the base station local task set are added to the remote network cloud node task set. The tasks not added to the base station local task set include: tasks that do not meet the basic requirements for entering the base station local task set and are directly added to the remote network cloud node task set; and tasks in the local candidate task set that were not added to the base station local task set.

[0056] In this embodiment, tasks are sorted according to their priority scores based on their maximum allowable latency, input data volume, and difficulty, resulting in a local execution priority ranking. Subsequently, the base station, following the sorting order and considering its remaining endogenously available computing power, uses a greedy algorithm to sequentially determine whether a task should be added to the base station's local task set. Tasks not included in the base station's local task set are assigned to the remote network cloud node's task set.

[0057] In conjunction with any of the above embodiments, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios. In addition to the steps described above, this method may further include steps S31 to S32: Step S31: If the number of CPU cores occupied by the communication tasks of the base station in the second scheduling period is greater than the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period, then reduce the number of endogenously available CPU cores of the base station in the first scheduling period to obtain the number of endogenously available CPU cores of the base station in the second scheduling period, and increase the delay reservation coefficient of the base station in the first scheduling period to obtain the delay reservation coefficient of the base station in the second scheduling period; based on the computing power of a single CPU core of the base station, the number of endogenously available CPU cores of the base station in the second scheduling period, the delay reservation coefficient and the estimated queuing delay, and the task parameter values ​​of each task received by the base station in the second scheduling period, determine the base station local task set and the remote network cloud node task set for the second scheduling period. The total number of tasks in the base station local task set for the second scheduling period is less than the total number of tasks in the base station local task set for the first scheduling period.

[0058] In this embodiment, the second scheduling period is the next scheduling period after the first scheduling period. The base station can read the number of CPU cores occupied by the communication tasks in the second scheduling period and compare the number of CPU cores occupied by the communication tasks in the second scheduling period with the number of CPU cores occupied by the communication tasks in the first scheduling period. If the number of CPU cores occupied by the communication tasks in the second scheduling period is greater than the number of CPU cores occupied by the communication tasks in the first scheduling period, it is determined that the current communication load of the base station is increased. Then, the number of intrinsically available CPU cores of the base station in the first scheduling period is reduced to obtain the number of intrinsically available CPU cores of the base station in the second scheduling period, and the delay reservation coefficient of the base station in the first scheduling period is increased to obtain the delay reservation coefficient of the base station in the second scheduling period.

[0059] It is understandable that the number of intrinsically available CPU cores of a base station in the second scheduling cycle equals the total number of CPU cores of the base station minus the number of CPU cores occupied by communication tasks during the second scheduling cycle. As the number of CPU cores occupied by communication tasks increases, the number of intrinsically available CPU cores of the base station decreases. Furthermore, the higher the communication load, the lower the intrinsically available computing power of the base station; therefore, the latency reservation level should be increased to improve the robustness of local filtering and remote optimization.

[0060] In this embodiment, the base station local task set for the second scheduling period and the remote network cloud node task set for the second scheduling period can be determined based on the computing power of a single CPU core of the base station, the number of endogenously available CPU cores of the base station in the second scheduling period, the latency reservation coefficient and the estimated queuing latency, and the task parameter values ​​of each task received by the base station in the second scheduling period. The total number of tasks in the base station local task set for the second scheduling period is less than the total number of tasks in the base station local task set for the first scheduling period.

[0061] In other words, when the communication load increases, the base station's internal available computing power decreases, so some tasks that could originally be reliably executed locally at the base station will be assigned to the remote execution set.

[0062] In one embodiment, the base station local task set and the remote network cloud node task set for the second scheduling period can be determined based on steps that are the same as or similar to those in steps S13 to S14 described above. Specifically, the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the second scheduling period can be determined based on the computing power of a single CPU core of the base station, the latency reservation coefficient of the base station in the second scheduling period, the estimated queuing latency of the base station in the second scheduling period, and the task parameter values ​​of each task received by the base station in the second scheduling period. Then, based on whether the minimum number of CPU cores required is greater than the number of endogenously available CPU cores of the base station in the second scheduling period, the base station local task set and the remote network cloud node task set for the second scheduling period are determined for each task received by the base station in the second scheduling period.

[0063] Step S32: If the number of CPU cores occupied by the communication tasks of the base station in the second scheduling period is less than the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period, then increase the number of endogenously available CPU cores of the base station in the first scheduling period to obtain the number of endogenously available CPU cores of the base station in the second scheduling period, and decrease the delay reservation coefficient of the base station in the first scheduling period to obtain the delay reservation coefficient of the base station in the second scheduling period; based on the computing power of a single CPU core of the base station, the number of endogenously available CPU cores of the base station in the second scheduling period, the delay reservation coefficient and the estimated queuing delay, and the task parameter values ​​of each task received by the base station in the second scheduling period, determine the base station local task set and the remote network cloud node task set for the second scheduling period. The total number of tasks in the base station local task set for the second scheduling period is greater than the total number of tasks in the base station local task set for the first scheduling period.

[0064] In this embodiment, if the number of CPU cores occupied by the communication tasks of the base station in the second scheduling period is less than the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period, it is determined that the current communication load of the base station is reduced. Then, the number of endogenous available CPU cores of the base station in the first scheduling period is increased to obtain the number of endogenous available CPU cores of the base station in the second scheduling period. In addition, the delay reservation coefficient of the base station in the first scheduling period is decreased to obtain the delay reservation coefficient of the base station in the second scheduling period.

[0065] It is understandable that the number of intrinsically available CPU cores of a base station in the second scheduling cycle equals the total number of CPU cores of the base station minus the number of CPU cores occupied by communication tasks during the second scheduling cycle. A decrease in the number of CPU cores occupied by communication tasks increases the number of intrinsically available CPU cores. Furthermore, lower communication loads result in higher intrinsically available computing power for the base station; therefore, the latency reservation level should be reduced to improve the robustness of local filtering and remote optimization.

[0066] In this embodiment, the base station local task set for the second scheduling period and the remote network cloud node task set for the second scheduling period can be determined based on the computing power of a single CPU core of the base station, the number of endogenously available CPU cores of the base station in the second scheduling period, the latency reservation coefficient and the estimated queuing latency, and the task parameter values ​​of each task received by the base station in the second scheduling period. The total number of tasks in the base station local task set for the second scheduling period is greater than the total number of tasks in the base station local task set for the first scheduling period.

[0067] In other words, when the communication load decreases, the base station's internally available computing power increases, thus allowing more tasks to enter the local execution set. In one embodiment, the base station local task set and the remote network cloud node task set for the second scheduling period can be determined using steps that are the same as or similar to those in step S31 described above.

[0068] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. In this method, the task parameter values ​​include at least: maximum allowable latency, difficulty, and input data volume; and step S13 above may specifically include steps S41 to S42: Step S41: Based on the delay reservation coefficient of the base station in the first scheduling period and the maximum allowable delay of the k-th task received by the base station within the first scheduling period. According to the formula Determine the effective schedulable time limit for the k-th task received by the base station within the first scheduling period. .

[0069] In this embodiment, the task parameter values ​​include at least: the maximum allowable delay of the task, the difficulty of the task, and the amount of input data for the task. To improve scheduling robustness, a delay reservation coefficient is introduced based on the maximum allowable delay of the task to reserve safe time during scheduling.

[0070] Specifically, the delay reservation coefficient of the base station in the first scheduling cycle can be used as a reference. And, the maximum allowable delay of the k-th task received by the base station within the first scheduling period. According to the formula Determine the effective schedulable time limit for the k-th task received by the base station within the first scheduling period. .in, , , This refers to the set of tasks received by the base station during the first scheduling period. This indicates the total number of tasks received by the base station during the first scheduling period.

[0071] Step S42: Based on the computing power of a single CPU core in the base station 1. Base station queuing delay estimate during the first scheduling period And the difficulty of the k-th task received by the base station in the first scheduling period. Input data volume Effective schedulable time limit According to the formula Determine the minimum number of CPU cores required for the k-th task received by the base station within the first scheduling period. .

[0072] In this embodiment, the computing power of a single CPU core of the base station can be used as a basis. 1. Base station queuing delay estimate during the first scheduling period The difficulty of the k-th task received by the base station in the first scheduling period The amount of input data received by the base station for the k-th task within the first scheduling period. And, the effective schedulable time limit of the k-th task received by the base station within the first scheduling period. According to the formula Determine the minimum number of CPU cores required for the k-th task received by the base station within the first scheduling period. ,in, This indicates rounding up to the nearest integer.

[0073] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. In this method, the number of remote network cloud nodes is multiple; and the step S15 above, "the base station schedules remote network cloud nodes to execute various tasks in the remote network cloud node task set for the first scheduling period," specifically includes steps S51 to S57: Step S51: The base station initializes P candidate allocation schemes and uses the P candidate allocation schemes as the initial positions of P particles. Based on the initial positions of the P particles, the base station determines the initial reliability priority cost function value of each of the P particles and initializes the group's historical best position and the individual historical best position of each of the P particles.

[0074] In this embodiment, a hybrid discrete optimization method is used to allocate remote tasks within remote network cloud node tasks. This can be achieved by employing different candidate solution update mechanisms and different inferior solution acceptance mechanisms, or by combining discrete particle swarm optimization (DPSO) with simulated annealing. Specifically, for the method combining DPSO and simulated annealing, at the very beginning (i.e., in the first iteration), P candidate allocation schemes are initialized, and these P schemes are used as the initial positions of P particles; that is, each candidate allocation scheme is represented as a particle's position vector. In other words, in the scenario of "hybrid discrete optimization allocation of remote network cloud nodes," each particle corresponds to one candidate allocation scheme. The particle's position vector represents the allocation relationship between remote tasks and remote network cloud nodes. The candidate allocation scheme includes the correspondence between which remote network cloud nodes each remote task within that remote network cloud node task is assigned to. The k-th element in the particle's position vector represents which remote network cloud node the k-th remote task is currently assigned to. That is: let the k-th element be... The particle in the first Position vector during round iteration for: ;in, For the first The remote network cloud node to which the first remote task is assigned during the round of iteration. For the first During the first iteration Each remote task is assigned to a remote network cloud node, among which... This indicates the number of remote tasks in the remote network cloud node tasks.

[0075] This embodiment determines the initial reliability priority cost function value for each of the P particles based on their initial positions. Then, based on these initial reliability priority cost function values, it obtains the initial collective historical best position and the initial individual historical best position for each of the P particles. The initial reliability priority cost function value is the function value of the reliability priority cost function corresponding to the first iteration round. This embodiment constructs a reliability priority cost function to evaluate the merits of different candidate allocation schemes and guide the updating and retention of candidate allocation schemes accordingly.

[0076] Here, the individual historical optimal position refers to the candidate allocation scheme that a particle has reached up to the current iteration during the iterative search process, which minimizes the value of the reliability-first cost function. The swarm historical optimal position refers to the candidate allocation scheme that all particles have discovered up to the current iteration during the iterative search process, which minimizes the value of the reliability-first cost function.

[0077] In this embodiment, the individual historical best position of each of the P particles is the initial position of each of the P particles, and the initial group historical best position is the initial position of the particle with the smallest initial reliability priority cost function value.

[0078] In addition, each particle will be given an initial velocity in the first iteration.

[0079] Step S52: The base station updates the velocities of P particles in the t-th iteration based on the individual historical best position and the group historical best position in the t-th iteration, and obtains the velocities of P particles in the (t+1)-th iteration.

[0080] In this embodiment, the particle velocity can be updated in each iteration based on the individual historical best position and the group historical best position of each particle. Specifically, in the (t+1)th iteration, the base station can update the velocities of the P particles in the t-th iteration based on their individual and group historical best positions from the t-th iteration, thus obtaining the velocities of the P particles in the (t+1)th iteration, where t is a positive integer. More specifically, the velocities of the P particles in the t-th iteration can be updated based on their individual and group historical best positions from the t-th iteration, thus obtaining the velocities of the P particles in the (t+1)th iteration.

[0081] Step S53: The base station generates P candidate allocation schemes for the (t+1)th iteration based on the velocity of the P particles in the (t+1)th iteration, and uses the P candidate allocation schemes for the (t+1)th iteration as the positions of the P particles in the (t+1)th iteration. Based on the positions of the P particles in the (t+1)th iteration, the reliability priority cost function value of each of the P particles in the (t+1)th iteration is determined.

[0082] In this embodiment, the base station can generate P candidate allocation schemes for the (t+1)th iteration based on the velocities of the P particles in the (t+1)th iteration, and use these P candidate allocation schemes as the positions of the P particles in the (t+1)th iteration. Then, based on the positions of the P particles in the (t+1)th iteration, the reliability priority cost function value of each of the P particles in the (t+1)th iteration is determined. Here, the particle velocity is used to characterize the tendency to change the allocation node according to the corresponding task dimension.

[0083] Step S54: Take p sequentially from 1 to P. If the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is less than the reliability priority cost function value of the p-th particle in the t-th iteration, then retain the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration; if the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is not less than the reliability priority cost function value of the p-th particle in the t-th iteration, then retain the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration with the probability corresponding to the t-th iteration.

[0084] In this embodiment, p is sequentially selected from 1 to P. For the p-th particle, its reliability priority cost function value in the previous iteration and the current iteration is compared. If the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is less than that of the p-th particle in the t-th iteration, then the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration is retained, i.e., the new scheme is accepted.

[0085] In this embodiment, the simulated annealing mechanism is used to accept inferior solutions with a certain probability when a new solution is inferior to the current solution, thereby avoiding premature convergence of the search process to a local optimum. For example, if the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is not less than the reliability priority cost function value of the p-th particle in the t-th iteration, then the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration is retained with the probability corresponding to the t-th iteration.

[0086] Step S55: The base station determines the candidate allocation scheme with the minimum reliability priority cost function value of the p-th particle in each iteration process as the individual historical best position of the p-th particle in the (t+1)-th iteration, and determines the candidate allocation scheme with the minimum reliability priority cost function value of the P particles in each iteration process as the group historical best position in the (t+1)-th iteration.

[0087] In this embodiment, in the (t+1)th iteration, the base station can determine the candidate allocation scheme with the minimum reliability priority cost function value of the p-th particle in each iteration process (i.e., from the 1st iteration to the (t+1)th iteration) as the individual historical optimal position of the p-th particle in the (t+1)th iteration.

[0088] Furthermore, the candidate allocation scheme with the minimum reliability-priority cost function value among the P particles in each iteration is determined as the group's historically optimal position in the (t+1)th iteration. That is, the candidate allocation scheme with the minimum reliability-priority cost function value among all candidate allocation schemes for the P particles in each iteration is determined as the group's historically optimal position in the (t+1)th iteration. For example, if t is 5 and P is 7, then the candidate allocation scheme with the minimum reliability-priority cost function value among the 42 candidate allocation schemes corresponding to 7 particles in 6 iterations can be determined as the group's historically optimal position in the 6th iteration.

[0089] Step S56: Repeat the above steps until the maximum number of iterations is reached to obtain the target allocation scheme.

[0090] In this embodiment, the above steps (i.e., repeating steps S52 to S55) can be repeated until the number of iterations reaches the preset maximum number of iterations. Then, the iteration stops, and the historical optimal position of the group in the iteration round corresponding to the stopping iteration is determined as the target allocation scheme. For example, if the maximum number of iterations is 100, then the historical optimal position of the group in the 100th iteration can be determined as the target allocation scheme.

[0091] In one example, there are a total of 3 remote network cloud nodes, and the task set of the remote network cloud nodes contains 4 remote tasks. The target allocation scheme includes: allocating the 1st remote task to the 2nd remote network cloud node, allocating the 2nd remote task to the 1st remote network cloud node, allocating the 3rd remote task to the 3rd remote network cloud node, and allocating the 4th remote task to the 2nd remote network cloud node.

[0092] Step S57: Based on the target allocation scheme, schedule the remote network cloud nodes to execute each task in the remote network cloud node task set for the first scheduling cycle.

[0093] In this embodiment, the base station can determine the remote tasks corresponding to each of the multiple remote network cloud nodes based on the target allocation scheme, and then schedule each remote network cloud node to execute the remote tasks corresponding to it in the remote network cloud node task set of the first scheduling period.

[0094] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. In this method, step S53, "determining the reliability priority cost function value of each of the P particles in the (t+1)th iteration based on their positions," specifically includes steps S61 to S63: Step S61: The base station determines the CPU core allocation results for each of the multiple remote network cloud nodes based on the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration.

[0095] In this embodiment, for the p-th particle among the P particles in the (t+1)-th iteration, the CPU core allocation results of each of the multiple remote network cloud nodes corresponding to the p-th particle can be determined based on the candidate allocation schemes corresponding to the p-th particle in the (t+1)-th iteration. The CPU core allocation within a node can be achieved using an optimization solution, a heuristic allocation method, or a combination of both.

[0096] Step S62: Based on the CPU core allocation results of each of the multiple remote network cloud nodes, determine the estimated completion time of each task in the task set of the remote network cloud nodes in the first scheduling period.

[0097] In this embodiment, the estimated completion time of each task in the task set of the remote network cloud nodes corresponding to the p-th particle in the first scheduling period can be determined based on the CPU core allocation results of the multiple remote network cloud nodes corresponding to the p-th particle.

[0098] Step S63: Based on the number of timeout tasks, the sum of timeout durations of timeout tasks, the sum of estimated completion delays of each task, and the load difference index of each remote network cloud node under the candidate allocation scheme corresponding to the p-th particle, determine the reliability priority cost function value of the p-th particle in the (t+1)-th iteration.

[0099] In this embodiment, based on the estimated completion delay of each remote task in the remote network cloud node task set corresponding to the p-th particle during the first scheduling period, and the maximum allowed delay of each remote task in the remote network cloud node task set during the first scheduling period, the timeout task under the candidate allocation scheme corresponding to the p-th particle is determined. Wherein, if the estimated completion delay of a remote task is greater than its corresponding maximum allowed delay, then the remote task is a timeout task.

[0100] Then, based on the number of timed-out tasks under the candidate allocation scheme corresponding to the p-th particle, the sum of the timeout durations of the timed-out tasks under the candidate allocation scheme corresponding to the p-th particle, the sum of the estimated completion delays of each task under the candidate allocation scheme corresponding to the p-th particle, and the load difference index value of each remote network cloud node under the candidate allocation scheme corresponding to the p-th particle, the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is determined, and thus the reliability priority cost function values ​​corresponding to each of the P particles in the (t+1)-th iteration are obtained.

[0101] In a specific alternative example, for any candidate allocation scheme Its reliability-first cost function is defined as: ; in: Indicating in candidate allocation schemes The number of timeout tasks; Indicating in candidate allocation schemes The sum of the timeout durations of all timeout tasks; Indicating in candidate allocation schemes The sum of the estimated completion times of all remote tasks; Indicating in candidate allocation schemes Load difference indicators for each remote network cloud node; , , , The weight coefficients are non-negative and satisfy the following conditions: .

[0102] The above weighting relationships indicate that, in the optimization process, this invention prioritizes reducing the number of timeout tasks, then considers reducing the timeout duration, further reduces the total latency, and on this basis improves the load balancing among network cloud nodes.

[0103] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. In this method, the CPU core allocation results for each of the multiple remote network cloud nodes include: the m-th task in the remote network cloud node task set of the first scheduling period is allocated to the i-th remote network cloud node, and the i-th remote network cloud node allocates the m-th task... Each CPU core; and step S62 may specifically include steps S71 to S72: Step S71: Combine the computing power of a single CPU core of the i-th remote network cloud node. The link bandwidth from the base station to the i-th remote network cloud node during the first scheduling period. The estimated queuing delay of the i-th remote network cloud node during the first scheduling period. And, the difficulty of the m-th task. and input data volume According to the formula Determine the estimated completion delay of the m-th task on the i-th remote network cloud node. .

[0104] In this embodiment, m takes values ​​from 1 to... The integer, where i is an integer greater than 0. That is, for the remote network cloud node task set in the first scheduling cycle... For each remote task, the CPU core allocation results of the multiple remote network cloud nodes determined based on the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration include: the m-th remote task is assigned to the i-th remote network cloud node, and the i-th remote network cloud node is the one that assigns the m-th remote task. One CPU core.

[0105] Thus, in this embodiment, the i-th remote network cloud node can be used to allocate resources for the m-th remote task. Each CPU core, combined with the computing power of the i-th remote network cloud node's single CPU core. The link bandwidth from the base station to the i-th remote network cloud node during the first scheduling period. The estimated queuing delay of the i-th remote network cloud node during the first scheduling period. And, the difficulty of the m-th remote task. The amount of input data for the m-th remote task According to the formula Determine the estimated completion delay of the m-th remote task on the i-th remote network cloud node. Thus, this embodiment can obtain the estimated completion delay of each remote task on its corresponding remote network cloud node in the remote network cloud node task set of the first scheduling period.

[0106] Step S72: If the estimated completion delay of the m-th task on the i-th remote network cloud node exceeds the maximum allowable delay of the m-th task. Then, the m-th task is determined to be a timeout task, and the timeout duration of the m-th task is determined as: the estimated completion delay of the m-th task on the i-th remote network cloud node. Maximum allowed latency for the m-th task The difference.

[0107] In this embodiment, if the estimated completion delay of the m-th remote task on the i-th remote network cloud node is... Exceeding the maximum allowed latency of the m-th remote task If so, the m-th remote task is determined to be a timeout task, and the timeout duration of the m-th remote task is determined as: the estimated completion delay of the m-th remote task on the i-th remote network cloud node. Maximum allowed latency with the m-th remote task The difference.

[0108] In one embodiment, following the above examples, after task execution, each execution node feeds back the task execution results and status information to the base station. The base station aggregates the execution results of all tasks, calculates the actual completion latency of each task, and calculates the task latency constraint satisfaction rate for the current scheduling period. The task latency constraint satisfaction rate is the proportion of the number of tasks that meet their maximum allowable latency requirements within a scheduling period to the total number of tasks. That is, based on the actual completion latency and the maximum allowable latency requirements of a task, the number of tasks meeting their maximum allowable latency requirements can be determined, and then the number of tasks meeting their maximum allowable latency requirements can be divided by the total number of tasks to obtain the task latency constraint satisfaction rate. Experimental results show that this embodiment not only prioritizes the low latency advantage of the base station near the network cloud in the end-base station-network cloud collaborative architecture, thus improving the task latency constraint satisfaction rate, but also allocates tasks that cannot be stably executed locally at the base station to remote network cloud nodes. This prioritizes the task latency constraint satisfaction rate while also considering total latency and load balancing, and achieves reliable scheduling of local and remote tasks with the task latency constraint satisfaction rate as the core objective.

[0109] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power. In this method, in addition to the steps described above, it may also include steps S81 to S82, and the step S54 above, "retaining the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration with the probability corresponding to the t-th iteration," specifically includes step S83; the step S52 above specifically includes step S84; and the step S53 above, "the base station generates P candidate allocation schemes in the (t+1)-th iteration based on the velocity of the P particles in the (t+1)-th iteration," specifically includes step S85. Step S81: Set the initial temperature, minimum temperature and temperature attenuation coefficient for the base station.

[0110] In this embodiment, for multiple iterations, the base station can set an initial temperature, a minimum temperature, and a temperature decay coefficient. The initial temperature refers to the temperature parameter at the beginning of the simulated annealing mechanism's remote task allocation search. A higher initial temperature means that even if a new task allocation scheme is slightly worse under the current evaluation, it still has a certain probability of being accepted, thus helping to escape allocation states that are locally optimal but globally unfavorable. The minimum temperature refers to the lowest temperature threshold that the simulated annealing mechanism is allowed to drop to in the later stages of the search. When the temperature drops to near this threshold, the system's probability of accepting a poor task allocation scheme decreases significantly, and the search process tends to converge more stably. In an optional example, besides stopping the iteration when the maximum number of iterations is reached, the iteration can also be stopped when the temperature drops to the minimum, thus obtaining the target allocation scheme. The temperature decay coefficient refers to the percentage decrease in temperature after each iteration; this parameter determines the speed at which the remote task allocation search transitions from "fully exploring different node allocation schemes" to "stable retention of the best allocation scheme."

[0111] Step S82: Based on the initial temperature and the temperature decay coefficient, determine the temperature of the t-th iteration. The temperature of the t-th iteration shall not be less than the minimum temperature.

[0112] In this embodiment, the initial temperature is the temperature of the first iteration. The temperature of the t-th iteration can be determined based on the initial temperature, the temperature decay coefficient, and the number of iterations, and the temperature of the t-th iteration is not less than the minimum temperature.

[0113] Step S83: Determine the reliability priority cost function value of the p-th particle in the (t+1)-th iteration. The reliability priority cost function value of the p-th particle in the t-th iteration is The cost difference between the two is determined to be Based on the temperature and cost difference in the t-th iteration, the probability of retaining the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration is: .

[0114] in, That is, the probability corresponding to the t-th iteration, with this probability Retain the candidate allocation schemes corresponding to the p-th particle in the (t+1)-th iteration. And, That is, the temperature in the t-th iteration.

[0115] In this embodiment, the temperature of each iteration is the current temperature of the particle, which is the current search temperature parameter given to the particle by the simulated annealing mechanism. It is used to control the probability that the particle will accept a poor solution when the new solution is worse than the current solution. When the temperature is higher, the particle is more likely to retain search diversity. When the temperature is lower, the particle is more likely to converge stably to a better solution.

[0116] Step S84: The velocity of the p-th particle in the (t+1)-th iteration. Update according to the following formula: .

[0117] in, This represents element-wise multiplication. Let p be the velocity of the p-th particle in the t-th iteration. Let be the individual historical best position of the p-th particle in the t-th iteration. This represents the group's historical best position in the t-th iteration. Let be the position vector of the p-th particle in the t-th iteration.

[0118] It is understandable that the velocity vector of the P particles in the t-th iteration is: .

[0119] Inertia weight refers to the degree to which a particle retains the current trend of task allocation changes when updating the node allocation scheme. When the inertia weight is large, the direction of change in the current task allocation scheme is more likely to be continued; when the inertia weight is small, the task is more likely to readjust its target network cloud nodes.

[0120] This represents the individual learning parameter; the individual learning parameter refers to the strength with which a particle moves closer to its own historical best task allocation scheme when updating the remote task allocation scheme. The larger this parameter is, the more the current candidate scheme tends to refer to the better task allocation results searched by this particle in the past.

[0121] This represents the group learning parameter; the group learning parameter refers to the strength with which a particle moves closer to the historical best task allocation scheme of all particles when updating the remote task allocation scheme. The larger this parameter is, the more the current candidate scheme tends to refer to the current globally optimal remote task allocation result.

[0122] , This represents the random vector, or random exploration parameter, which indicates the strength of the random allocation attempt introduced when updating the remote task node allocation scheme. This parameter is used to prevent all remote tasks from prematurely concentrating on a few fixed network cloud nodes, thereby maintaining the diversity of candidate allocation schemes.

[0123] Step S85: Based on the velocity of the p-th particle in the (t+1)-th iteration According to the formula The probability of changing the p-th candidate allocation scheme corresponding to the p-th particle Based on the change probability of the p-th candidate allocation scheme corresponding to the p-th particle Generate the p-th candidate allocation scheme in the (t+1)-th iteration.

[0124] In this embodiment, a higher probability of change indicates that the task is more likely to change its target network cloud nodes in this iteration. When a change occurs, the new node allocation result can be determined by a weighted average of the individual's historical best position, the group's historical best position, and random exploration, thus taking into account both historical optimization information and search diversity.

[0125] In an optional example, before assigning remote tasks to remote network cloud nodes, the base station can configure parameters including at least: particle count, maximum number of iterations, inertia weight, individual learning parameters, swarm learning parameters, random exploration parameters, initial temperature, minimum temperature, and temperature decay coefficient. These parameters control the search scope, search depth, update magnitude, and acceptance of inferior solutions for candidate schemes. The particle count refers to the number of candidate remote task node allocation schemes maintained in parallel. A higher particle count indicates more task allocation schemes are examined simultaneously in the same search round, which is beneficial for expanding the search scope of remote task allocation across multiple network cloud nodes. The maximum number of iterations refers to the maximum number of rounds for updating and comparing remote task node allocation schemes. A higher number of iterations indicates that the system allows for more thorough searching and correction of task allocation schemes.

[0126] In one embodiment, such as Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the implementation process of a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, as shown in an embodiment of the present invention. The system in this embodiment includes a terminal device, a base station, and multiple network cloud nodes. The method in this embodiment runs on the scheduling and control module on the base station side (i.e., Figure 3 In the scheduling control and resource awareness module, it is used to receive, filter, allocate and execute computing tasks among various terminal devices, base stations and network cloud nodes to improve the task latency constraint satisfaction rate.

[0127] In one embodiment, a two-stage scheduling mechanism is preferably adopted, which involves "first screening tasks suitable for reliable execution at the near-end base station, and then performing remote optimization allocation on the remaining tasks." The first stage is the local screening stage, used to determine the local task set of the base station and the task set of the remote network cloud nodes; the second stage is the remote optimization stage, used to determine the remote task allocation scheme among multiple remote network cloud nodes, and complete the remote task scheduling based on the CPU core allocation result corresponding to the allocation scheme. By using the two-stage scheduling method of this embodiment to adapt to dynamic changes in communication load, the overall reliability of the system can be improved.

[0128] In one embodiment, such as Figure 4 As shown, Figure 4This is a flowchart illustrating a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, as shown in an embodiment of the present invention. For ease of explanation, the task set within the current scheduling period is assumed to be: ;in, This indicates the total number of tasks within the current scheduling period.

[0129] For any task ( ),definition The amount of input data for the task; This represents the maximum allowable delay for the task. The difficulty of the task; Let the set of remote network cloud nodes be: .in, Indicates the total number of remote network cloud nodes. Indicates the first A remote network cloud node. Record the first... The total number of CPU cores of the remote network cloud nodes is ; For the first The single-core computing power of a remote network cloud node; In the scheduling cycle Inner Queuing delay estimate for each remote network cloud node; remember This represents the total number of CPU cores in the base station. The single-core computing power of a base station; For base stations during scheduling cycles The number of cores used by internal communication tasks.

[0130] exist Figure 4 In this embodiment, the method includes: Step S1: Task Reception and Task Parameter Parsing: For any task The following task parameters are obtained after parsing: the task identifier is denoted as... The amount of input data is denoted as The maximum allowable delay is denoted as Difficulty is recorded as The task type is denoted as The base station performs format verification on the received tasks, removes incomplete or non-compliant abnormal tasks, and forms a set of valid tasks for the current scheduling period. The output of this step is the set of valid tasks for the current scheduling period and their parameters.

[0131] Step S2: Base Station Intrinsic Availability Awareness: After completing task reception, the base station assesses its own status and that of the network cloud nodes. For the base station, this involves reading its total number of CPU cores. Single-core computing power and the number of cores currently used by the communication task Based on this, the endogenous available computing power within the current scheduling cycle can be obtained: For each network cloud node, read its CPU core count. Single-core computing power Link bandwidth and queuing delay estimates The purpose of this step is to obtain the resource status of base stations and network cloud nodes within the current scheduling period before scheduling, thereby providing input for subsequent local filtering and remote allocation. The intrinsic available computing power of the base station is not a fixed value, but changes dynamically with the communication load.

[0132] Step S3: Select the task to be executed locally at the base station: To improve scheduling robustness, a delay reservation coefficient is introduced based on the maximum allowable delay of the task. This is used to reserve safety time during scheduling. Therefore, the effective schedulable time limit for task k is defined as: .in, In order to make the task The effective schedulable time limit is met when the operation is performed locally at the base station. The minimum number of CPU cores required is: Determine whether the local reliable execution conditions are met (i.e., determine...) Is it less than or equal to? ), is (i.e. If yes, add it to the local execution set; otherwise, add it to the remote execution set.

[0133] Step S4: Hybrid Discrete Optimization Allocation of Remote Network Cloud Nodes: Suppose that the set of tasks to be offloaded to remote network cloud nodes for execution after filtering in Step S3 is: ;in, This represents the number of tasks executed remotely. The remote task allocation vector is defined as follows: ,in: Represents the first in the remote task set The task was assigned to the first Each network cloud node performs the task. Since the node allocation problem described above is a discrete combinatorial optimization problem, this invention employs a hybrid discrete optimization method to optimize the allocation vector. Perform a search and output the target allocation scheme.

[0134] Step S5: Construction of the Reliability-First Cost Function: In step S4, to evaluate the merits of different remote task allocation schemes, this embodiment constructs a reliability-first cost function. For any candidate allocation scheme... Its cost function is defined as: ;in, Indicating in the allocation scheme The number of tasks exceeding the latency threshold; Indicating in the allocation scheme The sum of the timeout durations of all timeout tasks; Indicating in the allocation scheme The sum of the completion delays of all tasks; Indicating in the allocation scheme Load difference indicators for each network cloud node; , , , The weight coefficients are non-negative and satisfy the following conditions: .

[0135] Step S6: Final CPU Core Allocation Output and Execution: In step S4, for each candidate remote task allocation scheme, the cost of the candidate scheme has been calculated based on the corresponding node's internal CPU core allocation result, and the optimal remote task allocation scheme (i.e., the target allocation scheme) has been determined accordingly. In step S6, the CPU core allocation result corresponding to the optimal remote task allocation scheme finally output in step S4 is confirmed, output, and executed to form the final resource allocation scheme for remote task execution. Let the task... Assigned to the Each network cloud node is assigned a specific number of nodes. Each CPU core, then the task The completion delay estimate at this node can be expressed as: ; in, Indicates the scheduling period Internal base station to the The link bandwidth of each network cloud node is determined; for each network cloud node, after determining its set of tasks, the CPU core allocation problem within the node is further solved to obtain the final resource allocation result for each task. The output of step S6 is: the CPU core allocation result of each task within the network cloud node, and the estimated completion delay of each task.

[0136] Step S7: Task Execution and Result Feedback: After completing the node allocation and resource allocation for the local execution set and the remote execution set, tasks in the local execution set are executed locally by the base station, and tasks in the remote execution set are executed by the corresponding network cloud nodes. After the task execution is completed, each execution node feeds back the task execution result and status information to the base station. The base station summarizes the execution results of all tasks, calculates the actual completion latency of each task, and calculates the task latency constraint satisfaction rate for the current scheduling period. The output of step S7 includes: the local execution set, the remote execution set, the allocation result of remote tasks to each network cloud node (i.e., the target allocation scheme), the CPU core allocation result corresponding to each remote task under the target allocation scheme, the actual completion latency of each task, the task latency constraint satisfaction rate for the current scheduling period, as well as timeout task information and status information for parameter updates in subsequent scheduling periods.

[0137] Through steps S1 to S7, this embodiment realizes a closed-loop task scheduling system for end-to-base station-network cloud collaboration in computing power-inherent scenarios. It can perform local reliable execution screening and remote reliability priority allocation of tasks under dynamic changes in communication load, thereby improving the task latency constraint satisfaction rate.

[0138] In one embodiment, such as Figure 5 As shown, Figure 5 This is a schematic diagram illustrating an implementation scenario of reliable edge-network-cloud collaborative task scheduling for computing power-inherent scenarios, as shown in an embodiment of the present invention. Figure 5 The corresponding embodiments are used to illustrate the execution process of the method of the present invention in a scenario of single base station and multiple network cloud nodes cooperating. It should be noted that the parameters listed in this embodiment are only used to illustrate the implementation of the method of the present invention and do not constitute a limitation on the scope of protection of the present invention.

[0139] The system includes a base station with inherent computing power and three network cloud nodes. The base station has a total of 32 CPU cores, with 10 cores used for communication processing. The single-core computing power of the three network cloud nodes is 3.0 GHz, 3.2 GHz, and 2.6 GHz, respectively, and the number of CPU cores in the three network cloud nodes are 16, 24, and 32, respectively. In this embodiment, the task input data volume... Values ​​can be selected from 1MB to 5MB, with a maximum allowable latency. Values ​​can be selected within the range of 0.5s to 1s, and the number of CPU cycles required per unit of data. The value can be taken in the range of 400Mcycles / MB to 1500Mcycles / MB. In this embodiment, the delay reservation coefficient... It can be set to 0.1.

[0140] Below, in conjunction with Figure 6 ( Figure 6This is a flowchart illustrating the steps of a reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, as shown in an embodiment of the present invention. Figure 6 In the process, the base station first receives the task set within the current scheduling period, collects the base station communication load and node status, calculates the base station's internal available computing power, and calculates the effective schedulable time limit of the task and the local minimum core requirements: based on the task parameters, the current communication occupancy and the local queuing status, it calculates the minimum number of CPU cores required for each task to be reliably executed locally at the base station.

[0141] The base station further sorts the tasks based on task urgency, resource adaptability, and local execution benefit ranking (or maximum allowable latency, input data volume, and difficulty) to determine whether each task meets the local reliable execution conditions, and then checks whether each task should be included in the local execution set in the order of sorting. If the remaining endogenous available computing power can meet the local reliable execution requirements of the corresponding task, the task is included in the local execution set; otherwise, it is assigned to the remote execution set.

[0142] For tasks entering the remote execution set, the base station constructs a remote task node allocation vector: Among them, the first in the vector Each element represents the network cloud node number to which the k-th remote task is assigned.

[0143] In this embodiment, the allocation of remote task nodes is achieved using a hybrid discrete optimization method. Preferably, this hybrid discrete optimization method combines discrete particle swarm optimization with simulated annealing. Specifically, each candidate node allocation scheme is represented as the position vector of a particle, and the particle's position vector is... Dimensional position indicates the first The target network cloud node corresponding to each remote task; the particle's velocity represents the intensity of the task's tendency to change the target node's dimension.

[0144] In this embodiment, the execution process of the optimization algorithm may include the following steps: Initialize multiple candidate node allocation schemes and use them as the initial positions for multiple particles; Assign an initial velocity, initial temperature, and determine the corresponding current cost for each particle; Calculate the individual historical best position of each particle based on the initial scheme, and select the group historical best position from them; In each iteration, the particle velocity is updated based on the inertia term, the individual learning term, and the group learning term; A new candidate node allocation scheme is generated based on the updated particle velocity; For each new candidate node allocation scheme, the CPU core allocation result within each network cloud node under that scheme is further solved; Based on the candidate node allocation scheme and its corresponding CPU core allocation result, the reliability priority cost function is calculated; wherein, in the iteration process of this embodiment, the outer layer searches for node allocation schemes, and the inner layer solves for CPU core allocation.

[0145] If the new proposal is better than the current proposal, then the new proposal is accepted; if the new proposal is worse than the current proposal, then the new proposal is accepted with a probability related to the current temperature, according to the simulated annealing acceptance criterion. Update the individual's historical best position and the group's historical best position; Determine whether the termination condition is met. When the maximum number of iterations is reached or the temperature drops to a preset threshold, output the optimal node allocation scheme and CPU core allocation result.

[0146] In this preferred embodiment, exemplary parameters can be set as follows: number of particles: 24; maximum number of iterations: 35; inertia weight: 0.72; individual learning factor: 1.6; swarm learning factor: 1.6; random exploration weight: 0.1; initial temperature: 0.5; minimum temperature: 0.005; and temperature decay coefficient: 0.88. These parameters are exemplary configurations under this preferred algorithm implementation, used to control the search range, search depth, update magnitude, and inferior solution acceptance capability of candidate solutions, and do not constitute a limitation on the scope of protection of this invention.

[0147] After the allocation scheme for each candidate node is determined, the base station further calculates the CPU core allocation result within each node. If the remote task... It is assigned to the i-th network cloud node and assigned... If there are 1 CPU core, then its remote completion latency is estimated to be: ; In this implementation, the allocation of CPU cores within a node can preferably be solved using a convex optimization method; for scenarios with limited computational complexity, a heuristic method can also be used to obtain approximate allocation results.

[0148] Subsequently, the base station calculates the reliability-first cost function based on the candidate node allocation scheme and its corresponding CPU core allocation results: ; in, Indicates the number of timed-out tasks. This represents the sum of timeout durations. Indicates the total completion delay. This represents the load difference between nodes. Preferably, the weights satisfy: After completing remote optimization, the base station obtains the optimal node allocation scheme and its corresponding CPU core allocation results, and performs the following operations: Tasks in the local execution set are handed over to the base station for local execution. Send the tasks in the remote execution set to the corresponding network cloud nodes for execution; Based on the CPU core allocation results in the optimal solution, perform resource allocation on the remote task; After the task is completed, each execution node reports the task results and execution status information back to the base station; Finally, the base station calculates the actual completion delay of each task within the current scheduling cycle, calculates the task delay constraint satisfaction rate, and records the number of timeout tasks, timeout duration, and load status of each node for continued use in subsequent scheduling cycles.

[0149] This embodiment demonstrates that the present invention can complete the entire scheduling process from task reception, resource awareness, local reliable execution screening, remote node allocation optimization, node internal resource allocation to execution feedback in a computing power-inherent scenario.

[0150] In one embodiment, such as Figure 7 As shown, Figure 7 This is a schematic diagram illustrating another implementation scenario of reliable edge-network-cloud collaborative task scheduling for computing power-inherent scenarios, as shown in one embodiment of the present invention. Figure 7 The corresponding embodiments illustrate the adaptive scheduling process of the method of the present invention under dynamically changing communication load conditions. It should be noted that the parameters listed in this embodiment are only used to illustrate the implementation of the method of the present invention in dynamic scenarios and do not constitute a limitation on the scope of protection of the present invention. The system includes a base station with inherent computing power and multiple network cloud nodes. The total number of CPU cores in the base station remains constant, but the number of cores occupied by communication processing changes dynamically in different scheduling cycles. Therefore, the inherent available computing power of the base station also changes dynamically in different scheduling cycles. Figure 7 In order to improve the scheduling robustness under dynamic load scenarios, an adaptive delay reservation coefficient setting method is adopted.

[0151] Below, in conjunction with Figure 8 ( Figure 8 This is a flowchart illustrating the steps of another reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, as shown in an embodiment of the present invention. It explains the reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power as shown in this embodiment. Figure 8 In this process, at the beginning of each scheduling cycle, the base station first reads the number of cores occupied by communication in the current scheduling cycle, and calculates the intrinsic available computing power for the current cycle according to the following formula: Subsequently, the base station sets the delay reservation coefficient for this scheduling cycle based on the current communication occupancy ratio. And update the effective schedulable time limit for each task: The essence of adaptively setting the delay reservation coefficient in this embodiment lies in the fact that the higher the communication load, the lower the base station's intrinsic available computing power. Therefore, the delay reservation level should be increased to improve the robustness of local filtering and remote optimization. This segmented setting is an optional implementation method, not a unique fixed rule.

[0152] After this step is completed, the base station reassesses whether each task in the current scheduling period meets the local reliable execution conditions, and constructs a comprehensive ranking result based on task urgency, resource adaptability, and local execution benefits, thus reforming the local execution set and the remote execution set. When the communication load is low, the base station's internally available computing power is high, so more tasks can enter the local execution set; when the communication load increases, the base station's internally available computing power decreases, and some tasks that could originally be reliably executed locally at the base station will be assigned to the remote execution set.

[0153] For tasks in the remote execution set, this embodiment still adopts the same remote optimization mechanism as the previous embodiment, namely: the outer layer uses a hybrid discrete optimization method to search for remote task node allocation schemes; preferably, a combination of discrete particle swarm optimization and simulated annealing is used to realize node allocation search; for each candidate node allocation scheme, the corresponding CPU core allocation result within the node is further solved; based on the candidate scheme and its corresponding CPU core allocation result, the reliability priority cost function is calculated; through iterative updates, the optimal node allocation scheme and its corresponding CPU core allocation result are output.

[0154] Since this embodiment prioritizes the number of timeout tasks and the timeout duration during the candidate scheme evaluation process, it can still maintain a high task latency constraint satisfaction rate as much as possible even when the communication load increases and the base station's internal available computing power decreases.

[0155] In this embodiment, the base station repeatedly performs the following steps in multiple consecutive scheduling cycles: updating the communication occupancy status and intrinsic available computing power, updating the latency reservation coefficient, performing local reliable execution filtering, performing remote task node allocation optimization, solving the CPU core allocation results within the node, executing tasks and collecting status feedback, and calculating the task latency constraint satisfaction rate of the current scheduling cycle.

[0156] This embodiment illustrates that the present invention is not only applicable to task scheduling under static resource conditions, but also applicable to situations where communication load changes dynamically in computing power-endogenous scenarios. It can adaptively adjust the scheduling strategy according to changes in resource status, thereby improving the overall scheduling reliability.

[0157] In summary, compared with related technologies, the present invention can produce at least the following beneficial effects: 1. Improve the task latency constraint satisfaction rate. This invention prioritizes the optimization of the task latency constraint satisfaction rate as a core reliability indicator, and explicitly incorporates the number of timeout tasks and timeout duration into the evaluation process of candidate remote task allocation schemes, so that the scheduling process prioritizes reliability objectives rather than just optimizing average latency.

[0158] 2. Dynamically characterize and utilize the base station's inherent available computing power. In this invention, considering the dynamic fluctuation of the base station's available computing power with changes in communication load, an inherent available computing power model of "total resources minus communication-occupied resources" is established. The difference between the total number of CPU cores in the base station and the number of cores occupied by communication tasks dynamically characterizes the amount of resources available for general task processing, thereby enabling scheduling decisions to adapt to changes in communication load.

[0159] 3. Improve the efficiency of near-end resource utilization. By prioritizing tasks suitable for execution at the base station during the local screening phase, some latency-sensitive tasks can be processed directly at the near end, reducing the additional latency caused by remote transmission.

[0160] 4. Reduce remote node timeout risk. By searching for a better node allocation scheme among multiple network cloud nodes during the remote optimization phase and calculating the scheme cost based on the CPU core allocation results within the node, the timeout risk caused by tasks being concentrated on a single node can be reduced. In other words, the remote hybrid discrete optimization method based on the reliability-first cost function of this invention can simultaneously take into account the priority relationship between the number of timeout tasks, timeout duration, total latency, and load balancing.

[0161] In one embodiment, such as Figure 9 As shown, Figure 9 This is a schematic diagram illustrating a process for allocating remote tasks based on a hybrid discrete optimization method, as shown in an embodiment of the present invention. Figure 9 In this process, after allocation begins, particle positions, velocities, and temperatures are initialized. Based on the initialized particle positions, the initial scheme cost is calculated, and individual and global optimum are determined. Multiple iterations are performed to determine if the termination condition is met. If the termination condition is not met, candidate schemes are updated based on individual and global optimum. The allocation of CPU cores within nodes under this scheme is solved, and the reliability-first cost function is calculated. In this embodiment, the reliability-first cost function prioritizes reducing the number of timeout tasks, then reducing timeout duration, then reducing total latency, and finally improving load balancing.

[0162] Next, based on the reliability-first cost function value, it is determined whether the new solution for each particle is better. If so, the new solution is accepted and the individual optimal and global optimal are updated. If not, it is determined whether to accept the inferior solution according to the current temperature probability. If the inferior solution is accepted according to the current temperature probability, the new solution is accepted and the individual optimal and global optimal are updated. If the inferior solution is not accepted according to the current temperature probability, the original solution is retained and the selection continues. If the termination condition is met, the optimal node allocation scheme and the corresponding CPU core allocation result are output, and the allocation ends.

[0163] In addition to the aforementioned preferred embodiments, the following alternatives may also be adopted; all of these alternatives should be considered to fall within the scope of the inventive concept: During the local screening phase, task ranking rules can be implemented using linear weighting, hierarchical scoring, or rule-based reasoning. The queuing delay estimate in this embodiment can be obtained through queue length conversion, historical moving average, or prediction model.

[0164] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0165] Based on the same inventive concept, one embodiment of the present invention provides a reliable edge-network-cloud collaborative task scheduling system for scenarios with inherent computing power. (Reference) Figure 10 , Figure 10 This is a structural block diagram of a reliable edge-network-cloud collaborative task scheduling system for scenarios with inherent computing power, provided by an embodiment of the present invention. Figure 10 As shown, the system includes: The intrinsic determination module is used to determine the number of intrinsically available CPU cores of the base station in the first scheduling period based on the total number of CPU cores of the base station and the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period. The coefficient determination module is used to determine the delay reservation coefficient of the base station in the first scheduling period based on the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period and the total number of CPU cores of the base station. The minimum number of cores determination module is used to determine the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the first scheduling period based on the computing power of a single CPU core of the base station, the delay reservation coefficient and queuing delay estimate of the base station in the first scheduling period, and the task parameter values ​​of each task received by the base station in the first scheduling period. The set determination module is used to determine the base station local task set and the remote network cloud node task set for each task received by the base station in the first scheduling period, based on whether the minimum number of CPU cores required is greater than the number of endogenously available CPU cores of the base station in the first scheduling period. The task scheduling module is used to execute each task in the base station local task set of the first scheduling period using its own intrinsic available CPU cores within the first scheduling period, and to schedule remote network cloud nodes to execute each task in the remote network cloud node task set of the first scheduling period.

[0166] Optionally, the set determination module includes: The first addition module is used to add each task received by the base station in the first scheduling period to the base station's local candidate task set if the minimum number of CPU cores required for the task is not greater than the number of endogenously available CPU cores of the base station in the first scheduling period. The score determination module is used to determine the priority score of each task based on the maximum allowable latency, input data volume, and difficulty of each task in the local candidate task set of the base station. The second addition module is used to add tasks from the local candidate task set to the local task set of the base station in descending order of priority score. The core count determination module is used to determine the remaining number of internally available CPU cores of the base station after each task is added to the base station's local task set. If the minimum number of CPU cores required for the next task is less than the remaining number of internally available CPU cores of the base station, the next task is added to the base station's local task set until the number of internally available CPU cores of the base station in the first scheduling period is fully allocated. The third module is used to add tasks that have not been added to the base station's local task set to the remote network cloud node task set.

[0167] Optionally, the system further includes: The first scheduling module is used to: reduce the number of internally available CPU cores of the base station in the first scheduling period if the number of CPU cores occupied by the communication tasks of the base station in the second scheduling period is greater than the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period; increase the latency reservation coefficient of the base station in the first scheduling period; and determine the base station local task set and the remote network cloud node task set in the second scheduling period based on the computing power of the base station's single CPU core, the number of internally available CPU cores of the base station in the second scheduling period, the latency reservation coefficient, the estimated queuing latency, and the task parameter values ​​of each task received by the base station in the second scheduling period. The total number of tasks in the base station local task set in the second scheduling period is less than the total number of tasks in the base station local task set in the first scheduling period. The second scheduling module is used to: increase the number of internally available CPU cores of the base station in the first scheduling period if the number of CPU cores occupied by the communication tasks of the base station in the second scheduling period is less than the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period; decrease the latency reservation coefficient of the base station in the first scheduling period; and determine the base station local task set and the remote network cloud node task set in the second scheduling period based on the computing power of the base station's single CPU core, the number of internally available CPU cores of the base station in the second scheduling period, the latency reservation coefficient, the estimated queuing latency, and the task parameter values ​​of each task received by the base station in the second scheduling period. The total number of tasks in the base station local task set in the second scheduling period is greater than the total number of tasks in the base station local task set in the first scheduling period.

[0168] Optionally, the task parameter values ​​include at least: maximum allowable latency, difficulty, and input data volume; the minimum core count determination module includes: The scheduling time limit determination module is used to determine the delay reservation coefficient of the base station in the first scheduling period. and the maximum allowable delay of the k-th task received by the base station within the first scheduling period. According to the formula Determine the effective schedulable time limit for the k-th task received by the base station within the first scheduling period. ; The CPU core count determination module is used to determine the computing power of a single CPU core in the base station. 1. Base station queuing delay estimate during the first scheduling period And the difficulty of the k-th task received by the base station in the first scheduling period. Input data volume Effective schedulable time limit According to the formula Determine the minimum number of CPU cores required for the k-th task received by the base station within the first scheduling period. ,in, This indicates rounding up to the nearest integer.

[0169] Optionally, the number of remote network cloud nodes is multiple; the task scheduling module includes: The initialization module is used to initialize P candidate allocation schemes and use the P candidate allocation schemes as the initial positions of P particles. Based on the initial positions of the P particles, the initial reliability priority cost function value of each of the P particles is determined, and the group's historical best position and the individual historical best position of each of the P particles are initialized. The velocity update module is used to update the velocities of P particles in the t-th iteration based on the individual historical best position and the group historical best position in the t-th iteration, so as to obtain the velocities of P particles in the (t+1)-th iteration. The cost calculation module is used to generate P candidate allocation schemes in the (t+1)th iteration based on the velocity of P particles in the (t+1)th iteration, and use the P candidate allocation schemes in the (t+1)th iteration as the positions of P particles in the (t+1)th iteration. Based on the positions of P particles in the (t+1)th iteration, the reliability priority cost function value of each of the P particles in the (t+1)th iteration is determined. The scheme retention module is used to sequentially select p from 1 to P. If the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is less than the reliability priority cost function value of the p-th particle in the t-th iteration, then the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration is retained; if the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is not less than the reliability priority cost function value of the p-th particle in the t-th iteration, then the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration is retained with the probability corresponding to the t-th iteration. The optimal position determination module is used to determine the candidate allocation scheme with the minimum reliability priority cost function value of the p-th particle in each iteration process as the individual historical optimal position of the p-th particle in the (t+1)-th iteration, and to determine the candidate allocation scheme with the minimum reliability priority cost function value of the P particles in each iteration process as the group historical optimal position in the (t+1)-th iteration. The solution output module is used to repeat the above steps until the maximum number of iterations is reached, and then obtain the target allocation solution. The scheduling and execution module is used to schedule remote network cloud nodes to execute various tasks in the remote network cloud node task set for the first scheduling cycle, based on the target allocation scheme.

[0170] Optionally, the cost calculation module includes: The core allocation module is used to determine the CPU core allocation results of multiple remote network cloud nodes for the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration. The completion delay determination module is used to determine the estimated completion delay of each task in the task set of the remote network cloud nodes in the first scheduling period based on the CPU core allocation results of each of the multiple remote network cloud nodes. The cost determination module is used to determine the reliability priority cost function value of the p-th particle in the t+1th iteration based on the number of timeout tasks, the sum of timeout durations of timeout tasks, the sum of estimated completion delays of each task, and the load difference index value of each remote network cloud node under the candidate allocation scheme corresponding to the p-th particle.

[0171] Optionally, the CPU core allocation results for each of the multiple remote network cloud nodes include: the m-th task in the remote network cloud node task set during the first scheduling period is assigned to the i-th remote network cloud node, and the i-th remote network cloud node is responsible for allocating the m-th task. One CPU core; The delay determination module includes: The first determining module is used to combine the computing power of the single CPU core of the i-th remote network cloud node. The link bandwidth from the base station to the i-th remote network cloud node during the first scheduling period. The estimated queuing delay of the i-th remote network cloud node during the first scheduling period. And, the difficulty of the m-th task. and input data volume According to the formula Determine the estimated completion delay of the m-th task on the i-th remote network cloud node. ; The timeout determination module is used if the estimated completion delay of the m-th task on the i-th remote network cloud node exceeds the maximum allowable delay of the m-th task. Then, the m-th task is determined to be a timeout task, and the timeout duration of the m-th task is determined as: the estimated completion delay of the m-th task on the i-th remote network cloud node. Maximum allowed latency for the m-th task The difference.

[0172] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0173] The reliable edge-network-cloud collaborative task scheduling system for computing power-intrinsic scenarios in this invention embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This invention embodiment does not impose specific limitations.

[0174] The reliable edge-network-cloud collaborative task scheduling system for computing power-inherent scenarios in this embodiment of the invention can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this embodiment of the invention does not impose specific limitations.

[0175] Based on the same inventive concept, another embodiment of the present invention provides an electronic device, such as... Figure 11 As shown, Figure 11 This is a schematic diagram of an electronic device according to an embodiment of the present invention. The electronic device includes a memory, a processor, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps in the reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios described in any of the above embodiments of the present invention.

[0176] It should be noted that the electronic devices in the embodiments of the present invention include the mobile electronic devices and non-mobile electronic devices described above.

[0177] Based on the same inventive concept, another embodiment of the present invention provides a readable storage medium storing a program or instructions. When executed by a processor, the program or instructions implement the steps in the reliable edge-network-cloud collaborative task scheduling method for endogenous computing power scenarios described in any of the above embodiments of the present invention. The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes a computer-readable storage medium, such as a computer read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk.

[0178] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the method implementation.

[0179] It should be noted that, in this document, 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 a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0180] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0181] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power, characterized in that, The method includes: The number of endogenously available CPU cores of the base station in the first scheduling period is determined based on the total number of CPU cores of the base station and the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period. The latency reservation coefficient of the base station in the first scheduling period is determined based on the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period and the total number of CPU cores of the base station. Based on the computing power of a single CPU core of the base station, the latency reservation coefficient and queuing latency estimate of the base station in the first scheduling period, and the task parameter values ​​of each task received by the base station in the first scheduling period, determine the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the first scheduling period. Based on whether the minimum number of CPU cores required is greater than the number of endogenously available CPU cores of the base station in the first scheduling period, for each task received by the base station in the first scheduling period, determine the base station local task set and the remote network cloud node task set for the first scheduling period. The base station uses its own inherent available CPU cores within the first scheduling period to execute each task in the base station local task set of the first scheduling period, and the base station schedules remote network cloud nodes to execute each task in the remote network cloud node task set of the first scheduling period.

2. The reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power as described in claim 1, characterized in that, Based on whether the minimum required number of CPU cores is greater than the number of intrinsically available CPU cores of the base station in the first scheduling period, for each task received by the base station in the first scheduling period, determine the base station local task set and the remote network cloud node task set for the first scheduling period, including: For each task received by the base station in the first scheduling period, if the minimum number of CPU cores required for the task is not greater than the number of endogenously available CPU cores of the base station in the first scheduling period, then the task is added to the base station's local candidate task set. The priority score of a task is determined based on the maximum allowable latency, input data volume, and difficulty of each task in the local candidate task set of the base station. Tasks from the local candidate task set are added to the local task set in descending order of priority score. After each task is added to the base station's local task set, the remaining number of internally available CPU cores of the base station is determined. If the minimum number of CPU cores required for the next task is less than the remaining number of internally available CPU cores of the base station, the next task is added to the base station's local task set until the number of internally available CPU cores of the base station in the first scheduling period is fully allocated. Add all tasks that have not been added to the base station's local task set to the remote network cloud node task set.

3. The reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power as described in claim 1, characterized in that, The method further includes: If the number of CPU cores occupied by the communication tasks of the base station in the second scheduling period is greater than the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period, then the number of the base station's intrinsically available CPU cores in the first scheduling period is reduced to obtain the number of the base station's intrinsically available CPU cores in the second scheduling period. Additionally, the delay reservation coefficient of the base station in the first scheduling period is increased to obtain the delay reservation coefficient of the base station in the second scheduling period. Based on the computing power of a single CPU core of the base station, the number of the base station's intrinsically available CPU cores, the delay reservation coefficient, and the estimated queuing delay in the second scheduling period, as well as the task parameter values ​​of each task received by the base station in the second scheduling period, the base station local task set and the remote network cloud node task set for the second scheduling period are determined. The total number of tasks in the base station local task set in the second scheduling period is less than the total number of tasks in the base station local task set in the first scheduling period. If the number of CPU cores used by the base station for communication tasks in the second scheduling period is less than the number of CPU cores used by the base station for communication tasks in the first scheduling period, then the number of endogenously available CPU cores of the base station in the first scheduling period is increased to obtain the number of endogenously available CPU cores of the base station in the second scheduling period. Additionally, the latency reservation coefficient of the base station in the first scheduling period is decreased to obtain the latency reservation coefficient of the base station in the second scheduling period. Based on the computing power of a single CPU core of the base station, the number of endogenously available CPU cores of the base station in the second scheduling period, the latency reservation coefficient, the estimated queuing latency, and the task parameter values ​​of each task received by the base station in the second scheduling period, the local task set of the base station and the task set of the remote network cloud node in the second scheduling period are determined. The total number of tasks in the local task set of the base station in the second scheduling period is greater than the total number of tasks in the local task set of the base station in the first scheduling period.

4. The reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power as described in claim 1, characterized in that, The task parameter values ​​should include at least: maximum allowable latency, difficulty, and input data volume; based on the computing power of a single CPU core of the base station, the latency reservation coefficient and queuing latency estimate of the base station in the first scheduling period, and the task parameter values ​​of each task received by the base station in the first scheduling period, determine the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the first scheduling period, including: Based on the base station's delay reservation coefficient in the first scheduling cycle and the maximum allowable delay of the k-th task received by the base station within the first scheduling period. According to the formula Determine the effective schedulable time limit for the k-th task received by the base station within the first scheduling period. ; Based on the computing power of a single CPU core in the base station 1. Base station queuing delay estimate during the first scheduling period And the difficulty of the k-th task received by the base station in the first scheduling period. Input data volume Effective schedulable time limit According to the formula Determine the minimum number of CPU cores required for the k-th task received by the base station within the first scheduling period. ,in, This indicates rounding up to the nearest integer.

5. The reliable edge-network-cloud collaborative task scheduling method for scenarios with inherent computing power as described in claim 1, characterized in that, The number of remote network cloud nodes is multiple; The base station schedules remote network cloud nodes to execute various tasks from the remote network cloud node task set for the first scheduling cycle, including: The base station initializes P candidate allocation schemes and uses the P candidate allocation schemes as the initial positions of P particles. Based on the initial positions of the P particles, it determines the initial reliability priority cost function value of each of the P particles and initializes the group's historical best position and the individual historical best position of each of the P particles. The base station updates the velocities of P particles in the t-th iteration based on the individual historical best position and the group historical best position in the t-th iteration, and obtains the velocities of P particles in the (t+1)-th iteration. The base station generates P candidate allocation schemes for the (t+1)th iteration based on the velocity of P particles in the (t+1)th iteration, and uses the P candidate allocation schemes for the (t+1)th iteration as the positions of P particles in the (t+1)th iteration. Based on the positions of P particles in the (t+1)th iteration, the reliability priority cost function value of each of the P particles in the (t+1)th iteration is determined. Take p sequentially from 1 to P. If the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is less than that of the p-th particle in the t-th iteration, then retain the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration. If the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is not less than that of the p-th particle in the t-th iteration, then retain the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration with the probability corresponding to the t-th iteration. The base station determines the candidate allocation scheme with the minimum reliability priority cost function value of the p-th particle in each iteration process as the individual historical best position of the p-th particle in the (t+1)-th iteration, and determines the candidate allocation scheme with the minimum reliability priority cost function value of the P particles in each iteration process as the group historical best position in the (t+1)-th iteration. Repeat the above steps until the maximum number of iterations is reached to obtain the target allocation scheme; Based on the target allocation scheme, remote network cloud nodes are scheduled to execute each task in the remote network cloud node task set for the first scheduling cycle.

6. The reliable edge-network-cloud collaborative task scheduling method for computing power-endogenous scenarios according to claim 5, characterized in that, The reliability priority cost function value of each of the P particles in the (t+1)th iteration is determined based on their positions, including: For the candidate allocation scheme corresponding to the p-th particle in the (t+1)-th iteration, the base station determines the CPU core allocation result of each of the multiple remote network cloud nodes; Based on the CPU core allocation results of multiple remote network cloud nodes, determine the estimated completion time of each task in the task set of the remote network cloud nodes in the first scheduling period. Based on the number of timeout tasks, the sum of timeout durations of timeout tasks, the sum of estimated completion delays of each task, and the load difference index of each remote network cloud node under the candidate allocation scheme corresponding to the p-th particle, the reliability priority cost function value of the p-th particle in the (t+1)-th iteration is determined.

7. The reliable edge-network-cloud collaborative task scheduling method for computing power-endogenous scenarios according to claim 6, characterized in that, The CPU core allocation results for multiple remote network cloud nodes include: the m-th task in the task set of the remote network cloud nodes in the first scheduling period is assigned to the i-th remote network cloud node, and the i-th remote network cloud node is responsible for allocating the m-th task. One CPU core; Based on the CPU core allocation results of multiple remote network cloud nodes, the estimated completion time of each task in the task set of the remote network cloud nodes in the first scheduling period is determined, including: Combining the computing power of a single CPU core of the i-th remote network cloud node The link bandwidth from the base station to the i-th remote network cloud node during the first scheduling period. The estimated queuing delay of the i-th remote network cloud node during the first scheduling period. And, the difficulty of the m-th task. and input data volume According to the formula Determine the estimated completion delay of the m-th task on the i-th remote network cloud node. ; If the estimated completion delay of the m-th task on the i-th remote network cloud node exceeds the maximum allowable delay of the m-th task... Then, the m-th task is determined to be a timeout task, and the timeout duration of the m-th task is determined as: the estimated completion delay of the m-th task on the i-th remote network cloud node. Maximum allowed latency for the m-th task The difference.

8. A reliable edge-network-cloud collaborative task scheduling system for scenarios with inherent computing power, characterized in that, The system includes: The intrinsic determination module is used to determine the number of intrinsically available CPU cores of the base station in the first scheduling period based on the total number of CPU cores of the base station and the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period. The coefficient determination module is used to determine the delay reservation coefficient of the base station in the first scheduling period based on the number of CPU cores occupied by the communication tasks of the base station in the first scheduling period and the total number of CPU cores of the base station. The minimum number of cores determination module is used to determine the effective schedulable time limit and the minimum number of CPU cores required for each task received by the base station in the first scheduling period based on the computing power of a single CPU core of the base station, the delay reservation coefficient and queuing delay estimate of the base station in the first scheduling period, and the task parameter values ​​of each task received by the base station in the first scheduling period. The set determination module is used to determine the base station local task set and the remote network cloud node task set for each task received by the base station in the first scheduling period, based on whether the minimum number of CPU cores required is greater than the number of endogenously available CPU cores of the base station in the first scheduling period. The task scheduling module is used by the base station to execute each task in the base station local task set of the first scheduling period using its own internally available CPU cores within the first scheduling period, and by the base station to schedule remote network cloud nodes to execute each task in the remote network cloud node task set of the first scheduling period.

9. An electronic device, characterized in that, The method includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the reliable edge-network-cloud collaborative task scheduling method for computing power-endogenous scenarios as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The program or instructions are stored on the readable storage medium, and when the program or instructions are executed by the processor, they implement the steps of the reliable edge-network-cloud collaborative task scheduling method for computing power-inherent scenarios as described in any one of claims 1 to 7.

Images