企业官网建设流程全解析

1. 为什么LTE上行总是“心有余而力不足”

1.1 上行受限于终端发射功率，而不是基站能力

很多做过LTE网优的朋友都有这种感觉：下行速率轻轻松松跑到50Mbps、100Mbps，甚至更高，可一测上行，10Mbps、20Mbps经常就是天花板。上传个视频、发几张原图，都要转半天圈。问题通常不在基站不努力，而在终端这个“小身板”先天受限。

LTE上行用的是SC-FDMA，单载波特性决定终端只能在一个连续的频段上发射。终端发射功率普遍只有23dBm（约200mW），配上手机天线增益，真正的等效全向辐射功率很有限。基站虽然可以做到80W、100W，可上行信号是终端发、基站收，终端功率天然是瓶颈。再加上LTE的上行只能单天线发射（初期），没有波束赋形增益，覆盖稍远一点，上行信噪比就掉得厉害，调制等级被迫一降再降。我用QXDM看log时见过不少次：下行MCS还在20多，上行MCS已经跌到6、7，吞吐率自然上不去。

所以，我们常说的“覆盖受限”，其实多数是上行受限。下行覆盖不够还可以靠基站调大功率、挂塔放，上行受限只能靠终端“自己努力”。这也是NR要花大力气解决的核心矛盾之一。

1.2 LTE PUSCH的“细长型”时频结构

PUSCH（Physical Uplink Shared Channel，物理上行共享信道）是承载用户上行数据的“主车道”。LTE的PUSCH在时域上占一个子帧（1ms），在频域上由多个RB（Resource Block，资源块）组成，每个RB是180kHz，包含12个子载波。结构上它特别“细长”：1ms间隔里，一个RB只有12×14=168个RE（资源单元）。如果只给5个RB，总共才840个RE，去掉参考信号，能塞的业务数据非常有限。

更尴尬的是，LTE的PUSCH上行在每个子帧里只能由单用户独占一个频域块，不能像下行那样多个用户平滑复用同一资源块上的不同层。也就是说，同样的5MHz带宽，下行可以同时“喂”好几个用户，上行却极易出现资源碎片。这种“细长型”结构意味着：调度器必须非常精细地给每个用户分配RB数，RB少了吞吐率不高，RB多了又可能导致功率谱密度下降，覆盖变差。这其实是LTE上行“受限”的结构性根源之一。

LTE PUSCH还有一个特点：它的解调参考信号（DMRS）通常只占第4个OFDM符号，只在有数据时才发送。这个设计在信道平坦时没问题，一旦用户移动速度变快，信道时变增强，仅靠一个符号上的DMRS做信道估计，误差就会明显增大，直接影响上行MCS选择，最终表现为上传速率频繁波动。

1.3 上行调度链路：SR、UL Grant、PUSCH一个都不能少

上行数据不是想发就发的。LTE/LTE-A里，终端要发送上行数据，需要先走一遍调度握手：

• 终端有数据要发，先在PUCCH上发送调度请求（SR，Scheduling Request）；
• 基站收到SR后，在PDCCH上给终端下发UL Grant，告诉它“你可以用哪些RB、用什么MCS、什么功率发射”；
• 终端收到Grant后，在对应资源上通过PUSCH把数据发出去；
• 如果解码不成功，基站反馈NACK，终端再在下一个可用子帧重传。

这串流程里，每一个环节都可能成为瓶颈。SR周期配置长了，调度时延就大；PDCCH的DCI格式0/4承载的Grant信息如果链路预算不足，终端可能根本解不出来；Grant里分配的RB数、MCS是否合理，直接决定了实际速率。

我实测过一种很普遍的情况：一个用户开了多个业务流，上行乱序严重。原因就是SR触发条件设置得太保守，终端迟迟不发SR，基站以为你没需求，久而久之缓存积压。后来把SR周期缩短到5ms、并打开上行“非周期调度”后，上传小包明显顺滑了很多。这个调度链路的认知，对理解后面NR的上行增强非常关键——NR其实在走同样的逻辑，只是把每个环节都“提速”了。

1.4 多卡终端的上行冲突：卡一通话中卡二发彩信为什么更难

热搜词里有一条很有意思：“在LTE环境下卡一通话中用卡二发彩信”。这听起来像个终端场景，但背后恰恰是PUSCH调度与射频前端冲突的典型案例。

先说明一下，彩信走的是数据域，通话（如果是CS语音或VoLTE）占用的是语音域或IMS通道。单卡设备处理这些业务是串行的，问题不大。但双卡双待手机通常只有一个蜂窝射频收发链路，两个SIM卡必须分时共享。当卡一在LTE网络上通话、卡二在同一个频段上要发彩信时，终端射频必须在两卡之间来回切换。如果两张卡处于同一个LTE频段，切换很容易引起上行发射中断，PUSCH的传输被“插空”；如果卡二还停留在2G/3G网络发彩信，则需要射频跳到另一个制式上，这个过程对LTE上行几乎是毁灭性的——卡一的上行子帧会连续丢失，基站侧看到的BLER高企，MCS被链路自适应压到最低，速率直线下降。

这类问题在网优排查时特别容易被误判为“小区干扰”或“基站故障”。实际上，换个单卡手机上传就正常了。所以我在测试上行速率时，总会看一眼终端是不是双卡开启了“智能切换”模式，并且尽量用纯净单卡状态做基准测试。这既是一个测试规范，也反映了LTE上行调度对终端射频能力的“深度依赖”。

2. NR把上行推到了新高度

2.1 波形可切换：DFT-s-OFDM与CP-OFDM的动态选择

NR在物理层设计上没有走LTE的老路，而是引入了波形“双轨制”：上行既可以用DFT-s-OFDM（也就是LTE SC-FDMA的进化版），也可以用CP-OFDM。这两个波形各有各的脾气。

• DFT-s-OFDM：单载波特性好，峰均比（PAPR）低，终端功放效率高，适合覆盖受限场景。它继承了LTE上行的优点，但调制和资源映射更灵活。
• CP-OFDM：就是下行在用的多载波波形，频谱效率更高，能支持多流MIMO和更灵活的导频设计，但PAPR高，会牺牲终端发射功率效率。

NR允许基站在不同场景下动态切换波形。覆盖边缘用DFT-s-OFDM“保底”，在信道条件好的近点切换到CP-OFDM“冲速率”。LTE时代只允许DFT-s-OFDM一种，也就锁死了上行多流的可能性。我在现网看到许多5G终端近点上传能稳定跑到80Mbps以上，正是CP-OFDM加256QAM加双流共同作用的结果。

这个“可切换”的设计思路，其实和“见人下菜碟”一个道理。链路好的时候追求高效率，链路差的时候优先保证可用性。NR的波形选择不是静态参数，而是可以配合调度策略实时调整的。在网管里，打开这项功能不费太大事，但对边缘用户的上行体验提升立竿见影。

2.2 灵活子载波间隔：小到覆盖、大到容量都能兼顾

LTE的子载波间隔固定是15kHz，一个子帧固定1ms，这导致了循环前缀（CP）长度固定，系统在时延、覆盖、容量之间很难灵活取舍。NR把 Numerology（参数集）玩活了，子载波间隔支持15kHz、30kHz、60kHz、120kHz、240kHz多档。

对上行PUSCH而言，子载波间隔的选择实际上是个权衡：

• 15kHz/30kHz：符号时间长，CP占比相对较高，抵抗时延扩展的能力强，适合广覆盖和大带宽低频段场景。
• 60kHz/120kHz：符号短，时隙短，适合高频段（FR2）、低时延场景，但覆盖能力天然下降。

在低频组网里，30kHz往往成为标配：它能在10ms帧里塞进更多时隙，缩短HARQ往返时延，同时提供比15kHz更低的调度时延。从PUSCH角度理解，更短的时隙意味着“调度机会”更多，上行突发小包不用等太久。这也是NR上行小包时延明显优于LTE的重要原因之一。

实际测试中，我对比过同一台终端分别在15kHz和30kHz的PUSCH传输时延，30kHz配置下峰值吞吐率提升约10%，靠的是更紧密的调度粒度。当然，如果不做选择直接照搬LTE的15kHz，也就丢失了NR的速度优势。

2.3 从单天线到多流：NR上行Massive MIMO的空间红利

LTE上行初期是单天线发射，上行MIMO只在高端终端上以2天线的方式存在，实际启用得少。NR则从上到下把多天线写进了设计基因：终端可以配置发射分集、空间复用、甚至上行波束赋形；基站侧则依靠大量接收天线做联合接收，等效增益显著。

这就直接改变了上行的链路预算。LTE时代上行覆盖半径被终端功率卡死；NR里，终端即使功率不变，上行发射分集也能获得3~4dB的增益，再加上基站侧Massive MIMO的接收合并，边缘上行速率翻倍是常见的结果。用个生活类比：之前是“一个人打手电筒”，基站睁一只眼闭一只眼；现在终端多了一个备用灯，基站也在多角度同时看，亮度和接收能力都上来了。

对于PUSCH的实现细节，上行多流意味着需要配置多个解调参考信号端口和对应的CSI上报。这也是NR里从“rank1”到“rank2/3/4”的差异所在。在测试终端log里，如果看到PUSCH Rank指示为2，且上行MCS保持在22以上，基本可以断定该点上行空间复用已经激活。过去LTE上行很难同时看到这两个条件同时成立。

2.4 上行载波聚合、SUL与重复传输：覆盖增强三板斧

NR解决上行受限的另一个思路，是多路径获取频谱：

• 上行载波聚合（UL CA）：把两个中频/低频载波拼在一起，用户上行能同时占两个载波的RB，汇聚峰值速率。这个在NSA/CA场景里很常见，但受终端能力限制，不一定所有手机都支持。
• 补充上行（SUL，Supplementary Uplink）：当NR失配在频段（比如3.5GHz）上上行信号覆盖不够时，终端可以借助一个低频段的SUL载波来发PUSCH，下行数据仍然走原来高频段。这个设计本质上是用低频段的覆盖能力给高频段“补课”，把上行覆盖半径大幅扩展，很多厂家把SUL称为“盲区救星”。
• PUSCH重复传输（PUSCH Repetition）：终端在不同时隙里重复发送同一份数据，基站合并解调，获得时间分集增益。这是URLLC和远点覆盖增强的万金油。

实测经验是：SUL对边缘用户提升最明显。我在一个3.5GHz NR弱覆盖点测试上行速率，不开SUL时只有1~2Mbps，开了SUL直接跳到20Mbps以上。因为PUSCH从高频段迁移到了低频段，副载波间隔虽然没变，但路径损耗小了十多个dB，功率余量一下就上来了。

这三招本质都是在补偿终端发射功率不足的先天劣势。网络侧需要根据用户的PHR（功率余量报告）和路径损耗估计来合理选择切换。用那些只盯着下行信号的AP能解决问题吗？显然不行，上行这套逻辑是独立成体系的。

3. PUSCH物理信道深度拆解

3.1 RB、RE、DMRS与PT-RS：一个数据块是怎么装满的

要对PUSCH有手感，必须熟悉它的“集装箱”结构。PUSCH承载于物理资源块（PRB）上，时域上按时隙为单位，一个时隙通常是14个OFDM符号（普通CP）。每个PRB在频域上占12个子载波，那么一个时隙里的一个PRB就是12×14=168个RE。

假设一个上行时隙里分配了10个PRB、8个符号用于数据，那么可用于传输的RE数大约是10×12×8=960。这些RE里还要留出DMRS的位置、可能还要放PT-RS（相位跟踪参考信号）和上行控制信息（UCI，比如HARQ-ACK），真正给业务数据用的RE数还要打个七折八折。

DMRS的密度直接影响解调性能。LTE上行DMRS只占1个符号，NR的DMRS则可以在时隙内占用1~3个符号，并且能够配置额外位置。带来的好处是信道估计更准，坏处是数据吞吐率会下降。所以，调度器需要根据信道时变快慢动态调整DMRS配置——这是一组“用开销换可靠性”的经典权衡。

PT-RS则更不为人熟知。它只在高层调制（如256QAM）或高频段时才被配置，用来跟踪相位噪声。这玩意儿的密度与MCS绑定，MCS越高，PT-RS频域越密。我见过不少新手，看PUSCH总RB数很多，但算吞吐率时忽略了PT-RS和DMRS开销，结果理论速率与实测速率对不上，还以为是设备bug。

3.2 MCS、TBS与HARQ：自适应调制和重传的配合

PUSCH每次传输都对应一个MCS（调制与编码策略）索引。LTE的MCS是0到28，NR更进一步，0到31，还支持多级高阶调制。MCS不同，意味着每个RE承载的有效比特数不同。

可以这样换算：64QAM的MCS下，一个RE能带6个比特（再加上编码率）；256QAM下，一个RE能带8个比特。听起来幅度不大，但乘以整个PUSCH承载的RE数，差距就出来了。在同样的20MHz带宽下，上行从64QAM升级到256QAM，峰值速率理论提升超过33%。这也是为什么NR终端近点的上行速率能明显甩开LTE。

但MCS选高也是有代价的。调制阶数越高，对信噪比的要求越苛刻，一旦信道波动大，BLER就容易飙升。PUSCH的HARQ机制在这里起到保险丝作用：如果基站解调失败，通过NDI（新数据指示）反转，终端在下一个调度里做重传。重传虽然浪费资源，但合并增益往往能把本来就擦边的数据“捞回来”。实际排障时，我看上行BLER目标一般设在10%左右，如果长期高于20%，多半不是调度不足，而是邻区干扰或功控出了问题。

3.3 开环+闭环功率控制：PUSCH发射功率是怎么定出来的

PUSCH的发射功率可不是“拍脑袋”设的，它遵循一条经典的功控公式。简化的NR PUSCH发射功率大致可以表示为：

P_PUSCH = min{P_CMAX, 10log10(2^μ × M_PRB) + P_O_PUSCH + α × PL + Δ_TF + f(i)}

其中：

• P_CMAX：终端最大发射功率，一般23dBm；
• M_PRB：分配的RB数；
• P_O_PUSCH：目标接收功率，网络可配；
• α：路径损耗补偿系数（0到1）；
• PL：终端估计的下行路径损耗；
• Δ_TF：与MCS相关的功率偏移；
• f(i)：闭环功控累积/绝对值。

开环部分用目标功率+路径损耗补偿，让离基站远的终端自动增大功率；闭环部分则由TPC命令动态调整。这样既保证接收端信噪比足够，又尽量减小对邻区的干扰。

这里有一个调试经验：α设得太小，边缘用户功率补偿不足；设得太大，小区间干扰又会失控。在城区高干扰场景，我习惯将α设为0.7~0.8，配合较高的P0，让近点用户不要过分发射，把干扰压在可控范围。PUSCH功控调优是一个“过犹不及”的活，拿P1/P2/P3不同参数组合对比KPI三天，数据会说话。

3.4 波束与多TRP：NR PUSCH的空间域新玩法

NR在FR2高频段里，PUSCH不单纯是“一个方向猛发”，而是通过波束指示来选择上行发送方向。基站可以通过SRS资源集配置上行波束，终端按指示用某个波束发送PUSCH。这个过程和下行波束对应，但原理不同，因为上行波束的确定往往依赖基站测量SRS后反馈。

多TRP（多点收发）场景下，基站可以同时从两个传输接收点接收同一个终端的PUSCH，合并后获得宏分集增益。这意味着即便一个TRP被遮挡，另一个TRP还能把数据接住。对于工业互联网场景，比如AGV在货架间穿行，PUSCH频繁中断的问题，多TRP联合调度很有价值。

当然，多TRP也带来复杂性：两个TRP接收到的信号可能有较大的时延差，HARQ反馈时序、功率控制都得更精细。实际工程中，一般先保证单TRP功能稳定，再开启多TRP载波聚合，避免复杂度把网络稳定性拖垮。

4. 小区ID、跟踪区与PUSCH：为何识别身份会影响上行调度

4.1 TAC、Cell ID、PCI之间的区别

网优新手经常把跟踪区码（TAC）、小区ID、物理小区标识（PCI）混在一起。简单说：

• TAC（Tracking Area Code）：跟踪区码，用于核心网寻呼一级的位置更新。终端跨TAC移动时，会触发Tracking Area Update（TAU）。
• Cell ID（ECI/NCGI）：小区的全局唯一标识，由PLMN+小区ID组成，用来在核心网侧唯一定位一个小区。
• PCI（Physical Cell ID）：物理层的小区标识，LTE有504个，NR有1008个，用于无线侧的扰码、移位序列生成。

搜索热词里同时出现“LTE 跟踪区”和“LTE 小区ID”，说明很多时候排查上行问题是需要把这条信令链串起来的。终端上报的服务小区和邻区信息里，就是靠PCI和全局小区ID来锁定地理位置和工程参数。PUSCH的解调依赖小区的加扰序列和DMRS序列，而这些序列的生成参数中就有小区ID（或通过PCI相关参数导出）。所以，小区ID配置错误会直接导致上行无法解调，这在开站时是要重点核查的。

4.2 搜索词里的“NR 513630”：一次真实小区识别

“NR 513630”这类数字，通常不是PCI，而是一个小区全局标识的十进制表示。比如某个NR小区的NCGI（NR Cell Global Identifier）由PLMN+NR Cell ID组成，分两段编码后，在测试终端上会以十进制显示为一段数字。513630可能是其中一种常见的“NR小区ID”展示形式，类似LTE的ECI。

这类数值在路测DT/CQT里会被记录在Log中。当上行出现问题时，我们会同时抓取终端log和路测GPS信息，定位到“513630”这个小区的上行MCS、PHR、BLER指标。如果同一个小区里多个用户上行都差，优先怀疑小区级的功控参数、邻区干扰、上行时隙配置不完整；如果只有个别用户差，多半是终端或无线环境问题。

所以，不要觉得“小区ID”跟PUSCH无关。实际上，基站需要根据小区ID和用户级配置生成解调序列，核心网的寻呼跟踪也依赖TAC/ECI。我们判断一次TAU失败是否影响了上行调度，往往就是靠这些标识符在信令流中的时间戳和小区切换关系。

4.3 跟踪区更新与PUSCH的时间窗：移动中上行为何偶发中断

跟踪区更新（TAU）是一个低优先级过程，但它要占用RRC连接中的上行资源。终端在TAU请求时，需要先获得上行Grant，然后通过PUSCH发送NAS消息。如果此时用户正在做大量上行传输，TAU消息会与普通用户数据复用同一PUSCH资源池，类似于高速公路上突然插入一辆“政务车”，会导致数据包排队变长。

更麻烦的是，TAU期间如果发生小区重选，整个上行传输会中断几百毫秒。我做过一次高铁场景测试：列车跨TA的时候，PUSCH出现明显的4~5个时隙空洞，上行吞吐率曲线像一个刀切一样的缺口。这其实不是网络故障，而是正常的信令优先级抢占。理解了这个过程，就不会一看到TAU后的上行速率掉点就急着开erd bundle。

解决思路一般是：优化TA配置，让跟踪区边界尽量避开高速通信热点区；同时将上行调度周期的SR周期设短、打开基于CQI的PUSCH链路自适应，减少TAU带来的影响。在NSA组网下，还可以让锚点的LTE上行尽量为NR用户分离资源，避免TAU和NR的PUSCH在同一时间抢资源。

5. 上行受限问题的实战排查手册

5.1 问题表象：速率低、时延大、BLER高

上行问题常见的用户反馈集中在三个词：上传慢、网页卡、语音断续。从指标上，我会先看三个数：

• PUSCH调度RB数：如果每个子帧RB分配都很小，可能是容量不足或Grant不足；
• MCS分布：如果MCS中位数长期低于10，说明链路预算或干扰有问题；
• 上行BLER：超过20%几乎可以断定有干扰或解调异常。

这三个数据在网管里基本都能通过“单用户调度信息”和“PUSCH信道质量统计”拿到。一次典型的“上行受限但下行良好”现象，大概率是终端离基站较远，或者有遮挡物，导致上行SNR不足。这时看PHR报告，会发现终端已经满功率发送（PHR=0），功率余量被吃干抹净。如果是一整片小区都这样，则要考虑SUL或增加上行接收通道。

5.2 单用户根因分析：MCS、RB数、PHR逐项排查

排查单用户上行慢，第一步别急着改参数，先在UE侧抓log。关注这几张表：

• PUSCH MCS Index：如果MCS一直在22以下，说明基站认为信道质量还够不上64QAM；
• RB的数目：看看每个调度周期实际分配了多少个RB，如果Grant里给的都是5RB、10RB的小块，那再怎么提升调制，速率也上不去；
• PHR：终端功率余量是否为0，决定是不是功率受限。
• 同时看下行SNR：下行好不一定上行好，因为FDD上下行频点不同，TDD上下行时隙比例不同，两方向的干扰模型差异很大。

我曾经处理过一例“上行只有6Mbps”的投诉。最终发现是终端被配置了“Limited UE capability”，上行只支持单天线和64QAM，且最大发射功率被限制到20dBm。换了一台能力完整的手机后，同一位置跑到45Mbps。所以，终端能力对齐也是排查清单里不得不看的一项。

5.3 多用户干扰：DMRS序列冲突与邻区干扰

上行干扰往往是“看不见的杀手”。在LTE里，DMRS序列由小区ID和循环移位共同决定。如果相邻小区的DMRS循环移位配置相近，多个用户在同一RB上发PUSCH，基站解调时就会出现DMRS互相关峰值抬升，干扰串进来。

NR虽然PCI数量翻倍，DMRS生成也重新设计，但FR1的大规模组网中，相邻小区同向干扰依旧存在。一个非常典型的现象：某小区上行IoT（Interference over Thermal）底噪突然升高到-105dBm以上，但下行KPI看着还行。这时候最有效的办法是上山/上塔查互调干扰和外部干扰源，并配合网管侧频域干扰分布图，看干扰是单频点、宽频段还是全频段。

如果是持续的带内干扰，优先检查周围是否有私装放大器。有时候客户投诉上行卡顿，一排查发现是3.5GHz频段上被人放了非法中继，哪怕只有一台设备，也能让附近一整片的上行BLER抬到30%以上。查这类问题，光调功控没用，必须物理定位干扰源。

5.4 双卡双待场景下的上行调度矛盾

再回到双卡场景。现代手机大多支持双卡双待双VoLTE，但真要两个卡同时进行上下行数据业务，射频资源依旧是共享的。尤其是“卡一通话中，卡二发彩信”这种场景，实际上两个SIM一张做CS域或VoLTE，另一张走PS域数据，终端需要频繁切换频段和基带资源，上行PUSCH传输会出现周期性中断。

在测试中，我用“时间线对齐”的方式观察过这类现象：卡一的语音每个20ms一个语音包，卡二的数据PUSCH则被拆得支离破碎。表现为上行Grant呈现明显的“凹槽”。这不是网络问题，而是终端射频调度的固有特性。运营商排查时，可以用测试卡把两个卡的业务分别放到不同频段、不同PLMN或者关闭其中一个卡的VoLTE来规避。

所以在做上行速率评测时，建议用一个纯数据卡、另一卡暂时禁用，并在测试报告中注明终端型号和双卡状态。否则，结果会出现大量“不可复现的波动”，白费功夫。

6. 实操笔记：那些PUSCH相关但我踩过的坑

6.1 PUSCH功率越大越好？被误判的“好信号”

第一次做功控优化时，我也天真地以为把P0调高、让终端发射功率顶格，上行性能一定能提升。结果恰恰相反：调高P0之后，近点用户发射功率过强，邻居小区收到的干扰显著上升，整个网络的上行BLER反而从8%涨到了15%，平均频谱效率下降。

后来我才意识到，PUSCH功控是一个博弈问题：既要保证本小区接收质量，又要牺牲一点邻区干扰来换取边缘覆盖。在城区高用户密度场景，P0设太高就是“杀敌一千自损八百”。正确的做法是先用路测看不同距离下的PHR和IoT，再决定P0、α怎么配。不要为了边缘用户体验而牺牲整体网络容量。

如果你的终端显示RSRP很好，但上行速率却差，先别急着怀疑功控——顺手查一下终端是不是用了“省电模式”。有些手机在低电量或后台限制时，会主动降低上行发射功率，这是终端侧策略，网络侧怎么调都无效。

6.2 参数配置的边界：不要只看“标称速率”

我们在方案宣传里常看到“上行理论速率300Mbps”的表述，但实际部署时，上行速率受限于：频谱带宽、时隙配比、终端能力、网络负荷、覆盖环境。比如TDD 3.5GHz 100MHz小区，如果时隙配比是7:3，上行等效带宽只有30MHz左右，PUSCH理论峰值本来就要打七折。

有一次做NR新站优化，客户根据厂商标书要求上行测50Mbps。我们用200MHz带宽，结果上行总分只有40Mbps，怎么调都上不去。后来发现是终端厂商对单卡上行频段支持有限，200MHz的CCE只支持100MHz带宽，而且上行用了“双面板方案”，射频链路在不同面板间切换有损耗。这种问题靠网络侧参数是解决不了的。

所以，评估一个站的上行能力，要和终端产品说明书、当前空口配置、时隙比例一起看。单独给一个“上行目标”并没有实际意义，脱离配置谈速率都是耍流氓。

6.3 给新人的一句话：先从UL grant看懂调度周期

如果你刚开始接触PUSCH，我建议别急着背公式，先去抓一段空口log，看看UL Grant从PDCCH下发到PUSCH真正发出之间隔了多少毫秒。这个间隔里藏着SR周期、调度时延、HARQ时序、子载波间隔等一系列概念。

我见过太多新人只会看网管里的“平均用户速率”，出了事就开load平衡，其实很多东西在上行调度信令里一看便知。比如某小区上行吞吐率异常低，但无线环境正常，打开抓包工具看PDCCH的DCI 0_1消息，如果发现一个用户被分配的都是“零多子帧模式”，那可定是Grant不足。这个观察点用五到十分钟就能定位问题，比在网管里找半天KPI曲线高效得多。

多看UL Grant，你会逐渐形成对“上行调度周期”的直觉：一个时隙能容纳多少用户、每用户能分到多少RB、天线端口数是多少、MCS在链路自适应下的变化幅度有多大。有了这种直觉，以后再复杂的PUSCH问题，你至少知道该从哪一层、哪条信令去找答案。

再分享一个落地技巧：调上行时，不要只看空闲状态下的峰值测试，一定要做“下行大包+上行小包”并发场景验证。因为真实用户的体验是双向同时进行的，PUSCH与PDSCH共享基站的调度器资源，并发时的MCS选择和GBR分配才是业务体验的实际决定因素。你会在这种并发测试里发现很多单方向测试永远不会暴露的问题，比如上行Grant被下行高负荷业务挤压、HARQ反馈优先级过低等等。

上行这条赛道，从LTE到NR，不止是速率的飞跃，更是一整套调度、功控、波束、覆盖增强机制的重新设计。底层的PUSCH信道虽然名字没变，但从波形到时频资源、从单天线到多波束，几乎处处都在变。把这条链路上的每一个环节摸熟，不管是做网优、终端测试还是标准协议分析，都能站得住脚。