OMNeT++中AODV协议调试与参数优化实践指南

在OMNeT++里调AODV协议，第一周我基本处于“看着满地图飘着的RREQ数据包发呆”的状态。协议规范读了好几遍，按需路由、目的序列号防环、Hello保活机制，逻辑背得滚瓜烂熟，可真把这些东西跑进离散事件模拟器之后，状况就变成了：传输半径调小一点路由全断，节点数量一多控制消息先吃掉一半带宽，最离谱的是偶尔还会出现路由环回——这在AODV的规范设计里本不该发生。

后来我把这一趟趟排查过程整理成了可供复现的调试清单和参数调优思路，才发现AODV在OMNeT++里的难点根本不在于协议本身，而在于你如何读懂模拟器里发生的事件、如何定位是哪一层逻辑出了问题、以及如何理解参数之间互相牵扯的关系。这篇指南就是那次踩坑经历的系统梳理，想给正准备在OMNeT++里跑AODV仿真、或者已经被路由震荡和参数调不明白折磨得头疼的开发者，提供一条能直接参考的路线。

1. 先把AODV仿真的“地基”摸清楚：OMNeT++里的协议栈位置与模块行为

很多人拿到AODV的OMNeT++实现后，第一件事就是改参数、跑场景，结果看到一堆莫名其妙的丢包就懵了。我的建议是，先把AODV在你的仿真节点里到底挂在什么位置彻底搞清楚，再来谈调试和优化。这一步省了，后面所有分析都是在空中楼阁上盖房子。

1.1 AODV模块到底跑在网络栈的哪一层

AODV是网络层的路由协议，但它在OMNeT++里的实现通常不是“直接处理IP包”，而是以独立模块的方式挂在节点内部，通过UDP和应用层通信。换句话说，节点里的应用层产生数据流后，会先交给UDP，再交给网络层，而AODV模块做的是维护一张路由表，决定这个数据包该从哪个邻居节点转发出去。

这个架构带来的一个直接后果是：你调试时要靠“看消息从哪个门进来”来判断逻辑走到了哪一步。AODV模块里通常有几类输入，一是来自下层网卡的信号（比如无线链路状态变化），二是来自UDP封装的AODV控制消息（RREQ、RREP、RERR、Hello），三是模块自己给自己发的定时器自消息（Hello定时器、路由请求重传定时器）。

我在项目里第一次定位问题，就是靠在这个模块的handleMessage入口处加了一行日志，把每种消息的类型、发送方、接收方、当前仿真时间全部打印出来。这一步看起来基础，但当你面对几百个节点同时发路由请求的时候，事件日志是唯一可靠的线索。没有这一步，你在动画界面里看到漫天的RREQ，根本分不清谁是源头谁是转发。

1.2 最小可调试场景：从两个节点而不是五十个节点开始

调试AODV最大的忌讳，是一上来就搭一个大型移动自组网场景。我曾经把一个几十个节点、带随机路点移动模型的场景跑起来，结果路由断了，我根本不知道是移动太快导致的拓扑变化，还是参数配置不合理，还是底层无线模块的传输范围设置出了问题。

正确的做法是先构造一个两节点或三节点的静态场景，然后把所有外部变量降到最低。比如两个固定节点，一个发UDP流，另外一个接收，中间不需要任何中继。这时候如果AODV还能跑出路由失败，那问题一定出在最基础的配置上——比如Hello机制被关了，或者路由表项的有效期太短。

我建议新场景按这样的最小配置起步：

• 节点数量固定为2到3个，关闭移动模型，位置固定但距离可调。
• 使用最简单的周期流（比如恒定比特率），把应用层变量干扰降到最低。
• 关闭不相关的网络协议，只保留AODV、UDP和基础无线网卡。
• 所有节点使用相同的无线参数和信道频率。

这个最小场景跑通之后，再逐步加入第三个节点、加入移动模型、加入更多业务流。每加一个变量就重新验证一次路由是否正常，这样出问题时你能很清楚地知道是哪一步引入的。

1.3 仿真库版本差异：同一套参数在不同版本里含义不同

在OMNeT++上实现AODV，多数人会选择某个现成的仿真协议库，而不是自己从零写。但这里有个非常隐蔽的坑：不同版本的协议库对AODV的实现细节并不完全一致，尤其是参数取值范围和默认值，可能会悄悄变化。

我遇到过的情况是，旧版本库里Hello消息的发送间隔叫helloInterval，新版本里同一个位置可能换成了更细粒度的广播间隔配置，同时默认值也变了。如果你把旧项目里的配置文件直接挪到新环境里跑，某些参数名会静默失效——OMNeT++对未知参数有时候只是弹个警告，并不会直接拒绝运行。这意味着你以为自己调了参数，实际上仿真用的还是默认值。

所以我建议拿到任何不熟悉的协议库时，先确认三件事：第一，AODV模块的类名和参数名是否和你之前用的相同；第二，控制消息的发送是走UDP端口还是直连网络模块；第三，Hello消息和路由请求的实现是基于定时器自消息，还是基于网卡的周期广播机制。这些差异决定了你后续所有调试手段的落脚点。

2. 调试AODV的完整工具箱：从事件日志到数据包追踪的配合打法

AODV调试跟普通的应用层程序调试不一样。它不是单线程跑逻辑，而是几十个模块之间通过消息交互推进仿真。传统打断点的方式有用，但需要配合对事件序列的理解才能真正解决问题。我把自己常用的四类调试手段串起来讲一下，它们之间是配合关系，不是替代关系。

2.1 事件日志：先学会“读时间线上的通话记录”

在OMNeT++里，每个模块都可以通过EV宏往仿真日志里输出信息。AODV模块本身通常会带一些日志，但这些日志在默认级别下输出得很有限，有时候只有报错信息。我的习惯是拿到一个不熟悉的AODV实现后，先打开它的源码，找到几个关键函数的日志点：

• 收到RREQ时，检查是否建立或更新了反向路由；
• 收到RREP时，检查是否建立了正向路由；
• 定时器触发时，检查是本节点的活跃路由表项超时，还是Hello定时器触发。

这三个日志点覆盖了AODV状态机的核心流转。只要把日志级别打开，你会发现很多问题一眼就能看出来。比如某个节点收到RREP但源节点没收到，那大概率是RREP沿反向路径转发时，某个中间节点的反向路由已经因为超时被删掉了。

我习惯给这些日志加上接收方地址和目的地址的打印，并用统一的格式写成一行。这样整个仿真结束后，用文本编辑器打开日志文件，Ctrl+F搜索某个节点的地址，就能完整地看到这个节点在仿真期间参与过的所有路由过程。这一步比盯着动画界面高效得多。

2.2 在OMNeT++里打断点调试C++模块：查状态机而不是查业务逻辑

当日志显示某个行为不符合预期，比如节点收到了RREP却不更新路由，这时候就需要进入源码打断点了。AODV模块本质上是一个cSimpleModule子类，核心处理函数就是handleMessage。在调试器里设置断点时，不要每一条消息都中断，否则你会疯掉。

我常用的方法是按消息类型设置条件断点。在handleMessage里，先把消息转化为AODV控制消息结构，再判断其类型。比如只有接收到的RREP才中断，或者只有删除路由表项时才中断。这样你能直接看到：这个节点为什么决定删掉某条路由？是因为收到了RERR，还是因为活跃路由超时？

另外有个小技巧：AODV模块内部大量使用自消息来实现定时器。自消息的type字段通常有定义好的枚举值，比如HelloTimer、RouteRequestTimer、RouteExpiryTimer。打断点时可以在消息的kind上设置条件，比如只中断kind为特定值的自消息。这样你就能沿着时间线观察某个定时器从设置到触发再到处理的全过程。

2.3 可视化动画与数据包跟踪：把抽象事件变成可感知的传播过程

OMNeT++的图形化运行界面可以慢速播放数据包在节点之间的移动过程。对AODV来说，这种可视化最大的价值不是看控制消息怎么传，而是观察路由建立的“时序”。

举个例子，节点A发起路由发现，泛洪RREQ，然后你看到不止一个节点回RREP。按照AODV规范，中间节点如果有活跃路由，可以直接回RREP。那么动画里就会出现多条RREP同时向源节点汇聚的情况。如果你设定的是期望走最短路径，但源节点选择RREP的逻辑是按照最先收到的响应来定，那么实际选中路径就可能不是最短那条。这个问题在动画里一眼就能看出来：先回的RREP来自离源节点稍远的中间节点，而后回的来自目的节点本身。

同时不要忽略数据包追踪功能。现在很多OMNeT++场景可以配置将仿真中的封包导出为抓包文件。这比动画更进一步——你可以离线分析每个AODV控制消息的字段内容、经过的路径、以及时间戳。我在分析一次路由震荡时就靠这个定位到：某个节点的路由表项在一秒内被反复建立和删除，导出抓包文件后看得非常清楚，几个控制消息在环形路径上不停打转。

2.4 仿真快照：复现“状态机内部现场”的利器

日志和断点能帮你看到“某个消息到达后发生了什么”，但有时候你需要的是“某个时刻节点的所有状态快照”。OMNeT++的快照功能可以在指定仿真时刻或者某个条件满足时，把模块内部的状态变量全部导出。

AODV调试里这个功能特别适合排查路由环。当你怀疑某个节点维护的路由表处于异常状态时，设置一个条件，比如收到来自特定邻居的Hello时触发快照，然后检查该节点的路由表项、序列号计数器、路由激活时间等内部状态。我在一次调试中就用这个方法发现了问题：某个节点的目的序列号长期低于邻居持有的序列号，导致它永远无法被选中作为新鲜路由的下一跳。这种状态问题靠日志很难看全，因为日志散落在不同节点上，但快照把某个节点某一时刻的全部状态一次性摆在你面前，问题瞬间就清楚了。

3. AODV核心参数逐项拆解：每个参数背后到底在控制什么

调试阶段解决的是“路由能不能建立”的问题，而参数优化解决的是“路由建立得好不好、稳不稳定、代价高不高”的问题。AODV协议里有几个参数直接决定仿真结果的走向。参数名字表面上只是一个数字，但它们之间有着复杂的联动关系。

3.1 Hello机制三兄弟：helloInterval、allowedHelloLoss与activeRouteTimeout

Hello机制是AODV维护本地连接的重要手段。每个节点周期性广播Hello消息，邻居在连续超过一定次数没收到Hello后，就判定该链路失效。

helloInterval控制Hello消息的发送间隔。这个值设得太小，Hello消息会占据大量信道资源，尤其在几十个节点的场景里，几乎每条Hello都在网卡队列里排队；设得太大，邻居发现链路断开的速度就变慢，数据包会在失效链路上持续发送，造成丢包。

allowedHelloLoss表示允许丢失Hello的次数。实际链路超时时间等于helloInterval乘以allowedHelloLoss。这个乘积很关键，它不是独立参数，而是决定了节点在多长时间内没收到邻居的任何数据包时判定邻居消失。我在优化时习惯先定链路超时时间，再反推这两个参数，避免单独调一个导致超时时间不符合预期。

activeRouteTimeout则控制路由表项在“活跃使用”之后还能存活多久。每次有数据包成功经过这条路由，活跃计时器就刷新一次。这个参数决定了路由在没有数据流量时还能保持多久。如果业务是间歇性的，这个值设小了会导致每条流开始前都需要重新发起路由发现，时延大增；设大了又会让路由表里的僵尸路由长时间占用空间。

3.2 路由发现压力阀：rreqRetries、rreqRateLimit与路由请求超时

AODV是“按需”路由，没路由时才发起路由发现。但如果真的一启动就疯狂发RREQ，网络会瞬间被控制消息淹没。协议设计里避免这种情况的重任就落在rreqRetries等参数上。

rreqRetries控制源节点在请求失败后最多重试几次。每次重试时，RREQ的TTL会递增，以便覆盖更大的网络范围。这个数值过大会让不存在的目标节点引发的广播持续很久；过小又可能错失窄带慢环境下的正常响应。

rreqRateLimit是我最喜欢调的参数之一，它限制了节点每秒最多发送多少条RREQ。在一次节点快速移动的仿真里，路由频频断裂，如果这个限制值太大，节点会疯狂发起路由发现，网络彻底陷入广播风暴；限制值太小，路由恢复速度又跟不上业务需求，导致大量包排队等待。

还有一组隐含参数和路由发现相关，比如RREQ的初始TTL和重试时的TTL递增步长。这组参数决定了一次路由发现最多覆盖多少跳。在小型网络中，过大的TTL只会制造冗余广播，没有任何收益。

3.3 邻居管理与路由表维护：路径删除相关的参数

当链路断开后，AODV不只是简单地把路由表项删掉，它还会向受影响的一跳邻居发送RERR消息，让它们也把对应的路由表项标记为失效。这个“删除传播”机制里有个关键参数，决定了节点在路由失效后还要保持表项多长时间。

这个参数通常和活跃超时有关联。如果在发完RERR之后立刻物理删除表项，那么某个缓存了旧路由的上游节点再次查询时，就会触发一次全新的路由发现。如果保持一段时间再删，上游节点有可能通过它再次广播RREQ时拿到旧节点的RREP——虽然路径新鲜度可能不够，但能减少部分路由发现的次数。

我在一次移动场景优化中对比过这两种配置：短保留时间导致路由发现次数显著上升，控制开销变大；长保留时间则导致部分数据包沿过期路径发送，丢包率上升。最后我取的折中值是activeRouteTimeout的约两倍。这个比例不是从文档里看到的，而是做了一整轮场景扫描之后得到的经验值。

3.4 参数之间的“牵一发而动全身”组合效应

上面这些参数不是孤立工作的。一个最典型的组合就是业务间歇性、Hello间隔与路由超时三者之间的匹配。

假如业务流每隔5秒发一轮数据，而activeRouteTimeout小于5秒，那么每轮数据开始时路由都会失效，都需要重新做一次路由发现。这时候你单独减小helloInterval没有任何用，因为问题不在邻居探测上，而在路由表生命周期上。

反过来，如果业务持续不断，activeRouteTimeout设得很小也无所谓，只要数据流不断刷新计时器，路由就一直有效。真正吃紧的是邻居超时时间——如果链路物理断开了，但邻居超时判定得很慢，下一跳依然是那个失联的邻居，业务流就只能干等丢包，直到邻居判定超时。

我把几个最常改的参数的默认行为和优化方向整理成下表，方便你对照排查：

这组参数我建议按照“业务特征—邻居判定—路由表生命周期—发现压力”的顺序依次调整，而不是一上来就同时改。每改一个，跑一轮相同种子和相同场景，只对比这一个变量的影响。这样你的优化过程才是可控和可解释的。

4. 经典故障现场：五个常见问题的排查链路

参数优化前你首先得确保基础行为正常。这里我整理了在OMNeT++里跑AODV最常遇到的五类故障，每类我都按“观察—假设—验证—修复”的完整链路来拆解，而不是直接把答案写在最前面。因为排查思路本身才是你离开文档后还能独立解决问题的真正能力。

4.1 开局就广播风暴：源节点根本没停下来

症状：仿真刚刚启动，全网每个节点都在疯狂发送RREQ，控制开销迅速占满信道，业务包几乎无法传输。

我当时的排查链路是这样的：先看是单个节点还是全网节点都在发。如果是全网都在发，先怀疑是不是所有节点同时启动业务，造成路由发现并发；如果只有单节点，则怀疑它找不到任何邻居。然后我查看事件日志，确认helloInterval和邻居表状态，发现那个节点一条Hello都没收到过——它甚至不知道自己在传输范围之外。

进一步往下查，发现无线模块的传输功率配置和节点之间的距离不匹配。这不完全是AODV的问题，但AODV用最显眼的方式暴露了它。修复方式很简单，调整节点间距或者加大传输功率；但如果你的本意就是测试断链场景，那就得降低rreqRateLimit避免节点在找不到邻居时一遍遍无意义重试。那次之后我养成了一个习惯：任何新场景里，先用一个最简便的方式确认物理连通性，再分析路由协议行为。

4.2 路由环回流：目的序列号比较逻辑失效

症状：数据包在两个节点之间来回转发，永远不会到达目的地，TTL耗尽后被丢弃。日志里能看到同一个数据包在相邻节点间交替出现。

AODV本身靠目的序列号避免环路。只有当收到的路由信息序列号比现有的大，或者在序列号相同的情况下跳数更少时，节点才会更新路由。环路的出现意味着这个比较逻辑出现了例外。

我遇到的情况是：某个中间节点没有正确把RREP中的目的序列号记录到路由表项，导致该节点的目的序列号比全网其他节点都低。于是别的节点发来的RREQ，这个节点每次都以“比我的序列号大”为由建立反向路由并转发，而它自己却无法用正确的序列号更新正向路由。最终导致数据包沿着不一致的路径兜圈子。

修复链路：先从数据包追踪中提取出成环的具体路径，然后在这几个节点的快照里对比目的序列号，找出序列号偏小的那个节点，回到它的路由表项更新代码里查找序列号赋值的遗漏。这个问题用断点调试很难在第一时间抓到，因为环路形成需要一段时间，普通断点只能看到一次更新的瞬间。快照对比在这里价值极大。

4.3 流量一来路由就断：Hello丢失连锁反应

症状：静态拓扑，业务流开始传输的前几秒正常，随后路由失效，过一段时间又恢复，之后再次失效，形成周期性断流。

这个症状最容易误解为网络拥塞。我一开始也把大量精力花在降低业务速率、调整网卡队列上，结果毫无改善。后来仔细看日志才发现问题本质是Hello消息在周期内丢失过多，链路被判定失效，AODV收到RERR后删除路由，业务中断。当业务流停止时，信道空出来了，Hello又开始正常工作，邻居重新发现——然后下一轮业务再触发放大。

为什么业务流会导致Hello丢失？因为在仿真默认的无线模型中，所有节点共享同一信道，业务流的帧会和Hello帧竞争信道接入。如果网卡竞争窗口参数不适合，突发流量完全可能把Hello挤掉。这个问题的排查关键在于区分“链路带宽不足”和“邻居判定失效”这两个不同层面。我只观察人均吞吐量是看不出问题的，必须把Hello接收事件单独统计出来，看它是否在流量期间持续丢失。

修复路径有两步：第一步是调大allowedHelloLoss，让链路判定不那么敏感；第二步是优化无线网卡的接入参数，保证Hello消息有基本的发送机会。两个方向都要做，只调一个往往治标不治本。

4.4 多条路由同时可用，但数据始终只走一条

症状：拓扑中有明显两条路径可以到达目的节点，但所有数据包都挤在一条路径上传送，另一条完全空闲，即使主路径上的节点队列已经接近拥塞。

从AODV设计出发，这不是一个“错误”，因为AODV本来就是单路径协议，源节点根据收到的RREP建立一条路由，之后所有数据都走这条。但是很多人误以为AODV会自动负载均衡，所以把这个现象当成故障来查。

如果你真的想让两条路径都承载流量，而不是单路径，需要检查源节点是否存储了多条备选路由。有些AODV实现会在源节点缓存多个RREP回复，然后根据某种策略选择使用哪条。默认策略往往是“先到先得”，也就是网络里传播最快的RREP胜出，而不是“跳数最短”或者“队列最短”。所以在静态拓扑里，哪怕三条路径跳数一样，物理传播略有差异也会导致某一条被选中。

如果你只是想优化单路径的性能，那真正值得做的不是改AODV，而是关注“为什么先到的那条路径后来拥塞了”。这时候你需要观察RREP响应时间和后续数据时延的关系，可能在网络层和无线层之间还存在隐藏瓶颈。

4.5 仿真结果飘忽不定：每次跑出来的指标方差很大

症状：参数完全没变，只换了随机种子，分组递交率从35%跳到80%，时延也从几十毫秒跳到几百毫秒，结论根本没有可复现性。

这是最容易被忽视、也最影响判断的一类问题。AODV仿真结果直接受节点移动模型、无线信道衰落模型和业务起始时间的随机性影响。如果移动节点每次运动的轨迹都不一样，链路断裂的时间点自然不同，那路由表现当然会有巨大波动。

正确做法不是去调AODV参数，而是控制仿真输入的随机性。我的习惯是先固定随机种子，把移动模型的随机数流和信道模型的随机数流分开编号，确保对比实验时移动轨迹完全一致，只让信道模型产生随机性。然后做多组随机种子实验，用平均结果和置信区间来评价AODV的优劣。

如果固定移动轨迹后结果依然波动，那问题大概率出在信道衰落模型的随机数流上。无线信道的快衰落变化会让同一位置同一距离的链路质量出现差异，进而影响Hello接收和RREP传播。这种情况下的优化重点应该转向物理层参数，或者通过多次重复实验取均值来消除信道随机性。

5. 参数优化实战：从指标倒推参数组合，而不是盲目扫描

把故障都处理干净之后，才到了真正意义上的参数优化阶段。但这里的核心不是“把所有参数组合都试一遍”，而是根据你要优化的场景特征，逆着推导出参数方向的上下边界。先想清目标，再动手调参，你的实验次数能减少一半以上。

5.1 先从指标反推参数：你的网络到底缺什么

不同场景对AODV优化的诉求完全不同。移动自组网场景最关心的往往是分组递交率；高密度传感网场景关心的是控制开销和能耗；实时传输场景则更在意端到端时延。这三个指标对同一个参数的优化方向往往是相反的。

举一个具体例子：如果你发现分组递交率低，先不要急着调路由协议。你先问自己丢包发生在哪里——是在路由建立前的排队阶段，还是已经建立路由但链路中途断裂。前者说明路由发现机制不够灵敏，需要降低helloInterval或缩短邻居超时时间；后者说明链路断开的检测太慢，需要让邻居判定更快、RERR传播更快。同一个指标低，对应的参数调整方向完全不同。

所以在优化前，我坚持先做一层指标分解。我把AODV场景的总指标拆成三部分：

• 路由发现时延：从业务包到达应用层到第一条数据成功转发的间隔；
• 路由维护开销：Hello、RREQ、RREP、RERR占用的总带宽比例；
• 路由生存期：一条路由从建立到失效的平均存活时间。

这三个子指标分别对应不同参数域。先定位你是哪个子指标差，再调参数就有的放矢了。直接总指标扫参数，不但实验量大，而且完全不知道为什么效果好、为什么效果差。

5.2 按场景分组的参数组合建议

我在不同场景里整理过几套组合，这里给出的是我实际跑过且有效的起点，具体数值要根据你的节点密度、移动速度和业务量再做一轮局部搜索。

低速静态或准静态网络（节点几乎不动、密度中等）是AODV最容易表现好的场景。路由建立之后基本不会断，所以重点优化的是路由发现开销。这种情况下我会把helloInterval适当调大，因为邻居关系很稳定，不需要高频Hello；activeRouteTimeout可以略短，因为就算路由失效，重建的成本也不高；rreqRateLimit可以设低，因为长期稳定环境下不会频繁请求。

高速移动网络是最难调的场景。链路持续断裂，路由重建频繁。这种情况下helloInterval要缩到比较小，保证断链后能快速发现新邻居；activeRouteTimeout要相应延长，否则路由稍微没有数据经过就过期，重建次数暴增；rreqRateLimit要设置到网络承受范围内的最大值，否则路由恢复会拖后腿。同时，路由失效保留时间需要适度加长，给上游节点一个缓冲。

间歇性业务网络是我自己经常遇到的一类场景。业务不是持续恒定，而是突发一波、停一段。这种场景最怕activeRouteTimeout比业务间歇期短，导致每一波突发到达时都要冷启动路由发现。我的优化思路是把activeRouteTimeout拉长到略大于最长业务间歇期；helloInterval保持适中；同时把allowedHelloLoss稍微调大，避免信道偶尔的波动触发邻居误判。

下面的表格是我常用的三套起点组合，可以直接当作你调参的初始值：

这三套组合不是唯一的答案，但方向是正确的。你拿到自己的场景后，先按这个起点跑几个种子，观察三个子指标，再按具体表现进行第二轮微调。

5.3 优化实验设计：别把时间浪费在全参数网格扫描

有人喜欢把所有参数按步长分成网格，跑几百组实验，最后用热力图找最优。这种方法在参数特别少时确实有效，但对AODV来说参数维度太高，而且参数之间强耦合，网格扫描既费时间又容易得出误导性的“最优解”。

我推荐一种更贴近工程实践的方法：单因素轮换加关键组合验证。第一步，使用上一节给出的起点组合，固定所有参数；第二步，每次只调整一个参数，保持其他全部不变，记录目标指标的变化；第三步，根据单因素结果找出两到三个最敏感的参数，做小范围的二维组合扫描；第四步，用未参与优化的随机场景验证最终组合是否具备泛化能力。

这个流程看起来朴素，但它能让你真正理解每个参数在你场景里的“手感”。比如你会发现改变helloInterval对时延几乎没有影响，但改变rreqRateLimit却能明显改变控制开销。这个认知比一组“最优数值”更有价值，因为你把同样的方法搬到另一个节点密度差异很大的场景时，你的直觉依然有效。

另外一个容易犯的错是只看平均值不看分布。AODV在不同随机种子下的表现可能差异极大。我建议每组参数至少跑10个随机种子的仿真，然后记录递交率的中位数和最小最大值区间。如果两个参数组合的平均值差不多，但一个组合的最差情况是60%，另一个是30%，那前者的稳定性绝对值值得你优先选择。

最后一小段经验

折腾AODV这段时间，我最深的体会是：OMNeT++里的协议调试，七成时间花在“搞清楚仿真环境里到底发生了什么”，三成时间才是在调协议参数。遇到问题不要急着改数值，先顺着事件日志把链路捋一遍，把“物理层现象”“邻居判定现象”“路由表现象”三层拆开，很快就能定位到真正需要动的那个旋钮。

最后分享一个我至今还在用的小技巧：所有的参数实验都保留一份完整的配置文件副本，并且在配置文件名里写清楚这组参数的核心目标。这样几周之后你拿回一组数据，还能立刻知道当初为什么这么设，而不需要重新读代码。这个习惯帮我节省了大量重复劳动，也希望对这个场景里的你有用。