企业官网建设流程全解析

5G峰值速率这个题目，几乎是每个做无线网络规划、终端测试、或者刚入行做通信产品的人都会碰到的一道必答题。宣传物料上写着几个Gbps，手机测速软件跑出来一两百Mbps，客户拿着两个数字来问你怎么解释——这种场面我经历过不止一次。峰值速率本身并不是一个“实际网速”指标，它是一个理论资源上限，是把一段频谱在理想条件下榨干之后能得到的天花板数值。搞不清楚这个天花板是怎么算出来的，就没法判断一次测试结果到底是网络不行、终端不行，还是本来就应该这样。

这篇内容围绕5G峰值速率的计算展开，从帧结构和时频资源的最小单位讲起，把PRB、子载波、OFDM符号、调制阶数、码率、MIMO层数这几个变量怎么乘在一起推导清楚，再给几组Sub-6G和毫米波的完整算例，最后讲理论值和实测值之间那段落差该怎么逐层排查。适合刚接触NR物理层的新人、需要写测试报告和方案文档的工程师，也适合做网络规划、想弄明白带宽和PRB数量对应关系的老手。基础概念我会补，但推导过程不会含糊，因为这道题最怕的就是“大概知道”。

1. 峰值速率考的是资源上限，不是网速体验

1.1 同一部手机跑出三个数字，问题出在哪

先把一个常见误解掰开。很多人把峰值速率理解成“网络能给单个用户的最快速度”，于是拿它和测速软件结果对不上就觉得哪里出了问题。实际上峰值速率的定义更接近“在协议允许的最优配置下，这条链路每秒最多能搬运多少个比特”，它假设了所有可用时频资源全部用于承载用户数据、调制方式取到最高阶、编码码率取到最大、MIMO层数拉满、且没有任何重传和调度等待。现实网络里这几个条件几乎不可能同时满足，所以实测值通常只有理论峰值的百分之二三十，基站负载高的时候甚至更低。

我在给非技术同事解释这件事时喜欢用高速公路做类比。峰值速率算的是“车道数乘以限速再乘以每辆车能装多少人”，它描述的是这条路的物理运力上限；而你实际开车时的平均车速，还取决于前车多不多、有没有事故、收费站排队多久。你不能因为某天堵车就断定这条路只有双向两车道，也不能因为设计图纸写了八车道就要求天天开满速。把峰值速率和用户感知速率混为一谈，是这类讨论里最常见的第一层误解。

第二层误解在于带宽。有人觉得带宽翻倍速率就翻倍，这话在理想条件下大致成立，但带宽和PRB数量之间不是线性整数关系，中间还隔着保护带宽和栅格对齐。比如100MHz带宽在30kHz子载波间隔下能塞273个PRB，但同样是100MHz在15kHz子载波间隔下就是270个PRB，如果换成60MHz带宽则只有162个PRB。这些数字不是拍脑袋定的，是协议表格里查出来的，用错一个数字，算出来的峰值就能差出一大截。所以真正需要记住的第一件事是：算峰值速率之前，先把带宽、子载波间隔、PRB数量这三者的对应关系查准。

1.2 把峰值速率拆成时间、频率、空间三把尺子

我更愿意把5G峰值速率的计算拆成三个维度来理解，这样即使公式记不全，也能凭逻辑把结果估个八九不离十。

时间维度回答的是“每秒有多少个可用的传输机会”。5G NR的一帧固定是10毫秒，一帧分成10个子帧，每个子帧1毫秒。子帧再往下切时隙，切多细取决于子载波间隔：15kHz时一个时隙1毫秒，一帧10个时隙；30kHz时一个时隙0.5毫秒，一帧20个时隙；60kHz时0.25毫秒，120kHz时0.125毫秒。换算成每秒钟的时隙数就是1000、2000、4000、8000。子载波间隔越大，时隙越短，每秒能调度的次数越多，这对降低时延很有好处，但每个时隙里能用的符号数并不变，正常循环前缀下都是14个OFDM符号。

频率维度回答的是“每次传输能占用多少个子载波”。一个PRB固定包含12个子载波，这是从LTE延续下来的设计。所以一个时隙内、一个PRB上，理论上有12乘以14等于168个资源粒子，业内叫RE。这个168是所有后续计算的基数，记住它，很多推导就能自己走通。

空间维度回答的是“同一份时频资源能重复利用几次”。MIMO层数就是干这个的，4层意味着同一批RE上并行发送4路独立数据流。这一维度是最容易被忽略又最影响结果的，因为层数从2提到4，峰值速率直接翻倍，而带宽只从100MHz提到200MHz在Sub-6G频段根本做不到。

把三个维度串起来，就得到了一条主干逻辑：每秒时隙数乘以每时隙的RE数，得到每秒的RE总量；每个RE能承载多少比特由调制阶数和码率决定；最后乘以层数。这条链路清楚了，后面所有的算例都只是往里面填参数。

2. 一个时隙能装多少比特的完整推导

2.1 帧结构决定了每秒有多少次传输机会

先把帧结构这张底图铺好。5G NR沿用10毫秒的无线帧，这一点和LTE一致，目的是保持和既有系统的帧对齐，方便双连接和共存。区别在于子载波间隔不再固定为15kHz，而是支持15、30、60、120、240kHz这几档，协议里用参数μ来标识，μ等于0对应15kHz，μ等于1对应30kHz，以此类推，每升一档子载波间隔翻倍。

时隙长度和μ的关系是除以2的μ次方毫秒。μ=0时1毫秒，μ=1时0.5毫秒，μ=2时0.25毫秒，μ=3时0.125毫秒。每秒的时隙数则正好反过来，是1000乘以2的μ次方。这个数量关系在写代码时特别好用，因为只要知道子载波间隔，除以15就得到了2的μ次方这个倍数因子，不用再去查表。

这里有个细节很多人会栽跟头：时隙变短了，但每个时隙里的OFDM符号数并没有变，正常循环前缀下始终是14个。也就是说，30kHz的子载波间隔带来的不是“每个时隙装更多东西”，而是“同样一段时间里装了更多个时隙”。符号长度本身随着子载波间隔增大而缩短，所以总的时频资源密度其实是不变的。理解了这一点，就不会误以为高频段靠加大子载波间隔能凭空变出更多容量。

还有一个容易忽略的是特殊时隙和帧结构配置。TDD制式下，一个周期内上下行的时隙配比会直接影响可用于下行数据传输的时隙数。理论峰值一般按“全部时隙都用于下行”来算，这也是理论值和实测值产生差距的原因之一。做规划时如果只按理论峰值估算容量，再乘以一个拍脑袋的系数，很容易高估，因为上下行配比这一刀砍下去，可用资源可能直接少掉三到四成。

2.2 PRB、子载波与符号：时频资源怎么数才不出错

资源块这个概念从LTE一路继承下来，一个PRB在频域上占12个连续子载波。为什么是12而不是16或者别的数，简单说是在频谱利用率和实现复杂度之间取的折中，12个子载波既能保证一定的资源调度颗粒度，又不至于让控制信令的开销过于庞大。这个数字在5G里没有改，所以很多LTE时代的资源计算直觉可以直接迁移过来。

一个时隙内，一个PRB上理论可用168个RE。但要注意，这168个是包括参考信号、控制信道等所有用途在内的总数，真正能拿来做业务数据传输的没这么多。协议在估算峰值时并不会逐个扣掉这些位置，而是统一用一个开销比例来折算，这一点放到第4节细讲。

再看带宽和PRB的对应。这个必须查协议表格，不能凭带宽除以子载波间隔再除以12来算，因为两边都有保护带宽，不同带宽的保护带宽还不一样，而且PRB数量还要满足一些特定的约束。下面这张表是常会用到的一部分，实际项目里建议直接翻标准原文核对。

看这张表能发现一个反直觉的点：同样是100MHz，用30kHz子载波间隔能拿到273个PRB，用60kHz却只有132个。原因在于子载波变宽之后，虽然每个PRB占的带宽变大了，但同样的总带宽里能容纳的PRB数量就少了，而且保护带占比也不同。所以“带宽越大峰值越高”这句话没错，但“子载波间隔越大峰值越高”就完全错了，恰恰相反，在同样带宽下，子载波间隔小的那一侧PRB更多，理论峰值更高。

那为什么毫米波要用120kHz？因为高频段相位噪声大，子载波必须做宽才能抵抗相位噪声带来的影响，同时宽子载波也让波束扫描和快速调度的符号粒度更细。这是典型的工程取舍，牺牲了单载波的资源块数量，换取了射频上的可实现性和更短的调度周期。理解了取舍逻辑，就不会拿着400MHz带宽却按273个PRB去算，得出一个虚高的数字。

2.3 调制阶数、码率和层数决定每个RE的含金量

调制阶数Qm的含义是每个RE能承载的比特数，QPSK是2，16QAM是4，64QAM是6，256QAM是8。理论上讲，调制阶数越高，单位资源承载的比特越多，但对信噪比的要求也越苛刻。256QAM需要很高的信噪比才能稳定解调，所以在小区边缘几乎不会用上，这也是为什么实测速率在近点和远点差别巨大的原因之一。

码率指的是信道编码后有效信息比特占总编码比特的比例。5G NR用的是LDPC码，下行数据信道的目标码率范围很宽，从低码率到接近1都有对应的MCS等级。计算理论峰值时，取的是最高MCS等级对应的码率，常见取值是948/1024，约等于0.9258。有些资料会直接用0.93这个近似值，差别不大，但如果要做精细对比，建议还是用分数形式。

层数L就是MIMO的并行数据流数。下行理论峰值计算中，Sub-6G的典型配置是4层，毫米波早期多是2层后来也有4层，上行一般是1到2层，部分场景支持更多。层数对结果的影响是一次方的线性关系，所以是最敏感的一个参数。我在审阅内部方案文档时见过好几次把“4T4R”和“4流”当成一回事的写法，实际上4T4R说的是射频通道数，能不能真的跑4层还要看终端能力、信道条件和调度策略。天线端口数、通道数、层数这三个概念一定要分清。

把上面这些串起来，单个载波的理论峰值公式可以写成这样：

每秒比特数 = PRB数 × 12 × 14 × 每秒时隙数 × Qm × 码率 × 层数 × 开销系数

公式里每一项都能在上面找到出处，没有含糊的地方。如果只想要一个不考虑开销的理想上限，把开销系数取1；如果要贴近协议估算口径，就代入对应的开销比例。两种口径的差异在第3节和第4节会分别算给你看。

2.4 把公式写成能跑的计算脚本

手算容易出错，尤其是PRB数量和时隙数这种查表得来的数字，抄错一位整个结果就废了。我习惯在项目里放一个小脚本，需要对比不同配置时直接改参数跑一下，比翻Excel表格快得多。

def peak_rate_mbps(prb, scs_khz, layers, qam, code_rate=948/1024, overhead=0.14): """ 计算单载波理论峰值速率，返回 Mbps prb: 带宽对应的PRB数量 scs_khz: 子载波间隔，单位 kHz layers: MIMO 层数 qam: 调制阶数对应的 Qm（QPSK=2, 16QAM=4, 64QAM=6, 256QAM=8） code_rate: 最高MCS对应的码率 overhead: 协议估算预留的开销比例 """ slots_per_sec = 1000 * (scs_khz / 15) re_per_slot = prb * 12 * 14 useful_re = re_per_slot * (1 - overhead) bits_per_slot = useful_re * qam * code_rate * layers return bits_per_slot * slots_per_sec / 1e6 # Sub-6G: 100MHz @ 30kHz, 4层, 256QAM print(round(peak_rate_mbps(273, 30, 4, 8), 1)) # 毫米波: 400MHz @ 120kHz, 2层, 256QAM print(round(peak_rate_mbps(264, 120, 2, 8, overhead=0.18), 1))

这段代码里唯一需要我自己确认的是开销量。协议在估算峰值时对不同频段取了不同的固定开销比例，业界常见的口径是Sub-6G约0.14、毫米波约0.18。这个值不是让你去精算每个参考信号的位置，而是一个统一的折算因子，目的是让不同厂家上报的能力值有可比性。如果要算不含开销的物理上限，把overhead传0进去就行。

我建议在脚本里再加一个函数，专门算多载波聚合后的总和，因为现在的商用网络几乎没有单载波跑满的场景，载波聚合是提升峰值最直接的手段。

def ca_total(rate_list): """载波聚合总峰值，参数为各载波峰值列表（Mbps）""" return round(sum(rate_list), 1) print(ca_total([2337.0, 1100.0])) # 两个载波叠加示例

代码很简单，但省去了反复按计算器的麻烦。真正有价值的不是这几行代码本身，而是它把公式里每个参数的物理含义固定下来了，后面讨论任何一次实测结果，都能回到这几个变量上找差异。

3. 三组完整算例：Sub-6G、毫米波与载波聚合

3.1 100MHz三十千赫四流：2.3到2.7 Gbps的区间从哪来

这是目前商用网络里最常见的一个配置，也是讨论最多的一组数字。参数如下：带宽100MHz，子载波间隔30kHz，对应273个PRB，每个时隙14个符号，4层MIMO，256QAM，码率取948/1024。

先算每秒的资源粒子总量。一个时隙内可用RE是273乘以12再乘以14，得到45864个。30kHz下每秒有2000个时隙，所以每秒的RE总量是91,728,000个。这个数字看着很大，但每个RE承载的比特有限，真正的结果还得乘上调制和码率。

每个RE在256QAM下承载8比特，乘以码率0.9258后约为7.4比特，再乘以4层，就是每个RE位置等效承载约29.6比特的信息。45864乘以29.6再乘以2000，得到约2.72Gbps。这是不扣任何开销的物理上限。

如果按Sub-6G常见的14%开销折算，有效RE变成45864乘以0.86，约39441个。重新算：39441乘以8乘以0.9258乘以4乘以2000，得到约2.34Gbps。这就是很多资料里写的“100MHz四流理论峰值2.3Gbps左右”的由来。

两个数字差了不少，根源就在开销量。所以当有人拿着2.7Gbps的数字来质疑实测为什么只有几百兆时，先问清楚他引用的口径是含开销还是不含开销，很多争论到这一步就散了。我个人在写方案文档时习惯两个都给，注明物理上限和协议估算口径，避免后续被反复追问。

再补一个上行视角。假设上行同样是100MHz带宽273个PRB，但只支持1层、256QAM，开销同样14%，那么结果是约584Mbps。如果支持2层上行，能到1.17Gbps左右。上行峰值普遍远低于下行，这是TDD制式下终端发射能力受限导致的，也是为什么上传大文件时速度感觉明显不如下载。

3.2 400MHz一百二十千赫双流：毫米波单载波上限

毫米波的配置和Sub-6G差别很大。以400MHz带宽、120kHz子载波间隔为例，对应264个PRB，每秒8000个时隙，2层MIMO，256QAM。

一个时隙的RE数：264乘以12乘以14，等于44352。每个RE承载8比特乘码率，约7.4比特，乘2层得到约14.8比特。44352乘以14.8再乘以8000，得到约5.26Gbps，这是不含开销的上限。

按毫米波常见的18%开销折算，有效RE是44352乘以0.82，约36369个。最终结果约4.31Gbps。如果毫米波也上到4层，这个数会翻倍到8.6Gbps左右，但4层毫米波对信道条件要求很高，实际部署中能不能稳定跑起来是另一回事。

把Sub-6G和毫米波两组数字摆在一起，能看出一个有意思的对比：毫米波单载波带宽是Sub-6G的4倍，但PRB数量只从273涨到264几乎没变，因为它用了更宽的子载波。真正让毫米波峰值更高的是带宽和时隙数的组合效应，加上高频段更容易做大规模天线阵列从而支持更多层。这也解释了为什么毫米波在实验室里动辄跑出几个Gbps，但覆盖一收缩就迅速掉速——高频段的传播损耗决定了它很难在移动状态下维持高阶调制和多层传输。

3.3 载波聚合后的理论叠加与真实损耗

单载波再猛也有上限，Sub-6G频段一段连续100MHz已经是奢侈配置，所以载波聚合是提升峰值的必由之路。理论上的叠加很简单，各载波峰值直接相加，比如两个100MHz四流载波，理论上是2.34乘以2约4.68Gbps（按含开销口径）。

但载波聚合的实际效果和理论叠加之间有几处必然的折损，这里必须说清楚，否则又会被拿去和实测对比。

第一处是各载波的带宽和PRB配置可能不一致。聚合的载波往往不是规整的100MHz，可能是60MHz加40MHz，对应162加106个PRB，加起来268个，比单载波273还少几个。带宽数字看着一样，PRB总数却对不上，这是很常见的坑。

第二处是跨载波的调度和终端处理能力。终端同时处理多个载波需要更多的基带资源，处理能力和功耗都会成为约束，实际能激活的载波数和层数组合是有上限的。协议里对载波聚合的各种组合都有明确的终端能力定义，不是基站想配几个就能配几个。

第三处是各载波的调制和层数往往不同。低频载波可能跑4层256QAM，高频载波可能只有2层64QAM，直接把各载波的理论最大值相加会明显高估。正确的做法是按每个载波的实际配置分别计算再求和，而不是用“最大配置乘以载波数”。

我做过一个对比，同样是标称“多载波聚合”的两套方案，一套是2个100MHz，一套是100MHz加60MHz加40MHz，前者PRB总数546，后者是273加162加106等于541，理论上只差不到1%，但实际配置中后者的调度灵活性和终端支持度差别很大。这说明光看峰值数字做选型是不够的，还得看具体的PRB结构和终端能力支持情况。

4. 理论峰值里被理想化掉的那些开销

4.1 控制信道、参考信号与同步广播各占多少

前面一直用统一的开销比例来折算，这里把这个比例背后的东西摊开讲。一个时隙里的14个符号并不是全部用来传业务数据的，下面这些用途都要占位置。

解调参考信号是其中占比最大的。它穿插在数据中间，用于信道估计，层数越多需要的参考信号资源越多。下行控制信道占用每个时隙开头的若干符号，具体数量取决于调度了多少个终端，理论峰值计算假设的是一种较优的配置。同步广播块是周期性出现的，虽然不在每个时隙都占位置，但摊到平均值上也是一块固定开销。此外还有信道状态信息参考信号、相位跟踪参考信号等，在特定配置下才会出现。

把这些逐项精确扣除是非常繁琐的，而且不同厂家的实现、不同调度策略下的占用都不一样，所以协议不去做逐项精算，而是给出一个约定的开销比例，确保大家在同一个口径下比较。这个做法的好处是可比性强，坏处是它和任何一个具体网络的真实开销都不完全相等。

我在实际项目里做过粗略的对照：在某些调度负载较轻、参考信号配置较精简的场景，真实开销可能低于协议假设的14%；而在多用户调度密集、控制信道占用较多的场景，开销可能超过20%。这意味着用协议口径算出来的2.34Gbps，在某些网络里对应的是二十几个百分点的实际折损，在另一些网络里则可能更接近真实可用上限。所以理论峰值不能直接当作容量规划的依据，必须结合现网的调度策略和负载情况做修正。

提示：做容量估算时，不要用理论峰值乘一个笼统的系数。更稳妥的做法是拿现网同一配置下的实测吞吐量做基准，再按带宽和层数的变化做比例外推，这样得到的数字可信度高得多。

4.2 协议口径和厂家口径为什么总是差一截

这件事我吃过亏。早年参与一个测试评估，三方给出的峰值数字对不上，各自都说自己是对的，最后发现是三个不同的计算口径。

协议口径是前面讲的这种，按统一的公式和开销比例算，目的是给终端能力上报一个标准化的参考值，它强调的是可比性和可重复性。厂家口径往往更偏向“物理上限”，把开销取到最小甚至取零，这样宣传数字更漂亮。还有一种口径是按特定配置算的，比如指定了控制信道符号数、指定了参考信号密度，算出来的数字介于两者之间。

三种口径都谈不上错，问题在于混用。我现在的习惯是在任何一份涉及峰值的文档里，第一句就写清楚采用的口径和关键假设，包括带宽、子载波间隔、PRB数、层数、调制、码率、开销比例。这七项写全了，别人拿去复算能对上，就不会有争议。

还有一点值得提醒：理论峰值的计算里通常假设了理想信道条件，也就是信噪比足够高、足以支撑最高阶调制和最大层数。真实信道里，调制和层数是动态调整的，近点跑256QAM四层，走到小区中部可能就掉到64QAM两层，理论上限还在，但实际用不上。这个动态调整机制本身就是为了在可靠性和速率之间找平衡，不是网络“不给力”。

5. 实测对不上理论值时按这个顺序查

5.1 先核对终端能力和频段组合是否匹配

拿到一个明显偏低的实测结果，我的排查顺序是从最不容易改的地方往最容易改的地方走。第一站永远是终端能力。

终端支持的频段组合、载波聚合组合、最大层数、最高调制方式，这些都写在能力上报里。如果终端本身只支持2层、只支持64QAM，那无论网络侧配置成什么样，峰值都不可能达到按4层256QAM算出来的数字。这种情况在测试早期特别常见，拿了一台能力有限的样机去测网络的理论峰值，测不出来就怀疑网络，方向一开始就错了。

具体怎么核对：抓取终端的注册和连接建立信令，找到能力上报部分，看它声明的最大MIMO层数、支持的调制方式、以及是否支持当前频段的带宽。这三项对上了，再往下走。如果对不上，结论很清楚，换终端或者调整测试预期，不用再查网络。

第二站是网络侧的配置。基站配置的载波数量、带宽、上下行时隙配比、MIMO模式，这些都会直接限制实测峰值。我遇到过配置里没开最高阶调制的情况，理论上限直接砍掉一档。还遇到过载波聚合配了但实际没有激活的，名义上三个载波，实际只用了一个。

这两站走完，如果配置层面都对得上，才进入第三站看实际调度。

5.2 看调度和MIMO是不是真的跑起来了

配置对了不代表实际就用上了。调度器是根据信道质量和资源情况动态决策的，很多原因会导致它保守行事。

最常见的是信道质量不够。信号强度不足或者干扰较大时，调度器会主动降阶降层来保证误块率，这时候速率上不去是正常行为，不是故障。判断方法是同时看参考信号接收质量和信噪比，如果这些指标偏低，先解决覆盖和干扰问题，别在速率上纠结。

第二类是资源不够。理论峰值假设的是整个带宽的所有PRB都分配给了这一个终端，实际网络里如果有其他用户，资源要分给多人，单用户能拿到的比例自然下降。做单用户峰值测试时，通常要选在负载很轻的时段和小区，这一点在测试方案里必须写明，否则结果没法解释。

第三类是调度策略本身就没打算跑满。有些网络为了兼顾时延和公平性，会对单用户的最大调度资源做限制，或者优先保证调度频次而不是单次分配量。这类策略从网络整体效率看是合理的，但会让单用户峰值测试的结果偏低。这种情况需要和网络侧确认配置策略，不能简单判定为性能问题。

第四类是重传和误块。如果误块率偏高，大量资源被重传占用，有效吞吐自然下降。这个在测试日志里的表现是重传次数异常，结合误块率指标一起看就能定位。

5.3 服务器、传输和协议栈这些非无线瓶颈

这一条我单独拎出来说，因为它是最容易被忽略、又最容易背锅的一块。无线侧一切都对，结果测出来只有几百兆，最后发现是测速服务器上行带宽不够，或者测试终端的网卡、USB接口成了瓶颈，又或者传输网的带宽配置没有跟上。

具体怎么排除：先做本地环回或者用内网服务器测，绕开公网的不确定性。再看测试终端的硬件接口，很多测试设备的有线口只有千兆，而实测速率已经接近千兆，那测量结果本身就不可信。还要确认传输侧给这个基站分配的带宽是否足够，一个几Gbps的理论峰值，如果回传只有1Gbps，那测出来的上限就是1Gbps。

协议栈层面也有影响。TCP的拥塞控制、窗口大小、往返时延，都会让单条TCP流跑不满带宽。测峰值通常要多流并发，单流测试跑出来的数字不能直接和理论峰值比。这一点在写测试报告时要说清楚，否则读者会误以为无线侧有问题。

下面这张表是我平时用的排查对照，按顺序走一遍基本能覆盖大部分情况。

6. 几个我踩过的计算坑

6.1 单位换算和PRB表用错是最常见的翻车点

第一个坑是单位。RE数、比特数、时隙数一路乘下来，得到的单位是比特每秒，但写报告时习惯用Mbps，中间要除以10的6次方。我见过有人在中间某一步把毫秒当秒用，结果差了三个数量级，算出来几个Tbps还浑然不觉。防这种错的办法很简单，算完之后做个数量级合理性检查：Sub-6G单载波100MHz四流，结果应该落在2到3Gbps这个区间，如果一个数量级都不对，肯定是单位出问题了。

第二个坑是PRB数量。不同带宽、不同子载波间隔对应的PRB数必须查表，绝对不能自己算。我自己就犯过一次，拿100MHz除以30kHz再除以12，得到约277，和正确的273差了4个。4个PRB看起来不多，乘以其他参数后误差也有1.5%左右，做精确对比时这个误差不能接受。更麻烦的是有些带宽的保护带配置特殊，自己算出来的数字可能差得更多。

第三个坑是层数的理解。前面提过，天线端口数、射频通道数、传输层数是三个不同的概念。设备规格上写4T4R，指的是4个发射通道4个接收通道，能不能跑4层还取决于终端能力和信道条件。把通道数直接当层数代进公式，是初学者最容易犯的错。我的建议是，凡是看到“多少T多少R”的描述，都单独确认一下对应的最大传输层数。

第四个坑是上下行配比。TDD系统里，理论上行和下行共用同一段频谱，按时间分开。如果直接按全部时隙都用于下行来算峰值，得到的是一个不可实现的数字。正确做法是先确认帧结构配置，算出下行可用的时隙比例，再乘进去。当然，作为“理论峰值”的定义，很多资料默认就是按全下行算的，但你要清楚自己在算什么，别把这个数字当成下行的实际可用上限。

6.2 别把理论峰值直接当容量指标用

这个坑不是计算层面的，是理解层面的，但影响更大。

理论峰值描述的是一条链路在最优条件下的极限，它不包含多用户并发、不包含调度开销、不包含重传、不包含控制面信令。拿它去做小区容量规划，结果一定偏乐观。我见过按理论峰值乘以用户数来估算小区承载能力的做法，得出的结论和实际相差好几倍。

合理的做法是把容量估算分成几层：物理层理论峰值作为天花板，扣掉协议开销得到可用峰值，再按实际调度效率和信道分布打折扣得到单用户平均吞吐，最后按多用户调度和公平性再折一次，得到小区级容量。每一层的折损系数都应该来自现网实测或者可靠的仿真，而不是拍脑袋。

另外要提醒的是，不同业务对速率的需求形态完全不同。峰值速率这个指标对下载大文件、视频缓存这类场景有意义，对网页浏览、即时消息这类小包业务，用户感知更多取决于时延和连接建立速度，而不是峰值。做网络优化时如果一味盯着峰值数字，很可能在用户真正在意的地方投入不足。

我个人在实际操作中的体会是，峰值速率计算这件事最大的价值不在于算出那个数字，而在于它逼着你把整条链路上的每个环节都过一遍。带宽怎么配、子载波间隔怎么选、层数能上几层、调制能到多高、开销占多少、终端支不支持，这些问题在算的过程中会一个个浮出来。很多时候算完一遍，方案里原本模糊的地方就清晰了，该调整的配置也就知道往哪个方向调了。至于最后那个数字对不对得上宣传物料，反而是次要的。