最近被问得最多的一个问题就是5G/NR一个小区到底能调度多少个RB说实话第一次做5G协议栈、网优或者终端适配的人很容易拿着LTE那套固定15kHz子载波间隔的思路去套NR结果对不上号的事情一件接一件。5G/NR物理资源的复杂度确实比LTE高了一个档次但核心骨架没变——一张资源网格一堆子载波和OFDM符号再加上灵活到有点“任性”的参数集。这篇文章我不会把协议原文抄一遍而是把5G/NR物理资源这套东西按我自己干活时的理解重新讲一遍。适合刚接触NR物理层的人快速建立框架也适合已经在做调度、网优或者产品验证的朋友拿来当排查思路参考。我会尽量把“为什么这么设计”也讲清楚毕竟5G里的很多参数不是拍脑袋定的理解背后的取舍比死记配置表有用得多。1. 5G/NR物理资源究竟长什么样1.1 资源网格从LTE继承但又完全不同的一张表5G/NR的物理资源最经典的描述就是“资源网格”。你可以把它想象成一张Excel表横轴是时间纵轴是频率。横轴按OFDM符号切纵轴按子载波切于是每个交点就是一个资源单元REResource Element。RE是NR物理资源最基本的单位一个子载波在一个OFDM符号周期内能承载的资源。一个RE能放一个调制符号QPSK放2bit256QAM放8bit就这么简单。这张网格和LTE最大的区别在于LTE的子载波间隔基本固定为15kHz一个RB固定为180kHz带宽。NR的子载波间隔则是一套“参数集”Numerology15kHz、30kHz、60kHz、120kHz、240kHz都可以用一个RB仍然是12个子载波但RB的实际带宽会随着子载波间隔变化30kHz下就是360kHz120kHz下就是1.44MHz。这就带来一个非常常见的误区很多人说“5G的RB是180kHz”这个说法只对15kHz参数集成立。如果你用30kHz参数集一个RB占360kHz用120kHz占1.44MHz。“RB”指的是12个子载波它不是一个固定的频域宽度。1.2 RE、RB、PRB、CRB先把四种“块”辨清楚NR里除了资源网格还有一堆带B的缩写RB、PRB、CRB、BWP、RBG。我第一次看规范的时候也确实被绕了一下。先说RBResource Block在NR里它专指频域上的12个子载波。一个时隙里的14个OFDM符号对应到频域的一个RB就是12乘14个RE。时域上纳?好多人把这个也当成“一个RB”消耗时长其实不对RB是纯频域概念。然后是CRB和PRB。NR里引入了Point APoint A是参考频率点所有的公共资源块CRB都从Point A开始编号。CRB 0是第一个公共资源块。UE又不会直接使用整个小区带宽所以RRC重配时会给UE设一个BWPBWP内部重新编号的RB就是PRB。PRB的编号按照相对于BWP起点的位置从头数。为什么要这么绕因为网络侧调度的时候习惯用CRB定位UE用PRB理解自己的分配。调试时最容易出错的点就在这DCI里频域资源指示的RB位置可能是相对BWP的PRB编号也可能是资源分配类型对应的预定义RBG不能拿网管上查到的“CRB起始位置”直接填。打个比方小区是整个大楼Point A是一楼门口的地桩CRB是整栋楼统一编的房号BWP是其中一层楼PRB就是这一层里重新编的房间号。调度时不看全楼编号只看你在哪一层、这层里的几号房。1.3 一张表看懂常用带宽下的RB数干活的时候最常用的是下面这张表不同信道带宽和子载波间隔组合下允许的最大RB数。先声明一点这是规范里定义的“最大传输带宽配置”对应值完整表格要翻协议规范我这里只列现场最常碰到的几档。信道带宽15kHz SCS30kHz SCS5MHz251110MHz522420MHz1065140MHz21610650MHz270133100MHz不适用273这张表怎么用举个例子运营商给你一个20MHz15kHz的小区物理资源总数最多就是106个RB如果你开的是100MHz30kHz那就是273个RB。很多网优报告里写“RB利用率90%”指的就是调度中的PRB数除以这个最大RB数。这里有个小坑表里是“最大RB数”不是说你随便配就能用满。实际是否够用还要看信道带宽边缘的保护带、SSB实际占用、以及终端能力。比如100MHz带宽下如果终端只支持20MHz那它只能在BWP里看20MHz资源哪怕小区总RB有273个对它来说也只是其中一小块。2. 为什么NR要搞多套Numerology2.1 子载波间隔和时隙长度怎么换算NR里的参数集用µ希腊字母mu表示子载波间隔SCS 15 × 2^µ kHz。µ0对应15kHzµ1对应30kHzµ2对应60kHzµ3对应120kHz。时隙长度也跟着变一个时隙是1ms除以2^µ。15kHz下一个时隙1ms30kHz下0.5ms60kHz下0.25ms120kHz下0.125ms。注意不管哪种子载波间隔一个常规时隙都固定是14个OFDM符号所以子载波间隔越大符号越短时隙也越短。拿30kHz举例一个符号周期约33.3微秒一个时隙14个符号正好0.5ms。一秒钟有2000个时隙。这个换算在速率估算时特别常用后面我会用它算一个100MHz小区的峰值速率。CP循环前缀也要一起看。子载波间隔越大OFDM符号越短CP也随之变短。CP的作用是抵抗多径时延和符号间干扰CP越短对信道时延扩展越敏感。低频大覆盖场景需要较长的CP来抗干扰所以15kHz更合适高频段相位噪声大、可用带宽大用120kHz可以把符号压缩得极短配合波束管理降低时延。2.2 到底怎么选子载波间隔很多人以为Sub-6GHz只能用30kHz毫米波只能用120kHz其实没这么简单。FR1也就是Sub-6GHz常用的是15kHz和30kHzFR2毫米波常用60kHz和120kHz。但在FR1的某些场景下60kHz也是允许的只是实际商用选择不多。怎么选本质上是一个权衡覆盖优先选15kHz符号长、CP相对长能扛更大的多径时延适合低频FDD或广覆盖场景。时延优先选30kHz或更高时隙短调度周期短HARQ往返快下行峰值吞吐也更高。高频场景选120kHz带宽大相位噪声影响大必须用大子载波间隔来压低。现场最经典的配置是FDD低频段用15kHzTDD中频段如2.6GHz、3.5GHz用30kHz毫米波用120kHz。做优化的时候不要一上来就调SCS先确认当前承载的业务到底需要覆盖还是时延。2.3 BWP把大带宽切成适合UE的小块BWPBandwidth Part带宽部分是NR物理资源里最值得讲清楚的概念之一。LTE没有BWP终端一开机整个小区带宽都得盲检。NR小区可以开到100MHz甚至更大但终端能力、功耗和成本不可能都支持这么大的带宽。于是协议允许网络侧在小区带宽内给UE单独划一个逻辑上的“带宽窗口”这个窗口就是BWP。BWP可以是一个很窄的20MHz也可以是一个完整的100MHz甚至可以配置不同的子载波间隔。UE只在自己的BWP里做PDCCH/PDSCH承载和反馈不用在整段大带宽上盲检功耗大幅下降。BWP还分初始BWP和活跃BWP。UE开机时用的初始BWP通常很窄主要是为了完成随机接入和读取系统消息比如初始DL BWP可能只有20MHz、24个RB左右。后续通过RRC重配再切换到更大的活跃BWP去做高速业务。注意一个坑BWP的配置不是“越大越好”。BWP太大UE的基带处理复杂度和功耗都会上升BWP太小吞吐受限于资源不足。曾经遇到过某个项目把100MHz小区的活跃BWP配成20MHz测试速率怎么都上不去查了一圈才发现是BWP没扩。这种问题在RRC信令里非常隐蔽因为UE层速率已经正常了只是物理资源根本不够用。3. 资源调度RB在时域和频域是怎么切给用户的3.1 时隙级调度DCI和符号级起止位置物理资源最终是要通过PDCCH上的DCIDownlink Control Information告诉UE“你的数据在哪块资源上”。NR的调度时域粒度比LTE细得多可以只分配一个时隙里的某几个OFDM符号而不是整个子帧。DCI里的时域资源分配字段指向一个高层配置的列表里面每一行定义了一个起始符号S和持续长度L。协议用SLIV这个统一编码把S和L打包成一个数字终端拿到后解码就知道PDSCH从第几个符号开始、占几个符号。为什么要搞得这么灵活因为TDD场景下一个时隙里既有下行符号又有上行符号还有特殊时隙里的GP保护间隔PDSCH不可能总是从符号0开始到符号13结束。如果一个小区把PDCCH配了3个符号那PDSCH最早也只能从符号3开始如果这是特殊时隙可用符号还要再砍。这里有个实际影响同样是273个RB的100MHz小区如果PDCCH占用2个符号PDSCH还有12个符号可用如果PDCCH占用4个符号数据符号只剩10个峰值速率可能下降15%以上。优化的时候看“PDCCH开销占比”往往比单纯看MCS更有效。3.2 频域调度RBG和DCI压缩频域资源分配NR有两种主要类型一种叫资源分配类型0用RBG位图方式一种叫资源分配类型1用连续的起始RB长度指示类似LTE的分配方式。RBGResource Block Group是一组RB的集合DCI里用一位代表一个RBG是否被调度。如果小区273个RB用RB粒度调度需要273个bitDCI会非常大把几个RB合成一个RBG后位图长度大幅缩短。RBG大小由网络侧决定通常BWP小于36个RB时RBG为2或4BWP大的时候RBG可能为8或16。代价就是分配粒度变粗。对边缘用户或者业务量很小的用户一个大RBG容易造成浪费。比如RBG大小是16一个用户只想要5个RB做VoNR语音包结果最低也给16个RB资源利用率不高。这就是为什么小带宽VoNR部署时不少人会把BWP设小一点让RBG变小调度更精细。PRGPRB Bundling则是另一个和频域资源相关的概念它把连续的多个PRB捆绑在一起使用同一个预编码矩阵/解调参考信号。这会影响DMRS的密度和解调性能调试时如果发现某个吞吐档位总是差一点可以看看PRG大小和信道估计配置是否匹配。3.3 别忘了那些“看不见”的资源开销资源网格里的RE一部分是给用户数据的还有一部分被各种参考信号和控制信道占用。常见的开销包括SSB同步信号块占用20个RB、4个符号周期性发送。PDCCH和CORESET下行控制信息占用的符号和RB。DMRS解调参考信号PDSCH、PUSCH都需要密度有type1/type2之分。CSI-RS信道状态信息测量用。CSI反馈、SRS上行测量和反馈资源。在TDD场景下还有上下行切换的GP保护间隔。很多人估算速率的时候直接把全部RB按14个符号、256QAM去算这样算出来的理论值很好看但实际永远达不到。原因就是这些开销没有扣除。至少先扣掉PDCCH占用的2到3个符号再扣掉DMRS和CSI-RS的开销得到的才是大致能看到的速率上限。4. 实操一个100MHz小区的峰值速率估算4.1 从RB数到RE数再到Mbps我们来算一笔账这个例子我自己做过很多次非常实用。假设一个TDD小区信道带宽100MHz子载波间隔30kHz最大RB数273。30kHz下1秒有2000个时隙每个时隙14个符号所以瞬时每一层可以用的RE数 273个RB × 12个子载波 × 14个符号 45864个RE每秒总RE数 45864 × 2000 91728000个RE如果采用256QAM每RE 8bit编码码率约0.925理想情况是 91728000 × 8 × 0.925 ≈ 678Mbps这只是单流、且使用全部14个符号的理想值。实际每个下行时隙前2个符号要留给PDCCHPDSCH一般从符号2或符号3开始按12个数据符号算就变成273 × 12 × 12 × 2000 78624000个RE再乘8bit再乘0.925 ≈ 582Mbps。再扣掉DMRS和CSI-RS开销单流实际峰值大概在520到550Mbps左右双流MIMO才能到1.1Gbps以上。这正好解释了为什么很多100MHz 5G站点宣传“下行1Gbps”实际测试单终端能跑到800Mbps已经很漂亮了。4.2 TDD上下行配比对可用资源的影响如果再加上TDD上下行配比计算要再打折扣。比如常见的5ms周期里下行6个时隙、特殊时隙2个、上行2个那真正用于下行的符号数就只有一半多。再按上面的方法算下行单流峰值可能只剩300Mbps左右。所以做容量规划的时候先确认三件事子载波间隔、TDD配比、PDCCH符号数。这三个定了理论峰值基本就能估个八九不离十。很多时候业务投诉“下载慢”查到最后要么是TDD配比里下行比例低要么是PDCCH符号数偏高跟无线环境关系反而不大。CQI和MCS的映射也要随手会看。DCI里的MCS表并不是简单的调制阶数对应关系实际TBS传输块大小要用MCS索引查表得到TBS索引再结合分配的RB数查TBS表。一个更粗暴的估法是用上面的有效RE数乘以调制阶数乘以码率再留10%的余量就能估算单用户单流速率。4.3 多用户场景下怎么算平均速率单用户峰值的算法搞明白了多用户容量估算就顺了。假设小区总下行有效RE数为78.6M/s256QAM下总吞吐约580Mbps。如果同时有100个用户在线每个用户都是满缓冲区、公平调度理想平均速率就是5.8Mbps左右。但实际不可能全部用户都占满资源还要看激活用户数和调度算法所以“用户体验速率”通常按小区容量的30%到50%去留。这个估算方法对上下行都适用只是上行要额外考虑终端发射功率受限SCS越大覆盖越小不能只看RB数。我之前做上行容量评估时总是先看每个UE的SRS SINR和功控余量再谈能分到多少RB顺序不能反。5. 现场排查手册物理资源相关的典型翻车案例5.1 速率上不去第一反应不要是加功率遇到下行速率不达标很多人第一步就去调发射功率或者加天线权值。但根据我的经验先看物理资源相关配置才是最合理的。排查顺序一般是看UE驻留的BWP带宽对不对。如果配置成20MHz用户只能用51个RB速率天花板就是25Mbps量级。看PDCCH符号数。PDCCH占3个符号比占2个符号数据符号少了近15%。看CQI/MCS有没有被限制。有没有配置MCS table 禁用256QAM或者CQI上报周期太长导致调度器用保守MCS。看秩Rank。如果终端上报rank1理论双流速率直接砍半。这时候要查天线端口配置、CSI-RS是否正常发射、以及终端是否支持4接收天线。最后才看RF问题比如SINR差导致MCS掉档。这套顺序几乎可以覆盖80%的“速率低”问题。我有一次排查到凌晨最后发现是RRC里BWP的起始PRB配错导致终端和基站对“哪个RB被调度”的理解完全不同速率忽高忽低但SINR一直很好。资源相关配置的错误就是这样隐蔽。5.2 BWP相关的“新坑”BWP的坑比LTE时代多得多。最常见的一个现象是UE初始接入正常但RRC重配完成后速率始终提不上来。打开日志一看UE还在初始BWP没有切换到活跃BWP。原因可能是网络侧下发的BWP配置里频率位置和UE搜索空间对不上或者激活DCI没成功UE永远留在窄带里做业务。另一种是BWP切换引发的调度中断。BWP切换不是瞬间完成的切换期间PDCCH和PDSCH都不能正常接收频繁切换会降低实际吞吐。有的场景为了省电配了多个BWP结果业务连续性变差。我的建议是除非有强烈的节电需求否则尽量保持一个足够带宽的活跃BWP别为了“看起来灵活”频繁切来切去。还有SSB和CORESET0所在的频率点。如果初始BWP的CORESET0配置太小比如只有24个RB虽然UE能接入但公共控制信道的容量也很小多用户并发时竞争信道容易出现随机接入拥塞。做高用户数验证的地方务必要确认初始BWP带宽和CORESET0配置是否匹配。5.3 频域资源分配异常怎么查如果DCI里频域资源指示的PRB位置总是不对先不要怀疑终端先看协议层配置。重点检查三处BWP起始位置和大小是否和PRB编号基准一致。资源分配类型是0还是1。类型0用RBG位图类型1用起始RB长度如果网络侧和UE侧配置不一致解析出来完全是两个结果。有没有开PDCCH的C-RNTI的BWP inactive timer。超时后UE会回落到默认BWP导致速率突然掉档。实测中还有一个高频问题基站侧统计的PRB利用率和终端侧实际调度的RB数对不上。这种情况往往是因为预留资源比如给VoNR或高优先级用户预留的RB没有计入普通数据调度统计或者有一部分RB被用于CSI-RS、SRS等测量信号。看统计口径的时候先确认两边定义的是“可用PRB”还是“全部PRB”再谈占比。最后再分享一个小技巧无论你是做协议栈开发、网络优化还是产品测试手边常备三样东西——一张RB数速查表、一份MCS/TBS表、一个时隙结构图。遇到物理资源相关的问题先回到这张资源网格上画一画把时间、频率映射坐标标出来大部分疑惑都能在纸上解决。我在项目里带人的时候最常说的一句话就是NR物理资源不急先画网格再谈优化。