企业官网建设流程全解析

简介：基于OPNET的移动自组织网络仿真实例包，面向网络方向的研究生、通信专业师生以及从事无线网络仿真的工程师，可用于理解自组织、无中心、动态拓扑与节点资源受限等MANET核心特点，并评估不同路由协议在典型移动场景下的性能表现。压缩包共54个文件，以1个prj工程文件为入口，配以27个m模型文件、14个seq序列文件和12个ac辅助配置文件，整体大小约296KB。文件按多组实验场景组织，覆盖AODV、DSR、TORA、OLSR、GRP等主流MANET路由协议，提供50节点与100节点规模、站点移动、集群网络、默认参数与降路由开销等多种仿真配置，便于对比节点规模、移动性、背景流量对端到端时延、丢包率和吞吐量的影响。研究时可结合自组织、多跳通信、能量效率等真实约束，分析协议在负载变化下的适应能力。目前已有838人浏览/学习，适合用作OPNET仿真入门练习和MANET协议研究的基础素材。

1. 别急着找资源，先想清楚 OPNET 里 MANET 仿真实例到底能替你解决什么

做无线自组织网络方案预研时，最尴尬的情况是：你需要在几个路由协议之间选型，但手头只有论文里的曲线和静态的拓扑分析，拿不出自己环境下的数据。OPNET 里的 MANET 仿真实例，解决的就是这个"拓扑持续变化"带来的量化难题——节点在场景里移动、链路断开重建、路由协议重新收敛，这些过程会被离散事件仿真完整记录成延迟、吞吐量、路由开销曲线。标题里这个实例包的价值，不是让你跑通一个 Demo 交差，而是给你一整套已经组合好的 MANET 场景：无线节点模型、路由协议配置、移动轨迹、业务负载和统计量都配好了，你只需要改参数、跑仿真、看对比。适合做课程设计的学生、做无线网络方案选型的工程师，以及想把 Ad Hoc 协议对比做成可复现实验的开发者。但拿到资源只是起点，搞不懂场景里每个模块在干什么，跑完也只能得到几张说不清含义的图。

2. 拆开 MANET 实例的模型栈：OPNET 里哪些模块决定了仿真能不能出数

2.1 节点模型：manet_station 不是一台"路由器"，而是一台完整的协议栈

在 OPNET 里部署 MANET 节点，最常见的模型是 manet_station。我习惯把它叫"协议栈打包机"，因为它把应用层、传输层、网络层、MAC 层和物理层一次性打包在一个节点里。展开节点的进程域，能看到 TCP、UDP、IP、MANET 路由进程、WLAN MAC，以及一对无线收发机（接收机 rx 和发射机 tx）。这意味着你跑一次 Ad Hoc 仿真，其实是在同时验证七个模块的配合。理解这一点，很多配置错误就有了解释。

比如有 A 同学，在 manet_station 里只配了路由协议，应用层什么都没挂，跑完发现全网零流量。为什么？因为 MANET 仿真里的数据包需要上层业务产生，路由协议只负责按表转发，自己不产生包。manet_station 的协议栈完整，不代表它会自动帮你发包。另一个认知误区是把 manet_station 当普通路由器，给它加一堆有线接口。实际上 MANET 节点默认依靠无线接口通信，节点之间通过 IP 层是否可达来决定路由行为，不是靠拓扑图上的连线。所以配置节点时，盯住的是无线参数组，而不是画布上的链路。

从实操角度看，我拿到一个实例场景，第一步永远是先把节点模型认全：先看节点属性里有哪些模块组，再看每个模块组里哪些参数暴露出来了。这一遍花十分钟，能避免后面所有"现象无法解释"的问题。MANET 仿真里的奇怪结果，十个有八个不是随机数问题，而是模型栈里某一层配置错位了。

2.2 路由协议在 OPNET 里的真实身份：进程模型与属性表

MANET 实例里最核心的可变量就是路由协议。在 OPNET 中，AODV、DSR、OLSR 这些协议并不是"安装进去"的插件，而是以进程模型的形式挂在节点网络层之下的独立进程。配置入口通常在 manet_station 节点属性里的 MANET 或 Ad Hoc Routing 分组下，下拉框里能看到 AODV、DSR、OLSR 等选项。

这里有一个新手必踩的认知差：下拉框选了 AODV，不等于 AODV 真的在跑。路由协议要生效，网络层（IP）必须知道"应该把路由决策交给这个 MANET 进程"。常见做法是，把节点属性里 IP 协议组的配置项保持为"使用 MANET 路由"，而不是默认的静态或动态路由。如果 IP 层设置和 MANET 协议不一致，仿真能跑，但所有节点之间互不可达，抓包看全是路由错误消息，数据业务一条都送不出去。

选协议不只是选名字。AODV 和 DSR 都是按需路由，OLSR 是表驱动路由，它们对 Hello 包间隔、路由缓存时间、TC 消息周期的敏感度完全不同。在实例里，这些参数字段都平铺在协议对应的属性组下。所以后面讲参数配置时，协议类型决定结果大趋势，参数取值决定曲线细节。做对比实验时，这两层要分清楚，不要混在一起改。

2.3 移动模型：为什么 Random Waypoint 是默认项，以及它绑在哪一层

MANET 仿真和固定网络仿真最大的区别，是节点位置随时间变化、链路会断。OPNET 里控制这个行为的是移动模型，最常用的是 Random Waypoint：节点随机选一个目标点、按某个速度匀速移动、到达后停留一段时间，再选下一个目标点。这个模型实现简单、结果可复现，所以绝大多数 MANET 实例默认用它。

移动轨迹在 OPNET 里的配置位置，在节点属性的 Trajectory 或 Mobility 分组下。选 Random Waypoint 后，会出现一组参数：开始移动时间、移动速度范围、暂停时间、移动范围。速度范围可以设成 Uniform(5, 20) 这种分布，也可以用 Constant 固定值。移动范围默认是整个场景，节点会在边界内随机游走。我强调一下"绑在哪一层"：移动模型挂在节点级别，不是挂在路由协议里。它影响的是节点地理位置，路由协议通过位置变化去判断链路可用性。所以调试时，检查顺序是先看节点有没有移动，再看路由协议有没有收敛，最后才查业务配置。

另外一个容易被忽略的点：Random Waypoint 有著名的"速度衰减"现象，长时间运行后节点平均速度会偏低。如果目标是仿真高速移动场景，建议改用 Random Direction 或自定义带方向的轨迹向量，而不是把 Random Waypoint 的速度范围调得很大。仿真时长有限，节点可能还没跑出几次完整移动，统计窗口就结束了，这时曲线代表的是"低速段的表现"而不是你想要的"高速段表现"。

2.4 网络拓扑与业务模型：节点数、场景范围、业务强度三者要一起调

MANET 实例里常见的默认配置是几十个节点、一个 1km 见方的场景。但很多人直接照搬这个规模，结果发现丢包率极高或路由开销占比离谱。问题不在随机数，而在三个量之间的匹配关系：节点数决定网络密度，场景范围决定通信距离，业务强度决定信道竞争压力。

举例来说，同样 30 个节点，放在 500m×500m 场景里，节点平均距离近、链路可用性好，丢包主要来自 MAC 层竞争；放到 1500m×1500m 场景里，平均距离拉远，大量链路处于覆盖半径边缘，丢包主要来自物理层不可达。这两种情况下的最优路由参数完全不同。所以拿到实例后第一件事不是改协议，而是确认场景尺寸和节点数量是否匹配你想要的网络密度。一个快速检查法是算节点平均邻居数，低于 3 到 5 个时，任何路由协议都很难维持可靠通信。

业务模型同样影响判断。实例里一般用 Application Config 和 Profile Config 定义业务，比如在指定节点对之间跑 FTP 或轻量 HTTP。业务一重，路由开销占比和端到端延迟都会被显著拖高。做协议对比时，所有场景要使用完全相同的业务配置，否则你比较的不是协议差异，而是业务强度的差异。这个坑我见过太多次，后面避坑章节专门展开。

3. 把 MANET 仿真实例跑起来：从建场景到导出结果的 6 个落地步骤

3.1 新建工程与场景：模板怎么选决定后面少踩多少坑

以你手头的 MANET 实例资源为例，常见做法是先在 OPNET 里建一个工程，再新建一个场景。场景向导里如果提供无线或 Ad Hoc 相关模板，优先用模板；没有模板就直接选空场景，从对象面板切换到 MANET 支持的模型库，再拖节点。模板的价值在于它会把全局统计量、仿真时长、默认业务配置一次性初始化好，减少后续遗漏。

工程命名我建议直接用协议名做区分，比如 AODV_scene、OLSR_scene，不要在同一个场景里反复切换协议。OPNET 场景一旦建好，很多统计量按场景名存储，场景名混乱，后面批量对比结果时会非常被动。这个命名习惯我从第一次跑 MANET 仿真用到现在，没吃过亏。

3.2 部署 MANET 节点并绑定移动轨迹

从对象面板拖入 manet_station，放置足够数量的节点，然后统一选中右键编辑属性。这里有一个效率技巧：先把一个节点的属性配置完整，确认无误后复制粘贴出其余节点，再统一微调位置和名称。逐个配置几十个节点不仅慢，而且容易漏项。复制出来的节点会继承全部属性，包括移动轨迹和路由协议，这是批量部署最快的方式。

绑定移动轨迹的操作：选中节点，在属性里找到 Trajectory 或 Mobility 项，设为 Random Waypoint，然后展开子属性。速度范围、暂停时间、移动范围这三项是必调的。速度建议按场景尺度设置，小场景里速度超过 20m/s 会导致节点频繁跑出边界后掉头，统计里会出现大量瞬时断链，这些数据点会污染延迟曲线。配置完移动属性后，建议先做一次极短仿真（比如 10 秒仿真时间），确认节点坐标真的在变化。这一步能提前暴露"轨迹没绑上"的问题，省得跑完长仿真才发现。

3.3 选好并激活路由协议：AODV 与 OLSR 的配置入口

在节点属性里找到 MANET 路由协议配置组，把协议类型切到 AODV 或 OLSR。注意这一步只是选择协议进程，还要同步确认网络层配置用的是 MANET 路由决策。常见做法是把两者放在一起检查：一侧是协议下拉框，另一侧是 IP 层转发决策配置，两个都到位了，AODV 才算真正激活。只改协议不改 IP 层配置，是路由"不生效"类问题的头号来源。

选 AODV 时，重点看这几个参数：Hello 间隔、路由表超时时间、路由请求重试次数。Hello 间隔决定邻居发现速度，默认值偏保守，高移动场景下建议调小；路由表超时时间决定失效路由的清理速度，调长了会转发到过期路径上。选 OLSR 时，重点看 Hello 间隔、TC 消息周期和邻居表超时时间。OLSR 是主动协议，TC 周期直接决定全网路由收敛速度和开销。一个参数技巧：做对比实验时，AODV 和 OLSR 的 Hello 间隔尽量保持同一数量级，避免把"参数差异"误读成"协议差异"。协议类型是自变量，参数尽量对齐，才是干净的对照实验。

3.4 配置业务负载：Application 与 Profile 的绑定关系

业务负载是 MANET 实例里最容易"跑飞"的部分。先拖入 Application Config 节点定义业务类型，比如 FTP 或轻量 HTTP；再拖入 Profile Config 节点，把应用挂到 Profile 下面；最后选中 MANET 节点，在属性里把 Application 配置成"支持指定 Profile"。三者的绑定关系是：应用定义内容，Profile 定义使用方式，节点决定谁在用。

业务负载的两个关键参数：请求间隔和包大小。请求间隔决定业务密度，包大小决定单包传输时长。做低负载与高负载对比时，优先调请求间隔，因为它对信道竞争的影响更直接。包大小影响的是分片和重传行为，调它容易把问题引入 MAC 层，那是另一个深坑。初次跑实例时，先用低负载把链路跑通，确认路由和移动都正常，再加负载。直接上高负载，结果里全是拥塞和冲突，你分不清是协议问题还是业务强度问题。

3.5 选择统计量：全局统计与节点统计分开看

运行仿真之前，先把统计量选好。常见错误是仿真跑完再去找统计量，结果发现某些指标没勾选，只能重跑。我一般会同时勾两组：全局统计里选路由开销和端到端延迟，节点统计里选 WLAN 的吞吐量和丢包率。全局统计回答"网络整体表现如何"，节点统计回答"某一跳链路是否健康"。两组合起来才能判断现象是协议层面的还是链路层面的。

举例来说，端到端延迟高，全局能看出来；但延迟是排队导致还是重传导致，要看节点的队列长度和重传次数。勾完统计量后，在场景上确认统计量列表里能看到"MANET 相关统计"这一层级，确认协议进程的统计量真的暴露出来了。有些实例包会把路由统计默认关闭，不在这一步打开，后面导出结果时你会发现自己只有业务延迟，没有路由开销，对比实验的结论单薄一半。

3.6 运行 DES 并导出数据：时长、种子与结果输出

配置好仿真后进入 DES 设置项，把仿真时长设置成业务稳定运行的分钟数，比如 600 秒仿真时间。注意仿真时长是模型世界里的时间，不是墙钟时间。仿真种子建议跑多个，比如 5 个种子，最后结果取平均，做对比时曲线不会因为单次随机性失真。前期调试用短时长和单种子快速验证逻辑，确认无误后再加长时长和多种子跑正式数据。

仿真结束后在 View Results 里查看曲线。需要导数据时，右键曲线图，选择导出为文本或表格文件。导出的数据是带时间戳的序列。我习惯用一个小的批处理把每次运行的结果归档，避免后面对比时找错文件：

for scene in AODV_scene OLSR_scene; do mkdir -p results/$scene cp "$scene/packet_delay.txt" results/$scene/ 2>/dev/null cp "$scene/throughput.txt" results/$scene/ 2>/dev/null done

这个脚本做的事，是把每个场景跑出来的延迟和吞吐量结果按场景归档到 results 目录。cp 命令的源路径取决于你导出文件时保存的位置，实际使用时换成你导出文件所在的目录。2>/dev/null 的作用是忽略不存在的文件报错，因为不同版本导出的统计量文件名会有差异，先跑通归档流程再回头补缺失项。导出数据时还有一个小习惯：每个统计量文件里通常带注释行，以 # 或引号开头，解析时要把这些行过滤掉，这个细节留到第六章的脚本里处理。

4. 一份可以照抄的 MANET 仿真参数表：无线、路由、业务、仿真四层

4.1 无线参数：数据速率、发射功率与接收门限的匹配关系

MANET 节点之间的通信质量，主要由三组无线参数决定。数据速率决定单包传输时间，发射功率决定覆盖半径，接收门限决定误码容忍度。三者必须匹配：发射功率调大但接收门限不变，覆盖半径变大但接收灵敏度没变，边缘链路的实际吞吐反而是下降的。我见过有人只调功率不调门限，结果丢包率不降反升，这类问题最难查，因为参数本身看起来都是合理的。

这里提醒一句：发射功率不是越大越好。功率大覆盖远，但信道竞争范围也变大，相距较远的节点对之间会互相干扰。做参数扫描时，功率按倍数步进而不是线性步进，效果更容易看清。无线参数的核心思路是：先确定你想要的覆盖半径，再反推功率和门限，而不是先给个功率看结果。

4.2 路由协议参数：AODV 的 Hello 间隔与 OLSR 的 TC 周期

AODV 属按需路由，只在需要通信时才发起路由发现。它的关键参数是路由请求（RREQ）重发次数和路由表超时时间。重发次数太少，弱链路环境下路由发现成功率低；太多，广播风暴会把低带宽信道打满。我一般从默认值开始，把重发次数加一倍，同时在低负载场景下验证开销增量，再决定要不要保留。

OLSR 属表驱动路由，全网节点周期性交换 Hello 消息和 TC 消息。Hello 间隔决定邻居发现精度，TC 周期决定全网拓扑同步速度。TC 周期越短，路由收敛越快，但控制开销越大。高移动场景下，TC 周期缩短带来的收益往往比调 Hello 间隔更明显，因为 OLSR 的路径质量依赖全网拓扑的新鲜度。下表是我在一组模拟场景里用过的初始参数，可以直接抄：

做协议对比时有个原则：除了协议类型这个自变量，其他参数尽量对齐。AODV 的 Hello 间隔和 OLSR 的 Hello 间隔如果差一个数量级，你得出的差异可能是参数差异而不是协议差异，这个结论拿到评审会上会被一句话问倒。

4.3 业务参数：发包间隔比包大小更影响结果

MANET 仿真的业务参数里，发包间隔对结果的影响远大于包大小。原因是 MANET 信道是共享的，每个节点都在竞争同一片频谱。发包间隔短，同时竞争的业务流就多，MAC 层退避和重传显著增加。包大小主要影响单次传输时间和分片概率，在大包场景下才需要重点关注。

做协议对比时，业务参数在所有场景里保持一致，这是对照实验的基本要求。如果你发现两个协议曲线差异巨大，先检查业务配置是否被某个场景的 Profile 覆盖了。这个错误很隐蔽，因为场景复制时 Profile 配置可能被带了过去，但节点的"支持 Profile"列表未必同步更新。检查方法是选中节点看属性，确认每个节点挂的 Profile 名字完全一致。

4.4 仿真控制参数：时长、种子与预热期

仿真控制参数是最容易被忽略的一层。仿真时长太短，业务还没进入稳定状态曲线就结束了；太长，一台机器要跑好几个小时。种子数决定随机性覆盖，多个种子取平均才能压掉单次随机性的噪声。预热期让路由协议完成邻居发现和路由表建立，这期间的数据不应该计入统计。

我一般这样配：仿真时长 600 秒，前 60 秒算预热期；种子至少 5 个；路由协议的统计量在全局统计里打开，业务级别统计在节点统计里打开。前期调试用"短时长+单种子"，确认逻辑无误后再用"长时长+多种子"跑正式数据。两种参数配置分开存，用场景名后缀区分，比如 AODV_scene_dbg 和 AODV_scene_final，避免正式跑的时候误用了调试参数。

5. MANET 仿真实例避坑指南：5 个让我白熬一周夜的坑

5.1 节点一动不动：移动轨迹配了等于没配

现象：仿真跑完，动画里所有节点静止在原地，生成的轨迹图上节点位置始终不变。但节点属性明明选了 Random Waypoint。

原因有两种。一是移动属性配在了节点上，但仿真运行视图的轨迹刷新被关闭，节点其实在动，只是画面没更新；二是移动配置层选错了，某些版本里节点属性存在两个移动相关的层级，一个是轨迹向量，一个是漫游配置，只填了其中一个，进程根本没读取到。

解决：先确认视图设置里开启了轨迹显示，再看属性层级。我习惯在节点属性里直接搜 mobility 关键词，把所有移动相关属性摊开逐一检查。确认无误后，用极短仿真时长（比如 10 秒）快速验证节点坐标是否变化，比直接跑长仿真节省大量时间。这一步放在场景配置完成后立刻做，不要等到正式仿真跑完才发现。

5.2 路由协议"选了但没生效"：协议与网络层配置不匹配

现象：节点属性里选了 AODV，仿真跑完发现全网数据包投递率几乎为零，但路由进程的统计量里有事件发生。

原因：MANET 协议进程在跑，但 IP 层没有把路由决策权交给它。IP 层可能还在用静态路由或默认路由，导致 AODV 计算出的下一跳根本没被用于转发决策。

解决：把节点属性里 IP 层相关配置改为使用 MANET 的转发决策，同时确认协议进程绑定的模块是网络层对应的那个进程槽位。不同版本里这个配置项的路径不一样，但关键词基本是 IP 和 MANET 的组合。排查时用抓包或路由表视图看一下，节点上有没有生成去往目的地的动态路由条目，能直接确认协议是否生效。这个检查比看统计量更快更准。

5.3 仿真结果全为零：统计量没勾对或者采集窗口太短

现象：仿真正常结束、无报错，但延迟和吞吐量曲线全是水平直线，数值为零。

原因：统计量根本没勾选，或者业务在预热期结束后还没开始发包，采集窗口内就没有数据包被统计到。

解决：打开统计量配置，重新勾选全局统计里的路由延迟和 WLAN 吞吐量。同时检查业务 Profile 的起始时间，确保业务在统计采集窗口内已经激活。我踩过一次最冤枉的：业务 Profile 配置里起始时间设了 1000 秒，仿真只跑了 600 秒，整个仿真期间业务从未启动，所有业务统计量当然为零。这个参数在节点属性里不显眼，但极其致命。查看方式：选中业务源节点，展开 Application 属性，看 Profile 的起始时间和持续时间。

5.4 高丢包却不报错：覆盖范围与节点密度失配

现象：仿真能跑、业务也能发，但端到端丢包率高达 50% 以上，而且不同随机种子之间差异巨大。

原因：场景尺寸和节点数量不匹配。场景范围太大，节点通信覆盖半径覆盖不到几个邻居，路由发现经常失败；场景范围太小，所有节点都在互相的干扰范围内，信道竞争导致大量冲突丢失。

解决：先做连通性检查。统计节点平均邻居数，MANET 仿真里平均邻居数低于 3 到 5 个时，链路层基本处于不可靠状态，任何路由协议都救不回来。根据这个指标反推场景尺寸：邻居太少就缩小场景范围或增加节点数，邻居太多就适当降低业务强度。记住一个原则：路由协议解决的是"选哪条路"的问题，解决不了"这条路根本不存在"的问题。这个坑的隐蔽之处在于没有任何报错，你只会看到很高的丢包率，容易误判成协议问题。

5.5 场景数量一多就跑不动：DES 的 Sim Efficiency 与内存取舍

现象：单个场景仿真很快，但批量跑多个场景时，后面的场景越跑越慢，某几个场景甚至卡死几个小时。

原因：OPNET 的离散事件仿真（DES）有一个 Sim Efficiency 设置项，它控制事件处理的优化程度。某些参数组合下，模拟可能退化成逐事件模拟，速度急剧下降。另外，场景数量多但内存有限，系统开始用交换分区，仿真速度会断崖式下跌。

解决：批量跑之前，把所有场景的 Sim Efficiency 统一设置到同一档，保证对比公平，也避免个别场景设置差异导致耗时爆炸。内存方面，我习惯一次只打开一个场景运行，或者按顺序批量跑而不是同时开多个工程。如果单个场景节点的进程特别多，先检查业务负载是否太高，高负载会让事件数量指数增长，这时候减少节点数比加内存更有效。这个坑最磨人：单个场景跑起来一切正常，批量跑才会暴露，且报错信息几乎没有，只能靠观察资源占用和耗时长来判断。

6. 让实例真正值钱的收尾动作：用多场景批量对比 AODV 与 OLSR

到这里，单场景的仿真链路已经通了，但实例的真正价值要等对比实验跑完才体现出来。我建议把 AODV 和 OLSR 各复制一个场景出来，分别改协议类型，业务参数和无线参数保持完全一致，然后批量运行，最后用脚本汇总结果。

复制场景常见做法是使用场景管理功能：右击场景标签，复制场景，改名为 OLSR_scene，然后在这个副本里只动路由协议这一项。这一点非常重要——只动自变量，其他全部不动。如果你连节点数量或业务 Profile 都改了，后面任何差异都解释不清。复制完场景后，逐个确认移动轨迹、业务配置、统计量勾选是否和原场景一致，这三项是场景复制时最容易丢配置的地方。

跑完后，把每个场景的导出文件汇总到一张对比表里。下面这个 Python 脚本是我常用的汇总方式，假设每个场景导出了 packet_delay.txt 和 throughput.txt 两个文本文件，每行是"时间 数值"：

import glob def load_numeric(path): xs, ys = [], [] with open(path, encoding="utf-8", errors="ignore") as f: for line in f: line = line.strip() if not line or line.startswith("#"): continue parts = line.split() if len(parts) < 2: continue try: x = float(parts[0]) y = float(parts[-1]) except ValueError: continue xs.append(x) ys.append(y) return xs, ys def avg(ys, skip=0): seg = ys[skip:] if skip > 0 else ys return sum(seg) / len(seg) if seg else 0.0 for path in glob.glob("results/*/packet_delay.txt"): xs, ys = load_numeric(path) print(f"{path.split('/')[1]:20s} delay_avg={avg(ys):.4f} n={len(ys)}")

这个脚本做了三件事：按行读取文本结果，跳过以 # 开头的注释行和解析失败的噪声行；取每行最后一个字段作为数值；计算平均延迟，跳过预热期数据。split() 解析依赖文件用空格分隔时间与数值，如果你的导出文件是 CSV 格式，把 line.split() 改成 line.split(",") 即可。glob.glob 里的路径按你实际归档目录调整。

把这个脚本稍加扩展，把 throughput 也读进来，就能生成一张AODV和OLSR在延迟、吞吐量、丢包率上的对比表。对比时先看总体趋势，再看参数敏感度：比如高移动场景下 AODV 的延迟峰值出现在什么时刻、OLSR 的开销曲线是否平坦。这一步跑完，你手里的就不再是"实例包照跑了一遍"，而是一组能支撑结论的完整证据。

最后说一个我自己的教训：曾经做协议对比，跑完发现 AODV 场景的延迟单位是毫秒，OLSR 场景的延迟单位是秒，两个场景的统计量单位不一致，直接对比得出了完全错误的结论。从那以后，我每次跑完第一件事是看统计量的单位列，确认两边一致再谈对比。这个动作花不了十秒，却能避免把整周的仿真结果变成废数据。

如果你手里的 MANET 实例资源还躺着没动，我的建议是别急着把它当黑匣子跑一遍就交差。照着这里的步骤拆一遍模型栈、配一遍参数、跑一次对比，你会发现协议选型的说服力比翻十篇文献都实在。希望帮到你。

本文还有配套的精品资源，点击获取