A wireless routing control method for real-time edge computing of a sink node

Abstract

This invention belongs to the field of routing control technology, specifically disclosing a wireless routing control method for real-time edge computing at aggregation nodes. Each aggregation node deployed in the edge computing network periodically self-checks its local computing load, classifying its own computing power status as relaxed, moderate, or strained, and broadcasts this status to neighboring nodes. This allows upstream nodes to select the next hop based on link availability and their own status priority when forwarding data, thus directly linking routing decisions to the actual computing power status of nodes. This effectively avoids forwarding data packets to busy or memory-constrained nodes, reducing processing delays and packet loss risks caused by computing power overload. Furthermore, the status determination and priority rules do not require complex numerical calculations, making them easy to implement on resource-constrained aggregation nodes, thereby improving the overall forwarding efficiency and stability of the edge computing network.

Description

Technical Field

[0001] This invention belongs to the field of routing control technology, and specifically discloses a wireless routing control method for real-time edge computing at aggregation nodes. Background Technology

[0002] In edge computing networks, aggregation nodes serve as hubs for data collection, aggregation, and forwarding, undertaking the task of transmitting massive amounts of terminal data back to the edge computing platform. Since aggregation nodes are typically networked using a multi-hop wireless architecture, data often needs to be forwarded through multiple intermediate nodes from the source node to the destination node. Therefore, it is necessary to design reasonable routing control methods to avoid data loss and transmission delays caused by local network congestion, node overload, or link interruptions.

[0003] Existing technologies already include relevant routing control schemes. For example, Chinese invention patent CN101674630A discloses a congestion-aware cross-layer routing implementation method. This method provides the network layer with two types of quality information obtained from the MAC layer through cross-layer design: the expected transmission success rate for link congestion awareness and the remaining load rate for node congestion awareness. During route discovery, the route request carries these two types of information and accumulates them hop-by-hop to ultimately form a routing decision function. The optimal path is then selected based on the function value.

[0004] However, the above technical solutions have the following shortcomings when applied to edge computing scenarios:

[0005] First, the scheme only uses the cache queue depth as an indicator of node congestion. In edge computing, aggregation nodes also need to undertake computationally intensive tasks such as data aggregation and edge computing. The utilization rate of their central processor and the amount of free memory directly affect the node's ability to process newly received data. Using only queue depth as a congestion criterion cannot accurately determine whether a busy node with a short queue still has the computational capacity to undertake forwarding tasks, which may lead to routing decisions being out of touch with the actual computing power status of the node.

[0006] Second, this scheme integrates link quality and node load into a numerical routing decision function. Routing selection depends on the comparison of function values. In resource-constrained wireless embedded environments, numerical computation places certain demands on node processing capabilities. When node computing resources are scarce, frequent function operations may further exacerbate the node burden and affect the timeliness of routing decisions. Summary of the Invention

[0007] To solve the above-mentioned technical problems, or at least partially solve them, the present invention provides a wireless routing control method for real-time edge computing at aggregation nodes.

[0008] The objective of this invention can be achieved through the following technical solution: a wireless routing control method for real-time edge computing at a convergence node, comprising the following steps:

[0009] In an edge computing network, multiple aggregation nodes are deployed, and upstream and downstream relationships are defined between adjacent nodes.

[0010] Each aggregation node periodically checks its local computing load and classifies its own status into easy, moderate, or tense states based on the self-check results. The easy, moderate, and tense states are three levels from high to low, and the node broadcasts its own status to its neighboring nodes.

[0011] Each aggregation node records the data flow path forwarded by itself, and groups multiple paths sharing the same congested node into an association group;

[0012] When a convergence node generates a data forwarding requirement, it initially selects candidate nodes according to the priority of link smooth and easy state, link smooth and moderate state, and link unsmooth and easy state. After downgrading the status level of nodes belonging to the congestion-related group among the initial candidate nodes, the final next-hop node is determined.

[0013] If no node is available, the data packet is temporarily stored and waits for one broadcast cycle. After the timeout, a forwarding failure notification is sent to the upstream node.

[0014] Combining all the above technical solutions, the positive effects of this invention are as follows:

[0015] 1. This invention enables each aggregation node in the edge computing network to periodically self-check its local computing load, allowing upstream nodes to select the next hop based on the self-check results when forwarding data. This directly links routing decisions to the actual computing power status of nodes, effectively avoiding forwarding data packets to busy or memory-constrained nodes and reducing processing delays and packet loss risks caused by computing overload.

[0016] 2. When selecting the next-hop node based on the self-test results of computing load, this invention classifies its own state into an easy state, a moderate state, or a tense state according to the self-test results, and then selects the next-hop node based on the state priority. There is no need to perform function value calculation and comparison, which reduces the demand on the computing resources of the aggregation node. When the node resources are tight, it will not add extra processor burden, thus ensuring the timeliness of routing selection and the overall network operating efficiency.

[0017] 3. After constructing a candidate set of downstream nodes according to priority rules, this invention further reduces its own state level based on the congested nodes in the associated group, so that the routing decision merges the coupling relationship between the real-time state of the node and the congested node, thereby effectively avoiding congested paths, preventing multiple flows from flooding into the same congested node, and improving the network's adaptive capability under dynamic load. Attached Figure Description

[0018] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0019] Figure 1 This is a diagram illustrating the implementation steps of the method of the present invention.

[0020] Figure 2 This is a schematic diagram illustrating how the self-state is classified into relaxed, moderate, or tense states based on the self-test results in this invention.

[0021] Figure 3 This is a flowchart illustrating the implementation of the initial candidate node selection in this invention. Detailed Implementation

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

[0023] With the surge in the number of IoT devices and the increasing demands for real-time processing, transmitting massive amounts of data back to the cloud for processing can lead to significant transmission latency and network bandwidth pressure. Edge computing effectively alleviates these problems by providing computing and storage capabilities locally at the network edge.

[0024] In edge computing networks, aggregation nodes are responsible for collecting terminal data, performing local data aggregation and preliminary calculations, and forwarding the processing results to adjacent aggregation nodes. They are widely deployed in scenarios that require multi-hop wireless communication, such as industrial IoT and power grid monitoring.

[0025] Since aggregation nodes typically form multi-hop wireless networks in a self-organizing manner, and the computing power and link quality of the nodes themselves may change at any time, it is necessary to design a reasonable wireless routing control method to dynamically adapt to the node status and network topology, and avoid data loss and transmission delays caused by computing power overload or link congestion.

[0026] To achieve the above requirements, see Figure 1 As shown, this invention proposes a wireless routing control method for real-time edge computing at aggregation nodes, comprising the following steps:

[0027] Step 1: Deploy multiple aggregation nodes in the edge computing network and define upstream and downstream relationships between adjacent nodes;

[0028] In edge computing networks, aggregation nodes are responsible for collecting terminal data, performing local computations, and forwarding it to neighboring nodes. Since data typically requires multi-hop wireless transmission to reach its destination, it is first necessary to determine the deployment locations of each node and their logical relationships. The specific implementation process is as follows:

[0029] Step 11: Divide the entire area into several adjacent and non-overlapping sub-regions according to the boundary range of the edge computing coverage area. To ensure that nodes in any two adjacent sub-regions can communicate directly, the Euclidean distance between the converging nodes in adjacent sub-regions is less than the preset stable wireless communication distance. This stable wireless communication distance is predetermined by the performance parameters of the wireless communication module used by the node, such as transmit power, receive sensitivity and actual environmental attenuation, and can be regarded as a known design input.

[0030] Step 12: Deploy a convergence node at the geometric center of each sub-region to ensure that the distance between nodes is relatively uniform and reduce communication blind spots;

[0031] Step 13: After the nodes are powered on, each aggregation node periodically sends a test message containing its own identifier. The two nodes establish an initial connection through a two-way handshake process: one party sends a request message, and the other party replies with a response message after receiving it, thus completing one handshake.

[0032] If three consecutive handshakes are successful, and the received signal strength measured by the node during the handshake process is always higher than the preset threshold value, then the two nodes are determined to be adjacent nodes.

[0033] The signal strength threshold is usually preset based on the sensitivity of the wireless receiver plus an empirical margin such as 5dB, with the aim of filtering out links with weak signals and unstable communication.

[0034] Step 14: Two adjacent nodes establish a bidirectional communication connection through a wireless link. When transmitting data packets for the first time, the upstream and downstream relationship is dynamically established according to the direction of data packet transmission: the party that sends the data packet is the upstream node, and the party that receives the data packet and is responsible for continuing to forward it is the downstream node.

[0035] Step 2: Each aggregation node periodically checks its local computing load and classifies its own status into easy, moderate, or tense states based on the self-check results. The easy, moderate, and tense states are three levels from high to low, and the node broadcasts its own status to its neighboring nodes.

[0036] Once the upstream and downstream relationships between nodes are established, the aggregation node can begin forwarding data. However, the node itself also needs to undertake real-time processing tasks such as data aggregation and edge computing, and its available computing power directly affects its ability to handle new forwarded data. If the routing decision does not take into account the computing load of the nodes, data packets may be forwarded to nodes that are already fully loaded, causing the decision to become disconnected from the actual computing power status of the nodes, which may lead to processing delays or even packet loss.

[0037] To address the aforementioned issues, this invention involves each aggregation node periodically self-checking its local multi-dimensional computing load and generating a status reflecting its willingness to undertake new tasks. This provides a decision-making basis for the routing selection of upstream nodes. The specific implementation process is as follows:

[0038] Step 21: Local computing load self-check

[0039] During each self-test cycle, the aggregation node checks the following three parameters in sequence:

[0040] Central Processing Unit (CPU) Run Queue Length: This reflects the number of tasks currently waiting for CPU scheduling. The longer the queue, the busier the CPU is, and the weaker the node's ability to process new tasks.

[0041] Free memory: This indicates the amount of memory a node can use for data caching and processing. The less free memory, the more strained the memory is, and the worse the node's ability to cache new data packets.

[0042] The queue depth of locally stored data packets: This indicates the number of data packets that the node has received but has not yet forwarded. A queue that is too deep means that the node is in a state of output congestion, and even if the CPU and memory are sufficient, it will not be able to process the newly arrived data in a timely manner.

[0043] The above three parameters evaluate the real-time load status of a node from three dimensions: computing power, storage capacity, and forwarding congestion. Each parameter corresponds to a limit, which can be obtained from the node's hardware specifications or network engineering planning documents. In one example, the CPU run queue length limit can be set to 5, the free memory limit can be set to 20% of the total memory, and the local temporary data packet queue depth limit can be set to 100 data packets.

[0044] Compare the results of each test with their respective limits. If none of the three tests exceed the corresponding limits, the test is marked as low load. If only one test exceeds the limit, the test is marked as medium load. If two or more test results exceed the limit, the test is marked as high load.

[0045] It should be noted that, among the three parameters mentioned above, the larger the value of the CPU run queue length and the local temporary data packet queue depth, the heavier the load. Therefore, exceeding the limit means that the check result is higher than the corresponding limit. On the other hand, the smaller the value of the free memory, the heavier the load. Therefore, exceeding the limit means that the check result is lower than the corresponding limit.

[0046] Through the above self-check, nodes can quantitatively grasp their own real-time computing power and load status, providing basic data for state division.

[0047] Step 22: Perform state classification using computing load self-test results.

[0048] See Figure 2 As shown, the aggregation node records the load flag for each of the most recent consecutive self-check cycles (e.g., 5 cycles), and counts the total number of occurrences of low load, medium load, and high load during this period. It then classifies its own status as relaxed, moderate, or stressed according to the following rules:

[0049] a) If a high load flag appears in at least one cycle, immediately set the state to tense without waiting for subsequent cycles.

[0050] Reason: High load indicates that the node has encountered a clear resource bottleneck and needs to be notified immediately to stop forwarding new data to it to prevent further deterioration.

[0051] b) If no high load indicator appears, compare the number of occurrences of the low load indicator with the number of occurrences of the medium load indicator:

[0052] b1) If the low load flag appears more often than the medium load flag, then set it to the relaxed state.

[0053] Reason: The nodes are mainly under low load, with sufficient CPU, memory, and queues, providing ample computing power to handle additional forwarding tasks, and are stable and reliable.

[0054] b2) If the number of times the low load marker appears is less than or equal to the number of times the medium load marker appears, then it is set to the moderate state.

[0055] Reason: The node resources are at a medium or high utilization level, which can still handle new tasks, but traffic needs to be controlled appropriately to avoid entering a high load too quickly.

[0056] In one partitioning example, if the load label sequence for 5 cycles is: low, low, medium, low, medium.

[0057] Low load occurred 3 times, medium load occurred 2 times, and high load occurred 0 times.

[0058] Since no high load occurred and the number of low load occurrences was greater than the number of medium load occurrences, the user's status is determined to be relaxed.

[0059] After the state division is completed, the aggregation node broadcasts a routing status message to its neighboring nodes in each cycle. The message carries the node's identifier and its current state, enabling neighboring nodes to obtain the available computing power information of the node in a timely manner.

[0060] Step 3: Each aggregation node records the data flow path forwarded by itself, and groups multiple paths sharing the same congested node into an associated group;

[0061] After load calculation and status broadcasting, each aggregation node possesses the ability to perceive its own and its neighboring nodes' load status in real time. However, relying solely on the instantaneous status of neighboring nodes for routing decisions has a short-sighted problem: a node currently displaying an easy state may have a deeply congested path downstream, causing data packets to still encounter long delays or packet loss after being forwarded. Therefore, each aggregation node also needs to record the path information of the data streams it forwards to avoid repeatedly selecting forwarding links that have already exposed congestion risks.

[0062] In a preferred embodiment, Step 3 is implemented as follows:

[0063] First, create a path record table.

[0064] The aggregation node maintains a separate path record table for each destination address. This table stores information about the different forwarding paths from this node to the destination address. Each entry in the table contains a sequence of downstream nodes, that is, the identifiers of each downstream node that is passed sequentially along the path starting from this node.

[0065] When a convergence node successfully forwards a data packet to a downstream node of a path and receives an acknowledgment, it keeps the path record unchanged; when forwarding fails, the path is recorded as an invalid path in the path record table, and invalid paths do not participate in the association group division.

[0066] Secondly, the association groups were divided.

[0067] The aggregation node checks the downstream node sequence of the currently valid path in the path record table. If two or more paths contain the same node in their respective downstream node sequences that is currently in a tense state, i.e. a congested node, then these paths are classified into the same association group.

[0068] For example, if both path A→B→C→D and path A→B→E→D contain node B, and B is currently in a tense state, then these two paths are grouped into the same association group.

[0069] It should be added that the aggregation node re-checks the current status of nodes in the associated group every broadcast cycle. If the node is no longer in a tense state, it is removed from the associated group. In addition, invalid paths in the path record table that have exceeded their lifespan should also be deleted in a timely manner.

[0070] The purpose of dividing these association groups is to identify paths that share the same congestion bottleneck. When any path in an association group becomes congested, all other paths within the group are also highly likely to be affected, as they all pass through the same congested node. By managing these paths together, the aggregation node can uniformly lower the state level of the entire association group during subsequent routing decisions, avoiding repeatedly selecting the same seemingly smooth but actually problematic path.

[0071] Step 4: When the aggregation node generates a data forwarding requirement, it initially selects candidate nodes according to the priority of link smooth and easy state, link smooth and moderate state, and link unsmooth and easy state. After downgrading the status level of the nodes belonging to the congestion-related group among the initial candidate nodes, the final next hop node is determined.

[0072] After the node deployment, upstream and downstream relationship establishment, computing power self-check and status broadcasting, path information recording, and association group division steps described above, each aggregation node not only has a grasp of its own real-time status and link connectivity of neighboring nodes, but also knows the congestion correlation between paths. Based on this, when a node generates a data forwarding request, it can select the next hop by combining priority order with association group information, thereby optimizing routing decisions. The specific implementation consists of the following three sub-steps:

[0073] Step 1: Determining the data forwarding requirement. Before the aggregation node starts selecting the next hop, it is necessary to first determine whether the current data packet really needs to be forwarded.

[0074] 11) After receiving a data packet forwarded from an upstream node or a data packet generated by itself, the aggregation node parses the destination address of the data packet;

[0075] 12) If the destination address is not this node and this node is not the final recipient of the data packet, then a data forwarding request is generated.

[0076] Step 2 uses the condition of link connectivity in the priority rules, and the specific determination method is as follows:

[0077] 21) For each sink node, a consecutive success count and a consecutive failure count are recorded for each adjacent node, both of which are initially zero;

[0078] 22) Whenever a data packet is sent to the adjacent node and a link layer acknowledgment is received, the consecutive success count is incremented by one, and the consecutive failure count is reset to zero.

[0079] 23) When the consecutive success count accumulates to the preset success threshold (e.g., 3 times), the link between the aggregation node and the adjacent node is determined to be in a smooth state;

[0080] 24) Whenever no acknowledgment is received or a retransmission request is received after sending a data packet, the consecutive failure count is incremented by one, and the consecutive success count is reset to zero.

[0081] When the consecutive failure count accumulates to a preset failure threshold (e.g., 3 times), the link is determined to be in a non-operational state.

[0082] See Figure 3 As shown, step 3 involves dividing the candidate set based on node status and link connectivity.

[0083] After the aggregation node triggers the next-hop selection, three candidate sets are constructed in sequence, each set corresponding to a priority level:

[0084] First, traverse all adjacent nodes that are downstream, and select nodes with smooth links and relaxed states to form the first candidate set.

[0085] If the first candidate set is not empty, the initial selection ends; if it is empty, the second candidate set is formed by selecting nodes with smooth links and moderate states.

[0086] If the second candidate set is not empty, the initial selection ends; if it is empty, the third candidate set is formed by selecting nodes whose links are not smooth but whose state is relaxed.

[0087] If the third candidate set is not empty, the initial selection ends; if it is empty, it is determined that there are no available nodes, and the process proceeds to Step 5, which involves backoff and waiting.

[0088] The logic behind the above priority order is as follows: In edge computing networks, node computing load is more decisive than instantaneous link quality, because insufficient computing power will cause data packets to not be processed at all, while link failure can be recovered by MAC layer retransmission, adjustment of encoding method or short wait; and the third priority is only triggered when no smooth link is available, which is an emergency strategy.

[0089] Step 4: Priority Adjustment Based on Congestion Association Groups

[0090] After selecting the first, second, and third candidate sets according to the above priority order, the aggregation node further adjusts the candidate sets using the congestion association groups recorded in Step 3;

[0091] For each downstream node in the candidate set, if any path the node belongs to belongs to a congestion association group, that is, the node is a component of a certain path in the association group, then the node's own state is temporarily downgraded by one level: from easy state to moderate state, from moderate state to tense state, and the tense state remains unchanged.

[0092] The purpose of the above modifications is to prevent multiple data streams from rushing to the same congestion bottleneck node at the same time, and to achieve coordinated avoidance between paths.

[0093] Step 5: Determine the final next hop node

[0094] After the priority correction is completed, the candidate set is re-divided according to the priority based on the downgraded state. Then, the aggregation node selects a node from the re-divided first candidate set as the final next hop. If the first candidate set is empty, a node is selected from the second and third candidate sets in turn as the final next hop.

[0095] Step 5: If no node is available, temporarily store the data packet and wait for one broadcast cycle. After the timeout, send a forwarding failure notification to the upstream node.

[0096] After the candidate set filtering and priority adjustment in Step 4, if all candidate sets are empty, it means that the current sink node has no available downstream nodes. In this case, the sink node should not immediately discard the data packet, but should wait for the network status to change before trying again, as detailed below:

[0097] When it is determined that there are no available downstream nodes, the aggregation node starts a timer with a duration equal to one routing status message broadcast cycle. This cycle is a system configuration parameter with a value ranging from 100ms to 2000ms. The purpose of the timer is to provide a short recovery period for the network status. During this period, the aggregation node suspends forwarding the current data packet but allows adjacent nodes to update their status.

[0098] During the timer's operation, the aggregation node retains the currently pending data packets at the head of the sending queue without discarding or reordering them. Simultaneously, it continuously receives routing status messages from neighboring nodes to promptly learn of changes in their status levels or link states.

[0099] Upon receiving a routing status message, the aggregation node updates the status information of its adjacent nodes (such as its own status level and link connectivity flag) and re-executes the next-hop selection according to the priority rules in Step 4. If a next hop is successfully selected before the timer expires, the data packet is immediately forwarded, the timer is canceled, and the normal forwarding process is resumed.

[0100] If no downstream node is available after the timer expires, it means that the network failed to recover to a forwardable state within the current broadcast period. In this case, the sink node discards the packet and constructs a forwarding failure notification message, sending it hop-by-hop to the upstream node in the opposite direction of the packet's original arrival. This notification informs the upstream node that the current downstream path is unavailable, prompting the upstream node to switch to an alternative path as soon as possible.

[0101] Through the aforementioned backoff waiting and failure notification mechanism, the aggregation node can adaptively delay its decision when encountering a temporary lack of available downstream nodes, avoiding invalid retransmissions caused by prematurely discarding data packets, while simultaneously achieving upstream propagation of congestion information through feedback notification.

[0102] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0103] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0104] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0106] Finally, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A wireless routing control method for real-time edge computing at a convergence node, characterized in that, Includes the following steps: In an edge computing network, multiple aggregation nodes are deployed, and upstream and downstream relationships are defined between adjacent nodes. Each aggregation node periodically checks its local computing load and classifies its own status into easy, moderate, or tense states based on the self-check results. The easy, moderate, and tense states are three levels from high to low, and the node broadcasts its own status to its neighboring nodes. Each aggregation node records the data flow path forwarded by itself, and groups multiple paths sharing the same congested node into an association group; When a convergence node generates a data forwarding requirement, it initially selects candidate nodes according to the priority of link smooth and easy state, link smooth and moderate state, and link unsmooth and easy state. After downgrading the status level of nodes belonging to the congestion-related group among the initial candidate nodes, the final next-hop node is determined. If no node is available, the data packet is temporarily stored and waits for one broadcast cycle. After the timeout, a forwarding failure notification is sent to the upstream node.

2. The wireless routing control method for real-time edge computing at a convergence node as described in claim 1, characterized in that: The implementation process of deploying multiple aggregation nodes in an edge computing network and defining upstream and downstream relationships between adjacent nodes is as follows: Multiple aggregation nodes are discretely deployed within the edge computing coverage area; Two nodes exchange node identifiers through a two-way handshake. If several consecutive handshakes are successful and the received signal strength is always higher than a preset threshold, they are determined to be adjacent nodes. Two adjacent nodes establish a communication connection and determine the upstream and downstream relationship based on the sending direction during the first data packet transmission. The party that sends the data packet is the upstream node, and the party that receives the data packet and is responsible for forwarding it is the downstream node.

3. The wireless routing control method for real-time edge computing at a convergence node as described in claim 1, characterized in that: The implementation process of the self-testing of local computing load is as follows: During each self-test cycle, the aggregation node sequentially checks the number of tasks waiting to be scheduled in the CPU's run queue, the amount of free memory, and the queue depth of locally stored data packets. Compare the results of each test with their respective limits. If none of the three tests exceed the corresponding limits, the test is marked as low load. If only one test exceeds the limit, the test is marked as medium load. If two or more test results exceed the limit, the test is marked as high load.

4. The wireless routing control method for real-time edge computing at a convergence node as described in claim 3, characterized in that: The process of classifying one's own state into a relaxed state, a moderate state, or a tense state is as follows: The aggregation node records the number of times each load marker appears in multiple consecutive self-test cycles; If a high load flag appears in at least one cycle, the state is set to a tense state. If no high load flag appears, compare the number of occurrences of the low load flag and the medium load flag: if the number of occurrences of the low load flag is greater than the number of occurrences of the medium load flag, set its own state to relaxed; otherwise, set its own state to moderate.

5. The wireless routing control method for real-time edge computing at a convergence node as described in claim 1, characterized in that: Each aggregation node records the data flow path forwarded by itself, and the specific content of grouping multiple paths sharing the same congested node into an association group is as follows: The aggregation node establishes a path record table for each destination address, and each entry in the table contains a sequence of downstream nodes; When a convergence node successfully forwards a data packet to a downstream node of a path and receives an acknowledgment, it keeps the path record unchanged; when forwarding fails, it records the path as an invalid path in the path record table. The aggregation node checks the downstream node sequence of the currently valid path in the path record table. If two or more paths contain the same node in their respective downstream node sequences that is currently in a tense state, i.e. a congested node, then these paths are classified into the same association group.

6. The wireless routing control method for real-time edge computing at a convergence node as described in claim 1, characterized in that: The process for determining the data forwarding request is as follows: After receiving a data packet forwarded from an upstream node or a data packet generated by itself, the aggregation node parses the destination address of the data packet; If the destination address is not this node and this node is not the final recipient of the data packet, then a data forwarding request is determined to be generated.

7. The wireless routing control method for real-time edge computing at a convergence node as described in claim 1, characterized in that: The process for determining whether the link is working properly is as follows: Each sink node records a consecutive success count and a consecutive failure count for each of its adjacent nodes, both of which are initially set to zero. Each time a data packet is sent to a neighboring node and an acknowledgment is received from the link layer, the consecutive success count is incremented by one, while the consecutive failure count is reset to zero. When the consecutive success count accumulates to the preset success threshold, the link from the aggregation node to the adjacent node is determined to be in a smooth state. Whenever a data packet is sent and no acknowledgment is received or a retransmission request is received, the consecutive failure count is incremented by one, and the consecutive success count is reset to zero. When the consecutive failure count accumulates to the preset failure threshold, the link is determined to be in a blocked state.

8. The wireless routing control method for real-time edge computing at a convergence node as described in claim 1, characterized in that: The process of selecting preliminary candidate nodes is as follows: After the convergence node triggers the next hop selection, it iterates through all adjacent nodes that are downstream, and selects nodes with smooth links and relaxed states to form the first candidate set. If the first candidate set is not empty, the initial selection ends; if it is empty, the second candidate set is formed by selecting nodes with smooth links and moderate states. If the second candidate set is not empty, the initial selection ends; if it is empty, the third candidate set is formed by selecting nodes whose links are not smooth but whose state is relaxed. If the third candidate set is not empty, the initial selection ends; if it is empty, it is determined that there are no usable nodes.

9. The wireless routing control method for real-time edge computing at a convergence node as described in claim 8, characterized in that: After downgrading the status level of nodes belonging to the congestion-associated group among the initial candidate nodes, the final next-hop node is determined as follows: After selecting the first, second, and third candidate sets according to priority, the aggregation node checks the downstream nodes in each candidate set one by one: For each downstream node in the candidate set, if any path of the node belongs to the congestion association group, its own status is temporarily downgraded by one level; After the adjustment is completed, the candidate set is re-divided according to priority based on the downgraded state. The aggregation node selects a node from the re-divided first candidate set as the final next hop. If the first candidate set is empty, a node is selected from the second and third candidate sets in turn as the final next hop.

10. The wireless routing control method for real-time edge computing at a convergence node as described in claim 1, characterized in that: The process of temporarily storing data packets and waiting for a broadcast cycle, followed by sending a forwarding failure notification to the upstream node after a timeout, includes the following: When it is determined that there are no available downstream nodes, the aggregation node starts a timer with a duration of one routing status message broadcast cycle; During the timer's operation, the current data packet is kept at the head of the sending queue, and routing status messages from neighboring nodes are continuously received. Upon receiving a message, the state of adjacent nodes is updated and the next hop selection is re-executed; if a next hop is selected before the timer expires, the data packet is forwarded and the timer is canceled. If no available node is found after the timer expires, the data packet is discarded, and a forwarding failure notification is sent to the upstream node that sent the data packet.

Images