简介面向移动自组网仿真的AODV路由协议头文件资源包适合网络协议学习者、无线自组网研究人员及准备开展NS2/NS3等环境仿真的开发者。AODV是一种按需路由协议通过RREQ、RREP、RERR三类消息完成动态路由发现与维护资源精选3个头文件分别对应协议核心结构、报文封装逻辑与路由表管理rar包仅8KB轻量易读便于直接嵌入实验工程或作为协议模块的参考实现。目前已有243人学习下载。借助该资源可快速掌握AODV的数据结构设计与接口划分理解移动节点间路由建立、失效告警及转发表维护的实现要点为后续仿真参数调优和路由性能分析提供代码级支撑也适合作为课程设计或科研入门的基础材料。1. 这个自组网仿真的题最后都比在 AODV 上反复调参课程设计里“移动自组网仿真”这类项目十有八九最后都会落到同一个点上把 AODV 协议放进仿真器里跑出可靠的路由数据。aodv.rar 这个包名在高校里流传很广里面通常就是 AODV 的源码、TCL 仿真脚本和几份统计工具但多数人解压后第一步就卡住——ns-2 装不上、脚本报错、数据对不上。这篇笔记想解决的就是把这个过程从“玄学”变成“可复现”AODV 协议在自组网仿真里究竟怎么工作、怎么搭出第一个能出数据的场景、怎么把 trace 文件算成 PDR 和时延以及那些让人反复翻车的参数坑。适合正在做移动自组网课程设计、毕业设计或者想用仿真验证路由算法的人。2. 自组网仿真为什么绕不开 AODV协议机制与选型参数2.1 AODV 报文交互RREQ→RREP→RERR 与序列号AODV 的全称是 Ad hoc On-Demand Distance Vector Routing中文常译作按需平面距离矢量路由协议。它最鲜明的特点就是“按需”不是像传统距离矢量协议那样周期性全网广播路由表而是当源节点真正要发包且没有可用路由时才发起一次路由发现过程。这个“按需”设计让它在节点频繁移动、拓扑剧烈变化的自组网环境里比周期性交换路由表的 DSDV 更省控制开销。路由发现过程分三步。源节点先广播一条 RREQRoute Request报文这条报文会被中间节点继续转发直到到达目标节点或者到达一个缓存里有到达目标节点有效路由的中间节点。目标节点收到 RREQ 后沿反向路径单播回复一条 RREPRoute Reply。源节点收到 RREP就把这条路径写入路由表开始发送数据。如果链路因为节点移动而断开断链处的上游节点会发起 RERRRoute Error通知相关节点把失效路由标记为不可用。AODV 防环的核心机制是目标序列号Destination Sequence Number。每个目标节点会维护一个单调递增的序列号中间节点只有在“序列号更新、跳数更短”时才会更新路由。仿真里最容易观察到的一个现象是序列号处理不对时RREP 会在两个节点之间来回震荡数据包进入一个死循环trace 里能看到同一个 IP 包被反复转发。这也是为什么你在 ns-2 里打开 aodv.cc 会看到大量对 seqno 的 if 判断。此外AODV 依靠 HELLO 报文维护邻居关系。节点每隔一段时间广播一次 HELLO如果在链路超时时间内没有收到邻居的 HELLO就判定链路断了触发 RERR。ns-2 的 AODV 实现里这个动作是本地链路检测local repair和邻居管理的基础。仿真里如果 HELLO 间隔和链路超时参数配得不合理会出现“路由还在但邻居早走了”的假象。2.2 三种经典协议怎么选AODV 在仿真里为什么最稳做自组网仿真绕不开 DSDV、DSR、AODV 这三个经典路由协议。ds-2 源码里三个协议都自带所以课程包和毕业论文最常拿它们做对比实验。选哪个直接决定后面脚本怎么写、指标怎么解释。我用一个对比表来说明协议路由发现方式是否源路由防环机制控制开销特点适合仿真规模DSDV周期性全网广播否列向量 序列号节点越多开销越稳定小规模、移动较慢DSR按需缓存路由是源路由 缓存校验移动频繁时缓存命中率高中规模适合链式拓扑AODV按需逐跳维护否目标序列号拓扑变化越大开销越高中大规模、移动性随机DSDV 的问题在于周期性广播节点一旦多起来控制报文占比会非常高。DSR 的优势是源路由中间节点缓存里能直接命中但每个数据包头都要带完整路径包越长在低带宽无线链路上的浪费越明显。AODV 站在两者中间按需发现节省了静默状态下的开销逐跳路由又没有源路由的包头开销所以它成为绝大多数自组网仿真项目的默认选择。从工程复现的角度AODV 还有两个现实优势。一是 ns-2 自带的 AODV 实现经过了大量论文验证网上能找到的 trace 分析脚本、对比数据都基于它你有参照物可以对照。二是 AODV 是 IETF RFC 3561 标准协议就算你后续迁移到 ns-3、OMNeT协议行为也是同一套学习投入不浪费。对于课程设计里常做的“AODV 与 DSDV 性能对比”AODV 作为主协议、DSDV 作为参照协议是非常稳妥的组合。2.3 第一批必设参数节点数、面积、移动速度、流量模式自组网仿真里场景参数不是随便填的。AODV 能不能建立路由、建立之后能不能稳住取决于节点密度、运动速度和流量分布。我的经验是拿到一个项目先别急写代码先把下面这组参数定下来参数常用值说明节点数30-60太少拓扑不连通太多 MAC 层冲突严重仿真面积600×600 到 1000×1000面积决定节点密度移动模型Random Waypoint经典默认模型节点速度1-20 m/s速度越高路由断链越快暂停时间0-30 s0 表示持续移动传输范围默认约 250 m取决于物理层模型流量模型CBR over UDP最便于统计丢包和时延仿真时长50-200 s太短冷启动影响大这里有一个我在课程验收里见过无数次的坑节点数 50、面积却设成 2000×2000结果平均邻居数连 2 都不到AODV 的 RREQ 发出去根本没人响应PDR 直接是 0。自组网要能工作节点密度必须先满足网络连通性。802.11 节点传输范围 250 米时在 1000×1000 的区域内放 50 个节点平均每跳覆盖半径大约 125 米网络还能连通如果这个密度再减半基本就是孤立节点集合。节点移动速度也是关键变量。AODV 是反应式协议速度从 5 m/s 提到 20 m/s断链频率会明显增加RREQ 重发次数和 RERR 报文数量都会上升。做性能对比实验时固定其他条件、只扫速度这一维度是很容易出趋势的题目。流量模式建议用 CBR over UDP因为 TCP 的拥塞控制会干扰路由层表现你很难把“丢包”归因到路由还是传输层。3. 在 ns-2 里把 AODV 仿真跑起来最小命令与 TCL 场景3.1 安装环境并确认 AODV 模块存在移动自组网仿真最传统的平台是 ns-2版本以 ns-2.35 最为常见。AODV 作为内置路由协议源码在 ns-2.35 的aodv目录下并不需要额外下载。但实际课程包里经常带着一份别人改过的 aodv 源码比如加了能量模型、修改了 hello 机制这就需要你把它覆盖到源码目录里重新编译。先做环境检查命令如下# 检查 ns 命令是否可用 which ns ns -version # 如果 ns 不可用在 Ubuntu/Debian 上直接装二进制包 sudo apt-get install ns2 # 确认 AODV 模块文件存在 find /usr -type d -name aodv 2/dev/null ls /usr/lib/ns2/aodv 2/dev/null安装完成后重点看两样东西aodv.cc和aodv.h是否编译进了解释器以及 TCL 脚本里能否用Agent/AODV这个类名。我一般会在 TCL 脚本里加一行puts $ns info class Agent/AODV来验证能输出版本信息就说明 AODV 类加载成功。如果你拿到的是 aodv.rar 这类源码包解压后先看包里有没有Makefile.in改动记录或者直接按make clean make重新编译避免旧.o文件没被替换而导致运行时报 invalid command。# 从源码目录重新编译 ns-2.35 cd ns-2.35 ./install 21 | tee build.log # 确认 aodv.o 已生成 ls -l aodv/aodv.o编译这一步最容易出问题的是 GCC 版本过高。老项目基本是按 GCC 4.x 写的在 Ubuntu 20.04 以上的环境直接 make 会碰到 C 语法报错。常见做法是安装gcc-4.8并指定CXXg-4.8重新配置或者干脆用 apt 装现成的ns2包只要不再改 AODV 源码自带模块就够跑。3.2 写一个 50 节点随机路点的 AODV 仿真 TCL 脚本下面这个 TCL 脚本是一个“最小可出数据”的 AODV 自组网仿真场景。50 个节点在 800×800 米区域内随机分布CBR 流量共 10 条流仿真时长 60 秒路由协议指定为 AODV。这个脚本基于 ns-2.35 的老式 trace 格式编写便于后续用 awk 直接统计。# 移动自组网 AODV 最小仿真场景 # 50 个节点800x800 米Random Waypoint 移动10 条 CBR 流 set val(nn) 50 set val(x) 800 set val(y) 800 set val(stop) 60 set val(rp) AODV set val(ifqlen) 50 set ns [new Simulator] set tracefd [open aodv_tr.tr w] $ns trace-all $tracefd set namtrace [open aodv_nam.nam w] $ns namtrace-all-wireless $namtrace 800 set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) # 物理层与 MAC 层参数保持默认既有范围 Phy/WirelessPhy set bandwidth_ 11Mb Mac/802_11 set basicDataRate_ 1Mb Mac/802_11 set dataRate_ 11Mb # 无线移动节点统一配置 $ns node-config -adhocRouting $val(rp) \ -llType LL \ -macType Mac/802_11 \ -ifqType Queue/DropTail/PriQueue \ -ifqLen $val(ifqlen) \ -antType Antenna/OmniAntenna \ -propType Propagation/TwoRayGround \ -phyType Phy/WirelessPhy \ -channelType Channel/WirelessChannel \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF # 创建节点并随机初始化位置 for {set i 0} {$i $val(nn)} {incr i} { set node_($i) [$ns node] $node_($i) set X_ [expr {int(rand()*$val(x))}] $node_($i) set Y_ [expr {int(rand()*$val(y))}] $node_($i) set Z_ 0 } # 每个节点在 0-20 秒内随机选择新地点以 5m/s 移动 for {set i 0} {$i $val(nn)} {incr i} { set xd [expr {int(rand()*$val(x))}] set yd [expr {int(rand()*$val(y))}] $ns at [expr {int(rand()*20)}] $node_($i) setdest $xd $yd 5 } # 10 条 CBR 流源节点 0-4目标节点 10-19 for {set i 0} {$i 10} {incr i} { set src [expr {$i % 5}] set dst [expr {10 $i}] set udp [new Agent/UDP] $ns attach-agent $node_($src) $udp set null [new Agent/Null] $ns attach-agent $node_($dst) $null $ns connect $udp $null set cbr [new Application/Traffic/CBR] $cbr set packetSize_ 512 $cbr set interval_ 0.25 $cbr attach-agent $udp $ns at [expr {5 $i}] $cbr start $ns at $val(stop) $cbr stop } proc stop {} { global ns tracefd $ns flush-trace close $tracefd exit 0 } $ns at $val(stop) stop $ns run这个脚本最关键的是node-config必须在创建节点之前执行否则后续节点不会带上无线接口trace 里全是NO TYPE之类的报错。ifqType我特意写的是Queue/DropTail/PriQueue这是 AODV 仿真的一个隐形要求路由发现期间数据包要在节点队列里等待AODV 的控制报文需要优先出队。如果你换成普通 DropTailAODV 的 RREQ 可能被数据包堵在队列尾部导致路由发现超时。create-god是 ns-2 无线仿真里的全局调度实体参数必须和节点数一致。位置随机生成用了 Tcl 的rand()每次运行都会不同这其实是好事——多次跑取平均能消掉随机性影响。如果需要完全可复现可以加一行ns-random 1固定种子或者用 setdest 生成固定移动轨迹。3.3 运行脚本并检查 trace 输出把脚本保存为aodv_sim.tcl在终端执行ns aodv_sim.tcl # 查看输出文件 ls -lh aodv_tr.tr wc -l aodv_tr.tr # 看 AODV 控制报文是否真的出现在 trace 里 grep aodv aodv_tr.tr | head -n 5正常运行时aodv_tr.tr会很快增长到几十万行。grep 输出应该能看到 RREQ、RREP、RERR 等报文记录。如果 trace 里只有 cbr 数据而没有 aodv 控制报文说明路由协议类没加载成功如果完全没有AGT层收包记录则说明节点间没有建立任何链路要去查密度和传输范围参数。这一步跑通了数据的处理才有意义。4. 从 aodv_tr.tr 到 PDR、平均时延、路由开销awk 统计一步步拆4.1 trace 行结构与 AODV 报文的识别ns-2 的老式无线 trace 每行有固定字段我常用的判断规则是$1表示事件类型s是发送r是接收d是丢弃是入队-是出队$2是时间戳$3和$4是收发节点编号$5是报文类型。比如 cbr 数据报文、aodv 控制报文。一个典型的 AODV 控制行长这样r 1.025314 _8_ RTR --- 0 AODV 48 [0 0 0 0] 0 0 [0 8 0 0] 0 8其中_8_是节点编号RTR表示报文发生在路由层AODV是协议类型。统计路由开销时直接数AODV行的数量即可。数据报文则是AGT层产生、类型为cbr的行。统计前先确认你用的是老式 trace 格式也就是 TCL 里不要加$ns use-newtrace。新格式字段顺序不同脚本要跟着改容易乱。4.2 用 awk 计算 PDR、平均时延和丢包数下面的 awk 脚本按“发送 cbr 时记录时间接收 cbr 时匹配序列号计算时延”的思路统计。需要注意$11在 ns-2 老式 trace 中是序号字段同一序号如果发生重传后发送的时间会覆盖先发送的时间这在 CBR 流里基本可忽略。awk { event $1 type $5 seq $11 time $2 if (event s type cbr) { send_time[seq] time send_ct } if (event r type cbr) { recv_ct if (send_time[seq] ! ) { delay_sum time - send_time[seq] delay_ct } } if (event d type cbr) { drop_ct } if (type aodv) { aodv_ct } } END { if (send_ct 0 recv_ct 0) { pdr recv_ct / send_ct avg_delay delay_sum / delay_ct } else { pdr 0 avg_delay 0 } printf send%d recv%d drop%d PDR%.4f avg_delay%.4f AODV_ct%d\n, send_ct, recv_ct, drop_ct, pdr, avg_delay, aodv_ct } aodv_tr.tr这段 awk 的逻辑不复杂但有一些细节要说明。send_ct统计的是 AGT 层的 cbr 发送不是 MAC 层发送同一数据包在路由转发过程中会被中间节点再发送一次但那一行发生在新 trace 没法逐跳级里统计时只认 AGT 层否则 PDR 会被重传数据拉高。delay_sum用的是接收时间减去源节点发送时间这是端到端时延如果还想拆出路由发现时延就得单独对第一个 RREQ 到 RREP 的时间段做分析。路由开销用AODV_ct除以recv_ct或者除以send_ct得出“每成功收到一个数据包需要多少控制报文”。这个比值是自组网论文里很常见的一个指标但它必须说明统计范围因为 RREQ 每跳转发都会计一次跳数越多开销越大。4.3 批量跑多个场景用 Python 画出趋势单次仿真的 PDR 其实没有太大说服力。我会固定随机种子跑三种不同协议或者固定协议扫三组节点数把数据汇总后画折线。这里给出一个简单的 Python 脚本用来读取多组结果并绘出 PDR 趋势import matplotlib.pyplot as plt x [30, 50, 70] pdr [0.65, 0.78, 0.71] plt.plot(x, pdr, markero) plt.xlabel(node count) plt.ylabel(packet delivery ratio) plt.title(AODV simulation) plt.grid(True) plt.savefig(pdr_trend.png)画图本身不是重点重点是每次跑完要保留三样东西TCL 脚本、trace 文件和 awk 计算结果。很多项目最后被导师追问数据来源时都是因为只留了截图没留 trace结果无法复现只能重跑。我自己的习惯是每次改参数前先备份一份脚本文件名里带节点数、速度和流量数例如aodv_n50_s5_f10.tcl这样批量做参数扫描时才不会把结果和配置对应错。5. 自组网 AODV 仿真避坑清单5 次踩坑记录与处理方式5.1 PDR 为 0场景密度根本没连通现象仿真跑完trace 文件很大但 awk 统计的 recv_ct 是 0send_ct 有几千。打开 NAM 能看到节点各自移动却几乎没有数据包到达。原因最常见的两个一是场景面积太大、节点太稀疏AODV 的 RREQ 广播找不到目标二是移动节点创建时没有正确设置X_、Y_所有节点初始位置都堆在0,0附近早期链路建立后节点迅速移出传输范围后续路由全部失败。解决先算一下节点平均邻居数。800×800 区域、50 节点、传输范围 250 米时理论平均邻居数约 15 个够用面积不变、节点降到 20平均邻居数不到 6AODV 基本就是半瘫痪。遇到 PDR 为 0第一件事不是改 AODV 参数而是把面积缩小到 600×600或者把节点数提到 50 以上把密度问题先解决。5.2 trace 里全是 RREQ、没有 RREP路由发现活着但找不到目标现象grep 统计发现 AODV 控制报文里 RREQ 占了 95% 以上RREP 极少CBR 根本没流量。仿真日志里还能看到timeout waiting for RREP之类的超时记录。原因目标节点不可达或者 RREQ 被 MAC 层丢弃。后者在节点密集时尤其明显RREQ 广播会造成广播风暴MAC 层冲突加剧RREQ 还没发出去就被丢弃。另一类原因是 HELLO 机制和链路检测参数不匹配节点判定邻居在线但实际链路质量已经差到数据帧传不过去。解决先把节点数降下来确认密度不是过度拥挤。然后调整 AODV 类属性比如在 TCL 里加一行Agent/AODV set hello_period_ 1000缩短邻居探测周期让节点更快发现链路断了去重新找路。如果还不是就把ifqLen从 50 提到 100因为 RREP 回来时如果队列已满也会被直接丢弃结果就是 RREQ 反复重发。5.3 PDR 超过 100%统计口径把控制报文算进去了现象awk 算出来的 PDR 是 1.3也就是收到了 130% 的“发送量”一看就不合理。检查 trace 才发现自己把 MAC 层重传和 AODV 控制报文也放进了接收计数。原因统计时没有只认 AGT 层的 cbr 发送行。AODV 的控制报文同样是r事件如果只看事件和报文类型而不限制层控制报文就会被当作数据报文。另外多跳传输中同一个数据包会在每个中间节点产生一条、-、r记录中间节点的r不是最终接收。解决awk 里严格加两个条件$1 s $5 cbr统计发送、$1 r $5 cbr统计接收并且确认这些行的层字段是 AGT 而不是 RTR 或 MAC。如果 trace 里层信息不好判断就只统计带AGT标记的行。统计前先跑一个 2 节点直连的最小场景手动验证 PDR 应该等于 1再上大场景。5.4 多组实验跑出来数据一模一样随机种子没有变化现象改了几次节点移动速度PDR 和时延曲线几乎完全一致怀疑是自己脚本写错了。实际上是因为每次运行都用了相同的随机种子连移动轨迹、流量启动时间都完全相同唯一变化只有速度参数而该参数对拓扑没有影响。原因ns-2 里的rand()默认由同一个全局随机源驱动TCL 脚本没有重新播种时每次ns执行产生的随机序列是同一份。多组对比实验里如果只改速度但移动轨迹还是一样的结果的差异只会来自路由层对速度的反应而不是拓扑随机性。解决在 TCL 脚本开头加一行ns-random [expr {int(rand()*10000)}]或者直接给每个实验指定不同种子值。更严谨的做法是用 setdest 工具先生成多个移动场景文件例如生成mob1.tcl、mob2.tcl再在仿真脚本里通过变量source mob1.tcl加载。这样拓扑变化和速度变化是解耦的后续归因才说得清。5.5 node-config 顺序错误导致节点无无线接口现象脚本看起来没问题但运行时报错提示节点不存在setdest操作或者 trace 行中完全没有 MAC 层记录。更隐蔽的情况是 NAM 里所有节点都画成普通有线节点。原因$ns node-config语句放在了节点创建之后。ns-2 的无线节点属性在创建那一刻就被固化之后修改配置不会影响已创建的节点。这个问题在很多派生课程包里都有因为作者把 node-config 和参数初始化写在不同 section复制粘贴时顺序丢了。解决务必按照“先全局参数、再 node-config、再创建节点、再设置移动和流量”的顺序组织脚本。我把这条贴在实验日志第一页如果新建的节点没有带无线接口先看 node-config 有没有跑到for循环前面。这个问题排起来非常费时因为报错往往不在第一屏而是在几十秒后才暴露出来。6. 把多组 AODV 结果做成可信结论批量跑、稳定性校验和 ns-3 出路仿真项目的验收通常不只问“出了什么数”更会追问“这个数可信吗”。我现在的固定做法是同一组参数跑 5 个不同随机种子取平均值和方差。如果 PDR 在 3 个不同种子下波动超过 0.1就说明场景本身不够稳定增加仿真时长或者调整节点密度后重跑而不是直接拿单次结果去写报告。批处理可以这样写for seed in 1 2 3 4 5; do ns-random $seed ns aodv_sim.tcl awk -f calc.awk aodv_tr.tr result_${seed}.csv done稳定性校验还有一个更快的办法在同一个场景里只改路由协议把 AODV 换成 DSDV 或 DSR看 PDR 是否有明显变化。如果 AODV 和 DSDV 结果几乎一样通常是场景太简单、节点基本静止协议的按需优势根本没发挥出来。这时候要加大移动速度或场景面积让路由协议真正面对拓扑变化。这个对照实验做出来整篇报告的说服力会高不少。如果 ns-2 在你当前系统上始终编译不过学校作业又有交源码的要求可以考虑迁移到 ns-3。ns-3 里有完整的 AODV 模块接口比 ns-2 干净trace 采集用pcap或 flow monitor 都更省事。但要注意ns-3 的 AODV 和 ns-2 的 AODV 在默认参数上不完全一致跨平台对比时不能直接说“相同协议在不同版本结果必然一致”要在论文里说明两套环境的差异。AODV 作为经典协议跑通它并不难难的是让每个数据都能被追溯、每个参数都有据可查。我自己吃过最大的亏就是一次实验里改了三个变量却只留了一组结果答辩时被问得哑口无言。自那以后每次跑仿真都会留一份带完整参数的日志。这个习惯希望能帮你少走一点弯路。本文还有配套的精品资源点击获取