An internet of things network adaptive topology visualization method based on signal quality evaluation

Abstract

The application provides a kind of based on signal quality evaluation's internet of things network adaptive topology visual method, it is related to data processing field.In the method, the signal quality data in internet of things network, service transmission load and link confirmation record are acquired, and node link data is formed;Real connection link and predicted recovery link are identified based on node link data, and recovery credible state is determined according to historical recovery state, mobile trend and signal change, and predicted recovery link is managed hierarchically;Hierarchical topology data is constructed to generate initial topology visual result, link state is updated by bidirectional communication verification, and risk area is identified in combination with updated node link data, link weakening, scheduling restriction and detection frequency reduction processing are executed, and adaptive topology visual result is generated.Implementation of the technical solution facilitates to improve the accuracy of internet of things network adaptive topology visual result.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and specifically to an adaptive topology visualization method for Internet of Things (IoT) networks based on signal quality assessment. Background Technology

[0002] As IoT communication networks evolve towards large-scale, multi-node, and highly dynamic architectures, an increasing number of IoT networks are adopting link prediction mechanisms to predict network topology in advance, thereby improving network topology continuity and link recovery response capabilities. In existing technologies, some systems predict potentially recoverable links based on historical communication trajectories, historical signal change states, and node movement trends, and pre-reserve the corresponding predicted connections in the topology visualization interface, thus avoiding frequent topology changes caused by short-term link fluctuations. However, existing technologies typically only retain predicted links based on historical recovery behavior or short-term signal recovery, lacking a continuous verification mechanism for the actual recovery status of the predicted links. This results in some predicted links that have been invalid for a long time or no longer have the conditions for recovery still being retained in the topology.

[0003] Especially in mobile IoT networks, edge collaborative networks, and complex wireless communication environments, the location changes of IoT nodes, channel interference, and changes in service transmission load are all highly dynamic. Although some predicted links have a history of recovery, they are difficult to re-establish stable communication in the current network environment. However, existing topology visualization systems still treat these predicted links as potential available paths in topology display and network scheduling, causing subsequent routing selection, service transmission load migration, and local topology expansion to continuously concentrate in the corresponding areas, leading to erroneous topology expansion in local areas. When a large amount of service transmission load continues to concentrate near unrecovered links, it can also easily cause excessive occupation of the communication resources of actual connected links, further triggering local traffic congestion, link congestion, and abnormal fluctuations in topology.

[0004] Therefore, how to avoid the long-term retention of predicted links that induces erroneous topology expansion and reduce the misleading impact of predicted links on network scheduling and topology visualization results has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides an adaptive topology visualization method for IoT networks based on signal quality assessment, which helps to avoid erroneous topology expansion induced by the long-term retention of predicted links, reduces the misleading impact of predicted links on network scheduling and topology visualization results, and improves the accuracy of adaptive topology visualization results for IoT networks.

[0006] The first aspect of this application provides an adaptive topology visualization method for IoT networks based on signal quality assessment. The method includes the following steps: S110, acquiring real-time signal quality data, service transmission load, and link confirmation records corresponding to each IoT node in the IoT network to form node link data; S120, identifying candidate connection relationships between IoT nodes based on the node link data, and dividing the candidate connection relationships into real connection links and predicted recovery links; S130, determining the recovery reliability state corresponding to the predicted recovery link based on the historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend, and the communicable status of adjacent real connection links, and dividing the predicted recovery link into unverified predicted recovery links and restricted predicted recovery links based on the recovery reliability state. And failure prediction and recovery links; S140, construct hierarchical topology data based on real connection links, prediction recovery links to be verified, restricted prediction recovery links, and failure prediction recovery links, and generate initial adaptive topology visualization results based on the hierarchical topology data; S150, perform bidirectional communication verification on the prediction recovery links to be verified based on the initial adaptive topology visualization results, update the recovery trust status corresponding to the prediction recovery links to be verified, and perform link type conversion on the prediction recovery links to be verified based on the updated recovery trust status to obtain updated node link data; S160, identify risk areas based on the updated node link data, and perform display weakening, scheduling restriction, and detection frequency reduction processing on the prediction recovery links to be verified and restricted prediction recovery links based on the risk areas to generate IoT network adaptive topology visualization results.

[0007] A second aspect of this application provides an adaptive topology visualization device for IoT networks based on signal quality assessment. The device includes an acquisition module and a processing module: the acquisition module acquires real-time signal quality data, service transmission load, and link confirmation records corresponding to each IoT node in the IoT network to form node link data; the processing module identifies candidate connection relationships between IoT nodes based on the node link data and divides these candidate connections into real connection links and predicted recovery links; the processing module further determines the recovery reliability status of the predicted recovery link based on its historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend, and the communicability status of adjacent real connection links, and classifies the predicted recovery link into unverified predicted recovery links and restricted predicted recovery links based on the recovery reliability status. The processing module is also used to construct hierarchical topology data based on real connection links, predicted recovery links to be verified, restricted predicted recovery links, and failed predicted recovery links, and generate initial adaptive topology visualization results based on the hierarchical topology data; the processing module is also used to perform bidirectional communication verification on the predicted recovery links to be verified based on the initial adaptive topology visualization results, update the recovery trust status corresponding to the predicted recovery links to be verified, and perform link type conversion on the predicted recovery links to be verified based on the updated recovery trust status to obtain updated node link data; the processing module is also used to identify risk areas based on the updated node link data, and perform display weakening, scheduling restriction, and detection frequency reduction processing on the predicted recovery links to be verified and restricted predicted recovery links based on the risk areas to generate adaptive topology visualization results for the IoT network.

[0008] A third aspect of this application provides an electronic device, which includes a processor and a memory; the memory stores a computer program, wherein the computer program, when executed by the processor, implements the above-described method for adaptive topology visualization of Internet of Things networks based on signal quality assessment.

[0009] In a fourth aspect of this application, a non-transitory computer-readable storage medium is provided, which stores instructions that, when executed, perform the above-described method for adaptive topology visualization of Internet of Things networks based on signal quality assessment.

[0010] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: By uniformly aligning real-time signal quality data, service transmission load, and link acknowledgment records in a unified time frame, node link data is formed. Based on this data, candidate connections are categorized into real connection links and predicted recovery links, thereby improving the accuracy of network link identification. Furthermore, this application combines historical disconnection duration, historical recovery records, current movement direction, current signal quality change trends, and the communicability status of adjacent real connection links to determine the reliable recovery status. Predicted recovery links are then categorized into unverified predicted recovery links, restricted predicted recovery links, and failed predicted recovery links, achieving differentiated management of predicted links. Subsequently, by constructing hierarchical topology data and performing bidirectional communication verification, the reliable recovery status and link type are dynamically updated, preventing long-term failed links from persisting in the topology. Simultaneously, risk areas are formed by identifying the degree of repetition of connection targets, the concentration of spatial distribution, and the aggregation of service transmission load. Links within these risk areas undergo explicit weakening, scheduling restrictions, and probe frequency reduction processing, effectively preventing the long-term retention of predicted links from inducing erroneous topology expansion, reducing the misleading impact of predicted links on network scheduling and topology visualization results, and improving the accuracy of adaptive topology visualization results for IoT networks. Attached Figure Description

[0011] Figure 1 A flowchart illustrating an IoT network adaptive topology visualization method based on signal quality assessment, provided in an embodiment of this application; Figure 2 A schematic diagram of a module for an IoT network adaptive topology visualization device based on signal quality assessment, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0012] Explanation of reference numerals in the attached figures: 21. Acquisition module; 22. Processing module; 31. Processor; 32. Communication bus; 33. User interface; 34. Network interface; 35. Memory. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0014] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0015] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. In addition, the terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0016] To address the aforementioned technical problems, this application provides an adaptive topology visualization method for IoT networks based on signal quality assessment, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an IoT network adaptive topology visualization method based on signal quality assessment, provided in an embodiment of this application. The method is applied to a server and includes steps S110 to S160, as follows: S110. Obtain real-time signal quality data, service transmission load, and link confirmation records corresponding to each IoT node in the IoT network to form node link data.

[0017] Specifically, after receiving real-time signal quality data, service transmission load, and link acknowledgment records uploaded by each IoT node, the server first appends a node identifier, a link identifier, and a collection time to each uploaded data entry. The node identifier uniquely identifies the IoT node to which the uploaded data belongs and can be generated from the IoT node's device number, communication address, or network registration number. The link identifier uniquely identifies the communication link between two IoT nodes and can be generated by combining the node identifiers of the IoT node initiating the communication and the IoT node responding to the communication. The collection time indicates the time when the data was generated on the IoT node side, rather than the time when the server received the data, thus avoiding network transmission delays affecting subsequent time alignment. Real-time signal quality data may include received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication latency changes. Service transmission load may include the amount of data to be sent, buffer queue occupancy status, forwarded data amount, number of forwarding failures, and number of service packets. The link acknowledgment record may include the acknowledgment request sending time, acknowledgment response return time, acknowledgment result, number of consecutive successful acknowledgments, and number of consecutive failed acknowledgments.

[0018] After completing node identification, link identification, and data acquisition time appending, the server performs classification and merging processing on real-time signal quality data, service transmission load, and link acknowledgment records based on the node and link identifications. Classification and merging processing means placing data belonging to the same IoT node and the same link identification into the same dataset, enabling subsequent analysis of the signal status, service status, and acknowledgment status of that link within the same time period. For example, under the same link identification, real-time signal quality data reflects whether the link currently has communication capabilities, service transmission load reflects whether there is congestion pressure on related IoT nodes, and link acknowledgment records reflect whether the link has completed two-way communication acknowledgment. Through classification and merging processing, the server no longer processes single signal strengths or single acknowledgment results in isolation, but rather organizes multiple types of data under the same link identification into a dataset that can be aligned, analyzed, and traced.

[0019] The server maps the merged real-time signal quality data, service transmission load, and link confirmation records to the corresponding unified acquisition period based on the acquisition time. The unified acquisition period is a standard time interval set by the server for topology analysis, such as every second, every five seconds, or every ten seconds. The time window is the data allocation range set around the unified acquisition period, used to accommodate slight time deviations caused by sampling clock errors and upload delays on the IoT node side. The server determines which unified acquisition period each piece of data should belong to based on its acquisition time and merges data falling within the same time window into data of the same period. The unified acquisition period can be determined according to the following expression:

[0020] in, Indicates the first A unified data collection cycle; This indicates the start time for time alignment set by the server, which can be the system startup time, the topology monitoring task startup time, or midnight of the current day. The sequence number represents the unified collection cycle and is determined based on the interval between the data collection time and the time alignment start time. The period length of the unified data collection cycle is determined by the topology refresh frequency of the IoT network and the data reporting frequency of the IoT nodes.

[0021] When the collection time of a data piece is At that time, the server can determine its corresponding unified collection cycle number based on the collection time:

[0022] in, Indicates the collection time as The unified collection cycle number corresponding to the data; This indicates the collection time corresponding to real-time signal quality data, service transmission load, or link confirmation records, which is written by the IoT node when the data is generated; Indicates the start time of time alignment; Indicates the period length of the unified data collection cycle; This indicates rounding down to the nearest integer.

[0023] When the server performs periodic merging on data falling within the same time window, it needs to handle situations where the same link identifier may be reported multiple times within the same unified collection period. For real-time signal quality data, statistical results of multiple sampled values ​​can be retained, such as the average state, minimum state, and changing state of received signal strength; for service transmission load, the number of service packets and forwarding failures can be accumulated, and the peak value of the buffer queue occupancy state can be retained; for link acknowledgment records, successful acknowledgment results, failed acknowledgment results, and acknowledgment response return time can be retained. Periodic merging is not simply overwriting data, but rather combining multiple data segments that can describe the link state within the same time window into a single periodic state, so that this periodic state can reflect both the overall level of the link and retain abnormal fluctuations in the link. The received signal strength after periodic merging can be represented by the following expression:

[0024] in, Link identifier In the The average received signal strength within a uniform acquisition period; Link identifier In the The number of received signal strength samples obtained within a unified acquisition period is obtained by statistically analyzing the sampled data that fall within the same time window and belong to the same link identifier. Link identifier In the Within the first unified collection cycle Each received signal strength sample value is obtained from real-time signal quality data uploaded by the IoT node; Indicates the sampling sequence number.

[0025] For real-time signal quality data, service transmission load, and link acknowledgment records under the same link identifier, the server performs association alignment processing to form link status association data corresponding to the same link identifier within the same collection period. Association alignment processing refers to binding real-time signal quality data, service transmission load, and link acknowledgment records under the same link identifier, within the same unified collection period, into a set of link status data. This allows the server to simultaneously determine whether the link's signal has deteriorated, whether the service is congested, and whether acknowledgment has failed. For example, when a decrease in received signal strength, an increase in buffer queue occupancy, and a failed acknowledgment response occur under the same link identifier, the server can identify this status as a communication anomaly within the current unified collection period, rather than treating the three types of status as isolated, unrelated events. Link status association data can be represented in the following form:

[0026] in, Link identifier In the Link status associated data within a unified collection cycle; Represents IoT nodes IoT nodes Link identifier between; Indicates the first A unified data collection cycle; Link identifier In the A set of real-time signal quality data within a unified acquisition period consists of received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication delay variation status. Link identifier The associated IoT node is at the The set of service transmission load within a unified collection period consists of the amount of data to be sent, the status of the buffer queue, the amount of data already forwarded, the number of forwarding failures, and the number of service packets. Link identifier In the The set of link confirmation records within a unified collection period consists of the confirmation request sending time, confirmation response return time, confirmation result, number of consecutive successful confirmations, and number of consecutive failed confirmations. This indicates a missing data marker, used to indicate whether real-time signal quality data, service transmission load, or link confirmation records are missing within the unified collection period.

[0027] When the confirmation request sending time and confirmation response return time in the link confirmation record fall within different acquisition periods, the server performs period assignment correction on the link confirmation record based on the confirmation request sending time. The confirmation request sending time is the time when the communication initiating IoT node sends the confirmation request, and the confirmation response return time is the time when the communication initiating IoT node receives the confirmation response. In cases of high network latency or short acquisition periods, the confirmation request sending time may fall within the current unified acquisition period, while the confirmation response return time may fall within the next unified acquisition period. If the link confirmation record is directly assigned based on the confirmation response return time, the real-time signal quality data in the current unified acquisition period will not match the corresponding confirmation result, resulting in link state misalignment. Therefore, the server assigns the link confirmation record to the unified acquisition period corresponding to the confirmation request sending time and associates the communication latency change state corresponding to the confirmation response return time with that unified acquisition period. Communication latency can be represented by the following expression:

[0028] in, Link identifier In the Communication latency within a unified data collection cycle; Link identifier In the The confirmation request sending time within a unified collection cycle is recorded when the communication-initiating IoT node sends the confirmation request; Link identifier The corresponding confirmation response return time is recorded by the IoT node that initiated the communication when it receives the confirmation response returned by the IoT node that responded to the communication. This indicates the unified collection cycle number determined based on the confirmation request sending time.

[0029] When performing periodic attribution correction, the server can also use the attribution function to determine the unified collection period to which the link confirmation record should be assigned:

[0030] in, Indicates link confirmation record The corresponding unified collection cycle number; Link identifier The corresponding link confirmation record; This indicates the time the confirmation request was sent in the confirmation record of this link, which is recorded by the IoT node that initiated the communication; Indicates the start time of time alignment; This indicates the cycle length of the unified data collection period.

[0031] After time alignment, the server generates node link data based on the same link identifier, real-time signal quality data under the same unified acquisition period, service transmission load, and link acknowledgment records. Node link data is the foundation for subsequent identification of candidate connections, classification of actual connected links, and prediction of recoverable links. It includes at least the node identifier, link identifier, unified acquisition period, real-time signal quality data, service transmission load, link acknowledgment records, communication latency change status, and data missing markers. Data missing markers indicate whether real-time signal quality data, service transmission load, or link acknowledgment records are missing within a given unified acquisition period. The server can use these markers to avoid misjudging link disconnection due to missing data when subsequently determining link status. Node link data can be represented by the following expression:

[0032] in, Indicates the first Node link data corresponding to a unified collection cycle; Link identifier In the Link status associated data within a unified collection cycle; Indicates the first The set of link identifiers identified by the server within a unified collection period is obtained by deduplicating the link identifiers in all uploaded data within that period. and Representing link identifiers respectively Node identifiers of the IoT nodes at both ends; Indicates the first The set of IoT nodes that participate in data reporting or link confirmation within a unified collection cycle is obtained by deduplicating the node identifiers in all uploaded data within that cycle.

[0033] S120. Identify candidate connection relationships between IoT nodes based on node link data, and divide the candidate connection relationships into real connection links and predicted recovery links.

[0034] Specifically, after obtaining node link data, the server first searches based on the link identifier in the node link data to extract real-time signal quality data, service transmission load, and link acknowledgment records between corresponding IoT nodes under the same link identifier. The link identifier uniquely represents the communication relationship between two IoT nodes; the real-time signal quality data represents the wireless communication quality of this relationship within the current collection period; the service transmission load represents the service carrying capacity of the IoT nodes associated with this communication relationship within the current collection period; and the link acknowledgment record indicates whether acknowledgment requests and responses have occurred between the two IoT nodes. The server determines whether a candidate connection relationship exists between the corresponding IoT nodes based on the link acknowledgment record. When the link acknowledgment record contains acknowledgment request sending records, acknowledgment response return records, or continuous acknowledgment history records, it indicates that at least a verifiable or traceable communication relationship exists between the corresponding IoT nodes. The server then identifies the two IoT nodes corresponding to the link identifier as having a candidate connection relationship. A candidate connection relationship does not directly indicate that the link is stable and available, but rather that the link has the basis for subsequent communication availability judgment and link type classification. A candidate connection relationship can be judged using the following expression:

[0035] in, Link identifier In the Whether candidate connections are formed within a unified collection period, when When a candidate connection is formed, This indicates that no candidate connection has been formed; Represents IoT nodes IoT nodes The link identifier between the IoT nodes is generated by combining the node identifier of the IoT node initiating the communication and the node identifier of the IoT node responding to the communication. Link identifier In the The set of link confirmation records within a unified collection period consists of the confirmation request sending time, confirmation response return time, confirmation result, number of consecutive successful confirmations, and number of consecutive failed confirmations. This represents an empty set.

[0036] After identifying candidate connections, the server further determines whether the candidate connections meet the communication availability conditions based on real-time signal quality data and service transmission load. Communication availability conditions refer to the fact that the candidate connection has basic signal transmission capability within the current acquisition period, and is not in a significant congestion state due to excessive service transmission load. Specifically, the server uses received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication latency changes as signal-side judgment criteria, and uses the amount of data to be sent, buffer queue occupancy status, forwarded data amount, forwarding failure count, and service packet count as load-side judgment criteria. When the real-time signal quality data corresponding to the candidate connection does not reach a severely degraded state, and the service transmission load does not reach a congestion state, the server retains the candidate connection as a valid candidate connection. A valid candidate connection indicates that the candidate connection still has the conditions to continue to be judged as a real connection link or a predicted recovery link, rather than an invalid link that should have been excluded. The communication availability state can be determined using the following expression:

[0037] in, Link identifier In the Whether the communication availability conditions are met within a unified data collection period, when When the condition for communication availability is met, This indicates that the conditions for communication availability are not met; Link identifier In the The signal quality evaluation value within a unified acquisition period is obtained by comprehensively considering the received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication delay variation status. This represents the minimum signal quality threshold that allows a connection to be retained as a valid candidate connection, and is set by network management policies, communication protocol requirements, or historical stable link statistics. Link identifier The associated IoT node is at the The service transmission load evaluation value within a unified collection period is obtained by comprehensively considering the amount of data to be sent, the status of the buffer queue, the amount of data already forwarded, the number of forwarding failures, and the number of service packets. This represents the highest service transmission load threshold that is allowed to be retained as a valid candidate connection, determined by the IoT node's buffer capacity, link forwarding capability, and network congestion control strategy. This represents a conditional function. The value is 1 when the condition inside the parentheses is true, and 0 when the condition inside the parentheses is false.

[0038] Signal quality evaluation values ​​can be obtained by normalizing and synthesizing multiple real-time signal quality data, allowing different types of real-time signal quality data to enter the same communication availability judgment process. The server can first obtain the link identifiers separately. In the The received signal strength, signal-to-noise ratio (SNR), packet loss status, retransmission status, and communication delay variation status within a unified acquisition period are then used to generate a signal quality evaluation value according to preset weights. Higher received signal strength and SNR generally indicate better basic link signal conditions; higher packet loss, retransmission, and communication delay variation statuses generally indicate poorer link transmission stability. Therefore, they need to be processed separately as positive and negative indicators during the synthesis process. The signal quality evaluation value can be expressed using the following formula:

[0039] in, Link identifier In the Signal quality evaluation value within a unified acquisition cycle; The normalized received signal strength is represented by the link identifier. In the The received signal strength within a unified acquisition period is obtained by normalizing the range of historical received signal strength. The normalized signal-to-noise ratio is obtained by normalizing the current signal-to-noise ratio with the historical signal-to-noise ratio range. This indicates the normalized packet loss status, which is obtained by counting the number of verification requests, the number of business packets, and the number of unsuccessful returns. This indicates the normalized retransmission status, which is obtained by counting the number of data packets repeatedly sent within the same acquisition period. It represents the normalized communication latency change state, which is obtained by normalizing the difference between the confirmation request sending time and the confirmation response return time and the historical communication latency range; These represent the weighting coefficients corresponding to received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication delay change status, respectively. Each weighting coefficient is set by the network management strategy, and the sum of all weighting coefficients is 1.

[0040] After obtaining valid candidate connections, the server performs a preliminary link type classification based on the confirmation results, consecutive successful confirmations, consecutive failed confirmations, and confirmation response stability in the link confirmation record. The confirmation result indicates whether a bidirectional communication confirmation has been completed within the current acquisition period. The consecutive successful confirmations indicate the continuity of the confirmation response across multiple adjacent acquisition periods. The consecutive failed confirmations indicate the duration of the failure to complete a confirmation response across multiple adjacent acquisition periods. The confirmation response stability indicates whether there are sudden increases in latency, intermittent returns, or abnormal return order in the confirmation response. The server uses this information to determine whether the valid candidate connection is closer to a stable and available state or closer to a predicted recovery state. The confirmation response stability can be determined using the following expression:

[0041] in, Link identifier In the The stability of the confirmation response within a unified data collection cycle; Link identifier In recent The communication latency within a unified collection period is calculated from the confirmation request sending time and the confirmation response return time. This indicates the number of cycles used to evaluate the stability of the confirmation response, and is set by the topology refresh sensitivity and link stability requirements; This indicates the standard deviation calculation, used to reflect the degree of fluctuation in communication latency over multiple recent unified data collection periods; Indicates recent The average communication latency within a unified collection period; This represents a correction parameter to prevent the denominator from being zero. It can be a very small positive number, such as 0.2.

[0042] When a valid candidate connection completes bidirectional communication confirmation within the current acquisition period and maintains continuous confirmation responses across multiple adjacent acquisition periods, while the corresponding packet loss status, retransmission status, and communication latency change status do not exhibit persistent anomalies, the server classifies the valid candidate connection as a real connection link. Bidirectional communication confirmation refers to the initiating IoT node sending a confirmation request to the responding IoT node and receiving a confirmation response from the responding IoT node; continuous confirmation responses refer to the bidirectional communication confirmation occurring continuously across multiple adjacent acquisition periods; persistent anomalies refer to packet loss status, retransmission status, or communication latency change status continuously exceeding the allowable range across multiple adjacent acquisition periods. A real connection link represents a link that has completed bidirectional confirmation and possesses stable transmission capabilities, and it can subsequently enter the main connection layer in the hierarchical topology data.

[0043] When a valid candidate connection has formed a real connection link within a historical collection period, and no anomalies occur in the current collection period, the server classifies the valid candidate connection relationship as a predicted recovery link. Here, the historical collection period refers to one or more unified collection periods prior to the current collection period; "formed a real connection link" means that the valid candidate connection relationship met the criteria for a real connection link within a historical collection period; "no anomalies occur in the current collection period" means that there are no instances of continuous packet loss, continuous retransmission, sudden increases in communication latency, excessively high service transmission load, or complete absence of link acknowledgment records within the current collection period. A predicted recovery link indicates that the link has not yet met the stable acknowledgment requirements of a real connection link, but because it has historically existed and no obvious anomalies have occurred currently, it is retained as a potentially recoverable link. The predicted recovery link can be determined using the following expression:

[0044] in, Link identifier In the Whether it is classified as a predictive recovery link within a unified collection cycle, when The time indicates that it is classified as a predictive recovery link; This indicates the number of historical backtracking cycles, which needs to be set for link recovery analysis. Link identifier In the Whether it was ever classified as a real connection link within a unified collection period; Indicates the period before the current collection cycle. The number of times a real connection link is formed within a historical data collection period; This indicates that the valid candidate connection relationship has not yet been classified as a real connection link in the current collection period; Link identifier In the Whether any abnormalities occur within a unified data collection period, when This indicates that there are no abnormalities in the current data collection cycle. This indicates an anomaly in the current data collection cycle.

[0045] Whether an anomaly has occurred in the current acquisition period can be determined by combining real-time signal quality data, service transmission load, and link confirmation records. The server can use packet loss status, retransmission status, communication latency change status, service transmission load evaluation value, and the number of consecutive confirmation failures as the basis for anomaly judgment; when any of the above statuses exceeds the corresponding threshold, and the anomaly continues to reach a preset number of periods, it is determined that an anomaly has occurred in the current acquisition period.

[0046] After classifying valid candidate connections into predictive recovery links, the server performs a recovery trend assessment on the predictive recovery links based on the current movement direction and deployment location changes of the corresponding IoT nodes. The current movement direction indicates the direction of position change of the IoT nodes at both ends of the predictive recovery link within the current acquisition period, and can be obtained from the IoT node's positioning data, inertial measurement data, gateway positioning results, or deployment location update records. The deployment location change indicates whether the relative distance between the two IoT nodes has shortened, remained stable, or increased. If the relative distance between the two IoT nodes shortens or remains stable, and the real-time signal quality data does not continuously deteriorate, it indicates that the predictive recovery link still has a recovery trend. If the relative distance between the two IoT nodes continuously increases, and no confirmation response is received for several consecutive acquisition periods, it indicates that the predictive recovery link lacks a basis for recovery.

[0047] When the server performs a recovery trend assessment on the predicted recovery link, it can combine the relative distance change, the current signal quality change trend, and the confirmation response result to form a recovery trend status. The current signal quality change trend can be determined based on the changes in signal quality evaluation values ​​in adjacent acquisition cycles. If the signal quality evaluation value continues to increase, it indicates that the signal quality has a recovery trend; if the signal quality evaluation value continues to decrease, it indicates that the signal quality continues to deteriorate.

[0048] When a predicted recovery link fails to receive a confirmation response for multiple consecutive acquisition cycles, and the corresponding IoT node continues to move away, the server removes the candidate connection from the predicted recovery link set. "Failed to receive a confirmation response for multiple consecutive acquisition cycles" means that the number of consecutive confirmation failures in the link confirmation record reaches a preset removal condition; "the corresponding IoT node continues to move away" means that the relative distance between the two IoT nodes continuously increases over multiple adjacent acquisition cycles. The removal process does not delete all historical records, but rather removes the candidate connection from the current predicted recovery link set and saves it as a historical link record to prevent it from continuing to participate in subsequent recovery trusted state calculations, hierarchical topology data display, and risk area identification.

[0049] S130. Based on the historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend, and the communicable status of adjacent real connection links corresponding to the predicted recovery link, determine the recovery credibility status corresponding to the predicted recovery link, and divide the predicted recovery link into a predicted recovery link to be verified, a limited predicted recovery link, and a failed predicted recovery link according to the recovery credibility status.

[0050] Specifically, the server retrieves link status records for the same link identifier from historical node link data prior to the current acquisition period, based on the link identifier corresponding to the predicted recovery link, and extracts historical recovery records from the link status records. The link identifier uniquely identifies a predicted recovery link. Historical node link data refers to the node link data that the server has generated and saved within the historical acquisition period. Historical recovery records describe the historical process of the predicted recovery link recovering from a disconnected state to a truly connected link. Specifically, this includes the historical disconnection start time, historical disconnection end time, number of successful historical recoverys, number of failed historical recoverys, number of consecutive unconfirmed recoveries, the time of the most recent recovery, and the stable holding time after the most recent recovery. The historical disconnection duration can be determined based on the difference between the time when the predicted recovery link most recently changed from a truly connected link to an unconfirmed state and the current acquisition period time. The calculation expression is as follows:

[0051] in, Link identifier In the The corresponding historical disconnection duration within each collection cycle; Represents IoT nodes IoT nodes The link identifier between the two IoT nodes is obtained by combining the node identifiers of the two IoT nodes. Indicates the first The current cycle time corresponding to each collection cycle can be the start time or the center time of that collection cycle; Link identifier The time when a link changed from a real connection to an unconfirmed state was obtained from the link type change record in the historical node link data.

[0052] The server can also determine the historical recovery stability of the predicted recovery link based on the number of successful and failed historical recovery attempts. The number of successful historical recovery attempts refers to the number of times the predicted recovery link was reverted to a real connection link during the historical data collection period. The number of failed historical recovery attempts refers to the number of times the predicted recovery link failed to be reverted to a real connection link or was downgraded to a failed predicted recovery link after recovery assessment during the historical data collection period. The historical recovery stability reflects the reliability of the predicted recovery link's past recovery behavior.

[0053] The server determines the current signal quality trend of the predicted recovery link based on real-time signal quality data from the current and historical acquisition periods. Real-time signal quality data can include received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication latency variation. The current signal quality trend indicates whether the communication quality of the predicted recovery link is gradually improving, remaining relatively stable, or continuously deteriorating relative to historical acquisition periods. The server can first obtain the signal quality evaluation value for each acquisition period based on real-time signal quality data from the current and several historical acquisition periods, and then compare the changes in the signal quality evaluation value between the current and historical acquisition periods. The expression for calculating the signal quality evaluation value is:

[0054] in, Link identifier In the Signal quality evaluation value within each acquisition cycle; Represents the normalized received signal strength, derived from the first... The received signal strength of the predicted recovery link within each acquisition period is obtained by normalizing the historical received signal strength range. Represents the normalized signal-to-noise ratio, derived from the first... The signal-to-noise ratio of the predicted recovery link within each acquisition cycle is obtained by normalizing the historical signal-to-noise ratio range. Represents the normalized packet loss state, from the first... The number of data packets that failed to return successfully within each collection cycle is obtained by statistically analyzing the number of data packets sent. Represents the normalized retransmission state, from the first... The number of retransmitted data packets and the number of sent data packets within each collection period are obtained by statistical analysis. Represents the normalized communication delay variation state, by the first The difference between the confirmation response return time and the confirmation request sending time within each collection cycle is obtained by normalization. These represent the weighting coefficients corresponding to received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication delay change status, respectively. Each weighting coefficient is set by the network management strategy, and the sum of all weighting coefficients is 1.

[0055] After obtaining the signal quality evaluation values ​​for the current acquisition period and historical acquisition periods, the server determines the current signal quality change trend. This trend is not an instantaneous change within a single acquisition period, but rather the direction of change relative to multiple historical acquisition periods. Therefore, it reduces the impact of occasional signal reflections, short-term interference disappearances, or single sampling anomalies on the recovery judgment. The expression for calculating the current signal quality change trend is:

[0056] in, Link identifier In the The trend of current signal quality changes within each acquisition cycle; Link identifier Signal quality evaluation value within the current acquisition period; Link identifier The first time before the current collection cycle Signal quality evaluation value within each acquisition cycle; This represents the number of historical lookback periods used to determine the current signal quality trend, set by the topology refresh rate and link fluctuation characteristics. This expression determines whether the communication quality of the predicted recovery link is recovering by comparing the change magnitude between the current signal quality evaluation value and historical signal quality evaluation values; when... When the value is greater than the preset positive trend threshold, it indicates that the current signal quality change trend shows recovery. When it approaches zero, it indicates that the current signal quality trend is basically stable. When the value is less than the preset negative trend threshold, it indicates that the current signal quality trend is deteriorating.

[0057] The server determines whether the predicted recovery link meets the spatial recovery conditions based on the current movement direction and deployment location changes of the IoT nodes at both ends of the predicted recovery link. The current movement direction refers to the direction of position change of the IoT node relative to the previous collection period within the current collection period, which can be obtained from positioning data, inertial measurement data, gateway positioning results, or deployment location update records. The deployment location change refers to the change in the relative distance between the IoT nodes at both ends of the predicted recovery link. The spatial recovery conditions are used to determine whether the spatial relationship between the two IoT nodes supports link recovery. For example, if the two IoT nodes are close to each other and the relative distance remains stable, or if the relative distance increases slightly but they are still within the communication coverage area, the preset requirements can be considered met. The relative distance between the two IoT nodes can be determined using the following expression:

[0058] in, Represents IoT nodes IoT nodes In the Relative distance within a collection cycle; Representing IoT nodes In the The deployment location coordinates within each collection cycle are obtained from the positioning device, the gateway ranging results, or the deployment location record; Representing IoT nodes In the The deployment location coordinates within each collection cycle are obtained using the same positioning method.

[0059] The server further determines whether the predicted recovery link meets the spatial recovery conditions based on the relative distance change and the current direction of movement. If the relative distance between the two IoT nodes shortens or remains stable, it indicates that the spatial relationship between the two IoT nodes has not continued to deteriorate; if the relative distance continues to increase and exceeds the communication coverage allowable range, it indicates that the recovery probability of the predicted recovery link decreases. The spatial recovery conditions can be determined using the following expression:

[0060] in, Link identifier In the Whether the spatial recovery conditions are met within each acquisition cycle, when When the space restoration condition is met, This indicates that the space recovery conditions are not met; This indicates the relative distance between the two IoT nodes within the current data collection period; This indicates the maximum relative distance that allows effective communication to be established under this communication protocol or application scenario, which is determined by the device's communication capabilities, the gateway's coverage area, or historical stable link statistics. This indicates the relative distance between the two IoT nodes during the previous data collection period; This represents the allowable threshold for relative distance variation. When the two IoT nodes are slightly far apart but communication can still be restored, it can be set to a tolerance value greater than zero. This represents a conditional function. The value is 1 when the condition inside the parentheses is true, and 0 when the condition inside the parentheses is false.

[0061] The server determines the communicability status of adjacent real connection links based on the stability of the confirmation response, service transmission load, and communication latency changes of the IoT nodes at both ends of the predicted recovery link. An adjacent real connection link refers to a link directly connected to either end of the predicted recovery link and currently classified as a real connection link. Confirmation response stability indicates whether the confirmation response of the adjacent real connection link is stable across multiple data collection periods. Service transmission load indicates whether there is congestion pressure on the IoT nodes associated with the adjacent real connection link. Communication latency changes indicate whether there is a sudden increase in the response time of the adjacent real connection link. If the overall communicability status of the adjacent real connection links is good, it indicates that the network environment in the local area where the predicted recovery link is located can still support link recovery. If there is a large-scale anomaly in the adjacent real connection links, it indicates that there may be regional interference or congestion in that local area, and the reliability of the predicted recovery link should be reduced. The communicability status of adjacent real connection links can be determined using the following expression:

[0062] in, Link identifier In the The communicable status of adjacent real connection links within each collection period; Indication and Predictive Recovery Link The set of real connection links between adjacent IoT nodes at both ends is obtained by filtering links that have been classified as real connection links in the hierarchical topology data or node link data within the current collection period; Indicates the number of adjacent physical connection links; Represents any real connection link in the set of adjacent real connection links; Represents the actual connection link In the The stability of the confirmation response within a collection cycle is calculated from the communication latency fluctuations within multiple collection cycles. This indicates the threshold for confirming response stability, which is set according to network stability requirements. Represents the actual connection link In the The service transmission load evaluation value corresponding to each collection period is obtained by comprehensively considering the amount of data to be sent, the status of the buffer queue, the amount of data already forwarded, the number of forwarding failures, and the number of service packets. This represents the service transmission load threshold, which is determined by the IoT node's buffer capacity and link forwarding capability. Represents the actual connection link In the The communication latency within each collection cycle is calculated from the confirmation request sending time and the confirmation response return time. This represents the communication latency threshold, which is determined by communication protocol requirements or historical stable link statistics.

[0063] The server determines the recovery reliability state corresponding to the predicted recovery link based on historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend, and the communicability status of adjacent real connection links. The recovery reliability state represents the degree of confidence that the predicted recovery link will recover from the predicted state to a real connection link. It is not a judgment result of a single indicator, but rather a comprehensive assessment of historical recovery capabilities, current signal recovery level, spatial recovery conditions, and the support capabilities of surrounding links. The server can convert historical disconnection duration into disconnection impact state, historical recovery records into historical recovery stability, current movement direction and deployment location changes into spatial recovery conditions, current signal quality change trend into signal recovery state, and the communicability status of adjacent real connection links into surrounding support status, and then perform a comprehensive evaluation. The recovery reliability state can be determined using the following expression:

[0064] in, Link identifier In the The corresponding recovery reliability status evaluation value within each collection cycle; This represents the normalized duration of historical disconnection, derived from the duration of historical disconnection. The value is obtained by normalization based on the preset maximum disconnection duration; the larger the value, the longer the disconnection lasts. The degree of historical stability recovery is represented by the number of successful historical recovery attempts and the number of failed historical recovery attempts. This represents the spatial recovery condition. The value is higher when the predicted recovery link meets the spatial recovery condition, and lower when the spatial recovery condition is not met. This represents the trend of current signal quality change after normalization, derived from the current signal quality change trend. The value is obtained by normalizing the historical trend range, and the higher the value, the more obvious the signal quality recovery trend. Indicates the communicable status of adjacent real-world links; These represent the weight coefficients corresponding to historical disconnection duration, historical recovery records, spatial recovery conditions, current signal quality change trend, and the communicable status of adjacent real connection links, respectively. Each weight coefficient is determined by network management strategy, application scenario requirements, or statistical results of historical link recovery samples, and the sum of all weight coefficients is 1.

[0065] The server categorizes predicted recovery links into three types based on their recovery trust level: unverified predicted recovery links, restricted predicted recovery links, and failed predicted recovery links. Unverified predicted recovery links are those with a high recovery trust level, suitable for subsequent bidirectional communication verification. Restricted predicted recovery links still have some recovery potential but are not suitable for direct entry into main topology display and network scheduling. Failed predicted recovery links are those with a low recovery trust level and currently lack effective recovery conditions. The server can further categorize these links based on the relationship between the recovery trust level evaluation value and a preset level threshold, expressed as follows:

[0066] in, Link identifier In the The predicted recovery link classification results corresponding to each collection cycle; This indicates the restoration of the trusted state evaluation value; This indicates a high trust threshold, set by the link recovery trust requirement that allows entry into bidirectional communication verification; This indicates a low-trust threshold, set by the minimum recovery trust requirement that allows continued retention as a predicted recovery link, and .

[0067] After the partitioning is completed, the server binds the predicted recovery links to be verified, restricted predicted recovery links, and failed predicted recovery links with their corresponding link identifiers, historical disconnection durations, historical recovery records, current movement direction, current signal quality change trends, the communicable status of adjacent real-world links, and their recovery reliability status, and writes this information back to the node link data. This write-back process allows the server to directly read the classification results of each predicted recovery link when constructing subsequent hierarchical topology data. Specifically, the predicted recovery links to be verified are used to form the subsequent verification observation layer and serve as bidirectional communication verification objects; the restricted predicted recovery links are used to form the subsequent restricted observation layer and serve as local observation objects; and the failed predicted recovery links are used to form the subsequent failure record layer and serve as anomaly tracing objects. Through this implementation process, the server avoids reserving all predicted recovery links as potentially available links, thereby reducing the risk of predicted links that cannot be recovered for extended periods continuing to participate in topology display and network scheduling.

[0068] S140. Construct hierarchical topology data based on real connection links, predicted recovery links to be verified, restricted predicted recovery links, and failed predicted recovery links, and generate initial adaptive topology visualization results based on the hierarchical topology data.

[0069] Specifically, after classifying real connection links, predicted recovery links to be verified, restricted predicted recovery links, and failed predicted recovery links, the server first constructs the main connection layer based on the real connection links. The main connection layer is the data layer in the hierarchical topology data used to express the currently available network structure. It only receives real connection links that have completed bidirectional communication confirmation, have stable continuous confirmation responses, and have not experienced persistent anomalies. The server writes the link identifier corresponding to the real connection link, the node identifiers of the IoT nodes at both ends, the link confirmation record, real-time signal quality data, and the service transmission load into the main connection layer. The link confirmation record proves that the real connection link has completed bidirectional communication confirmation, the real-time signal quality data indicates the current communication quality of the real connection link, and the service transmission load indicates the service carrying status of the IoT nodes associated with the real connection link. The links in the main connection layer can serve as the basic connection structure in the subsequent initial adaptive topology visualization results and can also serve as the main basis for subsequent network scheduling and routing selection. The main connection layer can be represented by the following expression:

[0070] in, Indicates the first The main connection layer within each acquisition cycle; Represents IoT nodes IoT nodes The link identifier between the two IoT nodes is obtained by combining the node identifiers of the two IoT nodes. Link identifier In the The link type within each acquisition cycle is obtained from the previous link partitioning results; Link identifier In the The link confirmation record within each collection period consists of the confirmation request sending time, confirmation response return time, confirmation result, number of consecutive successful confirmations, and number of consecutive failed confirmations. Link identifier In the Real-time signal quality data within each acquisition period consists of received signal strength, signal-to-noise ratio, packet loss status, retransmission status, and communication delay variation status. Link identifier The associated IoT node is at the The service transmission load within each collection cycle consists of the amount of data to be sent, the status of the buffer queue, the amount of data already forwarded, the number of forwarding failures, and the number of service packets. Link identifier In the Link status associated data within each collection cycle.

[0071] The server constructs a verification observation layer based on the predicted recovery link to be verified. This layer, within the hierarchical topology data, represents links with a high probability of recovery but which have not yet achieved stable bidirectional communication confirmation. Its primary function is not to directly participate in network scheduling, but rather to provide verification objects for subsequent bidirectional communication verification. The server writes the link identifier corresponding to the predicted recovery link to be verified, the node identifiers of the IoT nodes at both ends, the recovery trust status, historical disconnection duration, historical recovery records, current signal quality change trend, current movement direction, and the communicable status of adjacent real-connection links into the verification observation layer. The recovery trust status indicates the degree of confidence that the predicted recovery link to be verified has recovered to a real-connection link; the historical disconnection duration indicates the duration for which the predicted recovery link to be verified has left the real-connection link state; the historical recovery records indicate whether the predicted recovery link to be verified has successfully recovered in the past; the current signal quality change trend indicates whether the communication quality is improving; the current movement direction indicates whether the IoT nodes at both ends are approaching or remaining stable; and the communicable status of adjacent real-connection links indicates whether the local area where the predicted recovery link to be verified is located has communication recovery support. The verification observation layer can be represented by the following expression:

[0072] in, Indicates the first Verification observation layer within each acquisition cycle; Link identifier Corresponding link type; Link identifier The corresponding recovery reliability evaluation value is obtained by combining the historical disconnection duration, historical recovery records, current direction of movement, current signal quality change trend, and the communicability status of adjacent real connection links; The duration of historical disconnection is represented by the difference between the current data collection cycle time and the most recent disconnection time. This indicates the stability of historical recovery corresponding to the historical recovery record, and is obtained by counting the number of successful historical recovery and the number of failed historical recovery. It indicates the current trend of signal quality change, which is obtained by the change of signal quality evaluation value between the current acquisition period and the historical acquisition period; It indicates the current movement direction status, which is obtained from changes in the deployment location of the IoT nodes at both ends or changes in positioning data; It represents the communicable status of adjacent real connection links, and is calculated from the stability of the acknowledgment response of adjacent real connection links, the service transmission load, and the communication latency variation status.

[0073] The server constructs a restricted observation layer based on restricted predictive recovery links. The restricted observation layer is a data layer in the hierarchical topology data used to represent links that still have some recovery potential but are not suitable for immediate participation in bidirectional communication verification, regular topology display, and network scheduling. The server writes the link identifier corresponding to the restricted predictive recovery link, the node identifiers of the IoT nodes at both ends, the recovery trust status, the number of consecutive unacknowledged responses, historical recovery records, the current signal quality change trend, and the communicable status of adjacent real connection links into the restricted observation layer. The number of consecutive unacknowledged responses indicates how many consecutive collection cycles the restricted predictive recovery link has not received a valid acknowledgment response, reflecting whether the link has a tendency to remain unrecovered for a long period. The restricted predictive recovery links in the restricted observation layer are not used as available communication links in the main connection layer, nor do they directly participate in routing selection or service transmission load migration; they are only retained as observation objects for local viewing, anomaly analysis, or subsequent status recovery. The restricted observation layer can be represented by the following expression:

[0074] in, Indicates the first The limited observation layer within a single acquisition cycle; Link identifier Corresponding link type; This indicates the restoration of the trusted state evaluation value; This indicates the number of consecutive unacknowledged responses, which is accumulated from the number of collection cycles in the link acknowledgment record that have not received a valid acknowledgment response consecutively. This indicates the degree of historical recovery stability corresponding to the historical recovery record; Indicates the current trend of signal quality changes; Indicates the communicable status of adjacent real-world links; This indicates the data associated with the link status.

[0075] The server constructs a failure record layer based on the failure prediction and recovery links. The failure record layer is a data layer in the hierarchical topology data used to store records of links that no longer meet the conditions for effective recovery. It does not participate in regular topology display, bidirectional communication verification, network scheduling, or service transmission load migration. The server writes the link identifier corresponding to the failure prediction and recovery link, the node identifiers of the IoT nodes at both ends, the historical disconnection duration, historical recovery records, the number of consecutive unacknowledged connections, the current direction of movement, the current signal quality change trend, and the reason for failure judgment into the failure record layer. The reason for failure judgment explains why the failure prediction and recovery link is no longer retained as a verifiable or limited observation object, such as excessively long historical disconnection duration, excessively high number of consecutive unacknowledged connections, the IoT nodes at both ends continuing to move away, the current signal quality change trend continuing to deteriorate, or adjacent real-world links being uncommunicative. The purpose of retaining failure prediction and recovery links in the failure record layer is to support subsequent anomaly tracing, model correction, and historical link analysis, rather than allowing them to continue to affect the current topology visualization results. The failure record layer can be represented by the following expression:

[0076] in, Indicates the first Failure record layer within a collection cycle; Link identifier Corresponding link type; Indicates the duration of historical disconnection; This indicates the degree of historical recovery stability corresponding to the historical recovery record; Indicates the number of consecutive unconfirmed calls; Indicates the current movement direction status; Indicates the current trend of signal quality changes; The cause of failure is determined by the recovery confidence level, the number of consecutive unacknowledged responses, spatial recovery conditions, and the current trend of signal quality changes. This indicates the data associated with the link status.

[0077] The server constructs hierarchical topology data based on the main connection layer, verification and observation layer, restricted observation layer, and failure record layer. This hierarchical topology data is a data structure with IoT nodes as node objects and different link types as connection objects. It is used to simultaneously store the hierarchical relationships of real connection links, links to be verified and predicted for recovery, restricted for prediction for recovery, and failure for prediction for recovery. The server combines the main connection layer, verification and observation layer, restricted for observation, and failure record layer within the same acquisition period according to link identifiers, maintaining different display permissions, verification permissions, and scheduling permissions for different link types during the combination process. Display permissions determine whether a link is displayed normally, weakened, partially, or hidden in the initial adaptive topology visualization results; verification permissions determine whether a link can be selected for subsequent bidirectional communication verification processes; and scheduling permissions determine whether a link can participate in routing selection, service transmission load migration, or topology expansion. The hierarchical topology data can be represented by the following expression:

[0078] in, Indicates the first Hierarchical topology data corresponding to each collection cycle; Indicates the first The set of IoT nodes participating in topology construction within a collection cycle is obtained by deduplicating the node identifiers in the node link data. Indicates the main connection layer; Indicates the verification observation layer; Indicates a restricted observation layer; Indicates the failure record layer; Indicates the first The set of permission configurations for each link type within a collection cycle, including display permissions, verification permissions, and scheduling permissions.

[0079] When constructing hierarchical topology data, the server performs a uniqueness check on the link type corresponding to the same link identifier. Uniqueness check ensures that the same link identifier can only belong to one link type within the same data collection period, preventing the same link from appearing simultaneously in the main connection layer, verification observation layer, restricted observation layer, or failure record layer. Duplicate assignments may occur due to data arrival delays, delayed link type updates, failure to release historical records in a timely manner, or failure to synchronize bidirectional communication verification results. When performing uniqueness check, the server determines the final link type based on link confirmation records, restored trusted states, and link type priority within the current data collection period. Link type priority can be set as follows: Real connection links are higher than predicted recovery links to be verified, predicted recovery links to be verified are higher than restricted predicted recovery links, and restricted predicted recovery links are higher than failure predicted recovery links. Uniqueness check can be represented by the following expression:

[0080] in, Link identifier In the The final link type retained after uniqueness verification within each collection cycle; Link identifier In the The set of candidate link types identified within a collection period may include one or more of the following: real connection links, predictive recovery links to be verified, restricted predictive recovery links, and failure predictive recovery links. This function represents the link type priority and is used to assign priorities to different link types. This indicates that the link type with the highest priority is selected.

[0081] When the server generates the initial adaptive topology visualization result based on the hierarchical topology data, it first reads the main connection layer and generates the currently usable topology structure. Then, it reads the verification observation layer and overlays the predicted recovery links to be verified around the usable topology structure. Next, it reads the restricted observation layer and limits the restricted predicted recovery links to partial or weakened display. Finally, it reads the failure record layer and sets the failure predicted recovery links as hidden records. The initial adaptive topology visualization result is a stage visualization result before subsequent bidirectional communication verification. It displays the network structure formed by the current actual connection links and retains the status prompts for the predicted recovery links to be verified and the restricted predicted recovery links, but does not display the failure predicted recovery links as current network connections. The server can set visualization weights according to different link types to control the display intensity of links in the initial adaptive topology visualization result. The visualization weight can be represented by the following expression:

[0082] in, Link identifier In the The visibility weight within each acquisition cycle is used to control the display intensity of the link in the initial adaptive topology visualization results; Indicates the final link type after uniqueness verification; This indicates the restoration of the trusted state evaluation value; The display adjustment coefficient represents the predicted recovery link to be verified. It is set by the degree to which the system wants to highlight the object to be verified, and its value is less than or equal to 1. The explicit adjustment factor representing the constrained predictive recovery link is set by the degree to which the system wants to weaken the constrained observed object, and is typically less than [a certain value]. When the link type is a real connection link, the visibility weight is set to 1, indicating normal display; when the link type is a failure prediction and recovery link, the visibility weight is set to 0, indicating hidden display.

[0083] When generating the initial adaptive topology visualization, the server also writes verification and scheduling permissions into the visualization attributes of the corresponding links. This ensures that the visualization not only represents connection relationships but also provides operational status for subsequent processing. For real connected links, the server grants them regular display and scheduling permissions, allowing them to participate in network scheduling as currently available connections. For links awaiting verification and predicted recovery, the server grants them candidate display and verification permissions but not regular scheduling permissions, allowing them to be used as objects for subsequent bidirectional communication verification rather than being directly used as service transmission paths. For restricted predicted recovery links, the server grants them partial or weakened display permissions and restricts their verification and scheduling permissions. For failed predicted recovery links, the server only retains their traceability permissions, preventing them from participating in the current visual topology display and network scheduling. Through this processing, the initial adaptive topology visualization can serve as the source of objects for the next step of performing bidirectional communication verification on links awaiting verification, while also preventing predicted recovery links from being mistaken for real connected links.

[0084] S150. Based on the initial adaptive topology visualization results, perform bidirectional communication verification on the predicted recovery link to be verified, and update the recovery trust status corresponding to the predicted recovery link to be verified. At the same time, based on the updated recovery trust status, perform link type conversion on the predicted recovery link to be verified to obtain the updated node link data.

[0085] Specifically, the server extracts the predicted recovery links marked as bidirectional communication verification objects based on the initial adaptive topology visualization results, and reads the recovery trust status, historical disconnection duration, current signal quality change trend, and the communicability status of adjacent real connection links for each predicted recovery link. Bidirectional communication verification objects refer to the predicted recovery links located in the verification observation layer in the initial adaptive topology visualization results that have not yet been converted into real connection links. The bidirectional communication verification order is used to determine the order in which multiple predicted recovery links are verified. The server prioritizes verifying predicted recovery links with higher recovery trust status, shorter historical disconnection duration, better current signal quality change trend, and better communicability status of adjacent real connection links, in order to reduce the network resource consumption of verification requests and increase the effective probability of the predicted recovery links being converted into real connection links. The bidirectional communication verification order can be determined by a verification priority value, calculated using the following formula:

[0086] in, Link identifier In the The verification priority value corresponding to each collection period; the higher the verification priority value, the higher the priority of the bidirectional communication verification of the predicted recovery link to be verified. Represents IoT nodes IoT nodes The link identifier between the two IoT nodes is obtained by combining the node identifiers of the two IoT nodes. The recovery reliability evaluation value corresponding to the predicted recovery link to be verified is obtained by combining the previous historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend, and the communicability status of adjacent real connection links. This represents the normalized historical disconnection duration, which is obtained by normalizing the historical disconnection duration of the predicted recovery link to be verified according to the preset maximum disconnection duration. The higher the value, the longer the disconnection lasts. This represents the normalized trend of the current signal quality change, which is obtained by normalizing the current signal quality change trend according to the historical trend range. The higher the value, the more obvious the signal quality recovery trend. It represents the communicable status of adjacent real connection links, and is calculated from the stability of the acknowledgment response of adjacent real connection links, the service transmission load, and the communication latency variation status. These represent the weight coefficients corresponding to the recovery trusted state evaluation value, historical disconnection duration, current signal quality change trend, and the communicable state of adjacent real connection links, respectively. Each weight coefficient is set by the network management policy, and the sum of all weight coefficients is 1.

[0087] The server determines the communication initiating IoT node and the communication responding IoT node based on the link identifier corresponding to the predicted recovery link to be verified. It then controls the communication initiating IoT node to send a verification request to the communication responding IoT node, and simultaneously controls the communication responding IoT node to return a verification response, thus forming an acknowledgment response for the predicted recovery link to be verified. The communication initiating IoT node is the IoT node that sends the verification request, and the communication responding IoT node is the IoT node that receives the verification request and returns a verification response. These two can be determined based on the node identifier order in the link identifier, the current service transmission load, or remaining communication resources. For example, when IoT nodes... The service transmission load is lower than that of the IoT node At that time, IoT nodes can be The IoT node is identified as the initiator of the communication. The IoT node that initiates the communication is identified as the IoT node that responds, in order to reduce the impact of verification requests on high-load IoT nodes. The acknowledgment response indicates whether the verification request has completed the bidirectional interaction from the IoT node initiating the communication to the IoT node responding to the communication, and back to the IoT node initiating the communication. The acknowledgment response can be determined using the following formula:

[0088] in, Link identifier In the Confirmation response within a collection cycle, when When a valid acknowledgment response is formed, This indicates that no valid acknowledgment response has been generated; This indicates the time when the IoT node initiating the communication sends the verification request, which is recorded by the IoT node initiating the communication when sending the verification request; This indicates the time when the communication initiating IoT node receives the verification response, which is recorded by the communication initiating IoT node upon receiving the verification response; This indicates the maximum allowed response time for bidirectional communication verification, which is determined by the communication protocol, topology refresh cycle, and application latency requirements. This indicates the verification response return flag. The value is 1 when the IoT node that initiated the communication receives the verification response returned by the IoT node, and 0 otherwise. This represents a conditional function. The value is 1 when the condition inside the parentheses is true, and 0 when the condition inside the parentheses is false.

[0089] During the bidirectional communication verification process, the server collects the communication latency, packet loss status, and retransmission status corresponding to the predicted recovery link to be verified, and uses the acknowledgment response, communication latency, packet loss status, and retransmission status as the verification results for the predicted recovery link. Communication latency represents the time elapsed from sending the verification request to receiving the verification response; packet loss status indicates the degree to which the verification request or response was not successfully completed; retransmission status indicates the degree to which the same verification request needs to be resent. The server can send multiple verification requests within the same verification cycle to avoid the single verification result being affected by short-term interference. The communication latency, packet loss status, and retransmission status can be determined using the following formulas:

[0090] in, Link identifier In the Verification communication latency within each acquisition cycle; Indicates the first The number of verification requests that received a valid confirmation response within a collection period is obtained by counting the verification requests with a valid confirmation response of 1. The sequence number indicating a valid acknowledgment response; Indicates the first The time when a valid confirmation response is sent; Indicates the first The return time of the verification response corresponding to each valid confirmation response.

[0091]

[0092] in, Link identifier In the Verify packet loss status within each collection cycle; Indicates the first The number of verification requests that received valid confirmation responses within a collection cycle; Indicates the first The total number of verification requests sent within a collection cycle is obtained by statistically analyzing the records of verification requests sent by the IoT node that initiated the communication.

[0093]

[0094] in, Link identifier In the Verification retransmission status within each acquisition cycle; Indicates the first The number of verification requests that are retransmitted within a collection cycle is obtained by counting the number of repeated transmissions recorded by the IoT node that initiated the communication. Indicates the first Total number of verification requests sent within a collection cycle.

[0095] The server updates the recovery trust status of the predicted recovery link to be verified based on the verification results and the real-time status of adjacent real connection links. The verification results reflect whether the predicted recovery link itself has actual communication capabilities, while the real-time status of adjacent real connection links reflects whether the verification process affects surrounding real connection links, or whether the local area where the predicted recovery link is located still has communication support capabilities. If the predicted recovery link to be verified receives continuous and valid acknowledgment responses, and the verification communication latency, packet loss status, and retransmission status are low, while the service transmission load and communication latency changes of adjacent real connection links do not show any abnormalities, the recovery trust status is increased. If the predicted recovery link to be verified only receives intermittent acknowledgment responses, or any of the verification communication latency, packet loss status, or retransmission status is continuously abnormal, the recovery trust status is decreased or maintained. If bidirectional communication verification causes a significant increase in the service transmission load or communication latency of adjacent real connection links, the recovery trust status is further decreased to avoid the verification behavior interfering with the real connection links. The updated recovery trust status can be determined using the following formula:

[0096] in, Link identifier In the The updated recovery reliability status evaluation value within each collection cycle; This indicates a confirmation response, determined by whether a verification response is returned and whether the maximum response time has not been exceeded. This represents the normalized verification communication delay, which is obtained by normalizing the verification communication delay according to the preset maximum verification communication delay. This indicates the status of packet loss. Indicates the verification retransmission status; It represents the real-time status of adjacent real connection links, which is calculated from the stability of the confirmation response, the service transmission load, and the communication latency changes of adjacent real connection links during the verification period; These represent the weight coefficients corresponding to the acknowledgment response, verification communication delay, verification packet loss status, verification retransmission status, and the real-time status of adjacent real connection links, respectively. Each weight coefficient is set by the network management policy, and the sum of all weight coefficients is 1.

[0097] The server performs link type conversion on the predicted recovery link to be verified based on the updated recovery trust status. Link type conversion refers to reclassifying the predicted recovery link to be verified as a real connection link, a restricted predicted recovery link, or a failed predicted recovery link based on the recovery trust status verified by bidirectional communication. A convertible state indicates that the predicted recovery link to be verified has the conditions to be converted into a real connection link; a restricted hold state indicates that the predicted recovery link to be verified still has a certain recovery potential, but is not suitable to directly become a real connection link; a failed rollback state indicates that the predicted recovery link to be verified no longer has the conditions to continue as a verification object after verification. Link type conversion can be determined using the following formula:

[0098] in, Link identifier In the New link type verified by bidirectional communication within a collection cycle; This represents the updated recovery trust status evaluation value; This represents the trusted threshold required to convert to a real connection link, which is set by network stability requirements; This indicates a confirmation response; This indicates the status of packet loss. This represents the maximum threshold for verified packet loss states that are allowed to be converted to a real connection link. Indicates the verification retransmission status; This represents the maximum valid retransmission state threshold that allows a link to be converted to a real connection. This indicates the minimum confidence threshold for allowing a restricted predictive recovery link to remain in existence, and .

[0099] When a link awaiting verification for predictive recovery is in a convertible state, the server converts it into a real connection link and writes the link identifier, acknowledgment response, verification communication latency, verification packet loss status, verification retransmission status, and updated recovery trust status to the main connection layer. A real connection link indicates that it has been verified through actual bidirectional communication and can participate in the initial adaptive topology visualization update and subsequent network scheduling as a currently available link. During this conversion, the server also removes the link from the verification observation layer to prevent the same link identifier from appearing simultaneously in both the verification observation layer and the main connection layer. Through this process, links that originally only had predictive recovery potential can enter the currently available topology after successful actual verification, thereby improving the real-time performance and accuracy of topology updates.

[0100] When a predictive recovery link to be verified is in a restricted hold state, the server converts it into a restricted predictive recovery link and writes the link identifier, updated recovery trust status, verification communication latency, verification packet loss status, verification retransmission status, number of consecutive unacknowledged requests, and the reason for restricted hold into the restricted observation layer. The reason for restricted hold explains why the link was not converted into a real connection link, such as intermittent acknowledgment responses, high verification communication latency, high verification packet loss status, high verification retransmission status, or a decline in the real-time status of adjacent real connection links. After performing this conversion, the server restricts the link from participating in regular topology display and network scheduling, keeping it only as a local observation object. This process prevents unstable predictive recovery links to be verified from directly participating in service transmission path selection.

[0101] When a predictive recovery link to be verified is in a failure rollback state, the server converts it into a failure predictive recovery link and writes the link identifier, updated recovery trust status, verification failure records, number of consecutive unacknowledged responses, current signal quality change trend, real-time status of adjacent real connection links, and failure rollback reason to the failure record layer. The failure rollback reason explains why the link is no longer retained as a predictive recovery link to be verified, such as continuous failure to receive valid acknowledgment responses, persistently high verification packet loss, persistently high verification retransmission, persistently exceeding allowable communication latency, or the verification process affecting the stability of adjacent real connection links. After performing this conversion, the server no longer treats the link as a regular topology display object or network scheduling object, but only as a historical record for anomaly tracing and recovery model correction. This process prevents predictive links that cannot be recovered for a long time from remaining in the visible topology.

[0102] After completing the link type conversion, the server writes back the updated recovery trusted state, new link type, verification result, and corresponding conversion reason to the node link data, and synchronously updates the main connection layer, verification observation layer, restricted observation layer, and failure record layer in the hierarchical topology data. This write-back process ensures that subsequent risk area identification no longer uses expired predicted recovery link states. If a predicted recovery link has been converted to a real connection link, it no longer participates in predicted link risk identification. If a predicted recovery link is converted to a restricted predicted recovery link, it continues to be considered for risk identification. If a predicted recovery link is converted to a failed predicted recovery link, it is only retained as a hidden record. Through this process, the predicted recovery links in the initial adaptive topology visualization result can be dynamically converted to different link types through actual bidirectional communication verification, thus preventing predicted recovery links from remaining in the visualization topology for extended periods and inducing erroneous topology expansion.

[0103] S160. Identify risk areas based on the updated node link data, and perform display weakening, scheduling restrictions, and probe frequency reduction processing on the unverified predicted recovery links and restricted predicted recovery links according to the risk areas, so as to generate an adaptive topology visualization result for the Internet of Things network.

[0104] Specifically, after completing the bidirectional communication verification and link type conversion of the predictive recovery links to be verified, the server first extracts the links that still belong to the predictive recovery links to be verified and the restricted predictive recovery links from the updated node link data and the initial adaptive topology visualization results, and identifies the predictive recovery links to be verified and the restricted predictive recovery links as risk identification objects. Risk identification objects refer to links that have not yet been stably converted to real connection links, but may still affect the network structure judgment in topology display, local observation, or subsequent probing; links that have been converted to real connection links are no longer considered risk identification objects because they have passed bidirectional communication verification and can be used as currently available links; links that have been converted to failure predictive recovery links are also no longer considered risk identification objects because they are only retained as hidden records and should not continue to affect the current topology visualization results.

[0105] Based on the link identifiers and IoT nodes at both ends of the unverified and restricted predictive recovery links, the server counts cases where multiple unverified or restricted predictive recovery links point to the same communication response IoT node, the same gateway IoT node, or the same local relay IoT node to determine the degree of connection target duplication for the corresponding links. A communication response IoT node is an IoT node that receives verification requests or communication requests and returns a response; a gateway IoT node is an IoT node responsible for aggregation communication with the upper-level network or management platform; and a local relay IoT node is an IoT node that undertakes forwarding tasks between adjacent IoT nodes. The degree of connection target duplication indicates whether multiple risk identification objects are concentrated on the same connection target. If a large number of unverified and restricted predictive recovery links point to the same communication response IoT node, the same gateway IoT node, or the same local relay IoT node, it indicates that these links may form a false aggregation structure in the visible topology and induce service transmission load to gather towards that connection target. The degree of connection target duplication can be determined using the following expression:

[0106] in, Link identifier In the The degree of repetition of the corresponding connection targets within each acquisition cycle; Indicates the first The set of risk-identified objects within a collection period; Represents any link identifier in the set of risk identification objects; Link identifier The corresponding connection target can be a communication response IoT node, a gateway IoT node, or a local relay IoT node, determined by the role information and link direction information of the IoT nodes at both ends of the link identifier; Link identifier The corresponding connection target; Indicates the number of elements in the set; This represents a correction parameter to prevent the denominator from being zero; it can be a very small positive number.

[0107] The server determines the spatial clustering of multiple predictive recovery links (both to be verified and restricted) within the same local area based on the deployment location, current movement direction, and distribution status of adjacent real connection links of the corresponding IoT nodes. This determines the spatial distribution concentration of the corresponding links. Deployment location indicates the physical location of the IoT node, which can be obtained from positioning coordinates, gateway ranging results, or installation location records. Current movement direction indicates the direction of position change of the IoT node between adjacent data collection periods. The distribution status of adjacent real connection links indicates the spatial density and connection direction of real connection links around the risk identification object. Spatial distribution concentration is used to determine whether multiple risk identification objects are concentrated around the same communication coverage boundary, the same gateway IoT node, or the same local relay channel. If the IoT nodes at both ends of multiple predictive recovery links and restricted prediction recovery links are close in location and their current movement directions tend to be in the same area, it indicates that the local area may have formed a false topology expansion trend due to the retention of predictive links. The spatial distribution concentration can be determined using the following expression:

[0108] in, Link identifier In the The degree of spatial distribution concentration within each collection cycle; Link identifier In the The link center position corresponding to each collection cycle is obtained by averaging the deployment coordinates of the IoT nodes at both ends of the link; Link identifier In the The corresponding link center location within each collection cycle; This represents the spatial distance between the center locations of two links, calculated from the coordinates of the center locations of the two links. This represents the distance threshold for determining spatial clustering, which can be set by the gateway coverage radius, the local relay coverage range, or the granularity of operation and maintenance visibility. Link identifier The corresponding IoT node is at the The current direction of movement within each acquisition cycle is obtained by combining the position change vectors of the two IoT nodes; Link identifier The corresponding IoT node is at the Current movement direction within each acquisition cycle; This indicates the degree of directional consistency between two current movement directions; The threshold for determining convergence of movement directions is determined by the movement speed of IoT nodes and the topology refresh cycle; This represents a conditional function that evaluates to 1 if the condition within the parentheses is true, and 0 otherwise.

[0109] Based on the service transmission load of IoT nodes associated with the unverified predictive recovery link and the restricted predictive recovery link, the server determines the continuous aggregation of service transmission load towards the same local area, thus determining the degree of service transmission load aggregation for the corresponding link. Service transmission load represents the pressure on IoT nodes in terms of data transmission, buffering, forwarding, and retransmission, and can include the amount of data to be sent, buffer queue occupancy status, forwarded data amount, number of forwarding failures, and number of service packets. The degree of service transmission load aggregation indicates whether the service transmission load within the same local area is continuously increasing, and whether this increase corresponds to the spatial aggregation or duplicate connection targets of the unverified predictive recovery link and the restricted predictive recovery link. If a risk-identified object within a local area has not yet been converted into a real connection link, but the amount of data to be sent, buffer queue occupancy status, or number of forwarding failures of surrounding IoT nodes is continuously increasing, it indicates that the service transmission load may be misled to that local area by predictive links. The degree of service transmission load aggregation can be determined using the following expression:

[0110] in, Link identifier In the The degree of aggregation of business transmission load within each collection cycle; This indicates the number of historical backtracking cycles used to determine continuous aggregation, and is set by the characteristics of business traffic fluctuations and the topology refresh frequency. This indicates any collection period within the historical backtracking range; Link identifier In the The set of IoT nodes in the corresponding local area within each collection cycle is determined by the IoT nodes at both ends of the link, the IoT nodes of the adjacent gateway, the IoT nodes of the adjacent local relay, and the IoT nodes within the distance threshold. Represents IoT nodes In the The service transmission load evaluation value within each collection period is obtained by comprehensively considering the amount of data to be sent, the status of the buffer queue, the amount of data already forwarded, the number of forwarding failures, and the number of service packets. Indicates the first The set of all IoT nodes that participate in topology construction within a collection cycle; Represents IoT nodes In the Evaluation value of service transmission load within a collection period; This represents a correction parameter to prevent the denominator from being zero.

[0111] The server identifies risk areas based on the degree of repetition of connection targets, the concentration of spatial distribution, and the concentration of service transmission load. A risk area is a local network region that may induce erroneous topology expansion or erroneous concentration of service transmission load due to the concentrated retention of unverified predictive recovery links and restricted predictive recovery links. The server can first group risk-identified objects with similar link centers, identical connection targets, or overlapping adjacent real connection links into the same local area. Then, it comprehensively evaluates the degree of repetition of connection targets, the concentration of spatial distribution, and the concentration of service transmission load for each risk-identified object within that local area. When the comprehensive evaluation result exceeds a risk threshold, the local area is identified as a risk area. The risk area evaluation value can be determined using the following expression:

[0112] in, Indicates the first Within the first collection cycle, the first Risk assessment value for a local area; This indicates the local region number obtained by spatial clustering of risk identification objects or merging of connection targets; Indicates the first The average degree of connection target redundancy of risk-identified objects in a local area is obtained by averaging the degree of connection target redundancy of each predicted recovery link to be verified and the restricted predicted recovery link in that local area. Indicates the first The average spatial distribution concentration of risk-identified objects within a local area is obtained by averaging the spatial distribution concentration of each risk-identified object within that local area. Indicates the first The average service transmission load aggregation degree corresponding to the risk-identified objects in a local area is obtained by averaging the service transmission load aggregation degree of each risk-identified object in that local area. These represent the weighting coefficients corresponding to the degree of repetition of connection targets, the degree of spatial distribution concentration, and the degree of aggregation of service transmission load, respectively. Each weighting coefficient is set by the network management policy, and the sum of all weighting coefficients is 1.

[0113] The server can determine whether a risk area is formed based on the relationship between the risk area evaluation value and the risk threshold. The expression is as follows:

[0114] in, Indicates the first Within the first collection cycle, the first Whether a local area is identified as a risk area, when When it is identified as a risk area, This indicates that the area was not identified as a risk area; This indicates the risk assessment value of this local area; This represents the threshold for identifying risk areas, which is set by the system's allowed degree of predicted link aggregation, the tolerance for service transmission load congestion, and the requirements for topology visibility stability.

[0115] The server performs display weakening processing on the unverified and restricted predicted recovery links based on the risk area. Display weakening processing refers to reducing the display priority, intensity, or normal display range of unverified and restricted predicted recovery links in the topology visualization results within the risk area, so that maintenance personnel will not mistake them for currently available links. The server can adjust the display of unverified predicted recovery links within the risk area from normal candidate display to risk warning display, and adjust the display of restricted predicted recovery links within the risk area to partial view or default hidden display, and associate the risk area mark with the corresponding link. The visibility weight after display weakening can be determined using the following expression:

[0116] in, Link identifier Visible weights after risk area control; Link identifier The visible weight before risk area control is determined by the link type and the recovery trusted state; This indicates the weakening coefficient, which is set by the topology visual interface to the degree of weakening of risk areas; Link identifier Belonging to Risk assessment value for a local area.

[0117] The server applies scheduling restrictions to unverified and restricted predictive recovery links within a risk area. Scheduling restrictions limit the participation of unverified and restricted predictive recovery links within the risk area in primary route selection, service load migration, and topology expansion decisions. For restricted predictive recovery links within a risk area, the server prohibits their participation in network scheduling; for unverified predictive recovery links within a risk area, the server only allows them to participate in network scheduling after they have subsequently completed bidirectional communication verification and become real connection links. If service load has already concentrated in a risk area, the server prioritizes adjusting transmission paths using real connection links surrounding the risk area to prevent service load from continuing to concentrate on unstable predictive links. Scheduling permissions can be determined using the following expression:

[0118] in, Link identifier In the Scheduling permissions within a collection cycle, when When it indicates permission to participate in network scheduling, This indicates that participation in network scheduling is not permitted. Link identifier Link type after link type conversion; Link identifier Is the local area it belongs to a risk area?

[0119] The server performs probe frequency reduction processing on the unverified predictive recovery links and restricted predictive recovery links within the risk area. Probe frequency reduction processing refers to reducing the bidirectional communication verification frequency of the unverified predictive recovery links within the risk area and reducing the state probe frequency of the restricted predictive recovery links within the risk area, thereby reducing the consumption of communication resources on real connection links by verification requests and state probes. If the risk area evaluation value is high, it indicates that there is a significant clustering risk of predictive links in that local area. In this case, excessively frequent probes may further cause service transmission load aggregation and congestion of real connection links; therefore, it is necessary to reduce the probe frequency. The probe interval can be determined using the following expression:

[0120] in, Link identifier In the The detection interval after one acquisition cycle; The basic detection interval before risk area control is indicated, and is set by the topology refresh cycle and network management policy. This represents the detection frequency reduction factor, which is set by the system's allowed detection resource usage level; Link identifier Risk assessment value of the local area to which it belongs.

[0121] After completing the display weakening, scheduling restriction, and probe frequency reduction processing, the server writes the processing results back to the node link data. The processing results include risk area markings, risk area evaluation values, connection target redundancy, spatial distribution concentration, service transmission load aggregation, weakened visibility weight, scheduling permissions, and probe intervals. The write-back process ensures that subsequent hierarchical topology data and IoT network adaptive topology visualization results use link states that have undergone risk control, rather than continuing to use predicted link states from the initial adaptive topology visualization results. The written-back node link data can be represented by the following expression:

[0122] in, Link identifier In the Node link data after risk control write-back is completed within each collection cycle; This represents the link status associated data before risk control; Indicates whether the local area to which the link belongs is a risk area; Indicates the risk area assessment value; Indicates the degree of repetition of the connection targets; Indicates the degree of concentration in spatial distribution; Indicates the degree of load concentration in service transmission; This represents the weakened visual weight; Indicates scheduling authority; Indicates the detection interval.

[0123] The server updates the hierarchical topology data based on the written-back node link data and generates an adaptive topology visualization result for the IoT network. The updated hierarchical topology data still includes the main connection layer, verification observation layer, restricted observation layer, and failure record layer, but the links to be verified and the restricted predictive recovery links have been marked with risk area tags, visibility weights, scheduling permissions, and probe intervals. When generating the adaptive topology visualization result, the server prioritizes displaying the currently available topology structure formed by real connection links. It weakens or partially displays the links to be verified and the restricted predictive recovery links within risk areas and displays risk area tags around these areas. This ensures that the final visualization result simultaneously represents the currently available links, the restricted and retained predictive links, and the risk of erroneous topology expansion caused by the predictive links. The adaptive topology visualization result for the IoT network can be represented by the following expression:

[0124] in, Indicates the first The IoT network adaptive topology visualization results generated within each collection cycle; Represents the set of IoT nodes participating in the topology visibility; This represents the set of actual connection links in the main connection layer; This represents the set of predicted recovery links to be verified after risk control has been completed. This represents the set of restricted predictive recovery links after risk control has been completed. Indicates the first The set of risk areas identified within each collection cycle; This represents the set of visual attributes corresponding to each link and each risk area, including visual weight, display range, risk area marker, scheduling authority, and detection interval.

[0125] This application also provides an adaptive topology visualization device for IoT networks based on signal quality assessment, referring to... Figure 2 , Figure 2 This is a schematic diagram of a module for an IoT network adaptive topology visualization device based on signal quality assessment, provided in an embodiment of this application. The device is a server, comprising an acquisition module 21 and a processing module 22. The acquisition module 21 acquires real-time signal quality data, service transmission load, and link confirmation records corresponding to each IoT node in the IoT network to form node link data. The processing module 22 identifies candidate connection relationships between IoT nodes based on the node link data and classifies these relationships into real connection links and predicted recovery links. The processing module 22 further determines the recovery reliability status of the predicted recovery link based on its historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend, and the communicability status of adjacent real connection links. Based on the recovery reliability status, the predicted recovery link is then classified into unverified predicted recovery links, restricted predicted recovery links, and failed predicted recovery links. The processing module 22 is further configured to construct hierarchical topology data based on real connection links, predicted recovery links to be verified, restricted predicted recovery links, and failed predicted recovery links, and generate initial adaptive topology visualization results based on the hierarchical topology data; the processing module 22 is further configured to perform bidirectional communication verification on the predicted recovery links to be verified based on the initial adaptive topology visualization results, update the recovery trust status corresponding to the predicted recovery links to be verified, and perform link type conversion on the predicted recovery links to be verified based on the updated recovery trust status to obtain updated node link data; the processing module 22 is further configured to identify risk areas based on the updated node link data, and perform display weakening, scheduling restriction, and detection frequency reduction processing on the predicted recovery links to be verified and restricted predicted recovery links based on the risk areas to generate adaptive topology visualization results for the Internet of Things network.

[0126] This application also provides an electronic device, with reference to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: at least one processor 31, at least one network interface 34, a user interface 33, a memory 35, and at least one communication bus 32.

[0127] The communication bus 32 is used to enable communication between these components.

[0128] The user interface 33 may include a display screen and a camera. Optionally, the user interface 33 may also include a standard wired interface and a wireless interface.

[0129] The network interface 34 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0130] The processor 31 may include one or more processing cores. The processor 31 connects to various parts of the server via various interfaces and lines, executing instructions, programs, code sets, or instruction sets stored in the memory 35, and calling data stored in the memory 35 to perform various server functions and process data. Optionally, the processor 31 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 31 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 31 and may be implemented as a separate chip.

[0131] The memory 35 may include random access memory (RAM) or read-only memory. Optionally, the memory 35 may include a non-transitory computer-readable storage medium. The memory 35 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 35 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 35 may also be at least one storage device located remotely from the aforementioned processor 31. Figure 3 As shown, the memory 35, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for an IoT network adaptive topology visualization method based on signal quality assessment.

[0132] existFigure 3 In the electronic device shown, the user interface 33 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 31 can be used to call an application stored in the memory 35 for an IoT network adaptive topology visualization method based on signal quality assessment. When executed by one or more processors, the electronic device performs one or more methods as described in the above embodiments.

[0133] This application also provides a non-transitory computer-readable storage medium storing instructions. When executed by one or more processors, these instructions cause an electronic device to perform one or more of the methods described in the above embodiments.

Claims

1. An adaptive topology visualization method for Internet of Things (IoT) networks based on signal quality assessment, characterized in that, The method includes the following steps: S110. Obtain real-time signal quality data, service transmission load, and link confirmation records corresponding to each IoT node in the IoT network to form node link data. S120. Identify candidate connection relationships between each IoT node based on the node link data, and divide the candidate connection relationships into real connection links and predicted recovery links; S130. Based on the historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend and the communicability status of adjacent real connection links corresponding to the predicted recovery link, determine the recovery reliability status corresponding to the predicted recovery link, and divide the predicted recovery link into a predicted recovery link to be verified, a limited predicted recovery link and a failed predicted recovery link according to the recovery reliability status. S140. Construct hierarchical topology data based on the actual connection links, the predicted recovery links to be verified, the restricted predicted recovery links, and the failure predicted recovery links, and generate an initial adaptive topology visualization result based on the hierarchical topology data; S150. Perform bidirectional communication verification on the predicted recovery link to be verified based on the initial adaptive topology visualization result, update the recovery trust status corresponding to the predicted recovery link to be verified, and perform link type conversion on the predicted recovery link to be verified based on the updated recovery trust status to obtain updated node link data. S160. Identify risk areas based on the updated node link data, and perform display weakening, scheduling restriction, and detection frequency reduction processing on the unverified predictive recovery link and the restricted predictive recovery link according to the risk areas, so as to generate an adaptive topology visualization result for the Internet of Things network.

2. The IoT network adaptive topology visualization method based on signal quality assessment according to claim 1, characterized in that, Step S110 specifically includes: The real-time signal quality data, service transmission load, and link confirmation records uploaded by each IoT node in the IoT network are supplemented with node identifiers, link identifiers, and collection times, and then merged based on the node identifiers and link identifiers. Based on the acquisition time, the merged data is mapped to a unified acquisition period, and data within the same time window is periodically merged. For data under the same link identifier, perform association alignment processing to form link status association data, and when the link confirmation record spans different collection cycles, perform cycle attribution correction according to the confirmation request sending time; The node link data is generated based on the real-time signal quality data after time alignment, the service transmission load, and the link confirmation record.

3. The IoT network adaptive topology visualization method based on signal quality assessment according to claim 1, characterized in that, Step S120 specifically includes: Based on the link identifier in the node link data, extract the real-time signal quality data, service transmission load and link confirmation records between the corresponding IoT nodes, and identify candidate connection relationships based on the link confirmation records; The communication availability status of the candidate connection relationships is determined based on the real-time signal quality data and the service transmission load, and valid candidate connection relationships are filtered out. Based on the confirmation results, continuous confirmation status, and response stability of the valid candidate connection relationships, the valid candidate connection relationships are divided into real connection links and predicted recovery links. The recovery trend is determined based on the movement direction, position change, and confirmation response status of the IoT node corresponding to the predicted recovery link, and predicted recovery links that do not meet the recovery conditions are eliminated.

4. The IoT network adaptive topology visualization method based on signal quality assessment according to claim 1, characterized in that, Step S130 specifically includes: Based on the link identifier corresponding to the predicted recovery link, historical recovery records are extracted, and combined with the historical disconnection status of the predicted recovery link, the current direction of movement, the trend of signal quality change, and the communicability status of adjacent real connection links, the recovery reliability status corresponding to the predicted recovery link is determined. Based on the recovery trust status, the predicted recovery links are classified into levels, forming predicted recovery links to be verified, restricted predicted recovery links, and failed predicted recovery links.

5. The IoT network adaptive topology visualization method based on signal quality assessment according to claim 1, characterized in that, Step S140 specifically includes: Based on the link status information corresponding to the real connection link, the unverified prediction recovery link, the restricted prediction recovery link, and the failure prediction recovery link, the main connection layer, the verification observation layer, the restricted observation layer, and the failure record layer are constructed respectively. Hierarchical topology data is constructed based on the topology data of each layer, and the uniqueness of the link type corresponding to the same link identifier is verified. An initial adaptive topology visualization result is generated based on the hierarchical topology data.

6. The IoT network adaptive topology visualization method based on signal quality assessment according to claim 1, characterized in that, Step S150 specifically includes: Based on the initial adaptive topology visualization results, the predicted recovery links to be verified are determined, and the verification order is determined according to the recovery confidence state, historical disconnection state, signal quality change trend and adjacent real connection link state. Control the IoT nodes at both ends of the prediction recovery link to perform bidirectional communication verification, and obtain the corresponding confirmation response, communication latency, packet loss status and retransmission status; The recovery trust status of the predicted recovery link to be verified is updated based on the bidirectional communication verification results, and the predicted recovery link to be verified is converted into a real connection link, a restricted predicted recovery link, or a failed predicted recovery link based on the updated recovery trust status.

7. The IoT network adaptive topology visualization method based on signal quality assessment according to claim 1, characterized in that, Step S160 specifically includes: Extract the updated node link data and the unverified predicted recovery links and restricted predicted recovery links from the initial adaptive topology visualization results to identify risk identification targets; Risk areas are identified based on the degree of repetition of connection targets, the degree of spatial concentration of spatial distribution, and the degree of aggregation of service transmission load corresponding to the unverified predictive recovery links and the restricted predictive recovery links. Based on the risk areas, the corresponding links are subjected to display weakening, scheduling restrictions, and detection frequency reduction processing. The hierarchical topology data is updated according to the processing results to generate an adaptive topology visualization result for the Internet of Things network.

8. An adaptive topology visualization device for Internet of Things (IoT) networks based on signal quality assessment, characterized in that, The apparatus is used to execute the IoT network adaptive topology visualization method based on signal quality assessment as described in any one of claims 1 to 7, the apparatus comprising an acquisition module and a processing module, wherein... The acquisition module is used to acquire real-time signal quality data, service transmission load and link confirmation records corresponding to each IoT node in the IoT network to form node link data. The processing module is used to identify candidate connection relationships between each IoT node based on the node link data, and to divide the candidate connection relationships into real connection links and predicted recovery links. The processing module is further configured to determine the recovery reliability status of the predicted recovery link based on the historical disconnection duration, historical recovery records, current movement direction, current signal quality change trend and the communicability status of adjacent real connection links corresponding to the predicted recovery link, and divide the predicted recovery link into a predicted recovery link to be verified, a limited predicted recovery link and a failed predicted recovery link according to the recovery reliability status. The processing module is further configured to construct hierarchical topology data based on the actual connection link, the predicted recovery link to be verified, the restricted predicted recovery link, and the failed predicted recovery link, and generate an initial adaptive topology visualization result based on the hierarchical topology data; The processing module is further configured to perform bidirectional communication verification on the predicted recovery link to be verified based on the initial adaptive topology visualization result, update the recovery trust status corresponding to the predicted recovery link to be verified, and perform link type conversion on the predicted recovery link to be verified based on the updated recovery trust status to obtain updated node link data. The processing module is further configured to identify risk areas based on the updated node link data, and perform display weakening, scheduling restriction and detection frequency reduction processing on the predictive recovery link to be verified and the restricted predictive recovery link based on the risk areas, so as to generate an adaptive topology visualization result for the Internet of Things network.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; the memory stores a computer program, wherein the computer program, when executed by the processor, implements an IoT network adaptive topology visualization method based on signal quality assessment as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores instructions that, when executed, perform an IoT network adaptive topology visualization method based on signal quality assessment as described in any one of claims 1 to 7.

Images