Hyper-converged Internet of Things gateway

Abstract

The invention discloses a hyper-converged Internet of Things gateway, and relates to the technical field of Internet of Things. Comprising a network state preloading unit, a cellular automaton control unit and a protocol stack mapping unit, the network state preloading unit is used for carrying out multi-dimensional state acquisition on a heterogeneous access network connected with the hyper-converged Internet of Things gateway and generating a network state preloading set; the cellular automaton control unit is used for creating a cellular automaton node for each piece of network state baseline data based on the network state preloading set, and converging to obtain an evolution result; and the protocol stack mapping unit is used for mapping the to-be-transmitted data packet into a target protocol stack format according to the evolution result, adding a security label, and outputting the to-be-transmitted data packet to a corresponding external network interface. The method has the beneficial effects of improving the network adaptability, the abnormity identification precision, the protocol selection flexibility and the data transmission security, and is suitable for complex, dynamic and high-concurrency application scenes of the Internet of Things.

Description

Technical Field

[0001] The present invention relates to the technical field of the Internet of Things, and particularly to a hyper-converged Internet of Things gateway. Background Art

[0002] Currently, the widely deployed Internet of Things gateways generally adopt the method of data forwarding control based on static protocol mapping, fixed security policies, and single-cycle link detection. The core processing logic of such gateways generally includes the following key components: a network detection module, a protocol stack module, a transmission scheduling module, and a security authentication module. The network detection module periodically scans the status of the access network link, such as detecting parameters such as link reachability, latency, and bandwidth; the protocol stack module encapsulates the incoming or outgoing data into a specified network protocol format; the transmission scheduling module selects the currently available link according to certain rules and completes traffic allocation; the security authentication module attaches encryption or signature processing to the data stream according to the fixed configuration. This technical system has certain usability in the initial stage of the Internet of Things, but limitations gradually emerge in the following two aspects:

[0003] First, in the state acquisition method of heterogeneous links in the prior art, there is a lack of the ability to deeply model the interaction effects between multi-dimensional parameters. Most existing gateways take each link as an independent object and only collect single-dimensional indicators such as RTT or packet loss rate. The data shows a "flat" structure, lacking an abstract mechanism for the co-evolution process of multi-parameter linkages. In the actual scenario of multi-link dynamic evolution, the sudden packet loss of a certain link may not be an isolated event, but is caused by multiple factors such as load migration, encryption failure, and time slot congestion caused by the drastic change of the adjacent link state. The prior art cannot establish this state propagation relationship, resulting in overly passive link management and being unable to predict network behavior at the system level.

[0004] Second, in terms of the evolution and judgment strategy of the network state, most current gateways adopt a fixed threshold judgment mechanism. For example, if the packet loss rate is greater than 3%, the link is marked as unavailable, and if the latency is greater than 100 ms, the link is abandoned, etc. This mechanism lacks the joint judgment of local state and overall trend and cannot perform neighborhood-level joint analysis. When multiple links are simultaneously in a boundary state, the judgment of a single node based on a fixed threshold is extremely likely to fall into a vicious cycle of "frequent switching - performance jitter - re-switching", unable to ensure system stability. In addition, the existing mechanism hardly has the ability of evolutionary memory and cannot adjust the current judgment rule through the previous multi-round state evolution behaviors. Summary of the Invention

[0005] In view of this, the present invention provides a hyperconverged IoT gateway. It pre-loads and collects multi-dimensional states of heterogeneous access networks, constructs a node-level evolution model, and dynamically updates node states based on neighborhood relationships in each iteration cycle. This generates cluster-level states and maps them to target protocol dimension identifiers, ultimately driving adaptive reconfiguration of the protocol stack and attachment of security tags. This system achieves closed-loop linkage of local link state perception, intra-cluster evolution, autonomous early warning, cross-cluster consistency handshake, and protocol mapping. It offers beneficial effects such as improved network adaptability, anomaly identification accuracy, protocol selection flexibility, and data transmission security, making it suitable for complex, dynamic, and high-concurrency IoT application scenarios.

[0006] The technical solution adopted in this invention is as follows:

[0007] The hyperconverged IoT gateway includes: a network state preloading unit, a cellular automaton control unit, and a protocol stack mapping unit. The network state preloading unit performs multi-dimensional state acquisition on the heterogeneous access networks connected to the hyperconverged IoT gateway and generates a network state preloading set. The cellular automaton control unit creates cellular automaton nodes for each network state baseline data based on the network state preloading set, aggregates several cellular automaton nodes into cellular automaton cluster instances according to their access port affiliation, and assigns a unique cluster identifier to each cellular automaton cluster instance. Within a preset iteration period, each cellular automaton cluster instance evolves its node state according to neighborhood evolution rules and generates a cluster-level state based on the node state. Each cluster-level state is then mapped to a target protocol dimension identifier, and the resulting evolution is obtained. The protocol stack mapping unit maps the data packets to be transmitted to the target protocol stack format based on the evolution results, attaches a security label, and outputs the data packets to be transmitted to the corresponding external network interface.

[0008] Furthermore, the network state preloading unit initiates three rounds of scanning on all heterogeneous access ports of the hyperconverged IoT gateway in a fixed order. For each round of scanning, the following information is collected for each access port in sequence: link reachability identifier, round-trip delay identifier, bandwidth estimation identifier, packet loss trend identifier, and encryption negotiation identifier. The above five types of identifiers are combined into a single network state baseline data according to the port number from smallest to largest, and a network state preloading set is generated according to the timestamp index.

[0009] Furthermore, the cellular automaton control unit generates a group of cellular automaton nodes with the same initial state for each network state baseline data in the network state preload set; it divides all cellular automaton nodes into several cellular automaton cluster instances according to their access port affiliation, and assigns a unique cluster number to each cellular automaton cluster instance.

[0010] Furthermore, the process by which the cellular automaton control unit obtains the evolution results includes: at the start of a preset iteration cycle, invoking the initial loading action to load and lock the corresponding network state baseline data for each cellular automaton node; each cellular automaton node reads the current node state of its neighboring nodes from within its own cellular automaton cluster instance according to the preset four-neighbor relationship (up, down, left, and right); for the read current node state of the neighboring nodes, a local evolution judgment action is performed, comparing it one by one according to the following three evolution judgment rules: if the link reachability identifiers of at least two neighboring nodes are unreachable, the current node enters a failure state; if the round-trip delay identifiers of all neighboring nodes differ from its own round-trip delay identifier by the same number... If the packet loss trend indicator of any neighboring node is higher than its own and the encryption negotiation indicator is different, the current node enters a state of alert. Based on the results of the local evolution judgment action, the current node state is updated to one of the following: failure state, stable state, or alert state, and recorded in the local evolution result buffer. All node states in the local evolution result buffer are collected in order of cluster number, and the cluster-level state of the cellular automaton cluster instance is determined by majority voting. According to the cluster number from smallest to largest, the cluster-level state of each cellular automaton cluster instance is mapped to a target protocol dimension identifier, where the target protocol dimension identifier corresponds one-to-one with the cluster-level state. All target protocol dimension identifiers are combined into the evolution result.

[0011] Furthermore, the cellular automaton control unit performs a pre-update process before the start of each preset iteration cycle: each cellular automaton node generates a segmented cyclic redundancy check (CRC) code for its network state baseline data; the nodes broadcast the segmented CRC code in a one-way circular manner within the cluster according to the cluster number order; if any node detects that the segmented CRC code of any neighboring node is inconsistent with the previous record, it immediately updates its own node state to the alert state.

[0012] Furthermore, before the start of each preset iteration cycle, the cellular automaton control unit performs a pre-update process and elects a temporary dominant node for each cellular automaton cluster instance: the nodes are sorted in ascending order according to the round-trip delay identifier recorded in the previous iteration cycle; the time slot number corresponds one-to-one with the sorting result, and the node with the smallest round-trip delay identifier becomes the temporary dominant node in the current iteration cycle; the temporary dominant node activates a six-directional ring neighborhood composed of up, down, left, right and two diagonals within its cluster, while the other nodes maintain their original four-neighborhood relationship.

[0013] Furthermore, before the evolution of each cluster initiation node, the cellular automaton control unit has a temporary leading node collect the current node states of all nodes in the cluster and concatenate them into a state sequence according to the node number; lossless run-length compression is used to compress the state sequence; if the length of the compressed bytes exceeds the preset window threshold, the cluster-level state of the entire cellular automaton cluster instance is directly set to the failure state; otherwise, the normal node evolution continues.

[0014] Furthermore, during node evolution, the cellular automaton control unit detects the difference between its own link reachability identifier and the link reachability identifier of the temporary dominant node for each cellular automaton node. If the difference exceeds the preset impedance window, it temporarily lowers its own packet loss trend identifier threshold and prioritizes entering the alert state in the next round of local evolution judgment. After the difference returns to within the window, the threshold is automatically reset.

[0015] Furthermore, after obtaining the cluster-level states, the cellular automaton control unit divides the cluster numbers into odd and even groups to form the first-stage handshake pairs. The odd-numbered cluster-level states exchange timed double tokens with the next sequential even-numbered cluster-level states. After confirming that their states are consistent, they are merged and mapped into a single target protocol dimension identifier. If any handshake pair fails to complete the double token confirmation within the limited time window, the corresponding target protocol dimension identifier is directly set to a warning flag. All target protocol dimension identifiers are merged and combined into an evolution result, which is then transmitted to the protocol stack mapping unit.

[0016] By adopting the above technical solutions, this invention achieves the following beneficial effects: it significantly improves the accuracy of state perception, evolution processing efficiency, and protocol adaptation capabilities for heterogeneous access networks in the Internet of Things (IoT) environment. Compared to traditional gateway solutions that use fixed threshold judgment and static protocol mapping in existing technologies, this invention introduces a network state preloading mechanism, enabling the system to obtain multi-dimensional, full-port, and time-synchronized network baseline data before each iteration cycle, providing more complete state support for subsequent evolution. Simultaneously, the cellular automaton control unit performs local evolution judgment within each node and dynamically updates the node state based on neighborhood relationships, thereby achieving early detection and local amplification of abnormal states, improving the system's sensitivity and convergence stability in complex network jitter environments. Furthermore, the majority voting mechanism determines the cluster-level state, effectively suppressing interference from isolated anomalies and improving the robustness of overall judgment. This invention also incorporates a time-sequential dual-token handshake mechanism to quickly negotiate cross-cluster state consistency, ensuring global consistency and security of protocol mapping. The protocol stack mapping unit dynamically reconstructs the transport protocol stack format based on evolution results and automatically adds security tags, enabling hierarchical processing of service flows under stable, alert, and failure states, effectively reducing the probability of packet loss, repeated handshakes, and security negotiation failures. Therefore, this invention demonstrates excellent adaptability, stability, and security in IoT gateway applications involving multiple protocols, links, and services, possessing high engineering practical value. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the structure of the hyperconverged IoT gateway in an embodiment of the present invention. Detailed Implementation

[0018] All features disclosed in this specification, or steps in all methods or processes disclosed herein, may be combined in any way, except for mutually exclusive features and / or steps.

[0019] Any feature disclosed in this specification (including any appended claims and abstract) may be replaced by other equivalent or similar features, unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features.

[0020] refer to Figure 1 The network state preloading unit, as the first link in the entire gateway, is responsible for state data acquisition and temporal processing. It polls all heterogeneous access ports in a fixed scanning order, synchronously acquiring five observation dimensions for each poll: link reachability identifier, round-trip delay identifier, bandwidth estimation identifier, packet loss trend identifier, and encryption negotiation identifier. These five identifiers are then strictly combined into network state baseline data in ascending order of port number, and written into the network state preloading set using the system timestamp as an index. In this way, the network state preloading set naturally possesses time-series characteristics, preserving both the horizontal comparison of ports at the same sampling time and the vertical evolution of a single port at adjacent sampling times, providing a complete context for subsequent adaptive evolution.

[0021] After receiving the preloaded set of network states, the cellular automaton control unit instantiates a cellular automaton node in memory for each network state baseline data, ensuring that all nodes have the same initial state. Subsequently, the nodes are clustered and aggregated according to their access port affiliation, forming multiple cellular automaton cluster instances. Each cluster instance is assigned a unique cluster identifier to ensure the isolation and tracking of cluster-level behavior during parallel evolution. At the beginning of each preset iteration cycle, the cellular automaton control unit performs an initial loading action, loading the network state baseline data into its respective nodes and setting write protection locks to prevent data overwriting during iteration. Next, each node reads the current node state of its neighboring nodes according to the four-neighbor relationship (up, down, left, and right) and performs a local evolution judgment action.

[0022] The local evolution judgment action follows three strict sequential judgment rules: First, if the reachability indicators of at least two neighboring nodes are unreachable, the current node immediately transitions to a failed state; second, if the round-trip delay indicators of all neighboring nodes are on the same order of magnitude as its own, the current node maintains a stable state; third, if the packet loss trend indicator of any neighboring node is higher than its own and the encryption negotiation indicator is different, the current node enters a vigilant state. After the local evolution judgment action is completed, the node writes its own state update result into the local evolution result buffer. The cellular automaton control unit then schedules the majority voting method according to the cluster number order to statistically analyze the node states in the local evolution result buffer to determine the cluster-level state of the cellular automaton cluster instance. The majority voting method can still output a stable cluster-level state even when there are a few abnormal fluctuations in the node state distribution, thereby suppressing noise caused by sudden disturbances from isolated links. After generation, each cluster-level state is mapped to the target protocol dimension identifier and encapsulated as an evolution result for use by the protocol stack mapping unit.

[0023] To ensure the evolution results remain highly agile to real-world network state changes, the cellular automaton control unit performs a pre-update process before each iteration. Specifically, each cellular automaton node calculates a segmented cyclic redundancy check (CRC) code for its network state baseline data and broadcasts this code to neighboring nodes via a one-way circular broadcast within the cluster. If any node detects a discrepancy between the segmented CRC code of a neighboring node and the record from the previous iteration, it immediately upgrades its own node state to an alert state and synchronously updates its local evolution result buffer. This design allows network state anomalies to be flagged before the iteration begins, preventing dilution by majority voting during the formal evolution phase. After the pre-update, the cellular automaton control unit elects a temporary dominant node within the cluster based on the round-trip delay (RTD) identifiers of each node from the previous iteration, sorting them from smallest to largest. The node with the smallest and most stable RTD identifier is considered the most sensitive measurement benchmark for real-time link performance and is therefore designated as the temporary dominant node. In the current iteration, a six-directional circular neighborhood consisting of the top, bottom, left, right, and two diagonals is activated to more quickly detect and disseminate state changes observed by the temporary dominant node. After the dominant node expands its neighborhood, the information flow within the cluster increases, but the number of dominant nodes is unique in each cluster, so it will not cause overload on a global scale.

[0024] Before entering formal node evolution, the temporary dominant node aggregates the states of all nodes within the cluster and concatenates them into a state sequence according to node numbers. Then, it calls a lossless run-length compression algorithm to compress the state sequence and calculates the compressed byte length. This length is compared with a preset window threshold. If it exceeds the threshold, it indicates high homogeneity of states within the cluster, meaning a large proportion of nodes are in the same failed or alert state. In this case, the cluster-level state is directly set to a failed state, avoiding the waste of resources by evolving individual nodes one by one in common abnormal scenarios. If the compressed byte length does not reach the threshold, it indicates sufficient diversity of states within the cluster, and the system continues the normal evolution process. During normal evolution, each node continuously monitors the difference between its own link reachability identifier and the temporary dominant node's link reachability identifier. If the difference exceeds the impedance window, the node temporarily lowers its own packet loss trend identifier threshold, making it easier to enter the alert state in the next round of local evolution judgment, thus forming a protective band around the dominant node and isolating potentially faulty links in advance. After the difference returns to the impedance window, the threshold is automatically reset, ensuring that the evolution strategy is both sensitive and not overly conservative in the long term.

[0025] Once all cluster-level states are ready, the cellular automaton control unit pairs cluster numbers according to their parity to form handshake pairs. Odd-numbered cluster-level states and the next sequential even-numbered cluster-level states confirm state consistency by exchanging time-sequential dual tokens. If the handshake pair fails to complete dual token confirmation within a given time window, the corresponding target protocol dimension identifier is immediately set to a warning flag. Subsequent protocol stack mapping units, when processing evolution results containing warning flags, will prioritize protocol families with higher encryption strength and more rigorous handshake mechanisms, and attach additional security labels to the data packets to be transmitted. If dual token confirmation is successful, the two cluster-level states are merged and mapped to a single target protocol dimension identifier, thus logically unifying the states of highly related ports into the same protocol dimension abstraction to reduce redundant decision paths in the protocol mapping stage. After receiving the evolution results, the protocol stack mapping unit maps each target protocol dimension identifier to a predefined multi-protocol mapping table, enabling adaptive switching of the data packets to be transmitted between target protocol stack formats. The evolutionary outcome of a stable state will drive the protocol stack mapping unit to select a low-overhead, high-throughput transport protocol family; the alert state flag will trigger the protocol stack mapping unit to choose a conservative strategy, such as forcibly enabling end-to-end encryption, adding handshake interactions, or inserting keep-alive probe frames; the failure state flag will cause the protocol stack mapping unit to suspend non-critical service flows, retry routing, or actively switch to a backup link. All data packets to be transmitted are sent to the corresponding external network interface after being encapsulated in the target protocol stack format and having a security tag attached, realizing on-demand load balancing and dynamic security level enhancement for heterogeneous access networks.

[0026] Furthermore, the network state preloading unit immediately enters the scanning and scheduling phase after system initialization. The scheduler activates all heterogeneous access ports sequentially according to the fixed order given by the port mapping table built into the hyperconverged IoT gateway, forming triple sampling of the same time period through a three-round scanning mechanism. The first round of scanning mainly captures the link reachability identifier and round-trip delay identifier of the port under no-load conditions, providing a reference baseline for subsequent measurements. The second round of scanning injects a controllable burst load while maintaining the same activation order, performing stress measurement on the bandwidth estimation identifier and packet loss trend identifier. The third round of scanning is performed immediately after the completion of the first two rounds, using a dynamic negotiation handshake process to synchronize and encrypt the negotiation identifier in real time, and quickly corrects the four types of identifiers previously collected. During each round of scanning, the scheduler follows a fixed reporting order of port number from smallest to largest, concatenating the five types of identifiers in the sampling window of this port to form the network state baseline data, and then using a high-precision system clock to generate a timestamp and write it into the network state preloading set as an index. After three rounds of scanning, three network state baseline data will appear at the same timestamp in the network state preloading set, arranged in ascending order by port number. These correspond to three different load perspectives: no-load observation, pressure observation, and negotiation verification. This forms a highly consistent state matrix in both the longitudinal time dimension and the horizontal port dimension, providing precise, rich, and comprehensive evolutionary initial conditions for the cellular automata control unit.

[0027] Furthermore, after receiving the preloaded network state set, the cellular automaton control unit first traverses each network state baseline data in the set and instantiates a group of cellular automaton nodes with the same initial state in memory space. These nodes are uniformly assigned a stable state upon creation, ensuring that all nodes behave consistently before entering the first iteration cycle. This facilitates subsequent evolutionary behavior being driven only by neighborhood information and not disturbed by initial differences. Subsequently, the cellular automaton control unit divides all nodes into several cellular automaton cluster instances based on the access port affiliation information of the nodes. The partitioning process proceeds in ascending order of port number, ensuring that each access port occupies a unique slot in the cluster partitioning table, thereby ensuring that each cluster instance contains only the group of nodes directly related to its port. After partitioning, the system automatically assigns a unique cluster number to each cellular automaton cluster instance. This number is generated using a globally incrementing strategy, which avoids cluster number conflicts and facilitates quick location of cluster instances and their nodes in a distributed operating environment. In this way, the cellular automaton control unit logically completes the mapping from temporal network state baseline data to spatialized cellular automaton topology, laying a unified cluster-level management foundation for subsequent node evolution, cluster-level voting, handshake pair collaboration, and protocol dimension identifier generation.

[0028] Furthermore, the cellular automaton control unit activates a strictly controlled initial loading action at the start of each preset iteration cycle. First, it retrieves the network state preload set index corresponding to the current cycle, precisely locating the network state baseline data for each cellular automaton node. This data is then loaded into the node register area node by node. A write lock is triggered immediately upon loading completion. Once locked, no external process can modify the node register area before the end of the current iteration, fundamentally eliminating the risk of data drift caused by concurrent access. Subsequently, the cellular automaton control unit, based on a predetermined four-neighborhood relation table (up, down, left, right), arranges the reading order for each node within the cluster, allowing nodes to sequentially read the current node state of neighboring nodes in a completely decoupled parallel thread. If a neighboring slot is temporarily empty, the system fills it with the placeholder state cached in the previous cycle, ensuring a complete reading sequence without gaps.

[0029] After completing the collection of neighborhood states, a node immediately performs a local evolution judgment action. This action strictly follows the order of three evolution judgment rules: First, it checks the link reachability indicator. If at least two neighboring nodes report unreachability, the current node immediately switches its state to a failed state and records a failure label in the local evolution result buffer. If no failure condition is triggered, it continues to compare round-trip delay indicators. When the round-trip delay indicators of the four neighboring nodes are all within the same order of magnitude of its own, it indicates that the link performs evenly in terms of latency. The node maintains a stable state and registers a stability label in the buffer. If neither of the first two rules is met, the system then checks the combination of packet loss trend indicator and encryption negotiation indicator. If any neighboring node's packet loss trend indicator is higher than its own and the encryption negotiation indicators of both nodes are inconsistent, the node immediately enters an alert state to maximize the early exposure of potential security vulnerabilities. After the local evolution judgment action is completed, the node writes the updated state along with the corresponding timestamp to the local evolution result buffer. The buffer is divided into independent segments according to cluster number to ensure that cross-cluster data is never confused. Once all nodes in the cluster have reported, the cellular automaton control unit schedules a majority voting process. It traverses the buffer in cluster number order, counting the states of all nodes within each cluster instance. The cluster-level state of the cellular automaton cluster instance is determined based on the state with the most votes. If there is a tie, the cluster-level state is selected according to a priority system: failure first, then alert, and finally stability, to prevent anomalies from being masked. After the cluster-level state is determined, the control unit immediately maps it to a target protocol dimension identifier. The mapping table is written during system compilation to ensure a one-to-one correspondence and immutability. After all cluster instances are mapped, the control unit concatenates the target protocol dimension identifiers sequentially according to the natural order of cluster numbers from smallest to largest, generating the evolution result of this iteration. The evolution result is submitted to the protocol stack mapping unit via the internal bus in a zero-copy manner, allowing the upper layer to read it without waiting, greatly reducing call chain latency. At this point, the cellular automata control unit has completed the entire closed loop of node loading, neighborhood reading, local evolution judgment, buffer registration, cluster-level voting, and dimension mapping within this iteration cycle. The evolution results will directly drive the subsequent protocol stack mapping unit to select the protocol stack format and attach security labels to the data packets to be transmitted, realizing high-speed adaptive feedback and dynamic adjustment of security policies for heterogeneous access network status.

[0030] Furthermore, before each preset iteration cycle actually starts, the cellular automaton control unit inserts a pre-update process to ensure that subsequent node evolution is based on the most reliable and complete network state baseline data. The pre-update process consists of three sequential steps. The first step is segmented cyclic redundancy check (CRC) code generation. Each cellular automaton node calls its built-in verification core to read its network state baseline data in segments, appending CRC bits to each segment, and finally concatenating them to form a segmented CRC code. The segmentation strategy makes the verification granularity superior to overall verification because the five types of identifiers in the network state baseline data are often locally changed due to instantaneous network fluctuations. Segmented verification can quickly identify changed segments without increasing overall overhead, avoiding misinterpreting local changes as overall inconsistencies during subsequent comparisons. The second step is unidirectional circular broadcasting. In this step, nodes establish unidirectional logical channels within their clusters according to cluster numbering, sequentially sending their own segmented CRC codes to the next neighboring node in a clockwise unidirectional circular manner.

[0031] The advantage of ring broadcasting is that it ensures all nodes receive checksums from other nodes without the need for central scheduling, while the unidirectional flow avoids channel congestion caused by bidirectional contention. The entire broadcast process is implemented using a combination of asynchronous non-blocking sending and event-driven receiving. At the start of the broadcast, nodes write to a buffer, and at the end, nodes retrieve checksums in batches from the read buffer to enter the comparison phase. The third step is consistency comparison and early warning triggering. When a node receives a segmented cyclic redundancy checksum from a neighboring node, it immediately compares it segment by segment with the corresponding checksum recorded in the previous iteration cycle. Once a change in the checksum of any segment is detected, the node does not need to wait for cluster-level decision; it directly updates its node state to the alert state and writes the alert state to the local evolution result buffer. The significance of this is to expose potential link anomalies or security risks to the node level in advance, ensuring that new inconsistencies are marked before the majority voting method is used after the formal iteration begins, thus avoiding the dilution of anomalies due to the still dominant number of normal nodes in the cluster. The overall duration of the pre-update process is controlled to be less than 10% of the total iteration cycle length to ensure the real-time performance of the cellular automata model. The cellular automaton control unit will only begin loading once all pre-updates are completed and no new alert statuses appear. Conversely, if too many alerts are triggered, the system can choose to shorten subsequent iteration cycles or increase the weight of alert statuses in the majority voting method to further enhance sensitivity to abnormal links and achieve rapid adaptation to dynamic network environments.

[0032] Furthermore, after the pre-update process is completed and all nodes have generated segmented cyclic redundancy check codes for their network state baseline data and completed one-way ring broadcasting, the cellular automaton control unit immediately switches to the temporary dominant node election phase. The round-trip delay identifier recorded in the previous iteration cycle is used as the sole criterion to minimize decision complexity and convergence time. Specifically, the control unit first initiates a local sorting instruction within each cellular automaton cluster instance. All nodes write their own round-trip delay identifiers into the cluster's shared sorting buffer. Subsequently, driven by a decentralized distributed sorting algorithm, sorting results are generated based on the round-trip delay identifiers from smallest to largest. Simultaneously, the system assigns a time slot number to each row in the sorting table, ensuring a strict mapping relationship between "time slot number and sorting result." This design allows nodes to find their own and their neighbors' time slot locations without additional table lookups during subsequent time-slice polling or synchronization operations. The node corresponding to the first row of the sorting table, i.e., the node with the smallest round-trip delay identifier, is immediately marked as the "temporary dominant node" and assumes the dual responsibility of serving as the cluster's observation benchmark and information aggregation during the current iteration cycle.

[0033] To facilitate a broader and faster perception of the cluster state by the temporary dominant node, the control unit dynamically enables a "six-directional ring neighborhood consisting of up, down, left, right, and two diagonals" in its node configuration. This means that the temporary dominant node can read the states of neighboring nodes in all six directions at once during evolution and write the results back to the local evolution decision process by expanding the neighborhood weight factor. Simultaneously, the remaining nodes in the cluster maintain their original four-neighbor relationships, thus avoiding excessive expansion of the cluster-level neighborhood topology within a single iteration and ensuring a relatively constant computational load. The temporary dominant node is chosen based on the lowest round-trip latency indicator because the links connected to this node are typically closer to the core switching layer of the hyperconverged IoT gateway in terms of physical or logical distance, thus exhibiting higher latency sensitivity and lower transmission impedance, enabling it to detect subtle jitters first in the early stages of network state fluctuations. With the six-directional ring neighborhood enabled, the node can not only cover the original four orthogonal directions when reading the neighborhood state but also adds two diagonal directions, providing a richer multi-dimensional information source for local evolution decisions and improving the prior accuracy of cluster-level state decisions. Meanwhile, the control unit injects a lightweight priority scheduling label into the temporary dominant node, ensuring that its state update has an earlier write window in the local evolution result buffer than ordinary nodes. This reduces the uncertainty caused by timing competition and allows the majority voting method to integrate the dominant node's situation judgment earlier. If, in a certain iteration cycle, the node with the smallest round-trip latency is detected to have significantly increased latency due to link fluctuations compared to the previous cycle, this node will be automatically sorted in descending order in the election process of the next cycle, allowing a new low-latency node to take over the dominant role. This dynamic rotation mechanism ensures that cluster-level decisions are always based on the latest link quality distribution. Through the continuous action chain of "sorting—mapping—expanding neighborhood—priority scheduling," the cellular automaton control unit injects a core evaluation point that self-adjusts as latency fluctuates into each cellular automaton cluster instance. This not only enhances the ability to capture high-frequency, short-latency changes but also ensures, at the macro level, that the hyperconverged IoT gateway can quickly focus on the optimal transmission path when facing multi-port heterogeneous links and reflect it in real time in the subsequent protocol stack mapping logic. This ensures high sensitivity to security situation and fault trends while maintaining throughput.

[0034] Furthermore, after the cellular automata control unit concludes the election of the temporary leader node and before the actual evolution of regular nodes in each cluster is triggered, the system immediately enters a cluster-wide agile health check process undertaken solely by the temporary leader node. The core objective of this process is to determine, with minimal latency, whether a large-scale and homogeneous abnormal cluster has appeared within the cluster, thereby bypassing the high-overhead node-by-node evolution calculations when necessary and directly shifting the decision focus to cluster-level fault response. First, the temporary leader node broadcasts a read-only acquisition command within the cluster according to the node number in ascending order, based on the "node scan order" issued by the control unit. Each selected node sends back its "current node state," which it wrote to the local evolution result buffer during the pre-update phase, intact to the leader node. The leader node maintains a pre-allocated double-buffered circular queue locally, sequentially writing the received states into the first buffer according to the node number index, while simultaneously constructing a "state sequence" in real time in the second buffer. The state sequence is not a simple character concatenation, but rather uses fixed-width state encoding units to carry specific state values. For example, a failure state is encoded as "0xF0", a stable state as "0xAA", and a warning state as "0x55". The advantage of fixed-width encoding is that it avoids the alignment overhead of variable-length fields, allowing subsequent compression algorithms to directly perform run-length recognition at byte boundaries without additional parsing.

[0035] Once the state of the last node is written, the temporary master node immediately activates the on-chip lossless run-length compression module. Unlike the two-stage implementation of ordinary run-length compression (scanning then encoding), to reduce the on-chip buffer resources occupied at one time, the system adopts pipelined run-length compression: the state sequence flows into the compression module byte by byte from high address to low address. The compression module reads and checks whether consecutive bytes are the same. If they are the same, it increments the current run count; if they are different, it immediately writes "run count + run byte" to the compressed output buffer. This process is repeated until the sequence is traversed. The biggest advantage of pipelined implementation is that it can lock the input and output stream rates within a single clock domain, thereby compressing the peak latency to less than a few hundred nanoseconds. At the end of run-length compression, the control logic increments a "compression count register" and generates a complete 16-byte compression header below the register, which includes the compressed byte length, run count, compression end timestamp, and CRC checksum of a single compression cycle. The compression header and the compression body are concatenated and stored in the high-speed shared SRAM area local to the temporary master node.

[0036] At this point, the cellular automaton control unit performs a lock-free comparison between the "compressed byte length" field in the compression header and the "preset window threshold" of the same cluster. This threshold is a static value calculated during the gateway deployment phase based on the number of physical ports, service priority, and historical anomaly probability. It can be adjusted as needed through the maintenance interface without downtime. If the comparison result shows that the "compressed byte length" is greater than the "preset window threshold," the control unit immediately triggers the "cluster-level failure fast track." The fast track first suspends any remaining unstarted regular evolution threads in the cluster to prevent them from continuing to occupy computing resources; then, it forcibly writes the failure status code into the cluster's "cluster-level status register" and pushes this status to the protocol stack mapping unit through a low-latency message queue; immediately afterward, it sends a failure alarm packet with cluster number, trigger time, and compression length information to the upper-level health monitoring bus. Upon receiving a failure alarm packet, the protocol stack mapping unit immediately recalculates the cross-cluster routing table in real time and redirects the service flows involving the cluster port to the backup link or initiates a load reduction mode. At the same time, it automatically upgrades the data encryption negotiation level by one level and adds a context identifier for post-event auditing so that the complete log of this link journey can be traced back after the fault is recovered.

[0037] If the "compressed byte length" is less than or equal to the "preset window threshold," the control unit determines that the cluster state still possesses differentiateable characteristics, indicating that no extreme consistency failure or alert clustering has yet occurred. At this point, the temporary dominant node stores the compressed state sequence into the cluster's redundant data stack for subsequent trend analysis, and then issues an "evolution continue" command, allowing all ordinary nodes to re-enter the normal node evolution process. To avoid the potential skew represented by the newly generated long runs affecting subsequent decisions, the control unit simultaneously increases the dynamic coefficient of the "failure priority" of the cluster in effect during this iteration by 10%, appropriately increasing the influence of failure and alert states in the majority voting method, ensuring they occupy sufficient weight in subsequent cluster-level synthesis without being overwhelmed by the remaining stable states. In addition, the dominant node sends the compressed "number of runs" and "maximum run length" to a background thread called "evolution sensitivity adjuster". The latter makes fine-grained adjustments to the "preset window threshold" for the next cycle according to a predefined linear decay model to ensure that the threshold does not become rigid. In this way, if the network shows a significant stable trend over a period of time, the threshold will be lowered, making it easier for the system to capture low-probability anomalies. Conversely, if the network is in a period of frequent jitter, the threshold will be raised slowly to prevent excessive switching caused by frequent cluster-level failures.

[0038] The entire process, from the temporary leading node starting to pull node states to the system completing threshold judgment, takes only about "tens of microseconds." The core latency occupied by pipelined run-length compression is no more than "compressed byte length / bus width × single-cycle clock," which is negligible for a complete iteration cycle measured in milliseconds. More importantly, by introducing this step before evolution, the cellular automata control unit does not need to invest in any complex machine learning models beforehand, nor does it need to maintain historical training samples. This achieves an effect similar to "rapid shutdown of anomaly clusters," reducing unnecessary evolutionary computational consumption and making the anomaly notification chain shorter, more robust, and more intuitive. Ultimately, regardless of whether rapid failure is triggered or evolution continues, all decision and state metadata are written to the current disaster recovery snapshot file and synchronized to the gateway's built-in persistent link governance database. This allows the backend operations and maintenance system to obtain complete and structured before-and-after evolution comparisons in minute-level fault backtracking, providing actionable root cause data for subsequent long-term optimization.

[0039] Furthermore, in the conventional node evolution cycle driven by the cellular automaton control unit, each cellular automaton node initiates a dedicated impedance monitoring thread in parallel. The sampling period of this thread is synchronized with the microstep clock within the iteration cycle to ensure that the monitoring results are written to the node's local register before the next round of local evolution judgment. Upon arrival of each microstep clock pulse, the impedance monitoring thread first reads the node's latest written link reachability flag, and then obtains the link reachability flag published by the temporary dominant node in the current iteration cycle through the cluster-shared register channel. Both are Boolean bit encoded, where "1" represents link reachability and "0" represents link unreachability. To prevent misjudgments caused by momentary jitter, the system does not immediately calculate the difference after reading; instead, it weights and folds the two Boolean bits with the round-trip delay fluctuation coefficient in the node's cache to form a comprehensive difference value. The formula for calculating the overall difference value is written into a designated register during system deployment. The core idea is to give 70% weight to the link reachability Boolean difference and 30% weight to the round-trip latency fluctuation, thus more closely reflecting real-world perception: if the dominant node and itself are both reachable but the latency of the dominant node spikes, the overall difference value will also rise rapidly; if both are unreachable at the same time, the difference value will be significantly reduced because the Boolean difference is zero, thus avoiding excessive reduction of the threshold of individual nodes due to the simultaneous disconnection of the entire cluster.

[0040] Once the comprehensive difference calculation is complete, the impedance monitoring thread immediately compares it with the preset impedance window maintained locally on the node. The preset impedance window consists of two boundary values: the upper boundary is called the "impedance window high threshold," and the lower boundary is called the "impedance window low threshold." Both are hardcoded during node initialization but can be adjusted by the operations and maintenance side through a real-time configuration interface. If the comprehensive difference value exceeds the impedance window high threshold, the impedance monitoring thread immediately triggers a threshold reduction script. This script temporarily reduces the node's packet loss trend indicator threshold to 60% of the original threshold and writes a priority warning tag to the node's metadata area. The threshold reduction is done in-situ with a protective lock, ensuring that the new threshold is already in effect when the local evolution judgment action is executed. The priority warning tag is an explicit flag that is specially judged when the local evolution judgment action enters the third evolution judgment rule, making it easier for the node to meet the trigger condition of "packet loss trend indicator higher than itself and encryption negotiation indicator different," thereby quickly switching to the warning state.

[0041] Simultaneously, the impedance monitoring thread activates a cooling counter for nodes that trigger downsampling. The initial value of the cooling counter is set to "2," meaning the node needs to continuously monitor whether the overall difference value falls below the lower threshold of the impedance window in the next two micro-step samplings. Only when this condition is met in two consecutive detections will the cooling counter be reset to zero and the threshold reset script be automatically invoked. When the threshold reset script is executed, the node's packet loss trend indicator threshold is restored to the baseline value recorded during initialization, the priority warning label is cleared, and the node returns to the same evolutionary baseline as other nodes that have not triggered downsampling. Through the cooling counter mechanism, the system avoids frequent threshold fluctuations when the link briefly improves and then rapidly deteriorates, ensuring that the warning strategy has sufficient time inertia to observe the authenticity of the link recovery.

[0042] It is worth noting that the impedance monitoring thread is designed not to participate in the direct counting of cluster-level states using the majority voting method. It only adjusts the internal thresholds and vigilance tendencies of the nodes. The actual state decision is still made by the local evolution judgment action and the subsequent cluster-level voting. This separation of "soft adjustment and hard decision" ensures that a single abnormal node will not cause the cluster-level state to fail immediately due to temporary fluctuations, and can also gradually push the cluster-level state towards vigilance or failure as the abnormality persists. This provides the ability to rapidly amplify local risks while ensuring the overall robustness of the system.

[0043] If, within a certain period, more than one-third of the nodes in a cluster enter a threshold reduction state due to excessive comprehensive difference values, the cluster-level monitoring thread of the cellular automata control unit will capture this "threshold reduction intensive" event and automatically reduce the cluster's preset impedance window high threshold by 10%, while increasing the weight of the warning label in the majority voting method by 5%. This dynamic reweighting strategy further enhances the sensitivity to large-area impedance mutations and forms a positive feedback loop: when the overall links within the cluster tend to deteriorate, the warning threshold becomes increasingly stringent, prompting the cluster-level state to transition to warning or failure more quickly; while when the link state gradually recovers, the cooling counters of most nodes return to zero, the threshold reset script is triggered, and the cluster-level monitoring thread will slowly adjust the impedance window high threshold and warning weight back to the baseline to avoid long-term over-conservatism.

[0044] Through this impedance-sensing closed loop nested within the node evolution process, the cellular automaton control unit achieves millisecond-level reflective responses to link reachability anomalies: it utilizes the dominant node as a low-latency benchmark, allowing each node to compare its own differences with the benchmark in real time, as if "looking in a mirror"; once mirror distortion is detected, it immediately amplifies the sensitivity of the "packet loss trend" dimension locally, prioritizing the use of alert paths; when the mirror becomes clear again, the amplification is automatically revoked after a sufficiently long stabilization cooling period, returning to normal. The entire process is based entirely on internal node threshold movement and tag insertion, eliminating the need for high-overhead full-cluster synchronization and avoiding reliance on external anomaly detection algorithms. This fine-grained, fast, and low-overhead impedance-sensing mechanism is one of the key means for hyperconverged IoT gateways to maintain high throughput, low packet loss, and security protection in complex heterogeneous network environments.

[0045] Furthermore, after the cluster-level voting concludes, the cellular automaton control unit faces a cluster-level state table arranged in cluster number order. To further reduce protocol mapping conflicts that may arise from cross-port state inconsistencies at the logical level, the system does not immediately map these cluster-level states to the target protocol dimension identifier. Instead, it first performs a peer-to-peer verification across the entire cluster, the so-called first-phase handshake mechanism. The implementation process begins with odd-even grouping of cluster numbers: the control logic scans the cluster-level state table in ascending order, placing odd-numbered clusters into the odd group and even-numbered clusters into the even group. Then, each cluster in the odd group is paired with the cluster in the immediately following even group to form a handshake pair. If the last item in the odd group does not have a corresponding even item, the odd-numbered cluster does not participate in the handshake in this round and directly enters the alert setting, ensuring that the pairing rules are absolutely paired and do not generate dangling waits.

[0046] After the handshake is established, the cellular automaton control unit dynamically allocates a dedicated time-sequential dual-token channel to each pair. The channel is built on an internal high-speed message bus, using two fixed-length messages as carriers, called the initiating token and the acknowledgment token, respectively. The control unit defines a globally consistent time slot rhythm, and each channel is activated in the same initial reference time slot. At the start of the handshake, the odd-numbered cluster-level state first injects the initiating token into the channel writer. The token header contains the cluster number, timestamp, and SHA-256 hash value of its own cluster-level state. The even-numbered cluster listener, after reading the initiating token at the end of the same time slot window, immediately performs the same hash algorithm on its own cluster-level state and compares the two hash values. If the results are equal, the "content matches" flag is set to 1; otherwise, it is set to 0. Subsequently, the even-numbered cluster encapsulates its cluster number, timestamp, hash value, and "content matches" flag into an acknowledgment token and writes it back to the channel in the next reference time slot. After receiving the acknowledgment token, odd-numbered clusters re-verify hash consistency and read the "content consistency" flag. Only when the hashes match and the flag is 1 is the handshake pair considered bidirectionally consistent, and the control unit immediately invokes the merging strategy: following a priority chain of failure priority, warning second priority, and stability lowest priority, merging and mapping the two cluster-level states to a single target protocol dimension identifier. If the hashes do not match, or the flag is 0, or neither the odd nor even cluster completes any step of the send or reply within the limited time window, the handshake is considered a failure, and the target protocol dimension identifier corresponding to the handshake pair is directly set to the warning flag. The limited time window is not a fixed constant, but is dynamically correlated with the physical port topology distance mapped to the cluster number, the average round-trip time of the previous round, and the network congestion threshold through a lookup table. The greater the distance and the heavier the congestion, the longer the window; this avoids misjudgment due to latency overhead in long-distance links, and also prevents unnecessary delays in short-distance links.

[0047] During the handshake pair batch processing, the cellular automaton control unit maintains a target protocol dimension identifier table using lock-free parallel writing. Whenever a pair confirms merging or is set to a warning flag, the corresponding entry is immediately written to the table, and handshakes on other channels are not blocked. After all handshake pairs have been processed, the control unit performs a linear merging of the target protocol dimension identifier tables in natural cluster number order to obtain the final evolution result for the current iteration cycle. If an odd-numbered cluster that failed to pair is encountered during the merging process, its target protocol dimension identifier has already been set to a warning flag before the handshake, thus preventing gaps. The final evolution result, as a compact structure object, is pushed to the protocol stack mapping unit using a zero-copy method. After reading it, the protocol stack mapping unit performs three actions based on the specific value of each target protocol dimension identifier in the evolution result: if the identifier is stable, the original service flow continues to use the current protocol stack; if it is a warning flag, the security level is increased, and stricter encryption and retransmission strategies are enabled; if it is in a failed state, the service flow of the relevant link is immediately suspended, and an attempt is made to switch to a redundant backup link.

[0048] This handshake mechanism fully leverages the simple mathematical relationship of parity numbering to achieve rapid determination of bidirectional port consistency. Simultaneously, it eliminates write-read contention caused by concurrent updates through time-sequential dual tokens and hash verification. By introducing a dynamic time window, the system takes into account differences in physical distance and network conditions, significantly reducing the false positive rate. Under the strategy of setting an alert upon handshake failure, even in the case of only one-way inconsistency, the protocol stack mapping unit adopts a conservative strategy to ensure secure redundancy of data transmission on suspicious links. The entire process consumes only two to three more reference time slots at the logical clock level than single-cluster mapping, yet it brings an exponential enhancement to cross-port state synchronization, enabling the hyperconverged IoT gateway to robustly complete protocol stack adaptation and security tag attachment even in scenarios with multi-port concurrency, high load, and high security requirements.

[0049] The following example demonstrates the complete workflow of a hyperconverged IoT gateway in a lab network, covering all technical aspects from network state preloading to protocol stack mapping. First, the experimental environment contains eight heterogeneous access ports, numbered 1-8. Ports 1-4 connect to Ethernet links, ports 5-6 connect to 5G cellular links, and ports 7-8 connect to LoRa WAN links. The gateway scanning scheduler is set to a three-round scanning cycle of 120ms, triggered sequentially according to port number from smallest to largest.

[0050] In the first round of unloaded scanning, the link reachability identifier measured for each port was 1; the round-trip delay identifiers were respectively... Bandwidth and packet loss are not included in this round. The second round of pressure scanning injects 80% rate burst traffic into each link; the bandwidth estimation indicator (in Mbit / s) and packet loss trend indicator (in %) results are as follows:

[0051]

[0052] Round-trip latency is updated synchronously to

[0053] The third round of negotiation and verification is initiated within 10ms of the end of the second round; the latest encryption negotiation identifier (hash truncation value) for each port is recorded as:

[0054]

[0055] After three rounds of scanning, the five types of identifiers are combined into eight network state baseline data points according to the port number, and written to the network state preload set with a UTC timestamp of 1720785600. The cellular automata control unit reads the eight baseline data points from the preload set and instantiates eight groups of nodes (each group corresponds to one scan, for a total of 24 nodes). Since the initial state of the nodes is uniformly set to stable, the initial vector of the node matrix is ​​denoted as:

[0056]

[0057] Where 0 represents stability. Nodes are divided into 8 cluster instances based on port affiliation, with each cluster containing 3 nodes, corresponding to cluster numbers 1-8. Before the iteration period ΔT = 200ms begins, the pre-update process generates segmented cyclic redundancy check codes for each node. Taking the second round baseline data of port 5 as an example, its five types of identifiers are concatenated to obtain a hexadecimal sequence. After segmentation, take 2 bytes per segment and use CRC-16-IBM polynomial x. 16 +x 15 +x 2 +1 is calculated, and each checksum segment is calculated using CRC. i =CRC16(SEG) i The five segments yield {0xE1F4, 0x7B61, 0xBB52, 0x6A90, 0x1F3E}. The node broadcasts the five CRC combinations to the cluster, and neighboring nodes synchronously compare them. The third CRC segment on port 7 is inconsistent with the overhead of the previous cycle, so its node immediately enters a vigilant state, and its status register is written to 2.

[0058] A temporary leader election is then conducted. The node with the smallest round-trip time (RTT) recorded in the previous iteration falls on port 1, with an RTT of 1.3ms. Therefore, the first node elected by cluster 1 for port 1 is the temporary leader. The leader node enables a six-directional ring neighborhood, while the remaining nodes maintain a four-neighbor neighborhood. The leader node performs a cluster health check: it collects the state sequence {0,0,0} of three nodes. After run-length compression, only two bytes (3,0) are generated, which is much smaller than the preset window threshold of 12 bytes. Therefore, no direct failure judgment is triggered, and the cluster continues its normal evolution.

[0059] During the normal node evolution phase, each node reads the neighborhood state and applies three evolutionary judgments: The second-round node on port 5, detecting that the reachability of its upper and right neighboring links is 0 (ports 7 and 8 experienced link breaks after pressure scanning), triggers the first rule, setting its state to invalid (encoding 1). The first-round node on port 3 finds that the round-trip latency of all neighboring nodes is on the same order of magnitude as its own (1.5ms ± 0.4ms), satisfying the second rule and remaining stable. The second-round node on port 8, with a packet loss trend of 4.3% higher than its own 4.1% and an encryption negotiation identifier 0x30 different from the neighboring node's 0x2F, triggers the third rule and enters a state of alert.

[0060] After local evolution is completed, the majority vote of each cluster is conducted: if the states of the three nodes of cluster 7 are {2,2,1} (two are alert and one is invalid), the voting result is alert (2). The eight cluster-level states are mapped to the target protocol dimension identifier PD = {0,0,0,0,1,1,2,2} according to the cluster number; where 0 is stable, 1 is invalid, and 2 is alert.

[0061] To verify cross-cluster consistency, the control unit groups the cluster numbers as follows: (1,2), (3,4), (5,6), (7,8). During the handshake process for the (1,2) pair, the first token hash H1 = SHA256(0) = 0x4BF9..., the even-numbered cluster hash H2 is the same, the response token flag is 1, the handshake is successful, and the two clusters are merged and mapped to 0.

[0062] In handshake pair (5,6), cluster 5 fails, cluster 6 fails, the two hashes are equal, and the merged result remains invalid (1). In handshake pair (7,8), since the cluster response token corresponding to port 8 arrives at t=18ms, while the time window is limited to 12ms, the handshake fails, and the result is directly set to alert (2).

[0063] The updated target protocol dimension identifier sequence PD′ = {0,0,0,0,1,1,2}, note that there are only 7 items at the end because the last pair is merged to output a single identifier. The protocol stack mapping unit reads PD′ and executes the mapping rules:

[0064] Dimensions 1-4 take a value of 0, and data packets are sent using the UDP / IPv6 low-overhead stack.

[0065] Dimensions 5-6 are set to 1, switch to TCP / TLS 1.3 and enable retry logic.

[0066] Dimension 7 is set to 2, forcibly switching to QUIC / ChaCha20-Poly1305 and attaching the security label SID42 to the data packet, and suspending large packet segmentation.

[0067] During the demonstration, the gateway completed a full closed loop: three rounds of scanning took 3 × 120 = 360ms, pre-update took 5ms, health check and compression took 2ms, normal evolution took 15ms, and handshake process took 20ms, for a total time of approximately 402ms, which is less than the design budget of 500ms.

[0068] The following example demonstrates the end-to-end implementation of a hyperconverged IoT gateway. Unlike the previous example, which focused on link reachability, this example emphasizes dynamic bandwidth ordering, packet loss propagation suppression, and security tag linkage. Scenario: The gateway is located in a micro data center, carrying four types of service flows—high-definition video backhaul, industrial sensing, indoor positioning, and alarm broadcasting. The hardware includes six heterogeneous access ports: ports 1 and 2 are 10 Gigabit Ethernet, ports 3 and 4 are Wi-Fi 6E, port 5 is 5G NRsub-6 GHz, and port 6 is a satellite Ku-band port. The system clock base period τ is 10ms.

[0069] The network state preloading phase is controlled by the scan scheduler, with a total scan duration of 3τ across three rounds.

[0070] The first round of idle scanning acquired link reachability and round-trip time; measurements were obtained. and

[0071] In the second round, a burst of 70% of the port's design bandwidth was injected at time 1.5τ, and the bandwidth estimate was measured. With packet loss trend Synchronous update of round-trip latency

[0072] The third round of negotiation verification completes the ECDHE-P-256 handshake at time 2.8τ, and the encrypted negotiation truncated hash is recorded. After the three rounds, the six network status baseline data were written to the timestamp t0 = 1720789200.

[0073] The cellular automaton control unit creates one node for each baseline data point, for a total of 3 × 6 = 18 nodes; the initial state vector of each node is S0 = {0}. 18 The nodes are divided into 6 clusters based on their port affiliation, with 3 nodes in each cluster. Let the iteration period be ΔT = 5τ.

[0074] During the pre-update process, each node splits its baseline data into 16-byte segments and uses CRC-32-Castagnol i polynomial x 32 +x 30 +x 29 +x 28 +x 26 +x 20+x 19 +x 18 +x 14 +x 13 +x 11 +x 10 +x 8 +x 6 +x 4 +x 2 The calculation involves adding x and 1. Taking the second round baseline data hexadecimal string 7F000403340.180x5D from port 4 as an example, the four-segment checksum...

[0075] After the ring broadcast, the third CRC segment of port 5 is different from the previous iteration. The third round node of port 5 is immediately set to alert, and the node status changes from 0 to 2.

[0076] The minimum round-trip time (RTT) is for port 1, with a second round RTT of 1.2ms. Therefore, the first-round node of port 1 becomes the temporary dominant node of cluster 1. The dominant node expands to a six-directional ring neighborhood, while the remaining nodes maintain a four-neighborhood. The dominant node constructs a sequence {0,0,0} for the states of the three nodes within the cluster. The run-length compression result (3,0) is only 2 bytes, which is below the threshold of 10 bytes, and therefore does not trigger a direct failure judgment.

[0077] Evolutionary phase: Nodes process in parallel according to neighborhood rules. In the second round of port 3, the reachability of the upper and right neighboring links is 0 (high latency of satellite links causes timeout of 0), triggering the first rule to invalidate (1). In the first round of port 4, the difference between the round-trip latency of the neighboring network and its own 2.2ms sequence is within ±0.6ms, satisfying the second rule to remain stable (0). In the second round of port 6, the detection that the neighboring packet loss trend of 3.9% is higher than its own 3.9% is not valid, but the encryption negotiation identifier 0x19 is inconsistent with the neighboring 0x72, still satisfying the third rule to enter the alert state (2). After all nodes write to the buffer, the majority vote obtains the cluster-level state {0,0,1,0,2,2} corresponding to the encoding order of ports 1-6.

[0078] Impedance monitoring thread operation: Port 3 second round node comprehensive difference value The preset high threshold of 0.4 does not trigger threshold reduction if it is not exceeded. (Port 5, Round 3 node) The ultra-high threshold is set to 0.4, the packet loss threshold is reduced from 0.20% to 0.12%, and the priority warning label is set to 1, making it easier to enter the warning in the next iteration.

[0079] After obtaining the cluster-level state table, pair them according to parity: (1,2), (3,4), (5,6). Handshake process: For (3,4), the first token hash H3 = SHA256(1) = 0xB9… is not equal to the response hash H4 = SHA256(0) = 0x4B…, and the handshake fails in the second time slot, setting a warning for the target protocol dimension. For (5,6), both clusters are on warning, the hashes are consistent, the flag is set to 1, and the clusters are merged to maintain the warning. The time window Γ takes 2τ for the local port, and all pairs are completed within Γ. The final target protocol dimension sequence PD ★ ={0,0,2,2,2}.

[0080] Protocol stack mapping unit receives PD ★ Afterwards, Dimension 1.0 continues with UDP / IPv6, Dimension 20 continues with UDP / IPv6, and Dimensions 3, 4, and 5 are on alert. QUIC / AES-GCM-256 is selected and bidirectional forward erasure coding is enabled. Security tags SID77 are appended to data packets. At the same time, backup link detection is triggered on ports 5 and 6. If the alert status is still active for 5 consecutive heartbeat windows, the flow is switched to the backup 5GSA.

[0081] Total time: Three rounds of scanning 3τ = 30ms, pre-update calculation and broadcast approximately 0.6τ = 6ms, temporary dominant node health check and run compression 0.3τ = 3ms, regular evolution including majority voting 1.5τ = 15ms, handshake for dual tokens 0.7τ = 7ms, merged write 0.1τ = 1ms, total latency 62ms, meeting the system's requirement for adaptive closed loop within 100ms.

[0082] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A hyperconverged IoT gateway, characterized in that, include: The system comprises a network state preloading unit, a cellular automaton control unit, and a protocol stack mapping unit. The network state preloading unit performs multi-dimensional state acquisition on the heterogeneous access networks connected to the hyperconverged IoT gateway and generates a network state preloading set. The cellular automaton control unit creates cellular automaton nodes for each network state baseline data based on the network state preloading set, aggregates several cellular automaton nodes into cellular automaton cluster instances according to their access port affiliation, and assigns a unique cluster identifier to each cellular automaton cluster instance. Within a preset iteration period, each cellular automaton cluster instance evolves its node state according to neighborhood evolution rules and generates a cluster-level state based on the node state. Each cluster-level state is then mapped to a target protocol dimension identifier, and the resulting evolution is obtained. The protocol stack mapping unit maps the data packets to be transmitted to the target protocol stack format based on the evolution results, attaches a security label, and outputs the data packets to be transmitted to the corresponding external network interface.

2. The hyperconverged IoT gateway as described in claim 1, characterized in that, The network state preloading unit initiates three rounds of scanning in a fixed order on all heterogeneous access ports of the hyperconverged IoT gateway. For each round of scanning, the following information is collected for each access port in sequence: link reachability identifier, round-trip time identifier, bandwidth estimation identifier, packet loss trend identifier, and encryption negotiation identifier. Based on the port number from smallest to largest, the above five types of identifiers are combined into a single network status baseline data, and a network status preload set is generated according to the timestamp index.

3. The hyperconverged IoT gateway as described in claim 2, characterized in that, For each network state baseline data in the network state preload set, the cellular automaton control unit generates a group of cellular automaton nodes with the same initial state; it divides all cellular automaton nodes into several cellular automaton cluster instances according to their access port affiliation, and assigns a unique cluster number to each cellular automaton cluster instance.

4. The hyperconverged IoT gateway as described in claim 3, characterized in that, The process by which the cellular automaton control unit obtains the evolution results includes: at the start of a preset iteration cycle, invoking the initial loading action to load and lock the corresponding network state baseline data for each cellular automaton node; each cellular automaton node reads the current node state of its neighboring nodes from within its own cellular automaton cluster instance according to the preset four-neighbor relationship (up, down, left, and right); for the read current node state of the neighboring nodes, a local evolution judgment action is performed, comparing it one by one according to the following three evolution judgment rules: if the link reachability identifier of at least two neighboring nodes is unreachable, the current node enters a failure state; if the round-trip delay identifiers of all neighboring nodes are on the same order of magnitude different from its own round-trip delay identifier... If the packet loss trend indicator of any neighboring node is higher than its own and the encryption negotiation indicator is different, the current node enters an alert state. Based on the result of the local evolution judgment action, the current node state is updated to one of the following: failure state, stable state, or alert state, and recorded in the local evolution result buffer. All node states in the local evolution result buffer are collected in order of cluster number, and the cluster-level state of the cellular automaton cluster instance is determined by majority voting. According to the cluster number from smallest to largest, the cluster-level state of each cellular automaton cluster instance is mapped to a target protocol dimension identifier, where the target protocol dimension identifier corresponds one-to-one with the cluster-level state. All target protocol dimension identifiers are combined into the evolution result.

5. The hyperconverged IoT gateway as described in claim 4, characterized in that, Before the start of each preset iteration cycle, the cellular automaton control unit performs a pre-update process: each cellular automaton node generates a segmented cyclic redundancy check (CRC) code for its network state baseline data; the nodes broadcast the CRC code in a one-way circular manner within the cluster according to the cluster number order; if any node detects that the CRC code of any neighboring node is inconsistent with the previous record, it immediately updates its own node state to the alert state.

6. The hyperconverged IoT gateway as described in claim 5, characterized in that, Before the start of each preset iteration cycle, the cellular automaton control unit performs a pre-update process and then elects a temporary dominant node for each cellular automaton cluster instance: the nodes are sorted in ascending order according to the round-trip delay identifier recorded in the previous iteration cycle; the time slot number corresponds one-to-one with the sorting result, and the node with the smallest round-trip delay identifier becomes the temporary dominant node in the current iteration cycle; the temporary dominant node activates a six-directional ring neighborhood consisting of up, down, left, right and two diagonals within its cluster, while the other nodes maintain their original four-neighborhood relationship.

7. The hyperconverged IoT gateway as described in claim 6, characterized in that, Before the evolution of each cluster initiation node, the cellular automaton control unit has a temporary leading node that collects the current node states of all nodes in the cluster and concatenates them into a state sequence according to the node number. The state sequence is compressed using lossless run-length compression. If the length of the compressed bytes exceeds a preset window threshold, the cluster-level state of the entire cellular automaton cluster instance is directly set to the failure state; otherwise, the normal node evolution continues.

8. The hyperconverged IoT gateway as described in claim 7, characterized in that, During node evolution, the cellular automaton control unit detects the difference between its own link reachability identifier and the link reachability identifier of the temporary dominant node for each cellular automaton node. If the difference exceeds the preset impedance window, it temporarily lowers its own packet loss trend identifier threshold and gives priority to entering the alert state in the next round of local evolution judgment. After the difference returns to within the window, the threshold is automatically reset.

9. The hyperconverged IoT gateway as described in claim 8, characterized in that, After obtaining the cluster-level states, the cellular automaton control unit divides the cluster numbers into odd and even groups to form the first-stage handshake pairs. The odd-numbered cluster-level states exchange timed double tokens with the next sequential even-numbered cluster-level states. After confirming that their states are consistent, they are merged and mapped into a single target protocol dimension identifier. If any handshake pair fails to complete the double token confirmation within the limited time window, the corresponding target protocol dimension identifier is directly set to a warning flag. All target protocol dimension identifiers are merged and combined into an evolution result, which is then passed to the protocol stack mapping unit.

Images