简介：一套基于OPNET Modeler的ALOHA与AODV协议联合仿真平台项目，面向网络仿真研究人员、通信工程学生及协议开发人员，可用于在真实网络部署前验证随机接入协议与按需路由协议的交互表现。压缩包内共36个文件，主要包含网络拓扑与进程模型文件（.m）、工程文件（.prj）、C语言源码（.c）、动态链接库（.dll/.lib）、图形配置数据（.gdf/.ef）以及仿真日志（.log），整体约93KB，轻量精简。平台覆盖了OPNET建模、协议配置、事件调度、性能指标设定与结果分析等完整流程，并涉及equipmentqst所对应的设备特性与QoS配置问题。目前已有340人学习下载，适合通信仿真入门、课程设计及协议验证使用。借助该包的模型、源码和日志，可深入理解纯ALOHA、时隙ALOHA冲突解决机制与AODV路由发现维护流程，掌握OPNET中搭建无线仿真实验环境的方法，为无线网络优化提供参考。

1. Modeler搭建ALOHA协议仿真平台：一个全网只讲理论、少有落地细节的仿真方向

ALOHA协议在教科书上只有几页，看似五分钟就能建模。可真到用 Modeler（OPNET 原厂仿真环境，现属 MATLAB 系列工具链）去搭一个能跑、能统计、能和理论曲线对比的 ALOHA 仿真平台时，你会发现教材里根本没写清楚：收信机模型改哪几个参数、重传延时怎么设、AODV 路由协议和 ALOHA 的 MAC 层怎么在同一节点里共存。我见过不少人卡在“仿真跑完，统计量为 0”这个阶段，也见过把随机接入协议做成轮询的翻车操作。这篇笔记把 ALOHA 的建模管线、AODV 联合配置、统计量设置和排错思路完整拆开，给课程设计、毕业设计以及刚开始做无线自组网仿真的从业者一条能直接照做的路径。顺便说一句，这类平台搭建的核心难点不在“画节点”，而在“管时间”：ALOHA 的随机重传、AODV 的 Hello 消息、路由表超时这三套时间逻辑在同一个仿真内核里互相影响，理不顺它们，平台就只能看动画，不能出数据。

2. ALOHA 协议在 Modeler 里的建模基础：收信机模型与三处关键配置

2.1 先分清楚业务模型与传播模型之间的层次关系

Modeler 里搭建协议仿真平台，最容易上来就画节点模型，然后把传输层、MAC 层、物理层封装成模块堆在一起。这个做法在纯业务演示时没问题，但要做 ALOHA 这类随机接入协议的性能仿真，层次关系必须一开始就立住。

我的习惯是：网络层跑 AODV 路由，MAC 层跑 ALOHA 接入，物理层用默认的无线收信机模型。IP 层负责分片和路由查找，AODV 负责建路，ALOHA 负责把数据帧不管三七二十一发出去。三者是纵向串行关系，不是平级关系。很多人在 Modeler 里新建进程模型时，把 AODV 的定时器和 ALOHA 的定时器放在同一个进程模块里写，导致路由控制帧和数据帧互相抢占发送机会，跑出来的端到端时延曲线全是毛刺。

正确做法是在节点模型里至少放四个模块：source（业务产生）、aodv_rte（路由进程）、mac_aloha（接入进程）、rx（收信机）。路径是 source -> aodv_rte -> mac_aloha -> tx，收包路径反过来。ALOHA 只负责“接入”，不负责“寻路”，AODV 只负责“建路”，不负责“重传”。边界划清楚，后面调参才不至于牵一发动全身。

2.2 新建工程：场景尺寸、移动模型和业务源的初始设定

新建 Modeler 工程时，场景尺寸决定了无线传播时延，也就决定了 ALOHA 的“听到冲突”的时机。不要随手拉一个 1000m x 1000m 的矩形，这个尺寸对 ALOHA 来说太大了——传播时延一长，冲突检测的联动关系会变得很诡异。常见做法是先用 200m x 200m，节点数 20 到 30 个，后续再逐步扩大。

具体操作上，我一般这样配置初始项目参数：

选择 File -> New -> Project，项目名称建议用“aloha_aodv_platform”这类带协议标识的名字，而不是“test1”。然后在 Scenario 配置里做三个固定动作：

第一，把 Network Scale 设为 Office 或 Same Building，地图尺寸设为 200m x 200m。第二，选择节点模型时，先建一个带 wireless_lan 收信机的移动节点（mobile_node），后续再改它的 MAC 层进程。第三，配置业务源为指数分布的消息到达，平均间隔 0.1 秒，包大小固定 512 bit。这里有个关键思维转变：ALOHA 的性能指标是“吞吐量 vs 总到达率”，不是“时延 vs 节点数”。所以业务源的到达率要可调，最好映射成一个外部参数，后面每跑一轮就改一次参数，才能画出整条曲线。

移动模型如果暂时不是核心关注点，直接选 None 或 Random Waypoint 但把速度设成 0。先把 ALOHA 的接入行为跑通，再引入移动性。这样分类排错时会省很多力气——因为 AODV 和 ALOHA 各自的坑已经够多了，再加一个移动模型，几乎没法判断问题出在哪个环节。

2.3 搭建 ALOHA 接入进程模型的 Pipeline 设计

Modeler 里的收发包路径是一组 Pipeline Stage，ALOHA 的仿真本质就是控制“从发送到接收成功”这条流水线上的几个阶段。我们真正要干预的阶段有三个：transmission delay、error allocation、error correction。

transmission delay 阶段决定帧占用信道的时间，这个时间等于帧长除以数据速率。error allocation 阶段决定哪些接收节点会出错，出错原因可以是信噪比过低，也可以是冲突。ALOHA 的冲突模型很特殊：只要两个帧在信道上有时间重叠，接收节点就丢帧。Modeler 默认的 error allocation 是基于信噪比门限的，并不会因为“两个帧时间重叠”就直接丢包，所以必须修改这一段的逻辑。

我通常在模型里配置如下代码片段（进程模型里的 Proto-C 逻辑）：

// ALOHA 冲突检测核心逻辑：检查该信道上是否有其他帧正在传输 // 这是自定义 Pipeline Stage 的实现思路 static void aloha_error_allocation(OPN_List *packet_list, Objid receiver_obid) { // 遍历当前接收时刻所有正在传输的包 for (packet = opn_list_first(packet_list); packet != OPN_C_NIL; packet = opn_list_next(packet_list)) { // 统计在相同接收时段内、来自不同发送节点的帧 // 如果总数大于 1，说明发生了 ALOHA 冲突 if (packet_count > 1) { // 标记当前帧为错误帧，接收机丢弃 op_pk_destroy(packet); } } }

上面的代码是逻辑示意，实际在 Modeler 里要注册成 Pipeline Stage 后才会生效。注册路径是Node Model -> Interfaces -> Pipeline Stages，把自定义的 stage 替换掉默认的 error allocation。注意替换之后，原有的信噪比门限机制还可以保留在 upstream 阶段，不影响你这层逻辑。这么做的好处是模型更贴近真实 ALOHA：信道忙不忙无所谓，先发先撞，撞了全丢，这才是 ALOHA 的“莽夫式接入”本质。

2.4 三个必调的 MAC 层参数：它们决定实验成败

配置好 Pipeline Stage 之后，收信机模型里还有三个参数必须调。它们藏在收信机属性 -> Wireless Parameters里。很多新手只看传播模型，完全忽略这三个参数，导致仿真出来的吞吐量曲线翻车。

第一个是Receiver Sensitivity（接收灵敏度），单位 dBm。场景尺寸是 200m 时，灵敏度设成 -95 dBm 比较稳妥。设太高（比如 -70 dBm），节点之间会“听不见”，结果冲突率异常低，但丢包率异常高，因为灵敏度以下的数据包全被当归噪声丢弃。设太低（比如 -120 dBm），又会把远处微弱的冲突信号也算进来，冲突率高得离谱。这个参数本质上是在模拟无线网卡的物理接收能力，不能拍脑袋。

第二个是Data Rate（数据速率）。ALOHA 仿真对数据速率极其敏感，因为它直接决定“发送一帧占用信道多长时间”。建议把数据速率设为一个变量（比如 1 Mbps），以后调系统容量时直接改这一个变量。如果设成默认的 54 Mbps（802.11g 速率），你会惊讶地发现：帧长 512 bit 时，发送一个帧只占信道 0.0095 ms，冲突窗口极小，仿真跑出来的吞吐量接近 100%，完全不像 ALOHA。那是速率太高导致的时间窗口效应，不是你的协议做对了。

第三个是Transmit Power（发射功率）。200m 场景下，0.001 W 到 0.01 W 都可以接受。关键不是功率本身，而是所有节点的功率必须一致。Modeler 里如果复制节点后手动改过某个节点的功率，整个网络的对称性就破坏了。我吃过一次亏：20 个节点里有一个节点功率特别高，每次它一发送，周围节点全部信噪比骤降丢包，导致整体吞吐量掉了一半，查了整整一个下午。

3. 把 AODV 路由装进 ALOHA 平台：两种集成方案与时间参数对齐

3.1 方案一：使用 Modeler 自带的 MANET 路由模块，关闭 MAC 层退避

Modeler 从 14.5 之后的版本里都带了 MANET（Mobile Ad-Hoc Network）模块，里面封装了 AODV 的标准实现。很多人以为装了 MANET 模块就等于完成了 AODV 仿真，实际完全不是这么回事——MANET 模块的路由层协议默认依赖 MAC 层的 RTS/CTS/ACK 机制，而我们做的 ALOHA 平台里根本没有这套确认机制。如果直接叠加，仿真器会一直等待 ACK 超时，然后触发 AODV 的路由错误广播，结果就是网络中充满 RERR 报文，数据包永远送不出去。

正确做法是把 MAC 层的 ACK 机制关掉，让 AODV 的路由请求发出去之后，不指望 MAC 层确认链路是否可用，而是由路由层自身决定链路状态。在 Modeler 里，MANET 模块的 AODV 参数位于节点模型 -> aodv_rte -> Attributes。其中最重要的两个参数是Hello Interval和Allowed Hello Loss。

Hello Interval 控制 AODV 定期广播 Hello 报文的频率，默认是 1 秒。在 ALOHA 这种高冲突率的信道上，Hello 报文本身也可能冲突丢失，所以 Allowed Hello Loss 必须从默认的 2 调大，我一般设成 5。这意味着链路层允许连续丢 5 次 Hello 才判定邻居失联，为的是把 Aloha 接入导致的随机丢包和真正的链路中断区分开。

设置完这两个参数，AODV 和 ALOHA 就可以在同一个节点里共存。但注意，这样还远不够，因为 ALOHA 的重传逻辑和 AODV 的路由发现逻辑会在时间上互相踩踏，下一节细说。

3.2 方案二：自定义 Hello 报文触发按需路由，适合教学演示场景

如果你不希望引入 MANET 模块的完整协议栈（它内部有太多 dd 层、链路层状态机，对教学演示不友好），可以自己定义 AODV 的控制报文逻辑。这个方案适合对 Modeler 进程模型有一定掌握、想把“协议机制”显示在动画里的人。

实现路径是：在 aodv_rte 进程模型里新建两个状态——IDLE 和 WAIT_RREQ。源节点有数据要发送时，从 IDLE 进入 WAIT_RREQ，广播 RREQ，然后启动一个定时器。目标节点收到 RREQ 后回复 RREP，源节点收到 RREP 后进入 DATA_TRANS。如果定时器超时，重新广播 RREQ。关键是 RREQ 的发送要调用op_radio_tx()这种底层无线电发射函数，而不是调用 MAC 层的队列发送接口。这样才能保证 RREQ 报文是“直接发出去”的，符合 ALOHA 的随机接入精神——不去管信道忙闲，直接占用信道发送。

自定义方案的时间参数我们来手动对齐。AODV 最重要的两个时间参数是ROUTE_DISCOVERY_TIMEOUT和RREQ_RETRIES。

// 自定义 AODV 路由发现的关键参数 #define RREQ_RETRIES 3 // 最大重试次数 #define RREQ_TIMEOUT 0.5 // 单次等待 RREP 的超时时间，单位秒 #define HELLO_INTERVAL 1.0 // Hello 报文发送周期 #define NEIGHBOR_TIMEOUT 3.0 // 邻居超时时间，3 个 Hello 周期

在 ALOHA 信道上有几个特殊考虑。因为 ALOHA 的丢包率是随负载变化的，负载高时 RREQ 的发送成功率很低，所以 RREQ_RETRIES 不能设太小，3 是最低限。而 RREQ_TIMEOUT 要大于 ALOHA 的传播时延加上重传间隔。如果把 RREQ_TIMEOUT 设成 0.1 秒，那 RREQ 一旦遇到冲突丢失，源节点重发的时间间隔就过密，产生更多冲突，形成雪崩。我一般建议 RREQ_TIMEOUT 不低于 0.5 秒，也就是给了一次 ALOHA 冲突重传的容错机会。

3.3 ALOHA 重传逻辑与 AODV 路由发现的时间参数对齐

这是全文最容易翻车的地方。ALOHA 的重传策略通常是：发送失败后，等待一个随机时间（通常是 1 到 5 个数据帧传输时间），然后重新发送。AODV 路由发现策略是：等待固定超时时间，超时后重发 RREQ 或报错。两套时间逻辑叠加后，会出现什么情况？假设 ALOHA 的重传间隔是 0.2 秒，AODV 的路由发现超时是 0.5 秒。那么一个数据帧第一次发失败后，它要等 0.2 秒后重发。可这时候 AODV 的路由还没建好，因为 RREP 还没回来。数据帧只能继续排队。等 AODV 超时后重发 RREQ，又占用了 ALOHA 的发送机会，把原本要重传的数据帧挤到更后面。

正确的时间参数关系应该是：

这个表是我做了大量仿真实验总结出来的参数组合。核心逻辑是：上层协议的时间尺度必须是下层协议的整数倍加余量。ALOHA 的重传是底层时间的“最小粒度”，AODV 的所有定时器都要落在它的两倍以上。

3.4 AODV 与 ALOHA 的冲突连带问题：Hello 风暴

AODV 的 Hello 报文在 ALOHA 信道上有一个隐性问题：Hello 是周期性广播，它本身就是一个固定的信道负载。当节点数量增多时，Hello 报文的总到达率会等比例上升，这部分负载同样参与 ALOHA 的冲突计算。很多人在 20 个节点时跑得好好的，一扩到 50 个节点就全线崩溃，吞吐量掉到接近 0，第一反应是查看场景尺寸和发射功率，都没问题，实际上就是 Hello 风暴压垮了信道。

解决这个问题的方法不是关掉 Hello 机制，而是把 Hello Interval 和 ALOHA 的重传窗口绑定在一起。你希望在网络层把链路维持住，又要避免周期性报文压垮信道，常见的折中做法是：把 Hello Interval 设置成 ALOHA 平均重传间隔的 3 倍以上，同时不依赖 MAC 层的 ACK，只靠 AODV 层自身的丢失判断。

如果你要仿真的是一个高负载场景（比如节点数超过 40），我建议干脆禁用 Hello 机制，全部采用按需路由的方式。也就是为每条活跃的数据流发 RREQ，用 RREQ 的回复结果来维护路由表项，而不是让所有节点周期性地刷存在感。这个做法牺牲了一点路由发现时延，但换回了信道容量，在 ALOHA 这种低效接入协议下是合算的。

4. 跑通仿真平台：统计量、场景参数与结果导出

4.1 配置统计量：吞吐量、冲突率与端到端时延的采集位置

Modeler 的统计量采集有两种：一种是链路统计，一种是节点统计。做 ALOHA 平台，最重要的三个指标各有各的采集位置，不要全堆在全局统计里，否则数据拉出来后很难定位是哪一层的问题。

吞吐量要在接收端采集，而不是发送端。选择目标节点的 mac_aloha 进程模块，右键选择 Choose Individual Statistics，展开MAC -> Throughput (bits/sec)。这个统计量代表单位时间内成功接收到的有用数据量。注意它排除了帧头开销，所以在比较理论值时要记得把帧头处理掉。

冲突率要在发送端采集，因为冲突是发送侧观察到的现象。在 mac_aloha 进程模块里采集Retransmission Count或者Collision Count，这两个统计量是累计值。跑完仿真后，用最后时刻的累计值减去起始时刻的累计值，再除以总的发送次数，得到平均冲突率。

端到端时延必须从应用层采集，不能从 MAC 层采。原因很简单：MAC 层的时延只包含接入和排队，而用户关心的往往是整个数据包从业务源到目标应用层的时间。采集位置是Application Layer -> End-to-End Delay (sec)，这样把 AODV 的路由发现时延、排队时延、ALOHA 的重传时延全部包含进来。

4.2 仿真时间、随机种子与事件推进的参数设定

仿真时间的设定直接影响数据曲线的平滑度。ALOHA 的随机性很强，如果只跑 10 秒仿真，吞吐量曲线会像锯齿一样跳动，看不出规律。我一般跑 300 秒仿真时间，前 50 秒作为预热期，不参与统计。Modeler 里没有直接的“预热期”开关，我的做法是让业务源在第 0 秒开始产生业务，但在统计时把前 50 秒的采样点从生成的向量文件里截掉。

随机种子的处理也要科学。ALOHA 依赖随机重传，单次运行的冲突率波动很大。正确做法是：同一组参数跑 5 次，每次换一个随机种子，最后把 5 次结果的平均值作为该参数下的性能点。Modeler 的随机种子在Simulation -> Common -> Random Seed里设置。我通常设成 100、12345、54321、99999 和 1，这 5 个种子覆盖了不同的随机序列特征，均值具有统计意义。

事件推进方面，Modeler 的离散事件仿真是默认的事件驱动，不需要额外设置。但延迟精度（resolution precision）一定要调高。默认每一位数字代表 6 个十进制数字，这不够用。ALOHA 的帧传输时间接近微秒级，如果精度不够，可能出现“两个帧同时结束传输”的事件合并，导致冲突检测失效。把Simulation Efficiency -> Advanced -> Precision内的精度级别调到 10 位以上，虽然运行速度会慢一些，但代价完全值得。

4.3 导出向量文件并用 Python 做吞吐量-负载曲线

Modeler 仿真完成后，数据以 .csv 或 .scalar 形式存储。我习惯在仿真结束后用命令把向量导出。

# 将 Modeler 生成的输出向量导出为 CSV 格式 op_vu_export -f aloha_10nodes.csv -t 0 -e 300 \ node_20.mac_aloha.throughput \ node_12.mac_aloha.throughput \ node_5.mac_aloha.throughput

实际项目中op_vu_export的可用性取决于你装的 Modeler 工具链版本，如果界面没有这个命令，也可以直接在 GUI 里打开 View Results，然后手动拖出图表数据。需要保留的是每个节点的吞吐量时间序列。

拿到 CSV 后，我用 Python 做负载-吞吐量对比：

import pandas as pd import matplotlib.pyplot as plt # 读取 5 个不同负载配置下的仿真结果 data = pd.read_csv("throughput_vs_load.csv") # 计算归一化吞吐量 S（成功传输的分组占总分组的比例） data["S"] = data["throughput"] / data["offered_load"] # 与理论纯 ALOHA 曲线 S = G * exp(-2G) 比较 G = data["offered_load"] theory = G * np.exp(-2 * G) plt.plot(G, theory, label="Theory Pure ALOHA") plt.plot(G, data["S"], "o-", label="Modeler Simulation") plt.xlabel("Offered Load G") plt.ylabel("Throughput S") plt.legend()

这段代码做的事情很简单：把仿真采集到的吞吐量和总负载相除，得到归一化吞吐量 S，然后和理论公式 S=G·e^(-2G) 叠加在同一张图上。如果仿真的 S 曲线和理论曲线形状接近，峰值出现在 G=0.5 附近，S 约为 0.184，说明 ALOHA 的建模是正确的。如果峰值明显偏离或者高度不对，就要回到第 2 章的三个参数做排查。

关键点在于：这个归一化的过程必须在数据层面做，而不是在 Modeler 的图标模板里做。因为 Modeler 自带的图表工具通常是把吞吐量直接画出来，不会帮你计算“负载”这一个中间量。

4.4 场景配置的命名规范：_equ 后缀的坑

回到标题里的_equ后缀。在实际项目中，“equ”通常代表 Equipment（设备）节点分类。我见过很多人在复制节点时没有改名称，结果节点名叫node_0、node_0_1、node_0_2，到导出统计量时找都找不到哪个是发送端、哪个是接收端。我的习惯是所有业务源节点用src_equ_xx命名，所有汇聚节点用dst_equ_xx命名，中间转发节点用rtr_equ_xx命名。这个习惯在手动分析多个仿真场景时价值极大，尤其是批量跑 30 个以上场景时，名称混乱能让人抓狂。

5. 避坑：ALOHA 与 AODV 联仿的 5 个典型问题排查

5.1 仿真跑完但吞吐量统计为 0

现象：仿真结束后打开 Throughput 向量，所有时间点都是 0，但网络动画里明明看到有数据包在移动。

原因：统计量采集的是 MAC 层接收成功的数据量。动画里看到的数据包移动可能只是发送端的无线信号传播，并不代表接收端成功解析。在 ALOHA 这种高冲突率协议下，可能所有数据帧都在冲突中丢失了，接收端根本没收到任何完整帧。另外，如果接收端的收信机模型里没有注册 2.3 小节的自定义 error allocation，帧的接收判定会走默认信噪比门限，而门限过低导致所有帧都能“成功接收”。

解决步骤：先打开接收端节点的收信机模型，检查是否引入了自定义错误分配阶段。然后在仿真运行时实时监控 Collision Count 统计量，如果该值持续增长，且吞吐量为 0，说明确实发生了全部冲突。不要先调发射功率，先把错误分配逻辑确认好。

5.2 吞吐量曲线出现周期性塌陷

现象：吞吐量曲线呈现规律的“波峰-波谷”交替，波谷处吞吐量几乎为 0，波峰又恢复到正常值，周期大约 1 秒。

原因：这是 Hello 报文与数据帧周期性地在时间上撞车。AODV 的 Hello 报文固定 1 秒发一次，而 ALOHA 的重传间隔是固定的 0.3 秒。当 Hello 报文占用信道发送时，数据帧的重传计时器到点，两者在信道相遇，属于纯 ALOHA 的冲突窗口，两个都丢。下一个周期两者错开，吞吐量恢复。

解决方式：将 Hello Interval 从 1 秒改为 2 秒或 2.5 秒，同时将 ALOHA 重传间隔的随机化范围扩大（从固定 0.3 秒改为 0.2 到 0.6 秒均匀分布）。这个随机化很关键，它能打破周期性碰撞的同步效应，让吞吐量曲线平稳下来。

5.3 仿真中途发生大量事件堆叠，运行速度急剧下降

现象：仿真跑到某个时刻后，进度条几乎不动，CPU 占用率却到 100%，事件列表里全是 0 时刻重复事件。

原因：ALOHA 重传计时器设置过短，导致一个数据帧在极短时间内反复重传。重传产生新事件，新事件又触发更多重传，形成事件风暴。AODV 的 RREQ 重试与此类似——如果 RREQ_TIMEOUT 设太小，RREQ 会在 0.1 秒内重发多次，每次重发都广播给所有邻居，事件数量呈指数级增长。

解决方式：立即停掉仿真，检查 ALOHA 进程的重传间隔和 AODV 的 RREQ_TIMEOUT。我的经验值是最小间隔不少于 0.2 秒。如果某个业务模型逻辑上有“立即重传”的代码路径，需要加一个保护性的最小等待时间。

5.4 节点间距扩大后，吞吐量不下降反而上升

现象：把场景尺寸从 200m 改到 500m 后，理论上吞吐量应该下降（因为传播时延增大，冲突概率上升），实测却上升了 10% 到 20%。

原因：这通常不是 ALOHA 协议的问题，而是接收灵敏度与发射功率的组合效应。200m 场景中，远处节点的信号也能到达接收端，成为冲突源。扩到 500m 后，远处节点的信号强度低于接收灵敏度，直接被接收机当作噪声丢弃，不参与冲突检测。这相当于凭空减少了一部分潜在冲突源，吞吐量自然上升。

解决方式：这个现象本身不是 bug，但会误导结论。如果目标是研究 ALOHA 本身的性能，应保持节点间距不变，只增加节点数来提升负载。如果目标是研究网络规模的影响，则应所有节点同步调整接收灵敏度和发射功率，保证链路完整性。否则“因变果”链路被割断了，结论就不成立。

5.5 AODV 路由表建立慢，端到端时延有数百毫秒的初始尖峰

现象：仿真开始后，第一个数据包的端到端时延达到 500ms 以上，此后恢复正常。每次都复现，且尖峰高度随时间推进逐渐降低。

原因：这是冷启动效应。业务源第 0 秒就开始产生数据，而 AODV 此时还没有任何路由表项，必须发起 RREQ 广播，等待 RREP 回复。在 ALOHA 信道上，RREQ 发送后可能冲突丢失，触发 AODV 的 RREQ 重传，整个建路过程可能耗时数百毫秒。这个第一个数据包必须承担路由发现的初始时延。

解决方式：如果这个尖峰影响了你对平均时延的判断，可以在业务源配置里让业务在第 20 秒后开始产生，或者预先发送一个“路由预热包”后再正式开始统计。路由预热包的做法是：仿真开始后，源节点立即发送一个小的探测数据包（可以是一个空 IP 包），它的唯一作用是触发 AODV 建路。建完后，正式业务流的第一个数据包就可以直接通过已有路由发送，时延显著降低。

6. 仿真结果的验证与调优技巧：把理论曲线当镜子用

纯 ALOHA 的理论吞吐量曲线是 S = G·e^(-2G)，最大吞吐量为 0.184。这是验证仿真平台正确性的黄金标准。但我不是让你直接拿模型跑一遍曲线和理论对比——那个提升不大，因为仿真环境的默认设置能让你很容易碰巧得到接近的曲线。真正的价值在于利用理论曲线检查你的平台在“极端负载区”的行为是否正确。

先在 G=0.1、0.2、0.3、0.4、0.5、1.0、2.0、3.0 这几个点上各跑一轮仿真，每轮跑 300 秒仿真时间、5 个随机种子、取均值。然后把仿真 S 值与理论 S 值做相对偏差分析。偏差低于 5%-10% 说明协议建模正确；偏差超过 20% 就要排查接入流程是否有额外的退避逻辑混进来了。我见过的最大偏差来自有人把重传间隔设置成固定值，导致高负载下重传也很“准时”，系统涌现出类似时隙 ALOHA 的特性——最大吞吐量跑到 0.3 以上。这就是“仿出了错误协议”而不自知。

调优技巧有几个方向。第一是重传间隔的随机化范围。纯 ALOHA 对随机性要求很「纯」，重传间隔必须是均匀或指数分布，不能是固定值。固定值会让系统退化。第二是帧长的选择。帧长越短，在固定负载下冲突概率越低，但吞吐量曲线形状仍符合理论预测。不要把帧长设成 1 字节来“贪吞吐量”，因为这种结果脱离了无线网络的实际。第三是节点数的幂次递进，20、30、40、50 四个量级是一个合理的测试梯度，超过 50 后 ALOHA 信道的冲突概率接近饱和，数据分析价值不大，更适合做 ACK/退避协议的对比研究。

最后说一个我的习惯：我每次搭完 ALOHA 仿真平台，都会手动跑一遍“单对单通信”场景，一个源一个目的地，确认端到端时延稳定在传播时延加上传输时延数量级；再跑一个“三节点同发”场景，确认冲突导致丢包。这两个基础场景验证通过，再扩大到多节点，这样定位问题时永远有一个“确定没坏”的底。希望这次梳理的路径能帮你少走一段弯路——把教科书上的 ALOHA 变成一个真正能出数、能发论文的仿真平台。

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