5G NR理论峰值速率计算：从帧结构到FDD/TDD参数详解

简介一份面向通信初学者与从业者的5G NR理论速率计算详解PPT围绕FDD与TDD两种双工模式系统讲解子载波间隔、帧结构、调制编码、mMIMO、载波聚合及资源开销等关键因素并给出多个典型配置下的完整计算实例让小白也能逐步推导出2.3Gbps等峰值速率结果。整套资料共1个pptx文件压缩包仅817KB内容组织紧凑适合移动通信课程学习、网优入门或面试复习快速参考。已有2519人浏览学习。通过该PPT读者不仅能理解速率公式每个数字背后的物理含义还可掌握不同时隙配比下TDD上下行速率的变化规律是一份兼顾原理与实战手算的简明速成材料。1. 5G NR理论速率计算一张公式背后是「一秒钟塞进多少bit」刚接触NR的人拿到这份速率计算资料时多半会被帧结构图劝退五种子载波间隔、时隙、半帧、符号级调度每个概念单独看都眼熟连起来就是黑匣子。其实整份资料的核心只有一句话——把一秒内能承载的有效bit算清楚。FDD下行2.3Gbps、TDD在DDDSU配比下的1.7Gbps全是「每秒数据符号数 × 每符号bit数」的展开。这份资料从LTE的15kHz单一子载波讲到NR的五种子载波间隔用四个FDD/TDD案例把调制阶数、编码效率、开销、MIMO层数逐个代入公式。适合刚进协议测试的新人也适合要给现网峰值速率做验算的从业者。把每个乘数对应的物理资源对上号以后看到任何一份速率报告上的数值你都能自己验一遍。2. NR物理层参数五种子载波间隔、帧结构与符号级调度速率公式的第一个乘数来自物理层参数子载波间隔抄错一位后面所有数字都跟着错。这一章把公式背后涉及的时间和频率结构先摆出来后面的计算才有参照系。2.1 子载波间隔为什么NR要提供五种而不是一种LTE只有15kHz一种子载波间隔NR把选择空间扩到15、30、60、120、240kHz五种。子载波间隔直接决定OFDM符号时长间隔越宽符号越短时隙也越短。常规CP下每个时隙固定14个OFDM符号符号时长与SCS成反比时隙长度也由SCS唯一确定。子载波间隔常规CP下时隙长度每子帧时隙数15kHz1ms130kHz0.5ms260kHz0.25ms4120kHz0.125ms8240kHz0.0625ms16这张表是速率公式里的时间轴。同样是1ms子帧SCS取30kHz时有2个时隙取15kHz时只有1个直接决定了公式里写「14×2」还是「14×1」。60kHz以上在FR1里很少直接用多数是配合大带宽或特定场景240kHz那行基本属于毫米波频段符号极短覆盖半径也小。选型逻辑也不玄学15kHz符号太长对多径时延太敏感30kHz是覆盖和符号长度的折中毫米波用高SCS则是为了对抗相位噪声。2.2 帧、子帧、半帧、时隙与符号的层级关系NR的时间结构是一个无线帧10ms分成10个子帧每个子帧1ms。帧还分成两个半帧编号#0和#1#0半帧含子帧#0~#4#1半帧含子帧#5~#9。子帧再往下切时隙时隙个数又回到SCS那张表——15kHz时1个子帧就是1个时隙30kHz时1个子帧有2个时隙以此类推。每个时隙固定14个OFDM符号常规CP这一点LTE和NR一致。区别在于NR的上下行资源分配已经细化到符号级别。LTE的上下行配比按子帧定义一个子帧要么上行要么下行NR可以在一个时隙内部混排D、U、S三种符号TDD配比设计因此灵活得多。后面计算TDD速率时「某个周期里到底有多少个符号属于下行、多少个属于上行」就完全依赖这一层理解。2.3 调度粒度从子帧到符号NR比LTE多出的自由度LTE算理论峰值有个简单套路子帧数×每个子帧的时隙数×每个时隙符号数再乘上各层效率。NR多了一步——先确认SCS再确认一个周期内哪些符号真的在传数据。一个时隙有14个符号不代表14个都能给你传PUSCH或PDSCHTDD下还要扣掉特殊子帧里的GP和不在自己方向的符号。处理这类问题时我一般会先把符号轴画出来。比如「DDDSU」这个配比先画出5个时隙再标出D、S、U各自位置最后把S时隙展开成DwPTS、GP、UpPTS三段。这一步做完公式里的符号数才不会抄错。资料里几种TDD配比的计算差异本质都是在数这几个符号。3. FDD速率计算从公式到2.3Gbps与937MbpsFDD上下行用不同频段各自独享带宽所以计算时只需把下行和上行分别当作独立链路处理不涉及时隙占空比。资料里FDD下行算出来2,337,552,322.56bit/s约2.3Gbps上行937,739,013.12bit/s约937Mbps。差距主要来自MIMO层数、调制阶数和开销三项。3.1 调制阶数、编码效率与开销三个乘数分别代表什么调制方式决定一个符号能扛多少bit。资料里给了四档对照QPSK调制阶数216QAM是464QAM是6256QAM是8。下行按256QAM取8上行按64QAM取6这两个数字分别对应FDD公式里的第二个乘数。编码效率0.926是协议38.306里的典型值含义是信道编码之后有效信息bit占编码总bit的92.6%其余是校验和冗余。这是一个理想配置下的参考值实际调度中MCS变化编码效率也会跟着变不像调制阶数那样固定。开销占比OH(j)是另一个容易看漏的项。资料给出的口径是下行0.14、上行0.08。这0.14对应PDCCH、CSI-RS、SSB和一些公共信道的占用0.08对应DMRS、SRS、PUCCH一类开销。公式里的(1-0.14)和(1-0.08)就是扣除这些参考信号后真正能传数据的比例。上下行开销不一样是因为上行控制信道和参考信号密度相对低一些。3.2 100MHz带宽为什么取273个RB公式里的273×12需要分开看273是100MHz带宽、30kHz子载波间隔下的最大传输RB数来自协议表12是每个RB包含的子载波数标准固定。两者相乘得到3276个数据子载波。这个数字跟调制方式无关只由带宽和SCS决定换到15kHz SCS同一带宽可用的RB数会更多但时隙数减半综合速率未必占优。资料只给了100MHz/30kHz这组配置实际项目中如果遇到60MHz或80MHz带宽RB数也要对应查表不能拿273硬套。我通常会先确认目标带宽和SCS组合对应的RB数再代入公式避免后面整个数量级出错。3.3 FDD公式逐项拆解与Python验算FDD下行公式拆开看是这样的Rate 4 × 8 × 0.926 × 273 × 12 × (1-0.14) × 14 × 2 × 1000对应关系依次为4是4×4 MIMO层数8是256QAM调制阶数0.926是编码效率273×12是总子载波数(1-0.14)是扣除下行开销后的净占比14×2是30kHz SCS下1个子帧内2个时隙共28个符号1000是每秒1000个子帧。FDD上行则是2×6×0.926×273×12×(1-0.08)×14×2×1000层数按2层、调制阶数按6开销按0.08。资料注释里把上行MIMO写成了4×4属于笔误实际取2层才是937Mbps这个结果。def fdd_rate(layers, mod_order, oh, rb_count273, scs30): layers: MIMO层数下行4x4取4上行2x2取2 mod_order: 调制阶数256QAM取864QAM取6 oh: 开销占比下行0.14上行0.08 rb_count: 100MHz/30kHz下取273 scs: 子载波间隔30kHz时每子帧2个时隙 subcarriers rb_count * 12 symbols_per_subframe 14 * (scs // 15) # 30kHz - 2个时隙 x 14符号 return (layers * mod_order * 0.926 * subcarriers * (1 - oh) * symbols_per_subframe * 1000) print(fFDD下行: {fdd_rate(4, 8, 0.14) / 1e9:.2f} Gbps) print(fFDD上行: {fdd_rate(2, 6, 0.08) / 1e9:.3f} Gbps)输出为2.34Gbps和0.938Gbps与资料结果一致。函数里把SCS换算成每子帧时隙数30kHz时取215kHz时取1换带宽时只需改rb_count。实际使用时我会把rb_count单独抽出来这样60MHz、80MHz这类非标配置也能直接算。4. TDD速率计算三类时隙配比的公式与数字验证TDD上下行共用同一段频谱计算逻辑和FDD完全不同——不是每秒都有16个时隙给你传下行得先算清一个周期内属于下行的有效符号数再乘每秒周期数。4.1 TDD公式与FDD的差异周期、周期数与特殊子帧FDD公式里那个×1000表示每秒1000个子帧TDD不能这么直接乘因为上下行在时间上被切开了。TDD的通用写法是速率 层数 × 调制阶数 × 编码效率 × 子载波数 × (1-开销) × 每周期有效符号数 × 每秒周期数关键在于两个参数周期时长和每秒周期数。2.5ms周期对应每秒400次循环5ms周期对应每秒200次循环。资料里的「2.5ms双周期DDDSU DDSUU」稍微绕一点——它是由两个2.5ms的时隙块拼成一个5ms完整循环每秒其实只循环200次不是400次。这个点容易把周期和周期数搞混后面避坑章会专门说。特殊子帧配比也要先弄清楚。10:2:2分别是DwPTS下行导频时隙10个符号、GP保护间隔2个符号、UpPTS上行导频时隙2个符号。6:4:4同理是6、4、4。计算下行速率时只把DwPTS符号计入下行计算上行速率时只把UpPTS计入上行GP两端的符号都不参与数据承载。4.2 三种配比的符号数与最终结果资料给了三组TDD场景分别是2.5ms单周期DDDSU、2.5ms双周期DDDSU DDSUU、5ms单周期DDDDDDDSUU。把有效符号数先列成表再逐一代入公式。时隙配比周期每秒周期数特殊子帧配比每周期下行符号每周期上行符号DDDSU2.5ms40010:2:214×310×15214×12×116DDDSU DDSUU5ms20010:2:214×510×29014×32×246DDDDDDDSUU5ms2006:4:414×76×110414×24×132TDD下行公式代入Rate_dl 4 × 8 × 0.926 × 273 × 12 × (1-0.14) × 52 × 400 1,736,467,439.61bit/s ≈ 1.7Gbps上行公式代入Rate_ul 2 × 6 × 0.926 × 273 × 12 × (1-0.08) × 16 × 400 214,340,345.856bit/s ≈ 214Mbps双周期和5ms单周期的代入方式完全一样只是符号数和周期数不同。资料里5ms单周期DDDDDDDSUU的下行算出来也是1.7Gbps上行同样是214Mbps仔细看是「每周期下行有效符号数×每秒周期数」与DDDSU场景恰好相等104×20052×40020800符号/秒所以速率相同。遇到这种数字相等的场景核对符号总数就能快速自检。4.3 特殊子帧里的上行符号怎么数上行公式里最容易数错的是特殊子帧。以DDDSU配比为例上行有效符号数是14×12×116前面14×1来自U时隙的14个符号后面2×1来自UpPTS的2个符号。特殊子帧配比是10:2:2UpPTS只有2个符号能承载上行数据GP的2个符号虽然也在S时隙里但既不传下行也不传上行直接忽略。5ms单周期配比6:4:4时上行有效符号是14×24×132普通U时隙2个共28符号加上UpPTS的4符号。如果你的特殊子帧配比改成10:2:2那么UpPTS就只贡献2个符号。这里没有固定的「上行加2」的说法一切取决于特殊子帧第三个数字。手机上看到的实时速率是基站按当前信道质量、实际调度RB数和终端能力实时算出来的不是公式里全配置拉满的理想值。理论峰值只用于估算系统上限实际路测往往只有它的五六成。做对比时一定要确保两边的配比、带宽、调制方式处于同一口径否则数字对不上。5. TDD计算避坑五个高频翻车点的排查记录TDD计算的翻车点比FDD多得多因为一次引入了时隙配比、特殊子帧、周期时长三个变量。下面五条都是实际验算中遇到过的高频问题按现象、原因、解决的顺序记录拿来就能对照排查。5.1 特殊子帧配比读错把DwPTS当普通时隙用现象按DDDSU算下行时特殊子帧的10个符号被当成普通时隙的14个符号处理算出来约2.1Gbps比资料的1.7Gbps高出一截。原因特殊子帧里的DwPTS只占前10个符号不是完整的14个符号。把10:2:2里的「10」误当成整个时隙的下行符号数等于把一个时隙的下行能力多算了4个符号。解决先在纸上画出S时隙展开图——10个DwPTS、2个GP、2个UpPTS再只取DwPTS计入下行符号。同理计算上行时只取UpPTSGP永远不参与数据承载。5.2 周期与每秒周期数没对齐双周期算出一倍偏差现象把「2.5ms双周期DDDSU DDSUU」当成每秒400个周期来算下行直接翻倍到3.0Gbps。原因这个配比名称里的「2.5ms」指的是单个时隙块的长度完整循环是DDDSU拼接DDSUU总共5ms。每秒真正的循环次数是200不是400。看到2.5ms就条件反射地乘400是这里最常见的翻车点。解决先确认完整循环总时长。1000ms除以循环总时长得到每秒循环次数再乘每周期符号数。遇到「双周期」「多周期」名称时优先画总时长轴不要被名称里的单个数字带偏。5.3 上行开销误用0.14速率被压低20Mbps现象按DDDSU配比算上行结果只有200Mbps出头比资料的214Mbps少了约14Mbps。原因上行公式里误用了下行开销0.14。下行参考信号和公共信道开销明显高于上行把0.14套到上行公式里(1-oh)从0.92变成0.86整个结果被整体压低。解决确认OH(j)的取值对象。资料口径是下行0.14、上行0.08。我一般会在代码里把oh当作显式参数传进去而不是在函数内部写死这样上下行各传各的值不容易串。5.4 MIMO层数把收发天线数混淆上行翻倍现象上行算出来约428Mbps正好是资料214Mbps的两倍。原因把2T4R理解成上行也是4层。2T4R的4是接收天线数量上行层数由终端发射天线数决定一般按2层计算。资料里FDD上行同样取2层方向保持一致。解决MIMO层数看数据流方向不看收发天线数量。下行峰值口径常见4层上行常见2层。看到「2T4R」这类标注时上行层数先按2层试算再和已知结果比对。5.5 上行调制阶数抄成8速率虚高三分之一现象把256QAM套到上行公式算出来约285Mbps比资料214Mbps高出约三分之一。原因上行链路受终端发射功率和信道质量限制现网峰值口径最高按64QAM计算调制阶数是6不是8。256QAM是下行常见配置抄公式时容易顺手带错。解决核对MCS表上下行各自支持的调制等级。资料里上行所有公式统一用6说明这组计算口径是有意把上行上限放在64QAM。验算时先用6跑一遍再看结果是否落在资料数字附近。6. 把公式固化成验算工具改一个参数看速率怎么变公式的价值不只是算出一个数而是能反推「速率下降到底是谁的锅」。实际项目里现网速率不达标时我会先把公式里的乘数拆开逐个和基线值对比。以下是常用的参数变化与速率影响对照参数变更速率变化倍数调制阶数从8降到6256QAM→64QAM×0.75MIMO层数从4降到2×0.50SCS从30kHz换到15kHz×0.50下行开销从0.14降到0.08×1.07TDD配比从DDDSU换到DDDSU DDSUU×0.87这张表可以直接当快捷验算器用。比如路测下行只有1.2Gbps对照基准1.7Gbps差距约三成第一反应查调制阶数是否掉到64QAM再看层数是否只调度了3层或2层。def nr_rate(layers, mod_order, oh, effective_symbols_per_sec): effective_symbols_per_sec 由带宽、SCS和时隙配比预先算好 例如FDD下行30kHz为 14*2*100028000DDDSU为 52*40020800。 return layers * mod_order * 0.926 * 273 * 12 * (1 - oh) * effective_symbols_per_sec # 共用函数分别验算FDD和TDD print(f{nr_rate(4, 8, 0.14, 14*2*1000) / 1e9:.2f} Gbps) # FDD下行 print(f{nr_rate(2, 6, 0.08, 16*400) / 1e9:.3f} Gbps) # TDD DDDSU上行 print(f{nr_rate(4, 8, 0.14, 52*400) / 1e9:.2f} Gbps) # TDD DDDSU下行这个函数的思路是把「每秒有效符号数」单独抽出来带宽、SCS、配比的影响都提前折算进这一个参数里后面做多场景对比时只改一层参数就够了。我在做配比方案评估时会先把候选配比的有效符号数列成表再批量调用函数几分钟就能出完整对比。从那以后我每次拿到一份新的网优参数配置都会强制走一遍这个流程先画符号轴确认配比再跑函数核对基准值最后用倍数表定位偏差。整套对照看完通常能排查掉九成以上的低级错误剩下的一成才是信道质量这类需要实测数据来验证的变量。希望帮到你。本文还有配套的精品资源点击获取