前两天射频组的同事又拎着一台信号分析仪过来让我帮他对一下链路预算“你帮我看看这样一个OFDM符号里到底能塞多少数据”我第一反应是拿带宽除以符号速率套个公式直接算结果两边怎么都对不上。后来才发现不是公式错了而是我少问了一个问题——他问的到底是“原始bit”还是“用户能真正用上的bit”。这两个数字能差好几倍。OFDM符号承载能力这个问题看着简单实际上牵一发动全身子载波数、调制阶数、导频、循环前缀、编码效率、空间流数都会影响最终结果。今天就把这个问题的完整推导过程捋一遍看完你也能在5分钟内手算出任意一个OFDM符号大概能装多少数据。1. 这个问题的起点OFDM符号和比特的第一次碰面1.1 一个符号其实是许多小调制符号的集合很多刚接触OFDM的人会把“OFDM符号”理解成类似QPSK星座图上的“一个点”其实不是。一个OFDM符号是在某个时间窗口内所有子载波同时发送的一整块信号。它就像一字排开的几百个乃至上千个“小容器”每个容器对应一个子载波容器里装的才是真正调制过的星座点。举个例子20MHz带宽、子载波间隔312.5kHz的典型系统FFT点数是64那这个OFDM符号里就有64个频域位置。其中一部分放数据一部分放导频一部分留空做保护。接收端做一次FFT把时域信号变回频域就能从每个子载波上取出一个调制符号。如果每个子载波用的是64QAM那每个子载波携带6个bit如果是256QAM每个子载波携带8个bit。所以“一个OFDM符号有多少bit”的第一层答案很简单把所有数据子载波上的调制bit加总起来就是物理层原始bit数。公式就是单符号bit数 数据子载波数 × 每个子载波调制bit数log2(M)这里的M是调制阶数QPSK是416QAM是1664QAM是64256QAM是256。1.2 为什么这个数值不是固定答案如果你拿着这个公式去查不同系统的参数会发现答案五花八门。老一点Wi-Fi的20MHz OFDM符号一个符号的原始bit数可能只有一两百而一个5G大带宽符号数据bit数可以轻松过万。这不是谁算错了而是系统设计本来就不一样。决定单符号bit数的关键变量至少有这几个子载波总数、数据子载波占比、调制阶数、参考信号密度。再往后延伸到整条链路还要加上编码速率、循环前缀开销、空间流数、控制信道占用。任何一个变量变了你得到的“一个符号的bit数”就变了。因此想回答“到底含有多少bit”必须先定义清楚问题语境。是纯物理层原始bit还是编码后的bit还是MAC层能用的信息bit这三种口径结果可能差到3倍以上。这也是我同事和我第一次对不上的原因他关心的是业务吞吐量我算的是符号原始承载量概念不在一个维度上。2. 计算模型bit 数据子载波 × 调制阶数然后一步步打折2.1 数据子载波、导频子载波、保护子载波怎么瓜分频域一个OFDM系统的频域资源不是所有子载波都能用来传业务。常见分配有三类数据子载波、导频子载波、保护/直流子载波。数据子载波不必多说就是真正承载用户业务的子载波。导频子载波为了信道估计和相位跟踪发的是收发双方都已知的序列不携带用户信息。保护子载波则分布在频带边缘用来抑制带外泄漏让发射信号符合频谱模板。直流子载波在频带正中心因为DC附近干扰大且本地泄漏严重一般直接留空。这三类子载波的具体数量标准里写得清清楚楚。拿最经典的802.11a/g来看20MHz带宽做64点FFT一共64个子载波其中48个数据子载波、4个导频子载波其余12个留给保护带和直流。很多人会把“64个子载波”直接当成数据子载波数去算这就错了——实际可利用的数据子载波只有48个连总数的75%都不到。2.2 调制阶数决定每个子载波的bit上限每一个数据子载波在一个OFDM符号周期内只能发射一个调制符号。这个符号能带多少bit取决于调制方式调制方式每个子载波bit数星座点数对信噪比的要求BPSK12最低QPSK24较低16QAM416中等64QAM664较高256QAM8256很高bit数和星座点数的关系是2^kM。调制阶数每提升一级星座图上相邻点之间的欧氏距离就会缩小抗噪声能力随之下降。工程上一个很实用的经验是每多携带1个bit解调门限大约要提高3dB左右。所以系统不会永远用最高阶调制信道条件差的时候会自动回落到QPSK甚至BPSK。如果你在Wi-Fi或者蜂窝网里看MCS表格会发现同样一个符号不同MCS对应的bit数可以差出8倍。这就是为什么“一个符号有多少bit”首先要看调制阶数。2.3 完整公式单符号有效bit还要乘编码率和开销系数把上面所有因素合起来单符号的bit数估算公式可以写成单符号信息bit 数据子载波数 × log2(调制阶数) × 编码速率 × (1 - 参考信号资源占比) × 空间流数这里的编码速率是指信道编码后的信息比特比例。比如LDPC编码速率为3/4意思是4个编码bit里有3个是信息bit、1个是校验bit。参考信号资源占比是导频、DMRS等非业务RE占总RE的比例。空间流数则是MIMO带来的倍数1个空间流就不乘4个空间流就乘4。这个公式算出来的是“单符号能承载的信息bit”也就是用户可以实实在在拿去用的bit而不是空口上发射的原始bit。两者差别在后面几节我会用一个Wi-Fi和一个蜂窝系统的实例完整算一遍。3. 算一算真实系统的OFDM符号Wi-Fi和蜂窝网全流程推演3.1 Wi-Fi传统OFDM符号一镜到底算到Mbps以20MHz带宽的典型Wi-Fi OFDM系统为例先把关键参数列出来FFT点数64子载波间隔312.5kHz有用符号时间3.2微秒循环前缀0.8微秒完整符号时间4.0微秒数据子载波48个导频子载波4个其余子载波12个保护/直流如果一个OFDM符号采用64QAM、编码速率3/4那么调制原始bit 48 × 6 288bit扣除编码冗余后信息bit 288 × 3/4 216bit所以结论一这个配置下一个4微秒的OFDM符号能携带216个信息bit。这还不是终点再把它折算成空口速率速率 216bit / 4微秒 54Mbps这个54Mbps是不是很眼熟没错802.11a/g里的最高速率54Mbps就是这样算出来的。回头看整个速率家族每一个值都对应一个调制阶数和编码速率的组合调制编码组合每符号bit空口速率BPSK 1/2246MbpsQPSK 1/24812MbpsQPSK 3/47218Mbps16QAM 1/29624Mbps16QAM 3/414436Mbps64QAM 2/319248Mbps64QAM 3/421654Mbps跟标准对一遍一个都不差。这说明一个经验只要把“数据子载波、符号时长、调制阶数、编码速率”四个参数抓准计算过程完全可以手推。3.2 蜂窝系统用RB和RE视角看同一个问题Wi-Fi里习惯说子载波蜂窝系统里更习惯用“资源块RB”和“资源元素RE”。最小粒度其实是一个RE它就是一个子载波在一个OFDM符号周期内的资源。1个RB包含12个频域子载波在时域上跨整个时隙。以20MHz带宽、15kHz子载波间隔的典型蜂窝配置为例资源块数常见是100个左右取100个RB做估算。100个RB × 12个子载波 1200个频域子载波。那么一个OFDM符号在理想情况下有多少个RE可供使用1200个100RB × 12子载波 × 1符号。如果这个符号上用64QAM单符号原始bit 1200 × 6 7200bit如果调制升到256QAM单符号原始bit 1200 × 8 9600bit换算成速率15kHz子载波间隔对应的OFDM符号时长约66.7微秒正常循环前缀约4.7微秒总时长71.4微秒左右。256QAM下的原始空口速率就是9600bit / 71.4微秒 ≈ 134Mbps这个数字很能说明问题一个20MHz带宽系统即便用256QAM在单个OFDM符号层面也只有一万bit左右的原始承载能力。要得到更高的速率必须靠MIMO空间流相乘和更大的带宽。当然实际业务信道不可能把1200个RE全部拿来传用户数据。里面要扣掉小区参考信号、解调参考信号、控制信道、PSS/SSS这些同步信号。扣完之后大约只有七到八成的RE能真正分配给业务数据。所以如果你要算一个PDSCH符号真正能传的信息bit得在9600bit的基础上再乘0.7到0.8还得乘编码速率。这样算下来一个256QAM符号的典型信息bit大致落在5000到7000bit左右。3.3 从“一个符号”反推“一秒钟能传多少bit”很多实际场景比如链路预算、吞吐量评估最终关心的不是单个符号而是每秒速率。这个换算只需要再做一步除法比特速率 每符号信息bit / 完整符号时长完整符号时长 有用符号时间 循环前缀长度。别忘了循环前缀不传业务数据但它仍然占据时间资源。从这个公式能看出两个方向的设计权衡子载波间隔变大符号时间变短每个符号携带的bit数通常不变因为数据子载波数量随带宽划分决定但每秒能发送的符号数量变多速率提升。调制阶数升高每符号bit数增加但解调门限变高覆盖距离变小。这就是为什么高速率系统往往同时使用高阶调制和大带宽因为两个维度都在同一方向上拉高容量。4. 为什么按公式算出来的数字现实中总是“少一截”4.1 循环前缀白占时间但不占bit循环前缀的主要作用是消除多径时延扩展带来的符号间干扰。它把OFDM符号尾部的信号复制到头部接收端只要在循环前缀窗口内完成FFT同步子载波之间的正交性就不会被多径破坏。代价就是每个OFDM符号的实际发射时间比有用FFT时间长。这部分时间不承载任何有效数据等效于直接降低数据速率。Wi-Fi传统OFDM里循环前缀0.8微秒有用符号3.2微秒循环前缀占整个符号的比例是0.8 / (0.8 3.2) 20%也就是说即便数据子载波全部利用、编码效率100%光循环前缀一项就吃掉20%的吞吐。蜂窝15kHz子载波间隔情况下正常循环前缀开销大约6.7%左右看起来比Wi-Fi好一些但它用的符号时长本身就长时延也更高。子载波间隔提高到30kHz后循环前缀比例会变成11%~12%开销明显增加。工程上的启示是循环前缀越长系统抗多径能力越强但吞吐损耗越大两者需要根据部署场景做取舍。高频通信里子载波间隔做得很大循环前缀相应很短就是因为覆盖半径小、多径时延短不需要那么长的保护时间。4.2 导频和参考信号频率维度上的“非业务人口”导频承载的是收发双方约定的序列用来估计信道、纠正频率偏差、跟踪相位噪声。它消耗RE但不产生用户数据。在OFDM符号资源网格里导频通常是星型散布的不会连续占满一个符号但你没法把它完全去掉。Wi-Fi传统OFDM的4个导频子载波占了52个非保护子载波里的7.7%。蜂窝系统更复杂下行要布小区特定参考信号、信道状态信息参考信号、解调参考信号上行也有专用解调参考信号和探测参考信号。这些参考信号在正常情况下会占掉总资源量的5%~20%Massive MIMO场景下如果每个天线端口都发DMRS开销还会更高。所以你在算一个业务OFDM符号时必须把参考信号所在RE剔除。这个细节是“按公式算出来总是虚高”的最大元凶之一。4.3 编码和重传信息bit在发射前就已经缩过水信道编码会系统地加入冗余。Wi-Fi历史上常用1/2到3/4的编码速率5G NR里常见的LDPC速率范围更宽低速率下可以低到1/3甚至更低高速率下能到0.9以上。编码速率越低纠错能力越强但有效信息比特越少。在标准速率表和MCS表格里你看到的“速率”已经是乘完编码速率之后的结果不需要再额外乘一次。很多人容易搞混拿64QAM的288bit直接除以4微秒得出72Mbps然后怀疑系统为什么不支持这个速率——其实那是调制bit不是信息bit。另外无线信道有误码系统不会只发一次就完事。Wi-Fi有MAC层重传蜂窝有HARQ机制。一旦误码接收端反馈NACK系统就要重新调度资源再传一遍。在统计层面这会带来10%~30%的额外资源占用。所以真实吞吐和理论峰值之间永远有一段差距。4.4 MIMO一个OFDM符号变成多个并行符号MIMO意味着同一个OFDM符号时间多根天线同时发射不同的数据流。空间流数N直接让单符号bit数乘以N。例如4个空间流的64QAM单符号信息bit就是Wi-Fi单流场景的4倍。但MIMO不是白给的。每增加一个空间流参考信号也要相应增加因为接收端需要分辨每个流各自经历了什么信道。导频开销会随着流数上升。多流之间的干扰也需要编码和波束赋形来控制。否则就算你把MIMO倍数乘上去了实际能用的调制阶数也会掉下来最终收益远不如理论值。算MIMO场景时比较稳妥的简化方式是单符号总bit 单流bit × 有效空间流数 × (1 - 参考信号增加比例)现场粗略估算时4流MIMO一般按3.2到3.5倍的等效收益来打折扣不会直接按4倍计算。5. 现场掉坑记录几个常见的误算和历史教训5.1 先确认对方问的是哪种“bit”按我现在的经验回答“一个OFDM符号有多少bit”之前第一件事一定是反问要的是物理层原始bit还是编码后的信息bit算的是业务信道专用符号还是整个下行共享信道的平均符号考不考虑MIMO空间流要不要把控制信道和参考信号一起算进去这四个问题的答案不同最终数值差异非常大。一个20MHz蜂窝符号按原始bit口径可以接近一万按用户业务信息bit口径可能只有五六千再算上MIMO和编码还能再翻好几倍或者缩水。建议跟别人交流时直接沿用系统标准的术语调制bit、编码bit、信息bit。这三个词能避免大部分争吵。调制bit是星座图上携带的原始bit编码bit是编码器输出经过速率匹配后的bit集合信息bit才是递交给上层协议栈的数据bit。5.2 快速估算自查清单五步法我现在做现场估算时固定走下面五步基本不会出错确定带宽和子载波间隔算出子载波总数和数据子载波数。确认当前MCS对应的调制阶数和编码速率。查看参考信号类型和密度预留至少5%~20%的RE开销。如果有多天线确认实际调度的空间流数。最后除以完整OFDM符号时长换算到每秒速率。每一步要写清楚单位和时间粒度尤其是“一个符号时间”必须包含循环前缀不能用有用符号时间直接套否则明明算了正确bit数速度还是会快20%。5.3 我实际遇到过的误算案例第一个案例是把1200个子载波全当数据载波忽略了边缘保护子载波和DC结果单符号bit数被高估了百分之十几。后来拿频谱仪看发射信号发现边缘子载波功率是零才意识到资源网格里那部分是留空的。第二个案例是有人拿“1个RB × 14个OFDM符号”当成了1个RE的资源量来算bit把时域符号数和频域子载波数混在一起。一个RB其实等于12个频域子载波乘整个时隙的符号数任意一个单独OFDM符号的采样都只有12个RE不是14个。第三个案例是bit和Byte单位没捋清算数据速率时把“bit/s”和“Byte/s”互转搞差了8倍截图发给上游直接闹了笑话。这事听着低级但在多人协作的链路预算里经常发生。第四个案例是重传开销没有进预算。实测环境里快速移动或干扰严重的场景重传率可能到20%以上原先算出的可用速率会再次打折。现在我在做峰值速率估算时都会习惯性加一行“重传余量”宁可估低一点也好过交付时对不上。说到底一个OFDM符号的bit数不是一个固定的常数而是一个建模问题。把调制阶数、参考信号、编码速率这些边界条件说清楚答案其实就在一张A4纸上。下次再有人问这个问题建议把上面的五步走一遍先反问口径再套参数最后除以符号时长基本就能给出一个靠谱数字。我自己后来和射频同事对链路预算都是先用这个方法算一遍理论值再拿实测结果对比偏差通常在10%以内——剩下的差额就是导频、重传和实现损耗这些现实物理世界不肯让步的部分。