基于规则与感知的水声网络MAC 协议

李冲，杜秀娟,3,4，王丽娟，田晓静

（1.青海师范大学计算机学院，青海 西宁 810008；2.青海师范大学青海省物联网重点实验室，青海 西宁 810008；3.藏语智能信息处理及应用国家重点实验室，青海 西宁 810008；4.高原科学与可持续发展研究院，青海 西宁 810008）

0 引言

媒体访问控制（MAC,medium access control）协议、路由协议及物理层技术是水声网络（UAN,underwater acoustic network）的关键技术。MAC 协议用于网络节点分配信道资源，是UAN 可靠传输及通信的关键协议[1-4]。受水下环境影响，UAN 采用声波通信，然而水声通信为MAC 协议的设计带来一系列的问题，如时空变特性、能量受限、低带宽等[5-8]。针对UAN的特性，研究人员提出了大量的用于水下的MAC 协议，这些协议可分为3 种类型：基于竞争的MAC 协议、无竞争的MAC 协议和混合MAC 协议[9-13]。

无竞争的MAC 协议通常将信道按照时间、频率或扩频码进行划分，将信道分割成互不干扰的子信道分配给不同的节点。根据子信道划分原则，无竞争的MAC 协议分为时分多址（TDMA,time division multiple access）协议、频分多址（FDMA,frequency division multiple access）协议和码分多址（CDMA,code division multiple access）协议。水声信道的窄频带特性使基于FDMA的MAC 协议并不适用于UAN。TDMA 要求节点的时钟精确同步，这对于UAN 来说是个难题。UAN的远近效应给基于CDMA的MAC 协议在UAN的应用带来很大的挑战。

在基于竞争的MAC 协议中，文献[14]提出了第一个随机访问的Aloha 水下MAC 协议。Aloha协议在处理数据时，不关注节点状态，而是直接发送，因此容易造成冲突。文献[15]提出的Slotted FAMA 协议将载波侦听与RTS/CTS（request to send/clear to send）进行结合，通过划分时隙，并规定所有报文在时隙开始时发送，来避免冲突，在一定程度上提高了能量效率，但时钟的精确同步对UAN 本就是个难题；较长的时隙和只能在时隙开始时发送的机制浪费了UAN原本就有限的带宽资源，降低了信道利用率。文献[16]提出的R-MAC 协议采用基于预约的方式，避免了在水下采用握手机制的RTS/CTS 报文过长的问题，也避免了包碰撞问题。然而，ND、ACK-ND 和SYN 报文增加了R-MAC协议的控制开销，并且R-MAC 冲突避免机制较复杂，受节点运动影响，传播时延的估计误差较大，因此只适用于静态网络或节点移动较慢的场景，且仍存在公平性问题。

当前基于竞争的媒体访问控制协议多采用RTS/CTS 握手的传输控制机制。在UAN 中，优化的数据包长度为100～200 B，而RTS/CTS 控制包的长度为几十字节。与优化的数据包长度相比，RTS/CTS 帧的长度不能忽略[17]。使用RTS/CTS 握手机制不会带来更好的收益，而且考虑到水声信道带宽低、时延长等特性，使用RTS/CTS 握手反而降低了信道的利用率，从而降低了网络吞吐量，增加了端到端时延[18]。因此，本文提出基于规则与感知的水声网络 MAC（RP-MAC,rule and perception-based MAC）协议，避免了RTS/CTS 握手在低带宽、长时延的UAN 导致的信道利用率低下问题，在避免冲突的同时提高了网络吞吐量。

RP-MAC 协议通过信道访问规则在信道公平争用和传输效率最大化之间进行了较好的折中。此外，节点在传输数据帧之前需要查看邻居表中所有邻居节点的状态信息。如果接收节点状态为忙（发送状态或接收状态），则当前节点推迟发送。如果接收节点状态为闲（非发非收），但其他邻居节点正处于接收状态，为了不干扰邻居节点，当前节点也会推迟其发送。因此，使用该信道规则控制节点的传输能够在不交换握手报文的前提下实现冲突避免，从而提高信道利用率，这对长传播时延和带宽资源受限的UAN 尤其重要。

1 RP-MAC 协议机制

1.1 系统模型

将UAN的拓扑模拟为一个无向图G=(N,A)，N为网络中节点的集合，A为网络中可用链路集合。可用链路指传输质量Cij大于预定义阈值Cthr的链路，即Cij表示在排除干扰的情况下节点nodei与节点nodej之间链路上的平均交付率，它与发送功率、信号衰减、编码方式等因素有关。对于UAN 中的节点而言，常见的状态有接收、发送、空闲。假设在时隙slotn，节点nodei通过链路(i,j)向邻居节点nodej发送一帧，该帧被成功传输的概率Pij为

其中，Ps表示节点传输数据时不发生冲突的概率；s(n) 表示目的节点在时隙slotn是否处于可用状态，即空闲状态或接收状态，s(n)=0 表示节点不是可用状态，s(n)=1 表示节点处于可用状态。

根据UAN 信道传输特性，本文定义信道上的交付能力ΡiJ为在时隙slotn节点nodei发送广播报文被邻居节点成功接收的概率。ΡiJ计算式为

其中，W为nodei的邻居节点集合，W⊂A。在此基础上，本文计算了信道上单位时间内nodei向邻居节点成功传输的数据量RiJ，用于反映信道中端到端的吞吐量，如式(3)所示。

其中，l表示帧长度，m表示slotn时隙内nodei发送的帧数。

1.2 信道访问规则

在RP-MAC 协议中，为避免冲突，减少重传，同时考虑到传输效率和信道占用的公平性，RP-MAC 协议基于以下规则实施信道访问控制。

1) 节点在一个数据传输阶段中最多允许传输N个数据包，从而避免了信道被一个节点长时间占用。

2) 同一个节点的两次数据传输的退避时间为Ta。考虑到水声调制解调器状态转换的时延较大，退避时间Ta应足够长，通常设置退避时间Ta=2RTT，RTT 为数据包的最大往返时延。

3) 较大的数据被切分为多个块，每个数据块又包含多个数据帧，RP-MAC 会对每个数据块中的数据帧编序，并按序号顺序传输。

4) 为了避免干扰邻居节点的接收，当前节点的邻居节点已处于接收状态时，当前节点不能发送帧。

5) 为了避免干扰指定的接收节点，当指定的接收节点处于发送状态或接收状态时，发送节点不能发送帧。

1.3 节点状态感知

在网络初始化阶段完成后，每个节点都维护着一张邻居节点状态表，记录了邻居节点ID 及其状态信息，如表1 所示。

表1 邻居节点状态

表1 中，状态“0”表示节点处于发送状态，状态“1”表示节点处于接收状态，状态“2”表示节点处于未知或空闲状态，状态“3”表示节点处于发送避免状态。

为了避免冲突，RP-MAC 协议的信道访问规则规定了节点只有满足一定的条件时才尝试发送一组帧链，即当邻居表中的所有邻居节点都不处于接收（其他节点数据）状态，且接收节点也不处于发送状态时，当前节点才可以尝试发送。节点感知其邻居节点实时状态的方法如下。

在RP-MAC 协议中，节点“侦听”信道中传输的帧（数据帧或确认帧），根据帧的头部字段信息，进一步结合信道访问规则中的1)～3)来判断发出该帧的邻居节点的状态，从而更新邻居表中该邻居节点的状态。

为了详述节点是如何根据侦听到的XDATA或XACK 帧头信息判断来源节点的状态，这里给出RP-MAC 协议采用的数据帧格式，如表2所示。帧类型字段用于标识该帧的类型，“00”表示数据帧，“01”表示确认（ACK,acknowledgement）帧。RP-MAC 协议的确认帧用于向发送节点确认收到了一组帧中的第一帧或最后一帧。帧序列号用于标记该帧在这组帧链中的顺序。立即确认字段在数据帧中用于通知接收节点是否需要立即回复ACK 帧；在ACK 帧中用于接收节点向发送节点通告是否解码成功，“1”表示立即回复或解码失败，“0”表示不回复或解码成功。

表2 数据帧格式

节点侦听信道中传输的帧，根据帧首字段中帧类型（数据帧还是ACK 帧）、帧序列号、发送节点ID、接收节点ID，进一步基于前述的信道访问规则感知邻居节点的实时状态。例如，当节点侦听到含有如表3 所示的首部字段的帧时，结合“立即确认字段，在数据帧中用于通知接收节点是否需要立即回复ACK 帧”这一规则，可以判断出节点A 正在向节点B 发送帧序号为6、立即确认字段为“0”的数据帧，，在本次传输阶段还会陆续发送帧序号为5 到帧序号为1的5 个数据帧，因此，节点感知到邻居节点A的实时状态为发送，而节点B的状态为接收。

表3 数据帧

节点通过侦听感知邻居节点状态的算法如算法1 所示。

算法1节点状态感知算法

1.4 传输控制

RP-MAC 协议不需要RTS/CTS 握手机制。当节点需要传输数据帧时，首先在邻居状态表中查找接收节点和其他邻居节点的状态信息。为了避免在接收节点处的冲突，当接收节点处于状态“0”或状态“1”时，表明接收节点正在与其他节点通信，则发送节点推迟发送，继续侦听信道。为了避免干扰其他邻居节点的接收，当其他邻居节点处于状态“1”（正在接收其他节点的帧）时，当前节点也会推迟发送。只有当接收节点的状态为“发送避免”或“未知或空闲”，且其他邻居节点不在“接收状态”时，发送节点才会向接收节点尝试发送一个数据帧。当发送的第一帧收到确认后，发送节点才会继续按序发送帧链剩余的帧。接收节点对接收到的完整帧链回复一个立即确认字段为“0”的ACK 帧。RP-MAC 协议的整体流程如图1 所示。

图1 RP-MAC 协议的整体流程

为保证协议传输的可靠性，发送节点会对传输的数据帧链进行编码，接收节点需对接收到的数据帧进行解码。若接收节点成功解码，则向发送节点回复一个立即确认字段为“0”的ACK 帧；若接收节点未成功解码，则向发送节点回复立即确认字段为“1”的ACK帧，并将帧链中未解码帧的ID 通告发送节点，发送节点对未成功解码的数据重新编码后进行重传。

RP-MAC 协议是一种无RTS/CTS 握手的MAC 协议，虽然摒弃了RTS/CTS 握手机制，但保留了ACK帧，这样既避免了RTS/CTS 握手机制带来的降低信道利用率、增加网络开销的问题，又保证了数据的可靠传输，增加了网络的吞吐量。此外，与随机访问MAC协议不同，RP-MAC 协议在有数据发送时，会首先判断邻居节点状态，当邻居节点状态正确时，才会发送数据，这样既避免了随机访问带来的冲突严重的问题，又保留了随机访问MAC 协议随来随发的特性。

2 网络性能分析

2.1 信道利用率分析

本节将RP-MAC 协议与基于时隙的采用包链机制的Slotted FAMA 协议在信道利用率方面进行对比分析。为了便于分析，假设网络拓扑为正六边形结构，如图2 所示。位于拓扑中心的节点ω 共有N个邻居节点，而每个邻居节点又有Q个相对ω 节点为隐藏节点的邻居节点。网络中节点数据产生的概率服从泊松分布，平均每发送一个数据包。这些数据包以的概率发送给一个给定的邻居节点，因此，每个邻居节点接收数据的速率为

图2 网络拓扑

使用上述模型，节点的信道利用率可表示为传输有效数据占用信道的时间与总时间之比，如式(4)所示。

在文献[17]中，水声网络经负载优化后包负载长度为100～200 B，因此，在仿真与试验床测试时，每帧的长度设置为200 B，水声通信设备的数据率为5 kbit/s，节点传输范围为1 500 m，则传输长度为Lpacket的帧的传输时延Tduar可表示为

其中，Lpacket为包长度，R为数据率。按以上设置，每帧传输时延约为0.32 s。水声通信的速度约为1 500 m/s，按照1 500 m的传输范围计算，需要的传播时延约为1 s。可见帧的传输时延小于传播时延。

假设UAN 中的误码率为Pb，那么长度为lbit的数据包的错误率Pp为

在Slotted FAMA 协议中，节点ω 在信道上传输成功的概率定义为Ps-SF，即当拓扑中的节点ω 在时隙n发送RTS 时，ω的所有邻居节点都不传输的概率。在Slotted FAMA 协议中，邻居节点不传输是指在时隙n邻居节点既不发送RTS，也不发送CTS，其中，不发送CTS的情况等同于节点ω的隐藏节点在n-1 时隙不发送RTS的情况。因此，在Slotted FAMA 协议中，节点ω 传输成功的概率Ps-SF为

在RP-MAC 协议中，节点ω 在信道上传输成功的概率用Ps-RP表示，即当指定的接收节点状态为“未知”或“发送避免”时，指定接收节点在接收来自节点ω的帧的持续时间Tduar内，其他邻居节点不向接收节点发送数据的概率，并且指定接收节点在Tduar时间内没有帧产生的概率。根据RP-MAC 协议的规则，概率Ps-RP为

在式(7)和式(8)中，Tslot＞Tduar，且N+Q＞ 2。因此，Ps-RP＞Ps-SF。RP-MAC 协议中，节点ω 在信道上传输成功的概率远大于Slotted FAMA 协议中节点ω的传输成功概率。

Slotted FAMA 中，数据传输成功需要的时间为RTS、CTS、DATA（包括所有的重传）及ACK 成功传输所用的时间之和。其中，RTS、CTS 及ACK的传输各需一个时隙。数据传输需要的传输时延用Tdata表示。定义Tval为节点开始传输数据到成功接收ACK 所用的时间，即传输有效数据占用信道的时间，如式(9)所示。

Slotted FAMA 中，一次成功传输需要的总时间可表示为Ttol-S，即

其中，2Tslot为RTS/CTS 握手需要的时间开销。

RP-MAC 中，一次成功传输需要的总时间可表示为Ttol-R，即

其中，TACK为第一个ACK的传播时延加传输时延，TACK＜Tslot。

在式(10)中，对于 Slotted FAMA 协议，Tsuccess=Ttol-S；对于RP-MAC 协议，Tsuccess=Ttol-R。

在Slotted FAMA 协议中，信道冲突包含节点ω之外的其他邻居节点在时隙n发送RTS 和CTS的2 种情况，当节点ω 发送的RTS 帧与其他节点的控制帧冲突时，冲突时间包括当前时隙以及下个等待接收CTS的时隙，因此，Slotted FAMA 协议中节点ω的冲突时间Tfail-SF为

RP-MAC 协议中，信道冲突时间包含发送第一帧数据的传播与传输时延和等待不会被回应的ACK的时间，既然这里的传播时延远大于传输时延，RP-MAC节点 ω的冲突时间Tfail-RP可近似表示为

由于TACK＜Tslot，故RP-MAC 协议的冲突时间Tfail-RP小于Slotted FAMA 协议中的冲突时间Tfail-SF。当节点ω 侦听到信道中存在冲突或侦听到发送给邻居节点的CTS 时，节点ω 会进入退避状态。Slotted FAMA 协议节点ω的平均退避时间Tdefer为

对于RP-MAC 协议，当节点没有收到目的邻居节点对第一帧或最后一帧的ACK 时，节点会进行退避。节点接收到发送给目的邻居节点的第一帧ACK的概率

节点收到目的邻居节点最后一帧ACK的概率为

此时，退避时间为2Tslot。

因此，RP-MAC 协议节点退避时间Tdefer为

无论是Slotted FAMA 协议还是RP-MAC 协议，信道闲置的平均时间为

综合以上计算式，可以得出Slotted FAMA 协议的信道利用率SSF为式(21)，RP-MAC 协议的信道利用率SRP为式(22)。

由式(6)和式(7)可知，RP-MAC 协议不发生冲突的概率大于Slotted FAMA 协议。

由式(12)～式(20)可知，RP-MAC 协议传输无效数据的时间小于Slotted FAMA 协议传输无效数据的时间。由式(4)可知，当传输有效数据的平均时间越大、传输无效数据的时间越小时，节点的信道利用率越大，因此，RP-MAC 协议的信道利用率SRP明显大于Slotted FAMA 协议的信道利用率SSF。

2.2 RP-MAC 协议其他性能分析

2.2.1RP-MAC 协议避免隐藏终端问题

隐藏终端是指那些位于接收节点的传输半径内，却在发送节点传输半径之外的节点，由于接收不到发送节点发送的帧，因此采用载波侦听机制的隐藏终端可能会同时向同一接收节点发送帧，从而在接收节点处造成干扰和冲突，降低信道利用率，如图3 所示。

图3 隐藏终端

在图3 中，节点B 处于节点A 与节点C的传输半径内，而节点A 与节点C 不在对方传输半径内无法进行通信。节点A 与节点C 同时向节点B 发送信息，从而会在节点B 处发生碰撞，使源节点数据需要重传，从而增大了网络的开销。

RP-MAC 协议能够解决隐藏终端问题，如图4所示。在RP-MAC 协议中，节点A 发送数据时，首先会发送第一帧数据进行探测，当节点B 收到第一帧数据时，会向节点A 回应ACK 帧。由于节点C 处于节点B的传输半径内，因此，节点C 会侦听到该ACK 帧，从而学习到节点B 处于接收状态，节点C 将不会向节点B 发送第一帧数据，避免了冲突的发生，解决了隐藏终端问题。

图4 RP-MAC 协议解决隐藏终端问题

2.2.2RP-MAC 协议解决暴露终端问题

暴露终端是指处于发送节点传输范围内，但在接收节点传输范围之外的节点。暴露终端因侦听到数据源节点发送的信息从而认为信道处于忙碌状态导致通信被推迟。然而，暴露终端实则处于接收端的传输范围之外，它的数据传输不会造成信道上的冲突，反而可以实现数据的并行传输。因此，这样的推迟是没有必要的。

暴露终端问题如图5 所示。节点B 与节点D 处于对方的传输范围之内，且节点B 与节点A、节点D 与节点C 进行通信。节点B 向节点A 发送数据时，节点D 可以侦听到节点B 发送的数据，此时，节点D 认为信道处于忙碌状态。当节点D 有数据向节点C 发送时，节点D 认为信道处于忙碌状态，导致通信被推迟，无法进行数据并行传输。节点D成为暴露终端。

图5 暴露终端问题

RP-MAC 协议能够避免暴露终端问题，提高信道利用率，如图6 所示。在RP-MAC 协议中，节点B 向节点A 发送数据时，节点D 侦听到节点B 发送的数据，节点D 会将节点B的状态置为发送。当节点D 有数据发送时，若节点C的状态可以进行收发，则节点D 会向节点C 发送第一帧数据，节点C会回复ACK 帧，节点D 可与节点C 进行数据传输。此时，节点B与节点D的数据会在信道上发生碰撞，但由于节点A 不在节点D的传输半径内，节点C不在节点B的传输半径内。因此，此时的碰撞并不影响通信，这样就避免了暴露终端的问题，实现了数据的并行传输。

图6 RP-MAC 协议避免暴露终端问题

3 仿真与现场实验

3.1 NS3 仿真

为了验证RP-MAC 协议性能，本节使用NS3仿真平台对RP-MAC、Slotted FAMA 和R-MAC 协议的性能进行仿真与分析[20-25]。

仿真实验在5 km×5 km×3 km的3D 区域内随机放置35 个节点。实验测试了数据率（每秒发送的数据包数）为0.05、0.10、0.15、0.20、0.25、0.30、0.35、0.40的情况下，不同协议的平均能耗及吞吐量。仿真实验参数如表4 所示。

表4 仿真实验参数

平均能量消耗（AET,average energy tax）为

平均能量消耗指一次仿真过程中总的能量消耗Et与sink 节点成功接收的包数Np和网络中节点总数Nn乘积的比值。

网络吞吐量为

网络吞吐量指sink 节点成功接收的包数Np和包负载长度Lp的乘积与网络仿真时间Tsim的比值。

平均能耗随数据率变化如图7 所示。仿真结果表明，当数据率较小时，网络负载及冲突都较少，因此，Slotted FAMA、R-MAC 和RP-MAC 协议的能耗都较小，但由于Slotted FAMA 协议使用的RTS/CTS 握手机制增加了协议的能耗。R-MAC 协议使用预约机制，但其复杂的冲突避免机制和较多的控制报文均增加了协议的能耗，因此，Slotted FAMA 和R-MAC 协议的能耗大于RP-MAC 协议。随着数据率的增加，网络中的负载逐渐增加，RP-MAC 协议的能耗也会有所增加，但相对增加较少。而Slotted FAMA 和R-MAC 协议中，由竞争和信道预约等造成各种冲突导致能耗急剧增加，但由于R-MAC 协议采用了冲突避免机制，因此，R-MAC协议的能耗相对Slotted FAMA 协议而言增加较少。

图7 平均能耗随数据率变化

吞吐量随数据率变化如图8 所示。从图8 可以看出，随着数据率的增加，网络中的负载逐步增加，RP-MAC、R-MAC 及Slotted FAMA 协议的吞吐量逐渐增加，当网络负载逐渐趋于饱和时，RP-MAC协议的吞吐量会逐渐趋于稳定；R-MAC 协议由于采用了冲突避免机制，冲突较少，因而，吞吐量逐渐趋于稳定，但仍小于RP-MAC 协议；Slotted FAMA 协议的吞吐量由于冲突的增加而呈现降低的趋势。当数据率大于0.15 package/s 时，RP-MAC协议的吞吐量远高于Slotted FAMA及R-MAC协议的吞吐量。综合图7 和图8 可知，RP-MAC 协议的吞吐量及能耗均优于Slotted FAMA 和R-MAC 协议。

图8 吞吐量随数据率变化

3.2 现场实验

3.2.1试验床搭建

青海湖水域在线监测试验床被部署在青海湖西北部。该试验床由带4G 和Wi-Fi 模块的工业路由器、GPS、五套节点和一台远程服务器等组成。每套节点包含水上浮标、水下温盐深传感器、水声调制解调器和树莓派主控板。节点使用水下温盐深传感器采集水下温度、盐度、深度等属性数据，经过水声多跳通信传输至sink 节点，继而通过4G 和互联网传输至实验室服务器。水上浮标模块主要用于承载主控板、GPS、水声调制解调器和水下温盐深传感器等设备并提供电源。图9 为试验床实地部署场景。

图9 试验床实地部署场景

试验床拓扑如图10 所示。36 号节点和5 号节点将水声图片信息经65 号节点和8 号节点的转发，最后到达sink 节点（即1 号节点），之后由装有4G模块的sink 节点接收，并经由互联网传输至数据中心，对数据进行存储及可视化处理。

图10 试验床拓扑

3.2.2试验床测试

基于该试验床，本文分别在单数据源节点与sink 节点通信和多数据源节点与sink 节点通信的网络场景中将RP-MAC 与Slotted FAMA 协议进行了对比。实验参数设置如表5 所示。图11 和图12 给出了部分试验床的调试信息截图。图11为接收节点未成功恢复块中所有原始包时，发送节点重传第一帧的调试信息截图。图12 为发送节点收到接收节点回复的成功解码所有原始包的ACK 后，进入发送避免阶段的调试信息截图。图13 和图14 为RP-MAC 与Slotted FAMA 协议在单数据源与多数据源场景中不同数据率下的吞吐量对比。

图11 发送节点重传第一帧

图12 成功发送数据包后发送节点进入退避状态

表5 实验参数设置

由图13 可知，当数据率较小时，随着数据率的增加，网络中的负载逐渐增加，RP-MAC和Slotted FAMA 协议的吞吐量都会有所增加。当网络负载饱和后，RP-MAC 协议的吞吐量基本保持在500 bit/s左右，不会有显著的变化。而Slotted FAMA 协议的吞吐量由于冲突增加而出现下降的趋势，Slotted FAMA 协议的吞吐量从数据率为0.15 package/s 时开始，逐渐下降到140 bit/s。由图14 可知，多个数据源的情况下，与单数据源时变化相似，当数据率较小时，随着数据率的增加，网络负载会有一定的增加，协议的吞吐量也有小幅增加。但当网络负载基本饱和后，随着数据率的增加，多数据源场景下RP-MAC 协议吞吐量基本稳定在550 bit/s，不会有显著的增加。Slotted FAMA 协议的吞吐量在网络负载迅速增加的情况下，会从数据率为0.1 package/s时开始迅速下降，直至下降到120 bit/s。

图13 单数据源场景中的吞吐量

图14 多数据源场景中的吞吐量

4 结束语

本文提出了基于规则与感知的RP-MAC 设计，并将该协议与Slotted FAMA 等协议的性能进行分析对比，进一步通过NS3 和青海湖水域在线监测试验床对2 种协议进行了大量实验测试，实验表明，RP-MAC 协议的吞吐量基本稳定在500 bit/s，不会有显著的增加。R-MAC 协议的吞吐量基本稳定在300 bit/s。Slotted FAMA 协议的吞吐量在网络负载迅速增加的情况下，会从数据率为0.1 package/s 时开始迅速下降，直至下降到120 bit/s 左右。未来将会进一步进行融合路由机制与MAC 协议的研究工作，给出改进效果。此外，由于青海湖水域在线监测试验床实地部署时的难度较大，试验床的相关实验数据相对较少，未来仍需进一步进行大量的实地测试。