简介这份PPT资料聚焦移动通信领域5G NR理论速率计算面向通信工程师、终端研发人员及希望深入理解5G速率的入门学习者帮助读者从子载波间隔、帧结构等基础概念出发掌握FDD与TDD两种双工模式下的速率推导方法。资源包内含1个pptx文件大小约817KB以图文并茂的幻灯片形式系统梳理了5G NR的时频资源、调制方式、编码效率、载波聚合与mMIMO等核心影响因素。内容不止步于理论而是从实际产品层面逐一拆解影响速率的各项参数给出FDD上下行、TDD单周期与双周期等多种场景下的完整计算公式与数值示例并解释每个数字的具体含义。目前已有2519人学习适合希望透彻理解5G终端理论速率由来、并能独立完成速率估算的读者参考。1. 5G NR 理论速率到底怎么算从手机端到基站侧的完整拆解很多人第一次接触 5G 峰值速率脑子里蹦出来的都是运营商宣传页上那个“下行 2.3Gbps”。但真到了自己动手算或者拿手机测速发现连理论值一半都跑不到的时候就开始怀疑是不是基站偷工减料了。其实问题往往出在没搞清楚 5G NR 的帧结构和资源映射逻辑——它跟 LTE 完全不是一套玩法。LTE 只有一种子载波间隔 15kHz到了 NR 这里直接给了你 15kHz、30kHz、60kHz、120kHz、240kHz 五种选择时隙长度跟着变上下行分配粒度也从子帧级细化到了符号级。这份资料把 FDD 和 TDD 两种双工方式下的理论峰值速率公式全部拆开每一项乘数都对应一个物理层参数从调制阶数、编码效率、MIMO 层数到资源开销占比再到 TDD 特有的时隙配比换算全部落到了具体数字上。适合谁看做终端射频的、搞基站开通优化的、写协议栈测试用例的以及所有需要拿理论速率去反推设备能力边界的人。下面我按自己复现这套计算时的顺序把每一步的坑和参数含义讲清楚。2. 帧结构与子载波间隔为什么 30kHz 是当前主流配置2.1 五种 SCS 的时隙换算关系NR 的帧结构跟 LTE 最大的区别在于子载波间隔不再固定。协议里定义了 15kHz 作为基准其他间隔都是 2 的幂次倍乘关系。具体来说子载波间隔 Δf 15kHz × 2^μμ 取 0 到 4 分别对应 15、30、60、120、240kHz。这个 μ 值直接决定了每子帧的时隙数μ0 时 1 个子帧只有 1 个时隙μ1 时变成 2 个μ2 时 4 个以此类推。每个时隙固定 14 个 OFDM 符号常规 CP所以时隙持续时间 1ms / 2^μ。拿 30kHz 来说μ1一个子帧 1ms 里塞了 2 个时隙每个时隙 0.5ms每个时隙 14 个符号。这就是为什么公式里会出现“14×2”这个因子——它代表一个子帧内所有时隙贡献的符号总数。子载波间隔μ 值每子帧时隙数时隙时长每子帧符号数15kHz011ms1430kHz120.5ms2860kHz240.25ms56120kHz380.125ms112240kHz4160.0625ms224选 30kHz 不是拍脑袋定的。Sub-6GHz 频段下30kHz 能在覆盖和容量之间取平衡15kHz 时隙太长调度延迟大60kHz 虽然时隙短但符号周期压缩后对相位噪声和频偏更敏感终端实现成本高。所以当前主流 5G 手机和基站默认配 30kHz公式里的 14×2 就是这么来的。2.2 时频资源网格与 RB 映射频域上 NR 以 RB 为单位分配资源一个 RB 固定 12 个子载波。100MHz 带宽下30kHz 子载波间隔对应 273 个 RB这个数字是协议 38.101 里查表得到的不是随便算的。273×12 就是总的可用子载波数。时域上一个时隙 14 个符号但并不是所有符号都能拿来传用户数据。每个时隙里有一部分符号要留给下行控制信息、解调参考信号、相位跟踪参考信号等。协议 38.306 里给出了开销比例 OH(j)下行典型值 0.14上行 0.08。这个开销占比是算理论峰值时必须扣掉的否则算出来的数字会比实际空口能力虚高一大截。注意不同厂商对开销的处理可能有细微差异比如是否把同步信号块的开销单独扣除。做设备规格对比时先确认双方用的是同一套开销假设否则比出来的峰值速率没有意义。2.3 上下行分配粒度从子帧到符号的变化LTE 里上下行切换最小单位是子帧NR 把它细化到了符号级。这意味着 TDD 模式下可以更灵活地配置时隙格式比如一个时隙里前 10 个符号下行、后 4 个符号上行。但理论速率计算时通常还是按整时隙的配比来算因为调度器一般不会把符号级配比用到极限。资料里给的 TDD 公式用的是“14×3 10×1”这种表达意思是 3 个完整下行时隙加 1 个特殊时隙里的 10 个下行符号。特殊时隙的配比 10:2:2 指的是 10 个下行符号、2 个保护间隔符号、2 个上行符号。这个配比在 2.5ms 单周期里很常见算下来下行占比高适合下行流量为主的场景。3. FDD 理论速率计算把每一项乘数拆到不能再拆3.1 下行公式逐项拆解资料里 FDD 下行速率公式是Rate 4 × 8 × 0.926 × 273 × 12 × (1 - 0.14) × 14 × 2 × 1000。我把它拆成几个模块来看。4 是下行 MIMO 层数对应 4×4 MIMO 配置意思是基站四根发射天线同时发四个数据流。8 是 256QAM 的调制阶数每个符号承载 8 比特。0.926 是编码效率NR 里 LDPC 码在典型配置下的码率近似值。273×12 是频域资源100MHz 带宽 273 个 RB每个 RB 12 个子载波。0.14 是下行开销占比扣掉控制信道和参考信号。14×2 是时域资源30kHz 子载波间隔下一个子帧 2 个时隙每个时隙 14 个符号。1000 是 1 秒内包含 1000 个子帧。把这些乘起来4×83232×0.926≈29.6329.63×273×12≈97,080再乘 (1-0.14)0.86 得 83,489乘 28 得 2,337,692最后乘 1000 得 2.337×10^9 bit/s也就是 2.3Gbps 左右。跟资料里的 2,337,552,322.56 bit/s 基本一致微小差异来自编码效率的精度取舍。# FDD 下行理论峰值速率计算 mimo_layers 4 # 4x4 MIMO mod_order 8 # 256QAM, 8 bits per symbol coding_rate 0.926 # LDPC 编码效率 rb_count 273 # 100MHz 带宽下的 RB 数 subcarriers_per_rb 12 # 每个 RB 的子载波数 overhead_dl 0.14 # 下行开销占比 symbols_per_slot 14 # 常规 CP 下每时隙符号数 slots_per_subframe 2 # 30kHz SCS 下每子帧时隙数 subframes_per_sec 1000 # 每秒子帧数 rate_dl (mimo_layers * mod_order * coding_rate * rb_count * subcarriers_per_rb * (1 - overhead_dl) * symbols_per_slot * slots_per_subframe * subframes_per_sec) print(fFDD 下行峰值速率: {rate_dl / 1e9:.2f} Gbps) # 输出: FDD 下行峰值速率: 2.34 Gbps这段代码里每个变量都对应一个可配置的物理层参数。改 MIMO 层数就能看 2×2 和 4×4 的差距改调制阶数能对比 64QAM 和 256QAM 的速率差。实际做链路预算时我一般会把这些参数做成字典方便批量跑不同组合。3.2 上行公式的差异点上行公式是Rate 2 × 6 × 0.926 × 273 × 12 × (1 - 0.08) × 14 × 2 × 1000。跟下行比三个地方变了MIMO 层数从 4 降到 2调制阶数从 8 降到 664QAM开销占比从 0.14 降到 0.08。算下来是 937Mbps 左右。上行用 2×2 MIMO 和 64QAM 是当前终端发射能力的典型上限——手机天线数量有限发射功率也受限上 256QAM 对 EVM 要求太苛刻所以协议虽然定义了 256QAM 上行但实际网络里很少开。# FDD 上行理论峰值速率计算 mimo_layers_ul 2 # 2x2 MIMO mod_order_ul 6 # 64QAM, 6 bits per symbol overhead_ul 0.08 # 上行开销占比 rate_ul (mimo_layers_ul * mod_order_ul * coding_rate * rb_count * subcarriers_per_rb * (1 - overhead_ul) * symbols_per_slot * slots_per_subframe * subframes_per_sec) print(fFDD 上行峰值速率: {rate_ul / 1e6:.0f} Mbps) # 输出: FDD 上行峰值速率: 938 Mbps提示上行开销比下行低是因为上行没有同步信号块和广播信道但上行有 DMRS 和 PUCCH实际开销会随调度策略浮动。做终端能力评估时建议用 0.08 到 0.10 之间的值做敏感度分析。3.3 载波聚合与空域资源的叠加逻辑单载波 100MHz 算出来的 2.3Gbps 是理论天花板但实际部署中 Sub-6GHz 很难找到连续的 100MHz 频谱。载波聚合就是把多个离散频段拼起来用比如 60MHz 40MHz 凑成 100MHz 等效带宽。公式上就是 RB 数相加其他乘数不变。空域资源靠 mMIMO 的层映射实现一个码字映射到多个空间层层数越多速率越高但层数受信道秩限制——信道条件差的时候基站想发 4 层也发不出去终端反馈的 RI 会掉到 2 甚至 1。所以理论速率是“能力上限”不是“保证速率”。4. TDD 理论速率计算时隙配比才是那个隐藏变量4.1 2.5ms 单周期 DDDSU 配比换算TDD 跟 FDD 最大的不同是上下行共享同一段频谱靠时间切分。资料里给了三种典型配比先看 2.5ms 单周期 DDDSU。这个配比的意思是2.5ms 周期内前三个时隙全下行D第四个时隙是特殊时隙S第五个时隙全上行U。特殊时隙配比 10:2:2即 10 个下行符号、2 个保护间隔、2 个上行符号。2.5ms 周期在 30kHz 子载波间隔下包含 5 个时隙1 秒内有 400 个这样的周期。下行速率公式里时域因子变成了 (14×3 10×1) × 400。14×3 是三个完整下行时隙的符号数10×1 是特殊时隙里的下行符号数。乘 400 是因为每秒 400 个周期。算下来下行 1.7Gbps上行 214Mbps。上行时域因子是 (14×1 2×1) × 400即一个完整上行时隙加特殊时隙里的 2 个上行符号。# TDD 2.5ms 单周期 DDDSU 下行速率 periods_per_sec 400 # 1s / 2.5ms dl_slots_per_period 3 # DDD 三个下行时隙 dl_symbols_special 10 # 特殊时隙下行符号数 tdd_dl_symbols (dl_slots_per_period * symbols_per_slot dl_symbols_special) * periods_per_sec rate_tdd_dl (mimo_layers * mod_order * coding_rate * rb_count * subcarriers_per_rb * (1 - overhead_dl) * tdd_dl_symbols) print(fTDD DDDSU 下行: {rate_tdd_dl / 1e9:.2f} Gbps) # 输出: TDD DDDSU 下行: 1.74 Gbps4.2 2.5ms 双周期与 5ms 单周期的对比双周期 DDDSU DDSUU 是把两个 2.5ms 周期拼成 5ms第一个周期 DDDSU第二个周期 DDSUU。这样上行时隙多了一个适合上行需求稍大的场景。下行时域因子变成 (14×5 10×2) × 200因为 5ms 周期内 5 个下行时隙加两个特殊时隙的下行符号每秒 200 个周期。算下来下行 1.5Gbps上行 308Mbps。下行降了上行升了这就是配比调整的代价。5ms 单周期 DDDDDDDSUU 是七个下行时隙加一个特殊时隙加两个上行时隙特殊时隙配比 6:4:4。下行时域因子 (14×7 6×1) × 200上行 (14×2 4×1) × 200。算下来下行 1.7Gbps上行 214Mbps。跟 2.5ms 单周期比下行一样上行一样但周期更长意味着调度灵活性降低适合下行流量稳定且对时延不敏感的场景。TDD 配比周期下行速率上行速率适用场景DDDSU2.5ms1.7Gbps214Mbps下行主导时延敏感DDDSU DDSUU5ms1.5Gbps308Mbps上下行均衡DDDDDDDSUU5ms1.7Gbps214Mbps下行大流量4.3 特殊时隙配比对速率的影响特殊时隙的配比不是固定的协议允许灵活配置。10:2:2 是下行偏重的配比如果改成 6:4:4下行符号从 10 降到 6上行从 2 升到 4。在 5ms 单周期里下行时域因子从 (14×7 10×1) 变成 (14×7 6×1)下行速率会掉一点上行会升一点。实际网络里配比是基站根据业务模型动态调的但理论计算时得固定一个值才能横向对比。我一般会建议把配比和速率做成一张对照表方便优化时快速查。注意TDD 理论速率计算里最容易翻车的地方是把周期数算错。2.5ms 周期对应 400 个每秒5ms 对应 200 个10ms 对应 100 个。这个数字搞错了后面乘出来的速率会差一倍。5. 避坑与排查算出来的速率跟实测对不上怎么办5.1 现象理论算 2.3Gbps实测只有 800Mbps原因通常不是公式错了而是实际调度没跑满。理论速率假设所有 RB 都分配给单用户、所有 MIMO 层都用上、调制阶数拉满。但实际网络里 RB 要分给多个用户MIMO 层数受信道秩限制调制阶数受 SINR 限制。排查时先看调度器给这个用户分了多少 RB再看 RI 反馈是几层最后看 CQI 对应的调制阶数。这三个数一乘就能算出当前信道条件下的“可达速率”跟理论值对比才有意义。5.2 现象TDD 上行速率比下行还高原因可能是时隙配比搞反了。DDDSU 里上行只有一个完整时隙加两个符号下行有三个完整时隙加十个符号下行不可能比上行低。如果算出来上行高于下行先检查周期数是不是用错了——2.5ms 周期用 4005ms 用 200别搞混。再检查特殊时隙配比的方向10:2:2 是下行 10 上行 2别把顺序颠倒了。5.3 现象换了子载波间隔后速率没变原因可能是只改了 SCS 但没改时隙数。30kHz 下一个子帧 2 个时隙15kHz 下只有 1 个。如果公式里 14×2 的 2 没跟着 SCS 变算出来的速率就不对。另外 RB 数也跟 SCS 有关100MHz 带宽在 30kHz 下是 273 个 RB在 15kHz 下是 217 个这个对应关系在协议 38.101 里查表得到不能直接套用。5.4 现象载波聚合后速率没有线性叠加原因可能是聚合的载波之间没有完全独立调度。理论上线性的前提是每个载波都能跑满 MIMO 和最高调制但实际中辅载波的信号质量可能差一些调度器会降阶。另外跨载波调度会引入额外的控制开销这部分在单载波公式里没体现。做聚合速率估算时我一般会给辅载波打个 0.8 到 0.9 的折扣系数。5.5 现象开销占比取 0.14 但实际开销更大原因可能是没算上同步信号块和 CSI-RS 的开销。38.306 里的 OH(j) 是一个典型值但不同厂商的参考信号配置密度不同。比如 CSI-RS 周期从 5ms 改成 10ms开销就变了。排查时抓一段空口日志数一下一个时隙里实际用于用户数据的符号数反推真实开销占比比直接用协议值更准。6. 把公式做成可复用的计算脚本参数化与批量验证上面拆了这么多最终还是要落到能跑的工具上。我习惯把 FDD 和 TDD 的计算逻辑封装成一个函数参数包括双工方式、SCS、MIMO 层数、调制阶数、开销占比、TDD 配比和周期。这样改一个参数就能看速率变化做方案对比时不用手算。def calc_peak_rate(duplex, scs_khz, mimo_dl, mimo_ul, mod_dl, mod_ul, overhead_dl0.14, overhead_ul0.08, tdd_patternNone, period_msNone): 计算 5G NR 理论峰值速率 duplex: FDD 或 TDD scs_khz: 子载波间隔15/30/60/120/240 mimo_dl/ul: 下行/上行 MIMO 层数 mod_dl/ul: 下行/上行调制阶数 (2/4/6/8) tdd_pattern: TDD 时隙配比如 DDDSU period_ms: TDD 周期如 2.5 或 5 mu {15:0, 30:1, 60:2, 120:3, 240:4}[scs_khz] slots_per_subframe 2 ** mu symbols_per_subframe 14 * slots_per_subframe rb_count {15:217, 30:273, 60:135, 120:66, 240:33}[scs_khz] coding_rate 0.926 if duplex FDD: rate_dl (mimo_dl * mod_dl * coding_rate * rb_count * 12 * (1 - overhead_dl) * symbols_per_subframe * 1000) rate_ul (mimo_ul * mod_ul * coding_rate * rb_count * 12 * (1 - overhead_ul) * symbols_per_subframe * 1000) else: periods_per_sec 1000 / period_ms # 解析 TDD pattern这里以 DDDSU 为例 dl_slots tdd_pattern.count(D) ul_slots tdd_pattern.count(U) special_dl, special_ul 10, 2 # 特殊时隙配比 dl_symbols (dl_slots * 14 special_dl) * periods_per_sec ul_symbols (ul_slots * 14 special_ul) * periods_per_sec rate_dl (mimo_dl * mod_dl * coding_rate * rb_count * 12 * (1 - overhead_dl) * dl_symbols) rate_ul (mimo_ul * mod_ul * coding_rate * rb_count * 12 * (1 - overhead_ul) * ul_symbols) return rate_dl / 1e9, rate_ul / 1e9 # 批量对比不同配置 configs [ (FDD, 30, 4, 2, 8, 6, None, None), (TDD, 30, 4, 2, 8, 6, DDDSU, 2.5), (TDD, 30, 4, 2, 8, 6, DDDSUDDSUU, 5), ] for cfg in configs: dl, ul calc_peak_rate(*cfg) print(f{cfg[0]} SCS{cfg[1]}kHz: DL{dl:.2f}Gbps, UL{ul:.2f}Gbps)这个脚本里 RB 数按 SCS 查表不是硬编码 273。15kHz 下 100MHz 对应 217 个 RB60kHz 下只有 135 个因为子载波变宽了同样带宽里塞不下那么多 RB。TDD 的时隙配比解析用字符串计数DDDSU 里三个 D 一个 U特殊时隙固定 10:2:2。跑出来的结果跟资料里的手算值对得上说明逻辑没问题。验证方法很简单拿一个已知配置去跑看输出跟协议或设备规格书是否一致。比如 FDD 30kHz 4×4 MIMO 256QAM 下行跑出来 2.34Gbps跟资料里的 2.3Gbps 吻合。再换 TDD DDDSU 2.5ms跑出来 1.74Gbps也吻合。如果对不上先检查 RB 数查表对不对再检查周期数算没算错。从那以后我每次拿到新的 5G 设备规格书都强制走一遍这个脚本把理论值算出来跟标称值对一遍。对不上的时候要么是规格书虚标要么是我某个参数取错了从来没第三种可能。希望帮到你。本文还有配套的精品资源点击获取