刚做通信物理层那会儿我最怕的问题不是“信道估计怎么做”而是“一个OFDM符号到底含有多少bit数据”。听起来简单真答起来却容易翻车。说64QAM是6个bit吧对方问那20MHz LTE一个符号是多少bit我开始掰着指头算子载波数、导频、控制区最后发现答案不止一个甚至同一个系统里不同位置的符号都不一样。这个问题其实特别值得掰开揉碎讲一遍。它横跨调制映射、OFDM资源网格、导频开销、循环前缀和编码速率把这些概念串起来之后你看物理层速率、调度公式、测试账本都会顺很多。这篇文章我从最小单元开始算一步步算到一张完整速查表顺便把新手容易踩的坑都点一遍。1. 先从最小口径入手一个子载波一“口”能吃多少bit1.1 调制阶数决定每个子载波承载的bit数OFDM系统里数据不是直接以“bit”为单位放到子载波上的而是先把若干个bit映射成一个调制符号再放到某个子载波上。这个调制符号在复平面上对应一个点所有这些点的集合就是星座图。星座图上有多少个点就叫多少进制的调制。常见有这些调制方式星座点数 M每个子载波承载bit典型应用BPSK21极低速率兜底QPSK42低信号质量场景16QAM164中间档64QAM646LTE / WiFi高速档256QAM2568高信噪比场景1024QAM102410WiFi 6上限为什么一算就是log2(M)原因很简单M个星座点要想被解调端区分每个点必须对应一个互不相同的bit组合。64个点就要有64种组合6个bit能产生2^664种组合所以64QAM每符号承载6bit。你可以把它理解成一个码本码本越大每个字符携带的信息量越多但字符之间的距离越近越容易被噪声“认错”。所以第一层的答案是一个子载波上放多少个bit取决于调制阶数而不是这个子载波本身的频率高低。子载波只是一个传输通道通道里能塞多少信息由调制方式和信道质量共同决定。1.2 一个OFDM符号周期内每个子载波只发一个星座点这里有个常见的理解误区子载波频率很高有人以为它每个振荡周期都能发一个bit。实际不是这样。OFDM的发送过程是把一串bit按频域排好每个子载波位置上放一个复数星座点然后做IFFT得到时域波形。这个波形在一个OFDM符号周期内是完整的、并行的每个子载波的幅度和相位在该符号周期内保持不变。真正承载信息的是这个复数点在Q路还是I路、幅度多大、相位偏了多少而不是高频振荡本身“一周期发一bit”。所以更准确的口径是一个子载波在一个OFDM符号周期内只发一个调制符号也就是log2(M)个bit。这个“一口”的概念很重要后面所有计算都建立在它上面。2. 扩到整个OFDM符号把所有子载波累加起来2.1 总bit数公式与第一次试算一个OFDM符号由N个并行的子载波组成每个子载波上放一个独立的调制符号。那么一个OFDM符号的bit数就是总bit数 数据子载波数 × 每个子载波的bit数写成更直观的形式就是每符号bit N_data × log2(M)举个例子。LTE 20MHz带宽子载波间隔15kHz一个资源块是12个子载波、180kHz20MHz里一共有100个资源块所以可用于调度的子载波数是1200个。如果用64QAM每个子载波6bit一个OFDM符号的数据bit就是1200 × 6 7200 bit也就是900个字节。一个符号能装900字节听起来不少但LTE一毫秒内有14个符号这14个符号能不能都满负荷后面细说。再看WiFi的对照。802.11ac在80MHz下FFT大小是256但真正用于数据传输的子载波是226个。如果跑256QAM每个子载波8bit一个OFDM符号的bit数是226 × 8 1808 bit一个符号才226字节比LTE少但WiFi的符号时间短得多符号速率高所以每秒总吞吐并不低。这也是为什么看系统性能不能只看“一个符号多少bit”必须把时间维拉进来。2.2 为什么不能直接把FFT大小当子载波数量刚接触协议的人最容易犯的错是看到FFT大小是2048就拿2048去乘调制bit。错在FFT大小只是基带处理的采样点数不代表这些点都能用来传数据。真实系统里子载波要分成几类数据子载波真正承载用户数据的。导频子载波发已知序列用于信道估计、相位跟踪不承载用户数据。直流子载波中心频点附近容易受本振泄漏和直流干扰通常不承载数据。保护子载波频谱两侧留空用于满足发射频谱模板要求避免干扰相邻信道。以802.11ac的20MHz为例FFT大小是64但总共有52个非零子载波其中4个导频、48个数据。FFT里剩下的12个位置是直流和保护。80MHz下FFT大小是256数据子载波226个导频8个剩下的是直流和保护。换句话说FFT大小越大不等于能用的数据越多中间有相当一部分是“结构性开销”。LTE的情况略有不同它几乎所有子载波都参与传输但导频是在某些RE上复用的所以一个符号里能不能放满7200bit要看这个符号是不是含导频的符号。这一点放到后面资源网格部分展开。3. 完整算一遍LTE 20MHz 64QAM单流到底是多少bit3.1 关键参数是怎么来的LTE 20MHz的系统参数算是通信物理层的“标准练手题”参数如下子载波间隔Δf 15kHz因此FFT有效符号时间T 1/15000 ≈ 66.7us。20MHz带宽内有100个资源块每个RB有12个子载波总共1200个可用于调度的子载波。系统采样率30.72MHz对应FFT大小2048因为2048 × 15kHz 30.72MHz。正常循环前缀下1ms子帧有14个OFDM符号前一个时隙的第一个符号CP稍长其他符号CP稍短。这里多说一句FFT大小和带宽的关系。2048这个数字不是“20MHz带宽直接分配2048个子载波”而是采样率除以子载波间隔的结果。这2048个频域位置里实际承载数据的只有1200个两侧还有保护带。这就是前面说的“FFT不等同于数据子载波数”。3.2 分步计算从每符号bit到毛速率第一步一个数据子载波用64QAM承载6bit。第二步一个OFDM符号如果所有1200个数据子载波都满负荷则1200 × 6 7200 bit第三步1ms内有14个OFDM符号如果14个符号全都能放满数据则7200 × 14 100800 bit/ms 100.8Mbps这就是很多人说的“LTE 20MHz 64QAM单流理论上限”的毛速率。注意“毛”字——它假设没有任何导频、没有任何控制信道、没有编码冗余所有RE都被64QAM数据填满。真实系统永远到不了这个数因为导频和控制必须要占地方。第四步如果开2×2 MIMO两个空间流各自独立映射数据毛速率翻倍到201.6Mbps。再扣除导频、PDCCH、同步信号、广播信道和编码率之后通常就回到我们熟悉的150Mbps量级。这也是为什么LTE Cat4的峰值速率标称150Mbps而不是201Mbps。3.3 同一个系统里不同OFDM符号的bit数不一样这一点特别容易忽略。LTE里不是每个OFDM符号都能让1200个数据子载波满载。下行参考信号CRS在子帧的第0、4、7、11个OFDM符号上出现这些符号里的部分RE被导频占掉数据RE就减少了。所以“一个OFDM符号多少bit”这个问题严格说要看这个符号是纯数据符号还是带导频符号。带导频符号的数据bit (1200 - 导频占用的子载波数) × 调制bit。同一套系统、同一个调制方式下符号位置不同答案不同。这也是为什么我不建议背一个固定数字而是建议掌握“数资源网格”的方法下面会专门讲。4. 加入时间维和编码率才会变成吞吐率4.1 OFDM符号的“单价时间”是1/Δf加上循环前缀前面算的7200bit是“一次搬运的量”但每秒能搬多少次取决于OFDM符号周期。符号周期由两部分组成符号周期 1/Δf 循环前缀1/Δf是FFT的有效积分时间循环前缀是为了抵抗多径时延扩展而在符号之间插入的保护。不同系统差别很大。系统子载波间隔有效符号时间典型GI/CP符号速率LTE 15kHz15kHz66.7us4.7us左右约14k符号/sWiFi 11ac 80MHz312.5kHz3.2us0.8us约250k符号/sWiFi 11ax 80MHz78.125kHz12.8us0.8us约73.5k符号/s所以LTE一个OFDM符号虽然能装7200bit但每秒只有14000个符号WiFi 11ac一个符号只能装1808bit但每秒有25万个符号。把这个乘起来LTE7200 × 14000 ≈ 100.8Mbps毛速率单流WiFi 11ac 80MHz1808 × 250000 ≈ 452Mbps毛速率单流看到没有单看“一个符号多少bit”WiFi比LTE少但人家符号时间短按秒算完全不落下风。这就是为什么讨论OFDM符号bit数时必须把时间维一起带进来否则会得出非常误导的结论。4.2 编码率会把“有用bit”再打一个折扣还有一个经常被漏掉的概念装在OFDM符号里的bit是信道编码之后的bit不是用户原始数据bit。为了纠正信道错误发端会给原始数据加上校验bit。编码率3/4的意思就是每4个编码后的bit里只有3个是真正的用户数据1个是冗余。LTE高速率场景的编码率可以到0.93左右WiFi则常用5/6。所以净荷速率公式是用户吞吐 ≈ 每符号bit × 符号速率 × 编码率 × 空间流数 × 协议开销系数回到LTE的例子100.8Mbps毛速率 × 0.93编码率再扣除导频和控制带来的约20%开销就得到单流约75Mbps、双流约150Mbps的峰值。如果不乘编码率你就永远理解不了为什么“明明一个符号7200bit下载却只有几十兆”。4.3 MIMO会让bit按空间流成倍增加MIMO再怎么强调都不为过。OFDM符号的bit数公式在多层空间复用下要加一个层数因子每符号总bit N_data × log2(M) × N_layer以LTE 2×2 MIMO、64QAM、满负荷纯数据符号举例7200 × 2 14400 bit一个符号从900字节变成1800字节。当然这是理想信道条件下才能做到一旦信道相关性高、SNR不足系统会自适应降阶调制或减少层数。实际调度时你会看到调制阶数和层数是一起波动的。5. 带导频的符号怎么算资源网格才是完整答案5.1 在RB网格里数RE比背公式更可靠如果只记公式碰到带导频的符号很容易错。我自己的习惯是画资源网格。拿LTE正常CP来说一个资源块在一个时隙内是12个子载波 × 7个OFDM符号共84个RE。如果64QAM、所有RE都放数据一个RB一个时隙最多是84 × 6 504 bit但真实情况下CRS要占掉一部分。以最常用的2天线端口CRS配置为例一个RB在时隙里会被吃掉若干个RE。再加上前几个OFDM符号里还有PDCCH控制区剩下的PDSCH数据RE才是真正能装用户数据的地方。你在协议文档里看到的TBS传输块大小查表本质上就是先数出一个调度块里可用的数据RE数再乘以调制bit和层数最后按编码率反推原始数据大小。所以“一个OFDM符号多少bit”看起来是个小问题实际上是TBS计算的原型。5.2 5G NR里同一个符号的bit数更不固定5G NR比LTE更灵活解调参考信号DMRS是按需配置的可能只在某几个符号上出现而且不同的符号上DMRS密度还不一样。再加上PT-RS用于相位噪声补偿也是按需放置。所以讨论5G一个OFDM符号多少bit必须先问这个符号上有没有参考信号有没有控制资源集数据子载波是否全部调度满以100MHz、30kHz参数集为例调度子载波数是273个RB × 12 3276个。如果跑256QAM一个纯数据符号的bit数是3276 × 8 26208 bit如果这个符号带DMRS数据RE减少bit数就下降。同一套参数集、同一个符号时间答案可以有好几种。6. 常见系统速查一张表看穿量级差异6.1 标准配置下的每符号bit参考把几种常见系统的典型配置放在一起看量级差异一目了然。这里按单空间流、纯数据符号、不考虑导频在符号内的占用算实际调度时要自行扣除。系统标称带宽子载波间隔数据子载波数典型高阶调制每符号bit单流NB-IoT下行180kHz15kHz12QPSK24LTE下行20MHz15kHz120064QAM72005G NR下行100MHz30kHz3276256QAM26208WiFi 11ac80MHz312.5kHz226256QAM1808WiFi 11ax80MHz78.125kHz9801024QAM9800注意NB-IoT这个极端例子12个数据子载波、QPSK一个符号才24bit连3个字节都不到。但它覆盖一个窄带物联网设备的控制信令绰绰有余因为它对速率的要求本来就低换来的是极强的覆盖和低功耗。这正好说明“一个OFDM符号多少bit”不是一个越高越好的指标而是系统设计权衡的结果。6.2 从频谱效率看数字差异把每符号bit除以“带宽 × 符号时间”得到的是频谱效率单位是bit/s/Hz。这个指标可以公平比较不同系统。LTE 20MHz、64QAM、真实有效子载波1200毛频谱效率约100.8Mbps / 20MHz ≈ 5.04 bit/s/Hz。WiFi 11ax 80MHz、1024QAM、数据子载波980毛频谱效率约720Mbps / 80MHz ≈ 9 bit/s/Hz。差距来自两块一是调制阶数1024QAM每子载波10bit比64QAM的6bit高很多二是有效子载波占比802.11ax在80MHz下数据子载波达到980/1024占比超过95%比LTE的1200/2048高出一截。这也解释了为什么WiFi 6在良好信道下的峰值速率能做到接近千兆级。7. 新手容易踩的坑7.1 以为FFT大小就是数据子载波数2048点FFT不等于2048个数据子载波。LTE的20MHz真正用于PDSCH调度的只有1200个子载波其余是保护带和参考信号。WiFi更明显64点FFT里只有48个数据子载波。看协议时一定要分清“FFT点数”“有效子载波数”“数据子载波数”三个概念。7.2 以为64QAM就是一个OFDM符号64bit这是最典型的误会。64QAM指的是每个子载波上的调制符号有64个星座点承载6bit。要算整个OFDM符号必须乘以数据子载波数。一个只有12个子载波的窄带系统64QAM也只有72bit一个1200子载波的宽带系统64QAM是7200bit。7.3 算速率时忘了乘编码率每符号bit算完直接拿去除符号时间得到的是编码前的毛速率。实际用户吞吐还要乘编码率、扣除导频和控制开销、再乘流数。很多人不理解为什么理论计算和实测对不上多半是卡在这一步。7.4 把所有OFDM符号都当成满载LTE里CRS符号、PDCCH符号、空口上的同步和广播信号都会占掉一部分RE。说“一个OFDM符号7200bit”只适用于纯数据且满调度的理想符号。真正看调度情况时要按照资源网格逐个扣除。8. 口算技巧我平时怎么快速估一个OFDM符号的bit数最后分享几个我自己常用的口算套路算是给文章收个尾。第一看到系统先问四个参数FFT大小、子载波间隔、有效数据子载波数、最高调制阶数。前两个决定符号时间后两个决定每符号bit。第二口算时先算“每RB每符号的bit数”。LTE一个RB是12个子载波64QAM时是72bit/RB/符号100个RB就是7200bit/符号。这样算比直接记1200个子载波更不容易错因为调度时经常以RB为单位。第三如果一个符号带导频我习惯先画一列RE出来12个子载波往下排7个符号往右排然后把导频、控制、数据分别标上去。标完再数“这一列里有多少数据RE”乘调制bit答案就出来了。这个动作看起来笨但它能把“一个OFDM符号多少bit”变成一个永远不会错的算术题。我自己刚入行时总觉得背下峰值速率、背下一个符号多少bit就掌握了物理层。后来发现数字会变参数集会变只有“先画网格、再数RE、再乘调制、再扣开销”这套方法不会变。把这个问题想透之后看调度、看TBS、看吞吐测试思路会顺畅很多。以后再有人问你一个OFDM符号多少bit你可以反问他你说的是哪个系统、哪个符号、带不带导频、开没开MIMO能把条件说清楚答案自己就算出来了。