尧图网站建设 
简介这份资源面向移动自组网MANET路由协议的学习者与研究者提供在OPNET Modeler环境下搭建AODV按需距离矢量路由协议的完整建模工程。AODV通过RREQ广播、RREP应答、序列号防环与RERR失效通知等机制完成路由发现、建立与维护本模型可帮助读者在仿真中观察这些流程并评估延迟、丢包率、吞吐量与路由开销等指标。压缩包共56个文件约526KB以21个.m模型文件与12个.c源码为主体辅以obj编译产物、ef与prj工程配置、scenario_description场景说明及txt参考文档覆盖路由、MAC、应用管理与移动性等模块。资源已积累215人学习下载适合希望对照源码理解AODV实现细节、复现18节点场景并开展协议对比与参数调优的读者。1. 从一份 AODV_model 压缩包说起OPNET 里跑通 AODV 到底难在哪很多人第一次拿到AODV_model.rar这种命名风格的资源包时心里是没底的——解压出来一堆.h、.c、.pr文件扔进 OPNET Modeler 里编译报错仿真跑起来路由表死活不收敛。AODVAd hoc On-Demand Distance Vector本身协议逻辑不算复杂路由请求、路由应答、路由错误三件套但把它落到 OPNET 的进程模型里就变成了状态机、中断、包格式、进程注册一整套东西的耦合。这份资源包大概率包含 AODV 的进程模型源码、包格式定义和若干仿真场景配置目标就是让 OPNET 能仿真一个多跳无线自组网观察 AODV 的按需路由行为。适合谁看做 Ad hoc 网络仿真、写路由协议对比论文、或者需要在 OPNET 里验证自己改过的 AODV 变种的人。如果你只是想跑个现成结果那可能用 NS-3 更省事但如果你必须用 OPNET 出图、出统计量那这套东西绕不开。2. AODV 在 OPNET 里的进程模型从状态机到中断注册2.1 为什么 AODV 在 OPNET 里必须拆成进程模型OPNET 的仿真核心是离散事件驱动每个节点上的协议行为都对应一个进程模型process model用状态机state machine描述。AODV 的按需路由特性决定了它不能像 OSPF 那样周期性地泛洪而是由数据包触发路由发现。在 OPNET 里这个“触发”就是流中断stream interrupt和自中断self-interrupt的组合。进程模型里通常会有几个关键状态INIT、IDLE、RREQ_WAIT、RREP_WAIT、ROUTE_ACTIVE。每个状态之间的迁移条件就是收到什么包、超时多久。我一般会先看进程模型里的SV状态变量定义确认RREQ_ID、RREQ_RETRIES、NET_DIAMETER、NODE_TRAVERSAL_TIME这几个参数有没有暴露出来。因为 AODV 的很多行为——比如广播风暴抑制、路由请求重试次数——都直接受这些参数控制。如果资源包里的进程模型把这些硬编码在代码里后期改参数就得重新编译很麻烦。2.2 包格式定义AODV_model 里最容易漏掉的字段AODV 的包格式在 RFC 3561 里有明确定义但 OPNET 里需要用packet format接口重新声明。常见的做法是建一个aodv_pk包格式里面包含Type、Flags、Hop Count、RREQ ID、Destination IP、Originator IP、Life Time等字段。资源包里的.pr文件packet format如果字段顺序和 RFC 不一致仿真时解析就会错位表现为路由表里出现莫名其妙的 IP 或者跳数变成 255。下面是一个典型的 AODV RREQ 包格式定义片段用 OPNET 的包格式描述语言写// aodv_rreq 包格式定义OPNET packet format packet_format aodv_rreq { field Type : 8 bits; // 1 RREQ field Flags : 4 bits; // 保留位通常置 0 field Reserved : 4 bits; field HopCount : 8 bits; // 每转发一次加 1 field RREQ_ID : 32 bits; // 发起节点维护的序列号 field Dest_IP : 32 bits; // 目的节点 IP field Dest_SeqNum : 32 bits; // 目的节点当前序列号 field Origin_IP : 32 bits; // 发起节点 IP field Origin_SeqNum : 32 bits; // 发起节点序列号 }逻辑说明Type字段用来区分 RREQ、RREP、RERR通常 1 是 RREQ2 是 RREP3 是 RERR。HopCount每经过一个中间节点加 1用来防止无限循环同时接收端可以用它判断是否接受更优路径。RREQ_ID和Origin_IP组合起来唯一标识一个路由请求中间节点靠这个做重复包检测。参数说明Dest_SeqNum在 RREQ 里是目的节点已知的最新序列号如果发起节点不知道就置为未知值通常 0中间节点只有在自己的序列号大于等于这个值且路由有效时才回 RREP。2.3 进程注册与中断绑定让 AODV 进程能收到包OPNET 里每个协议进程需要在节点模型里注册绑定到对应的流stream和中断。AODV 通常绑定在udp或ip层之上通过op_intrpt_type()判断是流中断还是自中断。资源包里如果缺少op_pro_id的注册代码仿真启动时就会报“process model not found”或者“no interrupt handler”。一个常见的注册流程是在节点模型的process属性里指定 AODV 进程模型然后在进程模型的INIT状态里调用op_intrpt_register()注册自中断用于处理路由超时。下面这段代码展示了如何在INIT状态里注册一个延迟中断用于 RREQ 重试// 在 INIT 状态中注册 RREQ 重试自中断 // 参数中断码 RREQ_RETRY_INTR延迟时间由 RREQ_RETRIES 和 NODE_TRAVERSAL_TIME 决定 op_intrpt_schedule_self(op_sim_time() RREQ_RETRY_TIMEOUT, RREQ_RETRY_INTR);逻辑说明op_intrpt_schedule_self会在当前仿真时间加上RREQ_RETRY_TIMEOUT后触发一个自中断中断码是RREQ_RETRY_INTR。在状态机的IDLE状态里收到这个中断就检查是否收到 RREP如果没有就重发 RREQ并增加重试计数。参数说明RREQ_RETRY_TIMEOUT通常设为NODE_TRAVERSAL_TIME * 2而NODE_TRAVERSAL_TIME默认是 40 毫秒所以重试超时约 80 毫秒。如果网络直径大这个值要相应调大否则 RREQ 还没到目的节点就重试了反而加剧拥塞。3. 把 AODV_model 跑起来编译、场景配置与第一个仿真3.1 解压后的目录结构与文件作用拿到AODV_model.rar后先别急着往 OPNET 里拖。我一般会先看目录结构典型的布局是目录/文件作用src/进程模型源码.c、.h和状态机描述.pr.minclude/包格式定义、常量头文件scenarios/预置的 OPNET 场景文件.scenarioREADME编译顺序和依赖说明如果src/里缺少.pr.m文件那状态机就得自己画工作量很大。资源包如果只给了.c和.h那大概率是让你替换 OPNET 自带模型里的对应文件而不是从零建进程模型。3.2 编译顺序与常见编译错误OPNET 的编译依赖顺序很严格先编译包格式再编译进程模型最后编译节点模型。如果顺序反了就会报“undefined symbol”或者“packet format not declared”。我一般会在 OPNET 的Modeler里按这个顺序操作打开File Open加载include/下的包格式文件点击Compile。加载src/下的进程模型文件检查状态机是否完整然后Compile。打开节点模型确认 AODV 进程已绑定到正确的流然后Compile。常见的编译错误是op_pk_fd_set的字段类型不匹配。比如包格式里RREQ_ID定义成 32 位但代码里用op_pk_fd_set(pk, RREQ_ID, OPC_INT32, ...)时传了OPC_INT16编译能过但运行时会截断。血泪经验字段类型一定要和包格式定义严格一致否则仿真结果里的序列号会跳变。3.3 场景配置节点数、移动模型与流量注入编译通过后打开scenarios/里的场景文件。如果没有预置场景就自己建一个。关键配置项节点数至少 10 个否则多跳路径不明显。我一般用 20 个节点分布在 1000m x 1000m 区域。移动模型OPNET 自带Random Waypoint但要注意pause time设为 0 会导致节点一直移动路由频繁断裂。建议pause time设为 30 秒以上。流量注入用Application Config加一个FTP或Video业务目的节点随机选。流量速率别太高AODV 在 2Mbps 以下比较稳。配置完后在Simulation菜单里设置仿真时长比如 300 秒然后点Run。第一次跑建议把Animation打开看 RREQ 的泛洪范围是否合理。如果 RREQ 瞬间覆盖全网说明NET_DIAMETER设太大了或者没有做重复包检测。4. 避坑与排查AODV_model 仿真里最常见的 5 个翻车现场4.1 路由表一直不收敛RREQ 反复重发现象仿真跑了几十秒路由表里还是空的或者只有到邻居的路由。RREQ 重试计数很快达到上限然后丢包。原因最常见的是RREQ_ID没有全局唯一或者中间节点没有正确缓存反向路由。AODV 要求中间节点收到 RREQ 后先建立到发起节点的反向路由再转发。如果反向路由没建RREP 就回不去。解决检查进程模型里RREQ处理分支确认在转发前调用了route_table_add()添加反向路由。另外确认RREQ_ID是每个发起节点独立维护的不是全局变量。4.2 仿真跑着跑着就崩溃报“segmentation fault”现象OPNET 直接退出日志里只有一行segmentation fault。原因多半是包指针被释放后再次访问。AODV 里收到 RREQ 后如果决定不转发需要销毁包如果转发就不能销毁。资源包里的代码如果在一个分支里销毁了包另一个分支又去读就会崩。解决用op_pk_copy()复制包再转发原始包该销毁就销毁。或者统一在状态迁移的最后销毁中间只读不销毁。4.3 跳数统计不对RREP 里的 HopCount 是 0现象路由建立后查看路由表里的跳数发现全是 0 或者 1明显不对。原因HopCount字段在转发时没有递增。AODV 规定每转发一次 RREQ 或 RREPHopCount加 1。如果代码里忘了加接收端就以为目的节点就在隔壁。解决在转发分支里加hop_count op_pk_fd_get(pk, HopCount) 1; op_pk_fd_set(pk, HopCount, ...)。注意 RREP 的跳数是从目的节点往回累加的方向别搞反。4.4 移动场景下路由断裂后没有触发 RERR现象节点移动导致链路断开但源节点还在往旧路径发数据丢包率飙升。原因AODV 依赖链路层检测断链然后由中间节点发 RERR。OPNET 里如果无线接收机没有正确上报link failureAODV 就不知道链路断了。解决检查无线管道阶段pipeline stage里的radio receiver是否配置了error model并且把link failure中断映射到 AODV 进程。通常需要在进程模型里处理OPC_INTRPT_LINK_FAILURE类型的中断。4.5 仿真速度极慢一小时跑不完 300 秒现象仿真进度条几乎不动CPU 占用很高。原因AODV 的 RREQ 泛洪如果没有抑制20 个节点就能产生大量重复包。另外OPNET 的Animation如果全开也会拖慢速度。解决在进程模型里加重复包检测用RREQ_ID Origin_IP做缓存收到重复 RREQ 直接丢弃。仿真时关掉Animation或者只开Packet Flow的简化显示。如果还慢把NET_DIAMETER从默认的 30 降到 10减少 RREQ 的传播范围。5. 进阶技巧用 OPNET 的统计量验证 AODV 改动的效果跑通基础仿真只是第一步真正要出论文或者对比协议得会看统计量。OPNET 里 AODV 相关的统计量通常挂在AODV进程和IP层上我一般会重点抓这几个统计量含义怎么看RREQ Sent发起节点发出的 RREQ 总数数值越高路由发现越频繁可能移动太快RREP Received收到 RREP 的次数和 RREQ Sent 的比值反映路由建立成功率Route Errors触发的 RERR 数量越高说明链路越不稳定End-to-End Delay数据包平均端到端时延路由收敛慢会直接拉高这个值Routing Overhead路由控制包占总包的比例AODV 的 overhead 通常比 OLSR 低但移动快时会飙升如果你改动了 AODV 的某个参数比如把RREQ_RETRIES从 2 改成 5那就要对比RREQ Sent和End-to-End Delay的变化。我一般会跑三组默认参数、改后参数、以及一个固定路由的基线。三组跑完用 OPNET 的Results导出 CSV再画图。一个具体的验证技巧在进程模型里加一个自定义统计量记录每次路由发现的跳数。OPNET 支持op_stat_write()写自定义统计量代码片段如下// 在收到 RREP 后记录跳数 // 参数hop_count 从 RREP 包里读取stat_handle 是注册的统计量句柄 op_stat_write(stat_handle, hop_count);逻辑说明op_stat_write会把hop_count写入指定的统计量仿真结束后可以在Results里看到分布。参数说明stat_handle需要在INIT状态里用op_stat_reg()注册名字比如AODV Hop Count。这样你就能直接对比不同参数下的路径长度分布比只看平均时延更有说服力。最后说个我自己的习惯每次改完 AODV 代码先跑一个 10 节点、无移动、单条 CBR 流的小场景确认路由能建起来、数据能通再上大规模移动场景。这个“小场景冒烟测试”帮我省了无数个通宵排查的夜晚。希望帮到你。本文还有配套的精品资源点击获取 OPNET中AODV协议仿真：从进程模型到避坑实战
简介这份资源面向移动自组网MANET路由协议的学习者与研究者提供在OPNET Modeler环境下搭建AODV按需距离矢量路由协议的完整建模工程。AODV通过RREQ广播、RREP应答、序列号防环与RERR失效通知等机制完成路由发现、建立与维护本模型可帮助读者在仿真中观察这些流程并评估延迟、丢包率、吞吐量与路由开销等指标。压缩包共56个文件约526KB以21个.m模型文件与12个.c源码为主体辅以obj编译产物、ef与prj工程配置、scenario_description场景说明及txt参考文档覆盖路由、MAC、应用管理与移动性等模块。资源已积累215人学习下载适合希望对照源码理解AODV实现细节、复现18节点场景并开展协议对比与参数调优的读者。1. 从一份 AODV_model 压缩包说起OPNET 里跑通 AODV 到底难在哪很多人第一次拿到AODV_model.rar这种命名风格的资源包时心里是没底的——解压出来一堆.h、.c、.pr文件扔进 OPNET Modeler 里编译报错仿真跑起来路由表死活不收敛。AODVAd hoc On-Demand Distance Vector本身协议逻辑不算复杂路由请求、路由应答、路由错误三件套但把它落到 OPNET 的进程模型里就变成了状态机、中断、包格式、进程注册一整套东西的耦合。这份资源包大概率包含 AODV 的进程模型源码、包格式定义和若干仿真场景配置目标就是让 OPNET 能仿真一个多跳无线自组网观察 AODV 的按需路由行为。适合谁看做 Ad hoc 网络仿真、写路由协议对比论文、或者需要在 OPNET 里验证自己改过的 AODV 变种的人。如果你只是想跑个现成结果那可能用 NS-3 更省事但如果你必须用 OPNET 出图、出统计量那这套东西绕不开。2. AODV 在 OPNET 里的进程模型从状态机到中断注册2.1 为什么 AODV 在 OPNET 里必须拆成进程模型OPNET 的仿真核心是离散事件驱动每个节点上的协议行为都对应一个进程模型process model用状态机state machine描述。AODV 的按需路由特性决定了它不能像 OSPF 那样周期性地泛洪而是由数据包触发路由发现。在 OPNET 里这个“触发”就是流中断stream interrupt和自中断self-interrupt的组合。进程模型里通常会有几个关键状态INIT、IDLE、RREQ_WAIT、RREP_WAIT、ROUTE_ACTIVE。每个状态之间的迁移条件就是收到什么包、超时多久。我一般会先看进程模型里的SV状态变量定义确认RREQ_ID、RREQ_RETRIES、NET_DIAMETER、NODE_TRAVERSAL_TIME这几个参数有没有暴露出来。因为 AODV 的很多行为——比如广播风暴抑制、路由请求重试次数——都直接受这些参数控制。如果资源包里的进程模型把这些硬编码在代码里后期改参数就得重新编译很麻烦。2.2 包格式定义AODV_model 里最容易漏掉的字段AODV 的包格式在 RFC 3561 里有明确定义但 OPNET 里需要用packet format接口重新声明。常见的做法是建一个aodv_pk包格式里面包含Type、Flags、Hop Count、RREQ ID、Destination IP、Originator IP、Life Time等字段。资源包里的.pr文件packet format如果字段顺序和 RFC 不一致仿真时解析就会错位表现为路由表里出现莫名其妙的 IP 或者跳数变成 255。下面是一个典型的 AODV RREQ 包格式定义片段用 OPNET 的包格式描述语言写// aodv_rreq 包格式定义OPNET packet format packet_format aodv_rreq { field Type : 8 bits; // 1 RREQ field Flags : 4 bits; // 保留位通常置 0 field Reserved : 4 bits; field HopCount : 8 bits; // 每转发一次加 1 field RREQ_ID : 32 bits; // 发起节点维护的序列号 field Dest_IP : 32 bits; // 目的节点 IP field Dest_SeqNum : 32 bits; // 目的节点当前序列号 field Origin_IP : 32 bits; // 发起节点 IP field Origin_SeqNum : 32 bits; // 发起节点序列号 }逻辑说明Type字段用来区分 RREQ、RREP、RERR通常 1 是 RREQ2 是 RREP3 是 RERR。HopCount每经过一个中间节点加 1用来防止无限循环同时接收端可以用它判断是否接受更优路径。RREQ_ID和Origin_IP组合起来唯一标识一个路由请求中间节点靠这个做重复包检测。参数说明Dest_SeqNum在 RREQ 里是目的节点已知的最新序列号如果发起节点不知道就置为未知值通常 0中间节点只有在自己的序列号大于等于这个值且路由有效时才回 RREP。2.3 进程注册与中断绑定让 AODV 进程能收到包OPNET 里每个协议进程需要在节点模型里注册绑定到对应的流stream和中断。AODV 通常绑定在udp或ip层之上通过op_intrpt_type()判断是流中断还是自中断。资源包里如果缺少op_pro_id的注册代码仿真启动时就会报“process model not found”或者“no interrupt handler”。一个常见的注册流程是在节点模型的process属性里指定 AODV 进程模型然后在进程模型的INIT状态里调用op_intrpt_register()注册自中断用于处理路由超时。下面这段代码展示了如何在INIT状态里注册一个延迟中断用于 RREQ 重试// 在 INIT 状态中注册 RREQ 重试自中断 // 参数中断码 RREQ_RETRY_INTR延迟时间由 RREQ_RETRIES 和 NODE_TRAVERSAL_TIME 决定 op_intrpt_schedule_self(op_sim_time() RREQ_RETRY_TIMEOUT, RREQ_RETRY_INTR);逻辑说明op_intrpt_schedule_self会在当前仿真时间加上RREQ_RETRY_TIMEOUT后触发一个自中断中断码是RREQ_RETRY_INTR。在状态机的IDLE状态里收到这个中断就检查是否收到 RREP如果没有就重发 RREQ并增加重试计数。参数说明RREQ_RETRY_TIMEOUT通常设为NODE_TRAVERSAL_TIME * 2而NODE_TRAVERSAL_TIME默认是 40 毫秒所以重试超时约 80 毫秒。如果网络直径大这个值要相应调大否则 RREQ 还没到目的节点就重试了反而加剧拥塞。3. 把 AODV_model 跑起来编译、场景配置与第一个仿真3.1 解压后的目录结构与文件作用拿到AODV_model.rar后先别急着往 OPNET 里拖。我一般会先看目录结构典型的布局是目录/文件作用src/进程模型源码.c、.h和状态机描述.pr.minclude/包格式定义、常量头文件scenarios/预置的 OPNET 场景文件.scenarioREADME编译顺序和依赖说明如果src/里缺少.pr.m文件那状态机就得自己画工作量很大。资源包如果只给了.c和.h那大概率是让你替换 OPNET 自带模型里的对应文件而不是从零建进程模型。3.2 编译顺序与常见编译错误OPNET 的编译依赖顺序很严格先编译包格式再编译进程模型最后编译节点模型。如果顺序反了就会报“undefined symbol”或者“packet format not declared”。我一般会在 OPNET 的Modeler里按这个顺序操作打开File Open加载include/下的包格式文件点击Compile。加载src/下的进程模型文件检查状态机是否完整然后Compile。打开节点模型确认 AODV 进程已绑定到正确的流然后Compile。常见的编译错误是op_pk_fd_set的字段类型不匹配。比如包格式里RREQ_ID定义成 32 位但代码里用op_pk_fd_set(pk, RREQ_ID, OPC_INT32, ...)时传了OPC_INT16编译能过但运行时会截断。血泪经验字段类型一定要和包格式定义严格一致否则仿真结果里的序列号会跳变。3.3 场景配置节点数、移动模型与流量注入编译通过后打开scenarios/里的场景文件。如果没有预置场景就自己建一个。关键配置项节点数至少 10 个否则多跳路径不明显。我一般用 20 个节点分布在 1000m x 1000m 区域。移动模型OPNET 自带Random Waypoint但要注意pause time设为 0 会导致节点一直移动路由频繁断裂。建议pause time设为 30 秒以上。流量注入用Application Config加一个FTP或Video业务目的节点随机选。流量速率别太高AODV 在 2Mbps 以下比较稳。配置完后在Simulation菜单里设置仿真时长比如 300 秒然后点Run。第一次跑建议把Animation打开看 RREQ 的泛洪范围是否合理。如果 RREQ 瞬间覆盖全网说明NET_DIAMETER设太大了或者没有做重复包检测。4. 避坑与排查AODV_model 仿真里最常见的 5 个翻车现场4.1 路由表一直不收敛RREQ 反复重发现象仿真跑了几十秒路由表里还是空的或者只有到邻居的路由。RREQ 重试计数很快达到上限然后丢包。原因最常见的是RREQ_ID没有全局唯一或者中间节点没有正确缓存反向路由。AODV 要求中间节点收到 RREQ 后先建立到发起节点的反向路由再转发。如果反向路由没建RREP 就回不去。解决检查进程模型里RREQ处理分支确认在转发前调用了route_table_add()添加反向路由。另外确认RREQ_ID是每个发起节点独立维护的不是全局变量。4.2 仿真跑着跑着就崩溃报“segmentation fault”现象OPNET 直接退出日志里只有一行segmentation fault。原因多半是包指针被释放后再次访问。AODV 里收到 RREQ 后如果决定不转发需要销毁包如果转发就不能销毁。资源包里的代码如果在一个分支里销毁了包另一个分支又去读就会崩。解决用op_pk_copy()复制包再转发原始包该销毁就销毁。或者统一在状态迁移的最后销毁中间只读不销毁。4.3 跳数统计不对RREP 里的 HopCount 是 0现象路由建立后查看路由表里的跳数发现全是 0 或者 1明显不对。原因HopCount字段在转发时没有递增。AODV 规定每转发一次 RREQ 或 RREPHopCount加 1。如果代码里忘了加接收端就以为目的节点就在隔壁。解决在转发分支里加hop_count op_pk_fd_get(pk, HopCount) 1; op_pk_fd_set(pk, HopCount, ...)。注意 RREP 的跳数是从目的节点往回累加的方向别搞反。4.4 移动场景下路由断裂后没有触发 RERR现象节点移动导致链路断开但源节点还在往旧路径发数据丢包率飙升。原因AODV 依赖链路层检测断链然后由中间节点发 RERR。OPNET 里如果无线接收机没有正确上报link failureAODV 就不知道链路断了。解决检查无线管道阶段pipeline stage里的radio receiver是否配置了error model并且把link failure中断映射到 AODV 进程。通常需要在进程模型里处理OPC_INTRPT_LINK_FAILURE类型的中断。4.5 仿真速度极慢一小时跑不完 300 秒现象仿真进度条几乎不动CPU 占用很高。原因AODV 的 RREQ 泛洪如果没有抑制20 个节点就能产生大量重复包。另外OPNET 的Animation如果全开也会拖慢速度。解决在进程模型里加重复包检测用RREQ_ID Origin_IP做缓存收到重复 RREQ 直接丢弃。仿真时关掉Animation或者只开Packet Flow的简化显示。如果还慢把NET_DIAMETER从默认的 30 降到 10减少 RREQ 的传播范围。5. 进阶技巧用 OPNET 的统计量验证 AODV 改动的效果跑通基础仿真只是第一步真正要出论文或者对比协议得会看统计量。OPNET 里 AODV 相关的统计量通常挂在AODV进程和IP层上我一般会重点抓这几个统计量含义怎么看RREQ Sent发起节点发出的 RREQ 总数数值越高路由发现越频繁可能移动太快RREP Received收到 RREP 的次数和 RREQ Sent 的比值反映路由建立成功率Route Errors触发的 RERR 数量越高说明链路越不稳定End-to-End Delay数据包平均端到端时延路由收敛慢会直接拉高这个值Routing Overhead路由控制包占总包的比例AODV 的 overhead 通常比 OLSR 低但移动快时会飙升如果你改动了 AODV 的某个参数比如把RREQ_RETRIES从 2 改成 5那就要对比RREQ Sent和End-to-End Delay的变化。我一般会跑三组默认参数、改后参数、以及一个固定路由的基线。三组跑完用 OPNET 的Results导出 CSV再画图。一个具体的验证技巧在进程模型里加一个自定义统计量记录每次路由发现的跳数。OPNET 支持op_stat_write()写自定义统计量代码片段如下// 在收到 RREP 后记录跳数 // 参数hop_count 从 RREP 包里读取stat_handle 是注册的统计量句柄 op_stat_write(stat_handle, hop_count);逻辑说明op_stat_write会把hop_count写入指定的统计量仿真结束后可以在Results里看到分布。参数说明stat_handle需要在INIT状态里用op_stat_reg()注册名字比如AODV Hop Count。这样你就能直接对比不同参数下的路径长度分布比只看平均时延更有说服力。最后说个我自己的习惯每次改完 AODV 代码先跑一个 10 节点、无移动、单条 CBR 流的小场景确认路由能建起来、数据能通再上大规模移动场景。这个“小场景冒烟测试”帮我省了无数个通宵排查的夜晚。希望帮到你。本文还有配套的精品资源点击获取