简介：面向自组织网络协议研究者与工程开发人员，这份资源以OPNET仿真为平台，提供媒体接入控制层协议修改与仿真的完整源程序。压缩包内共九个文件，主体为六个以m为扩展名的源码文件，用于描述无线局域网媒体接入控制接口、交互上下文信息配置与目标地址传递等模块；另有一个c语言文件、一份txt说明文档和一个obj对象文件，整体大小约为二十九KB。目前已有三百八十四人学习下载。通过阅读这些代码，可以掌握在OPNET中自定义媒体接入控制层模型的方法，并基于Useful65模型快速搭建自组织网络仿真场景，分析信道利用率、吞吐量、丢包率与端到端延迟等性能指标。对于需要优化信道访问机制、降低冲突概率或提升能量效率的研究课题，具有直接参考价值，适合作为课程设计、毕业设计或科研入门阶段的学习素材。

1. 想改Ad Hoc MAC协议就别只调参数：usefull65工程里的源码才是主菜

做Ad Hoc网络MAC层协议修改和仿真，最磨人的不是算法本身，而是改完之后如何在OPNET里把改动落实到进程模型、还能让仿真结果证明改动是有效的。这份usefull65仿真源程序把节点模型、进程模型、配置ICI、控制帧格式和移动性模块全部放在同一个工程里，打开就能看到MAC接口处理信道接入、退避、重传和转发控制帧的完整动作。它解决的不是“怎么点按钮把仿真跑通”，而是“MAC层协议改了自己说了算，还要给评审和论文一个可复现的实验证据”。适合正在做Ad Hoc组网协议对比、毕业论文要做MAC优化、或者工作中要用OPNET Modeler验证新接入算法的研究生和工程师。拿到资源后先别急着运行，把压缩包里的每个文件按类型拆出来过一遍，后面少踩很多坑。

2. 拆开压缩包到OPNET工程：五个核心文件的分工与调用链

2.1 文件类型自查：一个OPNET工程不是只有单个.pr.m

OPNET Modeler的工程文件不是一种格式包打天下。同一个目录下，.pr.m是进程模型，.nd.m是节点模型，.pk.m是报文格式，.ic.m是ICI（接口控制信息）格式，而.pr.c是进程模型翻译出来的C语言源码。初次接触这个工程的人很容易只盯住.pr.m，以为改协议就是把状态图里某个转移条件改一下，实际改起来才发现属性读取失败、参数传不进去、编译对象没更新，哪一个都能让仿真结果失真。

先把文件类型弄明白再动手。这份资源里出现的文件主要分四类：以gpr_wlan_开头的是无线局域网部分的模型文件，以GPR_MAC_开头的是MAC模块相关的ICI格式，以gpr_billard_开头的是移动性模型，还有一个www.pudn.com.txt是来源站点的说明文本，不属于仿真模型部分。下表把文件类型和它在工程里的作用列清楚，方便对照。

把这张表记住之后，你再看压缩包就不会被文件后缀绕晕。gpr_wlan_mac_interface.pr.c和.pr.m本质上对应同一个进程模型，.c是源代码形态，.m是可以在OPNET进程模型编辑器中打开的状态图形态；两者不一致时，以你重新编译生成的版本为准。gpr_wlan_station_adv.nd.m是节点级装配图，它决定上层协议栈怎么和MAC接口进程连起来。这里有个容易被忽略的细节：.pr.c是导出的C代码，并不一定在每次仿真时都被执行，OPNET实际加载的是编译后的模型对象。所以修改完.c之后如果不重新编译，改动对运行结果毫无影响，这个坑后面的排查章节还会专门展开。

2.2 五个核心文件怎么配合：从建包到接入的一条调用链

从通信时序看，这五个文件的协作顺序大致是这样。初始化阶段，节点模型gpr_wlan_station_adv.nd.m里的上层模块创建GPR_MAC_CFG_ICI.ic.m格式的配置ICI，把时隙长度、退避上限、重传门限这类参数打包，通过op_ici_install挂到MAC接口进程的事件里；MAC进程在INIT状态读取并保存。进入数据发送阶段，上层协议栈构造数据包，创建GPR_MAC_Dest_ICI.ic.m格式的目标ICI，标明接收节点的地址；MAC接口进程拿到目标地址后，先做载波监听和退避，再决定直接发送还是先发RTS控制帧。

gpr_wlan_control.pk.m定义的控制帧在这里起作用：当节点走RTS/CTS流程时，MAC进程先发送一个RTS帧，收到对端CTS回应后才进入数据发送；如果开启的只是基础CSMA/CA流程，则控制帧只包含ACK确认。gpr_wlan_mac_interface进程做决策，控制帧用gpr_wlan_control承载，参数和目标地址由两个ICI传递，最终所有模块通过gpr_wlan_station_adv节点模型组装在一起，形成一个可运行的无线工作站。

这就是为什么绝大多数MAC层修改都从gpr_wlan_mac_interface入手。节点模型是装配层面的改动，通常只在你要给工作站增加新的模块比如再加一个物理收发信机、插入一个队列模块时才动；报文格式和ICI格式属于数据结构层面的改动，配合新协议增加字段时才会碰；真正决定“节点在什么时候能发包、遇到冲突怎么退避、重传几次就放弃”的，都在MAC接口进程模型内部。后面第3章的修改工作也是围绕这一点展开。如果你拿到工程后时间有限，优先级排序应该是：先读gpr_wlan_mac_interface的进程逻辑，再用GPR_MAC_CFG_ICI做参数注入，最后才考虑改节点模型和报文格式，这条路径能让你在最短时间内看到协议修改对仿真结果的影响。

3. 改MAC接口进程模型：从退避逻辑到配置ICI注入的三个落点

3.1 先读状态转移图：退避、接入时序和确认处理是修改的主战场

打开gpr_wlan_mac_interface.pr.m，你首先看到的是状态转移图。典型的WLAN MAC进程模型会包含初始化态、空闲态、退避态、发送态和等待确认态，节点从初始化态进入空闲态后，一旦上层有数据到达就触发信道检测，信道忙则进入退避态；退避结束再次检测，信道空闲就发送，发送后进入等待确认态，收不到ACK就重传。这整个循环对应的是CSMA/CA的核心流程，也是Ad Hoc网络各节点在没有中心控制时公平竞争共享无线信道的根本机制。

修改MAC协议时，我一般会从三个位置下手。第一个是退避计算：默认退避值由竞争窗口决定，想让节点延迟更久或者引入额外随机量，就在退避态里改。第二个是接入时序：DIFS或帧间间隔决定了发送前必须等待的静默时间，调长DIFS等于给低优先级节点增加接入难度。第三个是重传和确认超时：重传上限决定冲突后的最大尝试次数，确认超时决定节点多快判断一帧丢失并进入重传。这三个位置的共同特点是，它们都写在进程模型的函数体里，而不是写在GUI属性面板里；属性面板只暴露少数参数，真正控制逻辑走向的是状态转移函数。

以退避修改为例，常见做法是在退避态的处理函数里读入一个自定义的额外时隙数，给原退避值叠加随机量。下面是按OPNET的Proto-C语法写出的大致实现：

/* 在退避态处理函数里给backoff增加自定义扩展时隙 */ static void gpr_wlan_mac_handle_backoff (GprWlanMacT* mac_ptr) { int cw_current; int extra_slot = 0; double rand_value = 0.0; Objid node_obj = op_topo_parent (op_id_self ()); /* 读取节点属性，属性名要和节点模型里定义的完全一致 */ if (op_ima_obj_attr_get (node_obj, "GPR_Extra_Slot", &extra_slot) == OPC_COMPCODE_SUCCESS) { /* op_dist_uniform(x) 返回 (0, x) 范围内的随机数 */ rand_value = op_dist_uniform (extra_slot); } cw_current = mac_ptr->backoff_remain; mac_ptr->backoff_remain = cw_current + (int) rand_value; if (mac_ptr->backoff_remain < 0) mac_ptr->backoff_remain = 0; /* 退避结束，回到信道检测逻辑，检查信道是否空闲 */ gpr_wlan_mac_check_channel (mac_ptr); }

这段代码里的op_ima_obj_attr_get是OPNET读取节点属性的标准接口，第一个参数是节点对象ID，第二个是属性名，第三个是存放结果的地址。这里用op_topo_parent(op_id_self())取到当前进程所属的节点对象，因为MAC进程是节点内部的一个模块进程，直接使用op_id_self()会得到模块而不是节点，取父节点才能正确读取节点级属性。返回值OPC_COMPCODE_SUCCESS表示读到了属性；如果节点模型里没有定义GPR_Extra_Slot这个属性，函数返回失败码，代码不会进入扩展分支，退避行为保持原样。这一点很关键，后续避坑章节里改成参数无效的问题，多半就出在属性名对不上但代码没有报错上。

op_dist_uniform(extra_slot)生成的是(0, extra_slot)区间的随机数，注意不包含0，所以extra_slot取0时这个调用没有意义，调用前应做一个大于0的判断。在实际使用里，我会额外加一个上限保护，避免随机数过大导致退避时间被拉高到秒级，否则整网时延会异常恶化。退避逻辑改完之后，DIFS和重传的修改思路相同：先定位对应状态函数，把固定常量改成可配置变量，再从属性或ICI里读取新值覆盖默认值。这里的“可配置变量”建议统一放进一个结构体里管理，方便仿真参数扫描时批量修改，也方便回溯一组实验到底用了哪些参数。

3.2 配置ICI：把修改后的参数越过层间边界送进MAC进程

退避参数改在代码里，但仿真每次跑完要调整这些值，总不能每换一组参数就重新编译一次进程模型。OPNET里常见做法是把这类参数通过ICI在初始化阶段注入，这样只需在配置场景时修改ICI字段的值，进程模型代码不用重新编译。这份资源里的GPR_MAC_CFG_ICI.ic.m就是干这个用的。

在进程模型的INIT状态里，可以主动安装ICI实例并从当前事件中读取其中字段。参考实现如下：

/* 在初始化状态读取配置ICI，把字段值写入MAC状态变量 */ static void gpr_wlan_mac_init_config (GprWlanMacT* mac_ptr) { Ici* cfg_ici; double slot_time = 0.0; int max_backoff = 0; /* 安装一个ICI实例，用于从当前事件读取接口控制信息 */ cfg_ici = op_ici_install (OPC_ICI_TYPE); if (cfg_ici == OPC_NIL) return; /* 字段名必须与 .ic.m 文件定义一致，注意大小写敏感 */ if (op_ici_attr_get (cfg_ici, "Slot_Time", &slot_time) == OPC_COMPCODE_SUCCESS) { mac_ptr->slot_time = slot_time; } if (op_ici_attr_get (cfg_ici, "Max_Backoff", &max_backoff) == OPC_COMPCODE_SUCCESS) { mac_ptr->max_backoff = max_backoff; } /* 读取失败时保留默认值，保证仿真不会因参数缺失而中断 */ }

这里有几个需要注意的参数细节。op_ici_install(OPC_ICI_TYPE)创建一个ICI实例，返回值是ICI指针；一般情况下它会在当前事件处理结束后由OPNET自动回收，不需要手动释放。op_ici_attr_get的字段名必须和.ic.m文件里定义的字段名完全一致，包括大小写和前缀，比如Slot_Time和slot_time在OPNET看来是两个不同的字段。读取失败时，代码只保留默认值，不会中断仿真，但这也意味着你辛辛苦苦配置的参数可能根本没生效——这是后面排查“改了没反应”的常见根源。

实际项目里，我会在初始化完成后输出一句调试日志，把读到的slot_time和max_backoff打出来。这样每次启动仿真，先在运行日志里确认参数确实是按预期注入的，再做后续统计对比。如果没有这一行日志，参数传没传到MAC进程，只能靠猜，等于把一个本来可控的环节变成了黑匣子。除了参数注入，还要提防ICI实例被重复安装：同一个事件处理过程中，如果多次调用op_ici_install创建同名实例，后创建的会覆盖前一个，可能把前面的配置冲掉。我一般会先判断当前事件是否已经带有了ICI，有就用现成的，没有再新建。与之配套的GPR_MAC_Dest_ICI.ic.m作用类似，但它承载的是目标地址信息，在Ad Hoc多跳转发场景里，它决定数据帧在MAC层的投递目标；要改广播转发或组播行为，动的是这个ICI的字段。

4. 让Ad Hoc仿真跑起来：挂载节点模型、移动性脚本与参数表设置

4.1 搭一个最小可复现的仿真场景

拿到这份资源后，建议先搭一个节点数量在10到20之间的Ad Hoc场景，而不是一上来就复现论文里的百节点网络。因为MAC层修改验证的核心是退避和冲突行为，节点太少看不出信道竞争，节点太多又难定位问题是出在MAC还是路由。常见做法是先在OPNET项目编辑器里新建一个空场景，再从节点对象列表中选择自定义的gpr_wlan_station_adv节点模型，把它放置在场景中。

配置无线工作站时，有几个点需要和MAC修改配合。物理层的数据速率决定了单帧传输时间，速率越高，相同负载下信道占用时间越短，退避行为对整体时延的影响越明显；建议在同一组对比实验里固定数据速率，只改变MAC层的退避参数。应用层流量尽量使用恒定比特率，报文大小512字节、发送间隔0.1秒，这样统计曲线更平滑，不会因为流量源自身的突发性干扰对MAC行为的判断。无线信道参数里，传输功率和接收门限直接决定节点之间的干扰范围，Ad Hoc仿真中节点密度和覆盖范围的比值要合理，否则会出现大面积隐藏终端，退避算法再改也看不出效果。

场景搭好之后，把节点协议栈改为Ad Hoc模式，关闭接入点相关功能。因为gpr_wlan_station_adv是一个自组织工作站节点模型，它本身没有中心控制节点参与，所有节点平等竞争信道，这一步要确认节点属性里的工作模式不是Infrastructure模式。MAC地址、IP地址可以按节点编号顺序配置，方便后续按地址抓统计量。如果你打算跑多跳场景，还要给节点配置路由协议，AODV或DSR都可以，但注意路由协议本身就带一部分控制开销，会和MAC层退避互相影响；我的做法是先跑两跳以内的简单场景验证MAC修改，再扩展到多跳。

4.2 移动性模型对MAC退避仿真结果的显性影响

Ad Hoc仿真里移动性模型很容易被忽略，但实际上它对MAC层的退避统计影响很大。节点静止时，信道状态相对稳定，退避事件的触发较规律；节点移动时，链路距离变化导致接收信号强度波动，丢包和重传会增加，退避次数和时延都会跟着变。这份工程里的gpr_billard_mobility移动性模型，从命名就能猜出它的行为逻辑：节点像台球一样在场景边界反弹，撞墙之后改变运动方向继续移动，避免节点长时间停留在一个固定位置。

在OPNET中挂载这个模型的方法是在节点的移动性属性里选择自定义的进程模型，然后配置速度和初始方向。模型内部会按仿真时间周期更新节点位置，移动边界默认与场景尺寸相关。示例代码如下：

/* 台球式移动性的初始化：设定速度、方向与边界 */ static void billard_mobility_init (GprBillardState* ms, Objid node_obj) { double speed = 5.0; /* 默认移动速度，单位m/s */ double direction = 0.0; /* 初始方向，单位度 */ int scene_x = 1500; /* 场景宽度，单位m */ int scene_y = 1500; /* 场景高度，单位m */ /* 读取节点属性，覆盖默认速度与方向 */ op_ima_obj_attr_get (node_obj, "Speed", &speed); op_ima_obj_attr_get (node_obj, "Initial_Direction", &direction); /* 把极坐标方向换算成平面速度分量 */ ms->vx = speed * cos (direction * M_PI / 180.0); ms->vy = speed * sin (direction * M_PI / 180.0); ms->bound_x = scene_x; ms->bound_y = scene_y; }

这里op_ima_obj_attr_get同样是标准属性读取接口，Speed和Initial_Direction如果没在节点模型里定义，读取失败后就会沿用代码里的默认值。速度一般取1到10 m/s，对应步行到车载的移动场景；速度太高会导致链路频繁断裂，MAC层统计结果里重传占比会大幅上升，导致退避参数的影响被噪声淹没。M_PI在部分编译环境里需要自行定义，比如#define M_PI 3.14159265358979323846，遇到编译报错时先检查这一点，这属于移植过程中很常见的低级但麻烦的问题。

把移动性模型挂上之后，记得要确认每个节点都用同一个进程模型实例，而且仿真时间要足够长。移动对统计结果的影响会随时间累积，仿真时间只跑几十秒的模拟，节点还没移动几步，移动性配置等于白设。我一般会让仿真时间跑到300秒以上，统计区间从第50秒之后开始取，把冷启动阶段的异常排除在外。

4.3 参数表：把你改的MAC参数和场景参数对应起来

为了让新手能直接对照着配置，这里给出一张我在Ad Hoc MAC仿真里常用的参数表。它不是标准答案，但对复现这个工程、验证退避修改非常有用。

这张表里的GPR_Extra_Slot和Max_Backoff是进程模型自加的属性，如果节点模型里没有定义这两个属性，需要先回到gpr_wlan_station_adv.nd.m中把它们补上，或者在gpr_wlan_mac_interface的读取失败分支里保持默认值。参数扫描时，建议一次只改一个维度的参数，比如固定场景和流量，只改变GPR_Extra_Slot的取值，这样统计结果的变化才能归因于退避修改本身。多参数同时改动，最后定位不了是哪一项引起的差异，等于浪费了一整轮仿真时间。

5. 避坑排查：Ad Hoc MAC仿真的五个经典翻车点

5.1 现象：模型编译通过，仿真一运行就中途退出

OPNET对进程模型的编译检查和运行期行为是两回事。编译通过只说明语法没有致命错误，运行期崩溃往往出现在属性读取和空指针防护上。我在这个工程里见过最多的情况是，gpr_wlan_mac_interface进程代码里读取了GPR_Extra_Slot，但gpr_wlan_station_adv.nd.m节点模型里根本没有定义这个属性。op_ima_obj_attr_get返回失败码后，代码仍继续使用未初始化的变量，后续引用空状态变量直接导致进程异常退出。

解决方法是三步走。先在节点模型编辑器的属性列表里确认GPR_Extra_Slot是否存在，属性名是否和进程代码里完全一致；如果不存在，在节点模型上添加该属性并设置默认值。然后在进程代码的读取分支里加入返回值判断，读取失败时就给默认值。最后在初始化状态加一条调试日志，每次仿真启动时把读到的参数值打印出来，确认属性真的进了状态变量。这三步做完之后，这类崩溃基本不会再出现。记住一个原则：OPNET里属性读取的失败不会像普通C语言那样当场报段错误，它只会安静地返回一个错误码，真正的崩溃往往发生在后面很远的地方。

5.2 现象：改了退避参数，统计曲线纹丝不动

这是最让人怀疑人生的现象：代码改得很好，参数也配了，仿真跑完，吞吐量和时延曲线与修改前完全重合。原因多半不在逻辑，而在编译对象。OPNET进程模型在运行时调用的是编译后的目标对象，如果你修改了.pr.c但没有重新生成进程模型，或者进程模型编辑器里改了状态图但没有执行Rebuild，仿真实际调用的还是旧代码，你的修改自然毫无痕迹。

解决方法是进入进程模型编辑器，确认当前模型已保存，然后在编译菜单里重新生成目标对象。更稳妥的做法是把旧的.dev32.i0.pr.obj文件删掉，让OPNET强制全量重建。还要检查一个容易忽略的点：节点模型里引用的进程模型名是否正确。如果gpr_wlan_station_adv.nd.m里引用的是另一个进程名，你改的gpr_wlan_mac_interface根本就没被装入仿真。检查方式是打开节点模型里MAC模块的属性设置，看进程模型字段指向的名字和工程文件名是否一致。养成修改后立即Rebuild的习惯，可以省掉无数排查时间。

5.3 现象：节点模型和ICI字段对不上，报出attribute not found

GPR_MAC_CFG_ICI.ic.m定义了Slot_Time和Max_Backoff字段，进程代码里用op_ici_attr_get读取时却报了attribute not found，这是ICI字段名不一致导致的。OPNET的ICI字段名对大小写敏感，Slot_Time写成slot_time就会读取失败，而且这个失败不中断仿真，只是字段保持默认值。最坑的是，它在启动阶段不会弹窗，只有在认真对比结果时你才发现参数根本没传进去。

解决方法是打开ICI格式定义文件，把字段列表逐字复制到代码里，不要手动敲。如果不想让参数缺失悄悄发生，可以在初始化时用op_ici_attr_get的返回值做一次判断，读取失败就直接打印警告日志。日志里带上期望字段名和实际ICI格式名，排查时一眼就能看出是哪里对不上。字段名对不上这个问题，在多人协作或者从网上找来的工程里尤其高发，因为原作者命名习惯和你习惯的命名方式很可能不同。

5.4 现象：billard移动性模型在64位环境下运行异常

这份工程里带了一个gpr_billard_mobility.dev32.i0.pr.obj编译对象，注意它的dev32后缀，这是32位平台编译产物的记号。如果当前环境是64位操作系统、或者OPNET版本和原编译环境不一致，直接沿用这个对象文件可能导致模型加载失败或运行时行为异常。我在换机器验证工程时遇到过不止一次，现象是节点移动状态完全不更新，或仿真启动时提示对象文件无法解析符号，总之节点位置像被钉死了一样。

解决办法很简单：删除.dev32.i0.pr.obj，让OPNET从.pr.m源码重新生成当前平台的目标文件。如果你的进程模型引用了系统库之外的第三方库，重新编译前要把库路径加进OPNET的编译配置里。一条值得养成的习惯是，每次换环境后在正式跑统计之前，先跑一个5秒的小场景确认节点是否按预期移动，避免把问题拖到统计完成之后才发现。对象文件是平台相关的，这个常识在仿真工程里同样适用。

5.5 现象：仿真结果剧烈摆动，像“发散”一样失去解释性

有些参数配置下，统计曲线会异常剧烈地摆动，端到端时延在低值和高值之间来回跳，吞吐量波形也没有稳定趋势，这通常不是随机噪声，而是参数组合把系统推到了不稳定区。常见原因是退避上限设得过大或重传次数过多：退避时间过长时，节点长时间不发送，缓存堆积后又在某个时刻集中释放，形成周期性的突发和空窗，统计曲线自然发散。另一种情况是节点密度过高同时移动速度过快，链路频繁断裂，重传雪上加霜，整个网络陷入持续冲突状态。

解决方法是先把参数拉回常规区间，比如退避上限取3到5，重传次数取默认值，确认曲线稳定后再逐步调高。在做多参数扫描时，先固定其他维度，只动一个MAC参数，观察曲线从稳定到发散的分界点，这个分界点本身就是MAC协议性能的有效信息。把发散当成仿真的正常输出，往往会让后续统计分析完全失真。仿真发散不是失败，它在告诉你参数组合越过了稳定边界，这正是研究MAC协议极限性能最有价值的部分。

6. 验证MAC修改是否生效：抓三个统计量做对比实验

6.1 三个统计量怎么抓

MAC层修改的效果，不能靠“感觉节点变慢了”来下结论。我习惯每次实验固定抓三个统计量：网络吞吐量、端到端平均时延、重传次数或丢包率。吞吐量看整体传输能力有没有因为退避修改而下降；端到端时延看接入等待和排队延迟的变化；重传次数直接反映冲突控制的效果。在OPNET的结果面板里勾选这三个指标，跑完仿真导出CSV，后续用脚本处理均值。

对比实验要做的事是保持场景完全一致，只改变MAC进程模型的版本。推荐把基线工程和修改后工程分别保存成两个项目文件，流量模型、节点位置、随机种子全部相同，只更换gpr_wlan_mac_interface的实现，这是排除变量干扰最干净的做法。跑完三轮随机种子取平均，再绘制曲线对比：

# 对比基线与修改版的吞吐量均值，用于验证MAC修改是否生效 import csv def throughput_mean(path): with open(path, newline='') as f: rows = list(csv.reader(f)) vals = [float(r[1]) for r in rows[1:] if float(r[1]) > 0] return sum(vals) / len(vals) if vals else 0.0 base = throughput_mean("baseline_throughput.csv") mod = throughput_mean("modified_throughput.csv") print(f"baseline: {base:.1f} bps, modified: {mod:.1f} bps")

脚本里过滤掉值为0的采样点，是为了把仿真初始阶段没建立连接的空档排除在外。取均值之前先看一眼曲线是否平稳，如果前段明显偏高或偏低，就丢弃前几秒的数据再做均值，这个习惯能避免冷启动阶段把整个统计带偏。

6.2 对比实验的另一种验证方式

如果你改的是退避时序类参数，除了看均值，还要关注时延的分布特性。拿一组修改前后的端到端时延采样，计算P50和P90分位数，能看出新协议是整体抬高了时延，还是只把尾部高时延降下来了。这两种情况对应的接入策略完全不同，只看均值容易掩盖问题。举例来说，如果P50基本不变但P90明显下降，说明修改主要改善了高负载下的排队和冲突，这是很典型的退避优化效果；如果P50和P90同步抬升，则说明新协议付出的接入代价偏大，需要权衡公平性和吞吐量。

从那以后我每次改完MAC层模型，都强制走一遍固定流程：确认属性名和ICI字段名逐字匹配、检查编译对象已重建、跑一次5秒小场景验证节点移动和参数注入正常、再跑三轮随机种子统计。这套流程救过我很多次，因为大量“协议没改对”的结论，最后都发现是编译未生效或参数未注入这些低级问题。如果这份工程也让你在Ad Hoc MAC仿真上少绕两个弯，那就值了。希望帮到你。

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