Communication maintenance method and system based on edge internet-of-things proxy

Abstract

The invention discloses a communication maintenance method and system based on an edge Internet of Things agent, and relates to the technical field of communication maintenance. Real-time agent data of the edge Internet of Things agent is collected and preprocessed; in the cloud maintenance platform, constructing a three-dimensional dynamic agent field of the communication network based on the real-time agent data; setting an operation and maintenance stability plane, and selecting an execution edge internet-of-things agent based on the operation and maintenance stability plane and operation and maintenance requirements; the cloud maintenance platform safely packages the maintenance instruction and then issues the maintenance instruction to an execution edge Internet of Things agent, supervises the transmission process of the maintenance instruction through a multi-party verification mechanism, and generates a verification result; the execution edge internet-of-things agent executes corresponding operation based on the verification result; according to the method, intelligent scheduling of edge Internet of Things agents is realized by constructing a three-dimensional dynamic agent field, and a security supervision mechanism of multi-party cross validation is introduced, so that the reliability of instruction transmission and the accurate handling capability of abnormal nodes in the communication maintenance process are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of communication maintenance technology, and specifically to a communication maintenance method and system based on edge IoT agents. Background Technology

[0002] In the IoT architecture, the edge IoT agent serves as the core hub connecting terminal devices and the cloud platform, undertaking key functions such as data aggregation, protocol conversion, and command issuance. Existing communication maintenance is mostly based on the edge IoT agent to adopt automated link maintenance, and remote communication maintenance is carried out through heartbeat detection and link redundancy design. However, existing technologies have certain shortcomings. First, in terms of task scheduling, most solutions select execution agents based solely on static rules or a single load metric, without comprehensively considering the severity of agent load fluctuations and historical reliability. This can easily lead to high-load agents taking on additional tasks and triggering a chain of failures. Second, in terms of command transmission security, existing solutions rely on a single encrypted channel or centralized authentication, which makes it difficult to prevent data sharding from being tampered with after intermediate nodes are compromised. Furthermore, they lack a distributed monitoring mechanism, making it difficult to detect contradictions when multiple nodes collude to commit malicious acts. At the same time, in terms of anomaly handling, flagged suspected nodes cannot provide tamper-proof local operation logs for self-verification, and cloud platforms lack multi-party verification and dynamic isolation methods, resulting in difficulties in anomaly location and delayed handling. Therefore, it is of great significance to develop a communication maintenance method and system based on edge IoT agents. Summary of the Invention

[0003] The purpose of this invention is to provide a communication maintenance method and system based on edge IoT agents to address the shortcomings in the prior art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a communication maintenance method based on an edge IoT agent, comprising: Collect real-time proxy data from edge IoT agents and preprocess the real-time proxy data; In the cloud maintenance platform, a three-dimensional dynamic proxy field of the communication network is constructed based on real-time proxy data; An operation and maintenance stabilization plane is set at the bottom of the three-dimensional dynamic agent field. Based on the operation and maintenance stabilization plane and operation and maintenance requirements, the edge IoT agent is selected for execution. The cloud-based maintenance platform securely encapsulates maintenance commands and sends them to the execution edge IoT agent. It also monitors the transmission process of maintenance commands through a multi-party verification mechanism and generates verification results. When the edge IoT agent executes a maintenance command with a normal verification result, the cloud maintenance platform analyzes the verification result with an anomaly, generates an anomaly report, and performs troubleshooting operations.

[0005] In a preferred embodiment, the step of collecting real-time proxy data from the edge IoT agent and preprocessing the real-time proxy data is as follows: Collect the real-time load status and network topology location of each edge IoT agent; The real-time load status includes CPU utilization, memory usage, number of currently processed tasks, communication queue length, and energy consumption data. The network topology location is determined based on the connection relationship of the edge IoT agent in the physical network. The collected real-time load status and network topology location data are cleaned, normalized, and converted to generate real-time proxy data.

[0006] In a preferred embodiment, the step of constructing a three-dimensional dynamic proxy field of the communication network based on real-time proxy data in the cloud maintenance platform is as follows: Each edge IoT agent is assigned planar coordinates, which are generated based on the network topology location using a network topology distance algorithm. Each edge IoT agent is assigned a height coordinate. The height coordinate is positively correlated with the real-time load status. The higher the real-time load status, the larger the height coordinate value. The lower the real-time load status, the smaller the height coordinate value. A three-dimensional dynamic agent field is generated based on the planar and height coordinates of each edge IoT agent.

[0007] In a preferred embodiment, the step of setting an operation and maintenance stabilization plane at the bottom of the three-dimensional dynamic agent field, and selecting the execution edge IoT agent based on the operation and maintenance stabilization plane and operation and maintenance requirements, is as follows: The cloud-based maintenance platform collects historical load status data of all edge IoT agents within a preset period, performs statistical analysis on the historical load status data, and generates a statistical baseline load. The statistical baseline load is mapped to the height position of the operation and maintenance stability plane, and the operation and maintenance stability plane is generated in the three-dimensional dynamic agent field. The operation and maintenance stability plane is used to define the ideal operation and maintenance state of the edge IoT agent. The overall distance from each edge IoT agent to the operation and maintenance stable plane is calculated as the stability. The stability is generated by weighting the vertical distance, the speed of movement in the height coordinate, and the historical reliability. Among them, the vertical distance is the difference between the current height coordinates of the edge IoT agent and the operation and maintenance stable plane, the height coordinate movement speed is the speed at which the height coordinates of the edge IoT agent change, and the historical reliability is generated by weighting the success rate, average response time and number of failures of the edge IoT agent in the past. When communication maintenance tasks need to be performed, the target area of ​​the task is determined according to the operation and maintenance requirements, and the edge IoT agent with the highest stability is selected as the execution edge IoT agent within the vicinity of the target area.

[0008] In a preferred embodiment, the step of the cloud maintenance platform securely encapsulating maintenance instructions and then sending them to the edge IoT agent is as follows: The cloud-based maintenance platform breaks down maintenance instructions into multiple data shards, each of which does not contain complete instruction information. The cloud maintenance platform sends multiple data fragments to the execution edge IoT agent through multiple independent communication paths. These multiple independent communication paths are selected from any combination of cellular networks from different operators, fiber optic networks with different physical routes, and multi-hop communication paths forwarded by different neighboring edge IoT agents. The edge IoT agent receives and reassembles multiple data fragments to obtain a complete maintenance instruction, calculates the hash value of the complete maintenance instruction, and returns the hash value as a commitment to the cloud maintenance platform. The cloud maintenance platform publishes the data to be verified after a random delay. The data to be verified includes complete maintenance instructions and the shard hash values ​​corresponding to each of the multiple data shards.

[0009] In a preferred embodiment, the step of supervising the transmission process of maintenance instructions through a multi-party verification mechanism is as follows: The cloud-based maintenance platform constructs an independent virtual verification space and generates multiple edge IoT agents based on the stable operation and maintenance plane, serving as candidate verifiers. The cloud-based maintenance platform randomly selects multiple edge IoT agents from the candidate verifiers to enter the virtual verification space and discloses the data to be verified to the verifiers. Each verifier calculates the publicly available data to be verified on the cloud maintenance platform and compares it with the commitment returned by the execution edge IoT agent. If they are inconsistent, the execution edge IoT agent is marked as a suspected execution edge IoT agent. At the same time, the verifier sends a challenge request to each forwarding node on multiple independent communication paths. The challenge request requires the forwarding node to provide proof of the sending and receiving records, including timestamps, identifiers of both the sender and receiver, and hash values ​​of the data fragments forwarded. All verifiers publicly present their collected send and receive records in the virtual verification space, and jointly cross-compare all the proofs to identify any contradictory records. Among them, conflicting records include time record conflicts of the same forwarding node on different communication paths, mismatch of send and receive records between adjacent forwarding nodes, and inconsistent hash values ​​of the same data fragment on different communication paths. The verifier identifies the relevant forwarding nodes in the virtual verification space based on the identified contradictory records, marks the forwarding node as a suspected edge IoT agent, and records the basis for the identification. After multiple rounds of questioning and identification, the verifiers collectively vote in the virtual verification space to generate a consistent judgment on the suspected edge IoT agent. The conflict records, identification evidence, and consistency judgments are packaged to generate verification results and reported to the cloud maintenance platform.

[0010] In a preferred embodiment, the steps for executing maintenance instructions with normal verification results from the edge IoT agent, and for the cloud maintenance platform to parse verification results with abnormal results, generate an anomaly report, and perform troubleshooting operations are as follows: After confirming that the maintenance command has passed multiple verifications, the edge IoT agent executes the corresponding operation and feeds back the execution result to the cloud maintenance platform. For verification results that are found to be abnormal, the cloud maintenance platform analyzes the verification results and extracts contradictory records and evidence for identification. The cloud-based maintenance platform locates the communication path and node position where the anomaly occurred based on the conflict records and identification evidence, and determines the anomaly type, which includes data fragmentation and tampering, promise forgery, node offline, and malicious node behavior; Integrate verification results and exception types into an exception report; Based on the anomaly report, suspected edge IoT agents and suspected execution edge IoT agents are marked in the 3D dynamic agent field, their height coordinates are forcibly reduced to below the operation and maintenance stable plane, their communication permissions are cut off, and maintenance instructions are resent.

[0011] The present invention also provides a communication maintenance system based on an edge IoT agent, comprising: Data acquisition module: Collects real-time proxy data from edge IoT agents and preprocesses the real-time proxy data; Agent field construction module: Connected to the data acquisition module, it constructs a three-dimensional dynamic agent field for the communication network based on real-time agent data in the cloud maintenance platform; Stable plane construction module: Connected to the agent field construction module, it sets up an operation and maintenance stable plane at the bottom of the three-dimensional dynamic agent field, and selects to execute the edge IoT agent based on the operation and maintenance stable plane and operation and maintenance requirements; Security verification module: Connected to the stable plane construction module, the cloud maintenance platform securely encapsulates maintenance commands and sends them to the execution edge IoT agent. It also supervises the transmission process of maintenance commands through a multi-party verification mechanism and generates verification results. Command execution module: Connected to the security verification module, it executes maintenance commands with normal verification results from the edge IoT agent. The cloud maintenance platform parses verification results with abnormal results, generates an anomaly report, and performs troubleshooting operations.

[0012] The technical effects and advantages provided by the present invention in the above technical solution are as follows: 1. This invention constructs a three-dimensional dynamic agent field, transforming the real-time load status of edge IoT agents into dynamic height coordinates and mapping the network topology location into planar coordinates, forming a visualized agent spatial distribution. A stable operation plane based on historical load data statistics is set at the bottom of the three-dimensional dynamic agent field, allowing for the quantification of the load deviation and fluctuation intensity of each edge IoT agent. When communication maintenance tasks need to be performed, the cloud maintenance platform filters and executes edge IoT agents based on stability. For agents with excessively high loads, the system can first trigger a load migration mechanism to transfer non-urgent tasks to nearby low-load agents, and then formally assign tasks after the load decreases. This dynamic load balancing mechanism effectively avoids cascading failures caused by high-load agents taking on additional tasks, significantly improving the overall stability and reliability of the communication network and realizing intelligent scheduling of operation and maintenance resources. 2. This invention implements a distributed supervision of the maintenance instruction transmission process through a multi-party verification mechanism. A virtual verification space is established on the cloud-based maintenance platform, and multiple verifier agents are randomly selected to participate in the verification process while maintaining their identities concealed. The cloud-based maintenance platform breaks down the maintenance instruction into multiple data fragments and transmits them through multiple independent communication paths. After the edge IoT agent returns a commitment, the cloud publishes the data to be verified after a random delay. The verifier agents, acting as ordinary nodes, initiate challenges to the forwarding nodes, collecting proof of send and receive records containing timestamps and hash values. These records are then cross-checked in the virtual verification space. After identifying contradictory records, multiple rounds of challenges and accusations are initiated, ultimately leading to a consensus judgment through collective voting. This mechanism prevents any node attempting to tamper with data or forge records from predicting the verifier's identity, making it difficult to conceal abnormal behavior through collusion. Contradictions are inevitably exposed during multiple rounds of interaction. This design does not rely on a centralized trust anchor; it establishes a trusted verification result through distributed interaction, effectively ensuring the confidentiality, integrity, and traceability of the maintenance instruction transmission. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0014] Figure 1 This is a flowchart of the method of the present invention.

[0015] Figure 2 This is a system block diagram of the present invention.

[0016] Figure 3 This is a logic block diagram of the present invention. Detailed Implementation

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

[0018] Example 1, please refer to Figure 1 and Figure 3 As shown in this embodiment, a communication maintenance method based on an edge IoT agent includes: S1. Collect real-time proxy data from edge IoT agents and preprocess the real-time proxy data; S2. In the cloud maintenance platform, a three-dimensional dynamic agent field of the communication network is constructed based on real-time agent data; S3. Set up an operation and maintenance stable plane at the bottom of the three-dimensional dynamic agent field, and select to execute the edge IoT agent based on the operation and maintenance stable plane and operation and maintenance requirements; S4. The cloud-based maintenance platform securely encapsulates maintenance commands and sends them to the execution edge IoT agent. It also monitors the transmission process of maintenance commands through a multi-party verification mechanism and generates verification results. S5. If the edge IoT agent executes the maintenance command and the verification result is normal, the cloud maintenance platform will parse the verification result that is abnormal, generate an anomaly report, and perform troubleshooting operations.

[0019] As described in steps S1-S5 above, in the IoT architecture, the edge IoT agent, as the core hub connecting terminal devices and the cloud platform, undertakes key functions such as data aggregation, protocol conversion and command issuance. Existing communication maintenance is mostly based on the edge IoT agent to adopt automated link maintenance, and remote communication maintenance is carried out through heartbeat detection and link redundancy design. However, existing technologies have certain shortcomings. First, in terms of task scheduling, most solutions select execution agents based solely on static rules or a single load metric, without comprehensively considering the severity of agent load fluctuations and historical reliability. This can easily lead to high-load agents taking on additional tasks and triggering a chain of failures. Second, in terms of command transmission security, existing solutions rely on a single encrypted channel or centralized authentication, which makes it difficult to prevent data sharding from being tampered with after intermediate nodes are compromised. Furthermore, they lack a distributed monitoring mechanism, making it difficult to detect contradictions when multiple nodes collude to commit malicious acts. At the same time, in terms of anomaly handling, flagged suspected nodes cannot provide tamper-proof local operation logs for self-verification, and cloud platforms lack multi-party verification and dynamic isolation methods, resulting in difficulties in anomaly location and delayed handling. This invention constructs a three-dimensional dynamic agent field, transforming the real-time load status of edge IoT agents into dynamic height coordinates and mapping the network topology location to planar coordinates, forming a visualized agent spatial distribution. At the bottom of the three-dimensional dynamic agent field, an operation and maintenance stability plane generated based on historical load data statistics is set, allowing for the quantification of the load deviation and fluctuation intensity of each edge IoT agent. When communication maintenance tasks need to be performed, the cloud maintenance platform filters and executes edge IoT agents based on stability. For agents with excessively high loads, the system can first trigger a load migration mechanism to transfer non-urgent tasks to nearby low-load agents, and then formally assign tasks after the load decreases. This dynamic load balancing mechanism effectively avoids cascading failures caused by high-load agents taking on additional tasks, significantly improving the overall stability and reliability of the communication network and realizing intelligent scheduling of operation and maintenance resources. By constructing a multi-party verification mechanism to conduct distributed supervision of the maintenance command transmission process, a virtual verification space is established on the cloud maintenance platform. Multiple verifier agents are randomly selected and participate in the verification in an anonymous manner. The cloud maintenance platform splits the maintenance command into multiple data fragments and transmits them through multiple independent communication paths. After the edge IoT agent returns a commitment, the cloud publishes the data to be verified after a random delay. The verifier agents, acting as ordinary nodes, initiate challenges to the forwarding nodes, collect proof of the send and receive records containing timestamps and hash values, and perform cross-comparison in the virtual verification space. After identifying contradictory records, multiple rounds of challenges and accusations are initiated, and finally a consensus judgment is formed through collective voting. This mechanism makes it impossible for any node attempting to tamper with data or forge records to predict the verifier's identity, making it difficult to cover up abnormal behavior through collusion, and contradictions will inevitably be exposed in multiple rounds of interaction. This design does not rely on a centralized trust anchor and establishes a trusted verification result through distributed interaction, effectively ensuring the confidentiality, integrity, and traceability of the maintenance command transmission.

[0020] In one embodiment, step S1, which involves collecting real-time proxy data from edge IoT agents and preprocessing the real-time proxy data, includes: S11. Collect the real-time load status and network topology location of each edge IoT agent; S12, where the real-time load status includes CPU utilization, memory usage, number of currently processed tasks, communication queue length, and energy consumption data, and the network topology location is determined based on the connection relationship of the edge IoT agent in the physical network; S13. Perform data cleaning, normalization and format conversion on the collected real-time load status and network topology location to generate real-time proxy data; As described in steps S11-S13 above, the data acquisition module deployed locally on each edge IoT agent collects the real-time load status and network topology location of each edge IoT agent in real time according to a preset sampling period. The real-time load status specifically includes CPU utilization, memory usage, number of currently processed tasks, communication queue length, and energy consumption data. CPU utilization is calculated by reading CPU time statistics from the operating system kernel. Memory usage is determined by analyzing the difference between the total memory and available memory in the memory management unit. The number of currently processed tasks is obtained by counting the number of active tasks in the task scheduling queue. The communication queue length is obtained by acquiring the send and receive buffer occupancy information from the network device driver layer. Energy consumption data is obtained by reading the power management chip registers on the edge IoT agent hardware platform. The network topology location is determined based on the connection relationships of the edge IoT agents in the physical network, and is obtained by resolving network... The routing table at the network layer and the link layer discovery protocol obtain information about neighboring nodes and network hop counts. Data cleaning is performed on the collected real-time load status and network topology location. This cleaning includes removing outliers that are significantly outside the physical range due to sensor anomalies or momentary communication interruptions, and filling in temporary data gaps caused by sampling failures using interpolation methods. After cleaning, the data is normalized using a min-max normalization method to map load indicators of different dimensions to a unified numerical range, eliminating dimensional differences between indicators such as CPU utilization, memory usage, and communication queue length. Finally, format conversion is performed, repackaging the normalized data according to the data structure defined by the cloud maintenance platform to generate real-time agent data containing a unique identifier for each edge IoT agent, a timestamp, a standardized load vector, and a topology code field. This real-time agent data is then uploaded to the cloud maintenance platform via a message queue.

[0021] In one embodiment, step S2, which involves constructing a three-dimensional dynamic proxy field of the communication network based on real-time proxy data in a cloud maintenance platform, includes: S21. Assign planar coordinates to each edge IoT agent. The planar coordinates are generated based on the network topology location using a network topology distance algorithm. S22. Assign height coordinates to each edge IoT agent. The height coordinates are positively correlated with the real-time load status. The higher the real-time load status, the larger the height coordinate value. The lower the real-time load status, the smaller the height coordinate value. S23. Generate a three-dimensional dynamic agent field based on the planar coordinates and height coordinates of each edge IoT agent; As described in steps S21-S23 above, planar coordinates are assigned to each edge IoT agent. The allocation of planar coordinates is generated based on the network topology location using a network topology distance algorithm. A multidimensional scaling algorithm is used to convert the hop count matrix of the edge IoT agent in the network into Euclidean distance on a two-dimensional plane, ensuring that edge IoT agents with similar hop counts are close to each other on the planar coordinates, while those with larger hop counts are far apart. Conformal mapping is used to maintain the local adjacency relationship of the network topology. The planar coordinates are recalculated every network topology update cycle to synchronously update changes in the network structure. Simultaneously, height coordinates are assigned to each edge IoT agent. The height coordinates are positively correlated with the real-time load status. A comprehensive load value is obtained by weighted summing of CPU utilization, memory usage, number of currently processed tasks, communication queue length, and energy consumption data in the real-time load status. This comprehensive load value is then converted into height coordinate values ​​through a linear mapping function. A higher comprehensive load value results in a larger height coordinate value, and a lower comprehensive load value results in a lower height coordinate value. The system dynamically adjusts in real time according to changes in real-time load status. The weighted summation uses dynamic weighting. The cloud maintenance platform continuously monitors the historical fluctuation range of various indicators of all edge IoT agents. For CPU utilization, memory usage, number of current processing tasks, communication queue length, and energy consumption, the variance of each indicator within the most recent time window is calculated as a volatility measure. The greater the volatility of an indicator, the more unstable its current load status. Its weight should be reduced in the comprehensive load calculation to avoid excessive impact of instantaneous fluctuations on load assessment. Finally, a three-dimensional dynamic agent field is generated based on the planar and height coordinates of each edge IoT agent. A three-dimensional point matrix data structure is maintained in the memory of the cloud maintenance platform, storing the corresponding three-dimensional coordinates with the unique identifier of each edge IoT agent as an index. At the same time, the spatial distribution of all edge IoT agents is rendered in real time in a graphical interface in a visual manner. Each edge IoT agent is represented as an interactive node in three-dimensional space. The height change of the node intuitively reflects the load fluctuation, and the planar clustering degree of the nodes intuitively reflects the closeness of the network topology.

[0022] In one embodiment, step S3, which involves setting an operation and maintenance stabilization plane at the bottom of the three-dimensional dynamic agent field and selecting to execute the edge IoT agent based on the operation and maintenance stabilization plane and operation and maintenance requirements, includes: S31. The cloud maintenance platform collects historical load status data of all edge IoT agents within a preset period, performs statistical analysis on the historical load status data, and generates a statistical baseline load. S32. Map the statistical baseline load to the height position of the operation and maintenance stability plane, generate the operation and maintenance stability plane in the three-dimensional dynamic agent field, and use the operation and maintenance stability plane to define the ideal operation and maintenance state of the edge IoT agent. S33. Calculate the comprehensive distance from each edge IoT agent to the operation and maintenance stable plane as the stability. The stability is generated by weighted calculation of vertical distance, height coordinate movement speed and historical reliability. S34. Wherein, the vertical distance is the difference between the current height coordinates of the edge IoT agent and the operation and maintenance stable plane, the height coordinate movement speed is the speed at which the height coordinates of the edge IoT agent change, and the historical reliability is generated by weighting the success rate, average response time and number of failures of the edge IoT agent in the past. S35. When communication maintenance tasks need to be performed, determine the target area of ​​the task according to the operation and maintenance requirements, and select the edge IoT agent with the highest stability in the vicinity of the target area as the execution edge IoT agent. As described in steps S31-S35 above, the cloud maintenance platform collects historical load status data of all edge IoT agents within a preset period, samples and stores the comprehensive load value in the real-time load status of each edge IoT agent, and then performs statistical analysis on all historical comprehensive load values ​​to calculate their arithmetic mean as the statistical benchmark load. This statistical benchmark load reflects the average load level of the entire agent group within the historical period. The statistical benchmark load is mapped to the height position of the operation and maintenance stability plane. Through linear mapping, the statistical benchmark load value in the range [0,1] is converted into the corresponding value in the height coordinate range of the three-dimensional dynamic agent field. A virtual plane with constant height parallel to the plane coordinate is generated in the three-dimensional dynamic agent field as the operation and maintenance stability plane. This plane defines the ideal operation and maintenance state of the edge IoT agent, that is, the state where the load is close to the average level. Then, the comprehensive distance from each edge IoT agent to the operation and maintenance stability plane is calculated as the stability. The stability is generated by weighting three indicators: vertical distance, height coordinate movement speed, and historical reliability. The weight coefficient also adopts dynamic weight coefficient. The vertical distance is defined as the distance between the current height coordinate of the edge IoT agent and the height coordinate of the agent. The absolute value of the difference in altitude between the stable operation and maintenance planes is used. The altitude coordinate movement speed is obtained by calculating the moving average of the changes in altitude coordinates of the edge IoT agent within a preset time window. Historical reliability is calculated by weighting the success rate, average response time, and number of failures of the edge IoT agent in the past, and the value ranges from [0, 1]. The higher the value, the more reliable the historical performance. The smaller the comprehensive distance value, the more stable the edge IoT agent. The inverse of the comprehensive distance value is then used to obtain the stability value, so that the higher the stability, the more suitable the agent is for performing tasks. When communication maintenance tasks need to be performed, the cloud maintenance platform determines the target area of ​​the task according to the operation and maintenance requirements. For example, when the task is for a specific terminal device, the plane coordinates of the edge IoT agent connected to the terminal device are used as the center of the target area. Within the vicinity of the target area, all edge IoT agents with a distance less than a preset radius threshold are selected by calculating the Euclidean distance of the plane coordinates. Then, the edge IoT agent with the highest stability is selected from these candidate agents as the execution edge IoT agent to ensure that the edge IoT agent undertaking the communication maintenance task has the lowest current load, the smallest fluctuation, and the best historical performance.

[0023] In one embodiment, the cloud maintenance platform securely encapsulates the maintenance instructions and sends them to step S4, which involves executing the edge IoT agent. S41. The cloud-based maintenance platform breaks down maintenance instructions into multiple data fragments, each of which does not contain complete instruction information. S42. The cloud maintenance platform sends multiple data fragments to the execution edge IoT agent through multiple independent communication paths. The multiple independent communication paths are selected from any combination of cellular networks of different operators, fiber optic networks with different physical routes, and multi-hop communication paths forwarded by different neighboring edge IoT agents. S43. The edge IoT agent receives and reassembles multiple data fragments to obtain a complete maintenance instruction, calculates the hash value of the complete maintenance instruction, and returns the hash value as a commitment to the cloud maintenance platform. S44. The cloud maintenance platform will publicly release the data to be verified after a random delay. The data to be verified includes complete maintenance instructions and the shard hash values ​​corresponding to each of the multiple data shards. As described in steps S41-S44 above, the cloud maintenance platform splits the maintenance command into multiple data fragments. The splitting employs the polynomial interpolation principle in the secret sharing algorithm, dividing the binary data of the maintenance command into a preset number of fragments. Each data fragment contains only a partial data segment and does not contain complete command information. The number of fragments is set to at least three to ensure redundancy and security. Multiple data fragments are then sent to the execution edge IoT agent via multiple independent communication paths. These independent communication paths are selected from any combination of cellular networks from different operators, fiber optic networks with different physical routes, and multi-hop communication paths forwarded via different neighboring edge IoT agents. Specifically, the cloud maintenance platform maintains a path resource pool. Each time a command is issued, at least two paths with completely different physical media are randomly selected from the resource pool. For example, one path sends the command directly through a China Telecom 4G network, another path sends it through a China Unicom fiber optic network, and a third path sends it via a neighboring edge IoT agent A. The system employs multi-hop forwarding with neighboring edge IoT agent B to ensure that attackers cannot reconstruct the complete maintenance instruction if any single communication path is intercepted. After the execution edge IoT agent receives multiple data fragments, it reassembles them using a reassembly algorithm corresponding to the splitting algorithm to obtain the complete maintenance instruction. Then, the execution edge IoT agent calculates the hash value of the complete maintenance instruction using the SHA-256 hash algorithm and returns this hash value as a commitment to the cloud maintenance platform. The commitment is sent through an independent secure channel, such as a short message channel encrypted with a pre-shared key. At this point, the execution edge IoT agent is aware of the instruction content but does not execute it. Finally, the cloud maintenance platform publishes the data to be verified after a random delay, with the random delay ranged between five and thirty seconds to prevent attackers from obtaining complete information through synchronous eavesdropping. The data to be verified includes the complete maintenance instruction itself and the fragment hash values ​​corresponding to each of the multiple data fragments. The cloud maintenance platform publishes the data to be verified to some edge IoT agents via broadcast.

[0024] In one embodiment, step S4, which involves supervising the transmission process of maintenance instructions through a multi-party verification mechanism, includes: S45. The cloud maintenance platform constructs an independent virtual verification space and generates multiple edge IoT agents based on the stable operation and maintenance plane as candidate verifiers. S46. The cloud maintenance platform randomly selects multiple edge IoT agents from the candidate verifiers to enter the virtual verification space and discloses the data to be verified to the verifiers. S47. Each verifier calculates the data to be verified publicly on the cloud maintenance platform and compares it with the commitment returned by the execution edge IoT agent. If they are inconsistent, the execution edge IoT agent is marked as a suspected execution edge IoT agent. S48. At the same time, the verifier sends a challenge request to each forwarding node on multiple independent communication paths. The challenge request requires the forwarding node to provide proof of the sending and receiving records, which includes timestamps, identifiers of the sender and receiver, and hash values ​​of the data fragments forwarded. S49. All verifiers publicly present their collected send and receive records in the virtual verification space, and jointly cross-compare all the proofs to identify any contradictory records. S410, where conflicting records include time record conflicts of the same forwarding node on different communication paths, mismatch of send and receive records between adjacent forwarding nodes, and inconsistent hash values ​​of the same data fragment on different communication paths; S411. The verifier identifies the relevant forwarding node in the virtual verification space based on the identified contradictory records, marks the forwarding node as a suspected edge IoT agent, and records the basis for the identification. S412. After multiple rounds of questioning and identification, the verifiers collectively vote in the virtual verification space to generate a consistent judgment on the suspected edge IoT agent. S413. Encapsulate the contradiction records, identification basis, and consistency judgment to generate verification results and report them to the cloud maintenance platform; As described in steps S45-S413 above, the cloud maintenance platform constructs an independent virtual verification space in memory. This virtual verification space is a logically isolated communication area. All interaction information between edge IoT agents entering this space is only visible to members within the space. Based on the operational stability plane, the cloud maintenance platform selects all edge IoT agents with stability exceeding a preset threshold from the three-dimensional dynamic agent field as candidate verifiers, ensuring that the candidate verifiers themselves have high reliability and stability. From the candidate verifiers, a true random number generator randomly selects multiple edge IoT agents as verifiers to enter the virtual verification space. The number of verifiers is set to at least three and they are mutually exclusive. Knowing each other's identities, the identity information of the validators is only held by the cloud maintenance platform and is not disclosed to any other edge IoT agents, including execution edge IoT agents and forwarding nodes. The cloud maintenance platform discloses the data to be verified, namely the complete maintenance instruction, and the hash values ​​of each of the multiple data shards to all validators. Each validator independently calculates the hash value of the complete maintenance instruction disclosed by the cloud maintenance platform and compares this hash value byte-by-byte with the commitment previously returned by the execution edge IoT agent. If the two do not match, the execution edge IoT agent is marked as a suspected execution edge IoT agent, and the comparison result is recorded as the basis for identification. At the same time, each validator, as a regular node, sends multiple... Each forwarding node on an independent communication path initiates a challenge request. The challenge request is sent via an encrypted communication channel and requires the forwarding node to provide proof of the send / receive record, including a timestamp, sender and receiver identifiers, and the hash value of the forwarded data fragment. Upon receiving the challenge request, the forwarding node cannot distinguish between a regular node and a validator and must truthfully return a proof of the send / receive record signed with its own private key. The timestamp in the proof of the send / receive record is derived from the node's local hardware clock and is accurate to the millisecond level. The sender and receiver identifiers use the unique device number of the edge IoT agent, and the hash value of the forwarded data fragment corresponds one-to-one with the fragment content. All validators publicly disclose their respective... All the sent and received record proofs returned by the forwarding nodes are collected. Verifiers interact with each other through a secure channel provided by the virtual verification space. Based on the secure channel, all verifiers jointly cross-compare all the publicly available sent and received record proofs. The specific implementation of the cross-compare is to perform alignment analysis on the timestamp records provided by the same forwarding node on different communication paths to check for any time logic contradictions; to pair the sent and received records between adjacent forwarding nodes to check whether the sending time of the upstream node is earlier than the receiving time of the downstream node and whether the source identifier of the downstream node's record matches that of the upstream node; and to compare the hash values ​​of the same data fragment on different communication paths to check whether they are completely consistent.Verifiers identify contradictory records based on cross-comparison results. Specific contradictory records include time discrepancies of the same forwarding node across different communication paths (e.g., a node's transmission time on path A is later than its claimed reception time on path B); mismatches in transmission and reception records between adjacent forwarding nodes (e.g., an upstream node claims to have sent data but a downstream node denies receiving it); and inconsistent hash values ​​of the same data fragment across different communication paths (e.g., the same fragment is reported as different hash values ​​on two paths). Verifiers then identify relevant forwarding nodes in the virtual verification space based on the identified contradictory records. Identification requires publicly disclosing the specific content of the contradictory records and the comparison process as the basis for identification, and marking the forwarding node as a suspected edge IoT agent. The cross-comparison process involves aligning and analyzing the timestamp records provided by the same forwarding node across different communication paths to check for time logic contradictions; pairing the transmission and reception records between adjacent forwarding nodes to check if the upstream node's transmission time is earlier than the downstream node's reception time and if the source identifier of the downstream node's record matches that of the upstream node; and comparing the same data fragment across different communication paths to identify the contradictory data fragment. The verifier compares the hash values ​​of the data fragments across different communication paths to check for complete consistency. Based on the cross-comparison results, the verifier identifies conflicting records, including time discrepancies of the same forwarding node across different communication paths (e.g., a node's transmission time on path A is later than its claimed reception time on path B), mismatches in transmission and reception records between adjacent forwarding nodes (e.g., an upstream node claims to have sent data but a downstream node denies receiving it), and inconsistent hash values ​​of the same data fragment across different communication paths (e.g., the same fragment is reported with different hash values ​​on two different paths). Based on the identified conflicting records, the verifier identifies the relevant forwarding nodes in the virtual verification space. The identification requires publicly disclosing the specific content of the conflicting records and the comparison process as the basis for identification, and marking the forwarding node as a suspected edge IoT agent. Each verifier independently casts a vote of approval or disapproval. Suspected edge IoT agents receiving more than half of the votes are confirmed as malicious edge IoT agents, forming a consensus judgment. Finally, all conflicting records, identification evidence, and consensus judgments are packaged into a verification result and uploaded to the cloud maintenance platform.

[0025] In one embodiment, step S5, where the maintenance instruction executed by the edge IoT agent has a normal verification result, and the cloud maintenance platform parses the verification result with an abnormal verification result to generate an anomaly report and performs troubleshooting operations, includes: S51. After confirming that the maintenance command has passed multi-party verification, the edge IoT agent executes the operation corresponding to the maintenance command and feeds back the execution result to the cloud maintenance platform. S52. For verification results that are abnormal, the cloud maintenance platform analyzes the verification results and extracts contradictory records and evidence for identification. S53. The cloud maintenance platform locates the communication path and node position where the anomaly occurred based on the conflict records and identification evidence, and determines the anomaly type. The anomaly types include data fragmentation and tampering, commitment forgery, node offline, and malicious node behavior. S54. Integrate verification results and exception types into an exception report; S55. Based on the anomaly report, mark the suspected edge IoT agent and the suspected execution edge IoT agent in the three-dimensional dynamic agent field, force their height coordinates to be reduced below the operation and maintenance stable plane, cut off communication permissions, and resend the maintenance command. As described in steps S51-S55 above, the edge IoT agent executes the corresponding operation after confirming that the maintenance instruction has passed multi-party verification. Before execution, it is necessary to verify that the verification result returned by the multi-party verification mechanism does not contain any suspicious markers targeting itself. During execution, operations such as remotely restarting the terminal device, switching the uplink communication link, or adjusting local communication parameters are completed according to the specific content of the maintenance instruction. After execution, the execution result, including the success or failure flag, execution time, and abnormal records during the execution process, is encapsulated and fed back to the cloud maintenance platform. For verification results with verification anomalies, the cloud maintenance platform uses its own private key to parse the encapsulated verification result, extract the contradictory records and identification evidence contained therein, and locate the communication path and node location where the anomaly occurred based on the contradictory records and identification evidence. Specifically, by analyzing the timestamps and node identifiers involved in the contradictory records, combined with the topology diagram of multiple independent communication paths, the specific path segment and specific node where the anomaly occurred are traced. At the same time, based on the contradictions... The shield record type determines the anomaly type, and integrates contradictory records, identification basis, and the located anomaly node location with the determined anomaly type to generate an anomaly report. Based on the anomaly report, the cloud maintenance platform marks suspected edge IoT agents and suspected execution edge IoT agents in the 3D dynamic agent field. Specifically, in the data structure of the 3D dynamic agent field, the status field of the marked node is updated to the suspected status, and its height coordinate is forcibly reduced to below the operation and maintenance stable plane, for example, set to a negative value to distinguish it from normal agents. At the same time, the cloud maintenance platform cuts off all communication permissions of the marked node through the network configuration management module, including prohibiting it from receiving new maintenance instructions, prohibiting it from participating in data forwarding, and prohibiting it from entering the virtual verification space as a verifier. After completing the isolation operation, the cloud maintenance platform regenerates the same maintenance instructions and re-executes the security encapsulation and distribution process. When redistributing, it automatically avoids the communication path where the marked suspected node is located and selects other healthy forwarding nodes and independent communication paths to complete the transmission of operation and maintenance instructions.

[0026] Example 2, please refer to Figure 2 As shown in this embodiment, a communication maintenance system based on an edge IoT agent includes: Data acquisition module: Collects real-time proxy data from edge IoT agents and preprocesses the real-time proxy data; Agent field construction module: Connected to the data acquisition module, it constructs a three-dimensional dynamic agent field for the communication network based on real-time agent data in the cloud maintenance platform; Stable plane construction module: Connected to the agent field construction module, it sets up an operation and maintenance stable plane at the bottom of the three-dimensional dynamic agent field, and selects to execute the edge IoT agent based on the operation and maintenance stable plane and operation and maintenance requirements; Security verification module: Connected to the stable plane construction module, the cloud maintenance platform securely encapsulates maintenance commands and sends them to the execution edge IoT agent. It also supervises the transmission process of maintenance commands through a multi-party verification mechanism and generates verification results. Command execution module: Connected to the security verification module, it executes maintenance commands with normal verification results from the edge IoT agent. The cloud maintenance platform parses verification results with abnormal results, generates an anomaly report, and performs troubleshooting operations.

[0027] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication maintenance method based on edge IoT agent, characterized in that, include: Collect real-time proxy data from edge IoT agents and preprocess the real-time proxy data; In the cloud maintenance platform, a three-dimensional dynamic proxy field of the communication network is constructed based on real-time proxy data; An operation and maintenance stabilization plane is set at the bottom of the three-dimensional dynamic agent field. Based on the operation and maintenance stabilization plane and operation and maintenance requirements, the edge IoT agent is selected for execution. The cloud-based maintenance platform securely encapsulates maintenance commands and sends them to the execution edge IoT agent. It also monitors the transmission process of the maintenance commands through a multi-party verification mechanism and generates verification results. If the edge IoT agent executes a maintenance command with a normal verification result, the cloud maintenance platform will parse the verification result with an anomaly, generate an anomaly report, and perform troubleshooting operations.

2. The communication maintenance method based on edge IoT agent according to claim 1, characterized in that, The steps for preprocessing the real-time proxy data collected from the edge IoT agent are as follows: Collect the real-time load status and network topology location of each edge IoT agent; The real-time load status includes CPU utilization, memory usage, number of currently processed tasks, communication queue length, and energy consumption data. The network topology location is determined based on the connection relationship of the edge IoT agent in the physical network. The collected real-time load status and network topology location data are cleaned, normalized, and converted to generate real-time proxy data.

3. The communication maintenance method based on edge IoT agent according to claim 1, characterized in that, The steps for constructing a three-dimensional dynamic proxy field of the communication network based on real-time proxy data in the cloud maintenance platform are as follows: Each edge IoT agent is assigned planar coordinates, which are generated based on the network topology location using a network topology distance algorithm. Each edge IoT agent is assigned a height coordinate. The height coordinate is positively correlated with the real-time load status. The higher the real-time load status, the larger the height coordinate value. The lower the real-time load status, the smaller the height coordinate value. A three-dimensional dynamic agent field is generated based on the planar and height coordinates of each edge IoT agent.

4. The communication maintenance method based on edge IoT agent according to claim 1, characterized in that, The step of setting up an operation and maintenance stabilization plane at the bottom of the three-dimensional dynamic agent field, and selecting the execution edge IoT agent based on the operation and maintenance stabilization plane and operation and maintenance requirements, is as follows: The cloud-based maintenance platform collects historical load status data of all edge IoT agents within a preset period, performs statistical analysis on the historical load status data, and generates a statistical baseline load. The statistical baseline load is mapped to the height position of the operation and maintenance stability plane, and the operation and maintenance stability plane is generated in the three-dimensional dynamic agent field. The operation and maintenance stability plane is used to define the ideal operation and maintenance state of the edge IoT agent. The overall distance from each edge IoT agent to the operation and maintenance stable plane is calculated as the stability. The stability is generated by weighting the vertical distance, the speed of movement in the height coordinate, and the historical reliability. Among them, the vertical distance is the difference between the current height coordinates of the edge IoT agent and the operation and maintenance stable plane, the height coordinate movement speed is the speed at which the height coordinates of the edge IoT agent change, and the historical reliability is generated by weighting the success rate, average response time and number of failures of the edge IoT agent in the past. When communication maintenance tasks need to be performed, the target area of ​​the task is determined according to the operation and maintenance requirements, and the edge IoT agent with the highest stability is selected as the execution edge IoT agent within the vicinity of the target area.

5. The communication maintenance method based on edge IoT agent according to claim 1, characterized in that, The steps by which the cloud-based maintenance platform securely encapsulates maintenance commands and sends them to the edge IoT agent are as follows: The cloud-based maintenance platform breaks down maintenance instructions into multiple data shards, each of which does not contain complete instruction information. The cloud maintenance platform sends multiple data fragments to the execution edge IoT agent through multiple independent communication paths. These multiple independent communication paths are selected from any combination of cellular networks from different operators, fiber optic networks with different physical routes, and multi-hop communication paths forwarded by different neighboring edge IoT agents. The edge IoT agent receives and reassembles multiple data fragments to obtain a complete maintenance instruction, calculates the hash value of the complete maintenance instruction, and returns the hash value as a commitment to the cloud maintenance platform. The cloud maintenance platform publishes the data to be verified after a random delay. The data to be verified includes complete maintenance instructions and the shard hash values ​​corresponding to each of the multiple data shards.

6. The communication maintenance method based on edge IoT agent according to claim 5, characterized in that, The steps for supervising the transmission process of maintenance instructions through a multi-party verification mechanism are as follows: The cloud-based maintenance platform constructs an independent virtual verification space and generates multiple edge IoT agents based on the stable operation and maintenance plane, serving as candidate verifiers. The cloud-based maintenance platform randomly selects multiple edge IoT agents from the candidate verifiers to enter the virtual verification space and discloses the data to be verified to the verifiers. Each verifier calculates the publicly available data to be verified on the cloud maintenance platform and compares it with the commitment returned by the execution edge IoT agent. If they are inconsistent, the execution edge IoT agent is marked as a suspected execution edge IoT agent. At the same time, the verifier sends a challenge request to each forwarding node on multiple independent communication paths. The challenge request requires the forwarding node to provide proof of the sending and receiving records, including timestamps, identifiers of both the sender and receiver, and hash values ​​of the data fragments forwarded. All verifiers publicly present their collected send and receive records in the virtual verification space, and jointly cross-compare all the proofs to identify any contradictory records. Among them, conflicting records include time record conflicts of the same forwarding node on different communication paths, mismatch of send and receive records between adjacent forwarding nodes, and inconsistent hash values ​​of the same data fragment on different communication paths. The verifier identifies the relevant forwarding nodes in the virtual verification space based on the identified contradictory records, marks the forwarding node as a suspected edge IoT agent, and records the basis for the identification. After multiple rounds of questioning and identification, the verifiers collectively vote in the virtual verification space to generate a consistent judgment on the suspected edge IoT agent. The conflict records, identification evidence, and consistency judgments are packaged to generate verification results and reported to the cloud maintenance platform.

7. The communication maintenance method based on edge IoT agent according to claim 6, characterized in that, The steps for executing maintenance commands with normal verification results via the edge IoT agent, and for cloud maintenance platforms parsing verification results with abnormal results to generate an anomaly report and performing troubleshooting operations are as follows: After confirming that the maintenance command has passed multiple verifications, the edge IoT agent executes the corresponding operation and feeds back the execution result to the cloud maintenance platform. For verification results that are found to be abnormal, the cloud maintenance platform analyzes the verification results and extracts contradictory records and evidence for identification. The cloud-based maintenance platform locates the communication path and node position where the anomaly occurred based on the conflict records and identification evidence, and determines the anomaly type, which includes data fragmentation and tampering, promise forgery, node offline, and malicious node behavior; Integrate verification results and exception types into an exception report; Based on the anomaly report, suspected edge IoT agents and suspected execution edge IoT agents are marked in the 3D dynamic agent field, their height coordinates are forcibly reduced to below the operation and maintenance stable plane, their communication permissions are cut off, and maintenance instructions are resent.

8. A communication maintenance system based on an edge IoT agent, used to implement the communication maintenance method based on an edge IoT agent as described in any one of claims 1-7, characterized in that, include: Data acquisition module: Collects real-time proxy data from edge IoT agents and preprocesses the real-time proxy data; Agent field construction module: Connected to the data acquisition module, it constructs a three-dimensional dynamic agent field for the communication network based on real-time agent data in the cloud maintenance platform; Stable plane construction module: Connected to the agent field construction module, it sets up an operation and maintenance stable plane at the bottom of the three-dimensional dynamic agent field, and selects to execute the edge IoT agent based on the operation and maintenance stable plane and operation and maintenance requirements; Security verification module: Connected to the stable plane construction module, the cloud maintenance platform securely encapsulates maintenance commands and sends them to the execution edge IoT agent. It also supervises the transmission process of maintenance commands through a multi-party verification mechanism and generates verification results. Command execution module: Connected to the security verification module, it executes maintenance commands with normal verification results from the edge IoT agent. The cloud maintenance platform parses verification results with abnormal results, generates an anomaly report, and performs troubleshooting operations.

Images