干网优这些年听到最多的一句话就是“上行受限”。LTE时代不管是用户投诉“传照片好慢”还是后台统计里某个小区上行PRB利用率奇高但速率就是上不去最后追到物理层十有八九都会落到PUSCHPhysical Uplink Shared Channel物理上行共享信道头上。到了5G NR时代“上行起飞”成了另一句口头禅同样是PUSCH却因为波形、调制、多天线、调度这些底层机制换了血打出了一套完全不同的局。这篇文章我想把自己在LTE和NR两边摸爬滚打的经验摊开讲把PUSCH是什么、为什么LTE总受限、NR怎么改、以及热搜里那些TAC、CellID、“nr 513630”、“卡一通话中用卡二发彩信”到底和上行有什么关系一次性讲清楚。适合做网优、终端协议栈、测试或者单纯想搞明白手机网速为什么忽快忽慢的朋友一起看。1. “上行受限”到底卡在哪LTE PUSCH 的物理枷锁1.1 SC-FDMALTE 选择“稳”而不是“猛”LTE上行选择的上行多址方式不是OFDMA而是SC-FDMA单载波频分多址。这句话看起来像教材定义但理解了它就等于握住了LTE“上行受限”的第一把钥匙。OFDMA的最大优点是调度灵活可以把频谱切成很多小资源块任意组合分配给用户。但它的代价是信号在时域上是多个子载波叠加出来的峰均比PAPR很高。什么叫峰均比打个比方普通OFDM信号像一群人同时喊话偶尔所有声音峰值叠在一起瞬间音量爆棚而单载波信号更像一个人匀速说话音量平稳。基站功放大、散热好能承受高PAPR手机不行——电池就那么点功放又小如果也走OFDM为了保证信号不失真必须把功放功率大幅回退等于主动把自己的发射功率限制住。所以LTE在提出时做了个很务实的取舍先对数据做DFT预编码再映射到子载波发送让上行信号近似单载波特性PAPR低终端可以用满功率发射。代价就是调度灵活度下降——LTE的PUSCH必须在一段连续RB上传输不能像下行那样东一块西一块地拼资源。我常跟同事说LTE的PUSCH是“单车道连续行驶”你只能在一条连续车道里往前开不能随便变道超车。这就是“稳”但不是“猛”。1.2 功率、PHR与三种常见的“上行受限”上行受限在路测软件里的画像很典型UE的PUSCH发射功率已经拉到23dBm约200mW对手机来说就是物理天花板PHRPower Headroom功率余量降到0甚至负值MCS被调度器一点点压到QPSKBLER误块率还时不时飘红。即便RB资源给得再足吞吐也上不去。为什么会出现这种情况功率受限只是表象根因通常分三类覆盖受限小区边缘、地下室、楼宇深处路径损耗太大UE满功率发射但基站收到的SINR依然不够。这种场景下怎么调参数都没用加站、补室分、加波束增益才是正解。干扰受限重叠覆盖严重邻区之间的PUSCH互相穿扰尤其是LTE同频组网下干扰抬升导致有效信噪比被压下去。这种“上行受限”往往集中在特定区域换个位置速率就恢复。处理方法跟覆盖受限完全不同要做RF优化、小区间干扰协调。调度受限TDD制式下上下行时隙配比固定且往往偏下行。上行时隙本身就少PUSCH能占的符号有限用户在高峰期感觉上传尤其卡。这种情况不是物理层弱而是“分给上行的萝卜坑不够”。另外一个容易被忽略的是UCI上行控制信息的复用。LTE里HARQ-ACK、CSI这些控制信息经常被复用进PUSCH资源块里本来给数据的RB被控制信令挤占。在频分双工FDD或时分双工TDD的某些子帧下这部分开销能占到可调度资源的一大部分。所以有时候你看到PUSCH RB占用很高但实际承载数据的比例并不高——这也是一种“隐性上行受限”。1.3 TAC 与 CellID 不是简单的“编号字段”排“上行受限”第一步我习惯先确认终端到底挂在哪儿哪个PLMN、哪个TA、哪个小区。TACTracking Area Code由运营商规划取值范围0~65535一个大片区共用同一个TA。CellID是小区在基站侧的区域编号。两者结合再加上PLMN就构成LTE的ECGIE-UTRAN Cell Global Identifier。很多网优同事看日志看到TAC、CellID都是一眼跳过觉得这就是地址标识但实际排障时这两个字段信息量很大。举例来说如果手机在某个TAC边界来回移动终端会频繁触发TAU跟踪区更新。TAU是RRC层和NAS层的信令流程虽然不直接占用PUSCH但信令和业务在上行并行的瞬间会争抢终端处理和调度资源。在弱信号环境下用户上传大文件时刚好赶上TAU就可能出现“上传突然卡住几秒”的体感。再比如CellID配合地图工具可以反查小区是宏站还是室内分布、属于哪台eNodeB的哪个扇区。有一次客户报某写字楼高层上行掉速我一看ECGI对应的CellID就知道这是楼顶的某个宏站扇区覆盖过来的而不是楼内室分小区马上判断是宏站穿透覆盖导致的上行弱场室分整改方向立刻清晰。小区ID不是用来背的是用来关联一切指标数据的索引键。2. “卡一通话中用卡二发彩信”端侧上行受限的真实缩影2.1 双卡双待手机是怎么在同一时刻抢射频的很多用户吐槽的“LTE环境下卡一通话中用卡二发彩信发不出去”本质上不是核心网故障也不是彩信网关抽风而是终端侧上行资源被占死。市面上大量双卡手机是“双卡双待单通”——两张SIM卡都能同时驻网但射频收发通路只有一套。主卡通话时主卡要持续占用射频通道做语音数据的收发副卡只剩一些空闲间隙能维持最基本的驻网、听寻呼广播就不错了根本没有稳定上行信道可用来发彩信。如果这张手机只支持单VoLTE主卡在4G网络上做VoLTE通话副卡连LTE数据连接都会被抬掉甚至直接回落到2G/3G待机。彩信本质是PS域的数据业务终端需要先建立PDP或PDN连接拿到IP地址再通过WAP或HTTP把内容和MMSC交互。副卡连数据通道都没建起来彩信自然一直停在“发送中”。很多用户在这个场景里反复重启、开关飞行模式其实是把问题想复杂了——主卡通话一挂断副卡上行通道一恢复彩信往往“唰”地就出去了。2.2 为什么偏偏是LTE环境更明显放在5G时代看这个问题似乎淡化了是因为新机型普遍支持双VoLTE、双5G两张卡可以同时驻留高速网络硬件上也做了多收发通道或更精细的射频切换。但在LTE时代的存量手机上问题非常普遍。还有一个实际细节很多双卡手机的“默认数据卡”和“默认语音卡”是分开设置的。卡一用来打电话卡二用来跑数据流量但发彩信走的是卡二的MMS APN如果该APN没有配置MMSC地址或者手机策略把卡二设成“仅语音”那就算网络正常彩信也根本找不到出口。所以排查这类“上行不可用”的问题时不能只盯着无线侧APN设置、数据开关、双卡策略都要过一遍。2.3 完整的端侧排查链路从TAC到信令如果在工程模式或日志里排查这类问题我一般按固定顺序走看两张卡当前注册状态分别记录PLMN、TAC、CellID。如果副卡的TAC和主卡不一致说明两张卡没在同一个TA下甚至可能不在同一制式网络。看副卡实际制式和RRC状态副卡是驻留在LTE还是被释放到了GSM日志里出现“Redirect to GSM”或“RRC Connection Release with Redirect”基本就能实锤副卡被回落。看主卡的通话承载主卡走的是VoLTE还是CSFB如果是CSFB主卡可能在通话期间占用2G/3G射频副卡反而更没机会。看数据连接和APN副卡有没有发起PDP/PDN激活APN是不是正确的mms接入点MMSC地址有没有配最后做对照实验挂断主卡电话或手动切换默认数据卡到副卡重新发彩信看是否秒发。这套链路走完你基本能区分问题是“真无线侧上行受限”还是“终端双卡策略导致的假性不可用”。我处理过的客服工单里后者比例相当高。3. NR 的“起飞”逻辑PUSCH 的波形、调度和多天线变革3.1 两种上行波形并存CP-OFDM 与 DFT-S-OFDM 不是二选一NR的PUSCH有一个和LTE很不一样的设计它不是只给你一个上行波形而是同时支持两种并且可以灵活切换。CP-OFDM和下行结构一致调度灵活可以非连续RB分配能更好地配合DMRS多端口和MIMO。DFT-S-OFDM等同于LTE传承下来的低PAPR方案适合功率受限的覆盖边缘。这个设计在理想环境下颠覆了很多人的直觉NR明明可以全量使用CP-OFDM为什么还要保留看起来“老旧”的DFT-S-OFDM因为场景不同。市区宏站近点、信道好、多天线增益明显CP-OFDM拿高频谱效率是值得的但到了小区边缘、室内深处UE需要的是用满23dBm功率尽量延展覆盖这时DFT-S-OFDM的低PAPR特性就值钱了。两种波形通过RRC参数transformPrecoder动态切换基站侧也会根据信道质量自适应选择。实测中弱场环境下DFT-S-OFDM相比CP-OFDM通常能带来1~2dB的覆盖收益。不要小看这1~2dB很多手机在功率临界点上多这1dB就能从“MCS 0勉强维持”跳到“QPSK稳定上传”用户体验完全不一样。3.2 256QAM上行、UL MIMO以及更精细的功率控制约束NR上行“起飞”离不开三个关键词更高阶调制、更多MIMO层、更精细的功率控制。LTE上行最高到64QAMNR上行引入了256QAM。理论上256QAM需要SINR接近28dB才能稳定解调只有靠近基站的近点、且信道质量非常好的时候才能开出来。配合满RB调度和大带宽单流256QAM就可以把上行峰值拉到很高。做验证时我有个习惯性步骤先在近点看PUSCH的MCS是否冲到20以上如果近点只有QPSK或者16QAM那站点设备或者参数大概率有毛病。上行MIMO是另一个质变维度。LTE时代受终端形态、功放和天线数量的限制上行基本是单流传输NR定义了最多4层上行MIMO终端若具备双路甚至四路发射能力PUSCH可以按多层同时传输。但这里有个现实约束终端不是每个都支持真正的四发射通路。很多手机支持4天线接收4RX发射可能只有1路或2路所以实际网络中“上行双流”已经很常见“四流”则相对少见。多天线传输依赖基站对上行信道状态的精确估计核心参考信号是SRSSounding Reference Signal。如果SRS配置周期太长、资源不足或者天线切换没配好基站拿到的信道估计已经“过期”做预编码就会失真。这也是为什么有些站点配置了高阶MIMO但实际速率却不如预期——不是无线环境差而是SRS这一环拖了后腿。3.3 调度粒度与帧结构让PUSCH 不再“排队”LTE上行的“受限”有很大一部分是在等资源。NR在时域调度上做了几件事从根上改掉了这种等待体验。第一调度单位变细了。LTE是固定1ms子帧NR常规子载波间隔15kHz下slot仍是1ms但30kHz时slot缩短到0.5ms60kHz时进一步缩短。商用网络普遍配置30kHz或更大子载波间隔PUSCH调度和HARQ反馈的往返时间明显缩短同样一个上行数据块从“申请-授权-发送”的整个周期比LTE快得多。第二引入了mini-slot。URLLC这类低时延业务不需要等整个slot可以只占2个、4个或7个符号发送。窄带物联网小包也受益于此PUSCH不再被时长捆住。第三免调度传输Configured Grant常说的grant-free登场。一些周期性小包业务比如工业传感器上报、微信语音片段不再需要每次先发调度请求、再等DCI授权、然后才发PUSCH的“三轮问答”而是用RRC提前配好的一套资源直接发送。对很多实时交互场景这带来的时延改善甚至比速率提升更明显。另外NR TDD的帧结构也比LTE灵活得多。LTE TDD的上下行配比就那么几档NR可以灵活配置DDDSU、DSUUU等不同slot格式让上行时隙占比按业务需求调整。很多5G站点你看上行测速比LTE高一大截不是单纯调制技术翻身而是上行时隙真的给得更多了。4. 从“513630”这个 NR 小区 ID 里能读出什么4.1 NR 小区 ID 的构成与换算热搜里那个“nr 513630”乍看是一串无规律数字但它其实是NR小区全局标识NCINR Cell Identity的一部分拆开看信息量很大。NCI按3GPP定义本身是22~32位的二进制值常见做法是把低8位作为Cell ID高位作为gNB ID。拿513630来算513630 ÷ 256 2006余 94所以gNB ID 2006Cell ID 94。也就是说这个小区属于某地某个gNB ID为2006的基站扇区号为94。在路测软件里看到这个值后可以直接对照基站台账查出来是哪条街哪栋楼的第几小区。不同运营商或厂商对gNB ID和Cell ID的位数切分可能略有差异但换算思路是通用的。注意NCI在信令里显示为十进制而LTE的ECGI也是类似结构——eNodeB ID和CellID拼合而成。两者都能精确指向一个物理小区。所以当你看到一个“NR小区ID”时千万别只把它当随机数它是关联OMC、工参、告警信息最重要的键值。4.2 小区ID与PUSCH调度的关联逻辑有人可能想问小区ID就是一个编号它能影响PUSCH调度吗直接答案是编号本身不影响但编号对应的物理小区状态直接影响。所有上行调度决策——MCS选择、RB分配、层数确定、预编码矩阵——都是在“当前服务小区”这个逻辑实体上做的。如果这个小区ID对应的RRU有驻波告警、通道增益不平衡、或者上行干扰电平异常你就会看到该小区ID下所有UE的PUSCH SINR集体恶化。排查时我习惯把“NR小区ID gNB ID TAC”三件套拿到OMC上拉一段统计上行每PRB的干扰噪声IoT、PUSCH的MCS分布、PHR分布。如果特定小区ID下IoT偏高先怀疑外部干扰或邻区配置问题如果IoT正常但PHR普遍偏低又指向覆盖或功放问题。这就是为什么路测日志里看到“513630”这类值不要直接关掉日志窗口——它对号入座去查问题比盲猜强太多了。4.3 怎么验证“上行起飞”是真的起飞了NR上行说“起飞”不能只拿手机Speedtest刷个数字。从专业视角我会按由近到远三个层次验证近点看PUSCH是否调度到256QAM、是否开启了UL MIMO双流/四流发射功率余量是否充足。中点看PUSCH功率是否还在可控范围内SRS的SINR是否稳定MCS和RB配比是否健康。弱场看终端是否自动切到DFT-S-OFDM波形目标SINR能不能守住BLER是否收敛。实测中如果近点MCS已经很高但速率仍不理想问题大概率在SRS或MIMO层数如果中点功率已经逼近23dBm但速率平平大概率是覆盖或干扰问题如果弱场波形没切换那就要检查transformPrecoder的相关配置。三层看下来才能比较完整地回答“这个站点的上行到底起飞了没有”。5. 上行排障路上我踩过的一些坑与经验5.1 别把“调度没起来”当成“功率不够”有一年处理某室内分布站点的上传慢问题连续几天数据都显示PUSCH发射功率满格、BLER正常但吞吐就是低得离谱。一开始大家死磕覆盖认为功率到头了就该弱后来我翻调度统计才发现问题在SRS周期配置得太长基站拿到的信道估计已经严重过期按旧信息做的预编码完全不准导致MCS回退。把SRS周期从160ms调到40ms后问题立刻缓解。同一个“上行受限”结论根因一个在物理层一个在高层调度处理方式完全相反。所以遇到上行速率异常第一步不是改功率参数而是把MCS、BLER、PHR、SRS四类指标同步拉出来交叉看。5.2 双卡手机测试时忽略副卡状态会得“假速率”做终端路测时如果测试机插了两张SIM卡哪怕你测的是主卡副卡的周期性注册、TAU、寻呼响应这些活动也可能在上行时隙里挤占资源和终端处理能力。早期有次测试结果连续几天都是“上行只有几十Mbps”数据怎么都复现不了问题后来把副卡拔掉速率立刻恢复正常。现在我做所有上行专项测试都要求测试机只插一张卡或者至少确认副卡进入低活动状态。否则数据里混着端侧射频争抢定位问题毫无意义。这类坑在实验室脚本里经常被忽略到了外场就变成“见了鬼”的疑难杂症。5.3 NR 也有物理天花板别对 256QAM 和四流抱不切实际的期望NR上行虽然“起飞”但不是所有能力都能同时拉满。256QAM需要接近28dB的SINR基本只有近点才有条件上行四流要求终端有四路发射、网络侧配置多层传输、SRS资源充足三个条件缺一不可。目前不少商用手机的发射通路只有一两路拿标准手机去测看到单流64QAM是很正常的事。所以验证NR上行能力时先确认UE capability、看RRC重配里有没有激活多天线、再看SRS配置这几步做完再判断是设备问题还是终端能力问题。不查capability直接怀疑基站故障很容易被表象带偏。5.4 给普通用户的双卡彩信建议如果日常生活中经常需要在通话时发彩信、传文件我的建议很直接换支持双VoLTE、双5G的机型并且在手机设置里把“通话时可上网”或“智能切换数据卡”打开。发彩信前先确认当前用的卡数据开关是否打开、MMS APN里的MMSC地址填对了没有。对于还在用双卡单通老手机的用户别折腾网络设置了物理约束摆在那里。主卡正在通话时副卡发彩信大概率发不出去这不是网络问题是硬件设计限制。挂断电话再发往往一两秒就完成了。我自己现在做上行优化都会习惯性地先问一句“你测试的时候另一张卡在干嘛”这个问题的答案往往比后面一堆参数配置更能节省排查时间。PUSCH从LTE走到NR波形、调制、调度方式都变了但排障思路里“先确认你坐在哪个小区、哪张卡、什么状态下”这件事始终没变过。
