Low-power-consumption wireless communication networking system and method for Internet of Things
By selecting backbone nodes in the IoT network and constructing a chain-like backbone communication structure, and by adopting the PEGASIS protocol and the backbone-constrained Gossip synchronization model, the problems of high communication energy consumption and synchronization redundancy in large-scale low-power scenarios of IoT networks are solved, and low-power, controllable network state synchronization is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- XIRUI NETWORK TECH (TIANJIN) CO LTD
- Filing Date
- 2026-01-22
- Publication Date
- 2026-04-17
AI Technical Summary
Existing IoT networking and synchronization technologies suffer from high communication energy consumption, channel congestion, and synchronization redundancy in large-scale, low-power scenarios. They also lack low-power control mechanisms when the network is stable, leading to a reduction in overall network energy efficiency and lifespan.
By selecting backbone nodes and constructing a chain-like backbone communication structure, the PEGASIS protocol and backbone-constrained Gossip synchronization model are adopted to limit synchronization operations to be performed between backbone nodes, generate local and global summaries, perform differential synchronization control, and activate the synchronization process only when the topology changes or parameters are updated.
It effectively reduces the overhead of synchronous communication, improves network communication load, and has controllable energy consumption. It is suitable for the stable operation of large-scale IoT networks, reduces the communication load and energy consumption of irrelevant nodes, and avoids the problem of synchronization generalization.
Smart Images

Figure CN121888352A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and in particular to a low-power wireless communication networking system and method for IoT. Background Technology
[0002] With the continuous deployment of large-scale IoT in smart cities, industrial monitoring, and environmental sensing, the networking operation and state consistency maintenance of low-power wireless nodes have become fundamental conditions for the long-term stable operation of the network. At present, IoT networks typically achieve data interaction between nodes through multi-hop wireless communication and rely on periodic state synchronization mechanisms to maintain the consistency of network parameters, node states, and topology information to support subsequent data aggregation, control decisions, and operation and maintenance management.
[0003] Existing IoT networking and synchronization technologies still have significant shortcomings. On the one hand, traditional synchronization mechanisms often employ network-wide broadcasting or unconstrained diffusion, with all nodes participating in the synchronization process. This leads to a linear or even exponential increase in communication frequency and energy consumption with node size, making it difficult to meet low-power operation requirements and prone to channel congestion and synchronization storms as the network scales up. On the other hand, existing technologies typically use full synchronization or coarse-grained retransmission strategies when states are inconsistent, failing to precisely locate and converge differential data, easily resulting in duplicate data transmission and synchronization redundancy. Furthermore, they lack control mechanisms to freeze synchronization when the network state is stable and activate it on demand when topology or parameters change, causing nodes to remain under high communication load for extended periods, reducing overall network energy efficiency and lifespan. These deficiencies limit the effectiveness of IoT networks in large-scale, low-power, and long-term operation scenarios.
[0004] Therefore, how to provide a low-power wireless communication networking system and method for the Internet of Things is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0005] One objective of this invention is to propose a low-power wireless communication networking system and method for the Internet of Things (IoT). By hierarchically selecting communication nodes and constructing a chain-like backbone communication structure, and deploying a restricted synchronization mechanism among the backbone nodes, the system achieves network state aggregation, consistency determination, and differential synchronization control. While ensuring network state consistency, it effectively reduces synchronization communication overhead and has the advantages of low communication load, controllable energy consumption, and applicability to large-scale IoT network operation.
[0006] A low-power wireless communication networking system and method for the Internet of Things (IoT) according to an embodiment of the present invention includes the following steps:
[0007] The node selection module selects the backbone node set and divides the non-backbone node set from the Internet of Things network based on node communication quality and energy consumption indicators.
[0008] The backbone chain construction module uses the PEGASIS protocol to construct a single-chain structure for the backbone node set, generating a backbone communication link that includes the chain head and chain tail.
[0009] The synchronous deployment module deploys a backbone-constrained Gossip synchronization model on the backbone chain, ensuring that synchronization occurs only between backbone nodes and excluding non-backbone nodes from participating.
[0010] The summary generation module generates a local summary for each backbone node, which includes its own state and the states of the non-backbone nodes under its jurisdiction. These summaries are then aggregated sequentially along the backbone chain to form a global summary.
[0011] The consistency determination module compares the local and global summaries of adjacent backbone nodes to determine whether the network state is consistent, and marks the difference position when there is a difference.
[0012] The differential synchronization module extracts differential data based on the differential position and encapsulates it into a synchronization packet, which is transmitted hop by hop in the backbone. The synchronization packet is deduplicated and merged at each relay node until it converges and is transmitted.
[0013] The control module freezes the synchronization operation and enters a low-power state when the consistency determination result is consistent, and only activates the synchronization process when the topology change or parameter update event is triggered.
[0014] Optionally, modules can be integrated using the following methods:
[0015] The performance of each communication node in the Internet of Things network is evaluated, and the nodes are divided into a backbone node set and a non-backbone node set based on the communication quality and energy consumption indicators of each node.
[0016] A chain-based construction method is adopted, in which the backbone nodes in the backbone node set are organized sequentially according to the PEGASIS protocol to generate a backbone communication link containing the head node and the tail node.
[0017] Deploy a backbone-constrained Gossip synchronization mechanism in the backbone communication link to limit synchronization operations to only within the backbone node set, and non-backbone nodes do not participate in synchronization interactions;
[0018] Each backbone node collects the state information of non-backbone nodes in its associated set of non-backbone nodes, merges it with its own state information to generate a local state summary, transmits and aggregates it hop by hop along the backbone communication link to generate a global state summary at the backbone link level.
[0019] By comparing the local state summary and the global state summary between adjacent backbone nodes, it is determined whether the IoT network state is consistent, and when the state is inconsistent, the node range where the difference data is located is determined.
[0020] Based on the determined node range, target difference data is extracted, differential synchronization data packets are generated, and transmitted hop by hop along the backbone communication link. Each relay backbone node in the backbone communication link performs deduplication, merging, and overlay processing on the differential synchronization data packets to ensure that the differential data converges monotonically during the propagation process.
[0021] When the network status is determined to be consistent, the backbone constraint Gossip synchronization mechanism is frozen and enters a low-communication power consumption mode; when a change in network topology or parameter update event is detected, the backbone constraint Gossip synchronization mechanism is reactivated to resume the synchronization process.
[0022] Optionally, the nodes can be divided into a backbone node set and a non-backbone node set, including:
[0023] Within the set evaluation period, the communication success rate, link stability and power consumption per unit time of each communication node are collected to construct a node-level performance evaluation information set.
[0024] Based on the performance evaluation information set, the comprehensive evaluation value of each communication node is calculated. The comprehensive evaluation value is determined by considering the control capability of both communication quality and energy consumption level. The communication node with higher communication quality and lower energy consumption has a higher comprehensive evaluation value.
[0025] All communication nodes are sorted from high to low according to their comprehensive evaluation values, and a portion of the communication nodes located within the target range are selected according to a preset number threshold to form a preliminary set of backbone nodes.
[0026] Further topology distribution analysis is performed on the communication nodes in the initial selection set of backbone nodes. If there are nodes with overlapping coverage areas or redundant control capabilities, they are removed according to geographical distribution priority, and only communication nodes with representative distribution locations in the network topology are retained.
[0027] The communication nodes that have completed the topology optimization and screening are identified as the backbone node set, and the remaining communication nodes are classified as the non-backbone node set, thus completing the node hierarchical partitioning process.
[0028] Optionally, generating a backbone communication link that includes the head node and the tail node includes:
[0029] After the set of backbone nodes is determined, the physical location information of each backbone node in the Internet of Things network is obtained, and the communication distance between any two backbone nodes is calculated based on the physical location information to form a set of distance relationships between backbone nodes.
[0030] Based on the distance relationship set, for each backbone node in the backbone node set, calculate the total length of the link formed by connecting the remaining backbone nodes in sequence when it is used as the chain starting point, and select the backbone node that minimizes the total link length as the starting node of the chain construction, and determine the starting node as the chain head node.
[0031] The backbone communication link construction process is initialized by using the head node as the initial connected node.
[0032] In the remaining unconnected backbone nodes, chain-like organization steps are performed in the following fixed order:
[0033] Starting from the current chain node, select the backbone node with the smallest communication distance to the current chain node from all unconnected backbone nodes as the next connection node;
[0034] Establish a unique chain connection between the next connection node and the current chain end node, mark the next connection node as a connected node, and update the current chain end node to the next connection node;
[0035] After each node connection is completed, an integrity check is performed on the current backbone communication link. If a node other than the current link end node is detected as the connection target, the connection is cancelled and the node selection step is re-executed until the link structure contains only a single extension direction.
[0036] Until all backbone nodes in the backbone node set are sequentially connected to form a single-chain communication path that does not contain branches or form loops;
[0037] After the single-chain communication path is formed, the last connected backbone node is determined as the tail node, and a unique intra-chain sequence identifier is assigned to each backbone node according to the connection order from the head node to the tail node.
[0038] Based on the intra-chain sequence identifier, information about the forward and backward adjacent backbone nodes is recorded for each backbone node to generate structural description information of the backbone communication link.
[0039] Optional, backbone-constrained Gossip synchronization mechanisms include:
[0040] After the backbone communication link is constructed, each backbone node is numbered according to its physical order within the link, generating a unique in-link number. A backbone node adjacency table is constructed based on the link connection relationship, and the adjacency table contains the forward link number of the current node. With chain backward numbering The backbone node adjacency list is not propagated to non-backbone nodes after initialization;
[0041] The head node generates a Gossip interaction control table and broadcasts it to all backbone nodes. The control table defines structural constraint parameters for synchronous interactions, including the maximum number of interaction hops within the chain. Synchronization session number generation rules, interaction limit, and token field structure;
[0042] After receiving the control list, each backbone node generates a Gossip interaction candidate set locally. Its construction rules are as follows:
[0043] ;
[0044] in, This is the in-chain number of the current backbone node. To constrain the number of hops in interactions, ensuring that interactions are limited to other physically adjacent backbone nodes within the chain, the mechanism design limits the synchronization diffusion path. This indicates the candidate interaction object number used by the current node for calculation or selection. The difference in the numbers within the chain is compared with the current node i to determine the interaction pair.
[0045] Each backbone node establishes a local status directory structure, which consists of... It consists of 10 state entries, each containing key-value pairs. ,in For status keys, For the state digest corresponding to this key, all key values are arranged in lexicographical order to form a state index sequence. ;
[0046] When the synchronization period conditions are met, the head node generates a synchronization session number. It then sends a synchronization build token to its neighbors to initiate the current round of backbone constraint Gossip synchronization build process;
[0047] After receiving the synchronization build token, each backbone node performs a synchronization build operation once, following these steps:
[0048] Based on the interactive candidate set Determine the current interaction target node Its generation rules are as follows:
[0049] ;
[0050] in, This indicates that the node is the only selected synchronous interaction object in the current session, ensuring that each round of synchronous construction operation triggers only one point-to-point interaction;
[0051] Current node to target node Send a synchronization request containing the current state index sequence. and synchronization session number ;
[0052] After receiving the request, the target node compares it with its own state index sequence. Perform item-by-item comparison to identify the set of differing keys. And extract the corresponding state summary to form a differential response set and return it to the requester;
[0053] The current node updates the relevant key-value pairs in its local status directory based on the returned results and records the interaction log;
[0054] The current node will update the interaction record field in the synchronous construction token and then pass it to its subsequent neighbors, triggering the next backbone node to perform the synchronous construction operation;
[0055] After the node at the end of the backbone link completes its interaction and receives the full token, it generates a synchronization completion identifier carrying the current session number. The interaction is completed and the information is transmitted back to the head node of the chain, marking the completion of this Gossip mechanism deployment process.
[0056] Optionally, generating a global state summary at the backbone level includes:
[0057] Configure a set of non-backbone nodes for each backbone node and generate a list of associated nodes locally. The list of associated nodes records the numbers of all non-backbone nodes directly managed by the backbone node.
[0058] At the start of the preset status collection period, each backbone node actively sends a status request to its associated non-backbone nodes. The status request contains a collection time identifier and a request number. After receiving the request, the non-backbone nodes return the status information entry for the current time.
[0059] After receiving the status information returned by all associated non-backbone nodes, the backbone node extracts the status identifier and status summary value one by one, and merges them with its own status information set to form the current local status information set of the node.
[0060] The backbone node sorts the merged state information set according to the state identifier, removes redundant items, and retains only the latest summary value corresponding to each state identifier to form the local state summary of the node, and generates a timestamp for the summary record;
[0061] When the global digest aggregation process is started, the backbone node at the head of the chain initiates an aggregation session to its neighboring nodes. The aggregation message contains the local state summary of the current node and the session identifier, thus initiating the global digest transmission process.
[0062] After receiving an upstream aggregation message, the relay backbone node (referring to the backbone node located between the head and tail of the backbone communication link, undertaking the tasks of "intermediate forwarding" and "aggregation processing") completes an aggregation operation according to the following steps:
[0063] Parse the aggregated message and extract the aggregated state summary and session identifier sent by the upstream node;
[0064] Read the local state summary of this node and compare it item by item with all state identifiers contained in the upstream aggregate state summary;
[0065] For each duplicate state identifier, the more recent state summary value is selected and retained; for newly added state identifiers, they are directly added to the aggregate summary.
[0066] The aggregated summary after comparison and merging is re-encapsulated with the original session identifier into an aggregated message and sent to the downstream backbone node.
[0067] After the aggregated message is transmitted to the end node of the backbone link, the end node performs a final merging operation, completes the global digest construction, generates a digest completion identifier, carries the final aggregation result and session identifier, and returns to the head node along the backbone communication link.
[0068] After receiving the digest completion flag, the head node marks the end of this round of aggregation and archives the global state digest of this round in the backbone node set.
[0069] Optionally, the steps of comparing local state summaries with global state summaries between adjacent backbone nodes to determine whether the IoT network state is consistent, and determining the node range where the discrepancy data is located when the states are inconsistent, include:
[0070] After the global state summary is generated and stored, each backbone node reads the local state summary and the global state summary under the corresponding session identifier stored locally, and establishes a comparison cache for consistency determination locally.
[0071] In the backbone communication link, in accordance with the order within the chain, adjacent backbone nodes are grouped together to form a judgment pair. The backbone node with the smaller sequence number in the chain sends a comparison trigger message to its subsequent adjacent backbone nodes. The comparison trigger message contains at least the local state summary index list and the global state summary index list of the node.
[0072] Upon receiving the comparison trigger message, the backward backbone node executes the following processing steps in sequence:
[0073] Read and compare the list of local state summary indexes carried in the trigger messages one by one;
[0074] Search for the corresponding status identifier in the local global status summary to determine if a corresponding entry exists;
[0075] For status identifiers that have corresponding entries, compare their status summary values to see if they are consistent.
[0076] Record the status flags that do not have a corresponding entry or whose summary values are inconsistent as difference status flags, and form a difference flag list;
[0077] After completing the above comparison, the backward backbone node encapsulates the list of differences and the corresponding in-chain node numbers into a comparison result message and returns it to the forward backbone node.
[0078] After receiving the comparison result message from the backward backbone node, the forward backbone node merges the comparison result with its own previous judgment result and records the backbone node number that caused the difference.
[0079] The process of comparing adjacent nodes is repeated node by node along the backbone communication link until the backbone node at the end of the link completes the comparison and returns the result. The backbone node at the beginning of the link summarizes all the comparison results to form a difference record table containing the set of differences in backbone node numbers.
[0080] The backbone node at the head of the chain sorts the difference record table according to the chain number order. If the difference record table is empty, it is determined that the IoT network status is consistent.
[0081] If the difference record table is not empty, the first backbone node selects the backbone node with the smallest number in the chain from the difference record table as the difference start node and selects the backbone node with the largest number in the chain as the difference end node, and the backbone node interval between the two is determined as the node range where the difference data is located.
[0082] After determining the range of differing nodes, the head backbone node generates a differing range identifier and sends a notification message containing the differing range identifier and a list of corresponding differing status identifiers to all backbone nodes within the differing node range.
[0083] The beneficial effects of this invention are:
[0084] By employing the PEGASIS protocol to construct a single-chain backbone communication link in the selected backbone node set, the backbone nodes are connected sequentially to form a communication structure without branches or loops. This avoids the path redundancy and control complexity problems existing in traditional multi-hop or mesh topologies, which helps to reduce link maintenance overhead, reduce competitive communication behavior between nodes, and improve the controllability and overall energy efficiency of network communication from a structural level.
[0085] By deploying a backbone-constrained Gossip synchronization model on the backbone communication link, the synchronization interaction is strictly limited to the backbone nodes, and non-backbone nodes do not participate in the synchronization diffusion process. This effectively reduces the scope of synchronization, reduces the communication load and energy consumption of irrelevant nodes, and suppresses the synchronization generalization and communication storm problems that may be caused by the unconstrained Gossip mechanism. This gives the network state synchronization process clear boundaries and predictable communication scale. Attached Figure Description
[0086] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:
[0087] Figure 1 This is a flowchart of a low-power wireless communication networking system and method for the Internet of Things proposed in this invention;
[0088] Figure 2 This is a schematic diagram of the backbone node single-chain communication structure based on the PEGASIS protocol proposed in this invention. Detailed Implementation
[0089] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.
[0090] refer to Figure 1 - Figure 2 A low-power wireless communication networking system and method for the Internet of Things (IoT) includes the following steps:
[0091] The node selection module selects the backbone node set and divides the non-backbone node set from the Internet of Things network based on node communication quality and energy consumption indicators.
[0092] The backbone chain construction module uses the PEGASIS protocol to construct a single-chain structure for the backbone node set, generating a backbone communication link that includes the chain head and chain tail.
[0093] The synchronous deployment module deploys a backbone-constrained Gossip synchronization model on the backbone chain, ensuring that synchronization occurs only between backbone nodes and excluding non-backbone nodes from participating.
[0094] The summary generation module generates a local summary for each backbone node, which includes its own state and the states of the non-backbone nodes under its jurisdiction. These summaries are then aggregated sequentially along the backbone chain to form a global summary.
[0095] The consistency determination module compares the local and global summaries of adjacent backbone nodes to determine whether the network state is consistent, and marks the difference position when there is a difference.
[0096] The differential synchronization module extracts differential data based on the differential position and encapsulates it into a synchronization packet, which is transmitted hop by hop in the backbone. The synchronization packet is deduplicated and merged at each relay node until it converges and is transmitted.
[0097] The control module freezes the synchronization operation and enters a low-power state when the consistency determination result is consistent, and only activates the synchronization process when the topology change or parameter update event is triggered.
[0098] In this embodiment, the modules are interconnected using the following method:
[0099] The performance of each communication node in the Internet of Things network is evaluated, and the nodes are divided into a backbone node set and a non-backbone node set based on the communication quality and energy consumption indicators of each node.
[0100] A chain-based construction method is adopted, in which the backbone nodes in the backbone node set are organized sequentially according to the PEGASIS protocol to generate a backbone communication link containing the head node and the tail node.
[0101] A backbone-constrained Gossip synchronization mechanism is deployed in the backbone communication link, which limits the synchronization operation to only within the backbone node set, and non-backbone nodes do not participate in the synchronization interaction.
[0102] Each backbone node collects the state information of non-backbone nodes in its associated set of non-backbone nodes, merges it with its own state information to generate a local state summary, and then transmits and aggregates it hop by hop along the backbone communication link to generate a global state summary at the backbone link level.
[0103] By comparing the local state summary and the global state summary between adjacent backbone nodes, it is determined whether the IoT network state is consistent, and when the state is inconsistent, the node range where the difference data is located is determined.
[0104] Based on the determined node range, target difference data is extracted, differential synchronization data packets are generated, and transmitted hop by hop along the backbone communication link. Each relay backbone node in the backbone communication link performs deduplication, merging, and overlay processing on the differential synchronization data packets, so that the differential data converges monotonically during the propagation process.
[0105] When the network status is determined to be consistent, the backbone constraint Gossip synchronization mechanism is frozen and enters a low-communication power consumption mode; when a change in network topology or parameter update event is detected, the backbone constraint Gossip synchronization mechanism is reactivated to resume the synchronization process.
[0106] In this embodiment, the division into a backbone node set and a non-backbone node set includes:
[0107] Within the set evaluation period, the communication success rate, link stability and power consumption per unit time of each communication node are collected to construct a node-level performance evaluation information set.
[0108] Based on the performance evaluation information set, the comprehensive evaluation value of each communication node is calculated. This comprehensive evaluation value is determined by the control capability that simultaneously considers the level of communication quality and the level of energy consumption. The higher the communication quality and the lower the energy consumption of the communication node, the higher its comprehensive evaluation value.
[0109] All communication nodes are sorted from high to low according to their comprehensive evaluation values, and a portion of the communication nodes located within the target range are selected according to a preset number threshold to form a preliminary set of backbone nodes.
[0110] Further topology distribution analysis is performed on the communication nodes in the initial selection set of backbone nodes. If there are nodes with overlapping coverage areas or redundant control capabilities, they are removed according to geographical distribution priority, and only communication nodes with representative distribution locations in the network topology are retained.
[0111] The communication nodes that have completed the topology optimization and screening are identified as the backbone node set, and the remaining communication nodes are classified as the non-backbone node set, thus completing the node hierarchical partitioning process.
[0112] Topology distribution analysis refers to the structural analysis of the topology layout of communication nodes after the initial selection set of backbone nodes is formed, based on their geographical location and communication coverage in physical space. This analysis identifies and eliminates nodes with overlapping control functions or overly dense communication paths in local areas. Specifically, it includes: statistically analyzing the relative distances and communication radius overlaps between candidate backbone nodes, constructing a connection graph between nodes, and identifying functionally redundant nodes in adjacent areas according to preset minimum coverage spacing or non-overlapping connection rules; by retaining nodes with high communication control centrality, uniform distribution, or excellent link stability, and deleting redundant nodes, the analysis ensures that backbone nodes are representative and coverage-independent in the topology structure. This analysis improves the structural efficiency of backbone chain construction and avoids problems such as link loops, dense control paths, or redundant synchronization processes in chain topologies.
[0113] In this embodiment, generating a backbone communication link including a head node and a tail node includes:
[0114] After the set of backbone nodes is determined, the physical location information of each backbone node in the Internet of Things network is obtained, and the communication distance between any two backbone nodes is calculated based on the physical location information to form a set of distance relationships between backbone nodes.
[0115] Based on the set of distance relationships, calculate the total length of the link formed by connecting the remaining backbone nodes in turn when each backbone node in the backbone node set is used as the starting point of the chain, and select the backbone node that minimizes the total link length as the starting node of the chain construction, and determine this node as the chain head node.
[0116] The backbone communication link construction process is initialized by using the head node as the initial connected node.
[0117] In the remaining unconnected backbone nodes, chain-like organization steps are performed in the following fixed order:
[0118] Starting from the current chain node, select the backbone node with the smallest communication distance to the current chain node from all unconnected backbone nodes as the next connection node;
[0119] Establish a unique chain connection between the next connection node and the current chain end node, mark the next connection node as a connected node, and update the current chain end node to the next connection node;
[0120] After each node connection is completed, an integrity check is performed on the current backbone communication link. If a node other than the current link end node is detected as the connection target, the connection is cancelled and the node selection step is re-executed until the link structure contains only a single extension direction.
[0121] Repeat the above node selection, connection and verification process until all backbone nodes in the backbone node set are sequentially connected to form a single-chain communication path that does not contain branches or form loops.
[0122] After the single-chain communication path is formed, the last connected backbone node is determined as the tail node, and a unique intra-chain sequence identifier is assigned to each backbone node according to the connection order from the head node to the tail node.
[0123] Based on the intra-chain sequence identifier, information about the forward and backward adjacent backbone nodes is recorded for each backbone node to generate structural description information of the backbone communication link.
[0124] In this embodiment, the backbone-constrained Gossip synchronization mechanism includes:
[0125] After the backbone communication link is constructed, each backbone node is numbered according to its physical order within the link, generating a unique in-link number. A backbone node adjacency table is constructed based on the link connection relationship, and the adjacency table contains the forward link number of the current node. With chain backward numbering The backbone node adjacency list is not propagated to non-backbone nodes after initialization;
[0126] The head node generates a Gossip interaction control table and broadcasts it to all backbone nodes. The control table defines structural constraint parameters for synchronous interactions, including the maximum number of interaction hops within the chain. Synchronization session number generation rules, interaction limit, and token field structure;
[0127] After receiving the control list, each backbone node generates a Gossip interaction candidate set locally. Its construction rules are as follows:
[0128] ;
[0129] in, This is the in-chain number of the current backbone node. To constrain the number of hops in interactions, we ensure that the interaction objects are limited to other backbone nodes that are physically adjacent within the chain, thus limiting the synchronous diffusion path from the mechanism construction perspective.
[0130] Each backbone node establishes a local state directory structure, which consists of several state entries, each containing key-value pairs. ,in For status keys, For the state digest corresponding to this key, all key values are arranged in lexicographical order to form a state index sequence. ;
[0131] When the synchronization period conditions are met, the head node generates a synchronization session number. It then sends a synchronization build token to its neighbors to initiate the current round of backbone constraint Gossip synchronization build process;
[0132] After receiving the synchronization build token, each backbone node performs a synchronization build operation once, following these steps:
[0133] Based on the interactive candidate set Determine the current interaction target node Its generation rules are as follows:
[0134] ;
[0135] in, This indicates the unique synchronous interaction object selected by this node in the current session, ensuring that each round of synchronous build operation triggers only one point-to-point interaction;
[0136] Current node to target node Send a synchronization request containing the current state index sequence. and synchronization session number ;
[0137] After receiving the request, the target node compares it with its own state index sequence. Perform item-by-item comparison to identify the set of differing keys. And extract the corresponding state summary to form a differential response set and return it to the requester;
[0138] The current node updates the relevant key-value pairs in its local status directory based on the returned results and records the interaction log;
[0139] The current node will update the interaction record field in the synchronous construction token and then pass it to its subsequent neighbors, triggering the next backbone node to perform the synchronous construction operation;
[0140] After the node at the end of the backbone link completes its interaction and receives the full token, it generates a synchronization completion identifier carrying the current session number. The interaction is completed and the information is transmitted back to the head node of the chain, marking the completion of the Gossip mechanism deployment process;
[0141] Throughout the construction process, non-backbone nodes are excluded from the synchronization mechanism structure construction because they do not have an in-chain number, are not included in the candidate set, and cannot receive synchronization construction tokens and state indexes, thus ensuring that the structural boundaries of backbone constraints are clear and controllable.
[0142] In this embodiment, generating a global state summary at the backbone link level includes:
[0143] After the network deployment is completed, configure the corresponding set of non-backbone nodes for each backbone node, and generate a list of associated nodes locally. This list records the numbers of all non-backbone nodes directly managed by the backbone node.
[0144] At the start of the preset status collection period, each backbone node actively sends a status request to its associated non-backbone nodes. The status request contains a collection time identifier and a request number. After receiving the request, the non-backbone nodes return the status information entry for the current time.
[0145] After receiving the status information returned by all associated non-backbone nodes, the backbone node extracts the status identifier and status summary value one by one, and merges them with its own status information set to form the current local status information set of the node.
[0146] The backbone node sorts the merged state information set according to the state identifier, removes redundant items, and retains only the latest summary value corresponding to each state identifier to form the local state summary of the node, and generates a timestamp for the summary record;
[0147] When the global digest aggregation process is started, the backbone node at the head of the chain initiates an aggregation session to its neighboring nodes. The aggregation message contains the local state summary of the current node and the session identifier, which is used to initialize the global digest transmission process.
[0148] After receiving an upstream aggregation message, the relay backbone node completes an aggregation operation by following these steps:
[0149] Parse the aggregated message and extract the aggregated state summary and session identifier sent by the upstream node;
[0150] Read the local state summary of this node and compare it item by item with all state identifiers contained in the upstream aggregate state summary;
[0151] For each duplicate state identifier, the more recent state summary value is selected and retained; for newly added state identifiers, they are directly added to the aggregate summary.
[0152] The aggregated summary after comparison and merging is re-encapsulated with the original session identifier into an aggregated message and sent to the downstream backbone node.
[0153] After the aggregated message is transmitted to the end node of the backbone link, the node performs the final merge operation, completes the global digest construction, generates a digest completion identifier, carries the final aggregation result and session identifier, and returns to the head node along the backbone communication link.
[0154] After receiving the digest completion flag, the head node marks the end of this round of aggregation and archives the global state digest of this round in the backbone node set for subsequent consistency judgment or differential synchronization operations.
[0155] In this embodiment, the consistency of the IoT network state is determined by comparing the local state summary and the global state summary between adjacent backbone nodes, and the range of nodes containing the discrepancy data is determined when the states are inconsistent.
[0156] After the global state summary is generated and stored, each backbone node reads the local state summary and the global state summary under the corresponding session identifier stored locally, and establishes a comparison cache for consistency determination locally.
[0157] In the backbone communication link, in accordance with the order within the chain, adjacent backbone nodes are grouped together to form a judgment pair. The backbone node with the smaller sequence number in the chain sends a comparison trigger message to its subsequent adjacent backbone nodes. The comparison trigger message contains at least the local state summary index list and the global state summary index list of the node.
[0158] Upon receiving the comparison trigger message, the backward backbone node executes the following processing steps in sequence:
[0159] Read and compare the list of local state summary indexes carried in the trigger messages one by one;
[0160] Search for the corresponding status identifier in the local global status summary to determine if a corresponding entry exists;
[0161] For status identifiers that have corresponding entries, compare their status summary values to see if they are consistent.
[0162] Record the status flags that do not have a corresponding entry or whose summary values are inconsistent as difference status flags, and form a difference flag list;
[0163] After completing the above comparison, the backward backbone node encapsulates the list of differences and the corresponding in-chain node numbers into a comparison result message and returns it to the forward backbone node.
[0164] After receiving the comparison result message from the backward backbone node, the forward backbone node merges the result with its own previous judgment result and records the backbone node number that caused the difference.
[0165] The process of comparing adjacent nodes is repeated node by node along the backbone communication link until the backbone node at the end of the link completes the comparison and returns the result. The backbone node at the beginning of the link summarizes all the comparison results to form a difference record table containing the set of differences in backbone node numbers.
[0166] The backbone node at the head of the chain sorts the difference record table according to the chain number order. If the difference record table is empty, it is determined that the IoT network status is consistent.
[0167] If the difference record table is not empty, the first backbone node selects the backbone node with the smallest number in the chain from the difference record table as the difference start node and selects the backbone node with the largest number in the chain as the difference end node, and the backbone node interval between the two is determined as the node range where the difference data is located.
[0168] After determining the range of differential nodes, the first backbone node generates a differential range identifier and sends a notification message containing the differential range identifier and a list of corresponding differential status identifiers to all backbone nodes within the differential node range, in order to limit the execution scope of subsequent differential data extraction and synchronization operations.
[0169] In this embodiment, generating differential synchronization data packets includes:
[0170] Once the range of nodes containing the differential data is determined, the head backbone node sends a differential extraction instruction to each backbone node within that range. The differential extraction instruction contains a list of differential status identifiers that need to be synchronized and a synchronization session number.
[0171] Upon receiving the differential extraction instruction, each backbone node performs the following operations in sequence:
[0172] Read the local status directory;
[0173] Match each status identifier in the list of differing status identifiers one by one;
[0174] Extract the corresponding state summary value, and add the in-chain number of the node and the generation time identifier to each state summary to form a set of differential entries;
[0175] After sorting the differential entry set according to the status identifier, the backbone node encapsulates it into a differential synchronization data packet and sends it to its adjacent backbone nodes in the direction of the backbone communication link.
[0176] Upon receiving a differential synchronization data packet from an upstream node, any relay backbone node does not forward it directly. Instead, it processes each differential entry in the data packet in the following fixed order:
[0177] Read the status flag of the differential entry and search for an entry with the same status flag in the locally maintained temporary differential cache;
[0178] If no matching status identifier exists, the differential entry is written to the temporary differential cache.
[0179] If there are identical status identifiers, compare the generation time identifiers of the two difference entries, retain only the difference entry with the newer time identifier, and overwrite the original entry;
[0180] Remove overwritten or outdated differential entries from the temporary differential cache;
[0181] After processing all differential entries, the relay backbone node reorders the differential entries in the temporary differential buffer according to their status identifiers, repackages them into new differential synchronization data packets, and sends them to its adjacent backbone nodes.
[0182] The above differential entry processing and forwarding process is repeated node by node along the backbone communication link, so that any state identifier retains at most one differential entry in the differential synchronization data packet of any node, and the entry can only be updated to a version with a larger time identifier during the propagation process.
[0183] After the differential synchronization data packet is transmitted to the end backbone node in the differential node range, the end backbone node completes the last differential entry processing, and takes the final set of differential entries as the differential synchronization result, generates a synchronization completion identifier, and sends it back to the head backbone node along the backbone communication link.
[0184] Through the above hop-by-hop processing procedure, the differential synchronization data gradually reduces duplicate entries during its propagation along the backbone communication link and continues to converge along the propagation direction, ultimately forming a differential synchronization result without redundant status identifiers.
[0185] In this embodiment, the steps of freezing the running state of the backbone-constrained Gossip synchronization mechanism when the network status is determined to be consistent, and reactivating the backbone-constrained Gossip synchronization mechanism to restore the synchronization process when a network topology change or parameter update event is detected include:
[0186] After completing a network consistency determination and the determination result is consistent, the first backbone node generates a freeze command and sends it to its adjacent backbone nodes along the backbone communication link. After receiving the freeze command, each backbone node stops sending synchronization construction tokens, stops triggering synchronization interaction, records the freeze session number locally, and enters a low communication power consumption operation state.
[0187] In the frozen state, each backbone node maintains the backbone communication link structure information and status directory unchanged, and only sends link maintenance probe messages to its forward and backward adjacent backbone nodes at a preset low frequency period to detect changes in link connectivity.
[0188] When any backbone node detects that the adjacent link keeps probing continuously failing, the adjacency relationship of the backbone nodes changes, or the backbone node set is adjusted, a topology change event identifier is generated and reported to the head backbone node.
[0189] When any backbone node detects an update to the status directory field, a change in synchronization parameters, or a change in the set of differential status identifiers, it generates a parameter update event identifier and reports it to the head backbone node.
[0190] After receiving a topology change event identifier or parameter update event identifier, the first backbone node generates a reactivation instruction and sends it to all backbone nodes along the backbone communication link. The reactivation instruction contains a new activation session number and an event type identifier.
[0191] Upon receiving the reactivation command, each backbone node unfreezes, updates its local link structure information or status directory index according to the event type, and reinitializes the synchronization build token field.
[0192] After all backbone nodes have completed the recovery operation, the first backbone node initiates a new round of backbone-constrained Gossip synchronization sessions to resume the synchronization process.
[0193] Example:
[0194] In this embodiment, the present invention is applied to a typical large-scale industrial equipment wireless monitoring IoT network. This network deploys numerous low-power wireless communication nodes for long-term collection and reporting of operating status, energy consumption parameters, and environmental monitoring data from distributed industrial equipment. The communication nodes in the network are battery-powered, and communication between nodes is multi-hop via low-power wireless links. The overall network needs to minimize communication energy consumption while ensuring consistency of status information to meet the requirements of long-term unattended operation.
[0195] Before this invention, such networks typically employed a flat network structure, with all communication nodes participating in state synchronization and parameter updates within a fixed synchronization period. Each node needed to periodically broadcast its own state information and receive synchronization data from other nodes. As the network size increased, the number of synchronization messages increased dramatically, leading to severe link contention, frequent duplicate data, and some nodes being woken up multiple times in a short period to perform synchronization operations, resulting in uneven energy consumption and premature node failure. Especially when the network state remained stable for a long period, the synchronization behavior continued, resulting in significant communication and energy waste.
[0196] To address the aforementioned issues, this embodiment introduces a low-power wireless communication networking system and method for the Internet of Things (IoT) proposed in this invention. A node screening process is performed on all communication nodes in the network. During this process, communication success rate, link stability, and power consumption data per unit time are continuously collected for each communication node within a preset evaluation period. The communication success rate is obtained by statistically analyzing the proportion of times a node successfully transmits data within the evaluation period to the total number of transmissions. Link stability is obtained by statistically analyzing the frequency of link disconnections and reconnections between adjacent nodes. Power consumption data per unit time is recorded by the node's local power consumption metering module. Based on the above data, the system calculates a comprehensive evaluation value for each communication node. This comprehensive evaluation value reflects both communication quality level and energy consumption control capability; nodes with higher communication quality and lower energy consumption have higher comprehensive evaluation values.
[0197] After obtaining the comprehensive evaluation values of all nodes, the system sorts the communication nodes from highest to lowest comprehensive evaluation value, and selects the top-ranked nodes as the initial backbone node set based on a preset quantity threshold. Subsequently, the system performs topology distribution analysis on the initial backbone node set, identifying nodes with overlapping coverage or redundant control capabilities based on the physical location and communication coverage of each node. Only nodes that are evenly distributed and representative in the network topology are retained, ultimately forming the backbone node set, while the remaining nodes are classified as non-backbone node sets.
[0198] After the backbone node set is determined, the system performs a backbone chain construction process. First, the system obtains the physical location information of each backbone node and calculates the communication distance between any two backbone nodes, forming a set of distance relationships. Based on this, with the goal of minimizing the overall link length, the system selects a suitable backbone node as the chain head node and, following the chain organization rules of the PEGASIS protocol, sequentially selects the backbone node with the smallest communication distance to the current chain end node that is not yet connected, starting from the chain head node, and connects them accordingly. After each connection is completed, the system verifies the current link structure to ensure that there are no forks or loops in the link. By repeating the above process, all backbone nodes are sequentially connected, forming a single-chain backbone communication link with a clearly defined chain head and chain tail.
[0199] After the backbone communication link is constructed, the system deploys a backbone-constrained Gossip synchronization model on this link. The system assigns a unique intra-link ID to each backbone node and generates adjacency information for each backbone node based on the link connection relationship, containing only forward and backward adjacent backbone nodes. The structural constraint parameters for synchronization interaction are uniformly generated by the head node and distributed to all backbone nodes. These constraint parameters limit synchronization interaction to only between backbone nodes that are adjacent within the chain or within a limited hop count range. Non-backbone nodes do not have intra-link IDs and cannot receive synchronization control information, thus structurally excluding them from the synchronization mechanism.
[0200] During network operation, each backbone node sends status requests to its associated non-backbone nodes according to a preset status collection cycle. After the non-backbone nodes return their current status information, the backbone nodes merge the received non-backbone node status information with their own status information, organize it according to the status identifier, remove redundant data, and generate a local status summary containing a timestamp. During the global status aggregation phase, the head backbone node initiates an aggregation session, transmitting its local status summary hop-by-hop along the backbone communication link. Upon receiving the aggregation message, relay backbone nodes compare and merge the upstream summary with their own local status summary. For identical status identifiers, only the data with the updated timestamp is retained, thus gradually forming the global status summary.
[0201] After the global state summary is generated, the system executes a consistency determination process. Adjacent backbone nodes compare their local state summaries with the global state summary, identifying cases of missing state identifiers or inconsistent state values, and then summarize the comparison results node by node along the backbone link. The head backbone node determines whether the network state is consistent based on the summarized results. If no difference is found, the system freezes the synchronization process, putting backbone and non-backbone nodes into a low-communication-power state. If a state difference is found, the system determines the range of nodes containing the differing data based on the backbone node number of the differing node.
[0202] Once the range of differential nodes is determined, the system initiates the differential synchronization process. Backbone nodes within the differential range extract the corresponding state summary value according to the differential state identifier and encapsulate it into differential synchronization data packets for hop-by-hop transmission along the backbone link. Upon receiving the differential synchronization data packets, each relay backbone node sequentially performs deduplication and overwriting processing on the differential entries. For the same state identifier, only the differential entry with the more recent generation time is retained. After processing, the data is re-encapsulated and forwarded, ensuring continuous convergence of the differential data during propagation.
[0203] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.
Claims
1. A low-power wireless communication networking system for the Internet of Things, characterized in that, include: The node selection module selects the backbone node set and divides the non-backbone node set from the Internet of Things network based on node communication quality and energy consumption indicators. The backbone chain construction module uses the PEGASIS protocol to construct a single-chain structure for the backbone node set, generating a backbone communication link that includes the chain head and chain tail. The synchronous deployment module deploys a backbone-constrained Gossip synchronization model on the backbone chain, ensuring that synchronization occurs only between backbone nodes and excluding non-backbone nodes from participating. The summary generation module generates a local summary for each backbone node, which includes its own state and the states of the non-backbone nodes under its jurisdiction. These summaries are then aggregated sequentially along the backbone chain to form a global summary. The consistency determination module compares the local and global summaries of adjacent backbone nodes to determine whether the network state is consistent, and marks the difference position when there is a difference. The differential synchronization module extracts differential data based on the differential position and encapsulates it into a synchronization packet, which is transmitted hop by hop in the backbone. The synchronization packet is deduplicated and merged at each relay node until it converges and is transmitted. The control module freezes the synchronization operation and enters a low-power state when the consistency determination result is consistent, and only activates the synchronization process when the topology change or parameter update event is triggered.
2. A method for low-power wireless communication networking in the Internet of Things, characterized in that, The modules are connected in the following way: The performance of each communication node in the Internet of Things network is evaluated, and the nodes are divided into a backbone node set and a non-backbone node set based on the communication quality and energy consumption indicators of each node. A chain-based construction method is adopted, in which the backbone nodes in the backbone node set are organized sequentially according to the PEGASIS protocol to generate a backbone communication link containing the head node and the tail node. Deploy a backbone-constrained Gossip synchronization mechanism in the backbone communication link to limit synchronization operations to only within the backbone node set, and non-backbone nodes do not participate in synchronization interactions; Each backbone node collects the state information of non-backbone nodes in its associated set of non-backbone nodes, merges it with its own state information to generate a local state summary, transmits and aggregates it hop by hop along the backbone communication link to generate a global state summary at the backbone link level. By comparing the local state summary and the global state summary between adjacent backbone nodes, it is determined whether the IoT network state is consistent, and when the state is inconsistent, the node range where the difference data is located is determined. Based on the determined node range, target difference data is extracted, differential synchronization data packets are generated, and transmitted hop by hop along the backbone communication link. Each relay backbone node in the backbone communication link performs deduplication, merging, and overlay processing on the differential synchronization data packets to ensure that the differential data converges monotonically during the propagation process. When the network status is determined to be consistent, the backbone constraint Gossip synchronization mechanism is frozen and enters a low-communication power consumption mode; when a change in network topology or parameter update event is detected, the backbone constraint Gossip synchronization mechanism is reactivated to resume the synchronization process.
3. The IoT low-power wireless communication networking method according to claim 2, characterized in that, The nodes are divided into a backbone node set and a non-backbone node set, including: Within the set evaluation period, the communication success rate, link stability and power consumption per unit time of each communication node are collected to construct a node-level performance evaluation information set. Based on the performance evaluation information set, the comprehensive evaluation value of each communication node is calculated. The comprehensive evaluation value is determined by considering the control capability of both communication quality and energy consumption level. The communication node with higher communication quality and lower energy consumption has a higher comprehensive evaluation value. All communication nodes are sorted from high to low according to their comprehensive evaluation values, and a portion of the communication nodes located within the target range are selected according to a preset number threshold to form a preliminary set of backbone nodes. Further topology distribution analysis is performed on the communication nodes in the initial selection set of backbone nodes. If there are nodes with overlapping coverage areas or redundant control capabilities, they are removed according to geographical distribution priority, and only communication nodes with representative distribution locations in the network topology are retained. The communication nodes that have completed the topology optimization and screening are identified as the backbone node set, and the remaining communication nodes are classified as the non-backbone node set, thus completing the node hierarchical partitioning process.
4. The IoT low-power wireless communication networking method according to claim 2, characterized in that, Generating a backbone communication link that includes the head node and the tail node includes: After the set of backbone nodes is determined, the physical location information of each backbone node in the Internet of Things network is obtained, and the communication distance between any two backbone nodes is calculated based on the physical location information to form a set of distance relationships between backbone nodes. Based on the distance relationship set, for each backbone node in the backbone node set, calculate the total length of the link formed by connecting the remaining backbone nodes in sequence when it is used as the chain starting point, and select the backbone node that minimizes the total link length as the starting node of the chain construction, and determine the starting node as the chain head node. The backbone communication link construction process is initialized by using the head node as the initial connected node. In the remaining unconnected backbone nodes, chain-like organization steps are performed in the following fixed order: Starting from the current chain node, select the backbone node with the smallest communication distance to the current chain node from all unconnected backbone nodes as the next connection node; Establish a unique chain connection between the next connection node and the current chain end node, mark the next connection node as a connected node, and update the current chain end node to the next connection node; After each node connection is completed, an integrity check is performed on the current backbone communication link. If a node other than the current link end node is detected as the connection target, the connection is cancelled and the node selection step is re-executed until the link structure contains only a single extension direction. Until all backbone nodes in the backbone node set are sequentially connected to form a single-chain communication path that does not contain branches or form loops; After the single-chain communication path is formed, the last connected backbone node is determined as the tail node, and a unique intra-chain sequence identifier is assigned to each backbone node according to the connection order from the head node to the tail node. Based on the intra-chain sequence identifier, information about the forward and backward adjacent backbone nodes is recorded for each backbone node to generate structural description information of the backbone communication link.
5. The IoT low-power wireless communication networking method according to claim 2, characterized in that, The backbone-constrained Gossip synchronization mechanism includes: After the backbone communication link is constructed, each backbone node is numbered according to its physical order within the link, generating a unique in-link number. A backbone node adjacency table is constructed based on the link connection relationship, and the adjacency table contains the forward link number of the current node. With chain backward numbering The backbone node adjacency list is not propagated to non-backbone nodes after initialization; The head node generates a Gossip interaction control table and broadcasts it to all backbone nodes. The control table defines structural constraint parameters for synchronous interactions, including the maximum number of interaction hops within the chain. Synchronization session number generation rules, interaction limit, and token field structure; After receiving the control list, each backbone node generates a Gossip interaction candidate set locally. Its construction rules are as follows: ; in, This is the in-chain number of the current backbone node. To constrain the number of hops in interactions, ensuring that interactions are limited to other physically adjacent backbone nodes within the chain, the mechanism design limits the synchronization diffusion path. This indicates the candidate interaction object number used by the current node for calculation or selection. The difference in the numbers within the chain is compared with the current node i to determine the interaction pair. Each backbone node establishes a local status directory structure, which consists of... It consists of 10 state entries, each containing key-value pairs. ,in For status keys, For the state digest corresponding to this key, all key values are arranged in lexicographical order to form a state index sequence. ; When the synchronization period conditions are met, the head node generates a synchronization session number. It then sends a synchronization build token to its neighbors to initiate the current round of backbone constraint Gossip synchronization build process; After receiving the synchronization build token, each backbone node performs a synchronization build operation once, following these steps: Based on the interactive candidate set Determine the current interaction target node Its generation rules are as follows: ; in, This indicates that the node is the only selected synchronous interaction object in the current session, ensuring that each round of synchronous construction operation triggers only one point-to-point interaction; Current node to target node Send a synchronization request containing the current state index sequence. and synchronization session number ; After receiving the request, the target node compares it with its own state index sequence. Perform item-by-item comparison to identify the set of differing keys. And extract the corresponding state summary to form a differential response set and return it to the requester; The current node updates the relevant key-value pairs in its local status directory based on the returned results and records the interaction log; The current node will update the interaction record field in the synchronous construction token and then pass it to its subsequent neighbors, triggering the next backbone node to perform the synchronous construction operation; After the node at the end of the backbone link completes its interaction and receives the full token, it generates a synchronization completion identifier carrying the current session number. The interaction is completed and the information is transmitted back to the head node of the chain, marking the completion of this Gossip mechanism deployment process.
6. The IoT low-power wireless communication networking method according to claim 2, characterized in that, Generating a global state summary at the backbone level includes: Configure a set of non-backbone nodes for each backbone node and generate a list of associated nodes locally. The list of associated nodes records the numbers of all non-backbone nodes directly managed by the backbone node. At the start of the preset status collection period, each backbone node actively sends a status request to its associated non-backbone nodes. The status request contains a collection time identifier and a request number. After receiving the request, the non-backbone nodes return the status information entry for the current time. After receiving the status information returned by all associated non-backbone nodes, the backbone node extracts the status identifier and status summary value one by one, and merges them with its own status information set to form the current local status information set of the node. The backbone node sorts the merged state information set according to the state identifier, removes redundant items, and retains only the latest summary value corresponding to each state identifier to form the local state summary of the node, and generates a timestamp for the summary record; When the global digest aggregation process is started, the backbone node at the head of the chain initiates an aggregation session to its neighboring nodes. The aggregation message contains the local state summary of the current node and the session identifier, thus initiating the global digest transmission process. After receiving an upstream aggregation message, the relay backbone node (referring to a backbone node located between the head and tail of the backbone communication link, undertaking the tasks of "intermediate forwarding" and "aggregation processing") completes an aggregation operation according to the following steps: Parse the aggregated message and extract the aggregated state summary and session identifier sent by the upstream node; Read the local state summary of this node and compare it item by item with all state identifiers contained in the upstream aggregate state summary; For each duplicate state identifier, the more recent state summary value is selected and retained; for newly added state identifiers, they are directly added to the aggregate summary. The aggregated summary after comparison and merging is re-encapsulated with the original session identifier into an aggregated message and sent to the downstream backbone node. After the aggregated message is transmitted to the end node of the backbone link, the end node performs a final merging operation, completes the global digest construction, generates a digest completion identifier, carries the final aggregation result and session identifier, and returns to the head node along the backbone communication link. After receiving the digest completion flag, the head node marks the end of this round of aggregation and archives the global state digest of this round in the backbone node set.
7. The IoT low-power wireless communication networking method according to claim 2, characterized in that, The steps for determining whether the IoT network state is consistent by comparing the local state summary and the global state summary between adjacent backbone nodes, and determining the node range where the discrepancy data is located when the states are inconsistent, include: After the global state summary is generated and stored, each backbone node reads the local state summary and the global state summary under the corresponding session identifier stored locally, and establishes a comparison cache for consistency determination locally. In the backbone communication link, in accordance with the order within the chain, adjacent backbone nodes are grouped together to form a judgment pair. The backbone node with the smaller sequence number in the chain sends a comparison trigger message to its subsequent adjacent backbone nodes. The comparison trigger message contains at least the local state summary index list and the global state summary index list of the node. Upon receiving the comparison trigger message, the backward backbone node executes the following processing steps in sequence: Read and compare the list of local state summary indexes carried in the trigger messages one by one; Search for the corresponding status identifier in the local global status summary to determine if a corresponding entry exists; For status identifiers that have corresponding entries, compare their status summary values to see if they are consistent. Record the status flags that do not have a corresponding entry or whose summary values are inconsistent as difference status flags, and form a difference flag list; After completing the above comparison, the backward backbone node encapsulates the list of differences and the corresponding in-chain node numbers into a comparison result message and returns it to the forward backbone node. After receiving the comparison result message from the backward backbone node, the forward backbone node merges the comparison result with its own previous judgment result and records the backbone node number that caused the difference. The process of comparing adjacent nodes is repeated node by node along the backbone communication link until the backbone node at the end of the link completes the comparison and returns the result. The backbone node at the beginning of the link summarizes all the comparison results to form a difference record table containing the set of differences in backbone node numbers. The backbone node at the head of the chain sorts the difference record table according to the chain number order. If the difference record table is empty, it is determined that the IoT network status is consistent. If the difference record table is not empty, the first backbone node selects the backbone node with the smallest number in the chain from the difference record table as the difference start node and selects the backbone node with the largest number in the chain as the difference end node, and the backbone node interval between the two is determined as the node range where the difference data is located. After determining the range of differing nodes, the head backbone node generates a difference range identifier and sends a notification message containing the difference range identifier and a list of corresponding difference status identifiers to all backbone nodes within the difference range.