Collision avoidance method suitable for digital underwater acoustic communication

Abstract

The invention relates to the technical field of underwater communication, in particular to a collision avoidance method suitable for digital underwater acoustic communication, which is characterized in that a neighbor propagation delay mapping database is maintained at each communication node, and inter-node propagation delay information is acquired through passive monitoring and active detection. When a node wants to send data, combining delay mapping to predict a channel occupation time slot, and judging whether the sending is conflicted with an RTS / CTS handshake stage, a data transmission stage and an ACK (Acknowledgement Character) confirmation stage which are carried out by a neighbor; if a conflict risk exists, the node delays to send the RTS and then initiates handshake until the security window is finished, so that collision caused by hidden nodes and exposed nodes is avoided, meanwhile, parallel transmission under the conflict-free condition is allowed, the channel space-time multiplexing efficiency is improved, the network throughput can be remarkably improved, the data packet collision rate is reduced, and the network performance is improved. And the node access fairness is improved.

Description

Technical Field

[0001] This invention relates to the field of underwater communication technology, and in particular to a collision avoidance method in a digital underwater acoustic communication network. Background Technology

[0002] Underwater acoustic communication networks (UANs) have been widely used in marine environmental monitoring, petrochemical leak monitoring, submarine detection, and ocean observation. Compared to terrestrial radio communication, underwater acoustic channels have unique physical characteristics: extremely slow propagation speed and limited bandwidth. Sound waves travel at approximately 1500 m / s in water, only one fifty-thousandth the speed of electromagnetic waves in free space. This means that in an underwater network spanning several kilometers, the propagation delay of acoustic signals can reach several seconds, while the transmission time of a typical data frame may only be tens of milliseconds. Such a long propagation delay means that before the transmitted signal reaches the receiving node, other nodes in the network may mistakenly believe the channel is idle, leading to collisions. Furthermore, underwater acoustic channels suffer from narrow usable bandwidth, low data rates, multipath fading, and severe ocean noise; these factors collectively pose significant challenges to the design of medium access control (MAC) protocols for underwater acoustic networks.

[0003] Currently, the Carrier Sense Multiple Access (CSMA) protocol, commonly used in terrestrial wireless networks, is significantly less effective in underwater environments. The carrier sense mechanism cannot accurately determine the true occupancy status of the underwater acoustic channel, because an idle channel does not necessarily mean there is no ongoing communication in the distance. When the propagation delay is on the same order of magnitude as the data frame length, the traditional CSMA strategy of "listening" to the channel before transmission cannot prevent collisions. Typical random access protocols such as ALOHA have low latency under low load, but generate numerous collisions under slightly higher loads due to the lack of collision avoidance mechanisms. To address this, researchers have proposed several improved ALOHA schemes, such as ALOHA with Collision Avoidance (Aloha-CA) and ALOHA with Advance Notification (Aloha-AN). These protocols utilize neighbor data monitored by nodes to calculate busy / idle times, thereby avoiding collisions.

[0004] Given the limitations of pure carrier sense and random access in underwater acoustic environments, collision avoidance protocols based on handshakes have become a key focus of current research on MAC in underwater acoustic networks. Common handshake schemes involve sending Request to Send (RTS) and Clear to Send (CTS) frames to reserve the channel, such as the classic MAA protocol and its extension MAA-U (for underwater MAA). The handshake process causes neighboring nodes that hear the control frame to temporarily suspend their communication, thus solving the hidden node problem (hidden terminals cause signal collisions at the receiving node) to some extent. However, under long propagation delays, simple RTS / CTS bidirectional handshakes cannot completely avoid hidden node collisions: due to delayed feedback such as ACKs, other nodes may prematurely re-contend for the channel, and collisions may still occur. To address this, some improved schemes have emerged. For example, Molins et al. proposed the Slotted-FAMA protocol, which divides the time axis into time slots with a length equal to the maximum propagation delay, allowing data packets to be sent only at the beginning of the time slot. Although this method eliminates hidden node collisions, the excessively long time slots significantly reduce channel utilization.

[0005] For example, Peleato et al. proposed the Distance-Aware Collision Avoidance Protocol (DACAP), which combines carrier sense with RTS / CTS handshake and allows for handshake processes of different lengths for receivers at different distances to shorten the average handshake overhead. DACAP adds an appropriate waiting time before sending data to ensure that there are no harmful collisions before transmission begins.

[0006] In addition, Propagation Delay Aware Protocol (PDAP) avoids collisions by tracking the transmission status of neighboring nodes, allowing data frames between different communication pairs to be interleaved, thereby improving channel utilization; another type of scheme, such as the Tone-Lohi protocol, introduces short tone signals to compete for the channel, which also provides a certain degree of collision avoidance capability.

[0007] The above technologies demonstrate that improving MAC layer concurrency and avoiding collisions in environments with long propagation delays is a core challenge for underwater acoustic networks.

[0008] In particular, underwater acoustic ad hoc networks face the dual challenges of exposed node problem and hidden node problem: exposed nodes unnecessarily back off because they hear their neighbors transmitting, resulting in wasted channel space; hidden nodes, on the other hand, transmit rashly because they cannot hear ongoing communication, leading to collisions at the receiver.

[0009] Existing solutions each have their advantages and disadvantages. Scheduling protocols (such as TDMA / FAMA) are reliable but have low utilization rates, while pure contention protocols (such as ALOHA / CSMA) are flexible but prone to collisions, requiring a trade-off between throughput and latency.

[0010] Chinese patent publication CN110049572B proposes a delay-aware transmission scheduling method. Based on CSMA, it utilizes time and space reuse, scheduling transmissions by detecting the propagation delay of neighboring nodes and predicting information. This increases concurrent transmission opportunities to compensate for long delays and reduces the probability of exposed node collisions. This method significantly improves the overall network throughput and effectively alleviates spatial unfairness caused by differences in node location and propagation delay.

[0011] Nevertheless, there is still room for improvement in collision avoidance for multi-node concurrent environments; existing technologies focus on avoiding hidden node conflicts, but fail to make full use of long latency gaps. Summary of the Invention

[0012] This invention provides a collision avoidance method in a digital underwater acoustic communication network, employing a mechanism combining delay mapping and dynamic scheduling to achieve efficient collision avoidance under multi-node concurrent transmission. The method specifically includes the following steps:

[0013] S1. Establish a Neighbor Propagation Delay Mapping Database: During network initialization or communication, each node measures and records the propagation delay with its neighbors by exchanging probe messages or passively listening to neighbor communication. The delay mapping information includes: the neighbor node identifier, the distance or estimated propagation delay between the node and the neighbor, and the timestamp of the most recent delay measurement. When adjacent nodes perform an RTS / CTS handshake, other nodes can listen to the time difference between the RTS and CTS occurrences to estimate the propagation delay between the two nodes and record this in the delay mapping database. The delay mapping database can be dynamically updated over time to reflect the impact of factors such as node movement or changes in sound speed on propagation delay.

[0014] S2. Channel Listening and Transmission Intent Determination: When a node has data frames to transmit, it first enters channel listening mode to determine if the current channel is likely idle. Due to the propagation hysteresis characteristics of underwater acoustic channels, the node not only detects the local carrier signal but also needs to predict the channel state using a delay mapping database. Specifically, the node checks if any recently transmitted signals from neighbors are still propagating: for example, if the delay mapping shows that a neighboring node A sent an RTS to another node B at time t_0, and this node is preparing to transmit data at time t_1 (t_1>t_0), then the time range between B receiving the RTS and sending the CTS is calculated based on the propagation delay between A and B. During this period, if this node transmits to a node, it may interfere with B's response to A. Therefore, this node needs to wait until the end of this time window before attempting to transmit. If it is predicted that no neighbor communication activity will affect this transmission within the next Δt time, the channel is determined to be "idle," and the node can initiate a transmission intent. Otherwise, the node enters a backoff timer and postpones the retry transmission according to the backoff algorithm (e.g., re-evaluating after a random backoff period).

[0015] S3. Sending Handshake Frames and Avoiding Collisions: After determining the transmission timing, the node sends an RTS control frame to the target receiving node. During the RTS transmission process, the node continues to listen to the channel.

[0016] If, before or during the transmission of an RTS, a node detects that a neighboring node's CTS or ACK frame is arriving (e.g., a neighbor is responding to a request from another node), it immediately suspends or delays transmitting the RTS. The duration of the CTS / ACK is predicted using delay mapping, and the node's RTS is transmitted only after it has ended. This avoids air collisions between the node's RTS and its neighbor's control frames.

[0017] If there is no interference, the RTS transmission will be completed normally. The RTS frame should contain the expected data frame length information so that neighboring nodes can estimate the channel time occupied by this data transmission.

[0018] S4. Receiving Node Processes CTS Response: After receiving the RTS, the target receiving node waits for a short processing time τ_proc, and then determines whether it can send the CTS:

[0019] If the currently receiving node also detects other communications (e.g., it has received an RTS request from another pair of nodes), the response order is determined according to priority or scheduling policy. A "delayed acknowledgment" approach can be used: if the node discovers that it is also a potential interfering party in another communication, it can delay sending the CTS to avoid overlapping and interfering with the two handshake processes.

[0020] Once it is determined that a safe response is possible, the receiving node sends a CTS frame to the sending node. The CTS frame specifies the length of the data time slot that is permitted to be transmitted (i.e., the reserved time required to transmit data). CTS transmission also follows collision avoidance: before sending a CTS, the receiving node checks whether it is receiving other signals to avoid CTS collisions. After sending the CTS, the receiving node enters a data reception preparation state.

[0021] S5. Concurrency Decision-Making of Neighbor Nodes: When other neighboring nodes in the network hear RTS or CTS control frames, they use the delay mapping database to determine whether they are potential interferers.

[0022] If a neighboring node X only hears the RTS but not the CTS, it means the target of the RTS is not X and the CTS may be elsewhere. In this case, X cannot determine whether the handshake was successful, so it assumes a hidden node scenario and remains silent until sufficient time has passed. Alternatively, X can estimate the time window during which the CTS should return based on the delay mapping. If the CTS is still not detected after this window, it is inferred that the RTS was unsuccessful (the sending node may have given up or a collision may have occurred), and only then can X attempt to contend for the channel.

[0023] If a neighboring node Y hears the RTS and subsequently the CTS, but Y is far from both the sender and receiver of this communication, then Y may be an exposed node. This method differs from the traditional MACA protocol in that the exposed node Y does not need to blindly remain silent throughout the data transmission. Instead, it calculates whether its signal to another node Z will conflict with the current communication in time or space. If, according to the delay mapping, the arrival time of the Y->Z signal does not fall within the current A->B data reception time window, and Z is not within the interference range of A or B, then Y can initiate parallel communication with Z without interfering with A and B. In other words, it allows non-collision concurrent transmission, maximizing channel multiplexing efficiency. Conversely, if the calculation reveals a potential conflict (e.g., Y or Z is very close to A or B), then Y must wait for the A and B communication to finish before sending. In this way, this method significantly reduces the throughput loss caused by the exposed node problem.

[0024] S6. Data Frame Transmission and Reception: After receiving the CTS, the sending node transmits data frames according to the time slot length indicated by the CTS. Considering the precious bandwidth and high round-trip time of the underwater acoustic channel, this method supports a data frame train transmission mechanism: the sending node can continuously send multiple data frames (e.g., a group of packets) after one RTS / CTS handshake to reduce the overhead of frequent handshakes, thereby further improving throughput. These data frames can be assembled into a data block at the MAC layer and sent sequentially. The receiving node continuously receives until the end of the data block and then sends a unified ACK, or it can send an ACK for each frame, depending on the link reliability requirements. The sending node keeps listening throughout the data transmission process to prevent unexpected interference signals. If the sending node detects strong interference during data transmission (e.g., unexpected transmissions nearby), it can immediately stop transmitting according to the protocol design and wait for retransmission.

[0025] S7. Acknowledgment and Retransmission: After successfully receiving a data frame (or frame sequence), the receiving node waits for a short, randomized delay (to prevent ACK collisions) and then sends an ACK frame to the sending node. The sending node receives the ACK, indicating the end of this round of transmission, releases the channel, and updates its statistics. If the ACK is not received within the timeout period, a collision or packet loss is determined, triggering a retransmission mechanism. During retransmission, the sending node postpones the next RTS according to the backoff algorithm and may adjust subsequent transmission parameters appropriately (e.g., reducing the number of data frames sent per transmission or increasing power) to improve the success rate. It is worth noting that because this method reduces the collision probability to a low level through fine-grained scheduling, retransmissions are relatively rare. When they do occur, it is usually due to uncertainties caused by instantaneous environmental changes or the addition of new nodes.

[0026] S8. Dynamic Delay Mapping Updates: Changes in network topology or environment can affect propagation delay and interference. To maintain optimal performance, nodes continuously update the delay mapping database during communication. For example, when a node detects a new neighbor signal, if there is no previous record of that neighbor, it adds the neighbor and estimates the propagation delay; for neighbors with existing records, the entries are updated based on the delay measured in the latest handshake. When environmental changes are detected that cause changes in propagation speed (such as changes in water temperature affecting the speed of sound), correction information can be broadcast or delay estimates can be gradually adjusted through hop-by-hop measurements. Dynamic maintenance of the delay mapping ensures that the scheduling algorithm always makes decisions based on the latest spatiotemporal information, thereby reliably avoiding conflicts.

[0027] Through the above steps, the method of the present invention implements a distributed, delay-aware collision avoidance mechanism at each node.

[0028] The core idea of ​​this invention is to introduce a propagation delay database and time slot prediction scheduling on the basis of traditional CSMA / CA, so that nodes can predict potential conflicts in advance and then intelligently arrange the transmission timing.

[0029] This invention greatly improves the network's concurrent performance by allowing collision-free parallel transmission. At the same time, for collision scenarios that must be avoided, this method achieves more reliable collision prevention than previous solutions through accurate prediction and delayed transmission. In specific implementation, each node only needs to maintain a neighbor propagation delay table at the MAC layer and perform simple time calculations and comparisons before and after transmission. Therefore, the algorithm has low overhead and is suitable for resource-constrained underwater acoustic communication equipment.

[0030] In summary, the technical solution provided by this invention can effectively overcome the collision problem caused by long delays in underwater acoustic communication, improving throughput while ensuring network stability.

[0031] The beneficial effects achieved by the present invention using the above structure are as follows:

[0032] 1. This invention fully utilizes the long propagation delay of underwater acoustic channels, allowing multiple nodes to communicate in parallel within a safe range, which greatly improves the channel space reuse efficiency and the overall network throughput.

[0033] 2. By constructing a neighbor propagation delay mapping and predicting the transmission timing, this method can proactively avoid potential conflicts before transmission, reduce the probability of data packet collisions, and improve communication reliability and data transmission success rate.

[0034] 3. This invention solves the problem of unfair channel occupancy caused by the distance between nodes. Exposed nodes do not need to wait unnecessarily, and hidden nodes avoid interference with the receiving process, thereby balancing the channel occupancy opportunities of each node and reducing unnecessary waiting delays. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the digital underwater acoustic communication network of the present invention;

[0036] Figure 2 This is a timing diagram of the collision avoidance mechanism of the present invention;

[0037] Figure 3 This is a schematic diagram of the collision avoidance method of the present invention at a node. Detailed Implementation

[0038] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art can adjust the order of steps and parameter values ​​without departing from the spirit of the invention.

[0039] The collision avoidance method of this invention can be independently executed by each node in the network using a distributed algorithm. Each node makes decisions according to unified rules, without the need for central control. The method is particularly suitable for digital underwater acoustic communication environments, such as underwater wireless sensor networks and autonomous underwater vehicle (AUV) communication networks.

[0040] This invention targets a decentralized underwater acoustic self-organizing network where all nodes communicate through a single shared acoustic channel. It assumes each node is equipped with a full-duplex or half-duplex underwater acoustic communicator (typically half-duplex, meaning simultaneous transmission and reception is not possible, but rapid switching is possible). To focus on collision avoidance, this embodiment assumes all nodes operate in the same frequency band (i.e., single-channel mode), without employing multi-channel or multi-carrier modulation. Nodes in the network may be stationary or moving, with movement speeds very low relative to the speed of sound; the topology can be approximated as remaining unchanged within a single data exchange cycle.

[0041] The propagation delay between each pair of nodes depends on distance and the speed of sound. The speed of sound is affected by water temperature, salinity, and depth, but can be considered constant at approximately 1500 m / s over small areas and short periods. While the network layer employs a simple wireless routing protocol, this method operates at the MAC layer, improving data transmission efficiency at the point-to-point link level, thus ensuring seamless compatibility with upper-layer routing.

[0042] To monitor the channel, the node in this embodiment can identify basic frame types (RTS, CTS, data frames, ACK frames, etc.) and measure the arrival time of received frames. This invention does not involve specific physical layer modulation methods; any general underwater acoustic modulation and demodulation technique can be used, as long as it can achieve signal timing and packet decoding.

[0043] The delay mapping database is one of the key modules of this invention, recording the propagation delay estimates between a node and its communicating neighbors. This database is continuously updated during network operation. Initial establishment can be achieved through the following two mechanisms:

[0044] Nodes periodically send short probe packets (such as Ping) and receive responses from neighbors. The round-trip delay is estimated based on the round-trip time, then divided by 2 to obtain the one-way propagation delay. Due to clock errors and processing delays, multiple measurements can be taken and averaged to improve accuracy. Active probing is suitable for obtaining delays when a node initially joins the network or when it has not communicated with neighbors for a long time.

[0045] When neighboring nodes perform a communication handshake, this node can passively collect latency information. For example, if neighbor A sends an RTS to neighbor B, this node can receive the RTS almost simultaneously (assuming this node is within A's communication range). Subsequently, B sends a CTS after a processing delay, which this node can also receive. Let the time when this node receives the RTS be ti. The time to receive CTS is Then the propagation delay from A to B is... It can be estimated using the following formula:

[0046]

[0047] in The time required to process RTS for B. Let CTS be the time it takes for the current node to propagate from B to A. Since the distance between this node and A may differ from its distance to B, directly using the time difference between the time this node receives the RTS and the time it receives the CTS to estimate the delay between A and B will introduce errors. However, after repeatedly monitoring the A / B communication from different locations, this node or other nodes in the network can synthesize information from multiple sources to estimate a more accurate delay. Especially when the node is exactly equidistant from A and B, or when its relative position to A and B is known, the propagation delays from A to B and from B to A can be accurately calculated. In fact, through interactive probing and distributed exchange of delay information, the entire network can asymptotically approximate the actual distance matrix information between nodes. This is similar to network ranging or topology inference techniques, except that this invention simplifies it to a delay mapping table at the MAC layer, which is sufficient to meet the requirements.

[0048] Each record in the delayed mapping database can be in the form of: (neighbor ID, (timestamp), where This is a propagation delay estimate. A timestamp is used to record the update time of this estimate, reducing its reliability if it hasn't been updated for a long time (e.g., if it hasn't been updated for more than a certain threshold, it needs to be re-probeed). For mobile node environments, the validity period of the delay map should be short, and it should be refreshed periodically to track changes in neighbor distances; for static networks, a single measurement can be used for a long time, requiring only occasional calibration to account for changes in sound speed.

[0049] In implementation, the delay mapping database can reside locally on each node. When a node detects a new neighbor, it initializes a record; when a neighbor disappears (no signal is heard for an extended period), the record can be temporarily retained but marked as inactive to prevent the need to start measuring from scratch when a temporarily offline node reappears. The database size is typically proportional to the number of neighbors; in sparse underwater acoustic networks, the number of neighbors is limited, so storage and maintenance overhead is minimal.

[0050] The channel assessment before sending the decision is an innovative step that distinguishes this invention from traditional MAC. In this invention, the node not only listens to the current channel for signal through the physical carrier, but also combines a delay mapping database to predict whether the channel will be occupied in the near future.

[0051] For example, node X intends to send data to node Y. In traditional CSMA / CA, X listens to the channel and assumes it's idle if no signal is detected within a certain timeframe, allowing it to send an RTS (Real-Time Request). However, in underwater acoustic networks, "idleness" can be misleading: no signal may be arriving at X at that moment, but this doesn't mean Y is idle, nor does it mean the path from X to Y is idle. For instance, neighboring node A might be communicating with another node B at a distance from X. X might not hear the A->B data, but Y might be nearby and hear it. If X sends data to Y at this time, Y will simultaneously receive data from B and X's RTS, resulting in a collision. Such spatially hidden collisions need to be avoided through prediction.

[0052] Before sending, node X takes into account the "recent activity" recorded in the delay mapping database. In practice, each node can maintain a neighbor communication state table, recording recent... Communication initiated or participated in by neighbors within a time window. For example, recording communication initiated or participated in by neighbor A within a time window. RTS has been sent to B at any time, and the propagation delay from A to B and the data length are estimated based on the delay mapping, thus calculating the possible busy periods for B. If node X is ready at time... Send, and If Y falls within the aforementioned time period and is near B (based on delay mapping or known topology, Y and B are relatively close), then it can be determined that sending X at this time would interfere with Y listening to B's data, therefore X should postpone sending.

[0053] In order to implement this prediction mechanism, certain information acquisition channels are required.

[0054] This invention assumes that when a neighboring node sends an RTS (Redirect Time Schedule), it will indicate in the RTS header the duration for which it expects to occupy the channel (i.e., the data duration plus the CTS / ACK wait time). The IEEE 802.11 protocol's RTS / CTS framework already has a similar field (Duration field) used to notify neighbors how long the network will be busy. The MAC protocol for underwater acoustic networks can follow this approach: the RTS should include a time duration. (Network Allocation Vector) indicates the total time the sending node expects to occupy the channel for this session. After receiving the RTS, neighboring nodes can use this to set a soft blocking timer. To avoid conflicts, do not attempt to send again before the deadline.

[0055] However, unlike 802.11, because the underwater acoustic propagation delay is much longer than the frame duration, neighboring nodes need to accurately determine whether they are truly within the interference range before deciding whether to block. The improvement of this invention lies in the fact that neighbors do not blindly rely on any sound they hear. Instead of remaining silent, it further calculates whether the communication overlaps in time or conflicts in space with its own potential transmission.

[0056] In implementation, before deciding to send an RTS, node X can first collect information about potential conflicts within a two-hop range. For example, X might listen to its neighbor A's RTS and know that A plans to occupy the channel. Time; simultaneously, if X's target Y is also in A's neighbor list (this relationship can be inferred through delayed mapping, for example, X knows...). If X sends an RTS to Y now, Y will be unable to respond to X due to time constraints. Therefore, X should wait. Time expires. This two-hop information does not need to be provided by the central node; it can be completed entirely by each node's local listening and calculation: A's RTS is heard by X, and Y may also hear A's RTS or CTS. X knows the distance between Y and A through delay mapping, and thus X infers that Y will be occupied.

[0057] Taking all factors into consideration, the pre-transmission channel prediction algorithm can be described as follows:

[0058] [Function can_send_now(node ​​X, dest Y):]

[0059] # Returns a boolean value indicating whether node X can currently send to Y without causing a collision.

[0060] For each neighbor node N:

[0061] If communication is initiated with N detected in the near future (time < ΔT):

[0062] Let the communication target be M, and the duration be T_NAV(N) (from the time of listening to the start of timing);

[0063] Delay mapping is used to estimate the distance and propagation delay between Y and the communicating parties (N, M);

[0064] If Y is within the communication coverage area of ​​N or M:

[0065] Calculate the time t_busy_start when Y will begin receiving the N->M signal.

[0066] = t_commence(N) + Δ_{N->Y};

[0067] Calculate the time t_busy_end when Y will end receiving this signal.

[0068] = t_commence(N) + T_NAV(N) + Δ_{M->Y} (If M sends an ACK, it is also included);

[0069] If the current time t_cur and the data transmission completion time t_cur + T_DATA overlap within [t_busy_start, t_busy_end]:

[0070] Return False # Prediction will interfere with Y's ongoing communication

[0071] Returning True # No risk of conflict]

[0072] The algorithm described above iterates through the nearest communication activities of neighbor N, inferring whether the destination node Y is within the interference range of N or its communication partner M based on the delay mapping. In practical implementation, this can be optimized to only check those communications that are close to Y or have similar propagation delays, thereby reducing computation. When it returns True, X can safely send the RTS. When it returns False, X should start a backoff timer and retry after a short period of time. The backoff time can be dynamically adjusted according to the degree of conflict, for example, randomly taking a value between 0 and... Between (the maximum known propagation delay of the network), or by using a binary exponential backoff strategy to increase the waiting time, the probability of repeated collisions can be reduced.

[0073] Once the source node X decides to send an RTS, it enters the handshake phase. The handshake involves control frame exchanges in both the RTS and CTS directions. During this process, this invention provides several improvements to avoid collisions:

[0074] Protection of RTS Transmission: Although node X has made predictions before sending an RTS, unexpected situations may still occur. For example, after X starts sending an RTS, neighbor A's CTS arrives at X only then (indicating that A is communicating with someone else and X did not predict this). Therefore, X continuously listens to the local channel while sending an RTS. Once a strong signal (possibly a neighbor's CTS / ACK) is detected, RTS transmission is immediately stopped. This is similar to a "momentary backoff" mechanism: it's better to have an incomplete RTS than to let it interfere with someone else's important control frame. After stopping transmission, X records the time and type of interference (CTS or ACK) and will retry RTS transmission after the interference ends. Since CTS / ACK lengths are usually very short, this pause has little impact on itself but protects the neighbor's handshake from succeeding. In this embodiment, when X detects a CTS collision, it waits until the CTS frame ends, then waits for a small random delay (to prevent multiple affected nodes from simultaneously retransmitting RTS and colliding again), and then retransmits the RTS. Practice has shown that this effectively reduces control frame collisions, especially reducing mutual interference caused by multiple nodes contending almost simultaneously.

[0075] CTS Response Scheduling: After receiving an RTS from X, target node Y does not immediately and blindly reply with a CTS, but intelligently determines when it is most appropriate to reply. Y first checks if it is currently receiving data from another communication. If so, it directly rejects / ignores X's RTS (without sending a CTS) to avoid distraction that could cause both communications to fail. This situation is equivalent to X's RTS not receiving a CTS, and X will treat it as a timeout. If Y is currently idle, it also needs to consider the surrounding environment: Y can check its local neighbor status table (similar to X's prediction process) to confirm that replying with a CTS will not cause conflicts between neighbors. For example, if neighbor C also sends an RTS to Y and Y receives two RTSs almost simultaneously, Y can decide which one to serve based on its strategy: it can compare the sending duration or priority flags of the requests in the two RTSs, choose one to send a CTS to, and ignore the other or send a busy tone notification frame to indicate "busy". In its implementation, this invention allows Y to arbitrate multiple competing RTS requests to reduce competition uncertainty. In a simple implementation, Y can respond to the first received RTS using a "first-come, first-served" principle, discarding the others; in an improved implementation, it can also wait briefly. Multiple RTSs are collected, and the optimal one is selected for response based on factors such as transmission duration and channel conditions. The arbitration mechanism is not the core of this method, so details are not elaborated here. Before sending a CTS, Y performs a similar listening process as X when sending an RTS: confirming that no other high-priority signals are heard (e.g., an emergency stop command from the upper layer or environmental interference) before sending the CTS. Once the CTS is sent, Y is ready to receive data and marks its state as "busy" during the time slot specified by the CTS for its neighbors to reference.

[0076] Neighbor node coordination in the handshake: In addition to the communicating parties X and Y, the handshake phase also involves neighboring nodes that have heard the RTS or CTS. Following the principles of the MACA protocol, nodes that have heard the RTS and CTS will set the Network Assignment Vector (NAV) to avoid interference during the handshake and subsequent data transmission.

[0077] In this invention, neighboring nodes execute improved NAV logic:

[0078] If a neighboring node only hears the RTS and not the CTS, it is not the target node and there may be a hidden terminal. It will then determine the target node based on the information in the RTS. A temporary NAV timer is set, but the channel is continuously monitored during this timer period. If a CTS or data preamble is not heard for a long time, the RTS may have failed, and the NAV can be canceled in advance. This avoids the problem of neighbors being mistakenly silent for a long time due to RTS collisions causing CTS to fail to be sent in some cases.

[0079] If a neighboring node hears the CTS, it indicates a successful handshake and data transmission is imminent. The neighbor then remains silent for the time slot specified by the CTS. However, if the neighbor is far from both communicating parties and has confirmed through delay calculations that sending data in another direction will not affect the current communication, this method allows the neighbor to un-silence and initiate parallel communication. The decision to un-silence strictly follows the criteria described in step S5, and is only allowed when there are no conflicts in time and space. This is equivalent to shortening the NAV duration from a fixed "entire communication period" to a "conflict risk period." For example, if neighbor D hears the CTS for A->B, it would normally remain silent. While the timing is not directly measured, calculations show that communication from D to C does not interfere with AB (C is not within the coverage area of ​​AB, and B has already received all of A's data when the D->C signal arrives at B). Therefore, D can initiate D->C communication ahead of time without waiting for AB to complete. Experiments demonstrate that this computation-based dynamic adjustment of NAV can significantly improve concurrency without increasing the probability of collisions.

[0080] After a successful handshake, the data transmission phase begins.

[0081] Source node X sends data frames according to CTS permission. To maximize throughput, this invention has optimized the data transmission design:

[0082] Typical CSMA / CA requires an RTS / CTS handshake and ACK confirmation for each data frame sent, resulting in significant overhead in long-latency environments. To address this, this invention employs Packet Train technology: instead of sending a single data packet after a handshake, a series of data packets are sent. Specifically, a field is added to the CTS frame indicating the number of consecutive data frames allowed to be sent. Or total number of bytes After receiving a CTS, X can send not just one frame, but continuously. Frames (or no more than) (Data). These frames can be multiple segments of data from the same upper layer, or data from different upper layer queues sent sequentially. Using frame trains has two advantages: first, it reduces the protocol overhead of frequent handshakes, significantly improving efficiency when transmitting large amounts of data; second, it fully utilizes the valuable "channel occupancy rights" gained through RTS / CTS handshakes, avoiding wasted channel idle time under long delays. For example, if RTS / CTS takes 2 seconds to allow the channel to rotate to X for transmission, it's better to let X send as much data as possible before releasing it, rather than sending only a small packet and ending the transmission. This method allows for flexible configuration of frame train length based on network congestion levels and fairness requirements, preventing any node from occupying too much time. Frames in a frame train can be transmitted continuously without additional intervals. The receiving node Y continuously receives all frames... After each frame, the system checks and sends the corresponding number of ACKs, or sends a cumulative ACK (the ACK indicates how many frames were received and which sequence numbers are missing). For high reliability requirements, frame-by-frame ACKs can detect packet loss more promptly; in high-latency, high-throughput scenarios, cumulative ACKs can reduce reverse overhead. This embodiment uses frame-by-frame ACKs to simplify the logic.

[0083] When source node X is sending a train of data frames, it should not completely shut down its receiver. This invention requires nodes to monitor channel noise during inter-frame intervals or idle microseconds during frame transmission. This is partly to be aware of potential early termination notifications from target Y: for example, if Y detects an error in the current frame or is unable to continue receiving, it may send a special symbol to notify X to stop transmitting (to avoid wasting subsequent frames). On the other hand, monitoring the channel also serves to prevent external interference: although the handshake phase prevents most collisions, unexpected events can still occur, such as a distant node misinterpreting the signal and concurrently transmitting, causing interference. If X detects abnormally strong noise or interference, it can choose to abort the transmission of the remaining frames to avoid futile attempts. After aborting, X can retain the remaining untransmitted data and retransmit it later via the handshake. It should be noted that this situation is extremely rare and is an additional security mechanism; normally, X will not detect a signal requiring abort.

[0084] Underwater acoustic transmission consumes a lot of energy. To balance energy efficiency, this invention can incorporate a power control strategy. Before data transmission, the approximate distance to the target Y is known based on the delay mapping. X can then adjust its transmission power to be sufficient to cover this distance, without needing to transmit at full power indefinitely. Reducing power saves electricity and reduces the interference range to other nodes, indirectly benefiting increased concurrency (reduced interference range means increased network space reuse). Of course, if the link condition is poor (high bit error rate), X can also increase its power to ensure reliability. The power control strategy can be preset or dynamically adjusted based on the quality information fed back by the ACK (such as SNR, whether retransmission is required). This specific embodiment assumes that the node has two power levels: high and low, switching according to the target distance threshold. High power covers longer distances, while low power is used for nearby communication. The distance d is obtained through delay mapping. If the signal is low, it is transmitted at low power; otherwise, it is transmitted at high power. This not only saves energy but also reduces unnecessary long-distance interference and improves the overall performance of the protocol.

[0085] The receiving node Y sends an ACK to acknowledge each successfully received data frame. The ACK uses an immediate response strategy, meaning that an ACK is sent immediately after each received and verified frame (in frame train scenarios, ACKs can be inserted between frames). Due to half-duplex limitations, Y cannot receive the next data frame while sending an ACK; therefore, in frame train mode, the ACK is generally delayed or X waits for the ACK before resuming transmission. To avoid complexity, this example uses a frame-by-frame stop-and-wait approach: X sends a frame, waits for an ACK, and then sends the next frame upon receiving the ACK. This degenerates into conventional frame-by-frame transmission but offers high reliability. Another approach is for Y to buffer multiple frames and then send ACKs in batches; in this case, X needs a window mechanism to control the number of frames sent. Regardless of the ACK strategy, ACKs themselves can collide or be lost, especially in concurrent transmission scenarios.

[0086] To enhance the reliable delivery of ACKs, ACK frames are typically designed to be very short and sent redundantly (e.g., retransmitted twice). Neighboring nodes, upon hearing the ACK, also update their respective states: the ACK indicates the end of a communication, and the NAV previously set for that communication can be cleared or the waiting time reduced. If the source node X does not receive an ACK within the timeout period, it is presumed that the frame is lost. X then marks the frame as pending retransmission and initiates the retransmission process. The retransmission process is essentially the same as the initial transmission, but may use a doubling backoff exponent strategy to avoid repeated collisions: for example, waiting for a random backoff before the first retransmission, waiting even longer if the second retransmission also fails, and potentially increasing transmission power or abandoning the transmission if it fails again. This invention minimizes the retransmission requirement by reducing the initial collision probability, while still achieving the standard ARQ retransmission guarantee of reliable delivery.

[0087] It is worth noting that if ACK collisions are caused by concurrent communication (which may occur in very rare cases, such as when two receiving nodes simultaneously send ACKs back to their respective sending nodes, and the two ACKs meet and interfere at some point in between), this method does not take special measures to avoid ACK collisions due to the short ACK length and narrow collision window. This is partly because the probability is extremely low, and partly because the source node will retransmit the data frame after a timeout following an ACK collision, which can compensate for this. However, some possible improvements include using different frequencies or code patterns to send ACKs to differentiate them, or having ACKs also follow carrier sense to avoid simultaneous transmission, but these increase protocol complexity and will not be discussed further here.

[0088] This invention cleverly utilizes the seemingly negative characteristic of long latency to improve concurrency: long latency means that the signal takes a long time to propagate in space, and this time is actually idle and available for unrelated nodes.

[0089] The existence of a delay mapping database enables nodes to grasp the "time map" of signal propagation in the network, thus seizing the opportunity to send their own signals before other signals arrive at a certain point, achieving peak-shifting transmission.

[0090] For example, if nodes A and C are far apart, the signal sent by A to B will take 1 second to reach B. During this 1 second, C can send data to D, as long as it is ensured that the C->D signal arrives at B at a time that avoids the critical period when B is receiving A->B.

[0091] This interleaved communication is achieved through delay mapping prediction.

[0092] To ensure that the delay mapping remains accurate, each node continuously uses side effect information for correction during daily communication.

[0093] For example, with each successful data transmission, source node X can calculate the precise propagation delay between itself and Y from the round-trip time of the ACK and update its database. Another example is when a node detects a collision or failure in communication with a neighbor; by analyzing the time difference, it may infer new information about distance relationships (such as who collided, indicating they are close to the receiver). All this implicit information is used to improve the understanding of the network topology. This invention fully leverages these side effects, making the system increasingly "intelligent": the more communication, the more accurate the delay estimation, and the more efficient the scheduling.

[0094] The working process of the method of the present invention will be illustrated below through a specific scenario.

[0095] like Figure 1 As shown, consider nodes A, B, C, and D in the network, with the following distance relationships: AB is 1 km apart (propagation delay ≈ 0.67 s), AC is 2 km apart (≈ 1.33 s), BC is approximately 1.2 km apart (≈ 0.8 s), AD is relatively close (approximately 0.5 km, ≈ 0.33 s), and BD is approximately 1.5 km apart (≈ 1 s). Assume the initial delay mapping database is as follows:

[0096] [Record A: B (0.67 s), C (1.33 s), D (0.33 s);]

[0097] Record B: A (0.67 s), C (0.80 s), D (1.0 s);

[0098] Record C: A (1.33 s), B (0.80 s), D (??) (Assuming C has not yet communicated with D, there is no direct record);

[0099] Record D: A (0.33 s), B (1.0 s), C (??);

[0100] Now, node A has data to send to node B; at the same time, node C also has data to send to node D; the two pairs of communication requests are generated almost simultaneously.

[0101] According to the method of the present invention:

[0102] Step 1: Pre-send assessment.

[0103] A prepares to send a message to B. Checking the delay table, A finds that its neighbor C has no communication records with B in the past second (although C and B are 0.8 s apart, C is unaware that C is about to communicate). A detects that the channel is idle and predicts that B is not occupied by others, so it decides to send an RTS (Redirect Time Request) to B. Almost simultaneously, C prepares to send a message to D. C checks its table and finds that A and B are 1.33 s apart and there is likely no recent communication (assuming C is unaware that A is about to send a message). C also detects that the channel is idle and decides to send an RTS to D.

[0104] Step 2: RTS Send.

[0105] Nodes A and C send RTS messages almost simultaneously: A->B and C->D. Between A and C, due to the distance, they may not be able to hear each other's RTS messages (assuming this is the case). B and D each receive their own RTS requests. Regarding neighbors, B's neighbors are A and C; C's neighbors are A, B, and D. Node B currently only receives A's RTS message. It might vaguely hear C->D's RTS message, but C->D is far from B, so the signal might be weak or even not reach B, which we will ignore for now. Node D's neighbors A and B may be too far away to hear C->D's RTS message. In summary, both RTS messages successfully reach their respective destinations essentially independently.

[0106] Step 3: CTS response.

[0107] B receives A's RTS, and D receives C's RTS. Assume A's data is larger, with a transmission request duration of 2 seconds; C's data is smaller, with a transmission request duration of 1 second. This information is contained in their respective RTSs. After processing, B and D prepare to send a CTS almost simultaneously. At this point, B might be closer to C (BC 0.8 s), and the C->D RTS will reach B after 0.8 seconds of propagation through the air. However, B will need to send its CTS after processing A's RTS in 0.5 seconds, while the C->D RTS hasn't reached B yet (because the CD path doesn't pass through B, B will never receive the C->D RTS). Therefore, B is unaware that C is communicating and will directly send its CTS to A. D similarly sends its CTS to C. Now the handshake situation is: A <-> B handshake, C <-> D handshake, the two pairs are far apart, and their CTSs do not interfere with each other. Regarding neighbors: Whose CTS can A hear? A is too far from C to hear D's CTS; C also cannot hear B's CTS. B and D also cannot hear each other's CTS. Therefore, both pairs of CTS were successfully received by their respective sources.

[0108] Step 4: Concurrent data transmission.

[0109] A receives CTS and prepares to send 2 seconds of data to B; C receives CTS and prepares to send 1 second of data to D. According to the delay mapping, A knows that the propagation of C->D may not affect it because D is relatively far from A (AD 0.33 s, relatively close but AD communication hasn't occurred, mainly depending on CD). A doesn't detect strong nearby interference, so it starts sending data. C also starts sending. Now, two data streams propagate in space: A->B data and C->D data. At some point, these two signals may meet or cross. However, as long as they don't meet at the same receiving node, there is no collision. In our distance setting, B is 0.8 s from C. Therefore, when C->D data propagates past B, is B receiving A's data? The A->B signal takes 0.67 s to reach B, and the C->D signal takes approximately CB 0.8 s to pass near B, slightly later than A->B. However, B receives A's data for 2 seconds, and B is busy when C->D passes by, so B may hear some C->D energy, which could become interference. There is a potential conflict here: when the C->D signal passes through B, B is receiving data from A, which will cause some interference. This situation should be avoided according to the scheduling principles of this invention—meaning we should have considered CD communication when predicting before A's transmission. However, since we assumed A and C initiated simultaneously, unaware of each other, the prediction did not cover this cross-regional situation. This collision belongs to the residual hidden node conflict. Fortunately, if the signal strengths differ significantly, B may still successfully receive A's data, only with a slight increase in bit errors. Assuming the A->B signal is stronger than the interference leaked to B from C->D, B will eventually correctly receive most of A's data frames. On the D side, D is far from A (1.0 s), and when the A->B signal passes through D, D is also receiving C's data, which may also cause interference. However, since AD ​​is only 0.33 s, the A signal passes quickly, and the impact is minimal.

[0110] Step 5: ACK and retransmission.

[0111] B receives 2 seconds of data, and D receives 1 second of data; each then sends an ACK. The ACKs do not conflict because B and D are 1.0 s apart and their transmission times are staggered (B waits 2 seconds before sending an ACK, and D waits 1 second before sending an ACK; the ACK times are different). A receives the ACK, confirming the successful transmission of the 2 seconds of data. C waits for an ACK after the 1 second of data, but assuming D's ACK is lost, C times out and retransmits. After backing off, C retransmits the remaining data, completing the process quickly. Throughout this process, AB and CD essentially achieve parallel communication, transmitting their respective data in approximately 2 seconds. If completed serially, it would take more than 3 seconds (2 seconds for AB, then 1 second for CD), so concurrency saves the network one second.

[0112] The above example also exposes a potential problem: although the source and destination of AB and CD communications are far apart, there is cross-interference near the intermediate node B. To avoid this, this invention introduces more protections in practical applications, such as requiring the source node to provide broader collision domain information in the RTS, so that nodes two hops away are also aware of it. However, this involves more complex network coordination, which is not the focus of this invention. The basic mechanism of this invention has significantly reduced the collision probability through delay mapping and time calculation; the remaining few unavoidable interferences can be resolved through upper-layer error correction and retransmission.

[0113] The collision avoidance method of the present invention achieves the effect of improving performance through the above mechanism:

[0114] Because it allows for parallel transmission under non-interference conditions, network throughput increases linearly with the number of nodes, breaking the bottleneck of traditional MAC throughput being limited by single-channel exclusivity. Under high load conditions, this method can significantly increase the amount of data successfully transmitted per unit time compared to standard RTS / CTS.

[0115] By reducing unnecessary waiting and backoff, this method does not significantly increase single-hop latency under low to medium loads. Although nodes may engage in some predictive waiting under high loads to avoid collisions, this waiting is mostly consistent with propagation delays and does not introduce additional latency greater than the delay itself. On the contrary, the average end-to-end latency may decrease due to the reduced completion time of concurrent transmissions and lower network queue congestion. Latency jitter is also smoother due to reduced collisions.

[0116] The mitigation of the exposed node problem allows nodes at different distances to have a more equitable opportunity to access the channel. This method does not favor nearby or distant nodes, but rather decides to send based on the real-time environment, providing on-demand throughput guarantees for each node. At the same time, the backoff algorithm still ensures that multiple competitors can share channel resources equally in the long run, and that other nodes will not be starved due to frequent concurrency of some nodes.

[0117] The additional overhead of delay mapping maintenance and computation is minimal. Delay mapping measurements rely on normal RTS / CTS interactions and simple probe packets, requiring no dedicated control signaling. Computationally, each decision involves adding or subtracting several neighbors, which can be completed in microseconds on modern microprocessors, far smaller than the millisecond timescale of underwater acoustic communication. In terms of memory usage, each neighbor only needs to store a floating-point delay and timestamp, which is not a problem for typical sensor nodes.

[0118] This method can adapt to dynamic changes in topology and traffic; when new communication opportunities arise, nodes can seize the opportunity in real time through prediction and send concurrently; when the risk of collision increases, it can also back off in time to avoid avalanche collisions. Therefore, it exhibits excellent stability over a wide range from low to high load; at the same time, it does not require network-wide time synchronization (unlike time-slot schemes that require network-wide clock alignment), nor does it require complex centralized scheduling. It operates in a fully distributed manner, making it suitable for underwater environments where centralized control is difficult.

[0119] It's important to note that when the network is first established, the latency mapping database may be empty or inaccurate. This can be addressed by a short learning period to populate the data. For example, in the first few minutes after deployment, nodes frequently handshake by sending small data packets to acquire latency information from their neighbors. Once the map is formed, normal data transmission begins. This learning period strategy can be controlled by the upper layer or automatically initiated by the MAC layer upon detecting mapping holes. Collisions during this period may be slightly higher, but this is a one-time cost.

[0120] If a new node joins the network, it may cause collisions because it has no latency information before it starts communicating. To mitigate this risk, a new node can passively listen to the network for a period of time to collect some latency information before initiating communication. In addition, when existing nodes detect a new node's signal, they should also include it in the mapping and broadcast some of their own neighbor information to help it integrate.

[0121] It should be noted that the algorithm mentions things like the upper limit of the backoff time. Record validity period, competition arbitration pending These parameters need to be selected based on network size and application requirements. Generally, an estimate of the maximum two-hop propagation delay of the network can be used, such as if the network diameter is 5 km. The validity period depends on the node's movement speed and tolerance error; if a node moves at 1 m per second, it can move 600 m in ten minutes, corresponding to a 0.4 s delay, and the validity period can be set to update every 5-10 minutes; arbitration waiting. It should be slightly greater than the propagation delay jitter and processing time, for example, 0.1~0.2 s, to prevent CTS response collisions; all of the above parameters can be obtained through simulation or empirical tuning.

[0122] This invention operates at the MAC layer and interacts with the ARQ of the transport layer and the data generation of the application layer. Ideally, the upper layer should be aware that the MAC layer allows for a large throughput and can adjust the sending window accordingly. There is no need to worry about random long delays, because the MAC layer has minimized the unpredictable delays caused by collisions. For a small amount of high-priority data that requires strict real-time performance, the concurrency mechanism can be bypassed to force immediate transmission (this method supports direct data transmission but does not guarantee no collisions). In this case, the upper layer should be fault-tolerant.

[0123] Before deploying this protocol in actual underwater applications, its performance should be fully evaluated through simulations under various scenarios, including different node densities, service models (burst or periodic), mobility modes, and channel conditions (bit errors, noise). Parameters should be calibrated and theoretical analyses verified through simulations. For example, network simulators such as NS-3 can be used to construct underwater acoustic channel models and implement this protocol, observing the changes in throughput, latency, and collision rate with load, and comparing them with classic MAC protocols to quantify the improvement effect of this invention. In addition, pool or lake tests are also necessary to verify the protocol's operation under real channels using actual acoustic modems. In particular, the accuracy of delay mapping and the reliability of concurrent scheduling in multipath and noisy environments should be tested, and algorithm details (such as decision thresholds) should be adjusted accordingly.

[0124] In summary, the collision avoidance method for digital underwater acoustic communication proposed in this invention overcomes the performance bottleneck of traditional protocols in long-latency, high-concurrency environments by introducing propagation delay sensing and scheduling algorithms at the MAC layer. It utilizes the inherent long latency characteristics of underwater acoustic communication to achieve collision-free parallel transmission between different communication pairs, significantly improving network throughput and efficiency. Simultaneously, the precise collision prevention mechanism ensures high reliability and low retransmission rate of data transmission, improving the network's quality of service. This method is simple to implement, requires low computational and storage overhead, and is suitable for underwater wireless networks of various sizes. Through the above detailed description, those skilled in the art should be able to fully understand and implement this invention. Various equivalent substitutions and modifications can be made to the specific implementation without departing from the principles of this invention; the scope of protection of this invention is defined by the appended claims.

Claims

1. A collision avoidance method suitable for digital underwater acoustic communication, characterized in that, Includes the following steps: 1) Establish a delay mapping database: Nodes calculate and maintain a "neighbor identifier - propagation delay" mapping by probing signals and listening to the arrival times of RTS / CTS / ACK frames of their neighbors; 2) Channel monitoring and prediction: When the source node has data to send, it first detects the channel energy and combines it with the mapping database to predict the channel occupancy in the short term; if there is no risk of collision, it continues; otherwise, it randomly backs off and retryes. 3) RTS transmission and protection: After predicting that it can be transmitted, an RTS frame is sent. The system continuously listens before and after transmission. If a neighbor's CTS or ACK is detected to be arriving, the RTS is paused and retransmitted after the end of the frame and the protection interval. 4) CTS Response: When the target node receives the RTS and the channel is idle, it sends a CTS containing the permitted time slot and duration information after a preset delay; if busy, it delays the response. 5) Neighbor concurrency judgment: After non-neighbor nodes listen to RTS / CTS, they determine whether there is interference based on their propagation delay to the source / target and the CTS / Data time slot window. If there is no interference, they send concurrently; otherwise, they remain silent. 6) Data transmission: The source node transmits data frames or continuous data sequences (frame train) within the time slots permitted by CTS, and monitors for potential collisions during transmission, pausing if necessary; 7) ACK confirmation and retransmission: After the target node successfully receives the data, it sends an ACK. If the source node does not receive the ACK within the timeout period, it will randomly back off and retransmit. 8) Database update: After communication ends, each node updates the mapping database according to the actual arrival time and frame results to reflect the latest topology and channel conditions.

2. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, In step 1, the propagation delay is calculated by recording the arrival time difference between neighboring RTS and CTS frames, and multiple delay samples are stored to enhance the mapping accuracy.

3. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, The channel occupancy prediction in step 2 also takes into account the duration of the neighbor's last data transmission to avoid overlap with the current transmission window.

4. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, After pausing RTS in step 3, the source node retransmits RTS according to the corresponding neighbor delay in the mapping database plus a guard interval ΔT to prevent new collisions from occurring immediately afterward.

5. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, In step 4, the CTS frame contains the allowed start time slot number and the maximum duration, which are used to precisely constrain subsequent data transmission.

6. The collision avoidance method for digital underwater acoustic communication according to claim 4, characterized in that, In step 5, the neighbor concurrency judgment is based on three-dimensional spatial coordinates and delay mapping, combined with the node position relationship to determine whether there is a time or space conflict.

7. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, In step 6, multiple frames are continuously sent using a frame train method. The receiving node can send an ACK for each frame individually or send a cumulative ACK at the end of the sequence.

8. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, When no neighboring nodes detect a signal and the channel remains silent for an extended period, the source node can skip RTS / CTS and send data directly to reduce handshake latency.

9. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, When nodes move or the network size changes, the weight of expired delay records in the mapping database is reduced or deleted to prevent prediction errors caused by expired information.

10. The collision avoidance method for digital underwater acoustic communication according to claim 1, characterized in that, Each node periodically uses external temperature, depth, or sound speed detection information to calibrate the propagation delay recorded in the mapping database to adapt to changes in sound speed caused by environmental factors.

Images