Low-altitude relay and channel switching method based on starburst technology and communication node

Abstract

The application discloses a low-altitude relay and channel switching method based on star flash technology and a communication node. The method comprises the following steps: confirming that a direct link with a target node cannot meet a service transmission requirement, and sending a relay discovery request to a neighboring area; receiving a relay response returned by at least one node, wherein the relay response carries state information of the corresponding node, and the state information comprises at least one of the following: link quality of a candidate node to the target node, a load state of the candidate node, buffer occupancy of the candidate node, a forwarding success rate of the candidate node, link stability in a short time window, and whether to allow to undertake a relay responsibility; performing relay performance evaluation on the corresponding node according to the state information, and determining a target relay node from the at least one node according to an evaluation result. Some embodiments of the application ensure the stability and accuracy of relay selection, so that the selected relay can truly meet the requirements of service transmission.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, the embodiments of this application relate to a low-altitude relay and channel switching method based on star flash technology, as well as a communication node. Background Technology

[0002] In low-altitude wireless communication applications, communication nodes primarily facilitate network communication between ground-based data acquisition, sensing, and monitoring equipment and related terminals, rather than direct communication between aircraft in the air. These nodes are typically deployed in a distributed manner and are susceptible to factors such as equipment spacing, obstacle obstruction, frequency band interference, environmental changes, and link fluctuations, leading to communication connection attenuation, jitter, or even interruption. To ensure the continuity and reliability of low-altitude monitoring and ground sensing services, the relevant communication systems usually need to possess capabilities such as relay connection, link status awareness, and adaptive channel switching.

[0003] Currently, existing wireless communication solutions typically employ basic relay forwarding mechanisms for relay functionality. When a direct link cannot meet communication needs, a node can request assistance from nearby nodes for forwarding. However, existing solutions often rely on a single metric (such as signal strength or hop count) to select relay nodes, and once a relay path is established, it tends to remain fixed.

[0004] In terms of dynamic channel handover, existing technologies mostly employ handover strategies based on signal strength thresholds. When the signal strength falls below a set threshold, a node triggers channel handover. In low-altitude environments where channel quality fluctuates frequently, this approach is prone to frequent handovers due to instantaneous signal attenuation, causing network oscillations. Furthermore, when interference persists, the simple handover condition may lead to a slow response, making it difficult to guarantee service continuity. In addition, existing handover mechanisms typically use a "disconnect first, reconnect later" approach. During the handover process, data fragments that have been sent but not yet acknowledged are often discarded, requiring retransmission of the entire packet by the upper-layer protocol, further exacerbating transmission interruptions and resource waste.

[0005] In summary, existing wireless communication solutions mostly employ relatively independent and static mechanisms for relay selection and channel switching, lacking collaborative optimization for complex low-altitude scenarios. This makes it difficult to achieve efficient and stable data transmission under conditions of link fluctuations, node movement, and variable interference. Summary of the Invention

[0006] The purpose of this application is to provide a low-altitude relay and channel switching method and communication node based on star-flash technology. Some embodiments of this application trigger relay discovery only when the direct link cannot meet transmission requirements, avoiding unnecessary signaling overhead. Relay performance is evaluated by comprehensively considering multiple types of information such as link quality, load, buffering, and stability fed back from candidate nodes, ensuring the stability and accuracy of relay selection. Finally, the relay node is determined based on the evaluation results, ensuring that the selected relay truly meets the requirements of service transmission. This conditionally triggered, multi-dimensionally evaluated, and optimal selection mechanism effectively avoids frequent path interruptions and data retransmissions caused by incorrect relay selection in traditional solutions, significantly improving the stability of relay links and overall transmission efficiency.

[0007] In a first aspect, embodiments of this application provide a low-altitude relay and channel switching method based on star-flash technology. The method includes: confirming that the direct link with the target node cannot meet service transmission requirements, then sending a relay discovery request to a neighboring area; receiving a relay response from at least one node, wherein the relay response carries status information of the corresponding node, the status information including at least one of the following: link quality from the candidate node to the target node, load status of the candidate node, buffer usage of the candidate node, forwarding success rate of the candidate node, link stability within a short time window, and whether it is allowed to assume relay responsibilities; evaluating the relay performance of the corresponding node based on the status information, and determining a target relay node from the at least one node based on the evaluation results.

[0008] The embodiments of this application trigger relay discovery only when the direct link cannot meet the transmission requirements, avoiding unnecessary signaling overhead. Relay performance is evaluated by comprehensively considering multiple factors such as link quality, load, buffering, and stability feedback from candidate nodes, ensuring the stability and accuracy of relay selection. Finally, the relay node is determined based on the evaluation results, ensuring that the selected relay truly meets the service transmission requirements. This conditionally triggered, multi-dimensionally evaluated, and optimal selection mechanism effectively avoids frequent path interruptions and data retransmissions caused by incorrect relay selection in traditional solutions, significantly improving the stability of relay links and overall transmission efficiency.

[0009] In some embodiments, the low-altitude relay and channel switching method based on star-flash technology further includes: receiving status update information periodically sent by the target relay node, wherein the status update information is used to indicate the forwarding capability or operating status of the target relay node.

[0010] Some embodiments of this application establish a continuous state feedback mechanism between the source node and the target relay node, enabling the source node to monitor the relay node's forwarding capability, load changes, and link status in real time. When the target relay node's forwarding capability decreases or its operating status becomes abnormal, the source node can promptly trigger measures such as path reassessment, thereby avoiding communication interruptions caused by relay node failure. This significantly improves the stability and service continuity of relay communication.

[0011] In some embodiments, the relay response is obtained by the relay response sending node using a random backoff method.

[0012] Some embodiments of this application employ a random backoff mechanism when peripheral nodes respond to relay acknowledgments, effectively avoiding air collisions and signaling congestion caused by multiple candidate nodes responding simultaneously. Each node responds in a randomly selected time slot, allowing the source node to clearly receive the status information of each candidate node. This provides a complete and reliable data foundation for the comprehensive evaluation of relay performance, improving the success rate and efficiency of the relay discovery process.

[0013] In some embodiments, the step of evaluating the relay performance of the corresponding nodes based on the status information and determining the target relay node from the at least one node based on the evaluation results includes: eliminating nodes that do not meet preset conditions based on the status information to obtain a first candidate node group, wherein the preset conditions include at least one of the following: link quality is lower than the minimum availability threshold, cache usage exceeds the upper limit threshold, load status exceeds a preset value, or is not allowed to assume the relay role; prioritizing the first candidate node group according to link performance to obtain a relay candidate node queue, wherein the link performance is characterized at least by link quality and link stability within a short time window; and selecting the target relay node from the relay candidate node queue.

[0014] Some embodiments of this application achieve precise selection of relay nodes through a hierarchical screening mechanism: First, nodes that do not meet the basic conditions are eliminated to ensure that the candidate set has basic forwarding capabilities; then, multiple dimensions such as link quality and short-term stability are comprehensively considered to prioritize the nodes, so that the ranking results reflect both the instantaneous quality of the current link and the fluctuation of the nodes within a short time window, avoiding the selection of unstable nodes with strong signals but large fluctuations. This mechanism of filtering first, then ranking, and selecting the best upgrades the relay selection from a single-indicator coarse screening to a multi-dimensional fine evaluation, significantly improving the reliability and stability of relay paths.

[0015] In some embodiments, selecting the target relay node from the relay candidate node queue includes: selecting a primary relay node and at least one backup relay node from the relay candidate node queue, wherein the primary relay node is used for this communication, and the backup relay node is used as a new primary relay node when the status update information of the primary relay node meets the path switching conditions.

[0016] Some embodiments of this application establish a backup relay in addition to the primary relay, constructing a primary-backup collaborative relay path guarantee mechanism. When the primary relay is unable to continue its forwarding tasks due to link deterioration, excessive load, or forwarding failure, the source node does not need to re-initiate a large-scale relay discovery; it can directly switch to a new primary relay from the backup relay, greatly shortening the path recovery time. This primary-backup hot standby design effectively avoids long communication gaps after relay path interruption, significantly improving the continuity of multi-hop communication and the network's resilience to disturbances.

[0017] In some embodiments, the low-altitude relay and channel switching method based on star-flash technology further includes: confirming that the overall path availability is better than the current path after adding a next-level relay, wherein the overall path availability is evaluated using at least one of the following parameters: latency, air interface occupancy, state maintenance complexity, and recovery cost; extending the next relay layer, and the total number of relay layers is constrained by the maximum number of hops and path cost.

[0018] Some embodiments of this application achieve accurate control over multi-level relay paths by introducing dual constraints of maximum hop count and path cost. When communication cannot be completed through a single-level relay, the system does not blindly increase the hop count, but comprehensively evaluates dimensions such as latency, air interface occupancy, state maintenance complexity, and recovery cost, and only allows the establishment of multi-level relays when the overall availability of the extended path is better than the current path. This necessary and controllable multi-level mechanism ensures that detour capability is still available in complex terrain, while avoiding problems such as increased latency and excessive resource consumption caused by too many hops, thus achieving a balance between scalability and efficiency.

[0019] In some embodiments, prioritizing the first candidate node group based on link performance to obtain a relay candidate node queue includes: determining the service type of the data to be transmitted; selecting a matching sorting principle based on the service type; and sorting each node in the first candidate node group according to the sorting principle to obtain the relay candidate node queue, wherein the sorting principle includes: for first-priority services, sorting nodes according to link quality and link stability within a short time window; for second-priority services, sorting nodes according to load level and cache utilization.

[0020] Some embodiments of this application introduce a service type-aware relay selection mechanism, enabling path optimization to truly serve service needs. For high-priority services such as control commands and alarms, nodes with good link quality, strong stability, and low latency are prioritized to ensure fast and reliable transmission of critical commands. For ordinary status data, nodes with low load, sufficient buffers, and long-term sustainable forwarding capabilities are prioritized to avoid overall transmission efficiency degradation due to relay node overload. This differentiated relay selection strategy, while ensuring the service quality of critical services, achieves balanced utilization of network resources and significantly improves the overall performance of concurrent transmission of multiple services in complex low-altitude environments.

[0021] In some embodiments, the method further includes: evaluating the state of the current communication channel based on link quality parameters of the current communication channel; and determining, based on the state, whether to trigger a target search and channel switching.

[0022] Some embodiments of this application determine whether to trigger the process of finding a target and switching channels based on the current state of the communication channel, thereby avoiding the degradation of communication quality caused by frequent channel switching.

[0023] In some embodiments, evaluating the state of the current communication channel based on the link quality parameters of the current communication channel includes: obtaining the link quality parameters of the current communication channel over multiple consecutive sampling periods, wherein the link quality parameters include at least one of the following: current signal strength, successful transmission / reception ratio, retransmission count, channel busy / idle status, and service buffer changes; calculating a corresponding comprehensive link quality score based on the link quality parameters of each sampling period; determining the link quality change trend based on the comprehensive link quality score corresponding to the multiple consecutive sampling periods; and determining the state of the current communication channel based on the link quality change trend.

[0024] Some embodiments of this application periodically collect multi-dimensional link quality parameters and calculate a comprehensive score. Trend analysis of the scores across multiple sampling periods enables nodes to accurately identify a continuous downward trend in link quality, rather than misjudging due to momentary fluctuations. This trend-based link status assessment mechanism provides precise triggering criteria for relay discovery, effectively avoiding unnecessary relay switching caused by momentary signal jitter. Simultaneously, it ensures timely relay discovery when the link truly deteriorates, thereby reducing signaling overhead while maintaining service continuity.

[0025] In some embodiments, determining the link quality change trend based on the comprehensive link quality score corresponding to the multiple consecutive sampling periods, and determining the state of the current communication channel based on the link quality change trend, includes: confirming that the comprehensive link quality score continuously decreases and multiple consecutive comprehensive link quality scores are below a first threshold during the multiple consecutive sampling periods, then setting the current communication channel to a link attention state; determining whether to trigger the search for a target switching channel based on the state of the current communication channel includes: confirming that the current communication channel is in the link attention state, then initiating candidate channel evaluation to obtain a target switching channel.

[0026] Some embodiments of this application only enter the attention state when the comprehensive link quality score of the current communication channel continuously declines for multiple cycles and falls below a preset threshold, thereby avoiding false triggering caused by fluctuations in a single measurement. Once the channel enters the attention state, the system does not immediately perform a handover, but instead initiates candidate channel evaluation in advance, making ample preparations for a subsequent handover if it yields benefits. This mechanism of first judging trends and then preparing in advance effectively avoids the two extremes of traditional solutions—either slow response or oversensitivity—ensuring timely handover while suppressing unnecessary channel oscillations and significantly improving network stability in complex electromagnetic environments.

[0027] In some embodiments, the low-altitude relay and channel switching method based on star flash technology further includes: generating a channel switching command when the comprehensive link quality score of the target switching channel is higher than that of the current communication channel for multiple consecutive evaluation cycles and the difference exceeds a preset switching threshold.

[0028] Some embodiments of this application determine that channel switching is only triggered when the potential channel to be switched is higher than the current channel for multiple consecutive evaluation periods and the difference between the two exceeds a preset switching threshold (i.e., ensuring that the quality of the candidate channel is consistently and significantly better than the current channel). This beneficial switching mechanism avoids frequent switching (ping-pong effect) caused by instantaneous signal fluctuations and prevents repeated oscillations when channel quality is similar, thereby significantly improving the overall stability of the network while ensuring service continuity.

[0029] In some embodiments, the method further includes: confirming that the overall link quality score of the current communication channel in the link concern state further decreases and continuously falls below a second threshold, then confirming that the channel to be evaluated is in a risk state; if the channel to be evaluated is confirmed to be in the risk state, then generating a channel switching instruction.

[0030] Some embodiments of this application refine the channel quality degradation process into two stages: concern and risk, by setting two levels of state thresholds (concern threshold and risk threshold). When the link enters the concern state, the system only initiates candidate channel evaluation without immediate switching, avoiding unnecessary switching caused by instantaneous signal fluctuations; actual switching is only performed when the link further deteriorates and enters the risk state. This progressive state determination mechanism ensures timely switching (rapid response when the link truly deteriorates) and effectively suppresses frequent switching caused by short-term fluctuations (ping-pong effect), significantly improving network stability in complex electromagnetic environments.

[0031] In some embodiments, the channel switching instruction includes at least a target channel identifier, a switching effective time, a switching sequence number, and a recovery identifier; the wireless communication method further includes: before the switching effective time arrives, continuing to process transmitted but unacknowledged data fragments on the current communication channel, and freezing the delivery of new ordinary service data on the channel to be evaluated; after the switching effective time arrives, sending newly generated service data on the target switching channel; transferring unacknowledged data fragments to the recovery queue of the target switching channel, and retaining the original service flow identifier, fragment sequence number, and recovery identifier, and having the target switching channel continue to perform selective retransmission.

[0032] Some embodiments of this application achieve seamless service transition by dividing the channel handover process into multiple stages. Before the handover takes effect, the old channel continues to process unacknowledged fragments but freezes new services, preventing old data from being discarded and preventing new data from accumulating. After the handover takes effect, new services are immediately sent on the new channel to ensure timeliness. This staged handover mechanism, which uses parallel old and new channels, window buffering, and flag-based continuation, effectively avoids data interruptions and packet retransmissions caused by the first disconnection and then reconnection in traditional handover, significantly improving the continuous transmission capability of low-altitude services in channel handover scenarios.

[0033] In some embodiments, the method further includes: for high-priority short messages of the control, alarm, and recovery confirmation categories, during the transition phase before and after the handover effective time, using the channel to be evaluated and the currently switched channel for dual-channel redundant transmission.

[0034] Secondly, some embodiments of this application provide a communication node, which includes: a memory for storing instructions; and a processor for executing the instructions, causing the communication node to perform the low-altitude relay and channel switching method based on star-flash technology described in any of the embodiments of the first aspect above. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is one of the interaction diagrams for the low-altitude relay and channel switching method based on star flash technology provided in the embodiments of this application.

[0037] Figure 2 This is the second interactive diagram of the low-altitude relay and channel switching method based on star flash technology in this application. Detailed Implementation

[0038] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0039] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0040] The relay proposed in this application is not simply forwarding whenever a node is available, but rather a multi-level relay selection and path optimization method designed for complex low-altitude scenarios. Its goal is not to blindly increase the number of hops, but rather to select more suitable relay nodes and more stable forwarding paths through software algorithms, based on the capabilities of existing satellite flash modules, in scenarios such as building obstruction, mountain barriers, weak coverage areas, and areas with strong local interference, thereby improving the actual link availability, ensuring more continuous transmission, and faster recovery.

[0041] It should be noted that all communication nodes in the embodiments of this application possess a complete set of capabilities at the software architecture level, including but not limited to communication management, link awareness, status maintenance, task scheduling, data caching, and relay coordination. The role of a node in the network (such as source node, target node, management node, relay node, or ordinary service node) is not fixed but dynamically determined based on factors such as the current network environment, link status, node load, and service requirements. Therefore, the role labels for specific nodes in the accompanying drawings (such as source node, management node, relay node, etc.) are only used to exemplify the communication process in a specific scenario and do not constitute a limitation on the fixed roles or functional limitations of nodes. In actual operation, the same physical node can assume different logical roles at different stages or under different network conditions. That is to say, in some embodiments of this application, the nodes are master-slave integrated and their roles can be dynamically switched.

[0042] For example, some embodiments of this application provide a low-altitude relay and channel switching method based on star-flash technology. The method includes: confirming that the direct link with the target node cannot meet service transmission requirements, then sending a relay discovery request to a neighboring area; receiving a relay response from at least one node, wherein the relay response carries status information of the corresponding node, the status information including at least one of the following: link quality from the candidate node to the target node, load status of the candidate node, buffer usage of the candidate node, forwarding success rate of the candidate node, link stability within a short time window, and whether it is allowed to assume relay responsibilities; evaluating the relay performance of the corresponding node based on the status information and determining the target relay node from the at least one node based on the evaluation results.

[0043] It is easy to understand that some embodiments of this application trigger relay discovery only when the direct link cannot meet the transmission requirements, avoiding unnecessary signaling overhead. Relay performance is evaluated by comprehensively considering various information such as link quality, load, buffering, and stability fed back from candidate nodes, ensuring the stability and accuracy of relay selection. Finally, the relay node is determined based on the evaluation results, ensuring that the selected relay truly meets the requirements of service transmission. This conditionally triggered, multi-dimensionally evaluated, and optimal selection mechanism effectively avoids frequent path interruptions and data retransmissions caused by incorrect relay selection in traditional solutions, significantly improving the stability of relay links and overall transmission efficiency.

[0044] It should be noted that, in some embodiments of this application, the low-altitude relay and channel switching method based on star-flash technology further includes: receiving status update information periodically sent by the target relay node, wherein the status update information is used to indicate the forwarding capability or operating status of the target relay node. Embodiments of this application can assess the status of the target relay channel based on the received status update information of the target relay node, avoiding disruption to normal communication due to deterioration in channel communication quality. In some embodiments of this application, the relay response is obtained by the relay acknowledgment sending node replying to the relay discovery request using a random backoff method.

[0045] In some embodiments of this application, the above-mentioned evaluation of relay performance of corresponding nodes based on the status information and determination of target relay nodes from the at least one node based on the evaluation results includes: eliminating nodes that do not meet preset conditions based on the status information to obtain a first candidate node group, wherein the preset conditions include at least one of the following: link quality is lower than the minimum availability threshold, cache usage exceeds the upper limit threshold, load status exceeds a preset value, or is not allowed to assume the relay role; prioritizing the first candidate node group according to link performance to obtain a relay candidate node queue, wherein the link performance is characterized at least by link quality and link stability within a short time window; and selecting the target relay node from the relay candidate node queue.

[0046] In some embodiments of this application, at least one backup relay node needs to be selected in order to promptly replace the primary relay node whose communication performance cannot meet the requirements. For example, in some embodiments of this application, selecting the target relay node from the relay candidate node queue includes: selecting a primary relay node and at least one backup relay node from the relay candidate node queue, wherein the primary relay node is used for this communication, and the backup relay node is used as the new primary relay node when the status update information of the primary relay node meets the path switching conditions.

[0047] Some embodiments of this application also support multi-level relays. That is, in some embodiments of this application, the wireless communication method further includes: confirming that the overall path availability is better than the current path after adding a next-level relay, wherein the overall path availability is evaluated using at least one of the following parameters: latency, air interface occupancy, state maintenance complexity, and recovery cost; extending the next relay layer, and the total number of relay layers is constrained by the maximum number of hops and path cost.

[0048] To accommodate different types of data to be transmitted, the sorting principles for nodes in the relay candidate node queue in some embodiments of this application are variable. For example, in some embodiments of this application, the step of prioritizing the first candidate node group based on link performance to obtain the relay candidate node queue includes: determining the service type of the data to be transmitted; selecting a matching sorting principle based on the service type; and sorting each node in the first candidate node group according to the sorting principle to obtain the relay candidate node queue. The sorting principle includes: for first-priority services, sorting nodes according to link quality and link stability within a short time window; for second-priority services, sorting nodes according to load level and cache utilization.

[0049] Please refer to Figure 1 , Figure 1This paper illustrates the relay processing strategies included in the low-altitude relay and channel handover method based on star-flash technology provided in some embodiments of this application. The figure uses a source node, a first node, a second node, a third node, and a target node as examples to illustrate the relay processing strategies included in the low-altitude relay and channel handover method based on star-flash technology in some embodiments of this application.

[0050] Figure 1 Low-altitude relay and channel handover methods based on star flash technology include:

[0051] If it is confirmed that the direct link between the source node and the target node does not meet the communication requirements, relay discovery is triggered.

[0052] The source node enters the relay evaluation state and sends relay discovery requests to the first node, the second node, and the third node, respectively.

[0053] The first relay node randomly backs off for 50ms before sending a relay response to the source node. This response carries information about the link quality, load, buffer capacity, and stability level. For example, the first node might have a link quality of 90, a load of 30, a buffer capacity of 20%, and high stability.

[0054] The second relay node randomly backs off for 100ms before sending a relay response to the source node. This response carries information about the link quality, load, buffer capacity, and stability level. For example, the second node might have a link quality of 85, a load of 60, a buffer capacity of 50%, and medium stability.

[0055] The third relay node randomly backs off for 150ms before sending a relay response to the source node. This response carries information about the link quality, load, buffer capacity, and stability level. For example, this third node might have a link quality of 95, a load of 80, a buffer capacity of 70%, and low stability.

[0056] In other words, in some embodiments of this application, when a source node sends data to a target node, if a continuous degradation in the quality of the direct link is detected for several consecutive periods or a preset threshold is reached for consecutive transmission failures (i.e., confirming that the direct link between the source node and the target node does not meet communication requirements), the target node is not immediately determined to be disconnected from the network. Instead, it enters a relay evaluation state (confirming the initiation of the relay evaluation process). At this time, the source node initiates a relay discovery request to the neighboring area. Surrounding nodes (e.g., Figure 1Upon receiving a request, the first, second, and third candidate nodes do not respond immediately but instead distribute their responses according to random backoff times to avoid collisions caused by multiple candidate nodes returning simultaneously. Each candidate node's response includes a necessary state summary, including its current link quality (a quantified value of the link quality between the node and the requesting source node and the destination node in this communication, as assessed by the node itself; this level can be calculated based on the signal strength (RSSI) and signal-to-noise ratio (SNR) of the received relay discovery request), reachability to the target node (the node determines reachability by maintaining a neighbor table and routing table, or by listening to the target node's broadcast / heartbeat), and current load (the amount of traffic the node is currently processing, such as the number of traffic per second, the number of currently active traffic flows, etc.; the node's internal counter counts the number of currently active traffic flows, queue length, or time per unit). The data includes: number of packets sent within the node, cache usage (the node's current memory usage for data caching, such as used cache / total cache; the node's operating system or protocol stack provides a memory management interface that can directly read the current cache usage); remaining available forwarding capacity (how many additional relay forwarding tasks the node can still handle, usually determined by a combination of load, cache, and preset capacity limits); and whether the node is allowed to assume relay responsibilities (whether the node itself is willing and allowed to be selected as a relay. Some nodes may proactively declare that they will not assume relay responsibilities due to energy saving, task criticality, etc.; the node sets a boolean flag (allow / disallow) based on local configuration, current task priority, remaining power, or user policy).

[0057] In some embodiments of this application, the reachability to the target node can be determined by means of a reachable node record table, etc. For example, in some embodiments of this application, each node does not rely on a central node to uniformly maintain the network routing, but maintains a neighbor information table locally by periodically sending and receiving strong heartbeats or status messages; when relay selection or target node reachability judgment is required, a reachable node record table or a next-hop candidate table can be further maintained. Among them, 1) the neighbor information table is used to record the information of neighboring nodes that have a direct communication relationship with this node, including at least: neighbor node identifier; the time when the strong heartbeat or status message of the neighbor was last received; the current working channel; the received signal strength RSSI; the signal-to-noise ratio SNR; the link quality score; the current load of the neighbor node; the buffer usage of the neighbor node; and whether the neighbor node is allowed to assume relay responsibilities. 2) the reachable node record table is used to record the reachability from this node to the target node, including at least: the target node identifier; the reachability status; the recommended next-hop node identifier; the number of hops; the path quality score; and the last update time. For example: 0: Unreachable, no direct heartbeat from the target node was received within the preset time limit, and no valid relay reachability information was obtained from neighboring nodes. 1: Reachable (Directly Connected), the node directly received a strong heartbeat or status message from the target node within the preset time limit, and the corresponding link quality was higher than a preset threshold. 2: Reachable (Multi-Hop), although the node is not directly connected to the target node, it obtained a reachability summary, next-hop information, or relay probe response from one or more neighboring nodes, indicating that the target node can be reached via a relay path.

[0058] In some embodiments of this application, the remaining available forwarding capacity can be defined as: Remaining forwarding capacity = Maximum number of relays that can be handled - Number of relays currently handled, or, Remaining forwarding capacity = (1 - Current load / Maximum load) × (1 - Buffer usage) × Capacity coefficient. The first formula represents the quantification of discrete capacity, indicating how many relay tasks the node can still handle. The second formula is a continuous scoring quantification, indicating the strength of the node's current remaining forwarding capacity. In some embodiments of this application, the remaining available forwarding capacity is expressed by the formula: Nrem = max(0, Nmax − Ncur), where Nmax represents the maximum number of relay tasks the node can handle (preset), Ncur represents the number of relay tasks the node has currently handled, and Nrem represents the remaining relay slots for the node. In some embodiments of this application, the remaining forwarding capacity is represented by the formula: S fwd=1−(αL+βC+γR), where L represents the current load rate, with a value range of [0,1]; C represents the current cache occupancy rate, with a value range of [0,1]; R represents the relay occupancy rate, defined as R=Ncur / Nmax, with a value range of [0,1]; α,β,γ: weight coefficients, satisfying α+β+γ=1; Sfwd represents the remaining forwarding capacity score, with a value range of [0,1].

[0059] In other words, in some embodiments of this application, triggering relay discovery includes: when the first communication node detects a decline in the quality of the direct link for multiple consecutive cycles, or when the number of consecutive transmission failures reaches a preset threshold, entering a relay evaluation state and sending a relay discovery request to the neighboring area; receiving a relay response returned by at least one candidate node, wherein the relay response is sent in a distributed manner according to a random backoff time to avoid collisions caused by multiple candidate nodes responding simultaneously; the relay response carries a status summary of the candidate node, wherein the status summary includes at least one of the following: the current link level of this node, the reachability to the target node, the current load, buffer usage, remaining available forwarding capacity, and whether it is allowed to assume relay responsibilities.

[0060] It is not hard to understand that Figure 1 In the example, the candidate node carries its necessary state summary in the response, including the node's current link quality, load status, cache usage percentage, and stability level. In other embodiments of this application, the information carried by each candidate node in the response may also include the aforementioned remaining available forwarding capacity or reachability to the target node.

[0061] Figure 1 After receiving responses from each node, the source node removes unsuitable nodes, such as the third node, due to its excessive load. The remaining nodes that received responses are then comprehensively evaluated. Based on the evaluation results, the first node has the highest overall score, followed by the second node. Subsequently, the source node determines the primary relay node as the first node and the backup relay node as the second node based on the comprehensive scores.

[0062] In other words, in some embodiments of this application, after receiving a candidate response, the source node does not adopt a simple strategy of selecting the first responder or the one with the strongest signal, but instead uses a relay optimization algorithm to comprehensively evaluate the candidate nodes. The evaluation includes at least the following: the current link level from the source node to the candidate relay node, the current link level from the candidate relay node to the target node, the current service load of the candidate relay node, its available cache, recent forwarding success rate, and whether it has the ability to continuously undertake relay tasks.

[0063] For example, in some embodiments of this application, the relay selection algorithm includes: the source node first eliminates candidate nodes that do not meet basic conditions, such as nodes with link levels below the minimum available threshold, excessive cache usage, service load approaching the limit, or nodes explicitly declared to lack relay capabilities; then, the remaining candidate nodes are sorted by priority. During priority sorting, not only is the current instantaneous link quality compared (i.e., the current link level from the source node to the candidate relay node and the current link level from the candidate relay node to the target node), but also the stability within a short time window is compared (stability within a short time window refers to the degree of fluctuation or consistency of link quality between the source node and the candidate relay node, and between the candidate relay node and the target node, within a recent continuous period. It is a quantitative indicator reflecting the degree of fluctuation in link quality over a relatively short historical period. Commonly used parameters can be variance, standard deviation, or a coefficient of variation based on multiple measurements. This allows the "fluctuation magnitude" to be represented by a numerical value), avoiding the selection of nodes with strong instantaneous signals but large fluctuations. After sorting, the candidate node with the highest priority is set as the primary relay, and one or two nodes ranked after it are set as backup relays.

[0064] For example, in some embodiments of this application, stability within a short time window is not an isolated indicator completely independent of link quality, but rather an important parameter in the priority evaluation of candidate relay nodes. Stability within a short time window is the degree of stability obtained by statistically analyzing the changes in link quality based on the most recent preset number of strong heartbeats or status messages. For example, stability is first used as a pre-screening condition to eliminate candidate nodes whose link quality fluctuations exceed a preset threshold within the short time window; then, the remaining candidate nodes are comprehensively scored and ranked based on the current link quality, stability within the short time window, node load, buffer usage, and remaining forwarding capacity. This avoids selecting nodes with high instantaneous signal but large short-term fluctuations, and improves the continuous availability and path stability of relay selection. In some embodiments of this application, it is preferable to separately statistically analyze the fluctuations of the two links—from the source node to the candidate relay node and from the candidate relay node to the target node—in the most recent preset number of heartbeat records. If the fluctuation of either link exceeds a preset threshold, the candidate node is not given priority as a relay candidate. For candidate nodes that pass the stability screening, priority is then ranked based on the current link quality, current load, buffer usage, and remaining forwarding capacity. That is, filter first and then sort.

[0065] Figure 1The source node communicates through the primary relay node. The source node sends service data through the relay node, and the primary relay node forwards the service data to the target node. The target node sends an acknowledgment message to the primary relay node, which then sends an acknowledgment message back to the source node. It should be noted that the source node in this embodiment also needs to obtain status update information sent by the primary relay node and the backup relay node in real time or periodically (e.g., ...). Figure 1 The status update information shown can carry link quality parameters and load-related parameters. The source node then uses the received status update information to determine whether a replacement of the primary relay node is needed. For example, in... Figure 1 In this scenario, if the primary relay returns a status update indicating a link quality of 85 and a load of 50%, while the backup relay node reports a link quality of 80 and a load of 40%, the source node determines that the primary relay link has deteriorated and triggers a relay switchover. Specifically, the source node sends a stop relay command to the primary relay node and a switchover command to the backup relay node. Then, the backup relay node continues to transmit service data from the source node, and subsequently forwards the service data to the target node.

[0066] In other words, in some embodiments of this application, after the primary relay is established, the source node continues to receive the status summary of the primary relay during the transmission process, including link changes, load changes, and forwarding results. If the primary relay fails to forward for several consecutive cycles, the link level continues to decline, the cache approaches its limit, or the service load exceeds the threshold, a full network search is not performed again. Instead, a new primary relay is selected from the backup relay to shorten the path recovery time. The source node only re-initiates the candidate discovery process when neither the primary nor backup relays meet the requirements. For example, in an embodiment of this application, the process by which the source node determines the primary relay node and backup relay node from at least one candidate node using a relay optimization algorithm includes: eliminating candidate nodes that do not meet preset basic conditions, the preset basic conditions including at least one of the following: link level below the minimum availability threshold, cache usage exceeding the upper limit threshold, service load close to the upper limit, and candidate node declaring that it does not have relay capability; prioritizing the remaining candidate nodes, the priority ranking comprehensively considers at least two of the following factors: the current link level from the source node to the candidate relay node, the current link level from the candidate relay node to the target node, the current service load of the candidate relay node, cache availability, and recent forwarding success rate; the first communication node determines the candidate node with the highest priority as the primary relay node, and determines one or more candidate nodes with the second highest priority as backup relay nodes.

[0067] It should be noted that in some embodiments of this application, multi-level relay is also required to transmit the data of the source node.

[0068] In other words, in some embodiments of this application, for scenarios where communication cannot be completed through a single-level relay, the source node can continue to request the next-level candidate node based on the main relay. However, each additional relay level requires re-performing the candidate evaluation and is subject to the maximum number of hops and path cost constraints, preventing excessive relay levels from leading to excessive latency and a significant increase in management overhead.

[0069] For example, in some embodiments of this application, the implementation process of multi-hop relay includes:

[0070] In scenarios where communication cannot be completed through a single-level relay, the source node can continue to build a multi-level relay path through the established primary relay. Specific implementation steps include:

[0071] Initiating next-level relay discovery: The source node sends a relay discovery request to the next-level area through the current primary relay node. After receiving the request, the primary relay node, acting as the "source node," broadcasts the request to neighboring nodes and receives responses from surrounding candidate nodes.

[0072] Candidate Node Response and Information Reporting: Upon receiving a request, surrounding candidate nodes will return relay responses in a distributed manner using a random backoff method. The response must carry the same status digest information as a single-level relay, including: the link level between this node and the main relay, the reachability of this node to the target node (if known), current load, buffer usage, remaining available forwarding capacity, and whether it is allowed to assume relay responsibilities.

[0073] Next-level relay selection: The primary relay node (as the decision-maker at this level) eliminates candidate nodes that do not meet the basic conditions (such as low link level, high cache, excessive load, or explicit refusal to undertake relay) based on the received candidate responses. Then, it prioritizes the nodes based on factors such as instantaneous link quality, short-term stability, load, available cache, and recent forwarding success rate, and finally selects the node with the highest priority as the next-level relay. At the same time, alternative nodes can be determined.

[0074] Multi-level path cost constraints and maximum hop count limits: Before expanding each level of relay, it is necessary to verify whether the overall path cost after adding a new level exceeds a preset threshold and whether the hop count exceeds the system's maximum allowed hop count. Path cost is defined as a comprehensive indicator, which can be calculated based on the following weighted factors:

[0075] Cumulative end-to-end delay: The sum of the delays of each hop link. The delay can be estimated based on the link distance and load conditions.

[0076] Cumulative air interface overhead: For each additional hop, the data frame needs to occupy the channel multiple times. The cumulative air interface occupancy time can be quantified as the sum of the estimated transmission times of each hop.

[0077] State maintenance complexity: can be simplified to the number of hops itself, or the cache usage changes of each hop node can be considered.

[0078] Recovery cost: An estimate of the signaling overhead required to restore a multi-hop path after it has been interrupted.

[0079] A path cost upper limit Cmax can be set, and a path cost function C=w1⋅D+w2⋅H+w3⋅L can be defined, where D is the cumulative delay, H is the number of hops, and L is the cumulative load factor. A new relay level is allowed to be established only if the path cost Cnew calculated after adding a new level is less than the current path cost Ccurrent and does not exceed Cmax, and the number of hops does not exceed the maximum hop count threshold (e.g., 3 hops); otherwise, expansion is stopped, the existing path is maintained, or another relay is selected.

[0080] Iteration or Termination: If a multi-hop path is successfully established, subsequent data from the source node can be sent along that path. During communication, each relay level must continuously monitor the link status. If a primary relay fails, the backup relay at that level should be used first to switch over, avoiding full path reconstruction. If the path cost continues to deteriorate due to environmental changes and exceeds the constraints, a network-wide rediscovery or switchover to a backup path will be triggered.

[0081] Through the above steps, the construction of multi-level relays in this application not only ensures the rationality of each hop selection, but also avoids resource waste and performance degradation caused by unlimited expansion through strict cost constraints, thus achieving the optimization goal of necessary and controllable multi-level relays.

[0082] Unlike related technologies, the relay selection in some embodiments of this application is not a one-time event. After the relay is established, the source node and the relay node continue to maintain the path state. If the link grade of the primary relay node continues to decline, forwarding failures increase, the cache approaches its limit, or the load increases significantly, the system will trigger path reassessment, switch to a new primary relay from the backup relay, or re-initiate neighbor discovery. This avoids the common problem in the prior art where the selected relay remains unchanged for a long time after the initial selection until it completely fails and is then rebuilt.

[0083] In some embodiments of this application, for situations where communication cannot be completed through a single-level relay, multi-level relay paths are allowed. However, the number of hops is not unlimited; it is controlled by path cost. The path cost here considers not only reachability but also the latency, air interface occupancy, state maintenance complexity, and recovery costs incurred by adding a relay level. Some embodiments of this application only allow expansion to a second or third level relay if the overall availability after adding a relay level is better than the current path.

[0084] Furthermore, some embodiments of this application also consider the priority differences of low-altitude services. For high-priority services such as control commands, alarm information, and recovery requests, the relay path prioritizes candidate nodes with lower latency and higher stability; for ordinary status data or periodic monitoring data, relay nodes with long-term sustainability and more balanced load are prioritized. After the relay path is determined, subsequent data frame organization compression and relay stage reconstruction methods can be invoked during the forwarding process to reduce the air interface overhead caused by multi-level forwarding. In other words, different services can adopt different priority strategies under the same relay mechanism, so that path optimization serves the service, rather than just the connectivity itself.

[0085] In some embodiments of this application, the wireless communication method further includes: for first priority services, including control commands, alarm information, or recovery requests, prioritizing the selection of candidate nodes with lower latency and higher link stability as relays; for second priority services, including ordinary status data or periodic monitoring data, prioritizing the selection of candidate nodes with more balanced load and stronger sustainability as relays.

[0086] For example, in some embodiments of this application, during the priority ranking stage, the source node performs differentiated weighting on various evaluation indicators of candidate nodes according to the service type, thereby selecting the most suitable relay path for services of different priorities. For example, in some embodiments of this application, the source node directly judges the latency characteristics, stability, sustainability, and load balancing of each candidate node based on the status information periodically reported by the candidate nodes or carried through strong heartbeats. Latency characteristics can be judged based on information such as the response time of the most recent heartbeats, the forwarding confirmation return time, and the current queuing status of the sending queue; stability can be judged based on the fluctuations in the link quality records corresponding to the most recent heartbeats; sustainability can be judged based on the current load, cache usage, remaining available forwarding capacity, and whether there is a continuous deterioration trend; load balancing can be judged based on the number of relay tasks currently undertaken, the current forwarding traffic volume, and the remaining cache space. Successful transmission / reception ratios and retransmission burden indicators can be used as auxiliary references to supplement the judgment of link status, but are not the sole basis for latency characteristics.

[0087] In some embodiments of this application, after receiving a response from a candidate node, the source node first obtains parameters from each candidate node, including a comprehensive link quality score, short-term stability index, successful transmission / reception ratio, retransmission burden index, current load, buffer usage, remaining available forwarding capacity, and recent forwarding success rate. Then, the source node dynamically adjusts the weights of these parameters in the comprehensive priority calculation based on the priority type of the service to be sent.

[0088] For high-priority services such as control commands, alarm messages, and recovery requests, the source node increases the weight of the overall link quality score, short-term stability indicators, and the latency factor, which is composed of the successful transmission / reception ratio and retransmission burden indicators. The latency factor can be designed as a weighted combination of the successful transmission / reception ratio and the normalized retransmission burden indicator; for example, the higher the successful transmission / reception ratio and the lower the retransmission burden, the larger the latency factor. Simultaneously, the weights of indicators reflecting node busyness, such as load and buffer usage, are appropriately reduced, because high-priority services typically have short packets, allowing for rapid processing even with slightly higher node loads. Through this weight configuration, the candidate node with the highest overall priority is often the node with the best current link quality, the most stable connection, and the lowest latency, even if its current load is slightly higher. It is easy to understand that some embodiments of this application prioritize candidate nodes with higher current link quality, smaller recent heartbeat fluctuations, and lower current forwarding latency for high-priority services such as control commands, alarm messages, and recovery requests, to ensure rapid response and stable delivery.

[0089] For general status data or periodic monitoring services, the source node is given increased weight based on its current load, cache usage, and remaining available forwarding capacity. This is because these services require long-term, stable use of relay resources, and additional burdens on already busy nodes should be avoided. Link quality comprehensive score and stability indicators still need to be considered, but their weights are relatively reduced. The node with the highest overall priority calculated in this way is often one with low load, sufficient cache, and strong sustainability. Even if its instantaneous link quality is not optimal, it can still ensure long-term stable transmission of services. It is easy to understand that in some embodiments of this application, for general status data or periodic monitoring data, candidate nodes with consistently available links, low or stable load, low cache usage, and currently undertaking fewer relay tasks are preferentially selected to ensure continuous forwarding for a longer period and to prevent frequent path switching due to single-node overload.

[0090] In some embodiments of this application, when the current link quality of multiple candidate nodes is similar, nodes with low latency and low fluctuation are prioritized for high-priority services; for ordinary services, nodes with fewer relay tasks and larger buffer capacity are prioritized for allocation, so as to achieve service distribution and load balancing. The latency, stability, sustainability, and load balancing here are all derived from direct statistical results of the aforementioned node status information, and different selection orders are adopted according to the service type.

[0091] Finally, the source node recalculates the overall priority of each candidate node based on the adjusted weights and selects the node with the highest priority as the target relay node (including the primary relay node and at least one backup relay node). Throughout the communication process, if the service type changes, the source node can adjust the weights at any time to dynamically select the most suitable relay path for different types of services.

[0092] It should be noted that the wireless communication method in some embodiments of this application further includes: evaluating the state of the current communication channel based on the link quality parameters of the current communication channel; and determining whether to trigger a target search and channel switching based on the state. For example, in some embodiments of this application, evaluating the state of the current communication channel based on the link quality parameters of the current communication channel includes: obtaining the link quality parameters of the current communication channel over multiple consecutive sampling periods, wherein the link quality parameters include at least one of the following: current signal strength, successful transmission / reception ratio, retransmission count, channel busy / idle status, and service buffer changes; calculating a corresponding comprehensive link quality score based on the link quality parameters of each sampling period; determining the link quality change trend based on the comprehensive link quality score corresponding to the multiple consecutive sampling periods; and determining the state of the current communication channel based on the link quality change trend.

[0093] For example, in some embodiments of this application, determining the link quality change trend based on the comprehensive link quality score corresponding to the multiple consecutive sampling periods, and determining the state of the current communication channel based on the link quality change trend, includes: confirming that the comprehensive link quality score continuously decreases and multiple consecutive comprehensive link quality scores are below a first threshold during the multiple consecutive sampling periods, then setting the current communication channel to a link attention state; determining whether to trigger the search for a target switching channel based on the state of the current communication channel includes: confirming that the current communication channel is in the link attention state, then initiating candidate channel evaluation to obtain a target switching channel.

[0094] For example, in some embodiments of this application, the wireless communication method further includes:

[0095] When the overall link quality score of the target switching channel is higher than that of the current communication channel for multiple consecutive evaluation cycles, and the difference exceeds a preset switching threshold, a channel switching command is generated.

[0096] For example, in some embodiments of this application, the method further includes: confirming that the overall link quality score of the current communication channel in the link concern state further decreases and continuously falls below a second threshold, then confirming that the channel to be evaluated is in a risk state; if the channel to be evaluated is confirmed to be in the risk state, then generating a channel switching instruction.

[0097] For example, in some embodiments of this application, the channel switching instruction includes at least a target channel identifier, a switching effective time, a switching sequence number, and a recovery identifier; the wireless communication method further includes: before the switching effective time arrives, continuing to process transmitted but unacknowledged data fragments on the current communication channel, and freezing the delivery of new ordinary service data on the channel to be evaluated; after the switching effective time arrives, sending newly generated service data on the target switching channel; transferring unacknowledged data fragments to the recovery queue of the target switching channel, and retaining the original service flow identifier, fragment sequence number, and recovery identifier, and having the target switching channel continue to perform selective retransmission.

[0098] For example, in some embodiments of this application, the wireless communication method further includes: for high-priority short messages of control, alarm and recovery confirmation types, during the transition phase before and after the handover effective time, using the channel to be evaluated and the currently switched channel for dual-channel redundant transmission.

[0099] In other words, the dynamic channel switching in some embodiments of this application is not a simple fixed frequency hopping, nor is it a passive channel change after a complete communication interruption. Instead, it is an active switching method based on continuous link quality awareness. The core idea is: the node first continuously determines whether the current link can stably carry the current service, then determines whether there are more suitable candidate channels, and finally decides on the switching time, switching method, and continued service transmission after the switching. This avoids two common problems in existing solutions: one is being too sluggish, only processing when the link is clearly unavailable; the other is being too sensitive, frequently switching at the slightest signal fluctuation, which can lead to network instability.

[0100] In some embodiments of this application, each node periodically collects state variables related to the current link, including at least the current signal strength, the recent successful transmission / reception ratio, the number of retransmissions, the channel busy / idle status, and changes in service buffering. Specifically, signal strength reflects the basic coverage status of the current link; the successful transmission / reception ratio reflects the link's availability in actual services; the number of retransmissions reflects whether the current link has begun to deteriorate; the channel busy / idle status reflects the existence of local congestion or co-channel contention; and changes in service buffering reflect whether the current link has affected the continuity of upper-layer services. Through these types of information, the node not only checks for signal presence but also comprehensively judges whether the current link is suitable for continued use.

[0101] The following describes, with reference to the figures, the channel switching process included in some embodiments of the wireless communication method provided in this application.

[0102] Assume that the source node and the target node are currently operating on the first channel, meaning that the sender and receiver are communicating through the first channel at the current moment. During the communication process, the source node periodically collects the link quality parameters of the first channel and calculates a comprehensive link quality score based on the collected parameters. Then, it performs trend analysis based on the comprehensive link quality scores obtained for each sampling period using a sliding window (i.e., it determines the changing trend of the first channel by recording the scores of the most recent N sampling periods, where N is an integer greater than 1).

[0103] It should be noted that, for ease of engineering implementation, some embodiments of this application provide a comprehensive link quality scoring algorithm, the formula of which is:

[0104] L=a×R+b×S+c×I−d×T

[0105] in,

[0106] (L) represents the overall score of the current link;

[0107] (R) is the normalized signal quality index;

[0108] (S) represents the percentage of successful send and receive operations within the most recent window;

[0109] (I) is the channel idleness index;

[0110] (T) represents the retransmission burden indicator within the most recent window;

[0111] (a, b, c, d) are weight parameters.

[0112] The design principle of the above formula is that the link score increases with signal quality, success rate, and idle time, and decreases with increased retransmission burden. In actual deployment, different services can use different parameters. For example, control command services focus more on success rate and latency, so the weights of (b) and (d) can be appropriately increased; continuous monitoring data focuses more on stability, so the weight of (c) can be appropriately increased. In this way, the same set of algorithms can form an algorithm family to adapt to different low-altitude service scenarios.

[0113] In other words, in some embodiments of this application, the source node obtains at least one link quality parameter of the current link, including: periodically collecting state quantities related to the current link, wherein the state quantities include at least: current signal strength, successful transmission / reception ratio within the most recent window, number of retransmissions, channel busy / idle status, and service buffer changes; wherein, the current signal strength is used to reflect the coverage status of the link, the successful transmission / reception ratio is used to reflect the availability of the link in actual services, the number of retransmissions is used to reflect whether the link has begun to deteriorate, the channel busy / idle status is used to reflect whether there is local congestion or co-channel contention, and the service buffer changes are used to reflect whether the link has affected the continuity of upper-layer services. In some embodiments of this application, the source node evaluates the availability of the current link based on the link quality parameters, including: generating a comprehensive link quality score based on the current signal strength, successful transmission / reception ratio, channel busy / idle status, and number of retransmissions; the comprehensive link quality score is calculated according to the formula corresponding to the comprehensive link quality score algorithm above.

[0114] To avoid misjudgments caused by fluctuations in a single measurement, some embodiments of this application do not determine whether to switch based on a single score, but instead use a sliding window trend judgment. For example, in some embodiments of this application, the node continuously calculates the comprehensive link quality score for multiple sampling periods and analyzes the changes in these scores. When the comprehensive link quality score continues to decline and falls below a preset attention threshold, the node enters a link attention state; when the comprehensive link quality score further declines and falls below a risk threshold, the node enters a risk state. In other words, some embodiments of this application do not require switching as soon as the link deteriorates, but first observe the trend of the current communication link and then determine the action to be taken based on the trend. This can avoid frequent switching during low-altitude communication, such as when an aircraft makes a short-term turn or when a local blockage occurs momentarily, causing unnecessary frequent switching.

[0115] In some embodiments of this application, when the current communication link enters a state of interest, the node initiates candidate channel evaluation instead of immediately abandoning the current communication channel. The sources of candidate channels include a pre-configured set of available channels, recently reported preferred channel information from neighboring nodes, and the node's historical usage records. Then, the node performs lightweight probing of the candidate channels. This probing does not require prolonged occupation of the new channel; instead, it quickly assesses the availability of candidate channels through short listens, probing transmissions, or neighbor feedback. For each candidate channel, the node can also generate a candidate channel score for comparison with the current communication channel.

[0116] In other words, some embodiments of this application further include: the source node performs trend analysis on the comprehensive link quality score over multiple sampling periods using a sliding window method; when the comprehensive link quality score continuously decreases and falls below a preset attention threshold, the current link is determined to enter an attention state; when the comprehensive link quality score further decreases and falls below a preset risk threshold, the current link is determined to enter a risk state; the source node initiates candidate channel evaluation after the link enters the attention state, without immediately abandoning the current channel. In some embodiments of this application, initiating candidate channel evaluation includes: obtaining candidate channels from the following sources: a pre-configured set of available channels, preferred channel information reported by neighboring nodes, and historical usage records of this node; performing lightweight probing on the candidate channels, the lightweight probing including at least one of the following: short listening, tentative transmission, and obtaining neighbor feedback; generating a candidate channel score based on the probing results. In some embodiments of this application, it further includes: when the candidate channel score is higher than the current comprehensive communication link quality score for multiple consecutive evaluation periods, and the difference exceeds a preset switching threshold, the source node generates a channel switching instruction; the channel switching instruction at least includes a target channel identifier, a switching effective time, a switching sequence number, and a recovery identifier.

[0117] For example, Figure 2 If the score (i.e., the comprehensive link quality score of the current communication link) is determined to continuously decline and fall below the first threshold, the first channel enters the link attention state and reports this state to the management node. Subsequently, the source node initiates candidate channel evaluation: obtaining a list of candidate channels; for each candidate channel, performing lightweight probing (e.g., short listening / exploratory sending / neighbor feedback), and generating a candidate channel score based on the probing results. If, at this point, monitoring confirms that the first channel score is continuously declining and falls below the second threshold (which is less than the first threshold), the first channel is confirmed to be in a link risk state. If, at this point, it is further confirmed that the candidate channel score is higher than the current channel for multiple consecutive periods and the difference exceeds a threshold, the source node reports a handover decision request to the management node. After confirming the handover, the management node broadcasts a channel handover instruction, which includes at least the target channel identifier, handover effective time T0, handover sequence number, and recovery identifier.

[0118] Some embodiments of this application emphasize that handover should only occur when there is a benefit. That is, in some embodiments of this application, a candidate channel is not immediately switched simply because it is slightly better than the current channel; rather, a certain benefit threshold must be reached. For example, a handover action is only generated when the candidate channel score is higher than the current channel for two consecutive evaluation periods, and the difference exceeds a preset handover threshold. This is done to avoid channels oscillating between similar performance levels, ensuring overall network stability.

[0119] It should be noted that in some embodiments of this application, during the handover execution phase, the embodiments of this application do not employ the old channel disconnection and new channel reconnection method of related technologies to perform the handover process, but instead adopt a phased handover strategy prioritizing data continuity. To implement this strategy, the handover instruction in some embodiments of this application at least includes the target channel (i.e., the channel after the handover), the handover effective time T0 (if there is no unified time point, the time when each node receives the handover instruction varies, resulting in sequential frequency hopping, causing some nodes to be on the old channel and some nodes to have already switched to the new channel for a period of time, making communication impossible and causing network fragmentation), and the handover sequence number (identifying the uniqueness of this handover, used to distinguish different handover events, preventing nodes from mistakenly switching due to receiving expired handover instructions. The handover sequence number is the version identifier of the handover. Nodes can determine the age of the instruction based on the sequence number: only instructions with a sequence number greater than the previous handover are executed, and expired instructions are ignored). To avoid "ping-pong handover" and interference from historical commands, a recovery flag is used to indicate to the receiver that the data fragments transmitted this time belong to the incomplete service flow before the handover and need to be attached to the original service context, rather than being treated as new service flows. After the handover, if the sender retransmits the incomplete data fragments on the old channel, the receiver will treat these retransmitted fragments as data of new service flows if it does not distinguish them, resulting in chaotic reassembly, data duplication, or loss. The recovery flag is to ensure service continuity after the handover. The recovery flag is used to indicate to the receiver that this is the continuation data of an existing service flow, please use the original reassembly window to process it, thereby avoiding data interruption and repeated window opening caused by the handover. After receiving the handover command, the sender first freezes the delivery of new ordinary services on the old channel, and only allows the old channel to continue processing data fragments that have been sent but not yet acknowledged; newly generated service data is sent on the new channel first. For data that has not been acknowledged on the old channel, the system retains a short-term protection window, during which it continues to wait for acknowledgment from the old channel or performs limited retries. If acknowledgment is still not completed after the window expires, the relevant fragments are transferred to the new channel recovery queue, and the original service flow identifier, fragment sequence number (these two parameters are information stored when the fragment is placed in the recovery queue; the original service flow identifier must be retained, otherwise it will be unknown which flow the data belongs to during retransmission; the fragment sequence number must be retained, otherwise it will be unknown which fragment it is during retransmission; the recovery identifier needs to be retained to mark that this is data that needs to be retransmitted; when these fragments are taken out and sent, the switching sequence number can be obtained from the current handover context and added to the frame) and recovery flag are retained, and the new channel continues to complete selective retransmission. The receiving end does not immediately clear the original reassembly context during the handover process, but retains the service flow status and missing fragment record, and continues to complete the original service flow reassembly after the new channel recovery fragments arrive. In some embodiments of this application, for high-priority short messages of the control, alarm, and recovery confirmation types, limited dual-channel redundancy can be used for transmission during the transition phase; for ordinary service data, full dual transmission is not performed to reduce air interface overhead.By employing the above methods, data interruption, fragment loss, and packet retransmission can be minimized during channel handover, thereby improving the continuous transmission capability of low-altitude services in handover scenarios.

[0120] It should be noted that the limited dual-channel redundancy transmission in some embodiments of this application does not refer to the dual transmission of all data, but rather to limited dual transmission of only a small number of high-priority short messages such as control, alarm, and recovery confirmation messages within the handover transition window. The absence of full dual transmission of ordinary service data means that, in principle, ordinary services are not simultaneously occupied by both the old and new channels for repeated transmission. Instead, methods such as single transmission on the new channel, buffered continuation transmission, missing fragment retransmission, or frequency reduction transmission are preferred. Limited dual transmission is only performed for a small number of ordinary service fragments that meet specific conditions, such as data nearing the end of transmission, data with high recovery costs, or data about to be reassembled, when resources permit. This ensures uninterrupted critical services while avoiding the waste of wireless channel resources caused by full dual transmission of ordinary services.

[0121] like Figure 2 As shown, after receiving the channel switching instruction from the management node, the node continues to listen without switching. When the current time t is less than the switching time T0, it freezes the transmission of new ordinary service data on the current channel (i.e., the first channel) and continues to process the sent but unacknowledged fragments on the current channel (i.e., the first channel). It receives the acknowledgment message returned by the target node on the current channel and records the list of unacknowledged fragments (the service flow number and fragment sequence number of these fragments) at the source node. Afterwards, when the source node's acknowledgment time t reaches the switching time T0, all nodes synchronously switch to the target channel. After time t is greater than T0, the source node sends newly generated service data to the target node on the second channel (as the target signal). In some embodiments of this application, unacknowledged fragments are sent using the first channel within the protection window, and related fragment data is sent through the second channel after the protection window ends. Afterwards, the management node sends high-priority messages such as control and alarm messages through both the first and second channels.

[0122] It should be noted that in some embodiments of this application, the data frames do not use a uniform fixed-length frame, but are designed in layers according to message type, transmission stage, and link state. For example, in some embodiments of this application, management messages retain necessary fields to ensure network organization and state synchronization; service messages are compressed as much as possible after the context has been established; and fields are reconstructed during the relay and recovery stages, rather than being transmitted in their entirety. This ensures identification, reassembly, and continuation, while reducing unnecessary overhead in relay and weak link scenarios.

[0123] Some embodiments of this application categorize messages into three types. The first type is management messages, including network registration, heartbeat summaries, role negotiation, channel handover instructions, and relay candidate responses. These messages are few in number but crucial for network organization, therefore retaining relatively complete fields. The second type is service messages, including flight paths, weather, status feedback, and control services. These messages are sent frequently and in large quantities, making them a key focus for compression optimization. The third type is recovery messages, including missing fragment summaries, retransmission requests, and recovery confirmations. These messages carry only the information necessary for recovery and are kept as short as possible.

[0124] A basic data frame includes at least the following fields: frame header identifier, frame type, source node identifier, destination node identifier, service flow identifier, fragment sequence number, fragment control information, load area, and checksum area. Specifically, the frame header identifier is used for boundary identification; the frame type is used to distinguish between management, service, and recovery messages; the source and destination node identifiers are used to identify the communicating parties; the service flow identifier is used to associate multiple fragments of the same data flow; the fragment sequence number is used to identify the current fragment position; the fragment control information is used to indicate the status of the first fragment, last fragment, retransmitted fragment, and recovered fragment; the load area carries the actual service data; and the checksum area is used to verify integrity.

[0125] This application defines three frame organization methods in its embodiments. The first is a complete frame, used during the network entry phase, initial relationship establishment phase, critical control phase, and when the context has not yet been established. In this case, the complete source node identifier, target node identifier, and service flow identifier are retained to facilitate rapid establishment of mapping relationships. The second is a compressed frame, used during the normal stable transmission phase, where session relationships and service flow contexts have been established between nodes. In this case, the complete node identifier can be replaced with a logical short address, session identifier, or direction identifier to reduce header length. The third is a relay reconfiguration frame, used during relay forwarding, path switching, and transmission recovery phases. In this case, the information necessary for continuous service flow is retained, while redundant fields established through the context are compressed, and necessary relay or recovery markers are added.

[0126] Regarding field reorganization, the embodiments of this application have adjusted the original organization of "device ID, serial number, packet sequence number, and total number of packets". The device ID is still retained, but it is not required to be carried in full in every hop and every frame. When a node communicates for the first time, joins the network, or when the relationship has not been established, the source node identifier and the target node identifier are in full form; after the network has completed address allocation and the session has been established, a logical short address can be used instead of the full identifier. The serial number and packet sequence number are no longer used separately, but are uniformly organized into a structure of "service flow identifier and fragment sequence number". The service flow identifier is responsible for distinguishing different service packets or different transmission tasks, and the fragment sequence number is responsible for identifying the specific position in the service flow, which is more convenient for subsequent continuation and reorganization. As for the total number of packets, this invention does not require that it be explicitly carried in all scenarios. In short packet or stable scenarios, the last fragment can be identified by the end marker; in large packet, recovery patch, or high reliability scenarios, the total fragment information can be carried to facilitate the receiver to quickly determine the missing range.

[0127] To ensure correct reassembly after compression, embodiments of this application establish lightweight contexts at the sending end, receiving end, and relay nodes. The sending end records the current service flow identifier, target node, range of sent fragments, and most recent acknowledgment status; the receiving end records the reassembly window and missing fragment location of the current service flow; and the relay nodes only maintain necessary mapping relationships, such as which source node a service flow originates from, which target node it is destined for, and which path it is currently following. The emphasis here is on lightweightness, and it does not require maintaining large-scale routing tables or complete packet history.

[0128] Data frame reconstruction during the relay phase is a key feature of some embodiments of this application. Traditional relays often forward the entire frame as is, which, while simple, incurs significant air interface overhead under multi-level relay and weak link conditions. Some embodiments of this application retain only necessary fields during the relay phase, such as frame type, current sender short address, destination direction identifier, service flow identifier, fragment sequence number, fragment control information, load area, and checksum area. If the complete source node identifier and destination node identifier have already been established through context mapping, they are no longer repeatedly transmitted frame by frame. If necessary, only a lightweight relay flag or path flag is added to help the receiver determine whether the frame originates from a relay path and whether it belongs to a recovery transmission after handover.

[0129] During channel handover, relay handover, or short-term link loss recovery phases, some embodiments of this application add a recovery identifier to data frames. The recovery identifier indicates that the frame is not a completely new service flow, but rather a retransmission fragment of the original service flow after the handover. Upon seeing the recovery identifier, the receiving end directly attaches it to the original service flow context for reassembly, without mistaking it for a new independent service flow. If the frame is a selective retransmission, the fragmentation control information can also indicate that it is a missing fragment retransmission, thus allowing the receiving end to replace only the corresponding missing fragment without clearing the entire reassembly buffer.

[0130] In other words, some embodiments of this application do not uniformly compress all messages, but reconstruct fields and message bodies according to low-altitude service scenarios. Management messages retain the fields required for management, service messages are compressed during the stable phase, and relay and recovery messages are reconstructed according to the current phase. This ensures network control and service continuity while avoiding all data frames carrying complete redundant headers for extended periods, which helps reduce air interface occupancy and improve transmission efficiency in relay, weak link, and handover scenarios. Some embodiments of this application provide four frame structures: complete frame, compressed frame, relay reconstruction basic frame, and relay reconstruction recovery frame. The improvements for each frame structure are as follows: the complete frame retains the complete source / target identifier and optional total fragmentation information for the initial relationship establishment and control phases; the compressed frame uses a short address to replace the complete node identifier and omits the total fragmentation information to reduce header overhead; the relay reconstruction basic frame replaces the original source / target fields with the current sender's short address and target direction identifier during the relay phase to adapt to multi-hop forwarding scenarios; the relay reconstruction recovery frame further adds a recovery identifier to the fragmentation control information based on the relay reconstruction basic frame for path switching or recovery retransmission scenarios.

[0131] It should be noted that the data resumption and multi-service collaborative transmission methods in some embodiments of this application mainly address issues such as service interruption, high overhead of data retransmission, and mutual interference among multiple services caused by link fluctuations, channel switching, relay rerouting, or short-term node disconnection in low-altitude scenarios. For example, in some embodiments of this application, the sending end, receiving end, and relay node can flexibly restore data when the link is unstable, ensuring service continuity and prioritizing the transmission latency of important data, while effectively managing module memory and cache space.

[0132] For example, in some embodiments of this application, the sending end establishes a state for each service flow at the start of the service flow, recording the service flow identifier, total number of fragments, range of sent fragments, range of acknowledged fragments, fragments to be retransmitted, current channel, path information, etc. This state is retained only within a limited window and is managed hierarchically according to service priority and timeliness. High-priority services (such as control commands, alarm information, and recovery requests) occupy less buffer space, but their timely transmission is crucial; therefore, for these services, ensuring their complete buffer and state synchronization is prioritized. Ordinary services only retain the most recent state information to avoid buffer overflow and ensure reasonable memory allocation.

[0133] It should be noted that the limited window in the above examples refers to the fact that in some embodiments of this application, the sending end does not permanently store all historical fragments and all states of each service flow, but only retains a limited range of state information that is still needed for current recovery, retransmission, or continuous transmission. This limited range can be at least one of a sequence number window, a time window, or a cache quota window. Data states outside the window that are no longer involved in subsequent confirmation, retransmission, or recovery can be deleted to release cache and state record resources. For example, in some embodiments of this application, limited window retention can be implemented in at least the following three ways: sliding window retention based on fragment sequence number, where the sending end maintains a current transmission window for each service flow, retaining only the state of unconfirmed fragments within the window; upon receiving confirmation, the leading edge of the window slides forward, and confirmed states outside the window are deleted. Time-based limited retention, where the sending end records the most recent update time for each service flow state item, retaining only unconfirmed or pending recovery states within a preset retention period; states that exceed the retention period and are no longer involved in recovery processing are deleted. Based on limited retention using cache quotas and priorities, the sender sets different status retention quotas for services of different priorities. When cache pressure increases, status items in low-priority services that are out of window range or whose timeliness has been reduced are deleted first. The above three methods can be used individually or in combination.

[0134] The receiving end also faces limitations in cache space, therefore, some embodiments of this application have optimized its reassembly mechanism. For example, in some embodiments of this application, the receiving end uses a window caching method to organize the data stream according to the fragment sequence number and the service flow identifier, and caches some fragments in memory. If some fragments have not arrived for a long time, the receiving end decides whether to continue waiting, initiate a resend request, or terminate the service flow based on the cache usage. If the receiving end cache is full, it discards those service flow fragments that are no longer important (e.g., these data include: ordinary periodic service data that has obviously lost its timeliness; service flow fragments that have been missing for a long time and have not been replenished within a preset waiting time; old fragments that have been determined to be unable to continue to complete effective reassembly; old fragment records that have arrived repeatedly or have been replaced by updated status) and those that have not arrived, and prioritizes retaining the fragments that are currently needed for reassembly.

[0135] During the receiving process, the receiving end periodically evaluates its cache usage and decides whether to discard some less important data or continue caching fragments awaiting replenishment if sufficient space is available. Through this cache management mechanism, the system can efficiently manage data streams of different types of services with limited memory resources, avoiding memory overload.

[0136] When link switching, relay switching, or short-term link loss occurs, the resume transmission recovery process begins. After the link is restored, the receiving end returns a missing fragment digest to the sending end. This digest only contains the service flow number and the range of missing fragments; it does not send the complete data content. Upon receiving the missing fragment digest, the sending end only retransmits the missing fragments, rather than retransmitting the entire data packet. If the sending end finds that a service flow is no longer fully cached, it does not use a uniform recovery method for all services. Instead, based on the service type, service priority, current cache requirements, and timeliness constraints, it determines whether to use at least one recovery strategy: full retransmission, critical fragment retransmission, missing fragment resumption, or direct abandonment of the service flow. This avoids unnecessary retransmissions and reduces transmission overhead during the recovery process.

[0137] To adapt to different business scenarios, some embodiments of this application design a family of recovery strategies. For high-priority real-time control services, the recovery strategy emphasizes restoring subsequent critical data first, then filling in historical missing fragments, to avoid old data slowing down new instructions; for continuous monitoring services, the recovery strategy emphasizes maintaining the integrity of the service flow as much as possible, prioritizing filling in missing fragments before continuing regular transmission; for ordinary status reporting services, a simplified recovery method can be adopted, that is, only retaining the most recent critical status, without pursuing the complete recovery of all historical fragments. The purpose of this is to adjust the recovery depth and recovery order according to the service type and network environment, ensuring that important data can be transmitted first and avoiding meaningless historical data consuming bandwidth.

[0138] In some embodiments of this application, in multi-service concurrent transmission scenarios, the sending end maintains a transmission queue divided by priority. High-priority services occupy the transmission window first, while ordinary services are appropriately delayed. If the link enters a risky state, the system prioritizes the transmission of high-priority control and alarm services, while the transmission of ordinary status data can be reduced in frequency or merged. This strategy ensures that critical services can be completed first, while low-priority services are adjusted appropriately according to link conditions.

[0139] During the recovery process, some embodiments of this application require the receiving end to retain the reassembly context, ensuring that the context of the current service flow is not lost due to relay path switching or channel changes. For recovered fragments after switching, the receiving end determines whether they belong to the original service flow through the recovery identifier and directly attaches them to the original reassembly window, avoiding duplicate window opening or erroneous reassembly. In this way, the system can seamlessly connect service flows during relay switching, ensuring communication stability in low-altitude environments.

[0140] Meanwhile, to prevent the recovery process from consuming too many link resources, some embodiments of this application have designed recovery termination and degradation rules. When a service flow cannot be fully recovered after a set number of recovery attempts and has a low service priority, the system will stop continuing the recovery and only retain the most recent valid state; when the recovery process affects high-priority services, the system will automatically reduce the transmission priority of that service to avoid the recovery process becoming a bottleneck for the entire system.

[0141] Through the methods described above, some embodiments of this application achieve rapid recovery of service flows while ensuring the latency of critical services in the event of link fluctuations in low-altitude environments, thus avoiding high transmission overhead caused by the recovery process. The overall solution, based on existing hardware capabilities and combined with intelligent algorithms and protocol design, makes multi-service transmission in low-altitude scenarios more stable, reliable, and timely.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0143] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0144] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0145] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0146] 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.

[0147] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A low-altitude relay and channel switching method based on starburst technology, characterized in that, The wireless communication method for the low-altitude starburst includes: If it is confirmed that the direct link between the target node and the target node cannot meet the service transmission requirements, a relay discovery request is sent to the neighboring area. Receive a relay response returned by at least one node, wherein the relay response carries the status information of the corresponding node, the status information including at least one of the following: the link quality from the candidate node to the target node, the load status of the candidate node, the buffer usage of the candidate node, the forwarding success rate of the candidate node, the link stability within a short time window, and whether it is allowed to assume relay responsibilities. Based on the status information, the relay performance of the corresponding node is evaluated, and the target relay node is determined from the at least one node based on the evaluation results.

2. The low-altitude starburst wireless communication method of claim 1, wherein, The wireless communication method further includes; The system receives status update information periodically sent by the target relay node, wherein the status update information is used to indicate the forwarding capability or operating status of the target relay node.

3. The low-altitude starburst wireless communication method of claim 2, wherein, The relay response is obtained by the relay response sending node using a random backoff method.

4. The low-altitude starburst wireless communication method according to any one of claims 1-3, wherein, The step of evaluating the relay performance of the corresponding node based on the status information and determining the target relay node from the at least one node based on the evaluation result includes: Based on the status information, nodes that do not meet the preset conditions are removed to obtain the first candidate node group. The preset conditions include at least one of the following: the link quality is lower than the minimum availability threshold, the cache usage exceeds the upper limit threshold, the load status exceeds the preset value, or the node is not allowed to assume the relay role. The first candidate node group is prioritized according to link performance to obtain a relay candidate node queue, wherein the link performance is characterized at least by link quality and link stability within a short time window. Select the target relay node from the relay candidate node queue.

5. The wireless communication method for low-altitude starburst as described in claim 3, characterized in that, The step of selecting the target relay node from the relay candidate node queue includes: Select a primary relay node and at least one backup relay node from the relay candidate node queue. The primary relay node is used for this communication, and the backup relay node is used as the new primary relay node when the status update information of the primary relay node meets the path switching conditions.

6. The low-altitude starburst wireless communication method of claim 4, wherein, The wireless communication method further includes: It is confirmed that the overall path availability is better than the current path after adding the next level relay. The overall path availability is evaluated using at least one of the following parameters: latency, air interface occupancy, state maintenance complexity, and recovery cost. Extend to the next relay layer, and the total number of relay layers is constrained by the maximum number of hops and path cost.

7. The wireless communication method for low-altitude starburst according to claim 4, characterized in that, The step of prioritizing the first candidate node group according to link performance to obtain a relay candidate node queue includes: Determine the service type of the data to be transmitted; The sorting principle is selected according to the service type, and the nodes in the first candidate node group are sorted according to the sorting principle to obtain the relay candidate node queue. The sorting principle includes: for the first type of service, the nodes are sorted according to the link quality and the link stability within a short time window; for the second priority service, the nodes are sorted according to the load level and the cache utilization rate.

8. The wireless communication method for low-altitude starburst according to claim 1, characterized in that, The method further includes: The status of the current communication channel is evaluated based on the link quality parameters of the current communication channel; Based on the stated status, determine whether to trigger a target search and channel switching.

9. The wireless communication method for low-altitude starburst according to claim 8, characterized in that, The step of evaluating the state of the current communication channel based on the link quality parameters of the current communication channel includes: The link quality parameters of the current communication channel are obtained over multiple consecutive sampling periods, wherein the link quality parameters include at least one of the following: current signal strength, successful transmission / reception ratio, number of retransmissions, channel busy / idle status, and changes in service buffer. Calculate the corresponding comprehensive link quality score based on the link quality parameters for each sampling period; The link quality change trend is determined based on the comprehensive link quality score corresponding to the multiple consecutive sampling periods, and the current state of the communication channel is determined based on the link quality change trend.

10. The wireless communication method for low-altitude starburst as described in claim 9, characterized in that, The step of determining the link quality change trend based on the comprehensive link quality score corresponding to the multiple consecutive sampling periods, and determining the current communication channel state based on the link quality change trend, includes: If it is confirmed that the overall link quality score continues to decline and the overall link quality score is below the first threshold for multiple consecutive sampling periods, then the current communication channel is set to the link attention state. The step of determining whether to trigger a target search channel switch based on the current communication channel status includes: If the current communication channel is confirmed to be in the link interest state, then candidate channel evaluation is initiated to obtain the target switching channel.

11. The wireless communication method for low-altitude starburst as described in claim 10, characterized in that, The wireless communication method further includes: When the overall link quality score of the target switching channel is higher than that of the current communication channel for multiple consecutive evaluation cycles, and the difference exceeds a preset switching threshold, a channel switching command is generated.

12. The wireless communication method for low-altitude starburst as described in claim 11, characterized in that, The method further includes: If the overall link quality score of the current communication channel under the link concern state further declines and continuously falls below the second threshold, then the channel to be evaluated is confirmed to be in a risk state. If it is confirmed that the channel to be evaluated is in the risky state, a channel switching command is generated.

13. The wireless communication method for low-altitude starburst according to any one of claims 11-12, characterized in that, The channel switching instruction includes at least the target channel identifier, the switching effective time, the switching sequence number, and the recovery identifier; The wireless communication method further includes: Before the handover effective time arrives, continue processing the data fragments that have been sent but not acknowledged on the current communication channel, and freeze the delivery of new ordinary service data on the channel to be evaluated; After the handover effective time arrives, the newly generated service data is sent on the target handover channel; the data fragments that have not been confirmed are transferred to the recovery queue of the target handover channel, and the original service flow identifier, fragment sequence number and recovery identifier are retained, and the target handover channel continues to perform selective retransmission.

14. The wireless communication method for low-altitude starburst according to any one of claims 11-12, characterized in that, The method further includes: For high-priority short messages of control, alarm, and recovery confirmation types, during the transition phase before and after the handover effective time, dual-channel redundant transmission is performed using the channel to be evaluated and the currently switched channel.

15. A communication node, characterized in that, include: Memory, used to store instructions; A processor is configured to execute the instructions, causing the communication node to perform the low-altitude starburst wireless communication method according to any one of claims 1 to 14.

Images