Virtualized computing resource scheduling method and system based on power wireless local area network

Abstract

The invention provides a virtualized computing resource scheduling method and system based on a power wireless local area network, and the method comprises the steps: firstly obtaining power equipment operation load data of access equipment in the coverage of the power wireless local area network, including real-time current fluctuation and other features, carrying out the load feature extraction of the power equipment operation load data, and carrying out the load feature extraction of the power equipment operation load data; performing dynamic resource demand prediction on the set based on a preset load prediction model to generate a virtual resource demand prediction result including computing resource allocation magnitude and the like; generating a virtualized resource scheduling strategy containing edge computing node resource allocation topology and the like according to a virtualized resource demand prediction result, and finally dynamically adjusting virtualized computing resources based on the virtualized resource scheduling strategy, triggering resource reallocation and updating a global resource state mapping table. Effective scheduling of virtualized computing resources of the power wireless local area network is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing, and in particular to a method and system for scheduling virtualized computing resources based on a power wireless local area network. Background Art

[0002] In the field of power wireless LAN, with the increasing number of access devices and the increasing complexity of power equipment operation, the effective scheduling of virtualized computing resources has become a key issue that needs to be solved urgently.

[0003] Existing power wireless LAN resource scheduling technologies are mostly based on simple device connection status and fixed resource allocation rules. Typically, resource scheduling is based solely on device online availability and a pre-set, rough resource allocation ratio. This approach completely ignores the rich information contained in power equipment operating load data. In actual operation, key data such as real-time current fluctuation characteristics, voltage phase offset characteristics, and equipment operating cycle parameters contain important clues to equipment operating status and resource requirements, but existing technologies fail to effectively utilize this data.

[0004] Due to a lack of in-depth understanding of load characteristics, existing technologies cannot accurately grasp the actual resource requirements of each access device. This results in a one-size-fits-all approach to resource allocation, leading to excess resources for some devices and insufficient resources for others, impacting both normal device operation and the efficiency of power business processing. Furthermore, existing resource scheduling strategies are often static and cannot dynamically adjust to real-time device load changes, making them unsuitable for the rapidly fluctuating loads in power wireless LANs. Summary of the Invention

[0005] In view of the above-mentioned problems, in combination with the first aspect of the present invention, an embodiment of the present invention provides a method for scheduling virtualized computing resources based on a power wireless local area network, the method comprising:

[0006] Obtaining power equipment operating load data of all connected devices within the coverage area of the power wireless local area network, wherein the power equipment operating load data includes real-time current fluctuation characteristics, voltage phase offset characteristics, and equipment operating cycle parameters;

[0007] Extracting load characteristics from the operating load data of the power equipment to obtain a load characteristic set for each connected device, wherein the load characteristic set includes a device power consumption fluctuation characteristic, a load response time characteristic, and a resource request priority characteristic;

[0008] Performing dynamic resource demand forecasting on the load feature set based on a preset load forecasting model to generate a virtualized resource demand forecast result for each access device, wherein the virtualized resource demand forecast result includes a computing resource allocation magnitude and a storage resource allocation timeliness requirement;

[0009] Generate a virtualization resource scheduling strategy based on the virtualization resource demand prediction result, wherein the virtualization resource scheduling strategy includes a resource allocation topology of edge computing nodes and a resource redundancy backup instruction of a central cloud node;

[0010] Based on the virtualized resource scheduling strategy, the virtualized computing resources of the power wireless local area network are dynamically adjusted to trigger a resource reallocation operation and update a global resource status mapping table.

[0011] On the other hand, an embodiment of the present invention also provides a virtualized computing resource scheduling system based on a power wireless local area network, including a processor and a machine-readable storage medium, wherein the machine-readable storage medium is connected to the processor, the machine-readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine-readable storage medium to implement the above method.

[0012] Based on the above aspects, the embodiment of the present invention integrates the power equipment operating load data of access devices within the coverage area of the power wireless local area network, and then constructs a dynamic resource demand prediction mechanism based on a preset load prediction model. It can generate virtualized resource demand prediction results for each access device, which not only clarifies the magnitude of computing resource allocation, but also defines the timeliness requirements for storage resource allocation. On this basis, the generated virtualized resource scheduling strategy integrates the resource allocation topology of the edge computing node and the resource redundancy backup instructions of the central cloud node, forming a multi-level, highly flexible resource scheduling system that not only ensures the efficient utilization of local resources but also ensures the reliable backup of global resources. Ultimately, by dynamically adjusting the virtualized computing resources of the power wireless local area network, triggering resource reallocation operations and updating the global resource status mapping table in real time, intelligent, automated and global optimization of resource scheduling is achieved, significantly improving the resource utilization efficiency, response speed and system stability of the power wireless local area network in complex load environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 It is a schematic diagram of the execution flow of the virtualized computing resource scheduling method based on the power wireless local area network provided by an embodiment of the present invention.

[0014] Figure 2 It is a schematic diagram of exemplary hardware and software components of a virtualized computing resource scheduling system based on a power wireless local area network provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0015] The present invention will be described in detail below with reference to the accompanying drawings. Figure 1 This is a flow chart of a method for scheduling virtualized computing resources based on a power wireless local area network provided by an embodiment of the present invention. The method for scheduling virtualized computing resources based on a power wireless local area network is introduced in detail below.

[0016] Step S110: acquiring power equipment operating load data of all connected devices within the coverage of the power wireless local area network, wherein the power equipment operating load data includes real-time current fluctuation characteristics, voltage phase shift characteristics and equipment operating cycle parameters.

[0017] In the actual operation of power wireless LANs, there are various access devices, such as smart meters, power sensors, and surveillance cameras. These devices generate different power loads during operation. In order to achieve accurate scheduling of virtualized computing resources, it is first necessary to obtain the power equipment operating load data of these access devices. The real-time current fluctuation characteristics can reflect the changes in current during device operation, the voltage phase offset characteristics reflect the deviation between the voltage and the standard phase, and the device operation cycle parameters describe the periodic law of the device's task execution. The specific implementation is as follows:

[0018] Step S111: sending a periodic load monitoring instruction to each access device in the power wireless local area network, where the periodic load monitoring instruction includes a device identifier and a monitoring time window parameter.

[0019] In a power wireless LAN (WLAN) with multiple access devices, the central dispatching node is responsible for sending instructions to each device. For example, in a WLAN with 50 devices, the central dispatching node can send periodic load monitoring instructions to each device in a specific order. A device identifier uniquely identifies each device and is used to distinguish between them. For example, the identifier for device 1 might be "Device001," the identifier for device 2 "Device002," and so on, up to the identifier for device 50, "Device050." The monitoring time window parameter specifies the time period for data collection. This ensures that load data from each device is collected within a consistent timeframe for effective comparison and analysis. For example, if the monitoring time window is set to 30 minutes from the current time, the central dispatching node will require each device to monitor and record its load data for the next 30 minutes.

[0020] Step S112: receiving an original load monitoring data packet returned by each connected device within the monitoring time window, wherein the original load monitoring data packet includes a current waveform sampling sequence, a voltage waveform sampling sequence, and a device operation status log.

[0021] After receiving the periodic load monitoring command, each connected device begins data collection within the specified monitoring time window. For example, connected device "Device001" can sample current and voltage at a specific sampling frequency. Assuming a sampling frequency of 10 times per second, within a 30-minute (1800-second) monitoring time window, 18,000 current and 18,000 voltage samples are obtained. These samples are arranged in chronological order to form current and voltage waveform sampling sequences. Simultaneously, the connected device records its own operating status, including task start and end times, resource usage, and other information, which is organized into a device operating status log. After the monitoring time window expires, the connected device sends a raw load monitoring data packet containing the current and voltage waveform sampling sequences and the device operating status log back to the central scheduling node. The central scheduling node receives and stores these data packets for further processing and analysis.

[0022] Step S113: performing fluctuation feature extraction processing on the current waveform sampling sequence to obtain the real-time current fluctuation feature, wherein the real-time current fluctuation feature includes current peak offset, waveform distortion rate and frequency harmonic distribution parameters.

[0023] Taking the current waveform sampling sequence of the connected device "Device001" as an example, we first calculate the current peak offset. Current peak offset refers to the difference between the actual current peak and the theoretical current peak. Under normal circumstances, the device's current peak should remain within a relatively stable range. However, due to factors such as the device's operating status and the external environment, the actual current peak may deviate from the theoretical value. By analyzing and comparing each peak value in the current waveform sampling sequence, we can calculate the current peak offset. For example, if the theoretical current peak value in a certain sampling period is 5 amperes, while the actual current peak value is 5.2 amperes, the current peak offset for that sampling period is 0.2 amperes.

[0024] Next, calculate the waveform distortion rate. The waveform distortion rate reflects the degree of deviation of the current waveform from a standard sine wave. The waveform distortion rate can be obtained by comparing the actual current waveform with the standard sine wave and calculating the difference between the two. Specifically, each sampling point in the current waveform sampling sequence can be compared with the corresponding standard sine wave sampling point, and the sum of the squares of the differences between them can be calculated. The average value is then taken and the square root is taken to obtain the waveform distortion rate. Assume that the current waveform distortion rate of the connected device "Device001" is calculated to be 0.05, indicating that the current waveform of this device deviates to a certain extent from the standard sine wave.

[0025] Finally, the frequency harmonic distribution parameters are calculated. Frequency harmonics refer to frequency components in the current waveform other than the fundamental frequency. By performing a Fourier transform on the current waveform sampling sequence, we can convert it from the time domain to the frequency domain, thereby obtaining the frequency component distribution of the current waveform. In the frequency domain, we can analyze the amplitude and phase of each frequency harmonic, and these parameters constitute the frequency harmonic distribution parameters. For example, after the Fourier transform, it is detected that the current waveform of the connected device "Device001" contains, in addition to the fundamental frequency, the third and fifth harmonics, with amplitudes of 0.2 amps and 0.1 amps, respectively, and phases of 30 degrees and 60 degrees, respectively. These amplitude and phase information constitute part of the frequency harmonic distribution parameters. By combining the calculated current peak offset, waveform distortion rate, and frequency harmonic distribution parameters, we can obtain the real-time current fluctuation characteristics of the connected device "Device001."

[0026] Step S114: performing phase shift analysis processing on the voltage waveform sampling sequence to obtain the voltage phase shift characteristics, wherein the voltage phase shift characteristics include phase synchronization error, voltage drop amplitude, and transient response delay parameter.

[0027] Similarly, the central dispatching node can perform phase offset analysis on the voltage waveform sampling sequence. Taking the voltage waveform sampling sequence of the access device "Device001" as an example, the phase synchronization error is first calculated. The phase synchronization error refers to the difference between the actual voltage phase and the standard voltage phase. In the power system, the voltage phase should be synchronized with the standard phase, but due to various factors, the actual voltage phase may be offset. By analyzing and comparing the phase of each sampling point in the voltage waveform sampling sequence, the phase synchronization error can be calculated. For example, within a certain sampling period, the standard voltage phase is 0 degrees, while the actual voltage phase is 5 degrees, then the phase synchronization error within the sampling period is 5 degrees.

[0028] Next, calculate the voltage sag. A voltage sag is a sudden drop in voltage over a short period of time. The voltage sag can be calculated by comparing the maximum and minimum voltage values in the voltage waveform sampling sequence. For example, if the maximum voltage value in the voltage waveform sampling sequence for the connected device "Device001" during a certain time period is 220 volts and the minimum voltage value is 200 volts, then the voltage sag is 20 volts.

[0029] Finally, calculate the transient response delay parameter. Transient response delay refers to the time it takes for the voltage to return to a stable state after a device is subjected to external interference or load changes. By analyzing the changes in the voltage waveform sampling sequence after the interference, the time interval from the voltage starting to drop to the voltage returning to a stable state can be determined. This time interval is the transient response delay parameter. For example, when the load on the connected device "Device001" suddenly increases, the voltage begins to drop. After 50 milliseconds, the voltage returns to a stable state. The transient response delay parameter is 50 milliseconds. By combining these calculated phase synchronization error, voltage drop amplitude, and transient response delay parameters, the voltage phase offset characteristics of the connected device "Device001" are obtained.

[0030] Step S115: parsing the periodic task triggering record in the device operation status log to generate the device operation cycle parameters, which include the task execution interval, the task processing time threshold, and the resource occupancy ratio upper limit.

[0031] Taking the device operation status log for access device "Device001" as an example, we first analyze the task execution interval. The task execution interval refers to the time interval between two consecutive task triggers. By counting and analyzing the task trigger times in the device operation status log, we can calculate the task execution interval. For example, if the device operation status log records that Task A was triggered at the 10th, 20th, and 30th minutes, the task execution interval for Task A is 10 minutes.

[0032] Next, determine the task processing time threshold. This threshold represents the maximum time allowed for the device to complete a task. By analyzing the task start and end times in the device's operating status log, you can calculate the processing time for different tasks and use this data to determine a reasonable task processing time threshold. For example, if analysis of the device's operating status log reveals that Task B typically takes less than 5 minutes to process, you can set the threshold for Task B to 6 minutes.

[0033] Finally, calculate the upper limit of the resource usage ratio. The upper limit of the resource usage ratio refers to the maximum resource ratio allowed to be occupied by the device during the execution of the task. By analyzing the resource usage in the device operation status log, the resource ratio occupied by different tasks during the execution process can be statistically calculated, and a reasonable upper limit of the resource usage ratio can be determined based on this data. For example, after analyzing the device operation status log, it is detected that the proportion of CPU resources occupied by Task C during the execution process is mostly within 30%. In this case, the upper limit of the resource usage ratio of Task C can be set to 35%. By combining these calculated task execution intervals, task processing time thresholds, and resource usage ratio upper limits, the device operation cycle parameters of the access device "Device001" are obtained.

[0034] Step S120: extracting load characteristics from the power equipment operating load data to obtain a load characteristic set for each connected device, wherein the load characteristic set includes device power consumption fluctuation characteristics, load response time characteristics, and resource request priority characteristics.

[0035] After acquiring the operating load data of power equipment, further processing is required to extract key features that reflect the equipment load and form a load feature set. The device power consumption fluctuation feature reflects the changes in power consumption during operation. The load response timeliness feature reflects the speed and timeliness of the device's response to resource requests. The resource request priority feature is used to determine the device's priority during resource allocation.

[0036] Step S121: Construct a device power consumption calculation function according to the real-time current fluctuation characteristics and the voltage phase offset characteristics, and generate the device power consumption fluctuation characteristics based on the device power consumption calculation function, wherein the device power consumption fluctuation characteristics include the power consumption change rate per unit time, the peak power consumption duration and the low power state switching frequency.

[0037] Taking the connected device "Device001" as an example, the central dispatching node constructs a function to calculate device power consumption based on the previously calculated real-time current fluctuation characteristics and voltage phase offset characteristics. The current peak offset, waveform distortion rate, and frequency harmonic distribution parameters in the real-time current fluctuation characteristics, as well as the phase synchronization error, voltage drop amplitude, and transient response delay parameters in the voltage phase offset characteristics, all affect device power consumption. By comprehensively considering these factors, a function can be constructed to accurately calculate device power consumption.

[0038] After obtaining the device power consumption calculation function, we can calculate the device power consumption fluctuation characteristics. First, calculate the power consumption change rate per unit time. The power consumption change rate per unit time refers to the proportion of change in the device's power consumption per unit time. By calculating and comparing the device's power consumption at different time points, we can determine the change in power consumption per unit time. This change is then divided by the average power consumption for that time period to obtain the power consumption change rate per unit time. For example, within a minute, the initial power consumption of the connected device "Device001" is 100 watts, and at the end of the minute, the power consumption is 110 watts. Therefore, the change in power consumption for that minute is 10 watts. Assuming the average power consumption for that minute is 105 watts, the power consumption change rate per unit time is 10 ÷ 105 ≈ 0.095, or 9.5%.

[0039] Next, calculate the peak power consumption duration. Peak power consumption duration refers to the length of time a device maintains peak power consumption after reaching peak power consumption. By analyzing the device power consumption curve over time, you can determine the time when peak power consumption occurs and ends. The time interval between the two is the peak power consumption duration. For example, if the access device "Device001" reaches a peak power consumption of 200 watts during a certain period of time, and the interval from the peak power consumption to the power consumption dropping to 190 watts is 5 minutes, then the peak power consumption duration is 5 minutes.

[0040] Finally, calculate the low-power state switching frequency. The low-power state switching frequency refers to how often the device enters and exits the low-power state during operation. By analyzing the curve of the device's power consumption over time, the number of times the device enters the low-power state (that is, the power consumption is lower than a certain set threshold) and the number of times it exits the low-power state can be counted. The sum of the two is the low-power state switching frequency. Assuming that within an hour, the access device "Device001" enters the low-power state 5 times and exits the low-power state 5 times, then the low-power state switching frequency is 10 times / hour. Therefore, by combining the calculated power consumption change rate per unit time, peak power consumption duration, and low-power state switching frequency, we can obtain the device power consumption fluctuation characteristics of the access device "Device001".

[0041] Step S122: performing response timeliness modeling processing on the equipment operation cycle parameters to generate the load response timeliness characteristics, wherein the load response timeliness characteristics include task processing delay tolerance, resource request response timeout threshold, and real-time assurance level identifier.

[0042] Taking the device operation cycle parameters for access device "Device001" as an example, first determine the task processing delay tolerance. The task processing delay tolerance refers to the amount of task processing delay that the device can tolerate. The task processing delay tolerance can be determined based on the task execution interval and the task processing time threshold in the device operation cycle parameters. For example, if the task execution interval is 10 minutes and the task processing time threshold is 5 minutes, the task processing delay tolerance can be set to 3 minutes. This means that if the device starts processing the task within 3 minutes after the task is triggered, it is considered within the tolerable range.

[0043] Next, determine the resource request response timeout threshold. The resource request response timeout threshold refers to the maximum amount of time a device can wait for a response after issuing a resource request. The resource request response timeout threshold can be determined based on the device's business needs and the urgency of the task. For example, for tasks with high real-time requirements, the resource request response timeout threshold can be set to a shorter time, such as 1 second; while for tasks with lower real-time requirements, the resource request response timeout threshold can be set to a longer time, such as 10 seconds. Assuming that a task on the access device "Device001" has high real-time requirements, the resource request response timeout threshold for that task can be set to 2 seconds.

[0044] Finally, determine the real-time assurance level identifier. The real-time assurance level identifier indicates the device's real-time performance requirements. This identifier can be determined based on the task processing delay tolerance and the resource request response timeout threshold. For example, the real-time assurance level can be categorized into three levels: high, medium, and low. If the task processing delay tolerance is short and the resource request response timeout threshold is also short, the real-time assurance level identifier can be set to "high." If the task processing delay tolerance and the resource request response timeout threshold are moderate, the real-time assurance level identifier can be set to "medium." If the task processing delay tolerance and the resource request response timeout threshold are also long, the real-time assurance level identifier can be set to "low." Assuming that the task processing delay tolerance of access device "Device001" is 2 minutes and the resource request response timeout threshold is 3 seconds, its real-time assurance level identifier can be set to "medium." By combining these determined task processing delay tolerance, resource request response timeout threshold, and real-time assurance level identifier, we obtain the load response timeliness characteristics of access device "Device001."

[0045] Step S123: Priority weight allocation processing is performed according to the resource request record in the device operation status log to generate the resource request priority feature, which includes an emergency task trigger identifier, a key device identifier, and a service quality level parameter.

[0046] Taking the device operation status log for access device "Device001" as an example, first determine the emergency task trigger flag. The emergency task trigger flag indicates whether the device has triggered an emergency task. You can determine whether an emergency task exists by analyzing the task type and description in the device operation status log. For example, if the device operation status log records a task as "Emergency Troubleshooting Task," you can set the emergency task trigger flag for that device to "Yes"; otherwise, set it to "No."

[0047] Next, determine the key device identifier. This identifier indicates the device's importance within the power system. This identifier can be determined based on the device's function and role. For example, for devices that perform important monitoring and control tasks, their key device identifier can be set to "key device," while for more common auxiliary devices, their key device identifier can be set to "normal device." For example, if access device "Device001" is an important device used to monitor power system voltage, its key device identifier can be set to "key device."

[0048] Finally, the service quality level parameters are determined. The service quality level parameters represent the device's quality requirements for resource allocation. The service quality level parameters can be determined based on the device's service requirements and real-time assurance level identifier. For example, service quality levels can be categorized into three levels: high, medium, and low. If the device's real-time assurance level identifier is "high" and the service requirements place high demands on resource quality, the service quality level parameters can be set to "high." If the device's real-time assurance level identifier is "medium" and the service requirements place moderate demands on resource quality, the service quality level parameters can be set to "medium." If the device's real-time assurance level identifier is "low" and the service requirements place low demands on resource quality, the service quality level parameters can be set to "low." For example, if the real-time assurance level identifier for access device "Device001" is "medium" and the service requirements place moderate demands on resource quality, the service quality level parameters can be set to "medium." Combining these determined emergency task trigger identifiers, key device identifiers, and service quality level parameters yields the resource request priority characteristics for access device "Device001."

[0049] Step S124: normalizing and splicing the device power consumption fluctuation characteristics, the load response time characteristics, and the resource request priority characteristics to obtain the load characteristic set, and associating and storing them in the global resource status mapping table.

[0050] In this embodiment, the normalization process is to eliminate the differences in dimensions and numerical ranges between different features so that the features can be spliced and compared at a unified scale.

[0051] First, normalize the device power consumption fluctuation characteristics. For connected device "Device001," its power consumption fluctuation characteristics include the rate of change of power consumption per unit time, the duration of peak power consumption, and the frequency of low-power state transitions. Assuming the rate of change of power consumption per unit time ranges from -0.1 to 0.2, it needs to be normalized to the range of 0 to 1. Linear normalization can be used to find the minimum and maximum values of this characteristic across all connected devices, assuming the minimum value is -0.1 and the maximum value is 0.2. For "Device001," whose rate of change of power consumption per unit time is 0.095, the normalized value is calculated as follows: subtract the minimum value from the rate of change of power consumption per unit time, i.e., 0.095 - (-0.1) = 0.195. Then, divide this value by the difference between the maximum and minimum values, i.e., 0.2 - (-0.1) = 0.3. The resulting normalized value is 0.195 ÷ 0.3 ≈ 0.65.

[0052] For peak power consumption duration, assuming the peak power consumption duration of all connected devices ranges from 1 minute to 10 minutes, the peak power consumption duration of Device001 is 5 minutes. Using the same linear normalization method, subtract the minimum value of 1 minute from the peak power consumption duration of this device to obtain 5-1 = 4 minutes. This is then divided by the difference between the maximum and minimum values, 10-1 = 9 minutes. The normalized value is 4 ÷ 9 ≈ 0.44.

[0053] For the low-power state switching frequency, assuming that the low-power state switching frequency of all connected devices ranges from 2 times / hour to 20 times / hour, the low-power state switching frequency of "Device001" is 10 times / hour. Subtract the minimum value of 2 times / hour from the low-power state switching frequency of this device to get 10-2 = 8 times / hour. Then divide this by the difference between the maximum and minimum values (20-2 = 18 times / hour). The normalized value is 8 ÷ 18 ≈ 0.44.

[0054] After the above processing, the power consumption fluctuation characteristics of "Device001" are normalized into a vector containing three normalized values (0.65, 0.44, and 0.44).

[0055] The load response timeliness characteristics are then normalized. These characteristics include task processing delay tolerance, resource request response timeout threshold, and real-time assurance level identifier. For task processing delay tolerance, assume that the task processing delay tolerance of all connected devices ranges from 1 minute to 10 minutes, and that the task processing delay tolerance of "Device001" is 3 minutes. Using a linear normalization method, subtract the minimum value of 1 minute from the task processing delay tolerance of the device to obtain 3-1 = 2 minutes. This value is then divided by the difference between the maximum and minimum values (10-1 = 9 minutes). The normalized value is 2÷9≈0.22.

[0056] Assuming that the resource request response timeout threshold for all access devices ranges from 0.5 seconds to 10 seconds, the resource request response timeout threshold for Device001 is 2 seconds. Subtract the minimum value of 0.5 seconds from the resource request response timeout threshold for this device to get 2 - 0.5 = 1.5 seconds. Then divide this by the difference between the maximum and minimum values (10 - 0.5 = 9.5 seconds). The normalized value is 1.5 ÷ 9.5 ≈ 0.16.

[0057] Since the real-time assurance level identifier is a categorical variable (high, medium, low), one-hot encoding can be used. Assuming "high" is encoded as (1, 0, 0), "medium" is encoded as (0, 1, 0), and "low" is encoded as (0, 0, 1). If the real-time assurance level identifier for "Device001" is "medium," the encoded value is (0, 1, 0).

[0058] The normalized values of the task processing delay tolerance and resource request response timeout threshold are concatenated with the encoding of the real-time assurance level identifier. The load response timeliness feature of "Device001" is normalized into a vector containing five values (0.22, 0.16, 0, 1, 0).

[0059] The resource request priority feature is then normalized. The resource request priority feature includes an emergency task trigger flag, a key device identifier, and a quality of service (QoS) parameter. The emergency task trigger flag is a binary variable (yes, no), with 1 representing "yes" and 0 representing "no." Assuming the emergency task trigger flag for "Device001" is "no," its value is 0.

[0060] For the key device identifier, which is also a categorical variable (key device, ordinary device), one-hot encoding is used. Assuming that "key device" is encoded as (1, 0), "ordinary device" is encoded as (0, 1), and the key device identifier of "Device001" is "key device", it will be encoded as (1, 0).

[0061] For the service quality level parameter, which is also a categorical variable (high, medium, low), one-hot encoding is used. Assuming that "high" is encoded as (1, 0, 0), "medium" is encoded as (0, 1, 0), and "low" is encoded as (0, 0, 1), the service quality level parameter of "Device001" is "medium", then the encoded value is (0, 1, 0).

[0062] By concatenating the value of the emergency task trigger identifier with the key device identifier and the encoding of the service quality level parameter, the resource request priority feature of "Device001" is normalized into a vector containing four values (0, 1, 0, 0, 1, 0).

[0063] After normalizing each feature, the features are concatenated. The normalized vectors for the power consumption fluctuation feature of Device001 (0.65, 0.44, 0.44), the normalized vector for the load response timeliness feature (0.22, 0.16, 0, 1, 0), and the normalized vector for the resource request priority feature (0, 1, 0, 0, 1, 0) are concatenated in sequence. This results in a vector containing twelve values (0.65, 0.44, 0.44, 0.22, 0.16, 0, 1, 0, 0, 1, 0, 0). This vector is the load feature set for Device001.

[0064] Finally, this load feature set is associated and stored in the global resource status mapping table. The global resource status mapping table is a database used to record the resource status and related features of all access devices in the power wireless LAN. When storing, the load feature set is associated with the device using the access device identifier "Device001" as the index. For example, a new record is created in the global resource status mapping table with the primary key "Device001". The load feature set (0.65, 0.44, 0.44, 0.22, 0.16, 0, 1, 0, 0, 1, 0, 0) is stored in the load feature field corresponding to the primary key. In this way, in the subsequent resource scheduling process, the corresponding load feature set can be quickly queried based on the device identifier, providing a basis for resource allocation.

[0065] Step S130: Perform dynamic resource demand prediction processing on the load feature set based on a preset load prediction model to generate a virtualized resource demand prediction result for each access device, wherein the virtualized resource demand prediction result includes computing resource allocation magnitude and storage resource allocation timeliness requirements.

[0066] After obtaining the load characteristics of each access device, a preset load prediction model is used to dynamically predict resource requirements based on these characteristics to determine the future virtualization resources required by each access device. The computing resource allocation level determines the amount of computing resources allocated to the device, while the storage resource allocation timeliness requirement specifies the time requirements for the device to read, write, and back up storage resources. The specific prediction process is as follows:

[0067] Step S131: Call the pre-trained load prediction model to perform time series analysis on the load feature set to generate a short-term resource demand prediction sequence and a long-term resource demand trend distribution; wherein the short-term resource demand prediction sequence includes the computing resource demand peak and storage resource demand fluctuation range within a preset time period in the future; the long-term resource demand trend distribution includes the resource occupancy growth slope, the periodic task superposition impact factor and the probability of triggering a sudden load event.

[0068] For access device "Device001," a pre-trained load prediction model is used to perform time series analysis on its load signature set (0.65, 0.44, 0.44, 0.22, 0.16, 0, 1, 0, 0, 1, 0, 0). The pre-trained load prediction model is trained on a large amount of historical data and can learn the relationship between the load signature set and resource demand.

[0069] When forecasting short-term resource demand, assume the preset short-term time period is one hour into the future. The load forecast model uses the load signature set for Device001, combined with historical data and current operating status, to predict the peak computing resource demand and storage resource demand fluctuation range within the next hour. To predict peak computing resource demand, the model analyzes the device's power consumption fluctuation characteristics, load response timeliness, and resource request priority within the load signature set, taking into account factors such as the device's task execution status, real-time requirements, and resource request priority. For example, if a device's real-time assurance level is marked as "High" and its task processing latency tolerance is low, the model predicts that the device may experience a high peak computing resource demand within the next hour. Assume that the predicted peak computing resource demand for Device001 within the next hour is 80% CPU utilization and 60% memory utilization.

[0070] When predicting the fluctuation range of storage resource demand, the model takes into account the device's business needs and data generation. If the device is a data acquisition device that continuously generates large amounts of data, the model predicts a larger fluctuation range in its storage resource demand. For example, assume that the storage resource demand of Device001 will fluctuate between 10 GB and 20 GB over the next hour.

[0071] When forecasting long-term resource demand trend distribution, the long-term time period is assumed to be one month into the future. The load forecasting model analyzes the periodic task triggering records and resource request history in the load signature set to calculate the resource utilization growth slope, the impact factor of periodic task superposition, and the probability of triggering a sudden load event. The resource utilization growth slope reflects the rate of resource utilization growth of the device over the long term. If, based on historical data analysis, the computing resource utilization of "Device001" is detected to be increasing by 5% per month, the resource utilization growth slope is 5%.

[0072] The periodic task overlay impact factor considers the impact of a device's periodic tasks on resource requirements. If Device001 has multiple periodic tasks that execute simultaneously during certain time periods, the periodic task overlay impact factor will be large. Assume that, after analysis, the periodic task overlay impact factor for Device001 is 1.2, indicating that the overlay of periodic tasks will increase resource requirements by 20%.

[0073] The probability of a sudden load event triggering is the likelihood that a device will experience a sudden load event in the future. By analyzing anomalies in historical data and the device's operating environment, we predict that the probability of a sudden load event triggering for Device001 within the next month is 10%.

[0074] By combining these predicted short-term resource demand forecast series (the computing resource demand peak is 80% CPU utilization and 60% memory utilization, and the storage resource demand fluctuates between 10GB and 20GB) and the long-term resource demand trend distribution (the resource occupancy growth slope is 5%, the periodic task superposition impact factor is 1.2, and the probability of triggering a sudden load event is 10%), we can obtain a part of the resource demand forecast results for "Device001".

[0075] Step S132: Perform resource allocation level calculation based on the short-term resource demand forecast sequence and the long-term resource demand trend distribution to generate the computing resource allocation level, wherein the computing resource allocation level includes the CPU core number requirement, memory capacity requirement and GPU computing power allocation ratio.

[0076] The computing resource allocation level is calculated based on the short-term resource demand forecast sequence and long-term resource demand trend distribution for "Device001." First, the required number of CPU cores is calculated. Considering a peak computing resource demand of 80% CPU utilization within the next hour, a long-term resource usage growth slope of 5%, and a periodic task overlay impact factor of 1.2. Assume that the device currently uses 4 CPU cores, and that the utilization of each CPU core is evenly distributed under normal circumstances. Since the peak computing resource demand is 80%, a certain number of CPU cores must be added to ensure normal operation of the device under peak load. Based on experience and historical data, performance bottlenecks may occur when CPU utilization exceeds 70%. Therefore, to cope with future growth and the impact of periodic task overlays, the number of CPU cores needs to be appropriately increased.

[0077] First, calculate the peak CPU utilization after accounting for growth and stacking effects: 80% × (1 + 5%) × 1.2 = 100.8%. This means that the current 4 CPU cores may not meet demand. To keep CPU utilization within a reasonable range, assuming the target CPU utilization is 70%, the required number of CPU cores is 4 × 100.8% ÷ 70% ≈ 5.76, rounded up to 6 CPU cores.

[0078] Next, calculate the memory capacity requirement. Consider the fluctuation range of storage resource demand within the next hour, which will be between 10GB and 20GB, as well as the impact of long-term resource usage growth and periodic task superposition. Assuming that the current device has a memory capacity of 16GB, due to the large fluctuation range of storage resource demand and the impact of growth and superposition, a certain amount of memory capacity needs to be increased. Based on the upper limit of storage resource demand of 20GB and the coefficient of 1.2×(1+5%)=1.26 after considering the impact of growth and superposition, the required memory capacity can be calculated as 20GB×1.26=25.2GB, rounded up to 32GB.

[0079] Finally, calculate the GPU computing power allocation ratio. If the business needs of "Device001" involve some graphics processing or deep learning tasks, a certain amount of GPU computing power will be allocated. Based on the device's load characteristics and resource demand forecast results, assuming that analysis shows that 30% of "Device001"'s workload can be accelerated by the GPU, then the GPU computing power allocation ratio is 30%.

[0080] Combining the calculated CPU core requirement of 6, memory capacity requirement of 32GB, and GPU computing power allocation ratio of 30%, we get the computing resource allocation level of "Device001".

[0081] Step S133: Perform storage resource timeliness matching processing based on the resource request priority characteristics and the load response timeliness characteristics to generate the storage resource allocation timeliness requirements, which include the data read and write delay upper limit, storage bandwidth guarantee threshold and redundant backup response time.

[0082] Storage resource timeliness matching is performed based on the resource request priority and load response timeliness characteristics of Device001. First, the upper limit for data read and write latency is determined. The service quality level parameter in the resource request priority characteristic of Device001 is "Medium," and the real-time assurance level in the load response timeliness characteristic is "Medium." This indicates that the device has moderate real-time requirements for data read and write. Based on experience and historical data, for devices with a "Medium" service quality level and a "Medium" real-time assurance level, the upper limit for data read and write latency can be set to 100 milliseconds.

[0083] Next, determine the storage bandwidth guarantee threshold. Considering that the storage resource demand of "Device001" will fluctuate between 10GB and 20GB in the next hour, as well as its resource request priority and load response time characteristics. In order to ensure that the device can complete data read and write operations within the specified time, a certain amount of storage bandwidth guarantee is required. Assuming that the upper limit of storage resource demand is 20GB and the time range is 1 hour (3600 seconds), and taking into account certain redundancy and fluctuations, the required storage bandwidth is calculated to be 20GB ÷ 3600 seconds × 1.2 ≈ 6.67MB / s, rounded up to 7MB / s. This is the storage bandwidth guarantee threshold.

[0084] Finally, determine the redundant backup response time. Because Device001 is a critical device, its data requires redundant backup to prevent data loss. Based on its resource request priority and load response time characteristics, and considering its "medium" real-time assurance level, the redundant backup response time can be set to 5 minutes. This means that after a device data change, redundant backup of the data must be completed within 5 minutes.

[0085] By combining the determined data read and write latency upper limit of 100 milliseconds, the storage bandwidth guarantee threshold of 7MB / s, and the redundant backup response time of 5 minutes, we can obtain the storage resource allocation timeliness requirement for "Device001".

[0086] Step S134: jointly encode the computing resource allocation magnitude and the storage resource allocation timeliness requirement to generate the virtualization resource demand prediction result, and write the virtualization resource demand prediction result into the global resource status mapping table.

[0087] The compute resource allocation requirements for "Device001" (required CPU core count of 6, memory capacity of 32GB, and GPU computing power allocation ratio of 30%) and storage resource allocation timeliness requirements (data read and write latency limit of 100 milliseconds, storage bandwidth guaranteed threshold of 7MB / s, and redundant backup response time of 5 minutes) are jointly encoded. A fixed encoding format can be used to convert this information into a unified string or vector. For example, the compute resource allocation requirements and storage resource allocation timeliness requirements can be arranged in a certain order and separated by a delimiter to form an encoded string: "CPU core count: 6, memory capacity: 32GB, GPU computing power allocation ratio: 30%, data read and write latency limit: 100 milliseconds, storage bandwidth guaranteed threshold: 7MB / s, redundant backup response time: 5 minutes."

[0088] This encoded string is used as the virtualization resource demand forecast for "Device001" and is written into the global resource status mapping table. In the global resource status mapping table, the device identifier for "Device001" is used as an index to find the corresponding entry. The global resource status mapping table is typically stored in a database, and the database management system provides a series of operation interfaces to implement data writing.

[0089] First, establish a connection to the database. This requires using the connection tools provided by the database management system. For example, for the relational database MySQL, use the corresponding MySQL driver to create a database connection object. Assume that the database server address is "192.168.1.100," the port number is 3306, the database name is "power_wlan_resource," the username is "admin," and the password is "password." Use the connection function provided by the driver to pass these parameters to establish a connection to the database.

[0090] Next, construct an SQL statement to update the records in the global resource status mapping table. Since the virtualization resource demand prediction results need to be written to the record corresponding to "Device001," an update statement is required. Assume that the global resource status mapping table is named "device_resource_status," which contains the fields "device_id" for storing device identifiers and "virtual_resource_prediction" for storing virtualization resource demand prediction results. The constructed SQL update statement is: "UPDATEdevice_resource_statusSETvirtual_resource_prediction="CPU cores: 6, memory capacity: 32GB, GPU computing power allocation ratio: 30%, data read and write latency limit: 100 milliseconds, storage bandwidth guarantee threshold: 7MB / s, redundant backup response time: 5 minutes" WHERE device_id = "Device001"."

[0091] The constructed SQL statement is then sent to the database for execution. Using the previously established database connection object, the SQL statement execution method is called, passing the update statement as a parameter. The database management system parses and executes the statement, searches the "device_resource_status" table for a record with "device_id" equal to "Device001," and updates the value of the "virtual_resource_prediction" field with the encoded virtualization resource demand forecast.

[0092] After executing the SQL statement, you need to check the execution result. The database management system will return an execution status code or related information to determine whether the update operation was successful. If the execution status code indicates success, the virtualization resource demand forecast results for "Device001" have been successfully written to the global resource status mapping table. If an error occurs during execution, the database management system will return the corresponding error information, such as SQL syntax error, table non-existence, insufficient permissions, etc. Based on this error information, you can take appropriate action, such as checking the correctness of the SQL statement, confirming the correctness of the table structure, and checking user permissions.

[0093] Step S140: Generate a virtualization resource scheduling strategy based on the virtualization resource demand prediction result, where the virtualization resource scheduling strategy includes a resource allocation topology of edge computing nodes and a resource redundancy backup instruction of a central cloud node.

[0094] After obtaining the virtualization resource demand forecast results for each access device, a virtualization resource scheduling strategy needs to be generated based on these results to rationally allocate and manage virtualized computing resources in the power wireless LAN. Edge computing nodes are close to access devices and can provide low-latency computing services, while central cloud nodes have powerful computing and storage capabilities and are used for resource redundancy and global resource coordination. The specific generation process is as follows:

[0095] Step S141: Analyze the computing resource allocation level in the virtualization resource demand prediction result to generate a resource allocation topology of the edge computing node, wherein the resource allocation topology includes the computing resource allocation ratio of the edge node, the cross-node load balancing path, and the resource reservation buffer capacity.

[0096] Taking the virtualization resource demand forecast results for "Device001" as an example, we analyze the computing resource allocation levels (required CPU core count of 6, memory capacity requirement of 32GB, and GPU computing power allocation ratio of 30%) to generate the resource allocation topology of the edge computing node. Assume that there are three edge computing nodes in the power wireless LAN: "EdgeNode001," "EdgeNode002," and "EdgeNode003." Each edge computing node has a different total amount of computing resources. "EdgeNode001" has 16 CPU cores, 64GB of memory, and a certain amount of GPU computing power. "EdgeNode002" has 8 CPU cores, 32GB of memory, and a certain amount of GPU computing power. "EdgeNode003" has 12 CPU cores, 48GB of memory, and a certain amount of GPU computing power.

[0097] First, determine the computing resource allocation ratio for edge nodes. Based on the computing resource requirements of Device001 and the total resource allocation of each edge computing node, the calculation is performed using the principle of balanced resource allocation. Regarding the number of CPU cores, Device001 requires 6 CPU cores, and the total number of CPU cores for the three edge computing nodes is 16 + 8 + 12 = 36. The number of CPU cores allocated to EdgeNode001 is 6 × (16 ÷ 36) ≈ 2.67, rounded up to 3; the number of CPU cores allocated to EdgeNode002 is 6 × (8 ÷ 36) ≈ 1.33, rounded up to 2; and the number of CPU cores allocated to EdgeNode003 is 6 - 3 - 2 = 1.

[0098] Device001 requires 32GB of memory, and the total memory of the three edge computing nodes is 64 + 32 + 48 = 144GB. The memory capacity allocated to EdgeNode001 is 32 × (64 ÷ 144) ≈ 14.22GB, rounded up to 15GB. The memory capacity allocated to EdgeNode002 is 32 × (32 ÷ 144) ≈ 7.11GB, rounded up to 8GB. The memory capacity allocated to EdgeNode003 is 32 - 15 - 8 = 9GB.

[0099] For GPU computing power, the GPU computing power allocation ratio for "Device001" is 30%. Assuming that the GPU computing power of the three edge computing nodes can be allocated proportionally, the above calculation method is used to allocate the GPU computing power based on the total GPU computing power of each edge computing node. After calculation, the GPU computing power ratio allocated to "Device001" by each edge computing node is obtained. These CPU core counts, memory capacity, and GPU computing power distribution are summarized to form the computing resource allocation ratio of the edge nodes.

[0100] Next, determine a cross-node load balancing path. Taking into account factors such as network latency and resource utilization, a load balancing path between different edge computing nodes must be determined for Device001. By monitoring and analyzing the network connectivity between each edge computing node, network latency data can be obtained. Assume that the network latency between Device001 and EdgeNode001 is 10 milliseconds, the latency between Device001 and EdgeNode002 is 15 milliseconds, and the latency between Device001 and EdgeNode003 is 12 milliseconds. To achieve load balancing and reduce latency, when computing tasks for Device001 can be split, some tasks are preferentially assigned to EdgeNode001, which has lower network latency. Furthermore, the task allocation ratio is dynamically adjusted based on the resource utilization of each edge computing node. For example, when the resource utilization of EdgeNode001 reaches 80%, some tasks are transferred to EdgeNode003. This creates a cross-node load balancing path for Device001 between edge computing nodes.

[0101] Finally, determine the resource reservation buffer capacity. To cope with sudden resource demands, each edge computing node needs to reserve a certain resource buffer. The resource reservation buffer capacity is calculated based on the long-term resource demand trend of Device001 (resource usage growth slope of 5%, periodic task superposition impact factor of 1.2, and probability of triggering a sudden load event of 10%), as well as the total resource usage and current usage of the edge computing node. Taking EdgeNode001 as an example, its current CPU core utilization is 60% and its memory utilization is 50%. Considering the growing resource demand of Device001 and the possibility of sudden load events, the number of CPU cores reserved for Device001 is 16 × (1-60%) × 10% × 1.2 × (1+5%), which is approximately 0.8, rounded up to 1. The reserved memory capacity is 64 × (1-50%) × 10% × 1.2 × (1+5%), which is approximately 4GB. The resources reserved for Device001 are used as part of the resource reservation buffer capacity for EdgeNode001. Similarly, the resource reservation buffer capacities for other edge computing nodes are calculated. Combining the edge node's computing resource allocation ratio, cross-node load balancing paths, and resource reservation buffer capacities yields the edge computing node resource allocation topology for Device001.

[0102] Step S142: Generate a resource redundancy backup instruction for the central cloud node according to the storage resource allocation timeliness requirement, wherein the resource redundancy backup instruction includes a data backup cycle parameter, an off-site disaster recovery node identifier, and a backup data verification strategy.

[0103] Generate resource redundancy backup instructions for the central cloud node based on the storage resource allocation time requirements of "Device001" (data read and write delay upper limit of 100 milliseconds, storage bandwidth guarantee threshold of 7MB / s and redundant backup response time of 5 minutes).

[0104] First, determine the data backup cycle parameters. Considering that the storage resource requirements for Device001 fluctuate between 10GB and 20GB, and the redundant backup response time requirement is 5 minutes, to ensure that data backups are completed within the specified time, the data backup cycle needs to be calculated based on the guaranteed storage bandwidth threshold of 7MB / s. Assuming a 20GB storage resource requirement, 20GB is converted to bytes as 20 × 1024 × 1024 × 1024 bytes. The storage bandwidth is 7MB / s, or 7 × 1024 × 1024 bytes / second. Therefore, the time required to back up 20GB of data is (20 × 1024 × 1024 × 1024) ÷ (7 × 1024 × 1024) ≈ 2994 seconds, or approximately 50 minutes. However, considering the redundant backup response time is 5 minutes, the data backup cycle needs to be shorter to ensure that important data backups are completed within 5 minutes. After comprehensive consideration, the data backup cycle parameter is set to 3 minutes, that is, the data of "Device001" is backed up every 3 minutes.

[0105] Next, determine the remote disaster recovery node identifier. The central cloud node typically has multiple remote disaster recovery nodes for storing backup data to prevent single points of failure. Based on factors such as network connection stability, storage capacity, and geographic location, select an appropriate node from the pre-set remote disaster recovery node list. Assume that the pre-set remote disaster recovery node list includes "DisasterRecoveryNode001," "DisasterRecoveryNode002," and "DisasterRecoveryNode003." Real-time monitoring of the network connection status of these nodes reveals that "DisasterRecoveryNode001" has the lowest network latency with the central cloud node and sufficient storage capacity to store the data for "Device001." Therefore, "DisasterRecoveryNode001" is selected as the remote disaster recovery node for "Device001," and its identifier is "DisasterRecoveryNode001."

[0106] Finally, determine the backup data verification strategy. To ensure the integrity and accuracy of the backup data, an appropriate backup data verification strategy is necessary. A hash verification method, such as the MD5 or SHA-256 hash algorithm, can be used. During each data backup, the original data is hashed to obtain a hash value. After the data is transferred to the offsite disaster recovery node, the backup data is hashed again on the disaster recovery node to obtain a new hash value. These two hash values are compared. If they match, the backup data is complete and correct. If they differ, an error may have occurred during transmission or storage, requiring a new backup. Furthermore, to improve verification accuracy and efficiency, a block-by-block verification method can be used. This divides the data into several small blocks and performs a hash calculation and comparison on each block separately. Combining the 3-minute data backup cycle parameter, the offsite disaster recovery node identifier "DisasterRecoveryNode001," and the backup data verification strategy (using the SHA-256 hash algorithm for block-by-block verification) yields the resource redundancy backup instructions for "Device001" on the central cloud node.

[0107] Step S143: constructing a resource scheduling instruction set based on the resource allocation topology and the resource redundancy backup instruction, wherein the resource scheduling instruction set includes edge node resource allocation instructions, central cloud backup triggering instructions, and global load balancing coordination instructions.

[0108] Based on the previously generated resource allocation topology of the edge computing node for "Device001" and the resource redundancy backup instructions of the central cloud node for "Device001", a resource scheduling instruction set is constructed.

[0109] First, generate an edge node resource allocation directive. Based on the edge node's resource allocation ratio ("EdgeNode001" is allocated 3 CPU cores, 15GB of memory, and a corresponding GPU computing power ratio; "EdgeNode002" is allocated 2 CPU cores, 8GB of memory, and a corresponding GPU computing power ratio; "EdgeNode003" is allocated 1 CPU core, 9GB of memory, and a corresponding GPU computing power ratio), as well as the cross-node load balancing path and resource reservation buffer capacity, construct the edge node resource allocation directive. The directive includes the identifier of each edge computing node, the specific amount of resources allocated to "Device001" and resource reservation information, as well as the load balancing rules and conditions. For example, the instruction content can be: "EdgeNode001: 3 CPU cores are allocated, 15 GB of memory capacity is allocated, GPU computing power allocation ratio [specific ratio value], resource reservation buffer: 1 CPU core, 4 GB of memory; when resource utilization reaches 80%, some tasks will be transferred to EdgeNode003; EdgeNode002: 2 CPU cores are allocated, 8 GB of memory capacity is allocated, GPU computing power allocation ratio [specific ratio value], resource reservation buffer: [specific reservation amount]; load balancing rule [specific rule]; EdgeNode003: 1 CPU core is allocated, 9 GB of memory capacity is allocated, GPU computing power allocation ratio [specific ratio value], resource reservation buffer: [specific reservation amount]; load balancing rule [specific rule]".

[0110] Next, a central cloud backup trigger instruction is generated. Based on the 3-minute data backup cycle parameter in the resource redundancy backup instruction, the off-site disaster recovery node identifier "DisasterRecoveryNode001," and the backup data verification strategy (using the SHA-256 hash algorithm for block verification), the central cloud backup trigger instruction is constructed. The instruction content is: "Back up the data of Device001 every 3 minutes to the off-site disaster recovery node DisasterRecoveryNode001, using the SHA-256 hash algorithm for block verification."

[0111] Finally, global load balancing coordination instructions are generated. Considering the potential for multiple access devices within a power wireless LAN, global load balancing coordination is required for the entire network. Global load balancing coordination instructions are formulated based on the predicted virtualized resource requirements of each access device and the resource usage of edge computing nodes. For example, if the resource utilization of an edge computing node is excessively high, tasks from some access devices can be migrated to other edge computing nodes with lower resource utilization. Alternatively, resource allocation can be dynamically adjusted based on the real-time requirements and resource priority of different access devices. Instructions might read: "Real-time monitoring of resource utilization of each edge computing node. When the CPU utilization of an edge computing node exceeds 80% or the memory utilization exceeds 70%, a load migration mechanism is initiated to migrate tasks from some low-priority access devices to other edge computing nodes. Resource requests from high-priority devices are prioritized based on the real-time assurance level and resource request priority of the access devices."

[0112] By combining the edge node resource allocation instructions, the central cloud backup trigger instructions, and the global load balancing coordination instructions, we get the resource scheduling instruction set for "Device001".

[0113] Step S144: Encapsulate the resource scheduling instruction set into the virtualized resource scheduling policy, and associate and store it in the global resource status mapping table.

[0114] The resource scheduling instruction set generated for "Device001" is encapsulated into a virtualized resource scheduling strategy. The resource scheduling instruction set can be encapsulated in formats such as JSON or XML. Taking JSON format as an example, the edge node resource allocation instructions, central cloud backup trigger instructions and global load balancing coordination instructions are converted into JSON objects. This JSON object is used as the virtualized resource scheduling strategy for "Device001" and is associated and stored in the global resource status mapping table. Similarly, through the database connection, an SQL update statement is constructed to update the record corresponding to "Device001" in the global resource status mapping table. Assuming that a new field "reso urce_scheduling_strategy" is added to the global resource status mapping table to store the virtualized resource scheduling strategy, the constructed SQL update statement is: "UPDATE device_resource_status SETresource_scheduling_strategy="'{"edge_node_allocation_instructions":"EdgeNode001: Allocate 3 CPU cores, 15GB of memory, GPU computing power allocation ratio [specific ratio value], resource reservation buffer: 1 CPU core, 4GB of memory; when resource utilization reaches 80%, transfer some tasks to EdgeNode003; EdgeNode002: Allocate 2 CPU cores, 8GB of memory, GPU computing power allocation ratio [specific ratio value], resource reservation buffer: [specific reservation amount]; load balancing rule [specific rule]; EdgeNode003: Allocate 1 CPU core, 9GB of memory, GPU computing power allocation ratio [specific ratio value], resource reservation buffer: [specific reservation amount]; load balancing rule [specific rule]","cloud_backup_trigger_in"} "instructions":"Back up the data of Device001 every 3 minutes to the remote disaster recovery node DisasterRecoveryNode001, using the SHA-256 hash algorithm for block verification.","global_load_balancing_instructions":"Monitor the resource utilization of each edge computing node in real time. When the CPU utilization of an edge computing node exceeds 80% or the memory utilization exceeds 70%, initiate the load migration mechanism to migrate tasks of some low-priority access devices to other edge computing nodes. Prioritize the resource needs of high-priority devices based on the real-time assurance level and resource request priority of the access device."}'WHEREdevice_id="Device001"".

[0115] After constructing the above SQL update statement, it is sent to the database for execution. Using the previously established database connection object, the SQL statement execution method is called, passing the update statement as a parameter. Upon receiving the statement, the database management system performs a detailed analysis, first checking for syntax correctness, including the use of keywords, matching quotation marks, and the validity of field and table names. If the syntax check passes, the database management system locates the record in the "device_resource_status" table with a "device_id" of "Device001."

[0116] After finding the corresponding record, the database management system assigns the virtualization resource scheduling strategy JSON string specified in the update statement to the "resource_scheduling_strategy" field. During the assignment process, the database checks the data type and length to ensure that the JSON string conforms to the field definition. If the field is defined as a string type with a length limit, and the JSON string exceeds this limit, the database returns an error message indicating that the data length exceeds the limit.

[0117] After the update operation completes, the database management system returns an execution result. If the update is successful, it returns a status code indicating the success of the operation and the number of updated records. For example, the returned status code might be 200 (indicating success in some database systems) and the number of updated records might be 1, indicating that the record corresponding to "Device001" has been successfully updated and its virtualization resource scheduling policy has been associated and stored in the global resource status mapping table.

[0118] If an error occurs during execution, the database management system will return detailed error information. This error may include SQL syntax errors, table or field non-existence, data type mismatch, insufficient permissions, and so on. Different error types require different handling measures. For example, if it's an SQL syntax error, you need to check the update statement and correct the syntax error. If the table or field does not exist, you need to confirm that the database table structure is correct, and you may need to create the corresponding table or field. If it's a data type mismatch, you need to adjust the data format or field definition. If it's due to insufficient permissions, you need to check the user's permission settings to ensure that the user has permission to update the table.

[0119] Step S150: dynamically adjusting the virtualized computing resources of the power wireless local area network based on the virtualized resource scheduling strategy, triggering a resource reallocation operation and updating a global resource status mapping table.

[0120] After generating and storing the virtualized resource scheduling policy, it is necessary to dynamically adjust the virtualized computing resources of the power wireless LAN based on the policy to meet the resource requirements of the access devices, improve resource utilization and system stability. The specific operation process is as follows:

[0121] Step S151: Send the edge node resource allocation instruction to the target edge computing node, trigger the target edge computing node to dynamically partition the local resource pool according to the computing resource allocation ratio, and generate updated local resource pool configuration parameters.

[0122] For example, the edge node resource allocation instruction for Device001 specifies the amount of computing resources to be allocated to the three target edge computing nodes: EdgeNode001, EdgeNode002, and EdgeNode003. The central scheduling node sends the edge node resource allocation instruction to these three target edge computing nodes via a network connection. The target edge computing nodes then perform a series of operations based on the instruction:

[0123] Step S1511: parse the computing resource allocation ratio in the edge node resource allocation instruction to determine the number of CPU cores allocated, memory allocation capacity, and GPU computing power allocation ratio of the target edge computing node.

[0124] Taking EdgeNode001 as an example, upon receiving the edge node resource allocation instruction, it parses the computing resource allocation ratio for Device001. The instruction specifies a specific number of CPU cores, memory capacity, and a corresponding GPU computing power ratio to be allocated to Device001. By precisely analyzing the instruction content, EdgeNode001 determines that Device001 will be allocated 3 CPU cores, 15GB of memory, and a specific GPU computing power ratio (assuming this ratio is 20% calculated through complex resource evaluation and strategy).

[0125] Step S1512: Perform real-time resource occupancy detection on the local resource pool of the target edge computing node to generate current resource occupancy status parameters, which include the amount of allocated resources, the amount of idle resources, and the degree of resource fragmentation.

[0126] "EdgeNode001" will use the system monitoring tools or special resource management modules provided by the operating system to perform real-time resource occupancy detection on the local resource pool. For the CPU core, it detects that out of a total of 16 CPU cores, 10 have been allocated to other tasks, so the number of idle CPU cores is 6. At the same time, through the analysis of the CPU core allocation, it was detected that there is a certain degree of resource fragmentation. For example, some CPU cores are scattered and allocated to multiple small tasks, resulting in a certain impact on the overall resource utilization efficiency. The degree of resource fragmentation is evaluated to be 20% (derived through the fragmentation evaluation algorithm of the existing technology, which comprehensively considers factors such as the allocation granularity of the CPU core and the relevance of tasks). For memory, out of a total of 64GB of memory, 32GB has been allocated and 32GB is idle. The memory allocation is also analyzed, and the degree of memory resource fragmentation is 15% (based on the evaluation of factors such as the allocation size and continuity of the memory block). For GPU computing power, monitoring shows that 30% of the computing power is used, and the remaining 70% is idle. The GPU resource fragmentation level is relatively low, at 5% (based on the allocation of GPU computing tasks and the usage of video memory). This information on allocated resources, idle resources, and resource fragmentation is integrated to generate the current resource usage status parameters of "EdgeNode001".

[0127] Step S1513: performing resource reservation space calculation processing according to the computing resource allocation ratio and the current resource occupancy state parameter to generate a resource reservation buffer capacity and a resource recycling trigger threshold.

[0128] Resource reservation is calculated based on the computing resources allocated to Device001 (3 CPU cores, 15GB of memory, and 20% of GPU computing power) and the current resource utilization parameters of EdgeNode001. Regarding CPU cores, to account for unexpected tasks or fluctuations in resource demand, Device001 reserves an additional 1 CPU core as a resource reserve buffer in addition to the 3 CPU cores allocated. Regarding memory, in addition to the 15GB allocated to Device001, 4GB of memory is reserved as a buffer. Regarding GPU computing power, 5% of computing power is reserved in addition to the 20% allocated. This results in a resource reserve buffer capacity of 1 CPU core, 4GB of memory, and 5% of GPU computing power. Furthermore, to ensure efficient resource utilization and stable system operation, resource reclamation trigger thresholds are set. When CPU core utilization exceeds 90%, memory utilization exceeds 85%, or GPU computing power utilization exceeds 95%, resource reclamation is triggered to free up some resources for other tasks.

[0129] Step S1514: Dynamically partition the local resource pool of the target edge computing node based on the resource reservation buffer capacity to generate updated local resource pool configuration parameters, wherein the updated local resource pool configuration parameters include a newly allocated resource block address, a resource reservation area identifier, and a resource recovery strategy.

[0130] EdgeNode001 dynamically partitions its local resource pool based on the determined resource reservation buffer capacity. It allocates three CPU cores and 15GB of memory into a dedicated resource block for Device001 and assigns a unique address to this resource block, such as "ResourceBlock001." It also marks the resource reservation with the identifier "ReservedBlock001," which includes one CPU core, 4GB of memory, and 5% of the GPU computing power. A resource reclamation policy is established. When resource usage on Device001 falls below a certain percentage (e.g., CPU utilization below 30%, memory utilization below 20%, or GPU computing power utilization below 10%) or when system resources are limited (reaching the resource reclamation trigger threshold), some resources are reclaimed and reallocated. The newly allocated resource block address, resource reservation identifier, and resource reclamation policy are integrated to generate updated local resource pool configuration parameters.

[0131] Step S1515: returning the updated local resource pool configuration parameters to the central scheduling node, and triggering a synchronous update operation of the global resource status mapping table.

[0132] "EdgeNode001" sends the updated local resource pool configuration parameters back to the central scheduling node through the network. After receiving these parameters, the central scheduling node immediately triggers the synchronous update operation of the global resource status mapping table. The central scheduling node will construct an SQL update statement to accurately associate the updated local resource pool configuration parameters of "EdgeNode001" with the corresponding records of "Device001" and "EdgeNode001" in the global resource status mapping table. Similarly, "EdgeNode002" and "EdgeNode003" will also operate according to the above steps S1511-S1515, respectively generate their own updated local resource pool configuration parameters, and return them to the central scheduling node to update the global resource status mapping table.

[0133] Step S152: Send the central cloud backup trigger instruction to the central cloud node, triggering the central cloud node to perform redundant backup processing on the target data according to the backup data verification strategy, and generate a backup completion confirmation signal and a disaster recovery node status identifier.

[0134] The central scheduling node sends a central cloud backup trigger instruction for "Device001" to the central cloud node. After receiving the instruction, the central cloud node will perform redundant backup processing on the target data according to the following detailed steps:

[0135] Step S1521: parse the backup data verification strategy in the central cloud backup trigger instruction to determine the verification algorithm type, block backup size and disaster recovery node selection priority of the target data.

[0136] After receiving the instruction, the central cloud node analyzes the backup data verification policy. By analyzing the instruction content, it determines that the target data will be verified using the SHA-256 hash algorithm and that the block backup size is set to 1GB (this size is determined based on factors such as data transmission efficiency, storage device performance, and network bandwidth). It also specifies the priority for disaster recovery node selection. In this case, the off-site disaster recovery node "DisasterRecoveryNode001" is prioritized for data backup.

[0137] Step S1522: Filtering a target disaster recovery node from a preset disaster recovery node list according to the disaster recovery node selection priority, and sending a backup ready instruction to the target disaster recovery node.

[0138] The central cloud node selects the target disaster recovery node, DisasterRecoveryNode001, from the preset disaster recovery node list based on the determined disaster recovery node selection priority. The central cloud node then sends a backup readiness instruction to DisasterRecoveryNode001 over the network, informing it that it is about to perform a data backup operation on Device001 and requiring it to prepare to receive data.

[0139] Step S1523: receiving a storage space allocation confirmation signal returned by the target disaster recovery node, performing block processing on the target data based on the block backup size, and generating a plurality of data blocks and corresponding block check codes.

[0140] After receiving the backup readiness instruction, "DisasterRecoveryNode001" checks its own storage space and status. If there is sufficient storage space and the status is normal, it can return a storage space allocation confirmation signal to the central cloud node. After receiving this signal, the central cloud node divides the target data of "Device001" into blocks according to the 1GB block backup size. Assuming that the total target data of "Device001" is 15GB, it will be divided into 15 data blocks. For each data block, a simple sum check algorithm is used to generate the corresponding block check code, which is used to initially check the data integrity during the transmission process.

[0141] Step S1524: performing hash calculation processing on each data block using the verification algorithm type to generate a block hash value and compare and verify it with the block verification code to generate a data integrity verification result.

[0142] The central cloud node uses the SHA-256 hash algorithm to hash each data block. Each data block is used as input, and the algorithm generates a corresponding block hash value. The block hash value is then compared with the previously generated block checksum for verification. If the two match, the data block is considered intact before transmission. If they do not match, the data block may contain an error, and the data block is marked as potentially corrupted, generating a corresponding data integrity verification result.

[0143] Step S1525: When the data integrity verification result is passed, the multiple data blocks are transmitted in parallel to the target disaster recovery node, and a backup completion confirmation signal and a disaster recovery node status identifier returned by the target disaster recovery node are received.

[0144] When all data blocks pass the data integrity verification, the central cloud node transmits multiple data blocks in parallel via a high-speed network to the target disaster recovery node, DisasterRecoveryNode001. During the transmission process, a reliable transmission protocol is used to ensure accurate data transmission. After receiving the data blocks, DisasterRecoveryNode001 performs another verification, including recalculating the block hash value and block checksum, and comparing them with the values sent by the central cloud node. If the verification passes, DisasterRecoveryNode001 returns a backup completion confirmation signal and the disaster recovery node status indicator to the central cloud node. The disaster recovery node status indicator can indicate the current status of the disaster recovery node, such as "normal," "busy," or "failed." In this example, the returned disaster recovery node status indicator is "normal."

[0145] Step S153: receiving the updated local resource pool configuration parameters and the backup completion confirmation signal, performing real-time updating processing on the global resource status mapping table of the power wireless local area network, and generating an updated global resource status mapping table.

[0146] The central scheduling node receives the updated local resource pool configuration parameters from the target edge computing node and the backup completion confirmation signal and disaster recovery node status identifier from the central cloud node.

[0147] The central scheduling node associates the updated local resource pool configuration parameters with the corresponding records in the global resource status mapping table. For example, for EdgeNode001, the central scheduling node accurately updates the records corresponding to Device001 and EdgeNode001 with the newly allocated resource block address "ResourceBlock001," the reserved resource block identifier "ReservedBlock001," and the resource reclamation policy. This information is written to the corresponding fields in the global resource status mapping table using a constructed SQL update statement, ensuring data consistency and accuracy.

[0148] The central scheduling node updates the backup completion confirmation signal and the DR node status indicator into the backup-related record for "Device001" in the global resource status mapping table. If the backup completion confirmation signal indicates a successful backup and the DR node status indicator is "Normal," the backup status is updated to "Completed" and the DR node status information is recorded. Similarly, SQL update statements are used to accurately update this backup-related information to the corresponding fields in the global resource status mapping table.

[0149] When updating the global resource status mapping table, the central scheduling node rechecks the data for consistency and integrity. This includes checking whether the newly allocated resource amounts are consistent with the previous resource allocation instructions and whether the backup information is accurately recorded. For example, it verifies whether resource information such as the number of CPU cores and memory capacity allocated to "Device001" matches the edge node resource allocation instructions, and whether backup information such as the backup completion time and disaster recovery node status is complete and accurate. If data inconsistencies or errors are detected, appropriate error handling is performed, such as retrieving data, checking network connections, or confirming communication with relevant nodes.

[0150] After checking for data consistency and integrity, the central dispatch node executes a series of previously constructed SQL update statements, accurately writing the updated local resource pool configuration parameters, backup completion confirmation, and disaster recovery node status indicators into the corresponding fields. Upon completion of these operations, an updated global resource status mapping table is generated, reflecting the latest resource status and backup status of each node in the power wireless LAN.

[0151] Step S154: performing cross-node load migration processing on access devices for which resource allocation has not been completed according to the global load balancing coordination instruction, and generating a load migration log and a resource allocation abnormality alarm event.

[0152] The central scheduling node obtains a list of access devices with unallocated resources from the global resource status mapping table. It then performs cross-node load migration on these devices in the following steps:

[0153] Step S1541: Obtain a list of access devices for which resource allocation has not been completed from the global resource status mapping table, wherein the list of access devices includes device identifiers, types of unmet resource requirements, and remaining waiting time.

[0154] The central scheduling node extracts a list of access devices with unallocated resources from the global resource status mapping table. This list contains information such as device identifiers, resource requirement unmet type, and remaining wait time. For example, Device 002 is included in the list. Its resource requirement unmet type is insufficient CPU cores, and its remaining wait time is 5 minutes.

[0155] Step S1542: Filtering a set of available resource nodes from other edge computing nodes according to the type of unmet resource demand, where the set of available resource nodes includes a node identifier, an available resource amount, and a network transmission delay parameter.

[0156] The set of available resource nodes is filtered from other edge computing nodes based on the type of unmet resource requirements. For the CPU core count requirement for Device002, the central scheduling node checks the resource usage of each edge computing node. Assuming EdgeNode004 has four idle CPU cores and EdgeNode005 has two idle CPU cores, these two nodes are considered as the set of available resource nodes, which includes node identifiers (EdgeNode004 and EdgeNode005), available resource amounts (four and two CPU cores), and network transmission delay parameters (assuming the network transmission delay between EdgeNode004 and Device002 is 12 milliseconds, and the network transmission delay between EdgeNode005 and Device002 is 15 milliseconds).

[0157] Step S1543: performing migration path optimization processing based on the network transmission delay parameter and the available resource amount to generate an optimal migration path and an estimated migration time.

[0158] Migration paths are optimized based on network transmission delay parameters and available resources. To reduce latency and improve efficiency during migration, nodes with low network transmission delay and sufficient available resources are prioritized. In this example, EdgeNode004 has low network transmission delay and a large amount of available resources, so it is selected as the target node with available resources. The optimal migration path is calculated, assuming that migrating directly from the current node to EdgeNode004 is the optimal path, and the migration duration is estimated. The estimated migration duration can be estimated based on factors such as data size, network bandwidth, and transmission delay. Assume the estimated migration duration is 2 minutes.

[0159] Step S1544: Migrate the load data of the access device that has not completed resource allocation to the target available resource node according to the optimal migration path, and generate a load migration log. The load migration log includes the amount of migration data, actual migration time and target node resource update status.

[0160] Migrate the payload data of access device Device002, which has not yet completed resource allocation, to the target available resource node EdgeNode004, following the optimal migration path. Detailed payload migration logs are kept during the migration process. The payload migration log includes the amount of data migrated (assuming 5 GB), the actual migration duration (assuming 2.5 minutes), and the target node resource update status (one idle CPU core remaining on EdgeNode004 after the update).

[0161] Step S1545: When the actual migration time exceeds the estimated migration time or data loss occurs during the migration process, a resource allocation abnormality alarm event is generated and a resource rollback operation is triggered.

[0162] If the actual migration time exceeds the estimated migration time (2.5 minutes vs. 2 minutes) or data loss occurs during the migration, a resource allocation exception alarm is generated and a resource rollback is triggered. The resource rollback restores the load data for Device002 to its pre-migration state and records the exception for subsequent troubleshooting and resolution.

[0163] Step S155: performing iterative optimization processing on the virtualization resource scheduling policy based on the load migration log and the resource allocation abnormality alarm event, generating an optimized virtualization resource scheduling policy and updating the global resource status mapping table.

[0164] For example, the central scheduling node analyzes the actual migration time and resource allocation exception alarm events in the load migration log, and then performs the following iterative optimization process:

[0165] Step S1551: Analyze the actual migration time and resource allocation abnormality alarm events in the load migration log to determine the resource scheduling efficiency bottleneck factors and the root cause of the abnormality triggering.

[0166] The load migration for Device002 took 2.5 minutes, exceeding the estimated 2 minutes, and generated a resource allocation anomaly alarm. The central scheduling node, through in-depth analysis of the load migration logs and related network data, determined that insufficient network bandwidth was the bottleneck for resource scheduling efficiency. The root cause of the anomaly was network jitter during the migration, which resulted in unstable data transmission.

[0167] Step S1552: Perform topology optimization processing on the resource allocation topology in the virtualized resource scheduling strategy according to the resource scheduling efficiency bottleneck factor to generate an optimized resource allocation topology. The optimized resource allocation topology includes a newly added edge node identifier, load balancing path adjustment parameters, and resource reservation buffer expansion ratio.

[0168] The resource allocation topology in the virtualization resource scheduling policy is optimized based on resource scheduling efficiency bottlenecks. Consider adding edge computing nodes with greater network bandwidth or adjusting the load balancing path to avoid nodes with insufficient network bandwidth. Assuming that EdgeNode006 has sufficient network bandwidth and sufficient resources, it is added to the resource allocation topology as a new edge node with the identifier "EdgeNode006." Simultaneously, the load balancing path is adjusted so that when access devices require load migration, they prioritize routing through EdgeNode006. Furthermore, the resource reservation buffer is appropriately expanded to accommodate potential network fluctuations and sudden increases in resource demand. Assume that the resource reservation buffer expansion ratio is set to 20%. The optimized resource allocation topology is generated, including the newly added edge node identifier "EdgeNode006," load balancing path adjustment parameters (preferring routing through EdgeNode006), and a 20% resource reservation buffer expansion ratio.

[0169] Step S1553: Based on the root cause of the abnormal trigger, the resource redundancy backup instruction is subjected to policy correction processing to generate an optimized resource redundancy backup instruction. The optimized resource redundancy backup instruction includes a backup data compression algorithm, a dynamic disaster recovery node selection strategy, and a backup process retry mechanism.

[0170] Since the anomaly is caused by unstable data transmission due to network jitter, the backup data compression algorithm is optimized and a more efficient compression algorithm, such as the LZMA algorithm, is selected to reduce the amount of data transmitted. At the same time, a dynamic selection strategy for disaster recovery nodes is adopted to monitor the network connection status and load of each disaster recovery node in real time during the backup process, and select disaster recovery nodes with stable network connection and low load for backup. In addition, a backup process retry mechanism is set. When an error occurs during the backup process, it will automatically retry a certain number of times. Assume that the number of retries is set to 3 times. Generate an optimized resource redundancy backup instruction, which includes a backup data compression algorithm (LZMA algorithm), a dynamic selection strategy for disaster recovery nodes, and a backup process retry mechanism (retry 3 times).

[0171] Step S1554: performing policy fusion processing on the optimized resource allocation topology and the optimized resource redundancy backup instruction to generate an optimized virtualization resource scheduling policy, and updating the policy version identifier in the global resource status mapping table.

[0172] The information of newly added edge nodes, load balancing path adjustment, resource reservation buffer expansion, etc. is integrated with the information of backup data compression algorithm, disaster recovery node dynamic selection strategy and backup process retry mechanism to generate an optimized virtualization resource scheduling strategy.

[0173] Through the database connection, an SQL update statement is constructed to update the optimized virtualization resource scheduling policy to the record corresponding to "Device002" in the global resource status mapping table. Simultaneously, the policy version identifier in the global resource status mapping table is updated to distinguish different versions of the virtualization resource scheduling policy, facilitating subsequent management and tracking. This completes the iterative optimization of the virtualization resource scheduling policy and updates the global resource status mapping table.

[0174] Figure 2 A schematic diagram illustrates exemplary hardware and software components of a power wireless local area network-based virtualized computing resource scheduling system 100 that can implement the concepts of the present invention, as provided in some embodiments of the present invention. For example, processor 120 can be used in power wireless local area network-based virtualized computing resource scheduling system 100 to perform the functions of the present invention.

[0175] The power wireless LAN-based virtualized computing resource scheduling system 100 can be a general-purpose server or a special-purpose server, both of which can be used to implement the power wireless LAN-based virtualized computing resource scheduling method of the present invention. Although only one server is shown in the present invention, for convenience, the functions described in the present invention can be implemented in a distributed manner on multiple similar platforms to balance the processing load.

[0176] For example, the virtualized computing resource scheduling system 100 based on the power wireless local area network may include a network port 110 connected to the network, one or more processors 120 for executing program instructions, a communication bus 130, and storage media 140 in different forms, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the virtualized computing resource scheduling system 100 based on the power wireless local area network may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The method of the present invention can be implemented according to these program instructions. The virtualized computing resource scheduling system 100 based on the power wireless local area network also includes an input / output (I / O) interface 150 between the computer and other input / output devices.

[0177] For ease of explanation, only one processor is described in the virtualized computing resource scheduling system 100 based on the power wireless local area network. However, it should be noted that the virtualized computing resource scheduling system 100 based on the power wireless local area network in the present invention can also include multiple processors, so the steps performed by one processor described in the present invention can also be performed jointly or individually by multiple processors. For example, if the processor of the virtualized computing resource scheduling system 100 based on the power wireless local area network executes step A and step B, it should be understood that step A and step B can also be performed jointly by two different processors or individually in one processor. For example, the first processor executes step A, the second processor executes step B, or the first processor and the second processor execute steps A and B together.

[0178] In addition, an embodiment of the present invention further provides a readable storage medium, in which computer-executable instructions are preset. When a processor executes the computer-executable instructions, the above-mentioned virtualized computing resource scheduling method based on the power wireless local area network is implemented.

[0179] It should be noted that in order to simplify the description of the present invention and thus help understand one or more embodiments of the invention, in the foregoing description of the embodiments of the present invention, multiple features are sometimes combined into one embodiment, figure or description thereof.

Claims

1. A virtualized computing resource scheduling method based on a power wireless local area network, characterized in that: The method comprises: Obtaining power equipment operating load data of all connected devices within the coverage area of the power wireless local area network, wherein the power equipment operating load data includes real-time current fluctuation characteristics, voltage phase offset characteristics, and equipment operating cycle parameters; Extracting load characteristics from the operating load data of the power equipment to obtain a load characteristic set for each connected device, wherein the load characteristic set includes a device power consumption fluctuation characteristic, a load response time characteristic, and a resource request priority characteristic; Performing dynamic resource demand forecasting on the load feature set based on a preset load forecasting model to generate a virtualized resource demand forecast result for each access device, wherein the virtualized resource demand forecast result includes a computing resource allocation magnitude and a storage resource allocation timeliness requirement; Generate a virtualization resource scheduling strategy based on the virtualization resource demand prediction result, wherein the virtualization resource scheduling strategy includes a resource allocation topology of edge computing nodes and a resource redundancy backup instruction of a central cloud node; Based on the virtualized resource scheduling strategy, the virtualized computing resources of the power wireless local area network are dynamically adjusted to trigger a resource reallocation operation and update a global resource status mapping table.

2. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 1, characterized in that: The obtaining of the power equipment operating load data of all access devices within the coverage of the power wireless local area network includes: Sending a periodic load monitoring instruction to each access device in the power wireless local area network, wherein the periodic load monitoring instruction includes a device identifier and a monitoring time window parameter; Receive an original load monitoring data packet returned by each access device within the monitoring time window, wherein the original load monitoring data packet includes a current waveform sampling sequence, a voltage waveform sampling sequence, and a device operation status log; Performing fluctuation feature extraction processing on the current waveform sampling sequence to obtain the real-time current fluctuation feature, wherein the real-time current fluctuation feature includes current peak offset, waveform distortion rate, and frequency harmonic distribution parameters; Performing phase offset analysis on the voltage waveform sampling sequence to obtain the voltage phase offset characteristics, wherein the voltage phase offset characteristics include phase synchronization error, voltage drop amplitude, and transient response delay parameter; The periodic task triggering record in the device operation status log is parsed to generate the device operation cycle parameters, wherein the device operation cycle parameters include the task execution interval, the task processing time threshold, and the resource occupancy ratio upper limit.

3. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 2, characterized in that: The extracting load characteristics of the operating load data of the power equipment to obtain a load characteristic set of each connected device includes: Constructing a device power consumption calculation function according to the real-time current fluctuation characteristics and the voltage phase offset characteristics, and generating the device power consumption fluctuation characteristics based on the device power consumption calculation function, wherein the device power consumption fluctuation characteristics include a power consumption change rate per unit time, a peak power consumption duration, and a low power consumption state switching frequency; Performing response timeliness modeling on the equipment operation cycle parameters to generate the load response timeliness characteristics, wherein the load response timeliness characteristics include task processing delay tolerance, resource request response timeout threshold, and real-time assurance level identifier; Performing priority weight allocation processing based on the resource request record in the device operation status log to generate the resource request priority feature, wherein the resource request priority feature includes an emergency task trigger identifier, a key device identifier, and a service quality level parameter; The device power consumption fluctuation characteristics, the load response time characteristics and the resource request priority characteristics are normalized and spliced to obtain the load characteristic set, and the load characteristic set is associated and stored in the global resource status mapping table.

4. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 1, characterized in that: The performing dynamic resource demand prediction processing on the load feature set based on a preset load prediction model to generate a virtualized resource demand prediction result for each access device includes: The pre-trained load prediction model is called to perform time series analysis on the load feature set to generate a short-term resource demand forecast sequence and a long-term resource demand trend distribution; wherein the short-term resource demand forecast sequence includes the computing resource demand peak and storage resource demand fluctuation range within a preset time period in the future; the long-term resource demand trend distribution includes the resource occupancy growth slope, the periodic task superposition impact factor, and the probability of triggering a sudden load event; Performing resource allocation magnitude calculation processing based on the short-term resource demand forecast sequence and the long-term resource demand trend distribution to generate the computing resource allocation magnitude, wherein the computing resource allocation magnitude includes the CPU core number requirement, the memory capacity requirement, and the GPU computing power allocation ratio; Perform storage resource timeliness matching based on the resource request priority characteristics and the load response timeliness characteristics to generate the storage resource allocation timeliness requirements, where the storage resource allocation timeliness requirements include a data read and write delay upper limit, a storage bandwidth guarantee threshold, and a redundant backup response time; The computing resource allocation magnitude and the storage resource allocation timeliness requirement are jointly coded to generate the virtualization resource demand prediction result, and the virtualization resource demand prediction result is written into the global resource status mapping table.

5. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 1, characterized in that: Generating a virtualization resource scheduling strategy according to the virtualization resource demand prediction result includes: Analyze the computing resource allocation magnitude in the virtualization resource demand prediction result to generate a resource allocation topology of the edge computing node, wherein the resource allocation topology includes the computing resource allocation ratio of the edge node, the cross-node load balancing path, and the resource reservation buffer capacity; Generate a resource redundancy backup instruction for the central cloud node according to the storage resource allocation timeliness requirement, wherein the resource redundancy backup instruction includes a data backup cycle parameter, a remote disaster recovery node identifier, and a backup data verification strategy; Constructing a resource scheduling instruction set based on the resource allocation topology and the resource redundancy backup instruction, wherein the resource scheduling instruction set includes edge node resource allocation instructions, central cloud backup triggering instructions, and global load balancing coordination instructions; The resource scheduling instruction set is encapsulated as the virtualized resource scheduling policy, and is associated and stored in the global resource status mapping table.

6. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 5, characterized in that: The dynamically adjusting the virtualized computing resources of the power wireless local area network based on the virtualized resource scheduling strategy, triggering the resource reallocation operation and updating the global resource status mapping table, includes: Sending the edge node resource allocation instruction to the target edge computing node, triggering the target edge computing node to dynamically partition the local resource pool according to the computing resource allocation ratio, and generating updated local resource pool configuration parameters; Sending the central cloud backup trigger instruction to the central cloud node, triggering the central cloud node to perform redundant backup processing on the target data according to the backup data verification strategy, and generating a backup completion confirmation signal and a disaster recovery node status identifier; Receiving the updated local resource pool configuration parameters and the backup completion confirmation signal, performing real-time updating processing on the global resource status mapping table of the power wireless local area network, and generating an updated global resource status mapping table; Perform cross-node load migration processing on access devices that have not completed resource allocation according to the global load balancing coordination instruction, and generate load migration logs and resource allocation abnormality alarm events; The virtualization resource scheduling policy is iteratively optimized based on the load migration log and the resource allocation abnormality alarm event to generate an optimized virtualization resource scheduling policy and update the global resource status mapping table.

7. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 6, characterized in that: The triggering the target edge computing node to dynamically partition the local resource pool according to the computing resource allocation ratio to generate updated local resource pool configuration parameters includes: Analyze the computing resource allocation ratio in the edge node resource allocation instruction to determine the number of CPU cores allocated, memory allocation capacity, and GPU computing power allocation ratio of the target edge computing node; Performing real-time resource occupancy detection on the local resource pool of the target edge computing node to generate current resource occupancy status parameters, wherein the current resource occupancy status parameters include the amount of allocated resources, the amount of idle resources, and the degree of resource fragmentation; Calculate and process resource reservation space according to the computing resource allocation ratio and the current resource occupancy state parameter to generate a resource reservation buffer capacity and a resource recycling trigger threshold; Dynamically partitioning the local resource pool of the target edge computing node based on the resource reservation buffer capacity to generate updated local resource pool configuration parameters, wherein the updated local resource pool configuration parameters include a newly allocated resource block address, a resource reservation area identifier, and a resource recovery strategy; The updated local resource pool configuration parameters are returned to the central scheduling node, and a synchronous update operation of the global resource status mapping table is triggered.

8. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 6, characterized in that: The triggering of the central cloud node to perform redundant backup processing on the target data according to the backup data verification strategy and generate a backup completion confirmation signal and a disaster recovery node status identifier includes: Analyze the backup data verification strategy in the central cloud backup trigger instruction to determine the verification algorithm type, block backup size and disaster recovery node selection priority of the target data; Filtering a target disaster recovery node from a preset disaster recovery node list according to the disaster recovery node selection priority, and sending a backup ready instruction to the target disaster recovery node; receiving a storage space allocation confirmation signal returned by the target disaster recovery node, performing block processing on the target data based on the block backup size, and generating a plurality of data blocks and corresponding block check codes; Perform hash calculation on each data block using the verification algorithm type to generate a block hash value and compare and verify it with the block check code to generate a data integrity verification result; When the data integrity verification result is passed, the multiple data blocks are transmitted in parallel to the target disaster recovery node, and a backup completion confirmation signal and a disaster recovery node status identifier returned by the target disaster recovery node are received.

9. The method for scheduling virtualized computing resources based on a power wireless local area network according to claim 6, characterized in that: The cross-node load migration process is performed on the access device for which resource allocation has not been completed, and a load migration log and a resource allocation abnormality alarm event are generated, including: Obtaining a list of access devices for which resource allocation has not been completed from the global resource status mapping table, the list of access devices including device identifiers, types of unmet resource requirements, and remaining waiting time; Filtering a set of available resource nodes from other edge computing nodes according to the type of unmet resource demand, wherein the set of available resource nodes includes a node identifier, an available resource amount, and a network transmission delay parameter; Performing migration path optimization based on the network transmission delay parameter and the available resource amount to generate an optimal migration path and estimate the migration time; Migrating the load data of the access device for which resource allocation has not been completed to the target available resource node according to the optimal migration path, and generating a load migration log, wherein the load migration log includes the amount of migrated data, the actual migration time, and the resource update status of the target node; When the actual migration time exceeds the estimated migration time or data loss occurs during the migration process, a resource allocation abnormality alarm event is generated and a resource rollback operation is triggered.

10. A virtualized computing resource scheduling system based on power wireless local area network, characterized in that: It includes a processor and a memory, the memory is connected to the processor, the memory is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the memory to implement the virtualized computing resource scheduling method based on the power wireless local area network as described in any one of claims 1 to 9 above.

Images