Cloud side-end collaborative computing power network service request balanced distribution system

Abstract

The invention discloses a cloud side-end collaborative computing power network service request balanced distribution system, and relates to the technical field of computing power networks, and the system comprises end-side agent modules which are deployed at all end-side devices and are used for collecting computing power activity parameters, network connection parameters and energy state parameters of the end-side devices in real time, and generating an original credibility vector based on the parameters. According to the cloud side-end collaborative computing power network service request balanced distribution system, through dynamically adjusting the probability that the access nodes are distributed to the edge nodes, the access nodes are directly distributed to the end-side equipment, and the edge nodes are unloaded to the end-side equipment, combined balance of load balancing, time delay optimization and energy consumption constraint is realized; and the overall utilization efficiency and the service response speed of the whole network computing power resources are improved.

Description

A cloud-edge-device collaborative computing power network service request balanced distribution system Technical Field

[0001] This invention relates to the field of computing network technology, specifically to a cloud-edge-device collaborative computing network service request balanced distribution system. Background Technology

[0002] With the rapid development of cloud computing, edge computing, and distributed computing, computing power networks, as a new type of computing architecture, aim to meet diverse service request needs through efficient scheduling and allocation of computing resources. Currently, the distribution methods for service requests in computing power networks typically rely on centralized scheduling or local load balancing mechanisms to improve resource utilization and system response speed.

[0003] For example, patent document CN120128587A describes a "method and system for balanced distribution of computing power network service requests". This scheme collects global information, uses a centralized convex optimization method to generate a global distribution strategy, and combines a negative feedback mechanism to make real-time adjustments at the access nodes, achieving a synergy between global optimization and local dynamic adjustment. This patent has the advantages of supporting centralized and distributed dual-mode scheduling, introducing multi-objective optimization to balance load and network latency, and reducing information synchronization overhead through a local estimation mechanism, significantly improving resource utilization efficiency, service quality, and system robustness.

[0004] While the aforementioned patent achieves balanced distribution of computing power network service requests and possesses strong dynamic adaptability, it still has the following limitations: First, the solution primarily focuses on the two-layer architecture between access nodes and service nodes, lacking the ability to coordinate and schedule computing resources of terminal devices (edge-side). In a cloud-edge-device three-level collaborative scenario, the idle computing power of edge-side devices is difficult to fully utilize, resulting in room for improvement in the overall resource utilization rate of the computing power network. Second, the solution relies on the load status and latency information broadcast by service nodes in its negative feedback mechanism. For scenarios with highly dynamic changes in edge-side devices and unstable network connections, the timeliness and accuracy of information synchronization are difficult to guarantee, potentially affecting the real-time performance and balancing effect of distribution decisions. Furthermore, the solution does not fully consider the heterogeneity of computing power on edge-side devices and the energy consumption constraints of task offloading in its global optimization model, making it difficult to adapt to the complex requirements of edge-side computing power participating in service response, thus limiting its applicability and scalability in a cloud-edge-device collaborative architecture.

[0005] Therefore, there is an urgent need for a computing network service request balanced distribution system that can achieve collaborative scheduling of computing resources at the cloud, edge, and terminal levels, take into account the dynamic changes in terminal computing power and energy consumption constraints, and improve resource utilization and service response speed, so as to overcome the shortcomings of existing technologies. Summary of the Invention

[0006] The purpose of this invention is to provide a cloud-edge-device collaborative computing power network service request balanced distribution system to solve the problems mentioned in the background art.

[0007] To address the aforementioned technical problems, this invention provides the following technical solution: a cloud-edge-device collaborative computing power network service request balanced distribution system, comprising: an edge-side proxy module, deployed on each edge device, for real-time collection of computing power activity parameters, network connection parameters, and energy status parameters of the edge devices, and generating an original trustworthiness vector based on the parameters; an edge trustworthiness verification module, deployed on edge nodes, for receiving the original trustworthiness vectors of multiple edge devices in adjacent areas, performing cross-validation on the original trustworthiness vectors using a distributed consensus algorithm to generate a verification trustworthiness vector, and calculating the final trustworthiness of each edge device based on the original trustworthiness vector and the verification trustworthiness vector; and a computing power resource normalization module. The module is used to filter schedulable edge devices based on the final credibility, and map the heterogeneous computing power resources of the filtered edge devices to equivalent computing power units, which are determined based on computing power performance and remaining power. The collaborative scheduling optimization module is used to construct a multi-objective convex optimization model and generate a global distribution strategy with the comprehensive load balancing of cloud nodes, edge nodes and edge devices, end-to-end service latency and edge device energy consumption as optimization objectives. The dual-loop feedback verification module is used to receive the actual energy consumption and response latency of the edge device after executing the request, perform local verification and edge post-verification, and feed back the verification results to the collaborative scheduling optimization module to dynamically adjust the parameters of the multi-objective convex optimization model.

[0008] Preferably, the edge trust verification module includes: a local coarse screening unit, deployed on the edge proxy module, used to remove abnormal data from the computing power activity parameters, network connection parameters, and energy status parameters, generate an original trust vector, and send it to the edge node; a cross-validation unit, deployed on the edge node, used to receive the original trust vectors of multiple edge devices in adjacent areas, and initiate a computing power proof challenge for suspected abnormal edge devices, wherein the computing power proof challenge is to issue micro-computing tasks to surrounding adjacent devices to verify whether the actual computing power matches the reported value, and generate a verification trust vector based on the verification result; and a trust fusion unit, used to perform weighted fusion of the original trust vector and the verification trust vector according to dynamic weights to generate the final trust of the edge device, wherein the dynamic weights are adaptively adjusted according to the degree of network jitter.

[0009] Preferably, the original credibility vector includes computing power activity credibility, network connection credibility, and energy status credibility; wherein, the computing power activity credibility is determined based on the idle computing power of the central processing unit of the edge device, the available memory, and the number of storage input / output operations per second; the network connection credibility is determined based on signal strength, connection jitter variance, and predicted dwell time; and the energy status credibility is determined based on remaining battery power, charging status, and energy consumption mode.

[0010] Preferably, the computing power resource normalization module includes: a heterogeneous computing power mapping unit, used to multiply the peak computing power of the selected end-side devices by the architecture coefficient to obtain a basic computing power value; an energy consumption attenuation calculation unit, used to calculate an energy consumption attenuation factor based on the remaining power of the end-side devices, wherein the energy consumption attenuation factor tends to be one when the remaining power is higher than a threshold, and decays non-linearly as the remaining power decreases when the remaining power is lower than the threshold; and an equivalent computing power determination unit, used to multiply the basic computing power value by the energy consumption attenuation factor to obtain the equivalent computing power unit of the end-side devices.

[0011] Preferably, the energy consumption attenuation factor is calculated using an S-shaped function model. The S-shaped function model ensures that when the remaining power is below a threshold, the attenuation rate of the equivalent computing power unit gradually increases as the power decreases, so as to avoid over-scheduling of low-power end-side devices.

[0012] Preferably, the multi-objective convex optimization model constructed by the collaborative scheduling optimization module has optimization variables including the probability of an access node being distributed to an edge node, the probability of an access node being directly distributed to an end-side device, and the probability of an edge node being offloaded to an end-side device. Its constraints include the end-side device's final credibility constraint, the end-to-end latency upper limit constraint, and the network-wide energy consumption budget constraint.

[0013] Preferably, the optimization objectives of the multi-objective convex optimization model include minimizing the comprehensive load variance of the three-level nodes (cloud node, edge node, and end-side device), minimizing the average end-to-end latency of all service requests, and minimizing the total predicted energy consumption of the scheduled end-side devices. The comprehensive load variance is calculated by normalization based on the equivalent computing power unit.

[0014] Preferably, the dual-loop feedback verification module includes: a local verification unit, deployed on the edge device, used to compare the actual energy consumption with the predicted energy consumption and the actual latency with the predicted latency after each request processing. When the deviation exceeds a preset threshold, it triggers a temporary degradation of credibility and sends a deviation alarm to the edge node; an edge posterior unit, deployed on the edge node, used to collect deviation alarms and actual execution data from the edge device within the region, re-input the actual execution data into the multi-objective convex optimization model to calculate the posterior decision quality score, and upload the posterior data to the cloud center when the posterior decision quality score is lower than a preset threshold; and a cloud center optimization unit, used to receive the posterior data and dynamically adjust the weight coefficients of the multi-objective convex optimization model and the final credibility threshold based on the reinforcement learning model, generating an adaptive optimization parameter package and distributing it to all edge nodes.

[0015] Preferably, after the local verification unit triggers a temporary downgrade in credibility, the edge trusted verification module recalculates the final credibility of the end-side device, and the collaborative scheduling optimization module adjusts the distribution probability involving the end-side device based on the updated final credibility.

[0016] Preferably, the reinforcement learning model used by the cloud center optimization unit takes the posterior data uploaded by the edge nodes as input, aims to minimize the global load balancing deviation and the total network energy consumption, and outputs the updated weight coefficients of the multi-objective convex optimization model. The weight coefficients include load balancing weights, latency optimization weights, and energy consumption constraint weights.

[0017] This invention provides a cloud-edge-device collaborative computing power network service request balanced distribution system. It offers the following advantages: This system dynamically adjusts the probabilities of access nodes distributing requests to edge nodes, access nodes directly distributing requests to end-side devices, and edge nodes offloading requests to end-side devices. This achieves a joint trade-off between load balancing, latency optimization, and energy consumption constraints, thereby improving the overall utilization efficiency and service response speed of the entire network's computing power resources.

[0018] This cloud-edge-device collaborative computing power network service request balanced distribution system constructs a closed-loop adaptive mechanism of local verification, edge a posteriori verification, and cloud center optimization through a dual-loop feedback verification module. This mechanism enables the multi-objective convex optimization model to adjust the scheduling strategy parameters in real time based on network jitter, load changes, and edge state fluctuations, maintaining the accuracy of decision-making in the highly dynamic environment of edge devices and enhancing the system's adaptability to sudden traffic and node state changes. Attached Figure Description

[0019] Figure 1 is a system architecture diagram of a cloud-edge-device collaborative computing power network service request balanced distribution system according to the present invention; Figure 2 is a data flow diagram of a cloud-edge-device collaborative computing power network service request balanced distribution system according to the present invention. Detailed Implementation

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

[0021] Please refer to Figures 1 and 2. This invention provides a technical solution: a cloud-edge-device collaborative computing power network service request balanced distribution system. In a specific embodiment, the edge agent module is deployed on edge devices such as smartphones, IoT gateways, or edge cameras. This module collects the idle computing power, available memory, and number of storage input / output operations per second of the central processing unit as computing power activity parameters according to a preset period. It also collects signal strength, connection jitter variance, and predicted dwell time obtained based on Markov prediction of the movement trajectory as network connection parameters. In this solution, a second-order Markov prediction model is used to calculate the predicted dwell time of the edge device. The state space of the model is defined as the gridded area of ​​the geographical location of the edge device, with a grid unit of 50 meters × 50 meters. Each grid is an independent state, and the state encoding adopts a combination encoding method of latitude and longitude intervals. The row vector of the transition probability matrix is ​​the grid state of the device at the current time, and the column vector is the state of the device at the next time. The matrix lists the possible grid states to which the device may transition. Elements in the matrix represent the probability of transitioning from the current state to the next state. This matrix is ​​constructed as follows: The device's movement trajectory data from the past 72 hours is collected. The data is preprocessed to remove abnormal coordinates caused by positioning drift. Missing trajectory data is supplemented using linear interpolation. The number of transitions between grid states is counted, and the ratio of these transitions to the total number of transitions is used as the transition probability value. The transition probability matrix is ​​updated every 30 minutes, incorporating the latest 10-minute trajectory data using a sliding window method. Trajectory data is collected via the device's GPS and BeiDou dual-mode positioning modules at a frequency of once per second. The raw data includes the device's latitude and longitude, positioning accuracy, and collection time. During preprocessing, coordinates with positioning accuracy below 10 meters are removed, retaining valid data with positioning accuracy at least 10 meters. Remaining battery power, charging status, and energy consumption mode are collected as energy state parameters.

[0022] The edge agent module performs local coarse screening on the collected parameters, removes abrupt changes in data caused by instantaneous sensor drift, generates an original credibility vector containing computing power activity credibility, network connection credibility, and energy state credibility, and sends the original credibility vector to the corresponding edge node.

[0023] The edge trusted verification module is deployed on edge nodes. This module receives raw trust vectors from multiple end-side devices in adjacent areas. This solution uses the Practical Byzantine Fault-Tolerant (PBFT) algorithm to cross-verify the raw trust vectors. This algorithm is deployed and executed in the edge node cluster, with edge nodes acting as consensus nodes and end-side devices as information submission nodes. Nodes exchange encrypted information point-to-point via wired fiber optic or 5G wireless communication, using port 9001 and TCP / IP as the data transmission protocol. The execution steps of the PBFT algorithm are as follows: the end-side device submits the raw trust vector and parameter acquisition timestamp to its respective edge master node; the edge master node then... The information is broadcast to the remaining edge replica nodes within the cluster. Each replica node receives the information and performs a preliminary verification of the validity of the parameters collected from the edge device. Upon successful verification, it sends an acknowledgment message to the master node and other replica nodes. When the master node collects valid acknowledgment messages from more than two-thirds of the replica nodes, a consensus is reached, and the basic data for generating a verification credibility vector is generated. If not enough acknowledgment messages are collected, the original credibility vector is deemed abnormal, triggering the computing power proof challenge process. The core condition for consensus is that the number of nodes effectively participating in the consensus in the edge node cluster is not less than two-thirds of the total number of nodes, and the consistency rate of the verification results of each node is not less than 95%. When the computing power of a certain edge device is detected... When the activity credibility suddenly increases and exceeds the preset change threshold, the edge credibility verification module initiates a computing power proof challenge to three adjacent devices around the edge device. The computing power proof challenge is to issue a micro computing task and compare the matching degree between the actual execution time and the reported computing power value. For the computing power proof challenge initiated by the edge device suspected of being abnormal, the edge device itself executes the micro computing task. The edge node directly issues the micro computing task to the edge device suspected of being abnormal. At the same time, the three edge devices with the closest physical distance around the device are selected as witness nodes. The witness nodes synchronously receive the same micro computing task issued by the edge node and execute it to verify the standard execution time of the computing task. The microcomputing task involves solving a hash collision problem with a preset complexity. The hash algorithm used is SHA-256, and the complexity of the collision problem is set to medium to ensure that the edge device can complete the computation within 1 to 5 seconds. Edge nodes record the actual execution time of suspected abnormal edge devices and the average of the actual execution times of three witness nodes as the standard execution time. The comparison logic for the computing power proof challenge is as follows: based on the computing power activity parameters reported by the suspected abnormal edge device and combined with the device's processor architecture, the theoretical execution time of the microcomputing task is calculated. The formula for calculating the theoretical execution time is: Ttheoretical = K / C, where K is the computational constant of the microcomputing task, with a value of 1 × 102. 8In the next floating-point operation, C represents the idle computing power reported by the suspected abnormal end-side device. The actual execution time Tactual of the suspected abnormal end-side device is compared with the theoretical execution time Ttheoretical, while also referring to the standard execution time Tstandard of the witness node. If |Tactual - Ttheoretical| / Ttheoretical ≤ 0.2 and |Tactual - Tstandard| / Tstandard ≤ 0.3, then the reported computing power of the device is determined to be true and valid. If it exceeds this deviation range, then the reported computing power of the device is determined to be false. The value of its verification credibility vector is reduced according to the degree of falsehood, and a verification credibility vector is generated based on the challenge results.

[0024] The edge trust verification module adaptively adjusts the dynamic weights based on the network jitter level, and weights and fuses the original trust vector with the verification trust vector to obtain the final trust of the edge device. The edge device is only included in the schedulable resource pool when the final trust is greater than or equal to a preset threshold.

[0025] In the final credibility calculation, the original weight and the verification weight both range from 0 to 1, and their sum is always equal to 1. The weight values ​​are rounded to two decimal places. The quantitative mapping relationship between network jitter and weight is achieved by dividing the numerical range. The network jitter is represented by the variance σ of the network connection credibility of all end devices in the adjacent area in the most recent minute. σ∈[0,0.2] is the stable network range, with an original weight of 0.8 and a verification weight of 0.2; σ∈(0.2,0.5] is the range of slight network jitter, with an original weight of 0.5 and a verification weight of 0.5; σ∈(0.5,1] is the range of severe network jitter, with an original weight of 0.2 and a verification weight of 0.8. The final credibility ranges from 0 to 1. When the final credibility is ≥0.85, the end device is determined to be a schedulable device and included in the computing resource pool. When the final credibility is <0.85, the end device is determined to be an unschedulable device and does not participate in the distribution and scheduling of service requests.

[0026] The computing power resource normalization module receives the information of the end-side devices that have finally met the credibility standard, and multiplies the peak computing power of each end-side device by the architecture coefficient to obtain the basic computing power value. The architecture coefficient is obtained by benchmarking and calibrating different types of processor architectures in advance.

[0027] The architecture coefficient mapping table was calibrated using benchmark programs, including Linpack for floating-point operations, STREAM for memory access, and Sysbench for integer operations. The testing environment was a standard environment with a room temperature of 25℃ and no other background programs running. During the test, each processor architecture was run at full load for 10 minutes, and the average value of the test results was used as the calibration basis. The architecture coefficients were based on the x86-64 architecture Core i7 processor, with a base architecture coefficient of 1.0. The calibration results for the other architectures were as follows: Kirin 9000 processor architecture coefficient for ARMv8 architecture 0.85, Snapdragon 8 Gen3 processor architecture coefficient for ARMv9 architecture 0.92, Ascend 310 processor architecture coefficient for NPU architecture 1.2, and RTX 3050 mobile processor architecture coefficient for GPU architecture 1.15. All architecture coefficients were stored in the local database of the edge nodes and could be dynamically added and updated according to new processor architecture types.

[0028] Simultaneously, this module calculates the energy consumption attenuation factor based on the remaining power. The calculation of the energy consumption attenuation factor adopts an S-shaped function. When the remaining power is higher than the preset power threshold, the energy consumption attenuation factor tends to be one. The specific calibration method of the attenuation rate control coefficient k in the S-shaped function model is as follows: Select 50 different types of end-side devices: smartphones, IoT gateways, and edge cameras. In a laboratory environment, test the computing performance of each device under different remaining power conditions. The test ranges from 100% to 0% remaining power, with each 10% power level serving as a test node. Record the actual computing power output value of the device at each test node. Substitute the test data into the S-shaped function model for nonlinear fitting. Use the least squares method to solve for the k value that minimizes the fitting error. The criterion for judging the fitting error is the actual... The mean square error between the computing power output value and the model calculation value is less than 1%. The optimal value of k obtained by this calibration method is 10. The adjustment rule of k value is adapted according to the type of end device. For end devices with large battery capacity, such as IoT gateways with a battery capacity ≥10000mAh, the k value is adjusted to 8 to slow down the rate of decrease of the energy consumption decay factor. For end devices with small battery capacity, such as smart sensors with a battery capacity ≤2000mAh, the k value is adjusted to 12 to speed up the rate of decrease of the energy consumption decay factor. For end devices with conventional battery capacity, such as smartphones with a battery capacity of 2000mAh-10000mAh, the k value remains unchanged at 10. When the remaining power is lower than the preset power threshold, the energy consumption decay factor decreases in an S-shaped manner as the power decreases.

[0029] The equivalent computing power unit is obtained by multiplying the basic computing power value by the energy consumption attenuation factor. This equivalent computing power unit is used to characterize the computing power capability that the end-side device can stably contribute under the current power state.

[0030] The effective range of the energy consumption attenuation factor is 0 to 1. When the energy consumption attenuation factor is ≥0.8, the edge device is determined to be in a high-power state, and the equivalent computing power unit can fully utilize the device's computing performance. When 0.3≤energy consumption attenuation factor<0.8, the edge device is determined to be in a medium-power state, and the equivalent computing power unit gradually decreases as the power decreases. When the energy consumption attenuation factor<0.3, the edge device is determined to be in a low-power state, significantly reducing the scheduling probability of the device. The quantitative judgment standard for the equivalent computing power unit is based on the base computing power value of the x86-64 architecture Core i7 processor. The baseline equivalent computing power unit is 1000 GFLOPS. The equivalent computing power units of other edge devices are calculated based on their own basic computing power value and energy consumption attenuation factor. The value range of the equivalent computing power unit is 0 to 2000 GFLOPS. When the equivalent computing power unit is <100 GFLOPS, the edge device is removed from the schedulable resource pool and no longer participates in the distribution of service requests. The calculation result of the equivalent computing power unit is kept as an integer. The edge node recalculates the energy consumption attenuation factor and equivalent computing power unit of the edge device every 10 seconds and updates the device information of the computing power resource pool in real time.

[0031] The collaborative scheduling optimization module receives the equivalent computing power units of cloud nodes, edge nodes, and end-side devices, as well as the current load status, and constructs a multi-objective convex optimization model with the optimization objectives of minimizing the comprehensive load variance of the three-level nodes, minimizing the average end-to-end latency of all service requests, and minimizing the total predicted energy consumption of the scheduled end-side devices.

[0032] The optimization variables of the model include the first probability that the access node is distributed to the edge node, the second probability that the access node is directly distributed to the end-side device, and the third probability that the edge node is further offloaded to the end-side device. The constraints of the model include that the final credibility of the end-side device must be greater than or equal to the scheduling threshold, the end-to-end latency must be less than or equal to the upper limit specified by the service level agreement, and the total predicted energy consumption of the end-side devices in the entire network must be less than or equal to the preset energy consumption budget.

[0033] This solution uses the CVXPY solver to solve the multi-objective convex optimization model. The solver runs in Python 3.9 and utilizes the CPU of the edge nodes for computation, employing 4 CPU cores. The initial values ​​for the model solution iterations are set as follows: the initial probability of an access node distributing to an edge node is 0.6; the initial probability of an access node directly distributing to an end-side device is 0.2; and the initial probability of an edge node offloading to an end-side device is 0.2. The convergence condition for the iterations is that the absolute value of the difference between the objective function values ​​obtained from two consecutive iterations is less than 1 × 10⁻⁶. -5The iteration termination threshold is the maximum number of iterations, 100. If the convergence condition is not met after 100 iterations, the result of the 100th iteration is taken as the optimal solution. The interior point method of convex optimization is used for iterative calculation during the solution process. The constraints of the model are relaxed and the relaxation factor is set to 0.01 to ensure the feasibility and convergence of the solution process.

[0034] After solving the multi-objective convex optimization model, the collaborative scheduling optimization module generates a global distribution strategy and distributes it to each access node.

[0035] The dual-loop feedback verification module includes a local verification unit deployed on the end device, an edge verification unit deployed on the edge node, and a cloud center optimization unit deployed in the cloud center.

[0036] The local verification unit triggers a temporary downgrade of credibility, where 30% is a relative value. That is, the local credibility after the temporary downgrade = the original local credibility × (1-30%) = the original local credibility × 0.7. This temporary downgraded local credibility will be included in the process of recalculating the final credibility in the edge credibility verification module.

[0037] The edge posterior unit collects deviation alarms and actual execution data from all end-side devices within the region. It then uses the actual execution data as input to recalculate the posterior decision quality score in the multi-objective convex optimization model. This score reflects the degree of agreement between the actual execution effect and the optimization objective. The specific formula for calculating the posterior decision quality score is: S = α × (1 - |L_actual - L_expected| / L_expected) + β × (1 - |T_actual - T_expected| / T_expected) + γ × (1 - |E_actual - E_expected| / E_expected), where S is the posterior decision quality score, ranging from 0 to 1; α is the weighting coefficient for load balancing, with a value of 0.4; β is the weighting coefficient for latency optimization, with a value of 0.3; γ is the weighting coefficient for energy consumption constraints, with a value of 0.3; L_actual is the actual comprehensive load variance of the three-level nodes; L_expected is the model-preset comprehensive load variance; and T_actual is... The actual average end-to-end latency of all service requests, T is the model's preset average end-to-end latency, and E is the actual total energy consumption of the scheduled end-side devices, E is the model's preset total energy consumption. The preset threshold for the posterior decision quality score is set to 0.75. This threshold was calibrated through numerous simulation experiments. In the simulation experiments, 1000 different computing power network load scenarios were selected, and the correlation between the decision quality score and the scheduling effect in each scenario was statistically analyzed. When the score is ≥0.75, the scheduling effect meets the preset service quality requirements. When the score is <0.75, the scheduling effect does not meet the requirements, triggering the posterior data upload process. The edge node calculates the posterior decision quality score once every scheduling cycle, and the scheduling cycle is set to 30 seconds. When the posterior decision quality score is lower than the preset quality threshold, the edge posterior unit packages the posterior data and uploads it to the cloud center.

[0038] The cloud center optimization unit receives posterior data from multiple edge nodes and uses this posterior data as training samples to input into the deep Q-network reinforcement learning model. In this scheme, the deep Q-network model uses the Adam gradient descent method for parameter updates. The model's hyperparameters are set as follows: learning rate of 0.001, batch size of 64, experience replay pool capacity of 100,000, target network update frequency of once every 100 training iterations, discount factor γ of 0.95, and exploration rate ε dynamically adjusted using an ε-greedy strategy. The initial exploration rate is 1.0, decreasing by 0.01 every 1000 iterations until it reaches 0.1 and remains constant. The 27 weight coefficient increment combinations are adjustments for load balancing weights, latency optimization weights, and energy consumption constraint weights. The adjustment step size for each weight is 0.01 or 0.02. Specific combinations include: load balancing weights... The weights are adjusted by -0.02, 0, and +0.02; the latency optimization weights are adjusted by -0.02, 0, and +0.02; and the energy consumption constraint weights are adjusted by -0.02, 0, and +0.02. These three combinations result in 27 different incremental combinations, each corresponding to an output action. The model's input layer is a 64-dimensional state feature vector. The first hidden layer has 128 neurons, and the second has 64 neurons. The activation function for both layers is ReLU. The output layer has 27 neurons, corresponding to the 27 weight coefficient increment combinations. The output value is the Q-value of each action, and the action with the largest Q-value is selected as the optimal weight adjustment action. The reinforcement learning model aims to minimize the global load balancing bias and the overall network energy consumption, outputting updated multi-objective convex optimization model weight coefficients. These weight coefficients include load balancing weights, latency optimization weights, and energy consumption constraint weights.

[0039] The cloud center optimization unit distributes the updated weight coefficients as an adaptive optimization parameter package to all edge nodes. In the next scheduling cycle, the edge nodes use the updated weight coefficients to resolve the multi-objective convex optimization model.

[0040] It should be further explained that, in the specific implementation, the edge trust verification module includes a local coarse screening unit, a cross-validation unit, and a trust fusion unit.

[0041] The local coarse screening unit is deployed in a lightweight agent program of the end-side device. This unit uses the sliding window averaging method to smooth the real-time collected computing power activity parameters, network connection parameters and energy state parameters. When the parameter value at a certain moment deviates from the average value within the sliding window by more than a preset deviation threshold, the parameter is determined to be instantaneous drift data and is removed.

[0042] The local coarse screening unit converts the valid parameters after removing anomalies into computing power activity credibility, network connection credibility, and energy status credibility according to a preset mapping relationship, generates an original credibility vector, and sends the original credibility vector to the edge node through a long connection channel between the end device and the edge node.

[0043] The cross-validation unit is deployed on the edge node. This unit maintains a list of edge devices in the adjacent area. When it receives the original credibility vector of an edge device, the cross-validation unit stores it in the local cache. If it detects that the computing power activity credibility of the edge device has increased by more than 30% compared with the previous period and its network connection credibility is lower than the average value of the surrounding devices, the cross-validation unit determines that the edge device is suspected of being abnormal.

[0044] Subsequently, the three edge devices that are physically closest to the edge device are selected from the list of edge devices in the adjacent area as verification nodes. The same micro-computation task is issued to these three verification nodes. The micro-computation task is to solve a hash collision problem with a preset complexity. The verification nodes are required to record the actual time taken to execute the task and return the time value.

[0045] The cross-validation unit receives the actual time consumption returned by the three validation nodes and compares the actual time consumption with the theoretical calculation time consumption implied in the computing power activity parameters reported by the suspected abnormal device. If the deviation between the average actual time consumption of the three validation nodes and the theoretical calculation time consumption exceeds the preset deviation range, it is determined that the data reported by the end device is false. The cross-validation unit generates a verification confidence vector based on the degree of falsehood. If the theoretical calculation time consumption is close to the average actual time consumption and the deviation is within the preset range, the value of the verification confidence vector is consistent with the corresponding component in the original confidence vector.

[0046] The credibility fusion unit is deployed at the edge node. This unit receives the original credibility vector sent by the local coarse screening unit and the verification credibility vector sent by the cross-validation unit. At the same time, it collects the current network jitter level as the basis for adjusting the dynamic weight. The network jitter level is obtained by calculating the variance of the network connection credibility of all end devices in the adjacent area in the most recent minute. The larger the variance, the more severe the network jitter.

[0047] The credibility fusion unit adaptively adjusts the original weights and verification weights based on network jitter. When network jitter is severe, the verification weights are increased to suppress the impact of network fluctuations on the original data; when the network is stable, the original weights are increased to quickly respond to changes in the status of end-side devices. The fusion of the original credibility vector and the verification credibility vector is performed using a component-wise weighted approach. Both the original credibility vector and the verification credibility vector contain three components: computing power activity credibility, network connectivity credibility, and energy state credibility. Each component is weighted separately, and then the weighted components are combined to form the final credibility vector. The final credibility is calculated as follows: Final credibility component = Original credibility component × Original weight + Verification credibility component × Verification weight, where Original weight + Verification weight = 1. The dynamic weights are adaptively adjusted based on the network jitter level. Network jitter is calculated by taking the variance σ of the network connection reliability of all end-side devices in the adjacent area over the past minute. The variance is calculated using the sample variance formula, and the value of σ ranges from 0 to 1. The quantitative correspondence between dynamic weights and network jitter is as follows: when σ ≤ 0.2, the network is stable, the original weight is 0.8, and the verification weight is 0.2; when 0.2 < σ ≤ 0.5, the network is slightly jittery, the original weight is 0.5, and the verification weight is 0.5; when σ > 0.5, the network is severely jittery, the original weight is 0.2, and the verification weight is 0.8. The edge nodes calculate the variance of network connection reliability every 10 seconds and adjust the original weights and verification weights in real time based on the calculation results. The original reliability vector is multiplied by the original weights, and the verification reliability vector is multiplied by the verification weights and then added together to obtain the final reliability of the end-side device.

[0048] The credibility fusion unit sends the final credibility to the computing resource normalization module as the admission basis for subsequent scheduling.

[0049] It should be further explained that, in the specific implementation, the original credibility vector includes three components: computing power activity credibility, network connectivity credibility, and energy state credibility.

[0050] The reliability of computing power activity is determined as follows: the edge agent module collects the idle computing power of the central processing unit, the available memory, and the number of storage input / output operations per second. The number of storage input / output operations per second is recorded as the IOPS value. The idle computing power is divided by the peak computing power of the central processing unit of the edge device to obtain the reciprocal of the computing power occupancy. The available memory is divided by the total memory capacity of the edge device to obtain the memory idle ratio. The current IOPS value is divided by the maximum IOPS value of the edge device to obtain the storage idle ratio.

[0051] The computing power activity credibility is obtained by assigning a first weight, a second weight, and a third weight to the inverse of computing power usage, the proportion of memory free space, and the proportion of storage free space, respectively, and then summing them up. The first weight is greater than the second weight, and the second weight is greater than the third weight, so as to reflect the dominant role of computing power resources in the activity assessment.

[0052] The network connection reliability is determined as follows: the end-side proxy module collects the currently received signal strength indication value, and at the same time collects the jitter variance of the network transmission delay in the most recent minute, as well as the predicted dwell time obtained based on the Markov prediction of the movement trajectory. The signal strength indication value is divided by the standard signal strength upper limit of the network where the end-side device is located to obtain the signal strength normalized value. The jitter variance is divided by the preset jitter tolerance threshold to obtain the jitter normalized value and the reciprocal is taken. The predicted dwell time is divided by the preset dwell time benchmark value to obtain the dwell time normalized value.

[0053] The network connectivity credibility is obtained by assigning the normalized signal strength value, the reciprocal of the normalized jitter value, and the normalized dwell time value to the fourth, fifth, and sixth weights, respectively, and then summing them. The fourth weight is greater than the sixth weight, and the sixth weight is greater than the fifth weight, to ensure that signal strength plays a major role in the network credibility assessment.

[0054] The energy state reliability is determined as follows: the end-side agent module collects the remaining battery power, divides the remaining power by the total battery capacity of the end-side device to obtain the power percentage, and collects the charging status. If it is charging, the charging status factor is set to 1; if it is not charging, the charging status factor is set to 0.5. The current energy consumption mode is collected. If it is performance mode, the energy consumption mode factor is set to 1; if it is power saving mode, the energy consumption mode factor is set to 0.3.

[0055] The energy state confidence is obtained by multiplying the battery percentage, charging state factor, and energy consumption mode factor. This product form ensures that the energy state confidence decreases rapidly when the remaining battery is low, not being charged, and in power-saving mode, so as to suppress the scheduling priority of the device on that side.

[0056] The edge proxy module combines the computing power activity credibility, network connection credibility, and energy state credibility obtained above into an original credibility vector, and sends the vector to the edge credibility verification module through an encrypted transmission channel.

[0057] It should be further explained that, in the specific implementation, the heterogeneous computing power mapping unit of the computing power resource normalization module receives information on all end-side devices that have reached the final trustworthiness standard from the edge trust verification module. For each end-side device, the heterogeneous computing power mapping unit extracts its processor type identifier, which includes ARM architecture identifier, x86 architecture identifier, or graphics processor (GPU) identifier. Based on the processor type identifier, the corresponding architecture coefficient is queried in the pre-stored architecture coefficient mapping table.

[0058] The architecture coefficient mapping table is obtained by running standard benchmark tests on various processor architectures in advance. The tests include integer arithmetic tests, floating-point arithmetic tests, and memory access tests. The test results are compared with the test results of a benchmark processor architecture, and the ratio is the architecture coefficient.

[0059] The heterogeneous computing power mapping unit simultaneously extracts the peak computing power of the edge device, multiplies the peak computing power by the architecture coefficient to obtain the basic computing power value, which reflects the equivalent computing power of the edge device under ideal conditions.

[0060] The energy consumption attenuation calculation unit receives the remaining power parameters of the terminal device. The energy consumption attenuation calculation unit divides the remaining power by the total battery capacity of the terminal device to obtain the power percentage. The power percentage is then input into a preset energy consumption attenuation function model, which adopts an S-shaped function form.

[0061] When the percentage of battery power is higher than the preset high battery power threshold, the output value of the energy consumption attenuation factor approaches 1. When the percentage of battery power is lower than the preset low battery power threshold, the output value of the energy consumption attenuation factor decreases non-linearly and accelerates as the percentage of battery power decreases, approaching 0. The energy consumption attenuation calculation unit outputs the calculated energy consumption attenuation factor to the equivalent computing power determination unit.

[0062] The equivalent computing power determination unit multiplies the base computing power value from the heterogeneous computing power mapping unit with the energy consumption attenuation factor from the energy consumption attenuation calculation unit to obtain the equivalent computing power unit. This product operation ensures that the equivalent computing power unit of the end device is close to its base computing power value when the remaining power is sufficient, and the equivalent computing power unit decreases rapidly when the remaining power is insufficient, thereby automatically reducing the distribution of requests to low power devices in subsequent scheduling.

[0063] The equivalent computing power determination unit associates and stores the calculated equivalent computing power unit with the corresponding end-side device identifier, and sends it to the collaborative scheduling optimization module as input parameters for the multi-objective convex optimization model.

[0064] It should be further explained that the energy consumption attenuation factor is calculated using an S-shaped function model, which is built into the energy consumption attenuation calculation unit of the computing power resource normalization module.

[0065] The specific form of the S-shaped function model is as follows: η is the output energy consumption attenuation factor, E is the percentage of the current remaining power of the terminal device to the total battery capacity, E0 is the preset power attenuation midpoint threshold, and k is the attenuation rate control coefficient.

[0066] The energy consumption attenuation calculation unit is pre-calibrated with the values ​​of E0 and k through experiments: E0 is set to 30%, indicating that the energy consumption attenuation factor begins to enter a rapid decline range when the percentage of electricity drops to 30%; k is set to 10 to ensure that a sufficiently steep attenuation curve is formed near E0.

[0067] When the remaining power percentage E of the terminal device is higher than 50%, the output value of the S-shaped function approaches 1, and the equivalent computing power unit approaches the basic computing power value. At this time, the device has the same probability of being selected as other high-power devices in the scheduling.

[0068] When E decreases from 30% to 10%, the energy consumption attenuation factor drops rapidly from about 0.5 to 0.05, and the equivalent computing power unit is reduced proportionally. As a result, in the subsequent multi-objective convex optimization solution process, since the optimization objective includes the minimization of the total predicted energy consumption of the scheduled end-side devices, devices with low equivalent computing power values ​​will be automatically assigned a lower distribution probability by the model.

[0069] When E is below 5%, the energy consumption attenuation factor approaches 0, the equivalent computing power unit approaches 0, and the device is essentially removed from the schedulable resource pool.

[0070] The energy consumption attenuation calculation unit recalculates the energy consumption attenuation factor in each scheduling cycle to ensure that the equivalent computing power unit can reflect the power changes of the end-side equipment in real time.

[0071] This S-shaped function model introduces nonlinear decay characteristics to maintain full computing power output when the power is sufficient to make full use of resources, and suppresses scheduling requests through rapid decay when the power is critical, thus realizing gradual protection for low power devices and avoiding scheduling strategy oscillations or sudden device offline caused by sudden changes in power threshold.

[0072] It should be further explained that, in the specific implementation, the multi-objective convex optimization model constructed by the collaborative scheduling optimization module takes the collaborative scheduling of three-level nodes as the core, and its optimization variables are specifically set as three types of probability values: the first type of probability is the probability that the access node will directly distribute the received service request to the edge node, denoted as P_acc_edge. This probability represents the distribution ratio of request traffic from different access nodes at the edge layer.

[0073] The second type of probability is the probability that the access node will directly distribute service requests to the edge device, denoted as P_acc_end. This probability represents the proportion of access nodes that bypass the edge layer and directly call the edge computing power.

[0074] The third type of probability, denoted as P_edge_end, represents the probability that an edge node, after receiving a request distributed by an access node, will further offload the request to end-side devices within its jurisdiction. This probability characterizes the edge node's ability to reallocate end-side resources as a secondary scheduler. These three types of probability variables coexist and are coupled in the model, together forming a complete end-to-end distribution path.

[0075] The model's constraints include three dimensions: the first is the final credibility constraint of the end-side device, which means that for any end-side device pointed to by the second or third type of probability, the current final credibility of the device must be greater than or equal to the preset scheduling admission threshold. The default value of the scheduling admission threshold is 0.85, to ensure that only end-side devices with a credible state are included in the scheduling scope.

[0076] Secondly, there is an end-to-end latency limit constraint. For any distribution path, the entire process latency from the request arriving at the access node to the end device or edge node completing the response and returning the result must be less than or equal to the upper limit value specified in the service level agreement to which the request belongs. The latency limit value is dynamically configured according to the service type. For services with high real-time requirements, the latency limit is 50 milliseconds, and for ordinary services, the latency limit is 200 milliseconds.

[0077] Thirdly, there is the overall network energy consumption budget constraint. Within a scheduling cycle, the total predicted energy consumption of all scheduled edge devices for executing requests must be less than or equal to the preset overall network energy consumption budget. The overall network energy consumption budget is determined by classifying edge devices based on their power supply status. Edge devices are divided into two categories: those connected to the power grid (such as edge cameras and IoT gateways) and those powered by batteries (such as smartphones and smart sensors). Energy consumption limits are calculated for each category separately, and then summed to obtain the overall network energy consumption budget. The specific calculation formula is: E_overall_network = E_grid × N_grid + E_battery × N_battery, where E_overall_network is the overall network energy consumption budget, E_grid is the energy consumption limit for a single edge device connected to the power grid in a single scheduling cycle (valued at 10Wh), and N_grid is the current connected computing power. The number of grid-powered end-side devices in the network is defined by E-battery, which represents the energy consumption limit for a single battery-powered end-side device during a single scheduling cycle. This value is dynamically adjusted based on the device's remaining power. Specifically, E-battery is set to 2Wh when the remaining power of the battery-powered end-side device is ≥50%, 1Wh when 30% ≤ remaining power < 50%, and 0.5Wh when the remaining power < 30%. N-battery represents the number of battery-powered end-side devices currently connected to the computing network. Each edge node calculates the number of both types of end-side devices and the remaining power of the battery-powered devices every scheduling cycle, recalculates the overall network energy consumption budget, and sets the scheduling cycle to 30 seconds. Simultaneously, 10% of the overall network energy consumption budget is reserved as energy consumption to ensure that sudden service requests from the computing network can be effectively scheduled.

[0078] The collaborative scheduling optimization module aims to minimize the comprehensive load variance of the three-level nodes, minimize the average end-to-end latency of all service requests, and minimize the total predicted energy consumption of the scheduled end-side devices. It uses the above three types of probabilistic variables as decision variables to be solved, and the final credibility threshold, latency upper limit, and energy consumption budget value as constraint boundaries. It uses a convex optimization solver to perform iterative calculations to generate the optimal probability combination that satisfies all constraints as a global distribution strategy, and then distributes this strategy to each access node and edge node for execution.

[0079] It should be further explained that the optimization objective of the multi-objective convex optimization model is constructed and implemented in the following way: The collaborative scheduling optimization module first obtains the cloud node set, the edge node set, and the end-side device set after final credibility screening. For each node, its normalized load value is calculated based on the equivalent computing power unit output by the computing power resource normalization module. The normalized load value is the number of requests to be processed by the node divided by its equivalent computing power unit.

[0080] The comprehensive load variance is calculated as follows: calculate the average of the normalized load values ​​of all three-level nodes, then calculate the square of the difference between the normalized load value of each node and the average value, sum the squares of the differences of all nodes and divide by the total number of nodes to obtain the comprehensive load variance. This variance value is used as the first component of the optimization objective.

[0081] The average end-to-end latency of all service requests is calculated as follows: For each type of distribution path, including paths directly distributed from the access node to the edge node, paths directly distributed from the access node to the end-side device, and paths offloaded from the edge node to the end-side device, the response latency of completed requests on each path is calculated. The response latency includes request transmission latency, node processing latency, and result return latency. The response latency of all paths is summed and divided by the total number of requests to obtain the average end-to-end latency. This latency value is used as the second component of the optimization objective.

[0082] The calculation method for the predicted total energy consumption of the scheduled end-side devices is as follows: For each request planned to be distributed to the end-side devices within the current scheduling cycle, a pre-stored task power consumption mapping table is queried according to the task type of the request. The task power consumption mapping table is obtained by offline calibration of the average power consumption of various typical tasks running on the end-side devices. The task power consumption mapping table classifies the service request tasks of the computing network into three categories: compute-intensive, communication-intensive, and hybrid-intensive. Compute-intensive tasks are mainly tasks involving floating-point operations and data processing, such as video image recognition and big data analysis; communication-intensive tasks are mainly tasks involving data transmission and interaction, such as sensor data reporting and remote command issuance; and hybrid-intensive tasks are tasks with a relatively equal proportion of computation and communication, such as real-time video streaming. The predicted energy consumption values ​​for tasks on the edge devices were obtained through offline calibration. The calibration environment was the standard operating mode of the edge devices. The calibration used a power meter to collect the power consumption of the devices in real time when executing tasks, and combined with the task execution time to calculate the total energy consumption. The specific calibration results are as follows: the average predicted energy consumption per task for computationally intensive tasks is 500mWh, the average predicted energy consumption per task for communication-intensive tasks is 100mWh, and the average predicted energy consumption per task for hybrid-intensive tasks is 300mWh. For custom-type tasks, the predicted energy consumption is calculated using a weighted average method based on the proportion of computation and communication, with a weight of 0.6 for computation and 0.4 for communication. The predicted energy consumption of each request is summed to obtain the total predicted energy consumption, which is used as the third component of the optimization objective.

[0083] The collaborative scheduling optimization module configures load balancing weight, latency optimization weight, and energy consumption constraint weight for the three components mentioned above. The initial values ​​of the three weights are preset by the cloud center according to the business scenario. For example, in a latency-sensitive scenario, the latency optimization weight is 0.6, the load balancing weight is 0.3, and the energy consumption constraint weight is 0.1. In a power-saving priority scenario, the energy consumption constraint weight is 0.7, the load balancing weight is 0.2, and the latency optimization weight is 0.1.

[0084] The collaborative scheduling optimization module uses the sum of the products of the three components and their corresponding weights as the overall objective function of the multi-objective convex optimization model. During the solution process, it adjusts the three types of probability variables to minimize the overall objective function value, thereby achieving a dynamic trade-off between load balancing, latency optimization, and energy consumption control.

[0085] It should be further explained that, in the specific implementation, the local verification unit of the dual-loop feedback verification module is deployed on each end-side device participating in the scheduling. After each request processing is completed by the end-side device, the unit reads the actual energy consumption value and the actual response delay value of the current processing. The actual energy consumption value is obtained by reading the power consumption register of the power management chip of the end-side device, and the actual response delay value is obtained by recording the difference between the request reception timestamp and the result transmission timestamp.

[0086] The local verification unit compares the actual energy consumption value with the predicted energy consumption value predicted by the collaborative scheduling optimization module based on the task power consumption mapping table when distributing the request, and compares the actual latency value with the model predicted latency value. When the actual energy consumption value exceeds 1.2 times the predicted energy consumption value, or the actual latency value exceeds 1.5 times the predicted latency value, the local verification unit determines that there is a deviation between the current state of the edge device and the assumed state of the model, immediately lowers the local storage credibility of the edge device by 30%, and sends a deviation alarm containing the device identifier, deviation type, and deviation value to the corresponding edge node through the control channel uplink.

[0087] The edge post-hoc unit is deployed at the edge node. This unit continuously collects deviation alarms reported by all end-side devices in its jurisdiction, as well as the actual execution data of these devices in the previous scheduling cycle. The actual execution data includes the actual energy consumption, actual latency, and actual node identifier of each completed request.

[0088] The edge posterior unit takes the actual execution data as input, re-substitutes it into the multi-objective convex optimization model for calculation, and obtains a set of posterior optimization results. The posterior optimization results are compared with the optimization objective value corresponding to the global distribution strategy actually adopted in the previous cycle, and the posterior decision quality score is calculated. The posterior decision quality score is the weighted fit between the three components of the comprehensive load variance, average end-to-end latency and predicted total energy consumption obtained after substituting the actual execution data and the expected values ​​of the model.

[0089] When the posterior decision quality score is lower than the preset quality threshold of 0.7, the marginal posterior unit determines that the current multi-objective convex optimization model parameters can no longer accurately adapt to the actual environment, and packages and uploads the posterior data, including actual execution data, deviation alarm summary, and current model parameters, to the cloud center.

[0090] The cloud center optimization unit is deployed on the cloud center server. This unit receives posterior data from multiple edge nodes, uses the actual execution results in the posterior data as state input, uses the corresponding model parameters as actions, and uses the degree of agreement between the actual execution results and the optimization objective as rewards to construct training samples for the deep Q-network reinforcement learning model.

[0091] The Deep Q-Network model consists of three fully connected neural networks. The number of nodes in the input layer is the dimension of posterior data features, the number of nodes in the hidden layer is 128, and the number of nodes in the output layer is the dimension of adjustable weight coefficient combinations.

[0092] The cloud center optimization unit uses accumulated historical posterior data to periodically train the deep Q-network model offline. The training objective is to maximize the long-term cumulative reward, i.e., minimize the global load balancing bias and the total network energy consumption. After training converges, the cloud center optimization unit uses the current optimal model parameters as output to generate updated multi-objective convex optimization model weight coefficients. The weight coefficients include load balancing weights, latency optimization weights, and energy consumption constraint weights.

[0093] The cloud center optimization unit packages the updated weight coefficients into an adaptive optimization parameter package, which is then distributed to all edge nodes and access nodes through the control plane. When the edge nodes start in the next scheduling cycle, they load the new weight coefficients and resolve the multi-objective convex optimization model to achieve online adaptive updating of model parameters.

[0094] It should be further explained that the linkage mechanism is activated after the local verification unit triggers a temporary downgrade of trustworthiness. When the local verification unit of the end device determines that there is a deviation because the actual power consumption exceeds the predicted power consumption by 1.2 times or the actual latency exceeds the predicted latency by 1.5 times, the unit immediately lowers the locally stored trustworthiness identifier of the device by 30% and sends a deviation alarm to the corresponding edge node through the control channel uplink. The deviation alarm includes the device identifier, deviation type, deviation value, and the median trustworthiness value after the temporary downgrade.

[0095] After receiving a deviation alarm, the edge trust verification module recalculates the final trustworthiness by using the temporarily downgraded local trustworthiness as a reference benchmark for the original trustworthiness vector. A downgrade coefficient of 0.7 is introduced into the calculation of the original trustworthiness vector, i.e., the recalculated original trustworthiness vector = original original trustworthiness vector × 0.7. The updated final trustworthiness is then calculated by combining the verification trustworthiness vector and dynamic weights. If the updated final trustworthiness is still ≥ 0.85, the distribution probability of the device is adjusted. If the updated final trustworthiness is < 0.85, the device is temporarily removed from the schedulable resource pool for the current scheduling cycle. The edge node continuously monitors the status of the device and reassesses its final trustworthiness every 30 seconds. When the final trustworthiness recovers to ≥ 0.85, the device is reinstated into the schedulable resource pool.

[0096] The edge trust verification module compares the actual time taken by this rapid verification with the computing power activity parameters currently reported by the device. Combining the historical data trends of the last three periods, it recalculates the verification trust vector of the device using a weighted average method. The weight of this rapid verification result is set to 0.6, and the weights of the historical verification results of the last three periods are 0.2, 0.1, and 0.05 respectively, to ensure timely reflection of current status changes.

[0097] The edge trust verification module then inputs the recalculated verification trust vector and the original trust vector most recently reported by the local coarse screening unit into the trust fusion unit. The trust fusion unit dynamically adjusts the original weight and verification weight according to the current network jitter level, recalculates the final trust of the end device, and sends the updated final trust to the collaborative scheduling optimization module.

[0098] After receiving the updated final credibility, the collaborative scheduling optimization module immediately triggers a local policy adjustment process. The module first determines whether the updated final credibility is still greater than or equal to the scheduling admission threshold of 0.85. If it is still greater than or equal to the threshold, the second and third probabilities involving the device are reduced proportionally according to the decrease in final credibility. Specifically, the original distribution probability is multiplied by the ratio of the updated final credibility to the pre-update final credibility, ensuring that the probability of the device being scheduled matches its credibility status in real time.

[0099] If the updated final credibility is lower than the scheduling admission threshold of 0.85, the collaborative scheduling optimization module will temporarily remove the device from the schedulable resource pool of the current scheduling cycle, that is, set all second and third probabilities involving the device to 0, and then reinstate the device into the resource pool after the credibility of the device is restored in the next cycle.

[0100] After the probability adjustment is completed, the collaborative scheduling optimization module will send the updated local distribution strategy to the relevant access nodes and edge nodes in real time for execution, thus completing the response to changes in the status of the end-side devices.

[0101] It should be further explained that, in the specific implementation, the deep Q-network reinforcement learning model adopted by the cloud center optimization unit aims to minimize the global load balancing deviation and the total network energy consumption, and dynamically updates the weight coefficients of the multi-objective convex optimization model.

[0102] The input data for this model comes from posterior data uploaded by multiple edge nodes. Each posterior data includes the actual energy consumption, actual response latency, actual load distribution, and corresponding deviation alarm information of all end-side devices within a scheduling cycle.

[0103] The cloud center optimization unit first extracts features from the posterior data. The sum of the absolute values ​​of the differences between the actual load distribution and the model's expected load distribution is used as the load balancing deviation feature. The difference between the actual average latency and the model's expected latency is used as the latency deviation feature. The difference between the actual total energy consumption and the model's expected total energy consumption is used as the energy consumption deviation feature. The proportion of all deviation alarms triggered by energy consumption exceeding the standard is used as the energy consumption violation feature. The proportion of all deviation alarms triggered by latency exceeding the standard is used as the latency violation feature. At the same time, the specific values ​​of the load balancing weight, latency optimization weight, and energy consumption constraint weight used in the current scheduling cycle are used as action features. The above features are combined into a state feature vector.

[0104] The cloud center optimization unit constructs a deep Q-network, which includes an input layer, two hidden layers, and an output layer. The number of nodes in the input layer is consistent with the dimension of the state feature vector, set to 64. The number of nodes in the two hidden layers are 128 and 64, respectively. The activation function is a linear rectified function. The number of nodes in the output layer corresponds to the number of weight adjustment actions. Each action corresponds to a set of preset weight increment combinations, such as increasing the load balancing weight by 0.05, decreasing the latency optimization weight by 0.03, and decreasing the energy consumption constraint weight by 0.02, or decreasing the load balancing weight by 0.02, increasing the latency optimization weight by 0.04, and decreasing the energy consumption constraint weight by 0.02, etc., for a total of 27 preset actions.

[0105] The cloud center optimization unit stores historical posterior data into the experience replay pool in chronological order. Each time, 64 samples are randomly selected from the experience replay pool to form a mini-batch training data. For each sample, the state feature vector is input into a deep Q-network. The network outputs the Q value corresponding to each action. The Q value represents the cumulative reward expected to be obtained after performing the action in this state. The reward function is calculated as follows: the reward value is equal to the weighted sum of the negative load balancing deviation, latency deviation, and energy consumption deviation. The smaller the deviation, the larger the reward value; the larger the deviation, the more negative the reward value.

[0106] The cloud center tuning unit uses gradient descent to train a deep Q-network with the goal of minimizing the temporal difference error in the Bellman equation. After every thousand training iterations, the current network parameters are copied to the target network to stabilize the training process.

[0107] Once training converges, the cloud center tuning unit freezes the latest network parameters. For each edge node that has uploaded post-hoc data, the current state feature vector of that node is input into the deep Q-network. The action with the largest Q-value output by the network is taken as the optimal adjustment action. Based on the incremental combination corresponding to this action, the current load balancing weights, latency optimization weights, and energy consumption constraint weights are updated to obtain a new set of weight coefficients.

[0108] The cloud center optimization unit binds the updated weight coefficients with the corresponding edge node identifiers to generate an adaptive optimization parameter package, which is then sent to the corresponding edge nodes through the control plane channel. After receiving the parameter package, the edge nodes load the new weight coefficients and re-solve the multi-objective convex optimization model when the next scheduling cycle starts, thereby achieving adaptive optimization under different network environments and load characteristics.

[0109] In a specific implementation, the deep Q-network reinforcement learning model used by the cloud center optimization unit aims to minimize the global load balancing deviation and the total network energy consumption, and dynamically updates the weight coefficients of the multi-objective convex optimization model.

[0110] The input data for this model comes from posterior data uploaded by multiple edge nodes. Each posterior data includes the actual energy consumption, actual response latency, actual load distribution, and corresponding deviation alarm information of all end-side devices within a scheduling cycle.

[0111] The cloud center optimization unit first extracts features from the posterior data. The sum of the absolute values ​​of the differences between the actual load distribution and the model's expected load distribution is used as the load balancing deviation feature. The difference between the actual average latency and the model's expected latency is used as the latency deviation feature. The difference between the actual total energy consumption and the model's expected total energy consumption is used as the energy consumption deviation feature. The proportion of all deviation alarms triggered by energy consumption exceeding the standard is used as the energy consumption violation feature. The proportion of all deviation alarms triggered by latency exceeding the standard is used as the latency violation feature. At the same time, the specific values ​​of the load balancing weight, latency optimization weight, and energy consumption constraint weight used in the current scheduling cycle are used as action features. The above features are combined into a state feature vector.

[0112] The cloud center optimization unit constructs a deep Q-network, which includes an input layer, two hidden layers, and an output layer. The number of nodes in the input layer is consistent with the dimension of the state feature vector, set to 64. The number of nodes in the two hidden layers are 128 and 64, respectively. The activation function is a linear rectified function. The number of nodes in the output layer corresponds to the number of weight adjustment actions. Each action corresponds to a set of preset weight increment combinations, such as increasing the load balancing weight by 0.05, decreasing the latency optimization weight by 0.03, and decreasing the energy consumption constraint weight by 0.02, or decreasing the load balancing weight by 0.02, increasing the latency optimization weight by 0.04, and decreasing the energy consumption constraint weight by 0.02, etc., for a total of 27 preset actions.

[0113] The cloud center optimization unit stores historical posterior data into the experience replay pool in chronological order. Each time, 64 samples are randomly selected from the experience replay pool to form a mini-batch training data. For each sample, the state feature vector is input into a deep Q-network. The network outputs the Q value corresponding to each action. The Q value represents the cumulative reward expected to be obtained after performing the action in this state. The reward function is calculated as follows: the reward value is equal to the weighted sum of the negative load balancing deviation, latency deviation, and energy consumption deviation. The smaller the deviation, the larger the reward value; the larger the deviation, the more negative the reward value.

[0114] The cloud center tuning unit uses gradient descent to train a deep Q-network with the goal of minimizing the temporal difference error in the Bellman equation. After every thousand training iterations, the current network parameters are copied to the target network to stabilize the training process.

[0115] Once training converges, the cloud center tuning unit freezes the latest network parameters. For each edge node that has uploaded post-hoc data, the current state feature vector of that node is input into the deep Q-network. The action with the largest Q-value output by the network is taken as the optimal adjustment action. Based on the incremental combination corresponding to this action, the current load balancing weights, latency optimization weights, and energy consumption constraint weights are updated to obtain a new set of weight coefficients.

[0116] The cloud center optimization unit binds the updated weight coefficients with the corresponding edge node identifiers to generate an adaptive optimization parameter package, which is then sent to the corresponding edge nodes through the control plane channel. After receiving the parameter package, the edge nodes load the new weight coefficients and re-solve the multi-objective convex optimization model when the next scheduling cycle starts, thereby achieving adaptive optimization under different network environments and load characteristics.

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

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

Claims

1. A cloud-edge-device collaborative computing power network service request balanced distribution system, characterized in that, include: The edge proxy module is deployed on each edge device to collect the computing power activity parameters, network connection parameters and energy status parameters of the edge device in real time, and generate an original trust vector based on the parameters. An edge trust verification module, deployed at edge nodes, receives the original trust vectors of multiple end-side devices in adjacent areas, performs cross-validation on the original trust vectors using a distributed consensus algorithm to generate a verification trust vector, and calculates the final trust of each end-side device based on the original trust vector and the verification trust vector. A computing power resource normalization module filters schedulable end-side devices based on the final trust, and maps the heterogeneous computing power resources of the filtered end-side devices to equivalent computing power units, which are determined based on computing power performance and remaining power. A collaborative scheduling optimization module constructs a multi-objective convex optimization model and generates a global distribution strategy, with optimization objectives including comprehensive load balancing of cloud nodes, edge nodes, and end-side devices, end-to-end service latency, and end-side device energy consumption. The dual-loop feedback verification module is used to receive the actual energy consumption and response latency of the end-side device after it executes the request, perform local verification and edge post-verification, and feed back the verification results to the collaborative scheduling optimization module to dynamically adjust the parameters of the multi-objective convex optimization model.

2. The cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 1, characterized in that: The edge trust verification module includes: a local coarse screening unit, deployed on the edge proxy module, used to remove abnormal data from the computing power activity parameters, network connection parameters, and energy state parameters, generate an original trust vector, and send it to the edge node; a cross-validation unit, deployed on the edge node, used to receive the original trust vectors of multiple edge devices in adjacent areas, and initiate computing power proof challenges for suspected abnormal edge devices. The computing power proof challenge involves issuing micro-computing tasks to neighboring devices to verify whether the actual computing power matches the reported value, and generating a verification trust vector based on the verification results; and a trust fusion unit, used to weight and fuse the original trust vector and the verification trust vector according to dynamic weights to generate the final trust of the edge device. The dynamic weights are adaptively adjusted according to the network jitter level.

3. The cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 2, characterized in that: The original credibility vector includes computing power activity credibility, network connection credibility, and energy status credibility; wherein, the computing power activity credibility is determined based on the idle computing power of the central processing unit of the edge device, the amount of available memory, and the number of storage input / output operations per second; the network connection credibility is determined based on signal strength, connection jitter variance, and predicted dwell time; and the energy status credibility is determined based on remaining power, charging status, and energy consumption mode.

4. The cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 1, characterized in that: The computing power resource normalization module includes: a heterogeneous computing power mapping unit, used to multiply the peak computing power of the selected end-side devices by the architecture coefficient to obtain a basic computing power value; an energy consumption attenuation calculation unit, used to calculate an energy consumption attenuation factor based on the remaining power of the end-side devices, wherein the energy consumption attenuation factor tends to be one when the remaining power is higher than a threshold, and decays non-linearly as the remaining power decreases when the remaining power is lower than the threshold; and an equivalent computing power determination unit, used to multiply the basic computing power value by the energy consumption attenuation factor to obtain the equivalent computing power unit of the end-side devices.

5. A cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 4, characterized in that: The energy consumption attenuation factor is calculated using a sigmoid function model. This sigmoid function model ensures that when the remaining power is below a threshold, the attenuation rate of the equivalent computing power unit gradually increases as the power decreases, in order to avoid over-scheduling of low-power end-side devices.

6. The cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 1, characterized in that: The multi-objective convex optimization model constructed by the collaborative scheduling optimization module has optimization variables including the probability of an access node being distributed to an edge node, the probability of an access node being directly distributed to an end-side device, and the probability of an edge node being offloaded to an end-side device. Its constraints include the end-side device's final credibility constraint, the end-to-end latency upper limit constraint, and the network-wide energy consumption budget constraint.

7. A cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 6, characterized in that: The optimization objectives of the multi-objective convex optimization model include minimizing the comprehensive load variance of the three-level nodes (cloud node, edge node, and end-side device), minimizing the average end-to-end latency of all service requests, and minimizing the total predicted energy consumption of the scheduled end-side devices. The comprehensive load variance is calculated by normalization based on the equivalent computing power unit.

8. A cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 1, characterized in that: The dual-loop feedback verification module includes: a local verification unit, deployed on the edge device, used to compare the actual energy consumption with the predicted energy consumption and the actual latency with the predicted latency after each request processing. When the deviation exceeds a preset threshold, it triggers a temporary degradation of credibility and sends a deviation alarm to the edge node; an edge posterior unit, deployed on the edge node, used to collect deviation alarms and actual execution data from the edge device within the region, re-input the actual execution data into the multi-objective convex optimization model to calculate the posterior decision quality score, and upload the posterior data to the cloud center when the posterior decision quality score is lower than a preset threshold; and a cloud center optimization unit, used to receive the posterior data and dynamically adjust the weight coefficients of the multi-objective convex optimization model and the final credibility threshold based on the reinforcement learning model, generating an adaptive optimization parameter package and distributing it to all edge nodes.

9. A cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 8, characterized in that: After the local verification unit triggers a temporary downgrade in credibility, the edge trusted verification module recalculates the final credibility of the end device, and the collaborative scheduling optimization module adjusts the distribution probability involving the end device based on the updated final credibility.

10. A cloud-edge-device collaborative computing power network service request balanced distribution system according to claim 8, characterized in that: The reinforcement learning model used by the cloud center optimization unit takes the posterior data uploaded by the edge nodes as input, aims to minimize the global load balancing deviation and the total network energy consumption, and outputs the updated weight coefficients of the multi-objective convex optimization model. The weight coefficients include load balancing weights, latency optimization weights, and energy consumption constraint weights.

Images