企业官网建设流程全解析

简介：这份资源面向无线传感器网络与多址接入协议的学习者，尤其是使用OPNET Modeler开展Aloha协议仿真的研究人员与学生。内容围绕纯Aloha与时分Aloha在无线环境下的建模展开，涵盖节点分布、通信范围、MAC层参数配置、冲突检测与重传策略设定，并支持对吞吐量、延迟、丢包率等指标进行多维度评估，帮助读者理解随机接入机制的工作原理与优化方向。压缩包共150个文件，约384KB，以ot模型文件、desinfo仿真描述、log_info日志、m脚本、ov与ef配置等类型为主，另含prj工程、dll与lib库文件，构成可直接复现的OPNET项目结构。目前已有340人学习。通过实际运行与对比不同Aloha变体的仿真数据，读者可验证理论计算、掌握参数调优思路，并为更复杂的多址接入协议研究打下基础。

1. 从一次 MAC 层仿真翻车说起：Aloha 协议在 OPNET 里到底能跑出什么

很多人第一次在 OPNET 里搭 Aloha 仿真，跑出来的吞吐率曲线跟教科书上那条经典的 S 曲线对不上——要么在低负载时吞吐率就上不去，要么高负载时直接崩成一条水平线。这不是模型建错了，而是 Aloha 协议本身的随机接入特性决定了它对参数极度敏感，而 OPNET 的 MAC 进程模型又要求你把每个状态转移和中断处理都写对，差一个op_intrpt_schedule_self的时机，结果就完全两样。

Aloha 协议的核心思想极其简单：有包就发，冲突了重传。但正是这种“不管不顾”的接入方式，让它在 OPNET 里的仿真变得格外考验人对 MAC 层状态机的理解。纯 Aloha 的理论最大吞吐率是 18.4%，时隙 Aloha 翻倍到 36.8%，这两个数字在 OPNET 里能不能复现出来，取决于你怎么设置包到达过程、怎么定义冲突窗口、怎么处理退避重传。这篇笔记面向的是需要在 OPNET 里做 MAC 协议仿真验证的通信工程师和研究生，我会把从进程模型搭建到参数调优再到结果验证的完整路径拆开讲，重点放在那些让曲线跑偏的细节上。

2. Aloha 与 OPNET 的对接逻辑：为什么不能直接拖一个现成模型

2.1 Aloha 的随机接入本质与 MAC 层建模的对应关系

Aloha 协议在 MAC 层要解决的核心问题是：多个节点共享一个信道时，如何决定谁在什么时候发送。纯 Aloha 的做法是节点一有数据帧就立即发送，完全不检测信道状态。时隙 Aloha 则把时间划分为等长的时隙，节点只能在时隙边界开始发送。这两种模式在 OPNET 里的建模差异，直接决定了进程模型的状态机结构。

在 OPNET 的进程模型域中，MAC 层通常由一个process模型实现，内部用状态转移图描述协议行为。对于 Aloha，最简状态机只需要三个状态：IDLE（空闲等待）、TRANSMIT（发送中）、BACKOFF（冲突后退避等待）。但实际建模时你会发现，OPNET 的radio transmitter和radio receiver模块会引入额外的中断类型，比如OPC_INTRPT_STRM（流中断）和OPC_INTRPT_SELF（自中断），这些中断的优先级和调度顺序会直接影响冲突检测的准确性。

一个常见的误区是直接把 Aloha 当成无冲突协议来处理，忽略了 OPNET 中物理层信道模型对同时发送的建模方式。OPNET 的无线信道支持“碰撞”概念，但需要你在进程模型中显式调用op_td_get_dbl获取接收功率，再跟干扰功率比较来判断是否发生冲突。如果跳过这一步，仿真出来的吞吐率会虚高，因为所有同时发送的包都被当成了成功接收。

2.2 在 OPNET 中搭建 Aloha 进程模型的最小步骤

下面以纯 Aloha 为例，给出在 OPNET Modeler 中创建 MAC 进程模型的关键步骤。假设你已经建好了一个包含wlan_station和wlan_server的网络模型，接下来要替换默认的 MAC 进程。

第一步，创建进程模型。在 Project Editor 中右键 Process Model → New → Process Model，命名为aloha_mac。进入 Process Model Editor 后，定义状态变量：

/* aloha_mac 进程模型的状态变量定义 */ static int pkt_len; /* 当前数据包长度，单位 bit */ static double pkt_arrival_rate; /* 包到达率，单位 packets/sec */ static double slot_time; /* 时隙长度，纯 Aloha 下为 0 */ static int max_retries; /* 最大重传次数 */ static int retry_count; /* 当前重传计数 */ static double backoff_base; /* 退避基数，单位秒 */

这些变量中，slot_time在纯 Aloha 下设为 0，表示没有时隙对齐；在时隙 Aloha 下需要设为pkt_len / channel_rate，即一个包的传输时间。backoff_base决定了冲突后等待多久再重传，通常取pkt_len / channel_rate的整数倍。

第二步，定义状态转移图。在 Process Model Editor 的 State Transition 面板中，创建三个状态：

• init状态：初始化变量，设置包到达的自中断。
• idle状态：等待包到达或自中断。
• tx状态：发送数据包，调度发送完成中断。
• backoff状态：冲突后退避等待。

状态转移的条件用op_intrpt_type()和op_intrpt_code()判断。例如，从idle到tx的转移条件是op_intrpt_type() == OPC_INTRPT_SELF && op_intrpt_code() == PKT_ARRIVAL。

第三步，编写进入tx状态时的执行代码：

/* 进入 tx 状态：发送数据包 */ FIN(aloha_mac_tx_enter) { /* 获取当前包 */ Packet *pkt = op_pk_get(op_intrpt_strm()); /* 发送到物理层 */ op_pk_send(pkt, 0); /* 调度发送完成中断，延迟为包传输时间 */ double tx_time = (double)pkt_len / CHANNEL_RATE; op_intrpt_schedule_self(op_sim_time() + tx_time, TX_COMPLETE); /* 调度冲突检测中断，在包传输期间持续监听 */ op_intrpt_schedule_self(op_sim_time() + tx_time, COLLISION_CHECK); /* 记录发送统计量 */ op_stat_write(tx_stat_handle, 1.0); } FOUT

这段代码的关键在于op_intrpt_schedule_self的调用时机。TX_COMPLETE中断用于判断发送是否成功，COLLISION_CHECK中断用于在发送过程中检测是否有其他节点同时发送。如果两个中断的时间设置不当，比如COLLISION_CHECK的调度时间晚于TX_COMPLETE，冲突就检测不到。

第四步，处理冲突后的退避。在backoff状态的进入代码中：

/* 进入 backoff 状态：计算退避时间并调度重传 */ FIN(aloha_mac_backoff_enter) { retry_count++; if (retry_count > max_retries) { /* 超过最大重传次数，丢弃该包 */ op_pk_destroy(op_pk_get(op_intrpt_strm())); retry_count = 0; /* 回到 idle 状态 */ op_intrpt_schedule_self(op_sim_time(), IDLE_RETURN); return; } /* 计算退避时间：二进制指数退避 */ double backoff_time = backoff_base * (1 << (retry_count - 1)); /* 加入随机抖动，避免同步退避 */ backoff_time *= (1.0 + op_dist_uniform(0.5)); op_intrpt_schedule_self(op_sim_time() + backoff_time, RETRY_TX); } FOUT

退避时间的计算是 Aloha 仿真中最容易出问题的地方。如果所有节点用相同的退避基数且没有随机抖动，重传时会再次冲突，形成“同步退避”现象，导致吞吐率曲线在某个负载点突然塌陷。加入op_dist_uniform的随机因子后，重传时间被分散开，曲线才会平滑。

2.3 关键参数对仿真结果的影响量级

在 OPNET 中跑 Aloha 仿真，以下几个参数对结果的影响最大，需要重点标定：

这张表里的取值不是拍脑袋来的。以包长 1024 bit、信道速率 1 Mbps 为例，一个包的传输时间是 1.024 ms。如果退避基数取 1 倍传输时间，即约 1 ms，在 50 个节点同时活跃的场景下，退避后的重传仍然会大量碰撞。我一般会把退避基数设为 3~5 倍传输时间，再配合随机抖动，这样在负载 0.5 左右时吞吐率能稳定在理论值的 80% 以上。

3. 从零跑通一个纯 Aloha 仿真：节点配置、统计量与曲线验证

3.1 网络模型搭建与节点属性配置

在 OPNET 中新建一个 Project，选择Wireless Domain，创建一个包含 10 个wlan_station和一个wlan_server的场景。每个wlan_station的Application属性中配置一个FTP或Custom应用，产生固定间隔的包流。关键配置在MAC层：把默认的WLAN MAC替换成你刚创建的aloha_mac进程模型。

具体操作路径：右键节点 → Edit Attributes → 展开Wireless LAN→ 找到MAC Model属性 → 从下拉列表中选择aloha_mac。如果下拉列表里没有，说明进程模型没有注册到模型库中，需要在Model Library中手动添加。

节点间的距离设置也会影响仿真结果。如果所有节点距离很近，物理层接收功率差异小，冲突判断更严格；如果距离拉远，部分节点之间可能因为信号衰减而无法互相干扰，形成“隐藏终端”效应。在纯 Aloha 仿真中，我一般先把所有节点放在同一个subnet内，距离设为 10 米，确保全连通，这样能排除物理层因素对 MAC 层性能的干扰。

3.2 统计量的采集与全局配置

OPNET 的统计量采集需要在Global Statistics和Node Statistics两个层级分别配置。对于 Aloha 仿真，必须采集的统计量包括：

• Channel Throughput（信道吞吐率）：在Global Statistics→Wireless LAN→Channel Throughput中勾选。
• MAC Delay（MAC 层延迟）：在Node Statistics→Wireless LAN MAC→Delay中勾选。
• Packet Drop Rate（丢包率）：在Node Statistics→Wireless LAN MAC→Packet Dropped中勾选。
• Retransmission Attempts（重传次数）：在Node Statistics→Wireless LAN MAC→Retransmission Attempts中勾选。

采集这些统计量后，在Simulation配置中设置仿真时长为 300 秒，种子数设为 10 次取平均，以消除随机性带来的波动。仿真结束后，在Results中查看Channel Throughput曲线，横轴是仿真时间，纵轴是吞吐率（bits/sec）。

3.3 用脚本批量扫描负载并导出曲线

手动改参数跑仿真效率太低，我一般用 OPNET 的Simulation Sequence功能批量扫描包到达率。在Simulation→Simulation Sequence中新建一个序列，添加Application的Packet Interarrival Time属性作为扫描变量，设置从 0.02 秒到 1 秒，步长 0.02 秒，共 50 个取值。每个取值跑一次仿真，自动生成吞吐率随负载变化的曲线。

如果需要在外部脚本中处理结果，可以用 OPNET 的op_stat接口导出数据：

/* 在仿真结束时导出吞吐率统计量到文件 */ void export_throughput_stats() { FILE *fp = fopen("aloha_throughput.csv", "w"); fprintf(fp, "time,throughput\n"); /* 遍历仿真过程中记录的所有统计点 */ int num_points = op_stat_get_num_points(channel_throughput_handle); for (int i = 0; i < num_points; i++) { double time = op_stat_get_time(channel_throughput_handle, i); double value = op_stat_get_value(channel_throughput_handle, i); fprintf(fp, "%.6f,%.6f\n", time, value); } fclose(fp); }

这段代码把Channel Throughput统计量的每个采样点写入 CSV 文件，方便用 Python 或 Excel 做后续处理。op_stat_get_num_points返回采样点总数，op_stat_get_time和op_stat_get_value分别获取时间和数值。注意这个函数需要在仿真结束后的Simulation回调中调用，不能在进程模型内部直接调用。

3.4 纯 Aloha 与理论值的对比验证

跑完仿真后，把导出的吞吐率数据按负载水平重新整理。负载 G 的定义是：在包传输时间内到达的包数量，即G = arrival_rate * (pkt_len / channel_rate)。纯 Aloha 的理论吞吐率公式是S = G * exp(-2G)，最大值在G = 0.5处取得，S_max = 0.184。

在 OPNET 仿真中，如果参数设置正确，你应该能看到：当 G 从 0 增加到 0.5 时，S 从 0 上升到约 0.18；当 G 继续增加到 1.0 以上时，S 开始下降，最终趋近于 0。如果仿真曲线在 G = 0.3 时就达到峰值然后急剧下降，说明退避参数设置过激，冲突后的恢复太慢；如果曲线一直上升不下降，说明冲突检测没有生效，所有包都被当成了成功接收。

我一般会把仿真曲线和理论曲线画在同一张图上，用 Python 的 matplotlib 做对比：

import matplotlib.pyplot as plt import numpy as np # 理论曲线 G = np.linspace(0, 3, 100) S_theory = G * np.exp(-2 * G) # 仿真数据（从 CSV 读取） data = np.loadtxt('aloha_throughput.csv', delimiter=',', skiprows=1) G_sim = data[:, 0] # 需要根据实际数据调整列索引 S_sim = data[:, 1] plt.plot(G, S_theory, 'b-', label='Theory: S = G * exp(-2G)') plt.plot(G_sim, S_sim, 'ro', label='OPNET Simulation') plt.xlabel('Offered Load (G)') plt.ylabel('Throughput (S)') plt.legend() plt.grid(True) plt.savefig('aloha_comparison.png')

这段代码把理论曲线和仿真数据点画在一起，直观判断仿真是否可信。如果仿真点整体低于理论曲线，可能是物理层丢包或退避时间过长；如果仿真点整体高于理论曲线，大概率是冲突检测逻辑有漏洞。

4. 时隙 Aloha 的改造要点：时隙同步、边界对齐与吞吐率翻倍

4.1 时隙 Aloha 与纯 Aloha 的进程模型差异

时隙 Aloha 的核心改进是把时间划分为等长的时隙，节点只能在时隙边界开始发送。这个约束把冲突窗口从 2 倍包传输时间缩小到 1 倍，理论最大吞吐率从 18.4% 提升到 36.8%。在 OPNET 中实现时隙 Aloha，需要在进程模型里增加一个全局时隙同步机制。

最直接的做法是在每个节点内部维护一个时隙计数器，所有节点的时隙计数器在仿真开始时同步归零。具体实现是在init状态中调度第一个时隙边界中断：

/* 初始化时隙同步 */ FIN(aloha_slotted_init_enter) { /* 计算时隙长度：一个包的传输时间 */ slot_time = (double)pkt_len / CHANNEL_RATE; /* 调度第一个时隙边界中断 */ op_intrpt_schedule_self(op_sim_time() + slot_time, SLOT_BOUNDARY); /* 初始化其他变量 */ retry_count = 0; pkt_arrival_rate = DEFAULT_ARRIVAL_RATE; } FOUT

然后在idle状态中，当包到达时不能立即发送，而是等待下一个时隙边界：

/* 包到达时，如果不在时隙边界，缓存包并等待 */ FIN(aloha_slotted_idle_enter) { if (op_intrpt_type() == OPC_INTRPT_SELF && op_intrpt_code() == PKT_ARRIVAL) { /* 缓存包，等待时隙边界 */ pending_pkt = op_pk_get(op_intrpt_strm()); op_intrpt_schedule_self(op_sim_time() + slot_time, SLOT_BOUNDARY); } else if (op_intrpt_type() == OPC_INTRPT_SELF && op_intrpt_code() == SLOT_BOUNDARY) { if (pending_pkt != OPNIL) { /* 在时隙边界发送缓存的包 */ op_pk_send(pending_pkt, 0); pending_pkt = OPNIL; /* 调度发送完成中断 */ op_intrpt_schedule_self(op_sim_time() + slot_time, TX_COMPLETE); } /* 调度下一个时隙边界 */ op_intrpt_schedule_self(op_sim_time() + slot_time, SLOT_BOUNDARY); } } FOUT

这段代码的关键是pending_pkt变量和SLOT_BOUNDARY中断的配合。包到达时先缓存，等到时隙边界再发送。如果多个包在同一个时隙内到达，只发送第一个，其余的需要排队或丢弃，具体策略取决于你的应用场景。

4.2 时隙同步的精度问题与解决方案

OPNET 的仿真时间是离散事件驱动的，时隙边界的精度取决于op_intrpt_schedule_self的时间计算。如果slot_time用浮点数表示，多次累加后会产生累积误差，导致不同节点的时隙边界逐渐漂移。我遇到过跑 100 秒后时隙偏移超过 1 ms 的情况，直接让吞吐率曲线偏离理论值 10% 以上。

解决方法是不要在每次时隙边界中断时用op_sim_time() + slot_time计算下一个边界，而是用一个全局的时隙计数器：

/* 用全局计数器避免累积误差 */ static int slot_counter = 0; FIN(aloha_slotted_slot_boundary_enter) { slot_counter++; double next_boundary = slot_counter * slot_time; /* 如果下一个边界已经超过当前时间，调度中断 */ if (next_boundary > op_sim_time()) { op_intrpt_schedule_self(next_boundary, SLOT_BOUNDARY); } else { /* 时间已经超过，立即调度 */ op_intrpt_schedule_self(op_sim_time(), SLOT_BOUNDARY); } } FOUT

用slot_counter * slot_time计算绝对时间，而不是累加相对时间，可以消除浮点累积误差。slot_counter是整型变量，每次加 1，乘以slot_time后得到精确的时隙边界时间。这个方法在长时间仿真中尤其重要，我一般会在仿真 1000 秒以上的场景中强制使用。

4.3 时隙 Aloha 的吞吐率验证与参数边界

时隙 Aloha 的理论吞吐率公式是S = G * exp(-G)，最大值在G = 1.0处取得，S_max = 0.368。在 OPNET 中验证时，需要把包到达过程调整为时隙对齐的泊松过程，即每个时隙内到达的包数量服从泊松分布，但发送时刻固定在时隙边界。

仿真参数设置上，时隙长度必须严格等于包传输时间。如果时隙长度大于包传输时间，信道会出现空闲间隙，吞吐率下降；如果时隙长度小于包传输时间，包会跨时隙传输，冲突窗口重新变大。我一般会把时隙长度设为pkt_len / channel_rate的精确值，并在仿真日志中打印实际时隙长度和理论值的偏差。

另一个容易忽略的参数是节点的时隙同步误差。在实际系统中，时隙同步需要额外的信令开销，但在 OPNET 仿真中通常假设完美同步。如果你要模拟非完美同步，可以在每个节点的init状态中给时隙计数器加一个随机偏移：

/* 模拟时隙同步误差：给每个节点加随机偏移 */ double sync_error = op_dist_uniform(0.1) * slot_time; /* 最大 10% 时隙偏移 */ slot_counter = (int)(sync_error / slot_time);

这个偏移量会让不同节点的时隙边界错开，模拟实际系统中的同步误差。偏移越大，吞吐率越接近纯 Aloha；偏移为 0 时，吞吐率达到时隙 Aloha 的理论最大值。通过扫描偏移量，可以得到吞吐率随时隙同步精度的变化曲线。

5. 避坑与排查：Aloha 仿真中那些让曲线跑偏的细节

5.1 吞吐率曲线在低负载时就上不去

现象：包到达率很低时，吞吐率应该线性增长，但仿真结果显示吞吐率始终在 0.05 以下，远低于理论值。

原因：最常见的原因是物理层接收功率阈值设置过高，导致部分包被误判为丢失。OPNET 的radio receiver模块有一个Packet Reception Threshold属性，默认值可能不适合你的场景。另一个原因是进程模型中的op_pk_send调用没有正确设置流索引，包被发送到了错误的流上。

解决：检查radio receiver的Packet Reception Threshold，把它设为比最小接收功率低 3~5 dB。同时检查op_pk_send的第二个参数，确保流索引与物理层连接的流索引一致。可以在tx状态中加一行op_prg_log("Sending packet on stream %d", stream_index)来确认。

5.2 高负载时吞吐率突然塌陷到零

现象：当包到达率超过某个阈值后，吞吐率不是缓慢下降，而是突然掉到接近零，且不再恢复。

原因：这是典型的“退避同步”问题。所有节点用相同的退避算法和相同的退避基数，冲突后同时等待相同的时间，然后同时重传，再次冲突。反复几次后，所有节点都陷入无限重传循环，信道被无效重传占满。

解决：在退避时间计算中加入随机抖动，如 3.1 节代码中的op_dist_uniform(0.5)。另外，把最大重传次数限制在 5~7 次，超过后丢弃包而不是无限重传。如果问题依然存在，检查backoff_base是否过小，建议设为 3~5 倍包传输时间。

5.3 仿真结果每次跑都不一样

现象：同样的参数配置，每次运行仿真得到的吞吐率曲线差异很大，有时甚至相差 20% 以上。

原因：OPNET 的随机数种子默认是随时间变化的，每次仿真开始时种子不同，导致包到达过程和退避时间的随机序列不同。如果仿真时长不够长，统计量的方差会很大。

解决：在Simulation→Configure Simulation→Random Number Seed中设置固定种子，比如 42。同时把仿真时长增加到 300 秒以上，并跑 10 次不同种子取平均。如果需要在论文中报告结果，建议跑 20 次以上，给出均值和 95% 置信区间。

5.4 时隙 Aloha 的吞吐率只有纯 Aloha 的水平

现象：明明实现了时隙 Aloha，但吞吐率曲线和纯 Aloha 几乎一样，没有翻倍。

原因：时隙边界没有真正对齐。可能是slot_time的计算用了整数除法，比如pkt_len / CHANNEL_RATE中两个操作数都是整数，结果被截断为 0。也可能是SLOT_BOUNDARY中断的调度优先级低于PKT_ARRIVAL中断，导致包到达后立即发送，没有等待时隙边界。

解决：把slot_time的计算改为(double)pkt_len / CHANNEL_RATE，确保浮点运算。检查op_intrpt_schedule_self的中断码，确保SLOT_BOUNDARY和PKT_ARRIVAL不会互相抢占。可以在idle状态中加日志，打印每次发送时的op_sim_time()和最近的时隙边界时间，确认发送时刻是否对齐。

5.5 统计量曲线在仿真中途出现断点

现象：吞吐率曲线在某个时间点突然中断，之后没有数据。

原因：OPNET 的统计量采集有缓冲区大小限制，如果仿真时间过长或采样点过多，缓冲区会溢出，导致后续数据丢失。另一个原因是进程模型在某个状态下崩溃，比如op_pk_get返回了OPNIL但没有检查，后续操作导致仿真异常终止。

解决：在Simulation→Configure Simulation→Statistics中增大Statistic Buffer Size，一般设为 10000 以上。在进程模型的每个op_pk_get调用后加if (pkt == OPNIL) return;检查。如果仿真异常终止，查看Simulation Log中的错误信息，定位崩溃的状态和中断码。

6. 进阶技巧：用 OPNET 的仿真序列做参数扫描与结果自动化

6.1 用 Simulation Sequence 批量扫描退避基数

手动改参数跑仿真只能得到零散的结果，要找到最优参数组合，需要用 OPNET 的Simulation Sequence功能做批量扫描。具体操作：在Simulation菜单中打开Simulation Sequence，新建一个序列，添加两个扫描变量：backoff_base从 1 到 10，步长 1；max_retries从 3 到 7，步长 1。这样一次提交可以跑 50 个仿真，自动生成参数组合与吞吐率的对应关系。

在Simulation Sequence中，每个仿真运行结束后会自动保存结果到.os文件。你可以用 OPNET 的Results模块批量导出，也可以用脚本解析.os文件。我一般用 Python 的os模块调用 OPNET 的命令行工具op_run来批量执行：

import subprocess import os # 批量运行仿真序列 def run_simulation_sequence(seq_file): cmd = ['op_run', '-seq', seq_file, '-out', 'results/'] result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: print(f"Simulation failed: {result.stderr}") else: print(f"Simulation completed: {result.stdout}") # 解析结果文件，提取吞吐率 def parse_results(result_dir): throughput_data = {} for filename in os.listdir(result_dir): if filename.endswith('.os'): # 解析 .os 文件，提取 Channel Throughput # 具体解析逻辑取决于 OPNET 版本和文件格式 pass return throughput_data

这段代码调用 OPNET 的命令行工具执行仿真序列，然后解析结果文件。op_run是 OPNET 提供的命令行接口，-seq指定序列文件，-out指定输出目录。解析.os文件需要根据具体格式处理，一般可以用 OPNET 的op_stat接口导出为 CSV 后再用 pandas 分析。

6.2 用 Python 做参数敏感度分析与可视化

拿到批量仿真结果后，用 Python 做参数敏感度分析。下面是一个示例，分析退避基数和最大重传次数对吞吐率的影响：

import pandas as pd import matplotlib.pyplot as plt import seaborn as sns # 读取批量仿真结果 df = pd.read_csv('batch_results.csv') # 透视表：退避基数 vs 最大重传次数，值为吞吐率 pivot = df.pivot_table(values='throughput', index='backoff_base', columns='max_retries', aggfunc='mean') # 热力图 plt.figure(figsize=(10, 6)) sns.heatmap(pivot, annot=True, fmt='.3f', cmap='YlOrRd') plt.xlabel('Max Retries') plt.ylabel('Backoff Base (x tx_time)') plt.title('Throughput vs Backoff Parameters') plt.savefig('sensitivity_heatmap.png')

这段代码用 pandas 的pivot_table把批量结果整理成二维表格，然后用 seaborn 画热力图。从热力图上可以直观看到：退避基数在 3~5 之间、最大重传次数在 5~7 之间时，吞吐率最高。退避基数过小（1~2）会导致反复冲突，吞吐率下降；退避基数过大（8~10）会导致信道空闲时间过长，吞吐率也下降。

6.3 一个我常用的验证习惯

每次跑完 Aloha 仿真，我不会只看吞吐率曲线，而是会同时检查三个量：吞吐率、MAC 延迟、丢包率。这三个量是联动的——吞吐率上升时延迟通常也会上升，丢包率在高负载时会急剧增加。如果吞吐率上升但延迟不变，大概率是统计量采集有问题；如果丢包率在低负载时就很高，说明物理层或冲突检测有 bug。

我一般会把这三个量画在同一张图上，用双 Y 轴：左轴是吞吐率和丢包率，右轴是 MAC 延迟。这样一眼就能看出系统在哪个负载点开始进入拥塞状态。这个习惯帮我省了很多来回排查的时间，也让我对 Aloha 协议的性能边界有了更具体的感知。希望帮到你。

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