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的“细长型”时频结构PUSCHPhysical Uplink Shared Channel物理上行共享信道是承载用户上行数据的“主车道”。LTE的PUSCH在时域上占一个子帧1ms在频域上由多个RBResource Block资源块组成每个RB是180kHz包含12个子载波。结构上它特别“细长”1ms间隔里一个RB只有12×14168个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上发送调度请求SRScheduling 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场景里很常见但受终端能力限制不一定所有手机都支持。补充上行SULSupplementary 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×14168个RE。假设一个上行时隙里分配了10个PRB、8个符号用于数据那么可用于传输的RE数大约是10×12×8960。这些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到28NR更进一步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终端最大发射功率一般23dBmM_PRB分配的RB数P_O_PUSCH目标接收功率网络可配α路径损耗补偿系数0到1PL终端估计的下行路径损耗Δ_TF与MCS相关的功率偏移f(i)闭环功控累积/绝对值。开环部分用目标功率路径损耗补偿让离基站远的终端自动增大功率闭环部分则由TPC命令动态调整。这样既保证接收端信噪比足够又尽量减小对邻区的干扰。这里有一个调试经验α设得太小边缘用户功率补偿不足设得太大小区间干扰又会失控。在城区高干扰场景我习惯将α设为0.7~0.8配合较高的P0让近点用户不要过分发射把干扰压在可控范围。PUSCH功控调优是一个“过犹不及”的活拿P1/P2/P3不同参数组合对比KPI三天数据会说话。3.4 波束与多TRPNR 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混在一起。简单说TACTracking Area Code跟踪区码用于核心网寻呼一级的位置更新。终端跨TAC移动时会触发Tracking Area UpdateTAU。Cell IDECI/NCGI小区的全局唯一标识由PLMN小区ID组成用来在核心网侧唯一定位一个小区。PCIPhysical Cell ID物理层的小区标识LTE有504个NR有1008个用于无线侧的扰码、移位序列生成。搜索热词里同时出现“LTE 跟踪区”和“LTE 小区ID”说明很多时候排查上行问题是需要把这条信令链串起来的。终端上报的服务小区和邻区信息里就是靠PCI和全局小区ID来锁定地理位置和工程参数。PUSCH的解调依赖小区的加扰序列和DMRS序列而这些序列的生成参数中就有小区ID或通过PCI相关参数导出。所以小区ID配置错误会直接导致上行无法解调这在开站时是要重点核查的。4.2 搜索词里的“NR 513630”一次真实小区识别“NR 513630”这类数字通常不是PCI而是一个小区全局标识的十进制表示。比如某个NR小区的NCGINR Cell Global Identifier由PLMNNR 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报告会发现终端已经满功率发送PHR0功率余量被吃干抹净。如果是一整片小区都这样则要考虑SUL或增加上行接收通道。5.2 单用户根因分析MCS、RB数、PHR逐项排查排查单用户上行慢第一步别急着改参数先在UE侧抓log。关注这几张表PUSCH MCS Index如果MCS一直在22以下说明基站认为信道质量还够不上64QAMRB的数目看看每个调度周期实际分配了多少个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的大规模组网中相邻小区同向干扰依旧存在。一个非常典型的现象某小区上行IoTInterference 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信道虽然名字没变但从波形到时频资源、从单天线到多波束几乎处处都在变。把这条链路上的每一个环节摸熟不管是做网优、终端测试还是标准协议分析都能站得住脚。 上行速率为何受限？从LTE PUSCH到NR上行增强的深度解析
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的“细长型”时频结构PUSCHPhysical Uplink Shared Channel物理上行共享信道是承载用户上行数据的“主车道”。LTE的PUSCH在时域上占一个子帧1ms在频域上由多个RBResource Block资源块组成每个RB是180kHz包含12个子载波。结构上它特别“细长”1ms间隔里一个RB只有12×14168个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上发送调度请求SRScheduling 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场景里很常见但受终端能力限制不一定所有手机都支持。补充上行SULSupplementary 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×14168个RE。假设一个上行时隙里分配了10个PRB、8个符号用于数据那么可用于传输的RE数大约是10×12×8960。这些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到28NR更进一步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终端最大发射功率一般23dBmM_PRB分配的RB数P_O_PUSCH目标接收功率网络可配α路径损耗补偿系数0到1PL终端估计的下行路径损耗Δ_TF与MCS相关的功率偏移f(i)闭环功控累积/绝对值。开环部分用目标功率路径损耗补偿让离基站远的终端自动增大功率闭环部分则由TPC命令动态调整。这样既保证接收端信噪比足够又尽量减小对邻区的干扰。这里有一个调试经验α设得太小边缘用户功率补偿不足设得太大小区间干扰又会失控。在城区高干扰场景我习惯将α设为0.7~0.8配合较高的P0让近点用户不要过分发射把干扰压在可控范围。PUSCH功控调优是一个“过犹不及”的活拿P1/P2/P3不同参数组合对比KPI三天数据会说话。3.4 波束与多TRPNR 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混在一起。简单说TACTracking Area Code跟踪区码用于核心网寻呼一级的位置更新。终端跨TAC移动时会触发Tracking Area UpdateTAU。Cell IDECI/NCGI小区的全局唯一标识由PLMN小区ID组成用来在核心网侧唯一定位一个小区。PCIPhysical Cell ID物理层的小区标识LTE有504个NR有1008个用于无线侧的扰码、移位序列生成。搜索热词里同时出现“LTE 跟踪区”和“LTE 小区ID”说明很多时候排查上行问题是需要把这条信令链串起来的。终端上报的服务小区和邻区信息里就是靠PCI和全局小区ID来锁定地理位置和工程参数。PUSCH的解调依赖小区的加扰序列和DMRS序列而这些序列的生成参数中就有小区ID或通过PCI相关参数导出。所以小区ID配置错误会直接导致上行无法解调这在开站时是要重点核查的。4.2 搜索词里的“NR 513630”一次真实小区识别“NR 513630”这类数字通常不是PCI而是一个小区全局标识的十进制表示。比如某个NR小区的NCGINR Cell Global Identifier由PLMNNR 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报告会发现终端已经满功率发送PHR0功率余量被吃干抹净。如果是一整片小区都这样则要考虑SUL或增加上行接收通道。5.2 单用户根因分析MCS、RB数、PHR逐项排查排查单用户上行慢第一步别急着改参数先在UE侧抓log。关注这几张表PUSCH MCS Index如果MCS一直在22以下说明基站认为信道质量还够不上64QAMRB的数目看看每个调度周期实际分配了多少个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的大规模组网中相邻小区同向干扰依旧存在。一个非常典型的现象某小区上行IoTInterference 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信道虽然名字没变但从波形到时频资源、从单天线到多波束几乎处处都在变。把这条链路上的每一个环节摸熟不管是做网优、终端测试还是标准协议分析都能站得住脚。