简介：针对Wi-Fi网络中CSMA/CA机制，这份MATLAB代码包能直观模拟802.11 DCF下的信道访问与冲突避免流程，适用于协议学习、实验教学与仿真验证。资源共20个文件，以19个.m脚本为主，另附1个txt说明文档，压缩包整体仅22KB，结构紧凑。脚本按功能划分为主程序、辅助函数与图形显示模块，采用事件驱动模拟，可重现载波监听、多路访问、随机退避、RTS/CTS握手及ACK确认等关键环节，并通过图形化输出观察节点发送过程；随附的文本说明文档逐文件解析代码逻辑，适合无线通信初学者对照学习，也可为研究者提供参数修改与结果分析的实验基础。通过调整节点数量、业务负载等参数，还能观察不同场景下的信道利用率和冲突情况，加深对DCF机制的理解；该资源已有459人学习浏览，是快速上手CSMA/CA仿真的一份轻量实用参考。
1. 为什么我建议先把 802.11 DCF 的 CSMA/CA 放进 MATLAB 里跑一遍
CSMA/CA 是 Wi-Fi 协议栈里最容易被高估的模块。802.11 DCF 的分布式协调功能，上过课的人基本都能背出“先听后发、随机退避”，但一旦落到代码，DIFS 从哪个时刻开始计时、退避计数器到底在哪些时隙递减、信道一忙要不要冻结，每一步都有坑。标题里的“802.11dcf”其实不是什么新版本，就是 802.11 DCF（分布式协调功能），是 CSMA/CA 的基础。这套 MATLAB 仿真包把 DCF 拆成了可以单步观察的函数：SetBackoffTime 管理退避取值，GetFreeze 管理冻结，FramePush/FramePop 管理帧队列，还额外附了 CSMA/CD 版本做有线对比。它适合两类人：一类是准备通信或网络方向考核，想把 DCF 时序从文字记忆变成直观画面的人；另一类是做无线网络仿真，想拿一套可改参数的基线模型快速做方案对比的工程师。下面按我的拆解顺序来讲。
2. 把协议机制和 .m 文件对应起来：先看懂 DIFS、SIFS 和退避，再开跑
2.1 载波监听、冲突避免与 DIFS/SIFS：三个最基本的判断
802.11 DCF 下的所有站点是平等竞争的，没有中心节点分配信道。每个站点在发送前先监听信道，这叫做载波监听。但“信道空闲就立刻发”是新手最容易犯的理解错误。DCF 要求站点在发现信道空闲后，必须再等一个 DIFS（分布式帧间间隔），而且在等待期间信道要一直空闲，才算拿到发送资格。拿到资格之后还不能马上发，而是要从 [0, CW] 里随机取一个整数作为退避时隙数，每个空闲时隙退避值减 1，减到 0 才真正发送。这样做的目的是让多个等待站点以不同速率倒计时，避免它们同时看到信道空闲然后同时发。
DIFS 和 SIFS 的区别在仿真里特别关键。SIFS 用于 ACK、CTS 这类短控制帧，数值最小，能让确认帧在数据帧结束后最快抢到信道；DIFS 用于数据帧前的等待，数值更大，保证 ACK 这类短帧有更高的信道接入优先级。在 802.11g 下，典型参数是：Slot Time 9us，SIFS 10us，DIFS = SIFS + 2 × Slot = 28us。如果代码里把 DIFS 直接设成 SIFS 的两倍，时序就错了，最终吞吐量曲线会明显异常。
另外还有 RTS/CTS 可选机制，解决的是隐藏终端问题：A 给 B 发数据前先发 RTS，B 回 CTS，其他监听到 CTS 的站点会设置 NAV 网络分配向量，在一段时间内认为自己看到的“空闲”其实是虚拟占用。这套包里的 GetFreeze 函数，名称上就决定了它不只要看物理信道，还要把 NAV 冻结状态考虑进去。
2.2 把 .m 文件按功能分组:主流程、节点、队列、退避、显示
整套资源没有把逻辑灌进一个大脚本，而是按职责拆成了多个函数，这是它最适合学习的原因。我按功能把它们分成六组，先建立这张映射表：
| 功能组 | 对应文件 | 职责 |
|---|---|---|
| 主流程入口 | main.m、main1.m、CSMA_CA_test.m | 初始化参数、启动循环、调度测试场景 |
| DCF 核心 | Csmaca.m、csma_ca.m、csma_ca1.m | 载波监听、退避、发送、ACK 等待的仿真主逻辑 |
| CSMA/CD 对照 | Csmacd.m、csma_cd.m | 有线以太网的冲突检测版本，用于机制对比 |
| 节点管理 | AddNode.m、Increase.m | 增加节点、重传时扩大竞争窗口 |
| 帧队列与统计 | FramePush.m、FramePop.m、RecordSend.m | MAC 层数据帧入队、出队、发送事件记录 |
| 退避与冻结 | SetBackoffTime.m、GetFreeze.m | 退避初值设置、信道忙时是否冻结 |
| 可视化 | Display.m、Display1.m、mysphere.m、my.m | 节点位置、信道状态、统计结果的图形化展示 |
这里最值得注意的一点是包里有 Csmacd.m 和 csma_cd.m。CSMA/CD 是冲突检测，发送时监听，冲突后立刻停发并退避；CSMA/CA 是冲突避免，发送前尽可能规避冲突。两套逻辑放在同一套框架里，最大的好处是能直观看出“有线靠检测、无线靠避免”这句话在仿真曲线上的差异。无线之所以不能采用冲突检测，是因为发送和接收同时进行时，发送功率会完全盖住接收信号，自己根本听不见别人的碰撞，所以只能提前避。
2.3 按这份文件清单，我建议的阅读顺序
如果直接双击 main.m 然后看满屏曲线，大概率只能看到“结果对了”或“结果不对”，谈不上理解。我一般会按下面这个顺序读，避免被图形带偏：
第一步，先读包里的“程序模块功能详解.txt”。这份文件是代码的说明书，里面通常写了每个函数被谁调用、返回什么值。先花二十分钟把它过一遍，比逐个 m 文件猜接口高效得多。
第二步，打开 main.m 或 main1.m，只看前五十行，找出仿真的总时长 simTime、节点数 nodeNum、数据包长度 packetLen 这些顶层参数。不要去追显示函数，那些都是辅助。
第三步，用编辑器全局搜索 SetBackoffTime 和 GetFreeze 的调用位置。这两个函数出现的地方就是 DCF 主循环的关键分支，找到它们，基本就找到了整个状态机的骨架。
第三步做完后，再跑一次：
% 先跑主测试脚本，观察默认参数下的输出 main1; % 想看退避计数归零那一刻发生了什么，可以打断点 dbstop in Csmaca if backoff == 0第一行命令执行完整仿真，第二行命令在退避计数器归零的瞬间暂停程序。dbstop 加 if 条件的意思是：当工作区里的变量 backoff 等于 0 时，MATLAB 自动进入调试模式。这时可以查看当前节点的 ID、剩余退避值、信道状态等全部中间变量。这套包最大的学习价值就在这种单步观察能力上，比看十遍协议书都直观。
3. 把 DCF 主循环拆成状态机：退避怎么冻结、帧队列怎么进出
3.1 主循环的状态切换：空闲、等待 DIFS、退避、发送、等待 ACK
一套合格的 DCF 仿真，核心一定是一个状态机。我读 Csmaca.m 这类文件时，不会逐行读，而是先找它维护了几个状态。按 802.11 DCF 的标准流程，至少要有五个状态：IDLE 空闲、WAIT_DIFS 等待 DIFS、BACKOFF 退避、TRANSMIT 发送、WAIT_ACK 等待确认。下面这段代码，是我按这个包的文件职责还原出的等价主循环骨架，它和原包结构不完全一致，但每个分支都能对应上包里的函数：
% DCF 主循环状态机（MATLAB 风格等价还原） state = 'IDLE'; backoff = 0; while t <= simTime switch state case 'IDLE' % 持续监听信道，若 DIFS 期间信道一直空闲，进入退避 if channelIdleDuringInterval(t, t + difs) backoff = SetBackoffTime(nodeId, retryCount); state = 'BACKOFF'; end case 'BACKOFF' % GetFreeze 返回 1 表示信道忙或 NAV 未清零，必须冻结 if GetFreeze(nodeId, t) % 退避冻结，backoff 保持不变 elseif backoff > 0 backoff = backoff - 1; % 空闲时隙递减 t = t + slot; else FramePush(nodeId, packet); state = 'TRANSMIT'; end case 'TRANSMIT' % 帧出队并发射，记录发送事件 SendFrame(); FramePop(nodeId); RecordSend(nodeId, t, packetLen, 'start'); state = 'WAIT_ACK'; case 'WAIT_ACK' if t >= ackTimeout % 没等到 ACK，重传次数加 1，扩大竞争窗口 retryCount = retryCount + 1; Increase(nodeId); backoff = SetBackoffTime(nodeId, retryCount); state = 'BACKOFF'; end end end这段代码里，channelIdleDuringInterval 是辅助函数，检查从 t 到 t+difs 这段时间内信道是否始终空闲；SetBackoffTime 返回的是时隙数，不是物理秒数；GetFreeze 是原包里本来就有的函数，它判断的是“当前这个节点能不能继续倒数”。很多人在自己写 DCF 仿真时，会遗漏 BACKOFF 状态里的 t = t + slot，导致 MATLAB 死循环，因为时间不往前走。而 WAIT_ACK 状态里，ackTimeout 一般取 SIFS 加上一个短帧传输时间，不能拍脑袋设成 DIFS 的长度，否则 ACK 还没回来就重传，碰撞率会假性偏高。
3.2 SetBackoffTime 与二进制指数退避：CW 怎么递增
SetBackoffTime 名字很直白，它就是算退避值的地方。DCF 的退避不是一个固定随机数：每次传输失败，竞争窗口 CW 要翻倍；传输成功，CW 回到最小值 CWmin。这就是二进制指数退避。802.11g 里 CWmin 是 15，CWmax 是 1023，最大重传次数到了之后直接丢包。
如果让我把 SetBackoffTime.m 的核心逻辑重写清楚，关键就三行：
% 输入 retryCount：当前帧已经重传的次数 % 输出 backoffSlots：本次退避所需时隙数 cw = min(cwMin * 2^retryCount, cwMax); backoffSlots = randi([0, cw]); % 均匀随机取整，而非浮点数参数说明：cwMin 和 cwMax 都放在一个全局配置结构体里，方便一次性修改。randi 在 MATLAB 里表示从 [0, cw] 区间均匀选取整数，这是 IEEE 802.11 的标准做法。很多错误实现会用 rand * cw 再取整，语义上也是均匀，但边界处理和随机数序列特性不一样，在多节点重复仿真时差异会被放大。Increase.m 做的事情就是完成 cw = min(cwMin * 2^retryCount, cwMax) 这一递增动作，所以它和 SetBackoffTime 是成对出现的。
这里顺便解释一下为什么退避下限是 0 而不是 1。DCF 允许一个走了大运的站点退避值为 0，即 DIFS 结束后立刻发送。这个设置看起来不合理，但它能减小信道空闲浪费，而且因为有随机性，长期统计上不影响公平性。仿真时如果把下限改成 1，整体吞吐量会小幅下降，改的时候要意识到这是在偏离标准。
3.3 FramePush、FramePop、RecordSend：队列与发送记录的配合
DCF 仿真里不能把“每时隙都能生成新包”作为默认假设，否则网络负荷永远饱和，退避机制的作用会被高估。包里的 FramePush 和 FramePop 就是用来模拟 MAC 层发送队列的。FramePush 往队尾塞一帧，FramePop 从队头取一帧。队列长度是有限的，满了以后新到的帧直接丢弃，这个丢弃行为正是真实网卡会发生的事。
我一般会在 AddNode.m 里给每个节点单独分配队列长度参数，而不是用一个全局 scaler。原因很简单：如果所有节点共用一个队列对象，一个节点队满会导致另一个节点也发不出包，这种耦合在真实分布式系统里不存在。每个节点有独立队列，才能观察“某节点持续占信道导致其他节点丢包”的公平性问题。
RecordSend 则是统计模块的关键。它不直接画图，而是把每次发送的时间、节点号、帧长、是否成功追加到一个二维数组里。这个数组是后面计算吞吐量和碰撞率的基础数据。如果 RecordSend 只记录发送次数不记录帧长，那吞吐量永远算不出来，只能给一个发包速率曲线，这对无线仿真来说信息量损失很大。
3.4 如果要改仿真参数，先动这几个变量
不管跑哪一套 .m 文件，我建议把物理层参数集中在一个结构体里，而不是散落在各个脚本中。下面是我常用的配置块，也是这套包默认参数最可能的组织方式：
% 802.11g 物理层参数配置（集中管理） cfg.slotTime = 9e-6; % 时隙 9us cfg.sifs = 10e-6; % 短帧间间隔 10us cfg.difs = cfg.sifs + 2 * cfg.slotTime; % 28us cfg.cwMin = 15; % 初始竞争窗口 cfg.cwMax = 1023; % 最大竞争窗口 cfg.retryMax = 6; % 最大重传次数注意 DIFS 必须用公式 SIFS + 2 × SlotTime 推导，不能手写一个 28e-6 就完事。如果你后面想切到 802.11b，SlotTime 变成 20us，SIFS 还是 10us，DIFS 就变成 50us。用公式推导，只需要改两个基础量。把改完的时间参数换算成整数时隙数，再输入给主循环，能避开很多浮点比较问题。
4. 避坑排查：跑这套 MATLAB 仿真最容易翻车的 5 个地方
4.1 现象：退避计数一直停在原地，节点永远不退避
这个坑我遇到过一次之后印象极深。现象是打印每个时隙的 backoff 变量，发现它长时间不变，偶尔跳一下，但不会严格要求每个空闲时隙减 1。原因多半出在 GetFreeze 的返回值处理上。很多人的第一版实现会写成“只要当前时刻信道空闲，就返回 0 允许递减”，这是对的，但判断逻辑取了瞬时采样点，而真实 DCF 判断的是整个时隙是否空闲。如果上一个时隙尾部信道还是忙的，下一个时隙头部采样到空闲，就误判为空闲时隙，退避本该冻结却动了。
解决方法是把判断条件改成时隙粒度：从本次时隙起点到终点这一段区间内，检查是否存在任何节点的发送占用。在 MATLAB 里，这通常意味着记录每个发送的 startTime 和 endTime，然后用区间比较。如果包里的 GetFreeze.m 本身实现正确，那就检查主循环是什么时候调用它的，如果调用频率不是每个时隙一次，也会出现退避计数不规律跳动。
4.2 现象：节点数一多，仿真跑得极慢，一个 100ms 场景要等几分钟
这套包的定位是教学仿真，代码里很可能大量使用了 for 循环逐时隙逐节点扫描。当节点数从 5 加到 20，运算量不是线性增长，而是接近 O(N²) 增长，因为每个时隙每个节点都要检查信道占用，信道占用又要遍历所有发送事件。加上 Display 每个时隙都刷新图形，速度会雪崩。
我一般会把图形刷新频率降下来，比如每 100 个时隙刷新一次显示，而不是每时隙刷新。再就是把全节点扫描改成事件驱动的循环：维护一个“下一个事件时间”的数组，每次只处理最早到期的节点事件，跳过中间的空闲时隙。如果暂时不想改代码结构，最快的方法是缩短仿真时间或者只统计稳态部分，用 simTime = 0.05 代替 0.5，先验证逻辑再跑长场景。
4.3 现象：碰撞率高到离谱，吞吐量上不去，曲线比理论值低一大截
很多人第一反应是退避算法写错了，但我排查过几个类似项目后发现，最常见的根因是 ACK 等待超时设置得太短，或者根本没区分 SIFS 和 DIFS。802.11 DCF 里，接收方收到数据帧后要等 SIFS 才能回 ACK。如果代码把 ackTimeout 设成和 DIFS 一样长，或者设成比一个数据帧还短，那么发送方还没收到 ACK 就超时重传，正常传输被当成失败，碰撞率自然异常。
解决方式是把 ACK 等待超时拆成三段：数据帧最后一个 bit 到达接收方的时间、SIFS、ACK 帧传输时间。三段加起来才是合理的超时阈值。另外检查重传次数上限，如果 retryMax 设得过大，比如 100 次，那持续碰撞的帧会一直占着信道，系统吞吐量会被单帧拖死。
4.4 现象：图形窗口一闪而过，或者显示的画面和仿真结果对不上
Display.m 和 Display1.m 这类文件如果挂在主循环里，仿真结束后 GUI 窗口会随循环退出一起关掉。解决办法是在主脚本末尾加一句 keep 窗口等待用户输入：
% 仿真结束后保持图形窗口 drawnow; waitforbuttonpress;waitforbuttonpress 会让脚本停在那里，直到用户按任意键，窗口不会被 MATLAB 自动回收。至于画面和结果对不上，多半是因为记录统计的数组和绘制曲线用的数组不是同一份。比如 RecordSend 记录的是所有发送尝试，包括失败的，但 Display 只画了成功帧，那碰撞率高的时候图就严重失真。调试时先把两条曲线的数据源统一。
4.5 现象：两次运行同一套参数，结果差异大到无法判断对错
这不是 bug，是随机仿真没有固定种子。CSMA/CA 的核心是随机退避，每次运行 rand 生成的序列都不同，节点少的时候方差特别大。解决方法是每次运行前调用 rng 固定随机数种子：
% 固定种子，保证实验可复现 rng(20240101);如果做节点数对比实验，我习惯把种子和节点数绑定，比如 rng(100 + nodeNum)，这样跑不同节点数时，彼此之间仍然有随机差异，但同一节点数重复运行时结果可复现。固定种子之后，还必须注意一个细节：随机数的调用顺序要一致。如果你在节点配置阶段先调用了 rand 给信道噪声，会给每个节点分配不同的随机序列片段，看起来是随机的，但实际上是顺序错位。先跑一次不带种子的长仿真估计方差，再固定种子做正式实验，是更严谨的做法。
5. 用测试脚本验证 DCF：参数换算与吞吐量、碰撞率统计
5.1 理论参考：四个关键参数对应关系
验证仿真代码对不对，不能只看曲线长什么样，要对得上 IEEE 802.11 的参数体系。先把最常用的两组参数放在一起：
| 参数 | 802.11b | 802.11g |
|---|---|---|
| Slot Time | 20 us | 9 us |
| SIFS | 10 us | 10 us |
| DIFS | 50 us | 28 us |
| CWmin | 31 | 15 |
| CWmax | 1023 | 1023 |
| 数据速率典型值 | 11 Mbps | 54 Mbps |
如果在参数文件里看到 DIFS 比 SIFS 还小，那一定错了。DIFS = SIFS + 2 × SlotTime 是 802.11 DCF 的标准关系。用这个关系反过来可以验证代码里的时隙设置是否正确：比如 DIFS 是 28us，Slot Time 是 9us，那么 SIFS = DIFS − 2 × Slot = 10us，和标准对得上，说明这套参数是自洽的。
5.2 从 RecordSend 的日志里统计吞吐量和碰撞率
RecordSend 记录的数据是一种典型的 trace 数据结构。每行至少包含发送时刻、节点 ID、帧长（bit）、发送结果（成功或碰撞）。我用它算指标的思路是先定义好数组列含义，再看包里的输出是不是这个格式：
% 从 RecordSend 产生的 trace 计算吞吐量与碰撞率 % trace 每行: [发送时刻, 帧长(bit), 是否成功] function [tp, colRate] = AnalyzeTrace(trace) successIdx = trace(:, 3) == 1; totalBits = sum(trace(successIdx, 2)); simEnd = max(trace(:, 1)); tp = totalBits / simEnd; % bps colRate = 1 - sum(successIdx) / size(trace, 1); end参数说明：trace 第一列是发送时刻，第二列是帧长，单位是 bit，第三列是成功标志。总成功比特数除以仿真结束时刻，得到的是物理层有效载荷吞吐量，单位是 bps。碰撞率用失败发送次数除以总发送次数，取值范围在 0 到 1 之间。这里有个容易误导人的地方：碰撞率不是丢包率，碰撞后至少还会重传，真正丢包只发生在重传次数耗尽时，所以如果要画丢包率曲线，需要额外统计重传超过 retryMax 的帧。
5.3 我习惯的测试流程：固定种子、变节点数、重复跑、取平均
拿到这套包后，我不会直接改核心算法，而是先做一组基线实验。流程是固定的：
第一步，把 DIFS、SIFS、CWmin、CWmax 按 802.11g 参数设好。第二步，写一个循环，节点数从 2 增长到 40，每隔几个点取一个值。第三步，每个节点数跑 3 次，种子的后四位取节点数和重复批次的组合。第四步，把每次的吞吐量和碰撞率都存到结果矩阵，最后画均值点。
% 节点数扫描实验骨架 nodeList = [2 5 10 15 20 30 40]; result = zeros(length(nodeList), 3); for i = 1:length(nodeList) throughputList = zeros(1, 3); for rep = 1:3 rng(2024 + nodeList(i) * 10 + rep); stats = CSMA_CA_test(nodeList(i)); throughputList(rep) = stats.throughput; end result(i, :) = [nodeList(i), mean(throughputList), std(throughputList)]; end这段脚本用到了包里的 CSMA_CA_test.m，它应该是封装好的单节点数测试入口。如果原包的测试函数不叫这个名字，替换成对应的 main 或 main1 加传参即可。固定种子之后，三次结果的标准差如果仍然很大，说明仿真时间太短，随机退避的方差还没收敛，要把 simTime 拉长，而不是加长重复次数。
5.4 结果曲线怎么解读：吞吐量的“平顶”和碰撞率的“拐点”
画完曲线后，你会发现吞吐量并不是随节点数单调变化。节点少时，信道利用率低，吞吐量不高；节点增多后，总有节点在退避倒计时，信道利用率上升，吞吐量爬升；到了某个点之后，碰撞率快速上升，有效传输占比下降，吞吐量开始回落。这个“先升后降”的形态就是 DCF 的典型特征。
我判断这套仿真是否正常，通常看两个点：一是最大吞吐量是否落在理论值附近；二是碰撞率是否在节点数超过 15 后才开始明显抬头。如果节点数从 3 加到 5，碰撞率就飙升到 30%，说明代码里的冻结或 ACK 等待逻辑大概率有问题。
6. 最后一个技巧：把退避计数画成时间线，我看到 DCF 卡在哪一拍
前面几章看的是结果，最后我分享一个调试这套包时最值钱的技巧：画退避计数的时间线。DCF 的退避过程是肉眼看不见的，它发生在两个时隙之间，节点是否被冻结、冻结了多久，只看最终吞吐量曲线根本看不出来。但如果你能把每个节点的退避剩余值随时间变化画出来，整个协议的运行过程就像解了黑匣子一样展开。
实现方法不复杂。在 SetBackoffTime 返回后、GetFreeze 判定完成后、backoff 递减的三个位置，往一个日志数组里追加一行记录。每条记录包含三个字段：仿真时刻 t、节点 ID、退避剩余值 backoffRemaining。为了不让日志爆炸，我只在退避值发生变化时记录，稳定不变的时间段不重复追加。
% 收集退避时间线，供后续 stairs 绘图 backoffLog = []; % 每行: [时刻, 节点ID, 剩余退避时隙数] % 以下代码插入到主循环 BACKOFF 状态的处理位置 if freezeFlag backoffLog(end+1, :) = [t, nodeId, backoff]; elseif backoff > 0 backoff = backoff - 1; backoffLog(end+1, :) = [t, nodeId, backoff]; end参数说明：backoffLog 是 N 行 3 列的矩阵，第一列记录的是仿真时间，单位秒，画图时我会乘 1e6 转换成微秒；第二列是节点 ID；第三列是被冻结或递减后的退避剩余值。因为 MATLAB 里追加一行的代价是重新分配数组，日志长度控制在几万行以内完全没问题。
画图用 stairs 比 plot 合适，因为退避值只在时隙边界变化，是阶梯形状：
% 按节点分线绘制退避时间线 figure; hold on; for nodeId = unique(backoffLog(:,2))' idx = backoffLog(:,2) == nodeId; stairs(backoffLog(idx,1)*1e6, backoffLog(idx,3), 'LineWidth', 1); end xlabel('time / us'); ylabel('remaining backoff / slots');这段代码把每个节点的退避倒计时画成递减的阶梯。两个特征特别明显：一是斜线越陡说明退避速度越快；二是水平直线出现的地方，就是节点被冻结的时间段。哪条水平线越长，说明这个节点发起的帧把信道占得越久，或者其他节点正在竞争。以前我调这类仿真，遇到吞吐量异常只能靠猜，自从养成画这条时间线的习惯后，问题定位基本不会超过十分钟。从那以后我每次跑这套 MATLAB 仿真，都强制自己先导出 backoffLog，再谈吞吐量。希望帮到你。
本文还有配套的精品资源，点击获取
