企业官网建设流程全解析

1. 先搞清楚“5G峰值速率计算”到底在算什么

“5G峰值速率计算”这件事，几乎每个做无线的人都被问过：这套系统到底能跑多快？外场测出来只有 800Mbps，是设备不行还是本来就该这样？这两个问题的答案，都藏在同一个公式里。它的本质并不复杂——就是在给定带宽、给定帧结构、给定调制方式和空分层数的前提下，算清楚“一秒钟最多能往空中塞进去多少比特”。听起来像小学数学，但真正动手算的时候，十个参数里有七个容易取错值，最后算出来能差一倍。

这篇文章适合三类人看：第一类是刚接手 5G 网络规划或优化、需要自己动手做容量测算的同学；第二类是做终端、模组选型，想知道手里这颗芯片理论上限在哪的硬件工程师；第三类是做项目验收、需要拿理论峰值当基线去判断“实测结果合不合格”的人。全文以 3GPP 的通用计算口径为准，把公式拆到每一项，再用三个真实工程里常见的场景把数字跑一遍，最后给一份可以直接抄的参数表和一段算得动的脚本。

先说清楚一件事，避免后面理解跑偏：这里算出来的叫理论峰值速率，它的隐含前提是“所有资源满调度、最高阶调制、最高码率、信道条件理想”。它不代表用户实际体验速率，也不是小区平均吞吐。它的价值在于给出一个绝对上限——任何实测值都不可能超过它，一旦超了，那一定是统计口径错了。

1.1 峰值速率的物理本质：一次能装多少比特

把无线链路想象成一条流水线。带宽决定了流水线有多宽，帧结构决定了每秒有多少个“班次”，调制阶数决定了每个工件有多重，空分层数决定了同时开几条并行流水线。峰值速率就是这条流水线满负荷运转时的产出。

落到物理层，最小的资源单位是RE（Resource Element），一个 RE 就是一个子载波上的一个 OFDM 符号，能承载 Qm 个比特（Qm 是调制阶数，QPSK 是 2，16QAM 是 4，64QAM 是 6，256QAM 是 8）。RE 往上聚合成RB（Resource Block），一个 RB 在频域固定占 12 个子载波，时域占一个时隙内的全部符号。所以“一秒钟能传多少比特”，就是“一秒钟内有多少个 RE，每个 RE 装多少比特，再乘上能并行几层，最后扣掉不能传数据的开销”。

这个思路跟修高速公路完全一样：车道数对应带宽和层数，限速对应调制阶数，收费站和应急车道对应开销。你不能指望一条四车道高速跑出十六车道的流量，也不可能把应急车道也算进通行能力里。理解了这一点，后面那些看着吓人的参数就有了归属。

1.2 真正决定结果的只有三个数字

很多人第一次看峰值速率公式会被一堆下标吓住，其实对结果影响最大的只有三个量：PRB 数、空分层数、每层每 RE 的比特数（Qm × 码率）。其余参数要么是常数，要么影响很小。

举个例子，同样 100MHz 带宽，30kHz 子载波间隔下是 273 个 PRB，60kHz 下就只剩 135 个 PRB——带宽没变，但子载波变宽了，能切出来的 PRB 少了一半，速率直接腰斩。这就是为什么毫米波频段虽然带宽大，但子载波间隔宽，单 PRB 的“含金量”要重新算。

层数的影响是线性的。4 层就是 2 层的两倍，这一点非常好理解——多天线并行传输。但层数上不去，是因为它受信道条件和终端能力双重限制：终端只支持 2 层，基站就算配了 64 通道也只能按 2 层调度。

调制阶数的影响也是线性的，但每上一个台阶对信噪比的要求提升很大。256QAM 比 64QAM 多 33% 的比特，代价是需要更高的 SINR 才站得住。所以外场里 256QAM 的调度占比通常不高，这也是实测达不到理论峰值的主要原因之一。

1.3 为什么工程上必须自己算一遍

有人会问，参数表网上一搜一大把，为什么要自己算？因为参数组合是爆炸的。带宽有 5/10/20/40/60/80/100MHz，子载波间隔有 15/30/60/120kHz，层数 1 到 8，调制从 QPSK 到 256QAM，再加 TDD 上下行配比、特殊时隙符号分配、是否开载波聚合，组合数量足以让任何一张现成的表都不够用。

更重要的是，算的过程本身就是一次配置核对。我在做某网络的外场验收时就遇到过：规划文档写的下行峰值是 1.6Gbps，现场实测最高只到 1.1Gbps，一度怀疑是设备故障。后来把参数一项一项对回去，发现规划时按 4 层算的，而实际批量到货的终端只有 2 层能力，问题立刻定位。如果只查表不对参数，这种问题能排查一整天。

2. 公式拆解：每一项都要有出处

把公式完整写出来，其实是这个样子：

速率 = (N_PRB × 12 × N_sym × N_layer × Qm × R × (1 − OH)) ÷ T_slot

看着像天书，但拆开看每一项目标都很明确。N_PRB 是带宽对应的 PRB 数，12 是一个 RB 的子载波数，N_sym 是一个时隙里的符号数，N_layer 是层数，Qm 是调制阶数，R 是目标码率，OH 是开销比例，T_slot 是一个时隙的时长。分子算的是“一个时隙能装多少净荷比特”，除以时隙时长就得到速率。

下面逐项过一遍，重点讲哪些地方最容易踩坑。

2.1 带宽换算 PRB：不是除一下那么简单

新手最容易犯的错，是用“带宽 ÷ (12 × 子载波间隔)”直接算 PRB 数。比如 100MHz ÷ (12 × 30kHz) = 277.7，就取 277。这个数是错的，正确值是273。

差在哪？第一，实际发射信号不能占满整个信道带宽，两侧必须留保护带，避免对相邻信道造成干扰；第二，3GPP 在 TS 38.101-1 里明确规定了每种带宽和子载波间隔组合对应的 PRB 数，这是一个查表值，不是算出来的。

常用的几个组合必须记牢：

提示：100MHz/30kHz 的 273 这个数字用得最多，可以直接背下来。它对应的实际占用带宽约 98.28MHz（273 × 12 × 30kHz），剩下的 1.72MHz 就是两侧保护带。

这里有个细节值得说：为什么 100MHz 用 30kHz 而不是 15kHz？因为 15kHz 在 100MHz 下虽然也能切出 270 个 PRB，但每个时隙长达 1ms，调度粒度太粗，而且 15kHz 在大带宽下的相位噪声和频偏补偿难度更高，实际部署几乎不用。这就是选型背后的权衡——PRB 数只差 3 个，但时域灵活性和实现复杂度差得远。

2.2 时域参数：符号数和时隙长度绑在一起

N_sym 通常取14，这是正常循环前缀下一个时隙的 OFDM 符号数。扩展循环前缀下是 12，但 5G 里除了特定场景基本不用，算峰值时按 14 走。

T_slot 跟子载波间隔强相关，关系是固定的：

• 15kHz → 时隙 1ms，每帧 10 个时隙
• 30kHz → 时隙 0.5ms，每帧 20 个时隙
• 60kHz → 时隙 0.25ms，每帧 40 个时隙
• 120kHz → 时隙 0.125ms，每帧 80 个时隙

规律很清晰：子载波间隔翻倍，时隙长度减半，每帧时隙数翻倍。所以“每帧总符号数”其实是个常数——10ms 内永远是 140 个符号（正常 CP 下略有出入）。这意味着，如果你只关心“每帧能传多少比特”，时域这一项其实是不变的，变的只是调度的颗粒度。

真正影响速率的是这些符号里有多少能用来传数据。TDD 制式下，一部分时隙要留给上行，一部分时隙要做上下行转换，转换的那个特殊时隙里只有部分符号能用于下行传输。这部分损失，是靠帧结构配比来体现的。

2.3 开销系数：14% 和 8% 是怎么来的

OH 是最容易被低估的一项。有人图省事直接取 0，算出来的数字漂亮得离谱，实际根本达不到。

下行开销大约是14%，主要构成是：PDCCH 占 1 到 3 个符号（按平均 1 个算），DMRS 解调参考导频占约 7%（单符号前置 DMRS 的情况下），再加上 CSI-RS、SSB 等周期信号的摊销。这个 14% 是业界常用的经验值，3GPP 在 TR 38.802 的评估假设里也给过类似口径。

上行开销略低，大约8%，因为上行没有 PDCCH 那种每时隙必占的控制信道（上行控制信息走 PUCCH，资源占用方式不同），主要是 DMRS。

毫米波频段的开销会更高一些，因为要插入 PTRS 相位跟踪参考信号来对抗相位噪声，实际取值可能到 18% 到 20%。这一点在算 FR2 峰值时特别要注意，直接套 14% 会偏乐观。

注意：不同资料给的开销值从 8% 到 25% 都有，差异来源于假设的 DMRS 配置类型（Type 1 还是 Type 2）、前置符号数量、附加符号数量。做对比测算时，一定要确认双方用的是同一套假设，否则结论没法比。

2.4 调制阶数与层数：上限在哪里

调制阶数的取值和对应比特数：QPSK=2、16QAM=4、64QAM=6、256QAM=8。5G 下行最高支持 256QAM，上行在 Rel-15 里最高 64QAM，后续版本才引入上行 256QAM，很多网络至今没开。

码率 R 取0.9258，也就是 948/1024，这是 3GPP 定义的最高目标码率。这个数不是随便定的，它对应的是 LDPC 编码在最高码率下的频谱效率上限，实际调度中很少能稳定跑满。

层数的上限受制于两头。标准层面，下行最多 8 层，上行最多 4 层；设备层面，基站通道数和终端能力共同决定实际可用层数。中频段 64 通道基站配 4 层终端是很常见的组合，毫米波则经常用 2 层或 4 层。

这里有个容易被忽略的点：层数和调制不是独立的。高层数需要更好的信道条件才能解出来，而高调制同样需要高 SINR。两者抢占的是同一份信噪比预算，所以在实际网络里，“4 层 256QAM”这种理想组合的持续时间非常短，多数时候是在 2 层 64QAM 和 4 层 64QAM 之间摆动。

3. 手把手算三个场景，把数字跑出来

公式理解了，接下来动手。选三个工程上最常见的配置，把每一步的中间值都写出来，方便你对照自己的场景改参数。

3.1 场景一：3.5GHz 100MHz 下行，最典型的中频段配置

参数设定：带宽 100MHz，子载波间隔 30kHz，PRB 数 273，每时隙 14 符号，时隙长度 0.5ms，下行 4 层，256QAM（Qm=8），码率 0.9258，开销 14%。

先算单个时隙、单层的 RE 总数：

273 × 12 = 3276 个 RB 级子载波 3276 × 14 = 45864 个 RE

再乘调制和码率：

45864 × 8 = 366912 bit 366912 × 0.9258 = 339725 bit

扣开销：

339725 × 0.86 = 292164 bit

乘层数、除以时隙时长：

292164 × 4 = 1168656 bit 1168656 ÷ 0.0005 s = 2337312000 bit/s ≈ 2.34 Gbps

所以这套配置的理论下行峰值是2.34Gbps。这个数字和大量公开资料里的口径一致，可以作为中频段 100MHz 的基准值记下来。

把层数换成 2 层，其他不变：292164 × 2 ÷ 0.0005 = 1.17Gbps。换成 64QAM 4 层：292164 × 6/8 × 4 ÷ 0.0005 = 1.75Gbps。这几个数在脑子里有个印象，现场估算会快很多。

3.2 场景二：毫米波 400MHz 下行，带宽换来的暴力提升

参数设定：带宽 400MHz，子载波间隔 120kHz，PRB 数 264，每时隙 14 符号，时隙长度 0.125ms，4 层，256QAM，码率 0.9258，开销按毫米波实际取 18%。

264 × 12 = 3168 3168 × 14 = 44352 个 RE 44352 × 8 = 354816 bit 354816 × 0.9258 = 328489 bit 328489 × 0.82 = 269361 bit 269361 × 4 = 1077444 bit 1077444 ÷ 0.000125 = 8619552000 bit/s ≈ 8.62 Gbps

约8.6Gbps。如果按 14% 开销算，结果是 9.04Gbps。这 0.4Gbps 的差异就是 PTRS 的代价——毫米波频段相位噪声严重，不多插导频根本解调不出来。

对比一下场景一，带宽翻了 4 倍，但速率只翻了 3.7 倍左右，原因就是开销更高、PRB 效率略低。这个现象说明一件事：加大带宽不是线性收益，频段越高，为对抗物理损伤付出的开销越大。

3.3 场景三：上行速率与 TDD 配比的折减

上行参数：100MHz，30kHz，273 PRB，2 层（终端上行双流），64QAM（Qm=6），码率 0.9258，开销 8%。

45864 × 6 = 275184 bit 275184 × 0.9258 = 254765 bit 254765 × 0.92 = 234384 bit 234384 × 2 = 468768 bit 468768 ÷ 0.0005 = 937536000 bit/s ≈ 0.94 Gbps

上行峰值约0.94Gbps。如果终端支持上行 256QAM，能到 1.25Gbps 左右，但实际网络里上行 256QAM 的开启比例不高，主要是终端发射功率受限，很难在功控下维持那么高的 SINR。

TDD 制式还要考虑上下行配比。假设用的是 2.5ms 周期、DDDSU 结构（3 个下行时隙 + 1 个特殊时隙 + 1 个上行时隙），特殊时隙按 10:2:2 配置（10 个下行符号、2 个保护符号、2 个上行符号）：

每 2.5ms 下行可用符号 = 3 × 14 + 10 = 52 满配符号数 = 5 × 14 = 70 下行时间占比 = 52 / 70 ≈ 0.743

把场景一的结果乘上去：

2.34 Gbps × 0.743 ≈ 1.74 Gbps

这就是考虑 TDD 配比后的下行平均峰值，约1.74Gbps。这也解释了为什么很多外场 100MHz 站点的下行峰值实测在 1.5 到 1.7Gbps 之间——不是设备不行，是这个配比本来就该是这个数。想让峰值更高，就得往下行倾斜配比，比如换成 4:1 甚至更激进的配置，代价是上行容量被压缩。

3.4 反推：从目标速率倒推该怎么配

实际工作中更常见的需求是反过来的：客户要求单用户下行不低于 1.2Gbps，该怎么配？

先把目标转成单时隙比特数：

1.2e9 × 0.0005 = 600000 bit/时隙

再除回去：

600000 ÷ 45864 RE = 13.08 bit/RE

这显然超过单个 RE 最多 8 bit 的物理上限，所以必须靠层数。除以码率和开销修正：

600000 ÷ 0.9258 ÷ 0.86 ÷ 45864 = 16.4

也就是说，Qm × 层数的乘积至少要 16.4。可选组合有：

这张表的用处在于：达到同一速率，路可以走两条，但对网络的要求完全不同。选 4 层 16QAM，需要基站有足够通道数和终端支持 4 层；选 2 层 256QAM，硬件要求低但信道质量要求高，边缘用户基本没戏。做规划时这个取舍必须想清楚，否则配置下去发现终端只支持 2 层，整个测算就废了。

4. 常见问题与排查技巧实录

算出来和测出来对不上，是最常见的场景。这一节把遇到的典型问题整理出来，附上排查顺序。

4.1 实测只有理论值的六成，按这个顺序查

第一查终端能力。这是最高频的原因。终端支持的最大层数、最大带宽、最高调制，任何一个低于网络配置，整个上限就被它卡住。很多物联网模组标称支持 100MHz，实际只支持下行 2 层且不开 256QAM，那峰值就只剩 0.88Gbps 左右，跟网络侧配置毫无关系。

第二查调度占比。理论峰值假设 100% 的 PRB 都被调度给这一个用户。实际网络中，控制信道、系统消息、其他用户、测量参考信号都会占资源，单用户能拿到的 PRB 比例通常在 80% 到 90%。这一项直接按比例折减就行。

第三查 MCS 分布。理论峰值假设全程最高阶调制。实际要看路测数据里的 MCS 直方图，如果 256QAM 占比不到 30%，说明信道条件撑不住，此时应该用加权平均 Qm 去估算，而不是用 8。

第四查帧结构。TDD 配比、特殊时隙符号分配、是否配了上行增强，都会影响下行的有效符号数。这一项在场景三里已经算过，不做折减就会高估 25% 以上。

第五查传输层因素。基站到核心网的带宽、测试服务器的位置、TCP 参数、是否用多线程，这些不属于无线侧但一样会卡住峰值。我见过一个案例，无线侧明明能跑到 1.6Gbps，测试结果死活卡在 900Mbps，最后发现是测试用的服务器网卡是千兆的。

心得：排查时建议按“终端 → 调度 → 调制 → 帧结构 → 传输”的顺序，从最不可控的一项开始。终端能力是最硬的约束，先把它排除掉，后面才有意义。

4.2 参数误用速查表

这张表放在手边，大部分对不上的情况能在一分钟内定位。

4.3 几个踩过才知道的细节

特殊时隙的符号分配经常被忽略。2.5ms 周期下的特殊时隙，如果配成 6:4:4，下行只有 6 个符号能传数据，比 10:2:2 少 40%。这个参数在下发配置时经常沿用默认值，做容量测算时一定要去查实际配置。

载波聚合不是简单相加。多个载波聚合时，每个载波的开销、参考信号配置都要单独算，而且聚合后的调度效率会有损失，实际峰值通常是各载波理论值之和的 90% 到 95%。

双边带和单边带的算法不一样。有些毫米波设备用两个 200MHz 载波拼成 400MHz，这时 PRB 数是两个 264 相加还是按 400MHz 单载波算 264，结果差一倍。做设备对比时必须先统一口径。

上行增强会改变上行峰值。如果网络配了补充上行频段，上行的可用资源会增加，但补充上行频段通常带宽较小、子载波间隔不同，需要单独算一遍再加上去，不能直接对上行峰值乘系数。

5. 把计算固化成表格和脚本

手算一遍是为了理解，长期用还是要固化下来。这一节给一份参数模板和一段能直接跑的脚本。

5.1 参数记录模板

每次做测算，建议按这个格式把假设记全，否则三个月后回头看根本不知道当时是怎么算的。

这张表的价值不在于好看，而在于可追溯。任何一个数字被质疑，都能顺着来源查到依据。

5.2 一段可复用的计算脚本

Python 写一段，参数化之后换配置只需要改一行：

def peak_rate(prb, scs_khz, symbols, layers, qm, code_rate, overhead): slot_ms = 1.0 / (scs_khz / 15) # 时隙时长，随 SCS 反比变化 re_total = prb * 12 * symbols # 单层 RE 总数 bits = re_total * qm * code_rate * (1 - overhead) return bits * layers / (slot_ms / 1000) / 1e9 # 单位 Gbps # 场景一：中频段 100MHz 下行 4 层 256QAM print(peak_rate(273, 30, 14, 4, 8, 0.9258, 0.14)) # ≈ 2.34 # 场景二：毫米波 400MHz 下行 4 层 256QAM，开销 18% print(peak_rate(264, 120, 14, 4, 8, 0.9258, 0.18)) # ≈ 8.62 # 场景三：上行 100MHz 2 层 64QAM，开销 8% print(peak_rate(273, 30, 14, 2, 6, 0.9258, 0.08)) # ≈ 0.94 # TDD 配比折减 tdd_ratio = (3 * 14 + 10) / (5 * 14) print(peak_rate(273, 30, 14, 4, 8, 0.9258, 0.14) * tdd_ratio) # ≈ 1.74

这段代码跑一遍就能验证前面的手算结果。把prb和scs_khz换成别的组合，就能快速扫出一张速率对照表。做方案对比时，我习惯把候选配置一次性全跑出来，排个序，比一项一项手算快得多。

提示：脚本里slot_ms = 1.0 / (scs_khz / 15)这一行是按 15kHz 为基准做的换算，只在正常 CP 下成立。如果要用扩展 CP，符号数要单独改成 12，别直接套。

我个人在实际操作中的体会是，峰值速率这个数字本身不难算，难的是把假设说清楚。同一套网络，按终端能力算和按基站能力算能差一倍，按满配帧结构算和按实际配比算能差 25%，按 14% 开销算和按 18% 开销算在毫米波上能差 0.4Gbps。所以每次给别人报数字，我都会把那张参数表一起发过去——不是为了显得专业，是为了省掉后面来回扯皮的时间。这个习惯用了几年，确实少踩了不少坑。