企业官网建设流程全解析

简介：面向 5G 网络规划优化与通信技术学习者的《5G NR 吞吐量理论计算.pdf》，聚焦 5G NR 峰值速率如何从 3GPP 协议参数中推导而来，帮助读者掌握基于 PRB 数、Symbol 数、帧结构、调制阶数与流数计算上下行理论速率的方法，尤其适用于 sub-6GHz、100MHz 带宽、30kHz 子载波间隔场景。资料为一个 PDF 文件，压缩包大小 1.06MB，内容紧凑、公式完整，可直接对照学习；已有 1604 人学习。文档以 273 PRB、14 符号、常规循环前缀等为计算基础，分别给出 2.5ms 双周期与 5ms 单周期下的上行（64QAM、2流）和下行（256QAM、4流）峰值速率实例，并列出不同带宽、帧结构、MCS、流数对应的速率对照表，方便用于 5G 容量估算、帧结构选型与理论基础复习。文中还演示了扣除 PDCCH、DMRS 等控制开销后的近似折算思路，能帮助读者理解协议参数与实际有效速率之间的差异，为后续做链路预算和峰值速率验证提供可复用的参考。

1. 为什么“最大吞吐量”不等于“实际速率”：5G NR 峰值速率的换算起点

很多刚接触 5G NR 的人会被一个数字吓到：3GPP TS 38.913 里写的是下行峰值 20 Gbps、上行 10 Gbps。可真到了外场，拿着终端实测，发现 100 MHz 带宽跑出 1.7 Gbps 就已经是顶格，有人就会怀疑是不是设备不行。其实 20 Gbps 是协议对整体系统的目标值，不是某个载波在某个时刻能跑出来的数。真正决定一台设备能跑多快的，是一串可以手算的参数：PRB 数量、Symbol 数量、帧结构里上下行 slot 的占比、调制阶数、MIMO 流数。

这份《5G NR 吞吐量理论计算》把计算路径拆得很干净：先从 3GPP TS 38.101-1 里找到不同带宽和子载波间隔对应的最大 PRB 数，再按帧结构算出每毫秒的下行或上行 slot 数，最后乘上符号承载的 bit 数和流数，得出理论峰值。这个计算方式不仅适用于 sub-6GHz 的 100 MHz 带宽，也能推广到毫米波或者其他参数集。对从事无线网规划、优化、测试的从业者来说，掌握这套手算逻辑，比直接背一个速查表要可靠得多，因为你可以反推任意配置下的极限速率。

2. 从 OFDM 到 F-OFDM：NR 物理层参数集如何决定资源格栅

要理解吞吐量计算，先要弄清楚 NR 的时频资源是怎么组织的。NR 在物理层承接了 LTE 的 OFDM 和 SC-FDM，但把 OFDM 演进为 F-OFDM，本质区别在于子载波间隔不再固定为 15 kHz，而是由参数集 μ 决定。子载波间隔等于 15 × 2^μ kHz，μ 取 0 到 4，分别对应 15、30、60、120、240 kHz。这个设计直接影响了时隙长度：μ = 1 也就是 30 kHz 子载波间隔时，一个 slot 的时间是 0.5 ms；μ = 2 时是 0.25 ms，以此类推。

PRB 是频域调度的最小单位，一个 PRB 在频域上占 12 个子载波，在时域上对应一个 slot。所以计算速率的第一步，永远是确认你用的是哪个带宽、哪个子载波间隔，再决定能调度多少个 PRB。3GPP TS 38.101-1 对 FR1 频段给出了明确的 PRB 上限，下面这张表是我根据协议内容和常见配置整理的关键部分：

注意 100 MHz 带宽这一行，在 15 kHz 和 30 kHz 子载波间隔下 PRB 数都是 273。这是因为 100 MHz 是 FR1 里比较特殊的宽载波，它既能放下 273 个 30 kHz 的 PRB，也能放下 273 个 15 kHz 的 PRB，只是后者在频域上会更拥挤一些。而 50 MHz @ 30 kHz 时 PRB 数为 133，对应 50 MHz 实际占用带宽约 48 MHz，剩下的是保护带。计算峰值速率时，用 PRB 数乘以 12 得到总子载波数，这是频域维度的资源总量。

临界带宽位置还有个容易被忽略的细节：工程上常说的 100 MHz 载波，实际信道带宽是 100 MHz，但基带采样率和滤波器设计不同，在部分协议版本里 100 MHz @ 30 kHz 对应的 PRB 上限可能因保护带设置而略有浮动。我一般做规划时会用 273 这个值去估算，然后留出 3% 到 5% 的余量给调度开销和参考信号冲击。对于毫米波频段，比如 400 MHz 带宽 @ 120 kHz，PRB 数会到 264 左右，计算思路完全一样，只是 SCS 和带宽的对应关系要换一张表。

计算吞吐量的时域维度，要看一个 slot 内的符号数。常规循环前缀下每 slot 14 个符号，这个数字与 μ 无关，也就是说无论子载波间隔怎么变，一个 slot 里永远是 14 个符号。但 slot 的绝对时间随 μ 变化，所以每毫秒能塞多少个 slot 也随之变化。把频域总子载波数、时域总符号数、每毫秒 slot 数、调制阶数、MIMO 流数乘在一起，就是理论峰值速率。这里的核心认知是：NR 的高速不是靠某一项黑科技，而是靠更宽的带宽、更高的调制阶数、更多的空间流三层叠加。

3. 帧结构里的下行与上行比例：2.5 ms 双周期和 5 ms 单周期怎么选

帧结构配置决定了 TDD 系统里上下行资源在时间上的切分比例，这是 NR 吞吐量计算里变化最多、最容易算错的一环。NR 的帧结构通过上下行时隙配比来定义，常见的 TDD 配置有 2.5 ms 双周期和 5 ms 单周期两种。2.5 ms 双周期里面还有不同的特殊子帧时隙配比，比如 DSUUU 或 DDSUU，具体到特殊子帧里 DwPTS:GP:UpPTS 的比例又会影响上下行符号数。本文的原始计算基于两种典型配置：2.5 ms 双周期下特殊子帧配比 10:2:2，5 ms 单周期下特殊子帧配比 6:4:4。

在 2.5 ms 双周期、时隙配比 10:2:2 的情况下，5 ms 内下行 slot 数为 5 + 2×10/14，这里的 2 是特殊子帧里 DwPTS 占的符号数折算成的 slot 数。DwPTS 有 10 个符号用于下行，除以每 slot 14 个符号，得到约 0.714 个等效下行 slot。普通下行 slot 有 5 个，所以总下行 slot 数是 5.714，除以 5 ms，得到约 1.28 个下行 slot 每毫秒。上行侧同理，UpPTS 有 2 个符号，加上 3 个普通上行 slot，总上行 slot 数为 3 + 2/14 ≈ 3.143，除以 5 得约 0.657 个上行 slot 每毫秒。

5 ms 单周期、时隙配比 6:4:4 的配置则不同。下行侧 5 ms 内有 7 个普通下行 slot，特殊子帧里 DwPTS 占 6 个符号，折算为 6/14 个 slot，总下行 slot 数约 7.429，除以 5 得 1.48 个下行 slot 每毫秒。上行侧只有 2 个普通上行 slot，UpPTS 占 4 个符号，折算为 4/14 个 slot，总上行 slot 约 2.286，除以 5 得 0.457 个上行 slot 每毫秒。从数字上能直接看出，2.5 ms 双周期更偏上行，5 ms 单周期更偏下行。所以在做容量规划时，如果业务以下行为主，选 5 ms 单周期；如果上行大包多，选 2.5 ms 双周期，这个选择直接影响峰值吞吐量。

在实际网络里，帧结构配置往往是全网统一的，不是每个小区独立决定，因为 TDD 系统存在交叉时隙干扰的问题。异频组网时，相邻小区如果用不同的上下行配比，会出现在某个时隙 A 小区在发上行、B 小区在下行的情况，基站间会产生干扰。这也是为什么很多运营商在初期统一采用 2.5 ms 双周期，后期再根据业务模型逐步调整。对优化工程师来说，理解帧结构配比对吞吐量的影响，才能在上行弱、下行强或者反过来的时候，快速判断是不是配比导致的，而不是盲目去改功率或天线参数。

4. 上行 284 Mbps 还是 198 Mbps：完整复现 5G NR 理论峰值速率计算过程

现在进入最关键的环节：把整套公式用手算的方式完整复现一遍。计算 NR 理论峰值速率的通用公式是：峰值速率 = PRB 数 × 12 子载波 × 有效符号数 × 每毫秒 slot 数 × 调制阶数 × 流数。这里“有效符号数”用的是 11，因为每 14 个符号里有 2 个用于 PDCCH 和 DMRS，另外再预留 1 个给其他参考信号，相当于做了近似扣除。这是一个工程化的处理，协议里没有统一的“11 符号”说法，但用于估算非常实用。

先看上行 Type 1，也就是 2.5 ms 双周期、10:2:2 配比、2 流、64QAM 的配置。代入数值：273 PRB × 12 子载波 × 11 符号 × 0.657 上行 slot 每毫秒 × 6 bit × 2 流 ≈ 284 Mbps。再看上行 Type 2，5 ms 单周期、6:4:4 配比，同样 2 流、64QAM，但每毫秒上行 slot 数降到 0.457，计算结果 ≈ 198 Mbps。这两个数字差了约 30%，原因完全来自帧结构配比差异，调制阶数和流数都没变。这也说明，上行吞吐量对帧结构极其敏感，在 TDD 网络里选错配比，相当于瞬间损失三成容量。

下行计算把调制阶数换成 256QAM 的 8 bit，流数提到 4 流。Type 1 也就是 2.5 ms 双周期配置，每毫秒下行 slot 数为 1.28，计算过程为 273 × 12 × 11 × 1.28 × 8 × 4 ≈ 1.48 Gbps。Type 2 也就是 5 ms 单周期配置，每毫秒下行 slot 数为 1.48，计算过程为 273 × 12 × 11 × 1.48 × 8 × 4 ≈ 1.7 Gbps。注意这里有个细节：上行用的流数是 2，下行用的流数是 4，这符合终端能力的典型配置。FR1 频段下，手机下行通常支持 4 收 4 发，上行由于功放和功耗限制，一般只做 2 发。如果终端只支持 2 收，下行速率会直接减半到约 0.85 Gbps，这一项在评估真实终端速率时比帧结构的影响还大。

为了验证手算过程没有算错，可以把这个计算过程写成一段 Python 脚本，方便对不同参数做快速试算。以下是我常用的一个计算函数：

def nr_peak_rate(prb, scs, scs_per_slot_symbols=14, effective_symbols=11, slots_per_ms_tx, modulation_bits_per_symbol, mimo_layers): subcarriers = prb * 12 symbols_per_ms = subcarriers * effective_symbols * slots_per_ms_tx bits_per_ms = symbols_per_ms * modulation_bits_per_symbol * mimo_layers rate_mbps = bits_per_ms / 1000 return rate_mbps # 上行 Type 1: 2.5ms 双周期, 10:2:2, 2流, 64QAM ul_type1 = nr_peak_rate(prb=273, scs=30, slots_per_ms_tx=0.657, modulation_bits_per_symbol=6, mimo_layers=2) # 下行 Type 2: 5ms 单周期, 6:4:4, 4流, 256QAM dl_type2 = nr_peak_rate(prb=273, scs=30, slots_per_ms_tx=1.48, modulation_bits_per_symbol=8, mimo_layers=4) print(f"UL Type1: {ul_type1:.1f} Mbps") print(f"DL Type2: {dl_type2:.1f} Gbps")

这段脚本的输出结果应当与手算一致：UL Type1 约 284.1 Mbps，DL Type2 约 1701.3 Mbps。参数里effective_symbols是开销扣除后的有效符号数，slots_per_ms_tx是不同帧结构下每毫秒的可用 slot 数。修改这些入参，就可以快速估算任何配置下的理论极限。我一般在做站点容量预估时，会把这几个入参从配置表里取，批量算完再对比实测值，误差能控制在合理范围内。

下面这张表汇总了这四种典型配置的完整参数和计算结果，可以直接作为工作参考：

这里需要强调一个常见误区：有人在算下行 Type 2 时，会把每毫秒下行 slot 数 1.48 直接乘以 14 个符号，再乘以全部 PRB，得到的结果会比 1.7 Gbps 更高。问题在于多算了 PDCCH 和 DMRS 占用的符号，那是控制信道和导频的资源，不是用户数据。所以 11 个有效符号这个折扣因子必须保留，否则算出来的速率在实际网络中永远达不到。反之，如果你发现某设备标称速率高于这个计算结果，大概率是用了更高的调制阶数或者低开销的特殊帧结构，可以按同样的公式反向验证。

此外，计算时还要注意 100 MHz 带宽下 273 个 PRB 是上限，实际调度时不一定全部分配给一个用户。协议里 PRB 是调度单位，一个用户可能只分到一部分 PRB。理论峰值算的是“全部资源给一个用户”的极限情况，这也是它被称为理论值的原因。在测试环境中，通常会把测试终端设为唯一的调度用户，才能接近这个数。

5. 把计算变成工具：一套可复用的 NR 吞吐量估算脚本与参数表

第四章的 Python 方法可以再往前推一步。实际工作中，你面对的不是单个配置，而是一张包含几十个小区、不同带宽、不同帧结构的规划表。手动改参数效率太低，常见做法是把参数抽取到一张配置表里，用脚本批量算，再和路测或后台统计的 PRB 利用率、调度率、MCS 分布结合起来看。下面是我常用的一种实现思路：先定义好配置表，再逐行套用计算函数，输出所有小区的理论峰值和预期速率区间。

import csv def nr_rate_from_config(row, direction): prb = int(row['PRB']) slots_per_ms = float(row[f'{direction}_slots_per_ms']) bits = int(row[f'{direction}_bits']) # 64QAM=6, 256QAM=8 layers = int(row[f'{direction}_layers']) # 上行通常2, 下行通常4 return prb * 12 * 11 * slots_per_ms * bits * layers / 1000 # Mbps configs = [ {'name': '宏站100M', 'PRB': 273, 'downlink_slots_per_ms': 1.28, 'downlink_bits': 8, 'downlink_layers': 4, 'uplink_slots_per_ms': 0.657, 'uplink_bits': 6, 'uplink_layers': 2}, {'name': '室分100M', 'PRB': 273, 'downlink_slots_per_ms': 1.48, 'downlink_bits': 8, 'downlink_layers': 4, 'uplink_slots_per_ms': 0.457, 'uplink_bits': 6, 'uplink_layers': 2}, ] for cfg in configs: dl = nr_rate_from_config(cfg, 'downlink') ul = nr_rate_from_config(cfg, 'uplink') print(f"{cfg['name']}: DL {dl:.0f} Mbps / UL {ul:.0f} Mbps")

这段脚本里使用了一个简化假设：上下行都固定为 11 个有效符号。如果是特殊子帧里的 DwPTS 和 UpPTS，包含的符号数少于 14，可以再按比例折算。比如 DwPTS 有 10 个符号时，有效数据符号大约是 10 × (11/14) ≈ 7.9 个，不过实际做估算时，直接按公式展开会更精确，这一步通常留给详细预算阶段处理。脚本的价值在于把重复性计算自动化，让你从 273×12×11×… 这样的手工乘法里解放出来。

除了脚本，用表格管理多配置参数也是个好办法。规划阶段我习惯维护一张参数总表，包含以下字段：小区名、频段、带宽、子载波间隔、每毫秒下行 slot 数、每毫秒上行 slot 数、下行流数、上行流数、下行调制阶数、上行调制阶数。每次讨论容量方案时直接对照这张表，不用再翻协议或重新推公式。注意带宽和 PCell 配置变化时，PRB 上限也要同步更新，特别是从 100 MHz 切到 80 MHz 或 60 MHz 时，不能沿用 273 这个数。

批量计算后还有一个校验环节值得做：把脚本输出的理论值除以小区平均 PRB 利用率，得到“当前话务模型下的实际可用速率”，再和后台统计的平均吞吐量对比。如果实测远低于估算，说明存在调度限制、信道质量差导致的 MCS 回落、或者传输带宽瓶颈。如果实测接近估算，说明空口资源利用率已经很高，扩容思路要从增加带宽或流数入手。这套方法在 5G 网络优化里非常实用，能让理论计算直接服务于问题定位。

6. 特殊子帧配比的影响边界：把 10:2:2 换成 6:4:4 后吞吐量怎么变

很多人算完一组典型配置就停了，没有意识到特殊子帧的时隙配比本身就是一个连续可调的变量。特殊子帧由 DwPTS、GP、UpPTS 三部分组成，三者的符号数之和在常规 CP 下等于 14。配比从 10:2:2 改成 6:4:4，不只是把下行符号让给了上行，还在 GP 里增加了保护间隔，这会影响小区覆盖半径和上下行干扰隔离度。吞吐量计算时，直接把 DwPTS 的符号数除以 14 折算成下行 slot，把 UpPTS 的符号数除以 14 折算成上行 slot，再与普通上下行 slot 相加，即可得到新的每毫秒 slot 数。

以周期为 5 ms 的 DSUUU 帧结构为例，每个 5 ms 周期内有 1 个下行 slot、3 个上行 slot、1 个特殊子帧。时隙配比从 10:2:2 改成 6:4:4 后，5 ms 内的下行总 slot 为 1 + 6/14 ≈ 1.43，上行总 slot 为 3 + 4/14 ≈ 3.29。这个数字对应的每毫秒下行 slot 约 0.29，上行约 0.66。如果把这个配比放在主要承载下行大包的小区，吞吐量会大幅下降，因为下行可用资源被压缩到只剩特殊子帧的 DwPTS 部分。所以特殊子帧配比的选择，直接影响覆盖和容量的平衡，调大 GP 会增强抗干扰能力，但会牺牲吞吐量。

从运维视角看，现网是否应该从一个配比切到另一个配比，参考的依据不只是吞吐量计算。你要同时看上下行 PRB 利用率和用户感知速率。如果上行利用率长期超过 70% 而下行利用率只有 30%，说明资源分配和业务模型不匹配，可以考虑把特殊子帧配比调向更多上行符号，或者直接切换帧结构周期。切换前先把公式算一遍，用计算出的理论吞吐量变化作为预期收益，切换后对比实际指标。这样既发挥了理论计算的前瞻作用，又用数据验证了调整效果。

最后补充一个容易被忽略的边界：理论计算里默认终端能力支持满配，但实际的手机可能只支持 2 流下行或者 64QAM 上行，这时候理论速率直接按比例缩水。做峰值测试时，要先去终端的射频能力里确认最大流数和调制阶数，再决定用哪个数字作为目标值。这个看起来不起眼的检查，经常能避免一场因为终端能力不达标而误判为网络问题的测试。

对照这张配比变化表，你对特殊子帧的敏感度会直观很多：

配比从 10:2:2 切到 6:4:4，下行符号数减少 40%，上行符号数增加 100%，这个悬殊的比例说明只有在上行需求强烈时才值得切换。同时注意 GP 从 2 扩到 4，对应的覆盖半径增大，但也减少了上下行转换的频谱效率。实际外场操作中，我一般会先通过后台统计确认上行 PRB 利用率确实成为瓶颈，再启动配比调整流程，而不是只看吞吐量数字的大小。

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