5G NR吞吐量理论计算：从峰值公式到工程估算的完整指南

简介：一份面向5G无线网络优化、通信工程学习与设备研发人员的5G NR峰值速率计算解析文档。内容基于3GPP TS 38.913与TS 38.101-1协议，系统梳理OFDM向F-OFDM演进、更高阶调制与更大带宽对速率的影响，并以Sub-6GHz频段100MHz带宽、30kHz子载波间隔、273PRB为典型配置，逐步推导上下行理论峰值速率。文档同时对比2.5ms双周期与5ms单周期帧结构，说明PDCCH、DMRS等开销扣除方式，以及64QAM、256QAM和不同MIMO流数下的速率计算逻辑，便于读者掌握5G NR吞吐量估算方法。资源为单个PDF文档，压缩包大小约1.06MB，内容紧凑、公式与参数表配套完整，适合作为日常查询和培训参考。目前已有1604人学习使用。

1. 5G NR吞吐量理论计算：一个PDF标题背后的三句话真相

一份名为《5G NR吞吐量理论计算.pdf》的资料，落到网优工程师手里通常不是用来收藏的，而是用来对数的。白天拉网测试，路测软件上报峰值速率1.72Gbps，自己按公式一算却是2.0Gbps，差出来的300Mbps消失在哪个环节？这就是5G NR吞吐量理论计算要解决的事。它做的事情只有一件：在发牌之前先把物理层的账算明白——配置多少带宽、用哪种子载波间隔、TDD还是FDD、几层MIMO，理论上最多能搬多少数据。适合正在写测试报告、做容量规划或者跟厂商对峰值参数的人。读完你会得到一套能直接填数的估算方法和一排踩过才知道的坑。

2. 吞吐量计算底层：峰值速率公式与TBS查表两条路线的取舍

拿到一个吞吐量理论计算任务，我习惯先问一句：你要算的是“宣传口径的峰值”，还是“特定调度配置下能落地的速率”？这两个答案对应两种完全不同的算法路径，混在一起用最容易翻车。

2.1 先定框架：TDD和FDD的调度窗口不一样

第一步不是拿公式，而是定双工方式。FDD上下行各占一个载波，DL吞吐量可以直接按整帧计算；TDD上下行共享同一个载波，下行能用的时间窗口被帧结构切成了一段一段。同样是100MHz带宽，FDD下行可以一直占用，TDD下行可能只占到70%~80%的时隙资源。

我见过不少估算把TDD和FDD混成一套参数，算出来数字高得离谱。实际做容量规划的时候，必须先确认帧结构模式。常见的TDD帧结构DDDSU，2.5ms周期里3个纯下行时隙、1个上行时隙、1个特殊时隙，特殊时隙里还有一部分下行符号。折算下来下行占空比大概在75%~80%之间，这个值叫DL slot ratio，是后面所有计算必须乘的系数。

2.2 五个必填参数：RB数、SCS、调制阶数、码率、层数

理论吞吐量不是从空里冒出来的，它有五根柱子，每个参数直接乘进结果里，少一个就算不出来。

RB数可以从38.101-1的载波带宽表里查，不需要自己推。100MHz配30kHz子载波间隔是273个RB，这个数字必须记牢；20MHz配15kHz是106个RB，室内小站常用。SCS定的是时间维度，30kHz下每个时隙是0.5ms，1秒有2000个时隙；15kHz下每个时隙1ms，1秒只有1000个。调制阶数和码率则由调度器根据信道质量决定。

这里特别提醒：调制阶数和码率不是随便填的，它们绑定在MCS表里。5G NR的MCS表格在38.214的表5.1.3.1-2里维护，MCS 28附近对应256QAM，目标码率约0.926。查表比背数值可靠，协议版本更新时MCS表可能调整，参数填错后面整套测算就失真了。

2.3 选公式还是选查表：两条计算路径的取舍

公式派的做法是套38.306峰值速率公式。简化之后长这样：

峰值速率 = 层数 × 调制阶数 × 码率最大值 × RB数 × 12 × (1 - 开销) / 符号时长

查表派的做法则更贴近调度器真实行为：先确定MCS和RB数，从TBS表中查到每个时隙能传输块的大小，再乘以每秒可用时隙数。两条路线各有适用场景。

我日常的偏好是：给领导汇报峰值用公式，给优化建议用查表法。两者不应该差太远，如果差了10%以上，说明某个参数或开销因子选得不合理，需要回头检查。

3. 从理论峰值到真实估算：设备开销与TDD占空比的修正

大多数人算吞吐量的第一个版本都会偏高，问题通常出在只算了“物理层毛速率”，没扣掉参考信号、控制信道和TDD调度留白。这些扣减项在协议里有一个统一的名字：开销（overhead）。

3.1 开销因子不是玄学：DMRS、CSI-RS、SSB各占多少

5G的下行不是每个RE都拿来搬用户数据。每个时隙里，DMRS要占一部分RE用于信道估计，CSI-RS要周期性发送用于信道测量，SSB同步信号块要占固定位置，PDCCH控制信道还要吃掉最前面的符号。

这些开销各自分摊下来并不是小数目。一个典型的FR1载波上，SSB在20ms窗口内占去一小部分资源，PDCCH如果配置2个符号，那在每个时隙里直接损失约14%的符号资源，DMRS按1个符号前置加载又占一部分。把它们全部折算进去，物理层平均开销通常在14%左右。38.306峰值速率公式里直接给了OH = 0.14这个因子，做FR1估算时可以直接复用。

但要注意，0.14是平均值，不是绝对值。如果PDCCH配了3个符号，或者DMRS用了额外的前置载波，实际开销会超过0.14；反之控制信道压缩到极致，开销会略低。做精细化测算时，我会把开销拆成两部分：固定开销（SSB、CSI-RS）和可变开销（PDCCH符号数、DMRS密度），再按具体参数修正。

3.2 TDD上下行时隙比例怎么折算进单向速率

开销扣完之后还有一道坎：TDD占空比。FDD没有这个问题，TDD必须把整帧里的上行时隙和特殊时隙剔除，只留下行时隙算下行吞吐。

折算公式不是一个乘0.8就完事。特殊时隙S的结构需要细看：S时隙里的DwPTS（下行部分）是可以传数据的，UpPTS和GP（保护间隔）不能传。所以正确的做法是把一个帧结构周期里的所有下行符号数加起来，除以周期内的总符号数。

举个例子，DDDSU帧结构下，一个2.5ms周期包含5个时隙，其中3个纯下行时隙各14个符号，1个特殊时隙按DwPTS配置可能有10~12个下行符号，1个纯上行时隙0个下行符号。下行占空比大约是：

(3×14 + 11) / (5×14) ≈ 73%

直接用0.8会略乐观，用0.7又过于悲观。脚本算式里我一般让使用者直接输入DL时隙占比这个参数，默认给0.8，但注释里写明：精确值按帧结构周期内的下行OFDM符号数重新折算。

3.3 协议里0.14的OH因子用在哪类场景

0.14这个数值本身有它的适用边界。它出自峰值速率公式，用于估算“这个小区最多能跑多少”，不是用来预测用户实际体验。现网真实速率通常比这个理论值低20%~40%，因为还有调度器实现效率、HARQ重传、TCP行为、多用户竞争等因素。

所以我建议把计算分成两个层次：

• 理论峰值：用38.306公式，OH=0.14，层数和调制取最大能力，不考虑TDD占空比里的调度间隙。这个值叫标称峰值。
• 工程估值：在标称峰值基础上乘TDD下行占空比，再把OH从0.14调整到实际配置，比如PDCCH多一个符号就加到0.18。这个值用于跟实测对比。

如果两份报告用同一个词叫“理论吞吐量”，但一个扣了TDD占空比一个没扣，数字能差出30%。我们在评审时经常为这个争论，所以落笔前一定要写清楚有没有包含占空比折算。

4. 把计算脚本跑在本地：Python算例与参数表

理论框架立住之后，真正有用的是一段能改参数就能出结果的脚本。我习惯于把常用带宽和SCS的RB数映射做成一张表，再用简单算术算出单用户峰值速率。下面这套方法不需要装任何通信库，Python标准库就够。

4.1 最小参数表：100MHz带宽在不同SCS下的RB数

先做输入准备。不同带宽配不同子载波间隔，RB数不是一个固定百分比缩放，必须查表。

这套数值来自38.101-1的载波RB表，做理论计算时直接引用即可。注意100MHz在FR1不配15kHz，因为保护带占比会过大，这也是常见的一个认知盲区。

4.2 用Python脚本计算理论吞吐量

下面这段脚本的思路是：先算单时隙的比特数，再乘每秒有效时隙数，最后扣TDD占空比和物理层开销。代码尽量短，方便在测试电脑上直接跑。

# nr_throughput_calc.py # 5G NR 下行理论吞吐量估算脚本（工程简化版） def rb_by_bw_scs(bw_mhz, scs_khz): # 常见配置的RB数查找表，完整表见 38.101-1 mapping = { (10, 15): 52, (10, 30): 24, (20, 15): 106, (20, 30): 51, (50, 15): 270, (50, 30): 133, (100, 30): 273, (100, 60): 135, } return mapping.get((bw_mhz, scs_khz)) def nr_dl_peak_rate(bw_mhz=100, scs_khz=30, layers=4, mod_order=8, code_rate=0.926, dl_slot_ratio=0.8, oh=0.14): """ bw_mhz: 载波带宽 scs_khz: 子载波间隔 layers: MIMO层数 mod_order: 调制阶数，256QAM为8 code_rate: 目标码率，MCS28约0.926 dl_slot_ratio: TDD下行时隙占比，FDD设为1.0 oh: 物理层开销因子，FR1典型值0.14 """ rb_num = rb_by_bw_scs(bw_mhz, scs_khz) if rb_num is None: raise ValueError("未找到该带宽与SCS组合，请查38.101-1") # 每RB每时隙的RE数 = 12子载波 * 14符号 re_per_rb_slot = 12 * 14 # 单时隙可承载的信息比特 = RE数 * 层数 * 调制阶数 * 码率 bits_per_slot = rb_num * re_per_rb_slot * layers * mod_order * code_rate # 每秒时隙数：30kHz SCS下时隙长0.5ms，每秒2000个时隙 slots_per_sec = 1000 * (scs_khz / 15) # 每秒总比特 = 单时隙比特 * 每秒时隙数 * TDD下行占比 * (1-开销) rate_bps = bits_per_slot * slots_per_sec * dl_slot_ratio * (1 - oh) return rate_bps / 1e9 # 单位 Gbps if __name__ == "__main__": rate = nr_dl_peak_rate() print(f"理论DL吞吐量: {rate:.2f} Gbps")

代码逻辑可以拆成三层看。第一层rb_by_bw_scs是频域资源的锚点，查不到组合就报错，避免带宽和SCS错配导致数字虚高。第二层bits_per_slot算的是一个时隙里最多能放多少信息比特，RB数乘168个RE，再乘每RE的比特数，这是纯物理层上限。第三层用每秒时隙数把单时隙结果延展到1秒，同时把TDD占空比和协议开销一起扣掉。

参数调整的要点主要在两处：如果算FDD，dl_slot_ratio设成1.0，因为上下行独立载波；如果做的是上行估算，mod_order和layers要按UE能力降低，比如普通手机上行通常只有1~2层，调制碰不到256QAM的高MCS。

跑上面这段默认参数，输出约1.87Gbps。这个数跟厂商标称的“100MHz 4层256QAM理论峰值2Gbps左右”基本在同一量级，差异来自我们扣掉了TDD占空比和14%开销。如果只想对比峰值公式，把dl_slot_ratio改成1.0、oh改成0.0，就会得到约2.17Gbps，这时候对照38.306公式才能对上。

4.3 脚本参数怎么调：从100MHz到20MHz的缩放规律

很多人拿到脚本会问：改成20MHz小区怎么调？最稳妥的做法是改bw_mhz=20同时查表选scs_khz=15，20MHz在15kHz下有106个RB，比100MHz的273个RB直接少六成。如果硬把SCS也改成30kHz，20MHz只有51个RB，速率进一步打折。

带宽缩放之外的第二个关键调整项是层数。单用户峰值按UE能力写，中端手机下行通常只支持2层，旗舰机支持4层。把layers从4改成2，吞吐直接减半。第三个要调的参数是MCS，现网弱覆盖区域调制阶数经常掉到64QAM以下，mod_order改6、code_rate改0.75，速率会再少三成以上。实际做容量规划时，这三项一改，结果就能从2Gbps落到600Mbps量级，反而更贴近真实体验。

5. 吞吐量计算避坑指南：四类常见翻车现场

参数表填错了可以快速发现，真正难查的是“看起来没错、结果偏得离谱”的坑。下面是这四类问题里最常见的现场。

5.1 同一个带宽、不同的SCS，RB数不能用同一张表

现象：把100MHz/30kHz的273个RB，直接套到100MHz/60kHz的配置里算，结果速率虚高。原因：SCS越大，保护带占用的频域比例越高，可用RB数不是线性等比。100MHz在60kHz下只有135个RB，比30kHz的273少了一半。解决方法：RB数一律按“带宽+SCS”双条件查38.101-1表，绝不用单一带宽值推算。

5.2 理论峰值公式里的OH被重复扣除

现象：脚本里已经设了oh=0.14，又在算RE数时手动扣掉DMRS和PDCCH符号，结果比真实理论值低了20%。原因：0.14已经是物理层平均开销的综合估值，里面包含了参考信号和控制信道的折损；再做一次符号扣除等于重复计费。解决：用峰值公式时，RE数按每时隙12×14全量算，开销统一走OH因子；做精细调度模拟时，才需要显式扣除符号。

5.3 TDD按整帧平均估算，把DL算成DL/UL平均

现象：TDD 100MHz小区算出来只有0.9Gbps，但厂商资料写的是2Gbps。原因：有人把下行时隙数除以总时隙数算平均值，相当于把上行时隙也摊进了下行结果。解决：下行单向速率只看下行时隙和特殊时隙的下行符号，不要除以总时隙数。公式里dl_slot_ratio只反映下行占空比，不是帧结构的50%均分。

5.4 UE层数和小区层数混为一谈

现象：小区面板支持8层，但现场手机只支持2层，实测速度和理论值差出4倍。原因：峰值速率公式里的层数v指的是单用户的接收层数，不是小区的最大发射层数。小区层数是多用户共用能力，单用户理论计算必须按终端能力写。解决：算单用户峰值时，先查UE能力里的maxNumberMIMO-LayersPDSCH字段，FR1常见是2层或4层。

6. 验证吞吐量计算结果的三个技巧：向现网数据要答案

理论计算正确与否，最终要拿现网数据检验。这里分享三个我在测试现场常用的验证方法。

第一个技巧是反向对照路测日志。路测软件里一般会记录PDSCH分配的PRB数和调度MCS，把日志里“每毫秒调度的TBS”累加，1秒总比特数就是实际物理层吞吐。拿这个值除以理论峰值，能算出调度效率和资源利用率。理论值如果是2.0Gbps，实测物理层1.6Gbps，说明调度器在MCS选择上还有余量，优先查CQI上报和干扰。

第二个技巧是利用网管统计里的“平均调度PRB数”和“平均MCS”反推瓶颈。如果平均PRB只用了60%但用户速率已经上不去，说明瓶颈在时域调度或CA载波聚合配置，而不是带宽不够。这个判断用脚本反向算一遍，比单纯看速率曲线直观得多。

第三个技巧是给结果留安全边际。我习惯在报告里写两个数：理论峰值和工程估值。工程估值用TDD占空比扣完、OH按实际配置修正、层数按主流UE填写，确保测试时能跑到九成。理论峰值只用来跟厂商对齐能力上限，不进入优化目标。

每次算完吞吐量，我都会做一遍自检：带宽、SCS、RB数有没有查表；层数是UE能力还是小区能力；TDD有没有乘占空比；OH有没有扣两遍。这四个问题过完，数字基本就站得住脚了。希望帮到你。

本文还有配套的精品资源，点击获取