ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

OPNET中Aloha协议MAC层仿真:从进程模型搭建到吞吐率验证的完整指南

OPNET中Aloha协议MAC层仿真:从进程模型搭建到吞吐率验证的完整指南 简介这份资源面向无线传感器网络与多址接入协议的学习者尤其是使用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 仿真以下几个参数对结果的影响最大需要重点标定参数名典型取值对吞吐率的影响调整方向包到达率1~50 packets/sec决定负载水平从低到高扫描包长度512~4096 bit影响传输时间与冲突窗口固定值便于对比信道速率1~11 Mbps决定传输时间基准与包长匹配最大重传次数3~7影响高负载下的稳定性过小丢包多过大延迟高退避基数1~5 倍传输时间影响冲突后的恢复速度过小再次冲突过大吞吐率下降这张表里的取值不是拍脑袋来的。以包长 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 DelayMAC 层延迟在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,, skiprows1) G_sim data[:, 0] # 需要根据实际数据调整列索引 S_sim data[:, 1] plt.plot(G, S_theory, b-, labelTheory: S G * exp(-2G)) plt.plot(G_sim, S_sim, ro, labelOPNET 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步长 1max_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_outputTrue, textTrue) if result.returncode ! 0: print(fSimulation failed: {result.stderr}) else: print(fSimulation 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(valuesthroughput, indexbackoff_base, columnsmax_retries, aggfuncmean) # 热力图 plt.figure(figsize(10, 6)) sns.heatmap(pivot, annotTrue, fmt.3f, cmapYlOrRd) 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 协议的性能边界有了更具体的感知。希望帮到你。本文还有配套的精品资源点击获取
返回列表