（用

0x02 表示）和 ACK 信号（用 0x03 表示）。目的节点指的是要向哪个节点发送数据：A

节点（用

0x00 表示），B 节点（用 0x01 表示）C 节点（用 0x02 表示）。源节点指的是数据

来自于哪个节点：

A 节点（用 0x00 表示），B 节点（用 0x01 表示）和 C 节点（用 0x02 表

示）。待发送数据就是实际要发送的数据，这里的字节位数因实际数据的长度而定。

 

　　通过以上的定义，不管哪个节点收到了数据，都可以通过判断数据帧的前六位知道，
该数据是什么类型的，由哪个节点发出的，是发给谁的。那么该节点就可以知道应该给哪个
节点回复什么类型的数据，以及通过对收到数据的源节点个数来判断当前信道是否冲突。本
文处理信道冲突的方法是，让发送数据的节点退避等待一段随机的时间，再次请求通信。以
A 节点收到数据是否为 RTS 信号为例，其程序设计流程如图 2 所示。 
　　同样的，判断数据是否为

CTS 信号或 DATA 数据其设计思想也是如此。 

　　对于收到的数据是

ACK 信号时，对数据类型，目的节点的判断与前面的程序流程一样，

而对源节点的处理采用的方式是，判断数据是不是由

B 节点发送的 ACK 信号，如果是，

判断当前有没有

C 节点与之请求信道的信号，即 C_RTS 信号是否为真，如果有，说明信道

有冲突，之前对

B 节点发送的数据可能出现错误。造成这种结果的原因是，在 B 节点接收

A 节点的数据的时候，C 节点对 A 节点发送的 RTS 信号同时也被 B 节点收到，那么 B 节点
实际收到的数据就是两个节点发送数据和信号的叠加。

A 节点就需要重新对 B 节点发送数据，

同时暂时拒绝与

C 节点的通信。如果当前没有 C 节点的请求信道信号，说明信道没有冲突，

将冲突标志位置假，并反馈给

B 节点，告诉 B 节点数据接收完毕。 

　　对收到

ACK 信号的处理程序设计流程如图 3 所示。 

　　

3.2 水下通信网络节点三节点发送数据程序设计 

　　对于发送数据节点，其数据类型也是

RTS 信号，CTS 信号，数据信号和 ACK 信号。在

发送这些信号和数据前，都需要对当前的信道进行判断，是否信道冲突。本文的程序中是用
冲突标志位（

m_bCollision）值的真假来判断的，若为真，表示信道冲突，若为假，则表示

信道空闲。当信道空闲和发送冲突之后，该节点需要对这两种情况进行相应的处理，来延续
后续的通信。以下以节点发送

RTS 信号为例来介绍其具体的设计过程。 　　在发送 RTS 信

号之前，首先判断冲突标志位是否为真，如果是，则随机等待一段时间，并启动退避变量
（程序中为

RTSWait_i），直到冲突标志位值为假。每随机等待一段时间，RTSWait_i 自加

1，当退避次数大于 3，冲突标志位仍未真，则放弃本次通信，随机延时一段时间，重新准
备发送

RTS 信号。如果首先判断的冲突标志为假，则表示信道空闲，发送 RTS 信号，同时

启动定时器等待

CTS 信号的来临，如果等待时间超过了规定的时间（这个时间值因具体的

水下通信环境而定

——信号的传播速度和节点之间的距离等），认定当前信道冲突，对信

道标志位重新判断，若为假，重新发送

RTS 信号。每一次重新发送 RTS 信号都会用一个变

量来计量重发的次数，如果次数超过

3 次，则放弃重发，随机延时一段时间，重新准备通

信请求。其设计的程序流程如图

4 所示。同样，对于发送 CTS 信号和 DATA 数据也是如此。 

　　对于发送

ACK 信号，是在数据已经准确接收完之后，回复给发送节点的信息，所以节

点发送

ACK 信号主要考虑的是在回复信息的时候，判断信道是否空闲，如果空闲，就可以

发送

ACK 信号，如果冲突，随机等待一段时间等待信道空闲，并同时进行退避操作，用退

避变量记录退避次数，当退避次数小于

3 次时，信道空闲了就可以直接发送 ACK 信号，当

退避次数大于

3 次，信道仍冲突，就继续等待。 

　　

4.水下通信网络节点三节点网络协议实验实现 

　　按照以上的设计思路，用

A 节点向 B 和 C 节点发送 RTS 信号，进行通信调试，其具体

调试过程和实验结果：

 

　　将编写好的带有通信协议的服务器程序下载到

A 节点 ARM 中启动，分别用两台 PC 机

模拟

B 节点和 C 节点，将编写好的带有通信协议的客户端程序在 B，C 节点中启动，与 A