简介面向水下传感器网络UWSNs的研究者、教师和系统设计者这份压缩包提供了一整套可运行的仿真代码与配套资料聚焦声波通信、能量管理、自组织定位、MAC与路由协议等核心议题。包内共131个文件核心为30个C实现文件.cc及对应头文件.h配合14个Tcl网络场景脚本、awk统计工具、PDF理论文档以及能量/延迟/吞吐量等结果文件既可以支撑协议算法验证也便于课堂实验演示。整包约22.23MB已有122人学习使用。通过结合代码与文档读者能快速搭建水下多跳网络仿真环境复现不同参数配置下的网络性能也可在现有模块基础上编写新协议比较端到端延时、丢包率与节点生存时间等指标。对于初涉UWSNs的学者这是一条直观的入门路径对于工程师则是评估网络部署方案和优化协议参数的有力工具。1. 打开这个压缩包前先搞清水下传感器网络仿真要解决什么如果你以前跑过地面无线传感器网络的仿真第一次打开这类水下传感器网络仿真代码和资料包时会明显蒙住节点多了一堆麦克风一样的调制解调器模块信道模型不再是你熟悉的自由空间衰减跑完一个Ping的端到端延迟居然可能超过一秒。这个包解决的不是“怎么仿真”的问题而是“怎么把水下声学场景仿真得不像空中无线网”的问题——它整合了声学信道、传播延迟、能量消耗和路由协议让你把精力花在调协议参数上而不是从零发明一套仿真框架。适合两类人一类是刚接手水下监测课题的在校生需要快速搭出可复现的仿真环境另一类是做海洋物联网预研的工程团队想先通过仿真圈定可行路线。这套资料的价值在于仿真门槛高水下场景盲区多资料的代码框架能省下大量绕路时间。但要清楚一点拿到代码不等于跑通跑通不等于结果可信水下仿真每一项参数背后都是物理约束盲目沿用默认配置大概率翻车。2. 水下声学信道为什么让地面仿真的经验全部作废2.1 电磁波在水里走不远声学链路的物理差异地面无线传感器网络的仿真里信道模型往往基于射频电波传播。这个假设在水下一开始就不成立电磁波在海水中的衰减系数随频率急剧上升要实现深海几公里级的通信需要的发射功率和天线尺寸远超设备能承受的范围。于是水下数据链路转向声学声速约为1500米每秒比电磁波低了近五个量级这就是为什么水下网络所有协议都要重新设计。声学链路的第二个特征是收发双端的强不对称性。很多水下节点是电池供电的自主设备而岸基或水面网关往往有充足电力这导致链路预算、功率控制策略和地面节点间对称假设完全不同。更关键的是声波在水中的传播不遵循各向同性它受温度、盐度、压力分层的折射影响同样的发射功率在不同的水层可能覆盖半径相差数倍。对仿真来说这意味着信道模型的参数不是随便填的一套可用的水下传感器网络仿真代码核心价值就藏在这些物理模型的选择上。2.2 传播损失与Thorp公式把你的信道模型从F式换成水下经验式地面仿真常见的对数距离路径损耗模型在水下只能覆盖一些浅水短距的简单场景。深水声传播损失通常用经验公式近似最常见的写法是Thorp公式描述吸收系数的频率依赖关系。吸收系数的典型形式为\alpha \frac{0.11{f^2}}{1f^2} \frac{44{f^2}}{4100f^2} 2.75\times10^{-4}f^2 0.003其中频率 f 的单位是kHz\alpha 的单位是dB/km。从公式能看出频率越高吸收越强所以在能完成数据率的条件下大家都尽量压低载波频率。仿真中如果把吸收项设成0结果会乐观得没有任何参考价值——数据包全都能到达路由协议比不出好坏。除了吸收传播损失还要计算几何扩展损失。球形扩展大约为20log10(R) dB而实际中深水信道介于球形和柱形之间很多仿真代码里用20log10(R)到10log10(R)之间可配置的扩展系数。我一般建议把扩展系数作为参数暴露在仿真配置里不要写死在物理层代码里因为你需要在不同的水体深度场景间做敏感性分析。把Thorp吸收、几何扩展、叠加环境噪声三项都同时激活这样才能看到水下链路对距离和频率的真实敏感度。2.3 传播延迟与多径为什么一个Ping要等3秒电磁波的传播延迟在仿真里通常被忽略但水下不行这绝对是新手最容易栽的地方。1500米每秒的声速意味着一个千量级的包在1公里距离上往返就要约1.3秒如果经过路由还要多跳端到端延迟轻松到秒级。很多地面无线网络仿真器默认的传播延迟在微秒量级如果你直接借用力模型而不换声学传播速度仿真结果会有数量级的偏差整套介质访问控制策略都建立在错误基础上。另一个问题是多径和时变衰落。浅水信道中声波经海面、海底反射形成显著的多径扩展直射路径和反射路径时延差可能达数百毫秒。许多水下协议在MAC层加入重传、握手机制都是因为这里误码率不像地面那么稳定。仿真里不能假定信道是静态的至少要把节点移动和轻微的声速剖面变化纳入考量。理解了这些差异再去看代码包里的信道模块你就明白为什么大家用专门的UAN模块而不是复用WiFi模型了。3. 用NS-3搭一个最小水下网络从信道到收发端的完整代码3.1 最小可运行仿真脚本两个节点、一条声学信道我见过太多人一上手就摆几十个节点结果出了问题根本定位不到。最稳妥的做法是先搭建两个节点的最小系统确认信道、物理层、MAC、应用层全部打通再扩展规模。NS-3里可以基于UAN模块来搭建下面的脚本片段展示了建立一条声学信道并放上两个节点的核心结构。注意不同版本的NS-3类名可能有细微差异我给出的是较为常见的API写法。// mini-uan.cc #include ns3/core-module.h #include ns3/network-module.h #include ns3/mobility-module.h #include ns3/uan-module.h #include ns3/applications-module.h using namespace ns3; NS_LOG_COMPONENT_DEFINE(MiniUan); int main (int argc, char *argv[]) { // 固定随机种子保证结果可复现 SeedManager::SetSeed(7); CommandLine cmd; double simTime 100.0; cmd.AddValue(simTime, 仿真时长(秒), simTime); cmd.Parse (argc, argv); // 创建水下信道使用Thorp损耗模型理想物理层误码(便于先跑通链路) PtrUanPropModelThorp propModel CreateObjectUanPropModelThorp (); PtrUanChannel channel CreateObjectUanChannel (); channel-SetPropagationModel (propModel); // 两个节点坐标在水下几米处 NodeContainer nodes; nodes.Create (2); MobilityHelper mobility; mobility.SetPositionAllocator (ns3::GridPositionAllocator, MinX, DoubleValue (0), MinY, DoubleValue (0), DeltaX, DoubleValue (1000), DeltaY, DoubleValue (0)); mobility.SetMobilityModel (ns3::ConstantPositionMobilityModel); mobility.Install (nodes); // 给节点安装水下网络设备 UanHelper uan; uan.SetMac (ns3::UanMacAloha); uan.SetPhy (ns3::UanPhyGen, PhyMode, UanTxMode::Create (UanTxMode::FSK, 8000, 4000, UanTxMode::CONST), TxPowerDb, DoubleValue (185.0), // 水下发射声源级约185dB RxGainDb, DoubleValue (0)); NetDeviceContainer devices uan.Install (nodes); // 从节点0向节点1周期发送一个较小负载 OnOffHelper app (ns3::UdpSocketFactory, InetSocketAddress (Ipv4Address (10.0.0.2), 9)); app.SetConstantRate (DataRate (100bps)); app.SetAttribute (PacketSize, UintegerValue (64)); ApplicationContainer apps app.Install (nodes.Get (0)); apps.Start (Seconds (1.0)); apps.Stop (Seconds (100.0)); Simulator::Stop (Seconds (simTime)); Simulator::Run (); Simulator::Destroy (); return 0; }这段脚本的逻辑很直白先构造信道传播模型再创建两个节点其中一个周期性发包。关键参数有三处第一是声源级TxPowerDb水下通常用声源级而不是毫瓦因为它反映的是声学辐射强度185分贝只是一个浅水短距离的典型起点实际通信距离会随这个值剧烈变化第二是UanTxMode里设定的载波频率8000赫兹和数据速率4000比特每秒频率直接决定Thorp吸收的大小第三是包大小与发送速率这两个值共同决定信道负载观测吞吐量拐点时就靠调它们。3.2 信道模型与物理层参数设置跑通最小系统后要把物理层配置换成更实际的模型否则结果没有任何参考价值。UAN模块常用的信道模型除了Thorp外还有理想模型和Range模型理想模型忽略传播损失只能在功能测试时用一旦开始跑协议对比就必须切回Thorp否则所有协议性能曲线都是平的。物理层部分则要配置接收灵敏度、误码率计算方式和信噪比计算模型这些参数在资料包里通常集中在配置文件里不要散落在各个源文件里。参数名称会随NS-3版本波动但配置思路是一致的物理层要能算出每个分组的接收功率并判定是否接收成功。常用的信号干扰噪声比计算方法会把环境噪声底和同频干扰并入公式。环境噪声级在水下仿真里极其关键它跟海况和航运活跃度相关有的代码包把噪声级固定为某个常数这会让仿真结果失去场景代表性。你可以把噪声级从常量改成一个随海况等级变化的配置项至少留出高噪声与低噪声两组实验对照。3.3 数据收发验证与轨迹输出很多新手跑完脚本只看终端打印就认为仿真完成这远远不够。你需要确认数据包确实从物理层发给对方并被成功接收最简单的办法是在仿真脚本里挂上Capture或者在代码中加入按节点打印收发统计的逻辑。UAN模块通常会提供追踪源比如PhyRxDrop、PhyTxBegin等建议把每个关键事件输出到独立的trace文件而不是打印在屏幕上因为场景扩大后终端输出会让问题淹没在数据里。另外要把仿真配置与结果文件分离。我习惯在脚本里只保留仿真逻辑把坐标、发射功率、频率、包长、仿真时长全部通过命令行参数传入。这样做有两个好处一是批量实验时只需一个外层循环脚本改参数二是每次结果文件都带着配置摘要方便事后追溯。至于结果数据的整理可以统一把每个节点收到的包序号、时间戳、信号强度导出成文本后续用Python一类的脚本汇总成吞吐量和延迟表格。4. 让仿真接近真实MAC、路由与能量模型的参数怎么配4.1 MAC协议选型T-Lohi、SFAMA与ALOHA仿真参数水下MAC协议选择直接影响网络容量资料包里通常会包含几种MAC的实现常见的有ALOHA、SFAMA和T-Lohi。它们的区别在于信道接入方式和对传播延迟的处理。ALOHA最简单节点直接发包冲突后按概率重传但它只适合低负载和延迟不敏感的场景仿真配置中只需关注重传概率与最大重传次数SFAMA利用握手预约信道能显著降低冲突但每次握手都要付出传播延迟的代价节点间距越大效率越低。在仿真中你会发现节点距离从500米增加到3000米时SFAMA的吞吐量下滑比ALOHA更快因为控制报文占据了太多时间。T-Lohi是专门为水下场景设计的基于音调的协议节点在发送数据前先发一个短音调竞争信道。它适合节点数比较多或突发流量明显的网络但音调检测对物理层信噪比要求较高仿真里如果简化物理层T-Lohi性能会偏乐观。一个常见做法是在仿真代码里跑同一流量下三种MAC的吞吐量对比而不是只看绝对数值。参数调节时优先关注最大传播距离、RTS重发次数、发送间隙这三项因为它们决定协议的时间预算。4.2 移动模型与拓扑水流把节点推走怎么办水下节点不是静止的尤其在海域场景里洋流会把节点推动导致拓扑持续变化。许多人把节点设成ConstantPosition模型这会省事但实验结果无法反映真实网络的断链和重路由代价。合适的做法是给节点设置一个低漂移速度的随机游走模型或水流向量模型例如速度0.2米每秒左右方向缓慢变化每秒钟更新一次位置。如果你的目标是分析路由稳定性这个移动模型就不能省。拓扑本身也有讲究。传统网格拓扑在地面网络中常用但水下监测任务多采用星型或链型部署网关浮在水面水下节点分布在几个深度层。这个差异直接影响路由协议的转发策略网格里节点有大量邻居可供选择链型拓扑里转发路径几乎没有冗余。我建议仿真时至少设置一组稀疏链型、一组密集随机布点对比协议在不同拓扑下的表现。部署坐标不能拍脑袋应基于目标水域规模和通信半径计算保证平均节点度在3到6之间低于这个值很多协议会频繁进入无路由状态。4.3 能量模型给每个节点挂上电池与电量轨迹水下节点的能量约束比地面更严苛因为换电池的成本极高很多场景是一次性部署。如果资料包里没有能量跟踪仿真就缺了最关键的评价维度。给节点挂能量模型时要同时配置能量源与各状态的功耗发送状态功耗最高、接收状态其次、空闲状态也不可忽略。有的资料包只统计发送和接收空闲功耗为0导致很多协议看起来能耗很漂亮换到实际设备却撑不了多久。在NS-3中安装能量模型时要确保它感知到物理层的每次状态切换而不是简单地在应用层发包时扣一次电量。一个可行的做法是把能量模型挂到网络设备而不是应用层。如果你发现仿真结束后所有节点剩余能量百分比完全相同那大概率是能量模型没有接入物理层这个坑在下一章还会展开。能量分析要看曲线而不是终值至少要记录节点电量随时间的变化轨迹观察网络是否出现能量空洞因为某些路由协议会让靠近网关的节点过早耗尽能量。5. 水下传感器网络仿真避坑指南现象、原因与解决5.1 跑完统计全部为0为什么你的业务包从未离开发射队列现象仿真结束收到的分组数、吞吐量全是0但终端没有任何报错。原因多数情况是MAC层排队机制的问题。水下MAC重传次数有限如果信道一直忙或冲突持续发生数据包会被丢弃在队列里而你不一定能从默认日志看到。还有可能是应用层启动时间晚于仿真结束时间或者发送速率设置过低导致整个仿真周期内只发出了几个包。解决先在物理层加追踪确认节点是否尝试发送信道接入请求。如果根本没有发送动作检查应用启动时间和发送速率如果有发送动作但对方没收到再查信道模型里的最大通信距离与发射功率是否匹配。务必先用两个节点近距离通信做冒烟测试距离设成100米确认链路通再放大距离。5.2 端到端延迟比预期大一个量级仿真时钟与声学延迟的计算现象1000米的节点间距理论上声学传播延迟约0.7秒但仿真算出来的端到端延迟常常达到3秒以上并且随着节点数增加快速增长。原因延迟包含了排队延迟、信道接入延迟和重传延迟有时协议握手带来的等待时间远超传播延迟。另一个隐蔽原因是仿真场景里节点的移动模型更新步长过大导致数据包到达时节点坐标已经跳变路由表失效转发路径出现绕路。解决把端到端延迟拆成传播延迟与协议延迟两部分先测单跳单包的传播延迟验证与1500米每秒声速是否一致再逐层叠加负载观察排队延迟的增长曲线。如果协议延迟在空载时就异常重点检查MAC层是否有不必要的退避计时例如退避窗口的单位被误认为毫秒而实际是秒。5.3 能量模型毫发无损没有给物理层挂上调制解调器能耗现象仿真结束后所有节点剩余电量都是100%或者只有应用层发包时电量在下降而接收状态完全免费。原因能量模型没有与物理层状态绑定。水下节点的调制解调器能耗占大头在发送和接收状态如果你用的是通用网络设备的能量模型它可能只感知到数据包收发而没有感知到物理层的状态切换。解决确认能量模型使用的是水下调制解调器专用的能耗模型同时在物理层代码中添加状态切换的追踪。如果资料包里没有现成实现可以写一个简单的能量包根据物理层的发送、接收、空闲、睡眠四个状态分别记录功率。最后把节点剩余能量随时间的曲线画出来与理论消耗做交叉验证。5.4 结果永远不能复现随机种子与移动模型的选择现象两次相同配置的仿真结果差异很大而且你找不到原因。原因仿真器里的随机变量来源很多包括信道噪声、MAC退避时间、移动模型的随机游走。如果脚本里没有固定随机种子每次跑的结果自然不同。还有人把移动模型的初始位置随机化又没设置种子导致每次拓扑都不一样结果当然不可比。解决在所有实验脚本开头固定随机种子为不同的实验批次分配不同的种子编号并记录存档。对比实验时不同协议应该使用相同的种子序列才能把性能差异归因于协议本身。移动模型如果引入随机性也要单独控制种子或直接关闭随机性做确定性对比。5.5 节点位于岸基之外部署坐标与信道范围边界现象在密集拓扑中个别节点的统计结果异常低甚至完全无通信。原因部署坐标边界超出信道模型的有效覆盖范围或者节点被放置到陆地深度为0的区域导致声学传播模型计算出异常高的损耗。常见于从资料包模板复制坐标却未按你的场景调整水深。解决检查所有节点的坐标是否在设定的海域范围内深度应大于几米且小于信道模型的支持范围。对边界节点单独做连通性测试确保它们至少有一个邻居在有效通信半径内。批量部署时建议在脚本里加入部署合法性校验如果某个节点没有建立任何链路就输出警告。6. 让仿真数据从“能看”到“能引用”批量实验与统计口径到这里你已经能手动跑通水下传感器网络仿真接下来要做的是把实验自动化并且让数据经得起推敲。这里分享三个习惯最后一个最容易被忽略但最影响结论。第一个习惯搭建批量实验外壳。把每次仿真参数通过命令行传入用一段Shell脚本依次遍历参数组合并自动汇总结果文件这样你的注意力就从“重复敲命令”转移到“看数据趋势”。#!/bin/bash # run-batch.sh 批量扫参分别测试 3 个节点间距下的性能 for dist in 500 1000 2000; do for seed in 1 2 3 4 5; do ./build/mini-uan --simTime200 --nodeSpacing$dist --seed$seed \ --resultFileresult_dist${dist}_seed${seed}.txt done done # 汇总把每个结果文件的吞吐量字段拼接成一张表 python3 aggregate.py result_*.txt summary.csv第二个习惯统计指标不能只看平均值。水下网络受信道噪声和MAC随机退避影响单次仿真结果方差很大。我在实际项目里至少跑5个不同随机种子报告平均值的同时给出标准差或置信区间。对比两个路由协议时先检查它们的性能分布是否重叠如果重叠明显就不能轻易得出某协议更优的结论。第三个习惯验证链路层判断。仿真数据在进入论文或方案报告之前先做一次单跳单包实测一个节点发送、一个节点接收看收到的包数是否为发送数端到端延迟是否在声学理论延迟附近。这一步能筛掉大多数模型配置错误。我个人的教训是有一次批量实验跑完吞吐量曲线很漂亮后来发现信道模块的传播速度被误设为光速所有延迟数据都不能用。从那以后每次搭建新场景我都先做单跳校验再放大规模。希望这组方法和踩坑记录能帮你在水下传感器网络仿真里少走几段弯路把精力放在真正值得研究的协议设计上。本文还有配套的精品资源点击获取