企业官网建设流程全解析

很多搞网优的朋友应该都有这种感觉：用户报障“上传慢”的比例，远比“下载慢”要高。下载速率不行，我们还能甩锅给服务器；上传不行，那可是物理层的问题。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 piggyback，NR里这种复用机制更灵活。所以PUSCH一堵，不只是网速变慢，信令流程都可能拖着走。

1.2 LTE 和 NR 的 PUSCH 长得完全不一样

同样叫PUSCH，LTE和NR里的实现可以说是两代人。我把关键差异列成一个表，方便对照着看。

看到这个表你就明白，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频段最大支持100MHz，FR2毫米波频段最大支持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直接相关的指标。

我把这些指标一列，你们大概就能明白现场定位的思路了。先看手机发射功率是不是顶格了，顶格了再看PHR，PHR无余量说明是覆盖问题；如果发射功率不高但BLER高，那就是干扰问题而不是功率问题，这时候加功率只会让邻居更难受。

5.2 快速估算上行速率的方法

我教大家一个现场快速估算上行速率的办法，不需要专业工具，Excel拉个公式就行。PUSCH理论速率的公式可以简化成：单RB子载波数12乘以传输符号数，乘以调制阶数，乘以有效码率，再乘以RB数和每秒的时隙数。

举例算一个贴近实际的场景：FR1，30kHz子载波间隔，系统带宽100MHz，可用RB数约273个？不对，100MHz@30kHz大概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.8，NR里可以更灵活配置。边缘小区想保覆盖，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自然就“起飞”了。