A hardware time anchor point-based low-power consumption time division communication synchronization method for unmanned aerial vehicles

Abstract

The application discloses a low-power time division communication synchronization method for unmanned aerial vehicles based on hardware time anchor points. The master node periodically broadcasts beacon frames carrying versioned time slot configuration information; the slave node acquires a hardware receiving timestamp when receiving the beacon and establishes an air time reference point, analyzes the version information and performs version consistency processing, and determines the updated version as the current effective version; the slave node generates an absolute time triggered time division transceiving plan based on the air time reference point and the current effective version, executes sending and receiving windowing according to the plan, and enters a low-power state during non-transceiving time slots; when continuous missed reception reaches a threshold, the slave node enters a degenerate resynchronization mode, expands the receiving window or continuously receives to recapture the beacon, and regenerates the time division transceiving plan based on the new air time reference point and the recovered time slot configuration after recapturing. The method takes into account the deterministic delay, low power consumption and link robustness.

Description

Technical Field

[0001] This application relates to the field of UAV communication links and low-power wireless network technology, specifically to a UAV low-power time-division communication synchronization method based on hardware time anchors. Background Technology

[0002] With the development of applications such as low-altitude logistics, inspection and patrol, and emergency support, UAV communication links need to simultaneously meet the requirements of low latency, high reliability, and low power consumption under conditions of high movement speed, significant multipath obstruction, complex interference, and limited onboard power supply. Existing solutions, even those employing beacon synchronization, fixed TDMA, or intermittent reception, are mostly spliced ​​together as independent functions: on the one hand, some solutions still rely on software interrupts or software timestamps to establish synchronization references, which are easily affected by processor scheduling jitter and driver delays, forcing a wider reception window and increasing unnecessary reception power consumption; on the other hand, while some solutions can broadcast time slot information, they lack version number, base version matching, and consistency verification mechanisms. When nodes join, leave the network, or their priorities change, inconsistencies in the master and slave sides' understanding of time slot configurations can easily arise, leading to time slot conflicts or communication failures.

[0003] Furthermore, recovery after loss of synchronization typically relies on prolonged continuous monitoring or re-entry into the network, which is costly, especially in high-speed UAV movement and complex electromagnetic environments where short-term beacon frame drops are unavoidable. Existing solutions often require trade-offs between power consumption and recovery speed. Therefore, the real challenge in UAV communication links is not simply a matter of synchronization accuracy, time slot allocation, or power consumption, but rather how to couple a high-precision time base, dynamic time slot consistency, and rapid recovery after loss of synchronization. This would enable the system to perform time-division multiplexing based on a unified time slot configuration, even under dynamic node changes and channel fluctuations, and to quickly recover to a low-power deterministic operating state using a new airborne time anchor after a missed reception or loss of synchronization. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a low-power time-division communication synchronization method for unmanned aerial vehicles based on hardware time anchors.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] This application provides a low-power time-division communication synchronization method for unmanned aerial vehicles (UAVs) based on hardware time anchors, including:

[0007] The master node periodically broadcasts beacon frames, which carry versioned time slot configuration information for time-division communication. The versioned time slot configuration information includes at least superframe parameters, the mapping relationship between nodes and time slots, version identifiers, and update verification information.

[0008] When a node receives a beacon frame, it obtains a hardware reception timestamp and determines an air time reference point based on the hardware reception timestamp.

[0009] The node performs consistency processing based on the version identifier in the beacon frame and the local version: if they match, the local version is taken as the current valid version; if they do not match, an incremental update or a full update is performed according to the update type in the update verification information, and the updated version is determined as the current valid version after the verification passes.

[0010] Based on the air time reference point and the time slot configuration corresponding to the current valid version, the node generates an absolute time triggering plan for sending and receiving time slots in the current or next superframe.

[0011] The master node and slave node perform the sending and receiving windowing operations according to the absolute time triggering plan, and the slave node enters a low-power state during non-receiving windows and non-transmitting time slots.

[0012] The node detects beacon loss and enters a degradation resynchronization mode when the continuous loss reaches a preset threshold, in order to recapture the beacon by expanding the receiving window or by continuously receiving data.

[0013] After recaptures the beacon, the slave node reconstructs the air time reference point based on the new hardware receive timestamp, binds the reconstructed air time reference point to the restored current valid version time slot configuration, regenerates the absolute time triggering plan based on the binding result, and then exits the degradation resynchronization mode.

[0014] Optionally, the hardware reception timestamp is output by the wireless radio frequency transceiver module when the beacon frame is successfully received; when the hardware reception timestamp corresponds to a predetermined reference point after the start of the beacon preamble, the slave node adjusts the time offset according to a pre-calibrated fixed time offset. Hardware receive timestamp Converted to the air time reference point of the beacon preamble start The conversion formula is:

[0015]

[0016] in, This is a fixed time offset between the start time of the beacon preamble and the predetermined reference point. The sequence number for successfully received beacon.

[0017] Optionally, the node predicts the expected time of arrival of the target frame in the air based on the air time reference point. The receive start time is determined according to the following formula. and receive window length :

[0018]

[0019]

[0020] in, The duration required from receiving a command to the stabilization of radio frequency reception. To receive advance allowance, To receive timeout margin, The timer count value corresponds to the duration of the preamble and the synchronization word; when the actual arrival time of the target frame falls within the interval [ When the synchronization error estimate or the consecutive missed detection count increases, the narrow window capture is considered successful; when the synchronization error estimate or the consecutive missed detection count increases, the window is increased. or To widen the receiving window.

[0021] Optionally, for the transmission slot, the slave node determines the expected air transmission time. And the fixed offset between the start of the command transmission and the entry of the first bit of the preamble into the air channel. The absolute trigger time for sending the command is determined according to the following formula. :

[0022]

[0023] This ensures that the air start time for transmitting the preamble falls within the allocated transmission time slot.

[0024] Optionally, the update of the time slot configuration includes incremental update and full update; the master node increments the version identifier when the node composition, service priority, link quality or scheduling policy of the network changes; before performing an incremental update, the slave node first verifies that the base version number carried in the beacon is consistent with the local current version number, and after applying the incremental update, it verifies the updated time slot configuration according to the consistency verification field in the update verification information; if the base version number is inconsistent or the verification fails, the slave node rolls back to the full update process, that is, receives the complete time slot configuration and replaces the local configuration.

[0025] Optionally, the degradation resynchronization mode includes two phases executed sequentially:

[0026] The first stage is the expanded reception window stage, in which the slave node waits for the next beacon at the predicted beacon arrival time using a reception window larger than that in the normal narrow window synchronization mode;

[0027] The second stage is the continuous reception stage. When the number of beacons that are continuously missed during the expanded reception window stage reaches the second preset threshold, the node switches to the radio frequency continuous reception state to improve the probability of beacon re-acquisition.

[0028] Optionally, after the node recaptures the beacon, it first resets the missed reception counter to zero, then binds the newly acquired air time reference point to the currently recovered time slot configuration version as a valid synchronization reference, and recalculates the absolute transmission and reception times of subsequent beacons and service time slots based on this valid synchronization reference.

[0029] Optionally, let the first The airtime reference point established after the first successful beacon reception is The corresponding effective time slot configuration version is The service time slot index corresponding to the node identifier ID is ,in, According to version The time slot configuration information maps the node identifier ID to the corresponding service time slot index; then the airborne start time of the service time slot is determined. Calculated by the following formula:

[0030]

[0031] in, For version The corresponding business segment starting offset, For version The corresponding single time slot length, For version The corresponding protection interval length.

[0032] Optionally, set the effective superframe number for version switching to be... Then the current superframe number Corresponding valid version Satisfy: When Retrieve old version ,when And the new version is used when the consistency check passes. Predicted air arrival time of the next superframe beacon Calculate according to the following formula:

[0033]

[0034] in, For the first The airtime reference point of the superframe beacon. This is the superframe period length corresponding to the effective version; after the version is updated and the verification is passed, the slave node recalculates the expected airtime of the beacon and service slots in the next superframe based on the new version.

[0035] Optionally, the preset threshold is set or dynamically adjusted based on one or more of the following factors: local clock drift estimate, beacon miss count in the most recent superframes, link quality indicators, motion status of slave nodes, and service priority of slave nodes.

[0036] Compared with the prior art, this application has the following beneficial effects:

[0037] This invention proposes a low-power time-division communication synchronization method for unmanned aerial vehicles (UAVs) based on hardware time anchors. It integrates the use of hardware received timestamps to establish an airborne time reference, consistent updates and verification of versioned time slot configurations, and a degradation resynchronization mechanism after consecutive missed receptions into a closed loop. This solves the technical problems in the background technology, such as low synchronization accuracy due to software jitter, inconsistency between master and slave perception during dynamic updates of time slot configurations, and long recovery time and high power consumption after loss of synchronization. Hardware time anchors eliminate software scheduling jitter, enabling slave nodes to maintain synchronization with an extremely narrow receiving window, thereby reducing power consumption. Versioned time slot configurations, combined with incremental / full updates and consistency verification, ensure that both master and slave nodes always use the same time slot allocation when nodes change dynamically, avoiding time slot conflicts. When consecutive missed receptions reach a threshold, the slave node first expands its window and continues receiving, and immediately binds the new airborne time reference to the currently valid version after reacquisition. It can quickly return to a low-power deterministic working state without re-entering the network, thus simultaneously improving synchronization accuracy, dynamic scheduling reliability, link robustness, and node endurance. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of a low-power time-division communication synchronization method for unmanned aerial vehicles based on hardware time anchors, provided in an embodiment of this application.

[0039] Figure 2 This is a schematic diagram of the process by which the master node generates or updates time slot scheduling information in an embodiment of this application.

[0040] Figure 3 This is a schematic diagram of the synchronization and resynchronization process of the slave node in the embodiments of this application.

[0041] Figure 4 This is a schematic diagram of the process for restoring and verifying the version of the timeslot table from the slave node in this embodiment of the application. Detailed Implementation

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

[0043] Furthermore, in this invention, an element referred to as fixed to or disposed on another element may be directly disposed on the other element, or there may be an intermediate element. When an element is considered to be connected to another element, it may be directly connected to the other element, or there may be an intermediate element present simultaneously. The terms vertical, horizontal, left, right, and similar expressions used herein are for illustrative purposes only and do not represent the only possible implementation.

[0044] To make the objectives, technical solutions, and beneficial effects of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and specific embodiments. This embodiment is applicable to a master-slave communication scenario in an unmanned aerial vehicle (UAV) communication link. The master node can be located at a ground control terminal, a ground relay terminal, or other node with unified scheduling capabilities, while the slave nodes can be located on the UAV platform. The master node maintains superframe parameters and a time slot table, and periodically broadcasts beacon frames carrying the time slot table and version information. The slave nodes receive the beacon frames, establish an airborne time reference point, determine their corresponding time slot, and perform sending or receiving operations at the corresponding time, thereby achieving master-slave multi-node communication and synchronization. Both the master and slave nodes can be implemented using a wireless radio frequency transceiver module and a control processing module. The control processing module uses a state machine approach to execute processes such as acquisition, synchronization maintenance, time-division multiplexing, out-of-synchronization recovery, and version updates.

[0045] The following combination Figures 1 to 4 The technical solution of this application will be described in detail.

[0046] like Figure 1 As shown, this application provides a low-power time-division communication synchronization method for unmanned aerial vehicles (UAVs) based on hardware time anchors, including:

[0047] S1. The master node periodically broadcasts beacon frames, which carry versioned time slot configuration information for time-division communication. The versioned time slot configuration information includes at least superframe parameters, the mapping relationship between nodes and time slots, version identifiers, and update verification information.

[0048] The master node maintains versioned timeslot configuration information for time-division communication. This configuration information includes at least superframe period parameters, the mapping relationship between node identifiers and timeslot indexes, timeslot table version number, update type, base version number, and consistency check field. Within each superframe period, the master node generates and broadcasts a beacon frame carrying the above information. Figure 2 The process of the master node generating or updating time slot scheduling information and broadcasting beacons is shown.

[0049] S2. When receiving the beacon frame from the node, obtain the hardware reception timestamp and determine the air time reference point based on the hardware reception timestamp;

[0050] When a slave node successfully receives a beacon frame, its radio frequency transceiver module outputs a hardware receive timestamp. The slave node then converts this hardware receive timestamp into an airtime reference point for the start of the beacon preamble. Subsequently, it parses the beacon payload to obtain information such as the superframe period, mapping relationship, version number, update type, and base version number.

[0051] S3. The node performs consistency processing between the version identifier in the beacon frame and the local version: if they match, the local version is taken as the current valid version; if they do not match, an incremental update or a full update is performed according to the update type in the update verification information, and the updated version is determined as the current valid version after the verification is passed.

[0052] The node compares the version number in the beacon with the locally stored version number. If they match, the local version is adopted as the current valid version. If they do not match, an incremental update or a full update is performed depending on the update type. For incremental updates, the base version number in the beacon must match the local version number, and the update must pass a consistency check after application. Otherwise, a full update is initiated. After the update is complete, the updated version is determined as the current valid version. Figure 4 The recovery and consistency verification process for this version is shown.

[0053] S4. The slave node generates an absolute time triggering plan for sending and receiving time slots in the current or next superframe based on the air time reference point and the time slot configuration corresponding to the current valid version.

[0054] Based on the air time reference point and the time slot parameters (time slot length, guard interval, service segment start offset, etc.) corresponding to the current valid version, the node determines the corresponding transmission time slot and reception time slot in the mapping relationship in combination with its own node identifier, calculates the expected air start time and the corresponding absolute trigger time of each time slot, and generates a time-division multiplexing plan.

[0055] S5. The master node and the slave node perform the sending and receiving windowing operations according to the absolute time triggering plan, and the slave node enters a low-power state during non-receiving windows and non-transmitting time slots.

[0056] The master and slave nodes execute transmit commands or open receive windows at the scheduled absolute trigger time. Slave nodes enter sleep or low-power states outside of receive windows and transmit time slots to reduce the receive duty cycle.

[0057] S6. Detect beacon missed reception from the node. When the continuous missed reception reaches a preset threshold, enter the degradation resynchronization mode to recapture the beacon by expanding the reception window or by continuous reception.

[0058] The number of missed beacon receptions is counted from the node. When the number of consecutive missed receptions reaches a preset threshold, a degraded resynchronization mode is entered. First, the receiving window is expanded, and if necessary, continuous receiving is switched to recapture the beacon. Figure 3 The synchronization maintenance and resynchronization process is illustrated.

[0059] S7. After the node recaptures the beacon, it reconstructs the air time reference point based on the new hardware receive timestamp, binds the reconstructed air time reference point to the restored current valid version time slot configuration, and regenerates the absolute time triggering plan based on the binding result, and then exits the degradation resynchronization mode.

[0060] After the node recaptures the beacon, it reconstructs the airtime reference point based on the new hardware receive timestamp, binds the new reference point to the restored current valid version of the time slot configuration, regenerates the time-division transceiver plan, and then exits the degradation resynchronization mode and returns to the low-power operating state.

[0061] In one specific implementation, the hardware receive timestamp is output by the wireless radio frequency transceiver module when the beacon frame is successfully received; when the hardware receive timestamp corresponds to a predetermined reference point after the start of the beacon preamble, the slave node adjusts the timing according to a pre-calibrated fixed time offset. Hardware receive timestamp Converted to the air time reference point of the beacon preamble start The conversion formula is:

[0062]

[0063] in, This is a fixed time offset between the start time of the beacon preamble and the predetermined reference point. The sequence number for successfully received beacon.

[0064] In this embodiment, the hardware receive timestamp output by the wireless RF transceiver module when it successfully receives the beacon frame typically corresponds to a predetermined reference point after the preamble start (such as the preamble detection completion time or the synchronization word matching time). To obtain the true time when the first bit of the beacon preamble arrives in the air, the slave node obtains a fixed time offset in advance through laboratory calibration. Let the hardware reception timestamp obtained when the beacon is successfully received for the kth time be denoted as . Then the time reference point in the air Calculate using the following formula:

[0065]

[0066] This formula compensates for hardware timestamps moving forward. Thus, the in-flight time of the preamble's start is obtained. The calibration can be accomplished by sending a test signal with a known delay or by using loopback measurement, and its value can be reused in all subsequent nodes once calibrated.

[0067] In one specific implementation, the node predicts the expected time of arrival of the target frame in the air based on the air time reference point. The receive start time is determined according to the following formula. and receive window length :

[0068]

[0069]

[0070] in, The duration required from receiving a command to the stabilization of radio frequency reception. To receive advance allowance, To receive timeout margin, The timer count value corresponds to the duration of the preamble and the synchronization word; when the actual arrival time of the target frame falls within the interval [ When the synchronization error estimate or the consecutive missed detection count increases, the narrow window capture is considered successful; when the synchronization error estimate or the consecutive missed detection count increases, the window is increased. or To widen the receiving window.

[0071] In this embodiment, the slave node predicts the expected time of arrival of the target frame (e.g., the next beacon or service slot) based on the air time reference point. ; Receive startup time Calculate using the following formula:

[0072]

[0073] in, This is the time required from when the processor issues a receive command to when the RF front-end completes startup and is able to stably receive signals (including phase-locked loop stabilization, AGC establishment, etc.). This value is a fixed hardware parameter. To provide a lead time margin to cover uncertainties in synchronization errors, clock drift, and propagation delay, the initial value can be set according to the system clock accuracy.

[0074] Receive window length Calculate using the following formula:

[0075]

[0076] in, Let R be the timer count value corresponding to the duration of the preamble and the synchronization word; let the symbol rate be R. s The number of preamble symbols is N preThe number of synchronization characters is N sync ,but =(N pre +N sync )·(1 / R s ). This provides a receive timeout margin to handle minor frame start offsets caused by channel multipath or transient interference.

[0077] When the actual arrival time of the target frame falls within the interval [ + , + When the synchronization error estimate (e.g., the offset calculated based on the preamble correlation peak position) increases, or the consecutive missed reception count increases, the slave node actively raises the alert level. or The value of is adjusted to widen the receiving window and reduce the probability of missed reception due to channel degradation; this adaptive adjustment can be made dynamically based on the measurement results after each acquisition.

[0078] In one specific implementation, for a transmission slot, the slave node determines the transmission time based on the expected airborne transmission time. And the fixed offset between the start of the command transmission and the entry of the first bit of the preamble into the air channel. The absolute trigger time for sending the command is determined according to the following formula. :

[0079]

[0080] This ensures that the air start time for transmitting the preamble falls within the allocated transmission time slot.

[0081] In this embodiment, for the transmission time slot allocated to this node, the slave node first calculates the expected air start time of the transmission time slot based on the air time reference point and the time slot parameters of the current valid version. Because there is a fixed hardware delay (including baseband modulation, power amplifier rising edge, RF link propagation, etc.) between the start of command transmission and the actual entry of the first bit of the preamble into the air channel, this delay is denoted as... This is obtained through pre-calibration. Therefore, the absolute trigger time for sending the command is: From the node at Commands are sent at all times, after... After a fixed delay, the first bit of the preamble falls exactly on It enters the air channel at all times to ensure that the transmitted signal falls strictly within the allocated time slot and avoids overlapping with the transmit and receive windows of other nodes.

[0082] In one specific implementation, the update of the time slot configuration includes incremental update and full update; the master node increments the version identifier when the network node composition, service priority, link quality or scheduling policy changes; before performing incremental update, the slave node first verifies that the base version number carried in the beacon is consistent with the local current version number, and after applying incremental update, verifies the updated time slot configuration according to the consistency verification field in the update verification information; if the base version number is inconsistent or the verification fails, the slave node rolls back to the full update process, that is, receives the complete time slot configuration and replaces the local configuration.

[0083] In this embodiment, when the network status changes (such as a new node joining, a node leaving the network, service priority adjustment, link quality change, or scheduling policy change), the master node regenerates the time slot allocation and increments the version number of the time slot configuration. For scenarios with minor changes, the master node adopts an incremental update method: the beacon frame only carries the identifier of the changed node and its corresponding new time slot index, the base version number (i.e., the old version number on which this update is based), and a consistency check field (such as CRC32). After receiving the incremental update beacon, the slave node first verifies whether the base version number in the beacon is consistent with the local current version number. If they are consistent, the listed changes are applied to the local time slot configuration, and then the consistency check value is recalculated for the updated complete time slot configuration and compared with the check field carried by the beacon. If the check passes, the update is confirmed to be successful, and the local version number is updated to the new version number in the beacon. If the base version number is inconsistent or verification fails, the slave node determines that the incremental update is invalid and immediately enters the full update process: it receives the complete timeslot configuration broadcast by the master node (or waits for the full beacon in the next superframe), replaces the local configuration with the received complete configuration, and performs verification again. The full update ensures that the correct configuration can still be restored when the incremental update fails.

[0084] In one specific implementation, the degradation resynchronization mode includes two phases executed sequentially:

[0085] The first stage is the expanded reception window stage, in which the slave node waits for the next beacon at the predicted beacon arrival time using a reception window larger than that in the normal narrow window synchronization mode;

[0086] The second stage is the continuous reception stage. When the number of beacons that are continuously missed during the expanded reception window stage reaches the second preset threshold, the node switches to the radio frequency continuous reception state to improve the probability of beacon reacquisition. It should be noted that the second preset threshold can be equal to the preset threshold, or it can be set to a smaller value according to the actual situation to speed up resynchronization.

[0087] In this embodiment, when the number of consecutive missed beacons by a slave node reaches a preset threshold K, the slave node enters a degraded resynchronization mode. This mode consists of two phases:

[0088] The first phase is the phase of expanding the receive window. The slave nodes maintain the original beacon prediction logic, but the receive window length is increased. The window size is significantly increased (e.g., expanded to 3 to 5 times the normal narrow window size) to cover larger time offsets caused by clock drift or sudden channel fading. During this phase, the slave node still uses intermittent reception, opening the expanded window only when the predicted beacon arrives, and maintaining low power consumption the rest of the time.

[0089] The second stage is the continuous reception stage. If, during the expanded reception window stage, the slave node continues to miss beacon signals up to the second preset threshold (e.g., two more missed beacon signals), the slave node switches to continuous RF reception mode, meaning the receiver remains continuously on and off to capture any possible beacon signal with the highest probability. Although the continuous reception stage consumes more power, it offers the highest reacquisition probability, typically allowing the beacon to be reacquisition within a short time (e.g., 1-2 superframe cycles). Once successful, the node exits the degenerate resynchronization mode.

[0090] In one specific implementation, after the slave node recaptures the beacon, it first resets the missed reception counter to zero, then binds the newly acquired air time reference point with the currently recovered time slot configuration version as a valid synchronization reference, and recalculates the absolute transmission and reception times of subsequent beacons and service time slots based on the valid synchronization reference.

[0091] In this embodiment, after the slave node recaptures the beacon in degraded resynchronization mode, it first resets its local missed reception counter to clear the out-of-synchronization state. Then, the slave node obtains the hardware reception timestamp based on the newly received beacon and reconstructs a completely new airtime reference point (denoted as A). new Simultaneously, the node parses the time slot configuration information from the beacon and, through a version recovery mechanism, ensures that the local time slot configuration is the current valid version (denoted as v). recov Next, from node A... new With v recov Binding to a valid synchronization reference pair means explicitly declaring that the air start time of all subsequent time slots is based on A. new and v recov The parameters are calculated; based on this binding, the slave node recalculates the absolute transmission and reception times of the next beacon and each service time slot of this node, and generates a new time-sharing transmission and reception plan accordingly; after completing the above operations, the slave node exits the degradation resynchronization mode and returns to the normal narrow window low power operation mode.

[0092] In one specific implementation, let the first... The airtime reference point established after the first successful beacon reception is The corresponding effective time slot configuration version is The service time slot index corresponding to the node identifier ID is ,in, According to version The time slot configuration information maps the node identifier ID to the corresponding service time slot index; then the airborne start time of the service time slot is determined. Calculated by the following formula:

[0093]

[0094] in, For version The corresponding business segment starting offset, For version The corresponding single time slot length, For version The corresponding protection interval length.

[0095] This embodiment provides a specific formula for calculating the airborne start time of a service time slot. Let the airborne time reference point established after the k-th successful beacon reception be... The corresponding effective time slot configuration version is The node identifier of the node is ID, which is mapped by the function m(ID, Get the node in version The allocated service time slot index This mapping function can be implemented using a mapping table broadcast by the master node in the beacon, such as a list of (node ​​ID → slot number). Then the service slots... The start time in the air Calculate using the following formula:

[0096]

[0097] in, For version The corresponding service segment start offset is the time interval from the start of the superframe (the start time of the beacon preamble) to the start of the first service slot; For version The length of the corresponding single service time slot; For version The corresponding guard interval length; the guard interval is inserted between adjacent service time slots to absorb propagation delay differences and clock drift; the formula shows that the time slot position within a superframe is determined by the air time reference point and the versioned structural parameters. When the version is updated, the time slot length, guard interval, or offset may change, so it needs to be recalculated.

[0098] In one specific implementation, let the effective superframe number for version switching be... Then the current superframe number Corresponding valid version Satisfy: When Retrieve old version ,when And the new version is used when the consistency check passes. Predicted air arrival time of the next superframe beacon Calculate according to the following formula:

[0099]

[0100] in, For the first The airtime reference point of the superframe beacon. This is the superframe period length corresponding to the effective version; after the version is updated and the verification is passed, the slave node recalculates the expected airtime of the beacon and service slots in the next superframe based on the new version.

[0101] This embodiment defines the boundary handling for version switching and the beacon prediction formula. To avoid inconsistencies in the understanding of time slots within the same superframe by master and slave nodes due to version switching mid-superframe, this embodiment introduces a superframe number. When the master node broadcasts a new version, it also specifies the superframe number from which the version will take effect; the slave nodes select the effective version based on the current superframe number n: if n < ... If so, continue using the old version. If n≥ If the current version has passed the consistency check, then switch to the new version. .

[0102] Based on this version selection rule, the next predicted aerial arrival time of the beacon... Calculate using the following formula:

[0103]

[0104] in, This is the airtime reference point for the beacon of the nth superframe (i.e., the time anchor point established when the beacon is successfully received in this superframe). The superframe period length corresponds to the effective version. Since the superframe period may differ between versions (e.g., changes in the number and length of time slots), the superframe period must be calculated based on the effective version. After the version is updated and passes the consistency check, the slave node recalculates the expected airtime of the beacon and service time slots in the next superframe based on the updated version to ensure the accuracy of the prediction.

[0105] In one specific implementation, the preset threshold is set or dynamically adjusted based on one or more of the following factors: local clock drift estimate, beacon miss count in the most recent superframes, link quality indicators, motion status of slave nodes, and service priority of slave nodes.

[0106] In this embodiment, the setting or dynamic adjustment method of the preset threshold for triggering the degradation resynchronization mode is defined. This preset threshold K is not fixed, but can be set or dynamically adjusted based on one or more of the following factors:

[0107] Local clock drift estimate: If the clock drift of the slave node is large (e.g., due to drastic temperature changes), the synchronization error will accumulate quickly in a short period of time. A smaller threshold should be set so that resynchronization can be initiated as soon as possible; otherwise, a larger threshold can be set.

[0108] Recent missed reception counts for several superframes: If the missed reception shows a continuous increasing trend, it indicates that the channel quality is deteriorating, and the threshold can be dynamically reduced to enter protection mode earlier.

[0109] Link quality metrics, such as Received Signal Strength Indicator (RSSI) and Signal-to-Noise Ratio (SNR), should be lowered if they fall below a certain threshold.

[0110] From the node's motion state: When the UAV is moving at high speed, the Doppler effect and channel changes rapidly, which can lower the threshold; when hovering or moving at low speed, the threshold can be increased.

[0111] Service priority: High-priority services (such as control commands) require low latency and high reliability, so the threshold should be lowered to resynchronize as soon as possible; low-priority data services can have their thresholds raised to avoid frequent resynchronization and increased power consumption.

[0112] The above factors can be used individually or in a weighted combination, and the K value is calculated and updated in real time by the node's state machine. By dynamically adjusting the threshold, this method can adaptively balance power consumption and synchronization robustness.

[0113] Application Examples

[0114] In an exemplary application scenario, the master node is located at a ground control station or ground relay node, and multiple slave nodes are located on a drone platform performing low-altitude logistics delivery tasks. During flight, some drones may experience short-term beacon misses due to entering building obstruction areas, turning sections, or loading / unloading points; simultaneously, some drones complete their missions and leave the network while others temporarily join the formation, causing changes in the original time slot allocation. In this scenario, the master node continuously broadcasts a versioned time slot table containing version number, update type, base version number, and mapping information via beacons; each slave node establishes a unified airborne time reference point using hardware-received timestamps and determines its service time slot based on its own node identifier. When changes in formation size or task priority lead to adjustments in time slot allocation, the slave nodes first restore version consistency and then regenerate an absolute time-triggered transmission and reception plan based on the updated time slot table; when a slave node continuously misses beacons due to obstruction to a threshold, the slave node switches to a degraded acquisition mode and, after recapturing new beacons, quickly returns to a time-division low-power operating state based on the new airborne time reference point and the restored current valid time slot table.

[0115] Example parameter configuration is as follows: Superframe period T sf It can be set to 100ms. Each superframe includes 1 beacon time slot and 8 service time slots, with each service time slot having a length L. s The protection interval G between adjacent service time slots can be set to 1ms, and the service segment start offset O can be set to 8ms. b The system frame structure can be pre-configured (e.g., inserting a 10ms protection period after the beacon time slot ends before starting the service segment). For the mapping between node identifiers and time slot indices, for example, node ID1 can be set to correspond to service time slot 1, node ID2 to service time slot 3, and node ID3 to service time slot 5. The consecutive missed reception threshold K can be set to 3 times, meaning that when a slave node fails to capture a beacon within 3 consecutive prediction reception windows, it switches to degraded acquisition mode. It should be noted that the above values ​​are merely illustrative examples used to help understand the implementation of this application and do not constitute a limitation on the scope of protection of this application.

[0116] In one simulation verification embodiment, a discrete event model was constructed, including beacon synchronization, versioned time slot table updates, absolute time-triggered transmission and reception, and degradation and resynchronization after continuous missed reception, to verify the method of this application. The simulation model uses a repeatable random seed, with a reception start time T. rx,cmd Receive window length W rx Service time slot start time T slot Send absolute trigger time T tx,cmdFactors such as version number matching with the base version, CRC consistency verification, continuous missed reception threshold K, and sudden occlusion are considered. Simulation results show that after establishing an airborne time reference point using hardware receiving timestamps, the receiving window width can be reduced to less than 1 / 3 of the traditional software timestamp scheme, and the receiving duty cycle is reduced by about 60%. After adopting a versioned timeslot table and incremental / full update mechanism, the version recovery time in dynamic scheduling scenarios is shortened to within one beacon cycle, and no timeslot conflicts caused by configuration inconsistencies occur. After adopting a degradation acquisition resynchronization mechanism, the synchronization recovery delay after the end of occlusion is reduced from several seconds in the traditional scheme (requiring re-entry into the network) to within two superframe cycles. This shows that the proposed solution can balance low power consumption, synchronization stability, and dynamic scheduling reliability under low-altitude movement and dynamic node changes, meeting the requirements of UAV communication links.

[0117] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0118] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A low-power time-division communication synchronization method for unmanned aerial vehicles (UAVs) based on hardware time anchors, characterized in that, include: The master node periodically broadcasts beacon frames, which carry versioned time slot configuration information for time-division communication. The versioned time slot configuration information includes at least superframe parameters, the mapping relationship between nodes and time slots, version identifiers, and update verification information. When a node receives a beacon frame, it obtains a hardware reception timestamp and determines an air time reference point based on the hardware reception timestamp. The node performs consistency processing based on the version identifier in the beacon frame and the local version: if they match, the local version is taken as the current valid version; if they do not match, an incremental update or a full update is performed according to the update type in the update verification information, and the updated version is determined as the current valid version after the verification passes. Based on the air time reference point and the time slot configuration corresponding to the current valid version, the node generates an absolute time triggering plan for sending and receiving time slots in the current or next superframe. The master node and slave node perform the sending and receiving windowing operations according to the absolute time triggering plan, and the slave node enters a low-power state during non-receiving windows and non-transmitting time slots. The node detects beacon loss and enters a degradation resynchronization mode when the continuous loss reaches a preset threshold, in order to recapture the beacon by expanding the receiving window or by continuously receiving data. After recaptures the beacon, the slave node reconstructs the air time reference point based on the new hardware receive timestamp, binds the reconstructed air time reference point to the restored current valid version time slot configuration, regenerates the absolute time triggering plan based on the binding result, and then exits the degradation resynchronization mode.

2. The method according to claim 1, characterized in that, The hardware receive timestamp is output by the wireless RF transceiver module when the beacon frame is successfully received; when the hardware receive timestamp corresponds to a predetermined reference point after the start of the beacon preamble, the slave node adjusts the timing according to a pre-calibrated fixed time offset. Hardware receive timestamp Converted to the air time reference point of the beacon preamble start The conversion formula is: in, This is a fixed time offset between the start time of the beacon preamble and the predetermined reference point. The sequence number for successfully received beacon.

3. The method according to claim 1, characterized in that, The node predicts the expected time of arrival of the target frame in the air based on the air time reference point. The receive start time is determined according to the following formula. and receive window length : in, The duration required from receiving a command to the stabilization of radio frequency reception. To receive advance allowance, To receive timeout margin, The timer count value corresponds to the duration of the preamble and the synchronization word; when the actual arrival time of the target frame falls within the interval [ When the synchronization error estimate or the consecutive missed detection count increases, the narrow window capture is considered successful; when the synchronization error estimate or the consecutive missed detection count increases, the window is increased. or To widen the receiving window.

4. The method according to claim 1, characterized in that, For the transmission time slot, the slave node transmits according to the expected air transmission time. And the fixed offset between the start of the command transmission and the entry of the first bit of the preamble into the air channel. The absolute trigger time for sending the command is determined according to the following formula. : This ensures that the air start time for transmitting the preamble falls within the allocated transmission time slot.

5. The method according to claim 1, characterized in that, The update of time slot configuration includes incremental update and full update; the master node increments the version identifier when the network node composition, service priority, link quality or scheduling policy changes; before performing incremental update, the slave node first verifies that the base version number carried in the beacon is consistent with the local current version number, and after applying incremental update, it verifies the updated time slot configuration according to the consistency verification field in the update verification information; if the base version number is inconsistent or the verification fails, the slave node rolls back to the full update process, that is, receives the complete time slot configuration and replaces the local configuration.

6. The method according to claim 1, characterized in that, The degenerate resynchronization mode comprises two phases executed sequentially: The first stage is the expanded reception window stage, in which the slave node waits for the next beacon at the predicted beacon arrival time using a reception window larger than that in the normal narrow window synchronization mode; The second stage is the continuous reception stage. When the number of beacons that are continuously missed during the expanded reception window stage reaches the second preset threshold, the node switches to the radio frequency continuous reception state to improve the probability of beacon re-acquisition.

7. The method according to claim 1, characterized in that, After the node recaptures the beacon, it first resets the missed reception counter to zero, then binds the newly acquired air time reference point to the currently recovered time slot configuration version as a valid synchronization reference, and recalculates the absolute transmission and reception times of subsequent beacons and service time slots based on this valid synchronization reference.

8. The method according to claim 1, characterized in that, Let the first The airtime reference point established after the first successful beacon reception is The corresponding effective time slot configuration version is The service time slot index corresponding to the node identifier ID is ,in, According to version The time slot configuration information maps the node identifier ID to the corresponding service time slot index; then the airborne start time of the service time slot is determined. Calculated by the following formula: in, For version The corresponding business segment starting offset, For version The corresponding single time slot length, For version The corresponding protection interval length.

9. The method according to claim 1, characterized in that, wherein... The superframe number at which the version switch takes effect is: Then the current superframe number Corresponding valid version Satisfy: When Retrieve old version ,when And the new version is used when the consistency check passes. Predicted air arrival time of the next superframe beacon Calculate according to the following formula: in, For the first The airtime reference point of the superframe beacon. This is the superframe period length corresponding to the effective version; after the version is updated and the verification is passed, the slave node recalculates the expected airtime of the beacon and service slots in the next superframe based on the new version.

10. The method according to claim 1, characterized in that, The preset threshold is set or dynamically adjusted based on one or more of the following factors: local clock drift estimate, beacon miss count in the most recent superframes, link quality indicators, slave node motion status, and slave node service priority.

Images