简介《WIFI6空口速率计算.pdf》面向无线网络工程师、数通运维人员及无线技术学习者聚焦 802.11ax 理论峰值速率的结构化拆解解决建链速率“只知结果、不知算法”的常见问题。文档以空口速率MIMO 流数×1/SymbolGI×每子载波bit×编码率×有效子载波数量为主线逐项展开多天线 MIMO、Symbol 与保护间隔、1024QAM 编码、5/6 码率及 256 阶 FFT 子载波划分对速率的影响并结合华为 AP4050DN 等实际设备演示 AP 与终端“就低不就高”的协商机制说明三射频 AP 宣称 8 条流并不等于真实连接速率。资源为单个 PDF 电子文档整包约 204KB页面内配有公式速查与参数对照既适合无线网络方案设计时估算理论速率也可作为认证备考与排错时的桌面笔记。目前已有 179 人浏览学习适合希望快速建立 WiFi6 速率计算框架、深入理解理论值与实际差异的技术人员。1. WIFI6空口速率计算为什么协商速率不能直接当“真速率”做无线网络验收时最容易让人心里一沉的就是这一幕AP 管理页里终端协商速率明明显示 2402Mbps可 iperf 一跑只有 900 出头客户当场质疑设备“虚标”。干过这行的人都知道问题不在硬件而在我们把“空口速率”和“有效吞吐”混为一谈。WIFI6空口速率计算这件事本质是把物理层瞬时速率、协议固定开销、实际帧长三样东西拆开算而多数项目缺的正是这套折算路径。这份 PDF 解决的就是这个痛点从 802.11ax 的速率表怎么查到 DIFS、SIFS、ACK、退避这些开销怎么扣再到 64 字节小包和 1518 字节大包为什么结果差出一大截。适合无线网络工程师、WLAN 验收人员和做性能排障的同行照着算一遍至少能回答“这个速度到底正不正常”。2. 先摸清物理层底牌wifi4、wifi5、wifi6 的关键差异与速率表正确用法2.1 三代 WiFi 的空口效率差在哪要算 WIFI6 空口速率第一步不是套公式而是搞清楚 802.11ax 相对前两代到底改了什么。这也是很多同行讨论 wifi4和wifi5和wifi6的区别时容易忽略的地方速率提升不只是调制阶数变高符号结构和多用户机制的变化对空口效率的影响更关键。参数WiFi4 (802.11n)WiFi5 (802.11ac)WiFi6 (802.11ax)调制上限64-QAMMCS 0~7256-QAMMCS 0~94096-QAMMCS 0~11子载波间隔312.5 kHz312.5 kHz78.125 kHzOFDM 数据符号时长3.2 us3.2 us12.8 us最短 GI0.4 us0.4 us0.8 us最大空间流48常见 48常见 4多用户机制无DL MU-MIMOOFDMA UL/DL MU-MIMO典型极限速率40MHz/4流 约 600Mbps80MHz/4流 约 1733Mbps80MHz/4流 约 4808Mbps先说子载波间隔。802.11ax 把子载波间隔从 312.5kHz 降到 78.125kHz数据符号从 3.2us 拉到 12.8us。符号变长意味着每个符号携带的 bit 更多同时 CP 开销比例更低抗多径能力也更强。代价是符号内的时间粒度变粗对同步要求更高这就是为什么 GI 从 0.4us 变成 0.8us 起步。再说是调制。WiFi6 引入 4096-QAM单子载波一次能带 12bit比 WiFi5 的 8bit 多了一半。加上 1024 点 FFT 带来的更多数据子载波80MHz 带宽下单流极限从 WiFi5 的 433Mbps 左右提升到 1200Mbps 上下。这部分是“裸速率”提升但它只在理想信噪比下成立实际环境里 MCS 11 往往会被速率自适应算法降级。2.2 查 WiFi6 速率表先定带宽、流数、MCS、GI物理层速率不是算出来的而是查出来的。IEEE 在 802.11ax 标准里已经把 MCS、带宽、流数、GI 组合好的速率列成表计算时唯一要做的是确定四个输入项带宽20/40/80/160MHz、空间流数、MCS 等级、GI 长度。我一般这么查打开设备协商信息先确认带宽和流数再确认当前 MCS。多数商用 AP 管理页会直接显示“HE80 / 2SS / MCS11 / GI0.8”这一串对应速率就是 2402Mbps 附近。如果设备不显示 MCS只有协商速率那就反过来用协商速率反查当前 MCS 和 GI确认终端是否真的跑在短 GI 上。查表时有一个细节容易翻车WiFi6 的 GI 是 0.8、1.6、3.2us 三档很多人下意识认为 0.8 是短 GI1.6 是长 GI这没问题但 WiFi5 的短 GI 是 0.4us两代不能拿同一列去比。同样 MCS 11、80MHz、单流GI 从 0.8us 换到 1.6us速率大概降 5%换到 3.2us再降约 8%。这个比例对最终算出的有效吞吐影响不小后面避坑章会专门展开。提示查表前先确认设备固件里的 GI 配置是否强制长 GI。部分 AP 为了兼容老终端或提高稳定性会把最短 GI 锁在 1.6us此时按 0.8us 查表必然虚高。3. 空口速率怎么算从 PHY 速率到有效吞吐的三步折算3.1 第一步把“协商速率”还原成单个帧的空中时间协商速率只是物理层在一个 PPDU 传输窗口内的瞬时速率它不包含任何协议间隔。要算有效吞吐得先把问题转化成“传一个数据帧到底占了多少空中时间”。单个数据帧的一次完整交换空中时间可以拆成下面几段T_total T_preamble T_data T_SIFS T_ACK T_DIFS T_backoff各参数取值如下WiFi6 的 HE 前导大概 20us 左右具体随 HE-LTF 模式和 RU 数量变化SIFS 在 5GHz 是 16usDIFS 是 SIFS 加两个时隙5GHz 下约 34us平均退避大约是半个竞争窗口乘以时隙9us 一个 slot均值约 67us。把这些固定项加起来一次帧交换光是协议开销就有 130us 上下。这个数字单独看不吓人但放到小帧场景里就很夸张。一个 64 字节的 UDP 报文封装成 802.11 帧后数据段也就几十字节在 2.4Gbps 协商速率下传输时间只有几微秒协议开销反而是数据时间的几十倍。这就是为什么小包速率永远跑不上去也是空口速率计算里最核心的逻辑起点。3.2 第二步把协议开销一层层加回去很多人算空口速率只做减法协商速率乘以某个 0.5 或者 0.7 的经验系数得出一个数但这数一到答辩现场就说不清。更稳妥的做法是像上面那样把开销逐段列出来再用实际帧长去折算。以 5GHz、80MHz、双流、MCS11、GI0.8协商速率 2402Mbps 为例传一个 1518 字节的以太网帧封装成无线帧后约 1546 字节环节参数估算值前导开销HE 前导约 20 us数据段1546B 2402Mbps约 5.2 usSIFS固定16 usACK基本速率发送约 28 usDIFS 平均退避固定 随机约 100 us合计占用一次帧交换约 170 us这个 170us 里真正传数据的只有 5.2us其余全是协议开销。有效吞吐折算下来是 1518 字节除以 170us约 71Mbps听着很低——但注意这里没有算 A-MPDU 聚合。实际 WiFi6 会把几十个帧聚合在一个 PPDU 里发固定开销被摊薄吞吐率才会上来。3.3 第三步用经验折算因子做工程速算手工逐帧算太慢日常我更习惯在 PHY 协商速率后面直接乘一个“帧长折算因子”。这个因子是上面逐帧算法的浓缩结果随帧长变化很明显和 MCS、流数的关系反而弱一些。数据帧形态折算因子UDP、无重传典型场景64B 小包0.30 ~ 0.40IoT 上报、信令256B0.55 ~ 0.65语音、小事务512B0.65 ~ 0.75普通业务混合1518B 满帧0.80 ~ 0.88文件传输、视频流高密度 A-MPDU 聚合流0.85 ~ 0.92持续大流量 UDP拿前面 2402Mbps 的例子套跑 1518 字节 UDP取 0.85有效吞吐约 2042Mbps跑 64 字节小包取 0.35只有约 840Mbps。这个结果和我现场实测的规律一致——大包跑得接近链路速率小包直接腰斩再腰斩。注意上述因子是 5GHz、无 OBSS 干扰、无重传的理想场景。信道繁忙时退避时间和碰撞重传会把因子再往下压 10 到 20 个百分点所以现场测速低于表值不必急着怀疑设备。4. 避坑指南WIFI6 空口速率计算最常见的五个坡4.1 把协商速率当好“实际可用速率”现象AP 显示终端协商 2402Mbps客户预期下载速度必须到 300MB/s实测只有 110MB/s当场认为设备缩水。原因协商速率是物理层瞬时速率不包含 DIFS、退避、ACK、前导这些协议开销也不包含 TCP 确认反向流对信道的占用。用第 3 章折算表算一下1518 字节大包 0.85 因子出来约 2042Mbps再加上 TCP 双向交互和 ACK 反向占用掉到 110MB/s 其实是正常水平。解决验收口径改成“UDP 满帧单向不低于协商速率的 0.8”再把 TCP 结果单独报告。别拿协商速率做承诺值。4.2 GI 对不上算出来的数字系统性虚高现象按 MCS11、GI0.8 查表算出 2402Mbps设备协商信息里却只有 2167Mbps 左右数据对不上。原因AP 或终端的 GI 实际工作在 1.6us。很多 AP 默认开启“长 GI 兼容模式”尤其是混合接入 WiFi5 终端时整个 BSS 都会退到 1.6us。这时按 0.8us 查表速率自然虚高约 5%。解决查 AP radio 配置里的 GI 设置确认是 auto 还是强制值再看终端连接详情里的 GI 字段。两边都确认是 0.8us 再按短 GI 查表。4.3 看到“总速率”就把 OFDMA 下单个终端速率当成它现象AP 标称 4808Mbps现场单终端测速只有 1200Mbps 上下客户质问“剩下 3600 去哪了”。原因OFDMA 把 80MHz 频段切成多个 RU 分给不同终端单个终端往往只占其中一部分 RU自然分不到整段带宽。更常见的是终端只有 2 条流而 AP 标称 4 条流速率天然只有一半。解决计算前先看终端的 RX/TX 流数再看它关联的 RU 宽度。OFDMA 场景下每终端速率按它分配到的 RU 单独查表不能直接用整带宽速率。4.4 信道有雷达回避80MHz 频宽静默缩成 40MHz现象配置里选了 80MHz理论协商速率 2402Mbps实际长期跑在 1200Mbps抓包发现信道带宽只有 40MHz。原因5GHz 的 DFS 信道检测到雷达信号后AP 会触发信道可用性检查把频宽退回 40MHz 甚至 20MHz。这个过程往往不是一次性降级而是持续占用部分信道导致无法恢复 80MHz。解决查看射频扫描日志里的 DFS 事件确认当前主信道和辅信道是否被雷达占用。如果连续出现换到不含雷达检测的信道段并检查周边是否有雷达源。4.5 只测下行拿单方向结果代表全链路空口速率现象下行 UDP 测出 1.9Gbps上行只有 600Mbps验收报告只写下行数字后续业务投诉上行卡顿。原因很多终端是 2 发 2 收发射链路的 MCS 因为功率和天线增益限制比接收低部分 AP 默认关闭上行 OFDMA上行用传统 EDCA 竞争吞吐自然比下行低一截。解决上下行分开测分别记录 MCS、流数、GI。如果上行明显偏低先在 AP 里开 UL OFDMA 和 UL MU-MIMO再查终端发射功率和天线数。5. 验证计算结果的落地技巧抓包反推与回填校验5.1 用 iperf3 建立实测基线理论折算完必须用实测兜底。我的习惯是先跑一轮无重传 UDP 满帧再跑 TCP 多流最后抓包复核。UDP 命令有这么一段iperf3 -u -c 192.0.2.10 -b 1G -l 1472 -t 30 -i 5参数说明-u走 UDP-c指定服务端-b 1G是目标发送速率不要让 iperf 缺省用 1Mbps 的 UDP 速率否则测的是上限不是带宽-l 1472把负载设成 1472 字节加上 UDP/IP 头正好 1500避免 IP 分片-t 30跑 30 秒-i 5每 5 秒打印一次。重点关注最后一行的接收吞吐和丢包率丢包超过 0.1% 说明空口已经撑不住这个速率了。抓包复核时在终端侧用 Wireshark 抓 802.11 报文展开 Radio Tap Header看 Data Rate 字段。这个值是真实发送时的物理速率如果它和协商速率对得上说明链路没有降级如果它只有协商速率的一半那就是 GI、流数或者带宽配置有问题回头改配置再测。5.2 回填计算表把误差控制在 10% 以内实测数据到手后我把结果回填到第 3.3 节的折算表里对照。步骤如下记录实测 UDP 吞吐、抓包里的平均 Data Rate、AP 侧统计的空口占用率。然后拿实测吞吐除以协商速率得到实际因子和表里的区间对比。通常 1518 字节满帧的实测因子如果低于 0.75我会怀疑三件事是否没有开启 A-MPDU 聚合是否 GI 实际是 1.6us以及信道里是否有隐藏节点导致退避时间异常偏大。挨个排查多数情况是 A-MPDU 聚合在驱动里被关掉或者无线控制器模板里开了强制长 GI。把这两个开关对齐后实测因子回到 0.82 以上是常态。从那以后我每次做无线验收都强制走一遍“查速率表、定 GI 和流数、跑 UDP 实测、抓包复核”这四步不再拿协商速率单独拍脑袋。折算表只能给起点实测才是终点。希望帮到你。本文还有配套的精品资源点击获取