很多搞网优的朋友应该都有这种感觉用户报障“上传慢”的比例远比“下载慢”要高。下载速率不行我们还能甩锅给服务器上传不行那可是物理层的问题。LTE时代“上行受限”这四个字几乎写进每一个深度覆盖场景的报告里到了5G NR时代大家又开始喊“上行起飞”。这中间到底发生了什么变化核心就在一个信道上——PUSCH物理上行共享信道。这篇文章我从PUSCH的定位讲起把LTE上行为什么“憋屈”、NR上行为什么能放开手脚这件事拆开说清楚顺便把TAC、Cell ID、NR小区标识这些日常网优里经常打交道的东西跟上行调度串起来讲。最后再给一套实实在在的看指标、调上行的思路。不管你是刚入行的优化工程师、测试工程师还是想搞懂手机信号问题的数码爱好者都能在这篇里找到有用的东西。1. PUSCH 到底在传什么先把这个“主传送带”看清楚1.1 从“上传慢”的日常说起你在地铁里刷不出朋友圈小视频灯会现场图片转圈发不出去视频通话一卡一卡的这些体验背后几乎都有同一个物理信道的影子——PUSCH。很多人看网速只关心下行毕竟下载才是大头但上行数据传不上去你连一个“消息已读”的回执都送不回服务器。PUSCH的全称是Physical Uplink Shared Channel不管LTE还是NR它都是手机往基站方向传输数据的主干道。你在微信里发的照片、视频、语音包经过应用层打包、IP层封装、PDCP/RLC/MAC层层处理之后最终都要映射到PUSCH上通过空口送出去。不光是用户数据连RRC信令消息、MAC层的控制元素也都是搭PUSCH的便车走的承载在UL-SCH里面。更关键的一点是PUSCH不光是“运货的”它还是个“捎话的”。HARQ的ACK/NACK反馈、信道质量指示CSI、调度请求SR在某些配置下都会顺便搭载在PUSCH上一起发。LTE里这叫UCI piggybackNR里这种复用机制更灵活。所以PUSCH一堵不只是网速变慢信令流程都可能拖着走。1.2 LTE 和 NR 的 PUSCH 长得完全不一样同样叫PUSCHLTE和NR里的实现可以说是两代人。我把关键差异列成一个表方便对照着看。维度LTE PUSCHNR PUSCH上行波形DFT-S-OFDMSC-FDMA可选CP-OFDM或DFT-S-OFDM子载波间隔固定15kHz15/30/60/120kHz灵活配置最大带宽20MHzFR1可达100MHzFR2可达400MHz最高调制阶数64QAM为主256QAM有条件支持256QAM基本盘更高阶也在演进资源分配方式必须连续RB分配调度不灵活支持非连续RB分配、跳频、时域聚合HARQ进程数8个同步HARQ为主16个异步HARQ传输方式动态调度为主SPS辅助动态调度Configured Grant上行MIMO最多2层现网很少开最多4层MU-MIMO商用普遍看到这个表你就明白NR的PUSCH不是在小修小补而是把很多LTE时代“物理上没法做”的事情直接放开了。为什么要这么改每一处改动背后都对应着一个LTE上行被卡脖子的痛点。下面我从LTE的四个硬约束讲起你就知道“上行受限”这四个字是怎么来的。2. LTE 上行受限的四个硬约束这个“限制”到底从哪来2.1 物理层最残酷的现实手机只有那么点发射功率下行方向的发射机在基站侧导频功率动辄几十瓦天线阵列还能提供波束增益。上行完全反过来发射机在手机里一部手机的最大发射功率通常也就是23dBm换算一下只有200毫瓦左右。这200毫瓦要穿透墙壁、树叶、车窗最后到了基站还要面对热噪声和邻区干扰路损一大信噪比就崩了。这就是为什么网优行当里常说“上行覆盖受限”。基站听得见手机和手机听得见基站是两个完全不同的概念。实际网络规划里很多小区的覆盖半径就是被上行链路预算卡死的尤其是1.8GHz、2.1GHz以上频段频率越高路损越大手机发射功率又上不去覆盖缩水极其明显。进到室内深度覆盖场景LTE上行几乎就只能靠运气了。2.2 为了省功率选的“单载波”换来的是灵活性缩水LTE上行当时选了DFT-S-OFDM也就是大家常说的SC-FDMA这个选择在3GPP里讨论了很久。核心原因很简单OFDM信号是多个子载波叠加峰均比很高手机的功放为了不把信号削掉必须回退功率工作导致实际发射功率用不满。DFT-S-OFDM在频域上等于是“单载波”特性每个时刻只用一个窄带信号在发射包络平稳得多功放可以贴着饱和点工作发射功率利用率高覆盖自然更远。但天下没有免费的午餐。单载波特性带来的限制就是上行RB分配必须连续不能像下行OFDM那样在频域上东一块西一块地拼。频域调度灵活性没了频率选择性调度和干扰协调的手段就少了一大截。更麻烦的是多天线MIMO在上行也不好做多流传输需要多套射频链路手机尺寸、功耗、成本都扛不住所以LTE上行SU-MIMO在现网里基本就是个摆设。2.3 20MHz带宽和64QAM调制把天花板焊死了LTE单载波最大带宽20MHz这本身就是2008年左右的标准设定放到今天看确实不够宽。带宽不够RB总数就有限PUSCH能传的比特数自然被封顶。调制阶数也卡着——64QAM在理想环境下能跑但想要256QAM得UE支持、SINR够高、功率余量充足这几个条件在真实网络里往往同时满足不了。到了小区边缘MCS一路掉到16QAM甚至QPSK速率断崖式下跌用户体验直接从“卡”变成“死”。我见过不少LTE上行测试室内站点下RSRP显示还不错但PUSCH的MCS只有个位数上行速率只有几百kbps。原因是上行SINR被邻区干扰和底噪抬升吃掉了调制阶数根本抬不起来。调制阶数一降同样的RB数量能承载的比特数直接减半再减半这是LTE上行吞吐上不去的硬伤。2.4 调度和反馈8个HARQ进程背后的时延账LTE的HARQ是同步的8个进程进程号和子帧号一一绑定重传的时序是固定的。这意味着一次传输失败后要等8ms才能轮到重传。对于FDD倒还好TDD就尴尬了上下行时隙配比固定如果配的是2:2甚至1:3上行子帧少得可怜PUSCH调度机会本来就少再碰上重传排队时延和吞吐双重恶化。边缘用户VoIP靠的是SPS半静态调度每20ms给一次固定授权覆盖更差的用户还得开TTI Bundling把连续4个子帧的同一个数据块捆绑发送用时间换能量。这些都是LTE为了对抗上行受限而打的补丁。说到底LTE不是不想快而是从波形、带宽、功率到调度机制每一层都在为“覆盖优先”妥协这种妥协在上行方向上尤其明显。3. NR 上行起飞的核心它把“自由度”还给了上行3.1 双波形并行CP-OFDM冲速度DFT-S-OFDM保覆盖NR没有像LTE那样一根筋地只用单载波波形而是把选择权交了出来。终端能力允许的前提下网络可以给PUSCH配CP-OFDM这跟下行是同一个波形频域调度完全放开非连续RB分配、频选调度、MU-MIMO配对都变得顺理成章。CP-OFDM配合256QAM中近点吞吐能力比LTE上了一个量级。但CP-OFDM峰均比高的问题依然在所以NR也保留了DFT-S-OFDM专门用在那些功放功率受限、覆盖吃紧的场合。覆盖不足的时候网络通过RRC配置和DCI指示把PUSCH波形切到DFT-S-OFDM牺牲一点吞吐换更远的覆盖。两种波形可以在一个小区里并存不同用户各取所需这是LTE完全做不到的灵活度。实网里我建议优先把近中点用户放开用CP-OFDM边缘用户老老实实DFT-S-OFDM保接入和保基本速率。3.2 更大带宽和更灵活的子载波间隔NR的带宽配置直接把上行的可用资源拉高了一个数量级。FR1频段最大支持100MHzFR2毫米波频段最大支持400MHz一个100MHz的NR小区上行RB数量是20MHz LTE的5倍。这意味着一件事哪怕调制阶数不变资源多了吞吐自然就上去了。子载波间隔的灵活性也让时域资源更好用。C-band常用30kHz符号长度比15kHz短一半单时隙时长从1ms缩到0.5ms调度回合更快HARQ时延更短。毫米波频段用到120kHz一个时隙才125微秒。再加上NR支持非连续RB分配、时域资源分配表非常灵活、PUSCH映射类型A/B配合前置DMRS上行“挤牙膏”式发数据的方式彻底成为历史。3.3 调制、编码和重传256QAM不只是PPT上的数字NR的PUSCH把256QAM变成了常规配置近距离用户开256QAM是常态SINR稍好一点的区域都能吃上。同样的信道条件下256QAM比64QAM每个符号多传2比特同等RB数下吞吐直接提高三成以上。这不是纸面参数我在现场用路测软件看过C-band近点PUSCH的MCS能稳定在28左右这在LTE里是想都不敢想的。编码方面NR换成了LDPC高码率下的纠错性能比LTE的Turbo码更接近香农极限。HARQ也改成异步的16个进程基站可以更灵活地安排重传时机和资源不需要再绑死在固定子帧上。对于URLLC和上行低时延场景NR还搞了Configured Grant也就是免动态调度的上行授权配置好周期和资源后UE直接抢着发省掉了调度请求和授权往返的时间这就是为什么有些超低时延业务在NR上能跑起来的原因。3.4 上行不只是“一个手机”的事多天线与叠加NR终端开始标配多天线虽然手机尺寸有限但2发4收甚至4发已经出现在高端机型里。上行多流MIMO可以同时传2层乃至4层峰值速率翻倍再翻倍。更重要的是基站侧的MU-MIMO多个用户用不同的DMRS端口在同一块时频资源上同时发PUSCH基站靠空间区分把两个人拆开。这个技术在LTE上行因为DMRS正交端口数量有限基本没铺开NR里已经是很普通的多用户配对方案。再往大了说NR的上行还可以“叠buff”。上行载波聚合把两个载波的PUSCH一起调度EN-DC双连接下终端可以同时用LTE和NR两条路发上行这也是NSA时代用户感受到上传变快的一个重要原因。不过这里有个容易被忽略的坑双载波同时发意味着终端总发射功率要在两个链路之间分合路损耗、互调干扰都要考虑。所以上行CA实际增益不像纸面上那么线性调优时得看PHR和功率分配策略。最后必须提一下SUL补充上行链路。这是NR解决上行覆盖不足的一记大招。C-band上行覆盖差就专门配一个低频段比如700/900MHz来做上行下行还在C-band上行却可以切到低频发PUSCH。低频路损小、覆盖远一下子把上行覆盖半径拉大了好几圈。很多SA网络的“上行起飞”体验一半功劳得记在SUL头上。4. 真实网络里的 PUSCH 调度与标识TAC、Cell ID、NR 小区背后的上行逻辑4.1 “卡一通话、卡二发彩信”为什么让人头秃有用户反馈过这么一个场景LTE网络环境下卡一正在打电话用卡二发彩信图片转圈半天发不出去。很多人以为是彩信网关问题其实问题出在终端的射频能力和上行调度上。现在市面上绝大多数手机是双卡双待单通射频链路只有一套用于独立发射卡一通话时语音数据要持续占用上行资源卡二即便还在网上待着也拿不到足够连续的上行授权去传彩信的图片文件。从PUSCH的角度理解这件事特别清楚彩信本质上是走数据通道的IP业务MMS APN建立之后图片内容要通过PUSCH一层层传出去。卡一通话时PUSCH的调度机会都给了语音承载卡二的数据承载只能排队等。部分手机会直接暂停副卡的数据传输直到通话结束才恢复。所以遇到这种问题先别急着查彩信中心先看看终端是不是单通硬件限制再让用户挂断电话试一次往往立竿见影。这也是为什么双卡双待双通机型在高端市场一直有需求。4.2 TAC 和 Cell ID位置更新、寻呼背后也要消耗上行资源TAC全称Tracking Area Code翻译过来是跟踪区码它的作用是让核心网知道“用户大概在哪个范围里”这样寻呼终端时不用全网广播。用户跨TAC边界的时候要触发TAU位置更新流程这个过程中终端要发RRC连接请求、传输NAS消息这些信令最终都要映射到SRB上再由PUSCH承载发送。TAC规划不合理会带来一个非常现实的上行问题边界区域TAU频繁触发大量终端的随机接入和PUSCH小包并发挤在一起PRACH拥塞、PUSCH可用资源被信令占掉一大块用户感知就是“网速时好时坏”。Cell ID在LTE里通常指ECGI的一部分由eNB ID加小区ID组成。切换目标小区确定之后终端要通过PRACH发起随机接入然后拿到第一次PUSCH授权才能开始传数据。任何一个环节受阻比如目标小区PUSCH资源不足、随机接入冲突切换就会拖沓甚至失败。所以后台指标里如果看到切换成功率掉点除了查邻区关系也要看一眼目标小区的上行资源状况。4.3 “NR 513630”这串数字到底怎么读实际网优中经常会看到“NR 513630”这样的字段可能是路测软件里抓到的频点号也可能是小区标识的一部分看厂商的显示方式而定。如果它是频点号那它对应的是NR-ARFCN通过查频点表可以换算出中心频率。按FR1频段栅格来估算513630这个量级落在2.5GHz到2.7GHz附近大概率是n41或n7这类中频段。这类中频段上行覆盖能力比C-band好一些但依然好不到哪去所以这类站点通常也会配SUL或者依赖较密的站间距。如果这串数字是NCI也就是NR Cell Identity的一部分那它其实编码了整个小区的gNB ID和小区ID。日常优化里更值得关注的是PCI与小区ID规划对PUSCH的影响。NR的PUSCH DMRS序列是按小区ID和一定的跳变规则生成的两个小区的PCI在mod 30上冲突时DMRS序列可能不再正交邻区用户互相干扰会直接反映为PUSCH解调SINR恶化、上行BLER抬升。这种干扰在LTE里也很常见属于十几个小区里检查不出来、但速率死活上不去的经典坑。5. 实战怎么判断“上行行不行”又怎么把它调好5.1 先会看指标别只盯着RSRP很多初学者看覆盖只看RSRP这是最大的误区。RSRP反映的是参考信号的接收强度它决定的是下行能不能“听清楚”不代表上行就能发得动。判断上行健不健康要看下面这几个跟PUSCH直接相关的指标。指标什么含义什么表现说明有问题PUSCH Tx Power终端实际发射功率长期贴着23dBm说明处于功率受限状态PHR 功率余量当前还能再发多少功率余量接近0dB时上行已经到极限PUSCH MCS调制编码等级MCS长期个位数说明SINR差或者被限调制上行BLERPUSCH初传/重传误块率初传BLER超过10%基本是信道差或干扰IoT 噪声抬升基站底噪被抬高了多少IoT超过-105dBm级别就要查外部干扰上行RB数调度的资源块数量有机会却给不出RB多半是被别的用户或信令占满我把这些指标一列你们大概就能明白现场定位的思路了。先看手机发射功率是不是顶格了顶格了再看PHRPHR无余量说明是覆盖问题如果发射功率不高但BLER高那就是干扰问题而不是功率问题这时候加功率只会让邻居更难受。5.2 快速估算上行速率的方法我教大家一个现场快速估算上行速率的办法不需要专业工具Excel拉个公式就行。PUSCH理论速率的公式可以简化成单RB子载波数12乘以传输符号数乘以调制阶数乘以有效码率再乘以RB数和每秒的时隙数。举例算一个贴近实际的场景FR130kHz子载波间隔系统带宽100MHz可用RB数约273个不对100MHz30kHz大概273RB但如果只算20MHz就100RB左右。我就按100RB、单时隙0.5ms、PUSCH可用符号12个来做估算。100个RB乘以12个子载波是1200个子载波再乘以12个符号一个时隙里一共有14400个RE。如果256QAM即8比特每RE码率0.8那一时隙能传14400乘8乘0.8等于92160比特约11.25KB。每秒有2000个时隙理论速率就是22.5MB/s合180Mbps左右。扣掉DMRS开销、控制区占用和调度颗粒度实际跑到120M到150M上行在好环境下是合理的。这个估算方式能帮你快速判断测试结果是不是“物理上可能”。如果测出来上行速率比理论值低一大截那就说明有软阻塞或干扰问题值得深入查。5.3 现场调优三板斧功控、MCS偏置、干扰整治上行调优优先级最高的永远是功控参数。NR上行功控里P0和alpha是两个最常动的旋钮。P0是目标接收功率调高它等于让所有用户都加大发射功率覆盖好了但邻区干扰也上来了alpha是路损补偿系数LTE里常用的0.6到0.8NR里可以更灵活配置。边缘小区想保覆盖alpha可以调到0.9以上但一定要盯着邻区的IoT变化防止把旁边小区抬死。第二板斧是MCS偏置。现网里有些小区明明SINR还行但PUSCH初传BLER很高大概率是MCS选得过于激进。通过PUSCH MCS的Offset表把初始MCS压低几个等级牺牲一点峰值速度换取更低的误块率和重传率综合速率反而会更好。这个思路在线路差的站点尤其立竿见影。第三板斧是干扰排查。上行只要出现大面积吞吐塌陷优先怀疑外部干扰、系统间干扰、PCI/DMRS冲突这三件事。拿着频谱仪在现场扫一扫PUSCH频段底噪比对着后台IoT数据看时段规律往往能定位到是干扰器、无源互调还是邻区配置问题。PCI冲突这种问题则通过查邻区表就能发现mod 30相同的邻区尽量错开。5.4 上行受限典型场景的处理清单我把常见的上行受限场景和处理思路整理成一个清单照着排查基本上不会漏。室内深度覆盖导致上行弱场优先开DFT-S-OFDM保功率效率配置PUSCH时域重复repetition提升解调增益站间距条件允许时上SUL或者加射灯天线。邻区同频干扰导致IoT抬升查同频邻区PCI的mod 30关系优化功率参数收敛覆盖必要时调整alpha让边缘用户不要过度抬功率。终端问题导致PUSCH能力不足确认UE发射功率等级、上行MIMO层数、DFT-S-OFDM/CP-OFDM支持能力旗舰机和中低端机在同一位置的体验差异可能就在这。信令风暴吃掉PUSCH资源核查TAC边界的TAU频率优化跟踪区划分减少不必要的频繁位置更新。6. 最后再分享点实在的经验干了这么多年网优我最大的体会上行问题是“信号强度好不等于上传好”。有一回在某商场车库测出RSRP有-90dBm按理说覆盖不算差但上行速率只有几百kbps。最后查出来是附近一个小区PCI和本站mod 30冲突PUSCH的DMRS互相踩踏SINR烂得一塌糊涂。把邻区PCI改掉之后同一个点位上行速率一下翻了十几倍。这种问题在后台指标上看是最迷惑人的你不去扒PUSCH层面的数据光看覆盖率完全发现不了。还有一个特别实用的习惯看上行覆盖先看PHR再看Tx Power。PHR是最诚实的它直接告诉你手机还有没有往上冲的余量。PHR长期在0附近徘徊说明这条上行链路已经贴着物理极限在跑你再怎么调MCS、调功控都难有大起色该补覆盖就补覆盖。上行的道理说白了就这些波形选对、功率用对、干扰清干净PUSCH自然就“起飞”了。