简介面向移动通信初学者与终端研发人员的5G NR理论速率计算详解PPT围绕FDD/TDD制式从子载波间隔、帧结构、时隙/OFDM符号等物理层基础讲起逐步过渡到调制编码、载波聚合、mMIMO等实际影响因素让零基础用户也能理解理论峰值速率的由来。文件为1个pptx演示文稿压缩包仅817KB信息密度高已有2519人学习下载既适合自学也可作为内部培训的讲解素材或网优工程师的速查手册。资源不仅逐一解释各参数含义还给出了FDD下行/上行、TDD单周期/双周期等多种场景的完整速率计算公式并对每个数字的物理意义进行标注例如4×4MIMO、256QAM的8bit映射、编码效率0.926、273个RB、资源开销占比0.14、时隙配比等如何代入公式帮助读者举一反三自行计算不同配置下的5G峰值速率如FDD下行2.3Gbps、上行937MbpsTDD下行最高1.7Gbps等。无论是新手学习还是专业人士快速查阅这份PPT都能提供清晰、可操作的参考也能帮助理解5G NR技术潜力与限制。1. 5G NR理论速率是谁的指标先分清峰值与体验速率很多人第一次接触“5G NR理论速率计算”是被宣传页上的“下行峰值2.3Gbps、3.0Gbps”吸引来的。可真到了现场测速往往只有标称值的一半甚至三分之一。这不是设备偷了带宽而是大多数人都没搞明白理论速率是物理层在给定带宽、调制阶数、MIMO层数和帧结构下的极限搬运能力它天然不包括调度空隙、参考信号占用、终端接收能力和信道质量这些“现实损耗”。所以这篇笔记要做的是把5G NR理论速率的计算公式拆开从时频资源讲到调制编码再落到一套完整的计算流程上。适合网络优化、终端测试、无线产品经理和对速率指标较真的从业者也适合被指标忽悠过一次后想自己动手算明白的人。2. 理论速率公式怎么拆时频资源、调制编码与层数的乘积逻辑2.1 先从时频资源说起RB、子载波与符号NR的物理资源是一个二维网格横轴是时间纵轴是频率。频率方向的最小单位是子载波一个子载波间隔对应一种参数集时间方向的最小单位是OFDM符号常规循环前缀下每个时隙固定14个符号。真正参与调度的资源块RB则是12个连续子载波在频域上的组合一个RB乘以一个时隙就构成了物理层调度的最小粒度。这里有个关键变量子载波间隔SCS直接影响时隙长度。15kHz下1个子载波宽15kHz一个时隙1ms30kHz下时隙变成0.5ms1ms内有2个时隙60kHz下1ms内有4个时隙。同一段时间内时隙数量越多能塞进去的OFDM符号就越多这是NR能比LTE跑得快的底层原因之一。计算理论速率的第一步就是把“一秒内到底有多少个资源单元可用”先算出来。公式为每秒可用RE数 RB数 × 12子载波 × 14符号 × 每秒时隙数以100MHz带宽、30kHz子载波间隔为例NR定义的最大RB数是273个每秒时隙数是2000个。代入后每秒总RE数为273 × 12 × 14 × 2000 91,728,000个资源单元。这个数字是整个计算的地基后续所有乘数都要落在这上面。2.2 调制阶数与编码效率256QAM和LDPC为什么决定了天花板资源单元只是“格子”每个格子能装多少比特由调制阶数和编码效率共同决定。调制阶数越高单个符号携带的比特越多QPSK是2bit16QAM是4bit64QAM是6bit256QAM是8bit。NR下行在FR1频段最高支持256QAM这是物理层的调制天花板。但编码效率不能忽略。NR的LDPC信道编码在最大速率档位下码率取948/1024约等于0.9258。也就是说8bit的调制符号里真正能用于业务数据的只有8 × 0.9258 7.41bit。剩下那部分是被校验比特占掉的这是信道编码的“保护成本”不是浪费。把两者合并就能算出单层单RE的有效承载比特。256QAM配LDPC最大码率时是7.41bit/RE64QAM则只有6 × 0.9258 5.55bit/RE。别小看这1.86bit的差异换算到整个100MHz带宽上就是每秒上亿个RE乘以这个差值最终下行速率能差出30%以上。这也是为什么很多终端在弱信号环境下速率直接腰斩——调制阶数从256QAM掉到64QAM甚至16QAM物理层天花板先降了一大截。2.3 层数与帧结构MIMO和TDD配比是隐藏的乘数资源单元和调制编码算完还差两个最容易算错的乘数MIMO层数和TDD时隙配比。MIMO层数可以粗浅理解为“同时跑几条并行的数据流”。理论上下行8层、8个接收天线才能把这部分吃满但实际商用终端多数只支持4层接收基站侧即使有64通道调度器也会按终端能力限制在4层。因此计算时要先确认终端能力上报里的maxMIMO-Layers而不是直接拿8层去乘。TDD帧结构则是另一个大变量。NR在FR1的TDD频段上下行和上行共用一个载波靠时隙配比划分时间。以常见的DDDSU五时隙周期为例3个纯下行时隙加1个特殊时隙按特殊时隙里6个下行符号、4个上行符号、4个保护间隔来拆分5ms周期内下行占用的符号比例是(3×146) / (5×14) 68.6%。这意味着即使物理层算出来有2Gbps的搬运能力TDD配比一乘下行实际可用于调度的时间只剩68.6%。到这里理论速率的完整公式就立住了每秒RE数 × 调制比特 × 编码效率 × 层数 × TDD配比。接下来就看怎么往里面填真实参数。3. 拿真实配置算一遍100MHz带宽下的下行与上行明细账3.1 先确认带宽、SCS与RB数的对应关系很多第一次动手算的人最容易在RB数上翻车。NR的RB数量不是简单用“带宽除以子载波间隔再除以12”就能得到的3GPP在协议里按频段、SCS和信道带宽给出了固定的RB数表。100MHz带宽在30kHz SCS下对应273个RB这个值要直接查表确认不能自己硬算。SCS与RB数的对应关系整理成速查表如下信道带宽15kHz SCS30kHz SCS60kHz SCS20MHz106 RB51 RB24 RB40MHz216 RB106 RB51 RB50MHz270 RB133 RB66 RB100MHz不支持273 RB135 RB注意表中的“不支持”100MHz带宽在FR1频段下不适用15kHz SCS因为273个RB在15kHz下只占约50MHz频谱剩余频段无法利用。很多算出来速率特别高的推导问题就出在这里。另外确认RB数之后还要顺带确认每时隙的符号数。常规循环前缀下每时隙14个符号如果配置了扩展循环前缀一个时隙只有12个符号速率会再降一截不过FR1基本都用常规CP。3.2 下行峰值计算4层256QAM的完整推导现在把100MHz、30kHz SCS、273RB这套典型配置带入完整计算。我一般会先把算式拆成四步每一步都单独算清楚避免最后数字对不上时无从排查。第一步算每秒时隙数。30kHz SCS下每个时隙0.5ms1秒有2000个时隙。第二步算每秒RE总数。273RB × 12子载波 × 14符号 × 2000时隙 91,728,000个RE。第三步算单层速率。每个RE按256QAM的8bit和LDPC码率948/1024计算单层速率为91,728,000 × 8 × 948 / 1024 ≈ 679.4Mbps。第四步乘层数和TDD折算。4层MIMO下是679.4 × 4 2.72Gbps。到这里如果直接对外宣布“下行峰值2.7Gbps”就是没考虑TDD折算的典型错误。按3GPP能力上报公式里的做法TDD场景要乘一个0.75左右的折算因子代表上下行共享同一个载波的资源损失。2.72 × 0.75 ≈ 2.04Gbps这才是和UE能力上报里常见标称值一个量级的数字。这里我把完整推导落成一个可复算的脚本方便你换参数# 5G NR 下行理论峰值估算 scs_khz 30 # 子载波间隔 30kHz slot_ms 0.5 # 30kHz SCS每个时隙0.5ms rb_num 273 # 100MHz带宽30kHz SCS对应273RB slots_per_sec 1000 / slot_ms # 每秒时隙数 2000 # 时隙内资源 subcarriers_per_rb 12 symbols_per_slot 14 # 常规循环前缀 re_per_slot rb_num * subcarriers_per_rb * symbols_per_slot qm 8 # 256QAM 每个符号8bit rmax 948 / 1024 # LDPC最大码率 0.9258 layers 4 # 终端支持的MIMO层数 tdd_factor 0.75 # TDD共享载波折算因子 tdd_dl_ratio (3*14 6) / (5*14) # DDDSU配比下行符号占比 rate_bps re_per_slot * slots_per_sec * qm * rmax * layers * tdd_factor * tdd_dl_ratio print(f考虑TDD配比后下行峰值: {rate_bps/1e9:.2f} Gbps)几个参数说明scs_khz和rb_num要按实际小区配置改比如60kHz SCS下100MHz是135RBslot_ms要改成0.25layers要查终端的UE能力不要盲目写8tdd_dl_ratio取决于现网下发的tdd-UL-DL-ConfigCommon不同时隙配比算出来的结果差异很大。这个脚本算到1.40Gbps左右属于“理论值已折掉TDD配比、但还没扣参考信号”的量级往下看就知道为什么还要再打折。3.3 上行计算要点64QAM与DFT-s-OFDM的差异上行计算和下行最大的不同在于调制阶数和波形。NR上行虽然协议上支持CP-OFDM和DFT-s-OFDM两种波形但FR1现网终端普遍使用DFT-s-OFDM来降低峰均比而DFT-s-OFDM在Rel-15/16里通常只支持到64QAM。就算终端能力里上报了上行256QAM实际调度器在覆盖边缘或功率受限场景下也会降阶。拿同样100MHz、30kHz SCS的配置算一次上行每秒RE总数还是91,728,000个不变。调制阶数改成64QAM的6bit码率还是948/1024单层速率就是91,728,000 × 6 × 948 / 1024 ≈ 509.5Mbps。乘2层MIMO得到1.02Gbps再乘TDD上行方向的时隙占比。上行时隙占比取决于配比。如果沿用刚才DDDSU配比5ms内上行符号只有(44)个占比约11.4%那么上行理论峰值大约116Mbps这个数字偏保守如果用7D:2U:1S这种上行占比高一些的配比上行符号占比接近25%就能到250Mbps以上。所以上行速率算出来低不要先怀疑公式先看看时隙配比给上行分配了多少时间。这里还有一个容易被忽略的点上行MIMO层数。终端上行发射通常只有2个发射通道4层上行MIMO只是协议理想值实际几乎不存在。我一般算上行直接用1到2层取2层都已经算乐观了。4. 从理论到现网时隙配比、参考信号开销与终端能力的三个台阶4.1 TDD时隙配比把理论值打了折算完第3章你手里的数字是“折叠了TDD共享损耗、但还没扣调度开销”的理想值。可是现网测速看着手机信号满格下载速率却始终上不去原因往往就在时隙配比这一步。TDD配比不是固定的。3.5GHz频段上不同设备商、不同运营商可能用不同的帧结构常见的有DDDSU、DSUDD、DDDDU等。以DDDSU为例5ms周期内3个下行时隙、1个上行时隙、1个特殊时隙特殊时隙内部还有下行符号、上行符号和保护间隔。保护间隔GP不能传数据纯粹是下行转上行的“刹车距离”。我见过一个现场排查案例某开发者A同学在测试终端上看到下行速率只有理论值的60%查来查去发现现场实际下发的时隙配比是DSUDD5ms里下行只有2个完整时隙加1个特殊时隙下行符号占比掉到50%以下。他在后台看到的理论值表格是按DDDSU配比算的两个配比差了快20个百分点速率对不上是必然的。所以拿到一个新站点的速率预期第一件事是去查tdd-UL-DL-ConfigCommon里实际配置的时隙数而不是拿一个通用配比套到底。速率计算表的参数里这个值必须来自现场不是来自PPT。4.2 SSB、CSI-RS、DMRS的开销怎么扣时隙配比折完还有参考信号开销这一刀。NR不像LTE那样每个子帧都有满配的参考信号但SSB同步信号块、CSI-RS信道状态信息参考信号、DMRS解调参考信号和PDCCH这些控制资源仍然要占掉一部分时频资源不能传输业务数据。开销占比取决于具体配置。SSB在100MHz带宽下占约2%到3%CSI-RS按测量配置不同约2%到4%DMRS在前置符号加额外符号的配置下约4%到6%PDCCH占用前1到2个符号约3%到5%。粗算下来控制开销合计在10%到15%之间。这里要强调的是参考信号开销不是一个固定值。比如DMRS如果调度器开了额外前置DMRS或者为了对抗高速移动加配了额外DMRS符号开销会明显上升。CSI-RS如果配置了周期10ms的4端口测量开销又和周期5ms的8端口完全不同。严格的做法是从RRC配置里把实际启用的参考信号资源数拉出来逐项统计工程上为了快我一般按12%的整账抵扣算完心里有数就行。从第3章的1.40Gbps往下扣1.40 × (1 - 12%) ≈ 1.23Gbps。这个数字和现网单载波100MHz TDD小区在好信道条件下的实测峰值基本在一个量级可以作为参考基准。4.3 终端能力与网络配置共同决定最终峰值算到最后峰值速率并不是网络单方面决定的终端能力是另一块天花板。一个只支持2层MIMO、64QAM下行调制的手机放到8层256QAM的小区里速率上限也只有网侧理论值的四分之一。查终端能力需要看几个关键字段我用表格列一下常用参数和检查方向能力字段典型值对速率的影响maxMIMO-Layers4层数直接乘算2层只有4层的一半supportedModulationOrderDL256QAM降到64QAM后单RE速率下降约25%supportedModulationOrderUL64QAM上行调制常被限制scs-SpecificCarrierList30kHzSCS决定每秒时隙数maxNumberMIMO-LayersCB-PUSCH2上行MIMO层数上限除了UE能力调度器本身的策略也在起作用。小区里用户多了同样的时隙资源要分给多个人信道质量差MCS会降阶调度器没有足够数据积压时即使能力允许也不会满配传输。这些都是理论速率之外的“现实折扣”。但反过来说如果单用户、空载、好信道条件下实测始终达不到理论值的70%那就得回头看配置了。不是SCS配错就是时隙配比和预期不符要么就是参考信号开销超了常规值。这也是我坚持先笔算一遍理论值的原因没有基准线现场连“正常还是异常”都判断不了。5. 速率计算翻车现场5个常见误差与排查方法5.1 现象100MHz带宽套15kHz SCSRB数对不上某个项目里有人拿100MHz带宽直接除以15kHz再除以12算出555个RB换算出来的下行速率高达5Gbps以上明显偏离常识。原因很简单NR的RB数不是纯数学推导而是协议定义的。38.104协议表里100MHz带宽对应的SCS取值只有30kHz和60kHz两档15kHz SCS在这个带宽上根本不支持。解决方法是查协议表格按带宽和SCS配对取RB数。100MHz带宽、30kHz SCS取273RB15kHz SCS最多只能配到50MHz带宽、270RB。算速率之前先花30秒把RB数确认了能省掉后续一整轮排查。5.2 现象编码效率取0.85结果比官方标称低一截有人习惯沿用LTE时代的编码效率取值把Rmax填成0.85或者0.93算出来的速率比终端能力上报值低不少。NR的LDPC码在最高MCS档位下实际使用的码率是948/1024等于0.9258这个值在协议里有明确出处。调制阶数、码率这两项乘起来差几个百分点放到100MHz满带宽上就是每秒百兆比特的差距。我现在的习惯是直接把948/1024写进计算脚本的常量里不用小数近似避免中间精度损失。遇到厂商上报的理论峰值低于你的计算结果时先检查是不是码率用了不同的档位。5.3 现象TDD配比被忽略算出“全下行”的数字最典型的翻车就是把TDD小区当成FDD来算。FDD上下行各占一个载波下行可以从早到晚独占全部时频资源TDD不一样同一个载波分时复用下行最多只能占到70%左右的时间。原因有两层一是公式里忘了TDD的0.75折算因子这是UE能力上报层面的损耗二是时隙配比没乘DDDSU和DSUDD两种配比算出来的下行速率能差20%以上。解决方式是先确认小区是TDD还是FDDTDD就两步折算都做先乘折算因子再乘实际时隙配比。现网FR1主流频段基本都是TDD这一步省不掉。5.4 现象参考信号开销只扣了SSB忘了CSI-RS和DMRS有人扣开销时只想着SSB大约2%把这部分减掉就觉得算完了。实际上一看RRC配置CSI-RS周期10ms配了多个资源集DMRS又是双符号配置PDCCH还占了前2个符号控制面总开销轻松超过12%。原因是把“同步信号”和“全部控制开销”混为一谈了。SSB只是同步和解码的门面CSI-RS负责信道测量、DMRS负责数据解调PDCCH负责调度指令每一部分都有自己的时频占用。我建议在Excel或脚本里把SSB、CSI-RS、DMRS、PDCCH四行分开列每项按实际配置估算最后汇总。这样即使某项配置变了也能单独调整不会因为一个总比例数字误导后续决策。5.5 现象上行用CP-OFDM参数算DFT-s-OFDM速率上行速率容易出现“虚高”的计算结果原因多半是拿下行的思路套上行上行也按256QAM、也按4层MIMO算。现网里上行普遍用DFT-s-OFDM波形这个波形在FR1的典型终端能力下只支持到64QAM最大层数一般也就2层。按64QAM和2层算出来的上行理论值通常只有同等带宽下行的三分之一到四分之一这才是和实测对得上的量级。排查时先查UE能力里的上行调制阶数和上行MIMO层数再确认波形配置。如果终端上报的是CP-OFDM且支持上行256QAM那按高阶算也没错但这类终端在现网占比很低别拿特殊能力当普遍值。6. 理论速率落地用灌包实测反查配置的验证习惯6.1 建一张关键参数速查表计算这事重复几遍之后我手上一直留着一张速查表每次开新站点先对一遍参数再动手参数数值说明30kHz SCS时隙时长0.5ms每秒2000时隙100MHz30kHz RB数273查38.104协议表100MHz60kHz RB数135高频段可能用到256QAM每符号8bit下行最高调制64QAM每符号6bit上行典型调制LDPC最大码率948/1024Rmax固定值TDD折算因子0.75能力上报公式用这张表的作用是让计算有统一的起点不至于今天用0.85码率、明天用0.93算出来的数字缺乏可比性。6.2 用实测峰值反查配置的四步法理论值算完不是终点拿它和现场实测对表才是关键。我习惯按四步走第一步从后台取小区实际的下行MCS、层数、RB调度数以及时隙配比参数。第二步按这些实际参数算一遍理论峰值注意这里用的是实际调度到的层数和RB数不是配置上限。第三步用灌包工具在单用户空载场景下发满数据取物理层的峰值吞吐最好连续测3次取平均值排除调度波动。第四步把实测值除以理论值得到一个效率系数。超过85%说明系统工作正常低于70%就逐个环节排查先看MCS有没有降阶再检查DMRS和PDCCH额外开销最后确认时隙配比是否被改动过。这里有个小教训曾经有个小区速率连续一周不达标所有人都去调天线和功率最后发现是后台把特殊时隙的保护间隔从4个符号改成了8个符号下行符号少了一截。如果不先算理论值、不对实际调度参数这种问题靠肉眼很难发现。6.3 进阶256QAM依赖SINR链路预算要一起看理论速率还要和链路预算联动着看。256QAM对SINR的要求很高大致需要27dB以上的解调门限一旦低于这个值调制阶数就会自动降到64QAM甚至16QAM速率直接少一截。所以现场如果看到“信号满格但速率不高”先别怀疑计算错误去看看SINR。RSRP高不代表SINR高干扰严重的时候调制阶数根本抬不上去物理层再怎么算都是纸上谈兵。我现在拿到一个站的速率问题习惯顺序是先算理论值建立基准再拉实际调度参数对比最后看SINR决定是否值得投入调天线。三件事做完90%的速率“玄学故障”都能定位到具体原因而不是在误测和配置之间来回拉扯。希望这招对你有用。本文还有配套的精品资源点击获取