简介面向无线网络研究与OPNET仿真学习者的802.11-MAC协议源代码包适合需要理解WLAN信道接入机制、开展协议建模与性能分析的高校学生和开发人员。压缩包共356个文件、约1.31MB以OPNET模型文件ov、os、C语言源码c、编译中间文件obj、lib、dll及实验配置与日志文件为主保留了较完整的工程结构便于在OPNET中加载、阅读和二次调试。已有876人学习说明其在相关课程与科研中具有一定参考价值。通过梳理代码可具体观察帧结构定义、CSMA/CA载波侦听与退避流程、DCF分布式协调功能的实现方式并据此复现仿真、对比不同场景下的MAC性能为无线网络课程实验、协议改进和网络设计提供可操作的代码依据。1. 802.11 的吞吐量算不准是因为竞争本身就带随机性拿 opnet 跑 802.11 的 MAC多数人第一件事是把仿真出来的吞吐量和手算值对一下然后发现对不上而且差得不是一点半点。这份 opnet 802.11 MAC 协议的源代码价值恰恰在这里它把“为什么对不上”摊开成了一个个状态和变量。分布式协调靠的是每个节点各自数退避、各自听信道碰撞是概率事件重传次数是随机变量隐藏终端把“能不能听见”变成拓扑问题。教科书上那套饱和吞吐量公式前提是无限负载、无限重传、所有节点互相能听见一旦落到有限负载、多速率和部分可见的信道里公式就失效。想搞清慢在哪一段——是退避等太久、是 ACK 超时太频繁、还是重传把窗口顶到了上限——只能读 MAC 的源代码看状态机究竟在哪一步停下来等。2. CSMA/CA 的状态机为什么 MAC 逻辑必须写成有限状态机2.1 一帧从上层到空口ICI 是唯一的“信封”上层协议栈递给 MAC 的是一个 packet 对象但“怎么发”这件事——用哪个数据率、发到哪个信道、优先级多高、目的地址是谁——并不能塞进包里。包是载荷的容器它会被排队、被分片、被重传、被销毁重造“怎么发”这组信息只在跨层那一瞬间有效。把两者混在一起重传时就得把已经改过的字段再改回去是很典型的踩坑来源。OPNET 的做法是引入 ICIInterface Control Information一个独立于包的属性集合随包走一段就被销毁。常见的写法是上层创建 ICI、填属性、挂在包上MAC 取包的同时取 ICI把有用字段搬进自己的队列结构然后立刻销毁 ICI。/* 流中断上层递交一帧。包只管载荷怎么发全在 ICI 里 */ pk op_pk_get (op_intrpt_strm ()); /* 取出包 */ ici op_pk_ici_get (pk); /* 取出随包过来的接口控制信息 */ op_ici_attr_get (ici, dest_address, dest_addr); op_ici_attr_get (ici, data_rate, data_rate); op_ici_attr_get (ici, priority, priority); /* 入队。注意不是简单 FIFO后面 5.5 会讲优先级映射为什么常常失效 */ wlan_mac_queue_insert (pk, priority, dest_addr); op_ici_destroy (ici); /* 信息已落到 MAC 自己的数据结构 */op_pk_ici_get拿到的是挂在这个包上的 ICI 句柄属性名按当前模型的 ICI 格式定义不同版本里字段名会有出入但“目的地址、数据率、优先级、信道号”这四类基本跑不掉。关键是op_ici_destroy这一句不能省ICI 不是包的一部分不销毁就会一路泄漏到仿真结束跑长仿真时内存曲线会很难看。2.2 状态迁移不是 if-else 堆出来的中断类型和中断码决定一切离散事件仿真里没有“阻塞等待”这回事。任何“等 50 微秒”“等 ACK 回来”都必须翻译成“请在未来的某个时刻给我投递一个事件”否则进程就永远醒不过来。这就是 MAC 必须写成状态机的根本原因——不是风格问题是内核约束。OPNET 的进程模型把这件事抽象成状态加中断。事件进来时先判op_intrpt_type()再判op_intrpt_code()两者合起来唯一确定“发生了什么”中断类型来源中断码通常是典型处理OPC_INTRPT_STRM上层协议 / 无线接收机流号收帧、入队、更新 NAVOPC_INTRPT_SELF自己排的定时器自定义码退避时隙、ACK 超时、NAV 归零OPC_INTRPT_BEGSIM内核无读属性、注册统计量、初始化OPC_INTRPT_ENDSIM内核无冲刷统计量、释放队列/* 状态机主干所有事件先分流再落到具体状态里处理 */ switch (op_intrpt_type ()) { case OPC_INTRPT_STRM: /* 同一个流号既可能是上层递交也可能是接收机上报靠 code 区分 */ if (op_intrpt_code () WlanC_FROM_UPPER) { mac_state wlan_mac_frame_arrival (); } else { mac_state wlan_mac_frame_reception (); } break; case OPC_INTRPT_SELF: switch (op_intrpt_code ()) { case WlanC_SLOT_INTRPT: mac_state wlan_mac_backoff_tick (); break; case WlanC_ACK_TIMEOUT: mac_state wlan_mac_retry (); break; case WlanC_NAV_EXPIRE: mac_state wlan_mac_channel_idle ();break; } break; }wlan_mac_frame_arrival()这类函数返回的是“下一个状态”而不是在里面直接跳转。这么做的好处是状态迁移集中在一处改协议扩展比如加上 EDCA 的四条接入类别时只需要动返回值和分支不用在几十个函数里找goto。血泪经验是一旦有人在 executive 里直接改mac_state又忘了返回值状态机就会出现“看起来进了 BACKOFF 其实还在 DEFER”的幽灵状态仿真结果全错但一条报错都没有。2.3 状态变量块谁记住了退避计数器和 NAV进程的局部变量在 executive 返回时就没了而 MAC 需要跨中断记住的东西非常多当前退避还剩几个时隙、竞争窗口现在多大、已经重试了几次、NAV 什么时候归零、手上这一帧是不是分片。这些必须放进状态变量块由内核在进程整个生命周期内保留。常见的状态变量大致是这几类mac_state当前状态、backoff_slots剩余退避时隙、cw当前竞争窗口上界、short_retry_cnt/long_retry_cnt两套重试计数、nav_end_timeNAV 到期时刻、channel_idle_since信道连续空闲的起点、current_frame正在发或正在等的那个包句柄再加一个按优先级分桶的发送队列。channel_idle_since这个变量值得单独说。它记录的是“信道最近一次由忙转闲的时刻”后面算 DIFS 时不是去排一个 50 微秒的定时器而是拿当前时间减它判断差值够不够。这一个设计把 IFS 判断从“每个帧排一个事件”变成“一次减法”事件数直接降一个数量级——仿真跑得慢的人八成问题都出在类似的地方。3. 退避不是随机数DIFS、时隙和计数器的代码级拆解3.1 为什么退避计数器只在信道空闲时递减这是 CSMA/CA 和以太网 CSMA/CD 最本质的差别。以太网是撞了再退避Wi-Fi 是先排队再竞争节点在 DIFS 之后从[0, CW]里抽一个数每过一个空闲时隙减一减到零才发。信道一忙就冻结计数器等信道重新空闲并再等够 DIFS 才继续往下数。冻结机制解决的是一类活锁如果退避只在碰撞后重抽两个节点很容易反复抽到接近的数然后反复撞。冻结让退避计数变成一个分布式排队号——先来的计数小先发后来的计数大自动让路不需要任何中心协调。/* 自中断一个时隙过去了。只有信道在这段时间内全程空闲计数器才减一 */ case WlanC_SLOT_INTRPT: if (channel_busy () || op_sim_time () nav_end_time) { /* 冻结计数不变。下面这句是简化写法代价见 5.3 */ op_intrpt_schedule_self (op_sim_time () slot_time, WlanC_SLOT_INTRPT); break; } if (backoff_slots 0) { backoff_slots--; op_stat_write (backoff_stat, (double) backoff_slots); /* 退避深度统计 */ op_intrpt_schedule_self (op_sim_time () slot_time, WlanC_SLOT_INTRPT); } else { mac_state WlanC_MAC_STATE_XMT; /* 数到 0直接发不再等 DIFS */ } break;slot_time是物理层相关常量DSSS 是 20 微秒OFDM 是 9 微秒。channel_busy()的判断要同时看物理载波侦听和 NAV只看其中一个就是典型的错模型——只看物理层会低估隐藏终端的影响只看 NAV 会漏掉那些短到没来得及解出 Duration 的帧。op_stat_write那行不是可选项退避深度的分布是判断模型对不对最直接的证据没有它就只能靠吞吐量一个数字猜。3.2 竞争窗口翻倍与重试计数CW 的边界在哪发送失败之后竞争窗口翻倍。这里有个容易写错的地方CW 的语义是“取值范围的上界”标准里的序列是 31、63、127、255、511、1023也就是 2^n - 1不是 32、64、128。所以在代码里应该写(cw 1) 1而不是cw * 2。/* 超时未收到 ACK/CTS窗口翻倍重试到上限就丢帧 */ if (short_retry_cnt short_retry_limit || long_retry_cnt long_retry_limit) { op_pk_destroy (current_frame); /* 丢帧向 上层 上报失败 */ cw cw_min; /* 关键重置下一帧从最小窗口重来 */ short_retry_cnt 0; long_retry_cnt 0; mac_state WlanC_MAC_STATE_IDLE; } else { cw (cw 1) 1; /* 31 - 63 - 127 ... 严格连续 */ if (cw cw_max) cw cw_max; /* 封顶 1023不会无限涨 */ backoff_slots (int) op_dist_outcome (uniform_dist (0, cw)); mac_state WlanC_MAC_STATE_BACKOFF; }为什么是两套重试计数短帧不超过 RTS 阈值用短重试上限一般 7 次超过阈值的长帧必须走 RTS/CTS用长重试上限一般 4 次。逻辑是代价不对称——一个 20 字节的 RTS 撞了再试很便宜一个 1500 字节的数据帧反复重传则会把信道占满早点放弃、让上层重来更划算。参数对照表读源码时对着看比较省事参数DSSS11bOFDM11a/g在代码里影响什么SlotTime20 μs9 μs退避自中断的间隔直接决定仿真事件数SIFS10 μs16 μs数据帧和 ACK 之间的间隔DIFS50 μs34 μs退避启动前的强制空闲CWmin3115初始退避的抽取上界CWmax10231023翻倍封顶值ACK TimeoutSIFS SlotTimeSIFS SlotTime等不到 ACK 就判失败的时刻3.3 时隙边界与时间精度为什么你的 DIFS 差了一个数量级OPNET 的属性是有单位的而单位在图形界面里常常不显示。SIFS 写成16如果属性单位是微秒就对了如果单位是秒那就是 16 秒——仿真里所有节点都像被冻住一样吞吐量趋近于零但因为没有报错很容易被误解成“协议实现有问题”。我一般会这么理解这件事凡是带物理单位的属性在 INIT 状态里读出来之后立刻打一条调试输出把值和量纲一起确认。op_ima_obj_attr_get读回来的是纯数值量纲信息在属性定义里代码看不见。IFS 的实现方式也值得说。前面提过用op_sim_time() - channel_idle_since difs这种比较代替定时器但有个前提channel_idle_since必须在信道每一次由忙转闲时被准确更新。如果只在收到帧时更新那么两个帧之间的空闲期就被漏算了DIFS 会被反复重新计时退避永远启动不了仿真表现为“节点永远在 DEFER 状态吞吐量为零”——这是排查时最该先看的一个中间量。4. RTS/CTS 与 NAV虚拟载波侦听要付出什么代价4.1 Duration 字段一个整数如何让所有邻居闭嘴物理载波侦听只能听见“现在有信号”听不见“这信号还要持续多久”。NAV 就是给后者补的每个帧的 MAC 头里有一个 Duration 字段声明“这轮交互还要占多久”听到的人不管这帧是不是发给自己的都把自己的 NAV 推到那个时刻。/* 收到任何一帧先解析头部拿 Duration哪怕目的地址不是我 */ op_pk_nfd_get (pk, MAC_Header, hdr); duration hdr.duration; /* 微秒 */ if (hdr.addr1 ! my_addr) { if (op_sim_time () duration nav_end_time) { nav_end_time op_sim_time () duration; /* NAV 是从忙转闲的边界必须排一个事件把自己唤醒 */ op_intrpt_schedule_self (nav_end_time, WlanC_NAV_EXPIRE); } }op_pk_nfd_get取的是包格式里的具名字段MAC_Header是一个复合字段展开后是帧控制、Duration、地址 1 到 4、序列控制这些。nav_end_time用绝对时刻而不是剩余时长因为绝对时刻做比较不用每来一个事件就减一次而且自中断里可以直接比op_sim_time() nav_end_time。这里有个前提容易被忽略MAC 必须能收到并解析目的地址不是自己的帧。如果接收逻辑里写了“不是给我的就丢”NAV 永远是零虚拟载波侦听等于没实现隐藏终端场景会显得比实际更糟——不是模型夸大是模型缺了一半。4.2 握手失败的三种死法超时、EIFS、以及退避没重置第一种是 ACK 超时。数据帧发出去等到SIFS SlotTime还没收到 ACK判定失败进重传流程CW 翻倍。这条路径最常见也最好排查——把重传计数打成统计量突增就说明链路质量或者干扰有问题。第二种是 EIFS。收到一个 FCS 校验失败的帧时MAC 解不出 Duration不知道对方什么时候发完只能按最保守的方式等SIFS DIFS ACK 最低速率发送时间。很多实现里 EIFS 是硬编码的常量改物理层参数时忘了改它就会出现“换个数据率吞吐量掉得莫名其妙”的情况。去源码里搜eifs看它是在 INIT 里算出来的还是写死的两分钟能定位。第三种最隐蔽超时之后重抽了退避但忘了把channel_idle_since一起重置。结果是新一轮退避在错误的空闲起点上启动DIFS 被少算或者多算表现在统计曲线上是重传数和退避深度的相关性完全不对——正常应该正相关错了会看到两者互相独立。4.3 隐藏终端在仿真里是“造”出来的不是“跑”出来的隐藏终端的定义是A 和 C 都能和 B 通信但 A 和 C 互相听不见。这在真实环境里靠距离和遮挡自然形成在仿真里必须显式构造——设发射功率、设接收门限、设距离让载波侦听范围和通信范围不重合。具体做法是把接收门限调到比最小可解码功率还低这样能听见别人在发同时把发射功率调到只够覆盖目标距离这样 A 和 C 互相低于门限。这两个参数一个是物理层属性一个是无线接收机属性不同版本里名字不一样但一定都在节点模型的无线模块上。构造成功后的现象很好认开启 RTS/CTS 之后吞吐量上升关掉之后碰撞率飙升。如果开关 RTS 对结果毫无影响说明隐藏终端根本没造出来——大概率是三个节点互相都能听见或者干扰范围设成了零。RTS/CTS 的价值只在有隐藏终端时才为正在全可见的网络里它是纯粹的开销这一点在源码里体现为“RTS 阈值”那一个判断分支改一下阈值就能观察到拐点。5. 避坑与排查仿真结果对不上先看这五个地方5.1 量纲最常见的“差了一千倍”现象吞吐量比理论值低三个数量级或者仿真时间几乎不推进。原因时间类属性以秒为单位但代码里按微秒填了。SIFS 填 16实际是 16 秒DIFS 填 50实际是 50 秒。整个网络在一帧上耗掉几十秒后面的所有统计都没意义。解决在 INIT 状态里把所有时间常量读出来统一换算并打印一遍确认。凡是源码里出现* 1.0e-6的地方都去核对一遍对应的属性单位别靠猜。5.2 随机种子所有节点一起退避到 0现象碰撞率异常高而且碰撞都发生在仿真开始的第一个帧。原因每个节点的退避分布用的是同一套随机数。OPNET 的分布对象如果没单独设种子相同参数会产生相同的抽样序列于是所有节点在同一时刻抽到同一个退避值同步碰撞。解决给每个节点的分布对象单独设置种子种子取节点 ID 或者对象 ID 派生出来的值避免手工写死一串数字。验证方法很直接把每个节点的第一次退避值打成统计量如果全都一样就是这个问题。5.3 事件风暴仿真跑一晚上还没结束现象仿真进度条几乎不动事件计数器在涨但仿真时间只走了一点点。原因退避期间每个时隙都排一次自中断而 802.11 的时隙是 9 微秒一个节点一秒就排十万个事件。如果信道一直忙这些中断全是无用功——醒了发现还是忙再睡一个时隙。解决信道忙的时候不要排时隙中断改成只在信道由忙转闲时排一次从那里开始数。这一改动通常能把事件数降一个量级仿真时间跟着降。另一条是同类的op_stat_write如果每收到一个包就写一次向量统计输出文件会膨胀到几个 G改成标量统计或者只在关键状态迁移时写。5.4 拓扑隐藏终端造不出来现象开了 RTS/CTS 吞吐量反而下降关掉之后碰撞率也没升高。原因节点之间互相都能听见隐藏终端不存在。RTS/CTS 退化成纯开销四路握手多花两个 SIFS 加两个控制帧的时间吞吐量当然掉。解决先把发射功率降下来让通信半径缩小到拓扑里最长链路的长度再把接收门限调低让载波侦听半径大于通信半径。两个半径的比值决定了隐藏终端的严重程度一般调到 1.5 到 2 倍之间比较有代表性。5.5 优先级EDCA 的映射没生效现象配了四个接入类别、配了不同的 AIFS 和 CWmin但高优先级业务和低优先级业务的时延曲线几乎重合。原因上层递交的 ICI 里优先级字段没有被正确读取或者读到了但入队时全落进了同一个桶。也可能是映射表里把 802.1p 的优先级映射成了同一个用户优先级源头就错了。解决在入队函数里加一条统计按接入类别计数跑一小段看四个桶是不是都有值。如果只有一个桶有值问题在映射如果四个桶均匀但时延不分化问题在退避参数没被真正用到抽样的那一步。排查完这些最后一步是拿标量输出快速扫一眼分布别只盯着平均值import re rows [] for line in open(wlan_dcf.scalar, encodingutf-8): m re.match(r^scalar\s\S\s(\S)\sthroughput\s([\d.eE-]), line) if m: rows.append((m.group(1), float(m.group(2)))) rows.sort(keylambda r: -r[1]) total sum(tp for _, tp in rows) for node, tp in rows: print(f{node:24s}{tp:10.3f} kbps {tp / total * 100:5.1f}%) print(ffairness index: {total ** 2 / (len(rows) * sum(tp ** 2 for _, tp in rows)):.4f})这段脚本的作用不是算精确吞吐量而是看分布所有节点占比接近说明竞争是公平的退避在正常工作某一个节点吃掉八成带宽要么是它的退避参数不对要么是位置太好一直抢到信道。最后那个公平性指数在 0 到 1 之间DCF 的典型值应该在 0.95 以上低于这个数就值得往下查。6. 设计取舍把这套源码当参照物而不是当标准答案读到这儿会发现802.11 的 MAC 在仿真里被压成了三样东西一个状态机、一组跨中断保留的状态变量、一个事件队列。所有看起来复杂的机制——退避冻结、CW 翻倍、NAV、EIFS、分片——都是这三样的组合。这套结构最大的取舍是“单进程状态机”而不是分层对象。理论上 MAC 可以拆成信道评估、退避管理、帧交换、分片重组四个模块各自维护状态但拆分之后一次信道由忙转闲要穿过四个模块每个模块都得知道其他模块的状态反而更难保证一致性。压成一个进程加一组状态变量代价是这个进程会变得很长好处是所有决策点都在同一个 switch 里调试时打断点就能看到完整上下文。第二个取舍是时间精度。仿真里所有时间都是浮点秒而 802.11 的最小时间单位是微秒级两者之间必然有舍入。把op_sim_time()直接拿去和SIFS SlotTime做浮点比较在某些边界上会判错。稳妥的做法是给所有时间比较留一个极小容差或者把关键时间量统一换算成整数微秒再比较——这不是洁癖是那种“一千次里错一次、但错了完全查不出来”的问题。第三个取舍在抽象层次PLCP 前导、物理层汇聚过程、误码率曲线这套模型都有建模但精度取决于 pipeline 里配了什么。如果只关心 MAC 层的竞争行为把误码率固定成零反而更干净如果要看速率自适应就必须让误码率随信噪比变化。这两件事不能同时做源码里的抽象层次已经替你选好了边界读的时候先看清边界在哪再判断结论能推到多远。验证的方法其实不复杂拿经典的二维马尔可夫链饱和吞吐量结果做对照把负载加到饱和看仿真曲线在 CWmin、CWmax 变化时的趋势是否一致再关掉隐藏终端、关掉重传上限看模型是否退化到理论上界。两次都对得上才说明你读懂了这套源码里的每一行判断在做什么。从那以后我每次拿到一份 MAC 层的仿真结果都会强制先跑一遍退避深度和重传次数的分布确认它们符合预期再去看吞吐量这个最终数字——因为吞吐量对了但中间量不对多半是两处错误互相抵消换一个场景就会翻车。这套源代码里的状态机骨架、ICI 字段定义和退避实现比任何时序图都直接值得对着自己手上的模型读一遍。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 11:21:23 · 阅读 1.2k OPNET 802.11 MAC源码解析：CSMA/CA状态机与退避仿真
简介面向无线网络研究与OPNET仿真学习者的802.11-MAC协议源代码包适合需要理解WLAN信道接入机制、开展协议建模与性能分析的高校学生和开发人员。压缩包共356个文件、约1.31MB以OPNET模型文件ov、os、C语言源码c、编译中间文件obj、lib、dll及实验配置与日志文件为主保留了较完整的工程结构便于在OPNET中加载、阅读和二次调试。已有876人学习说明其在相关课程与科研中具有一定参考价值。通过梳理代码可具体观察帧结构定义、CSMA/CA载波侦听与退避流程、DCF分布式协调功能的实现方式并据此复现仿真、对比不同场景下的MAC性能为无线网络课程实验、协议改进和网络设计提供可操作的代码依据。1. 802.11 的吞吐量算不准是因为竞争本身就带随机性拿 opnet 跑 802.11 的 MAC多数人第一件事是把仿真出来的吞吐量和手算值对一下然后发现对不上而且差得不是一点半点。这份 opnet 802.11 MAC 协议的源代码价值恰恰在这里它把“为什么对不上”摊开成了一个个状态和变量。分布式协调靠的是每个节点各自数退避、各自听信道碰撞是概率事件重传次数是随机变量隐藏终端把“能不能听见”变成拓扑问题。教科书上那套饱和吞吐量公式前提是无限负载、无限重传、所有节点互相能听见一旦落到有限负载、多速率和部分可见的信道里公式就失效。想搞清慢在哪一段——是退避等太久、是 ACK 超时太频繁、还是重传把窗口顶到了上限——只能读 MAC 的源代码看状态机究竟在哪一步停下来等。2. CSMA/CA 的状态机为什么 MAC 逻辑必须写成有限状态机2.1 一帧从上层到空口ICI 是唯一的“信封”上层协议栈递给 MAC 的是一个 packet 对象但“怎么发”这件事——用哪个数据率、发到哪个信道、优先级多高、目的地址是谁——并不能塞进包里。包是载荷的容器它会被排队、被分片、被重传、被销毁重造“怎么发”这组信息只在跨层那一瞬间有效。把两者混在一起重传时就得把已经改过的字段再改回去是很典型的踩坑来源。OPNET 的做法是引入 ICIInterface Control Information一个独立于包的属性集合随包走一段就被销毁。常见的写法是上层创建 ICI、填属性、挂在包上MAC 取包的同时取 ICI把有用字段搬进自己的队列结构然后立刻销毁 ICI。/* 流中断上层递交一帧。包只管载荷怎么发全在 ICI 里 */ pk op_pk_get (op_intrpt_strm ()); /* 取出包 */ ici op_pk_ici_get (pk); /* 取出随包过来的接口控制信息 */ op_ici_attr_get (ici, dest_address, dest_addr); op_ici_attr_get (ici, data_rate, data_rate); op_ici_attr_get (ici, priority, priority); /* 入队。注意不是简单 FIFO后面 5.5 会讲优先级映射为什么常常失效 */ wlan_mac_queue_insert (pk, priority, dest_addr); op_ici_destroy (ici); /* 信息已落到 MAC 自己的数据结构 */op_pk_ici_get拿到的是挂在这个包上的 ICI 句柄属性名按当前模型的 ICI 格式定义不同版本里字段名会有出入但“目的地址、数据率、优先级、信道号”这四类基本跑不掉。关键是op_ici_destroy这一句不能省ICI 不是包的一部分不销毁就会一路泄漏到仿真结束跑长仿真时内存曲线会很难看。2.2 状态迁移不是 if-else 堆出来的中断类型和中断码决定一切离散事件仿真里没有“阻塞等待”这回事。任何“等 50 微秒”“等 ACK 回来”都必须翻译成“请在未来的某个时刻给我投递一个事件”否则进程就永远醒不过来。这就是 MAC 必须写成状态机的根本原因——不是风格问题是内核约束。OPNET 的进程模型把这件事抽象成状态加中断。事件进来时先判op_intrpt_type()再判op_intrpt_code()两者合起来唯一确定“发生了什么”中断类型来源中断码通常是典型处理OPC_INTRPT_STRM上层协议 / 无线接收机流号收帧、入队、更新 NAVOPC_INTRPT_SELF自己排的定时器自定义码退避时隙、ACK 超时、NAV 归零OPC_INTRPT_BEGSIM内核无读属性、注册统计量、初始化OPC_INTRPT_ENDSIM内核无冲刷统计量、释放队列/* 状态机主干所有事件先分流再落到具体状态里处理 */ switch (op_intrpt_type ()) { case OPC_INTRPT_STRM: /* 同一个流号既可能是上层递交也可能是接收机上报靠 code 区分 */ if (op_intrpt_code () WlanC_FROM_UPPER) { mac_state wlan_mac_frame_arrival (); } else { mac_state wlan_mac_frame_reception (); } break; case OPC_INTRPT_SELF: switch (op_intrpt_code ()) { case WlanC_SLOT_INTRPT: mac_state wlan_mac_backoff_tick (); break; case WlanC_ACK_TIMEOUT: mac_state wlan_mac_retry (); break; case WlanC_NAV_EXPIRE: mac_state wlan_mac_channel_idle ();break; } break; }wlan_mac_frame_arrival()这类函数返回的是“下一个状态”而不是在里面直接跳转。这么做的好处是状态迁移集中在一处改协议扩展比如加上 EDCA 的四条接入类别时只需要动返回值和分支不用在几十个函数里找goto。血泪经验是一旦有人在 executive 里直接改mac_state又忘了返回值状态机就会出现“看起来进了 BACKOFF 其实还在 DEFER”的幽灵状态仿真结果全错但一条报错都没有。2.3 状态变量块谁记住了退避计数器和 NAV进程的局部变量在 executive 返回时就没了而 MAC 需要跨中断记住的东西非常多当前退避还剩几个时隙、竞争窗口现在多大、已经重试了几次、NAV 什么时候归零、手上这一帧是不是分片。这些必须放进状态变量块由内核在进程整个生命周期内保留。常见的状态变量大致是这几类mac_state当前状态、backoff_slots剩余退避时隙、cw当前竞争窗口上界、short_retry_cnt/long_retry_cnt两套重试计数、nav_end_timeNAV 到期时刻、channel_idle_since信道连续空闲的起点、current_frame正在发或正在等的那个包句柄再加一个按优先级分桶的发送队列。channel_idle_since这个变量值得单独说。它记录的是“信道最近一次由忙转闲的时刻”后面算 DIFS 时不是去排一个 50 微秒的定时器而是拿当前时间减它判断差值够不够。这一个设计把 IFS 判断从“每个帧排一个事件”变成“一次减法”事件数直接降一个数量级——仿真跑得慢的人八成问题都出在类似的地方。3. 退避不是随机数DIFS、时隙和计数器的代码级拆解3.1 为什么退避计数器只在信道空闲时递减这是 CSMA/CA 和以太网 CSMA/CD 最本质的差别。以太网是撞了再退避Wi-Fi 是先排队再竞争节点在 DIFS 之后从[0, CW]里抽一个数每过一个空闲时隙减一减到零才发。信道一忙就冻结计数器等信道重新空闲并再等够 DIFS 才继续往下数。冻结机制解决的是一类活锁如果退避只在碰撞后重抽两个节点很容易反复抽到接近的数然后反复撞。冻结让退避计数变成一个分布式排队号——先来的计数小先发后来的计数大自动让路不需要任何中心协调。/* 自中断一个时隙过去了。只有信道在这段时间内全程空闲计数器才减一 */ case WlanC_SLOT_INTRPT: if (channel_busy () || op_sim_time () nav_end_time) { /* 冻结计数不变。下面这句是简化写法代价见 5.3 */ op_intrpt_schedule_self (op_sim_time () slot_time, WlanC_SLOT_INTRPT); break; } if (backoff_slots 0) { backoff_slots--; op_stat_write (backoff_stat, (double) backoff_slots); /* 退避深度统计 */ op_intrpt_schedule_self (op_sim_time () slot_time, WlanC_SLOT_INTRPT); } else { mac_state WlanC_MAC_STATE_XMT; /* 数到 0直接发不再等 DIFS */ } break;slot_time是物理层相关常量DSSS 是 20 微秒OFDM 是 9 微秒。channel_busy()的判断要同时看物理载波侦听和 NAV只看其中一个就是典型的错模型——只看物理层会低估隐藏终端的影响只看 NAV 会漏掉那些短到没来得及解出 Duration 的帧。op_stat_write那行不是可选项退避深度的分布是判断模型对不对最直接的证据没有它就只能靠吞吐量一个数字猜。3.2 竞争窗口翻倍与重试计数CW 的边界在哪发送失败之后竞争窗口翻倍。这里有个容易写错的地方CW 的语义是“取值范围的上界”标准里的序列是 31、63、127、255、511、1023也就是 2^n - 1不是 32、64、128。所以在代码里应该写(cw 1) 1而不是cw * 2。/* 超时未收到 ACK/CTS窗口翻倍重试到上限就丢帧 */ if (short_retry_cnt short_retry_limit || long_retry_cnt long_retry_limit) { op_pk_destroy (current_frame); /* 丢帧向 上层 上报失败 */ cw cw_min; /* 关键重置下一帧从最小窗口重来 */ short_retry_cnt 0; long_retry_cnt 0; mac_state WlanC_MAC_STATE_IDLE; } else { cw (cw 1) 1; /* 31 - 63 - 127 ... 严格连续 */ if (cw cw_max) cw cw_max; /* 封顶 1023不会无限涨 */ backoff_slots (int) op_dist_outcome (uniform_dist (0, cw)); mac_state WlanC_MAC_STATE_BACKOFF; }为什么是两套重试计数短帧不超过 RTS 阈值用短重试上限一般 7 次超过阈值的长帧必须走 RTS/CTS用长重试上限一般 4 次。逻辑是代价不对称——一个 20 字节的 RTS 撞了再试很便宜一个 1500 字节的数据帧反复重传则会把信道占满早点放弃、让上层重来更划算。参数对照表读源码时对着看比较省事参数DSSS11bOFDM11a/g在代码里影响什么SlotTime20 μs9 μs退避自中断的间隔直接决定仿真事件数SIFS10 μs16 μs数据帧和 ACK 之间的间隔DIFS50 μs34 μs退避启动前的强制空闲CWmin3115初始退避的抽取上界CWmax10231023翻倍封顶值ACK TimeoutSIFS SlotTimeSIFS SlotTime等不到 ACK 就判失败的时刻3.3 时隙边界与时间精度为什么你的 DIFS 差了一个数量级OPNET 的属性是有单位的而单位在图形界面里常常不显示。SIFS 写成16如果属性单位是微秒就对了如果单位是秒那就是 16 秒——仿真里所有节点都像被冻住一样吞吐量趋近于零但因为没有报错很容易被误解成“协议实现有问题”。我一般会这么理解这件事凡是带物理单位的属性在 INIT 状态里读出来之后立刻打一条调试输出把值和量纲一起确认。op_ima_obj_attr_get读回来的是纯数值量纲信息在属性定义里代码看不见。IFS 的实现方式也值得说。前面提过用op_sim_time() - channel_idle_since difs这种比较代替定时器但有个前提channel_idle_since必须在信道每一次由忙转闲时被准确更新。如果只在收到帧时更新那么两个帧之间的空闲期就被漏算了DIFS 会被反复重新计时退避永远启动不了仿真表现为“节点永远在 DEFER 状态吞吐量为零”——这是排查时最该先看的一个中间量。4. RTS/CTS 与 NAV虚拟载波侦听要付出什么代价4.1 Duration 字段一个整数如何让所有邻居闭嘴物理载波侦听只能听见“现在有信号”听不见“这信号还要持续多久”。NAV 就是给后者补的每个帧的 MAC 头里有一个 Duration 字段声明“这轮交互还要占多久”听到的人不管这帧是不是发给自己的都把自己的 NAV 推到那个时刻。/* 收到任何一帧先解析头部拿 Duration哪怕目的地址不是我 */ op_pk_nfd_get (pk, MAC_Header, hdr); duration hdr.duration; /* 微秒 */ if (hdr.addr1 ! my_addr) { if (op_sim_time () duration nav_end_time) { nav_end_time op_sim_time () duration; /* NAV 是从忙转闲的边界必须排一个事件把自己唤醒 */ op_intrpt_schedule_self (nav_end_time, WlanC_NAV_EXPIRE); } }op_pk_nfd_get取的是包格式里的具名字段MAC_Header是一个复合字段展开后是帧控制、Duration、地址 1 到 4、序列控制这些。nav_end_time用绝对时刻而不是剩余时长因为绝对时刻做比较不用每来一个事件就减一次而且自中断里可以直接比op_sim_time() nav_end_time。这里有个前提容易被忽略MAC 必须能收到并解析目的地址不是自己的帧。如果接收逻辑里写了“不是给我的就丢”NAV 永远是零虚拟载波侦听等于没实现隐藏终端场景会显得比实际更糟——不是模型夸大是模型缺了一半。4.2 握手失败的三种死法超时、EIFS、以及退避没重置第一种是 ACK 超时。数据帧发出去等到SIFS SlotTime还没收到 ACK判定失败进重传流程CW 翻倍。这条路径最常见也最好排查——把重传计数打成统计量突增就说明链路质量或者干扰有问题。第二种是 EIFS。收到一个 FCS 校验失败的帧时MAC 解不出 Duration不知道对方什么时候发完只能按最保守的方式等SIFS DIFS ACK 最低速率发送时间。很多实现里 EIFS 是硬编码的常量改物理层参数时忘了改它就会出现“换个数据率吞吐量掉得莫名其妙”的情况。去源码里搜eifs看它是在 INIT 里算出来的还是写死的两分钟能定位。第三种最隐蔽超时之后重抽了退避但忘了把channel_idle_since一起重置。结果是新一轮退避在错误的空闲起点上启动DIFS 被少算或者多算表现在统计曲线上是重传数和退避深度的相关性完全不对——正常应该正相关错了会看到两者互相独立。4.3 隐藏终端在仿真里是“造”出来的不是“跑”出来的隐藏终端的定义是A 和 C 都能和 B 通信但 A 和 C 互相听不见。这在真实环境里靠距离和遮挡自然形成在仿真里必须显式构造——设发射功率、设接收门限、设距离让载波侦听范围和通信范围不重合。具体做法是把接收门限调到比最小可解码功率还低这样能听见别人在发同时把发射功率调到只够覆盖目标距离这样 A 和 C 互相低于门限。这两个参数一个是物理层属性一个是无线接收机属性不同版本里名字不一样但一定都在节点模型的无线模块上。构造成功后的现象很好认开启 RTS/CTS 之后吞吐量上升关掉之后碰撞率飙升。如果开关 RTS 对结果毫无影响说明隐藏终端根本没造出来——大概率是三个节点互相都能听见或者干扰范围设成了零。RTS/CTS 的价值只在有隐藏终端时才为正在全可见的网络里它是纯粹的开销这一点在源码里体现为“RTS 阈值”那一个判断分支改一下阈值就能观察到拐点。5. 避坑与排查仿真结果对不上先看这五个地方5.1 量纲最常见的“差了一千倍”现象吞吐量比理论值低三个数量级或者仿真时间几乎不推进。原因时间类属性以秒为单位但代码里按微秒填了。SIFS 填 16实际是 16 秒DIFS 填 50实际是 50 秒。整个网络在一帧上耗掉几十秒后面的所有统计都没意义。解决在 INIT 状态里把所有时间常量读出来统一换算并打印一遍确认。凡是源码里出现* 1.0e-6的地方都去核对一遍对应的属性单位别靠猜。5.2 随机种子所有节点一起退避到 0现象碰撞率异常高而且碰撞都发生在仿真开始的第一个帧。原因每个节点的退避分布用的是同一套随机数。OPNET 的分布对象如果没单独设种子相同参数会产生相同的抽样序列于是所有节点在同一时刻抽到同一个退避值同步碰撞。解决给每个节点的分布对象单独设置种子种子取节点 ID 或者对象 ID 派生出来的值避免手工写死一串数字。验证方法很直接把每个节点的第一次退避值打成统计量如果全都一样就是这个问题。5.3 事件风暴仿真跑一晚上还没结束现象仿真进度条几乎不动事件计数器在涨但仿真时间只走了一点点。原因退避期间每个时隙都排一次自中断而 802.11 的时隙是 9 微秒一个节点一秒就排十万个事件。如果信道一直忙这些中断全是无用功——醒了发现还是忙再睡一个时隙。解决信道忙的时候不要排时隙中断改成只在信道由忙转闲时排一次从那里开始数。这一改动通常能把事件数降一个量级仿真时间跟着降。另一条是同类的op_stat_write如果每收到一个包就写一次向量统计输出文件会膨胀到几个 G改成标量统计或者只在关键状态迁移时写。5.4 拓扑隐藏终端造不出来现象开了 RTS/CTS 吞吐量反而下降关掉之后碰撞率也没升高。原因节点之间互相都能听见隐藏终端不存在。RTS/CTS 退化成纯开销四路握手多花两个 SIFS 加两个控制帧的时间吞吐量当然掉。解决先把发射功率降下来让通信半径缩小到拓扑里最长链路的长度再把接收门限调低让载波侦听半径大于通信半径。两个半径的比值决定了隐藏终端的严重程度一般调到 1.5 到 2 倍之间比较有代表性。5.5 优先级EDCA 的映射没生效现象配了四个接入类别、配了不同的 AIFS 和 CWmin但高优先级业务和低优先级业务的时延曲线几乎重合。原因上层递交的 ICI 里优先级字段没有被正确读取或者读到了但入队时全落进了同一个桶。也可能是映射表里把 802.1p 的优先级映射成了同一个用户优先级源头就错了。解决在入队函数里加一条统计按接入类别计数跑一小段看四个桶是不是都有值。如果只有一个桶有值问题在映射如果四个桶均匀但时延不分化问题在退避参数没被真正用到抽样的那一步。排查完这些最后一步是拿标量输出快速扫一眼分布别只盯着平均值import re rows [] for line in open(wlan_dcf.scalar, encodingutf-8): m re.match(r^scalar\s\S\s(\S)\sthroughput\s([\d.eE-]), line) if m: rows.append((m.group(1), float(m.group(2)))) rows.sort(keylambda r: -r[1]) total sum(tp for _, tp in rows) for node, tp in rows: print(f{node:24s}{tp:10.3f} kbps {tp / total * 100:5.1f}%) print(ffairness index: {total ** 2 / (len(rows) * sum(tp ** 2 for _, tp in rows)):.4f})这段脚本的作用不是算精确吞吐量而是看分布所有节点占比接近说明竞争是公平的退避在正常工作某一个节点吃掉八成带宽要么是它的退避参数不对要么是位置太好一直抢到信道。最后那个公平性指数在 0 到 1 之间DCF 的典型值应该在 0.95 以上低于这个数就值得往下查。6. 设计取舍把这套源码当参照物而不是当标准答案读到这儿会发现802.11 的 MAC 在仿真里被压成了三样东西一个状态机、一组跨中断保留的状态变量、一个事件队列。所有看起来复杂的机制——退避冻结、CW 翻倍、NAV、EIFS、分片——都是这三样的组合。这套结构最大的取舍是“单进程状态机”而不是分层对象。理论上 MAC 可以拆成信道评估、退避管理、帧交换、分片重组四个模块各自维护状态但拆分之后一次信道由忙转闲要穿过四个模块每个模块都得知道其他模块的状态反而更难保证一致性。压成一个进程加一组状态变量代价是这个进程会变得很长好处是所有决策点都在同一个 switch 里调试时打断点就能看到完整上下文。第二个取舍是时间精度。仿真里所有时间都是浮点秒而 802.11 的最小时间单位是微秒级两者之间必然有舍入。把op_sim_time()直接拿去和SIFS SlotTime做浮点比较在某些边界上会判错。稳妥的做法是给所有时间比较留一个极小容差或者把关键时间量统一换算成整数微秒再比较——这不是洁癖是那种“一千次里错一次、但错了完全查不出来”的问题。第三个取舍在抽象层次PLCP 前导、物理层汇聚过程、误码率曲线这套模型都有建模但精度取决于 pipeline 里配了什么。如果只关心 MAC 层的竞争行为把误码率固定成零反而更干净如果要看速率自适应就必须让误码率随信噪比变化。这两件事不能同时做源码里的抽象层次已经替你选好了边界读的时候先看清边界在哪再判断结论能推到多远。验证的方法其实不复杂拿经典的二维马尔可夫链饱和吞吐量结果做对照把负载加到饱和看仿真曲线在 CWmin、CWmax 变化时的趋势是否一致再关掉隐藏终端、关掉重传上限看模型是否退化到理论上界。两次都对得上才说明你读懂了这套源码里的每一行判断在做什么。从那以后我每次拿到一份 MAC 层的仿真结果都会强制先跑一遍退避深度和重传次数的分布确认它们符合预期再去看吞吐量这个最终数字——因为吞吐量对了但中间量不对多半是两处错误互相抵消换一个场景就会翻车。这套源代码里的状态机骨架、ICI 字段定义和退避实现比任何时序图都直接值得对着自己手上的模型读一遍。希望帮到你。本文还有配套的精品资源点击获取