简介：这是一份面向5G网络优化工程师的专项技术文档，聚焦700M频段小区上行速率低于2Mbps、下行低于30Mbps的慢速问题，适用于FDD商用网络的日常优化与集团通报指标改善。文档系统梳理了低速率小区的判定规则，并重点解析影响上、下行速率的关键参数，如上下行CCE配比自适应开关、PDCCH聚合级别、PUSCH功率控制门限、上行波形自适应等，逐一给出默认值与FDD商用推荐值。针对AMC调整、OLLA大步长、关闭上行256QAM等场景，文档还附带了可执行的MML命令与黑名单配置示例，便于现场直接落地验证。资源为1个docx文件，压缩包仅约30KB，内容紧凑但完整，适合需要快速掌握700M低速率优化手段的网优一线人员参考。目前已有131人学习浏览，对正在开展700M专项优化或应对集团通报考核的团队具有实用参考价值。
1. 700M上行低速率小区优化：覆盖最好的频段，上行反而最拖后腿
做网优最怕的就是这种工单：下行速率正常，RSRP也漂亮，偏偏上行低速率用户投诉一串串地来。700M这个频段覆盖远、穿透强，建站时大家指望它兜底深度覆盖，可真正跑起运营指标才发现，上行低速率小区优化成了日常工单里最磨人的一类。原因不复杂：FDD低频上行带宽本身窄，终端多数单发，底噪又容易被外部干扰抬起来，一个环节出问题，用户体感就是“网页能开、图片转圈、视频传不上去”。
这篇文章按我自己处理这类工单的路径来写：先从指标拆解把问题分类，再讲功控、MCS、调度这些必调参数，接着排查干扰和终端这两个隐形因素，最后把踩过的坑和验证方法摆出来。做这个方向的兄弟可以参考这套动作复现，省得从头摸索。
2. 先定位再动手：把“上行低速率”拆成可排查的指标链条
2.1 上行速率的物理构成：调度RB、比特效率和时隙占用的乘积
用户上行速率不是网管里一个孤立的数，它本质上是三个因素的乘积：调度给用户的RB数、每个RB承载的有效比特数、以及单位时间内实际占用传输资源的比例。900M和1800M时代的经验也能套用到700M上——把这三个因素拆开，问题就定位了一半。
以常见的n28 30MHz带宽为例，上行是FDD独立频谱，按30kHz子载波间隔算下来约100个PRB。理论上限取决于调制阶数：256QAM、码率接近0.9时，物理层峰值可以摸到百兆左右，扣掉DMRS、PUCCH、SRS和PDCCH开销，用户面峰值大概在70到80Mbps。所以有个反直觉的结论：700M上行“低速率”往往是和理论峰值比低得离谱，而不是绝对值低到没法用。这也意味着，任何一点点资源浪费、MCS回落、额外重传，都会在最终速率上被放大。
我处理这类小区时，第一步从来不看速率本身，而是看三张分布：PUSCH平均调度RB数、PUSCH平均MCS、PUSCH初传误块率。RB数少是调度或带宽问题，MCS低是信道质量或限制配置问题，误块率高是链路或干扰问题。这三个数一出来，方向基本就定了。
2.2 从网管指标里快速锁定“病根”类型
网管指标多，不能用蛮力翻。我一般按下面这套顺序筛，优先级从高到低：
- 上行PRB级干扰统计。看平均干扰电平和干扰出现的PRB位置。平均底噪高于-112dBm/PRB就要当心，窄带干扰看特定RB位置，全带抬升多半是外部宽带干扰或系统内同频。
- PHR（功率余量）分布。PHR等于0的占比高，说明终端已经顶到最大发射功率，属于功率受限，再调参也要先解决覆盖或路损，否则就是硬顶。
- 上行平均MCS与误块率。如果MCS集中在低位但误块率不高，优先怀疑MCS表格限制或CSI/SRS测量不准；如果误块率高，优先查干扰和信道质量。
- 上行PRB利用率与激活用户数。利用率高且平均RB少，是容量问题，得开MU-MIMO或做负载均衡，而不是继续加功率。
- RSRP和SINR分布。RSRP好但SINR差，往往是干扰或者近场问题；RSRP也差，那就先做覆盖补盲。
这些指标在主流厂商网管里都能直接拉出来，只是名称不同。比如有的叫PUSCH SINR分布，有的叫PHR上报统计，命令路径也不一样，但看数的逻辑一致。我习惯把一张表拉全：每小区平均RB数、平均MCS、BLER、PHR分布、干扰电平、PRB利用率，横向对比同基站的其它小区，谁异常一眼能看出来。
2.3 现场复测的标准化动作：锁频、定UE、分点测
后台指标看完，现场必须跑，但跑法有讲究。上行速率测试最怕变量失控：测试终端漂移到别的频段、电话进来抢资源、或者站在天线正下方以为信号好结果SINR差到没法看。
我现场复测的标准动作是：
- 用支持n28的固定测试终端，同一台手机从头测到尾，不要中途换机。不同手机的上行发射通道数、最大发射功率不一样，换机等于改变量。
- 锁频到n28，有条件的话锁SA模式，关掉VoNR和VoLTE开关，防止语音业务抢占数据调度。
- 每个测试点至少连续测5轮，取中位数而不是最大值。单轮突高突低都说明不了问题。
- 记录每轮的RSRP、SINR、平均MCS、调度RB数、NACK率。测试App或网管侧都能拿到，没条件就用路测软件看物理层调度信息。
值得多说一句的是单点测试和拉网测试抓的是两种问题。单点极限速率抓的是“小区能提供多快的上行”，拉网平均速率抓的是“用户移动中体验到的上行”。如果是用户投诉类工单，拉网更能反映体感；如果是全网指标类优化，单点更适合验证参数调整。
3. 参数侧优化：上行功控、MCS与调度资源三项必调
3.1 上行功控：P0、alpha和PHR的配合逻辑
上行功控是低速率优化里最容易动手、也最容易翻车的参数。NR里PUSCH的发射功率大致按这个逻辑算：目标功率P0加上alpha乘以路损补偿，再顶上终端最大发射功率这个天花板。P0是开环基准值，alpha负责按路损做部分或全部补偿。
去现场之前，先看PHR分布：如果PHR为0的用户占比很低（绝大多数用户还有余量），但上行速率低，那问题不在功率，别乱调；如果PHR=0的占比明显高，说明大量终端已经顶到功率上限，这时有两个选择：把P0往上抬，或者把alpha往1.0调。
我一般会先做一步试探性调整，以某厂商参数为例：
// 查看当前上行功控参数 LST PUSCHPC: CELL=小区名; // 修改P0参考值，单位dBm，常见取值范围[-120, -80] MOD PUSCHPC: CELL=小区名, P0NOMINALPUSCH=-90; // 修改alpha，常见取值{0.0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0} MOD PUSCHPC: CELL=小区名, ALPHA=0.8;注意参数名以你用的厂商网管为准，思路是一样的：P0抬升3到5dB，观察PHR分布是否下降、MCS是否提升。这里的关键不是参数值本身，而是观察周期。功控调整后至少等一个话务周期（建议24小时）再看统计，不要调完两小时就下结论，用户分布和信道变化还没稳定。
另一个坑是P0调到-85以上之后，近点用户速率可能没变化，但远点用户和对邻区的干扰先上来了。所以P0调整要配合“误块率和干扰电平”一起看，如果干扰抬升超过2dB而MCS没涨，说明功率是浪费掉了，应该回退。
3.2 MCS限制与调制阶数：先看误码率再看限值
上行MCS是基站根据SRS测量和PUSCH实际解调结果估计的，再通过调度命令告诉终端用多大的调制阶数和码率。很多低速率小区的MCS被“限制”住了，不是信道差，而是配置本身不让它上去。
我排查的顺序是：先看PUSCH误块率。如果在目标值附近（一般配置10%左右），说明信道良好，那再看MCS分布是不是被限制在某个区间。有些小区为了保守，把maxMCS限制在15（即64QAM以下），或者是mcs-Table配置成不支持256QAM的表格，直接把上行峰值砍掉一截。
尝试打开更高阶调制时，需要确认终端侧能力。以某厂商网管为例：
// 查看PUSCH最大MCS限制，qpsk=0~10，16qam=11~16，64qam=17~21，256qam=22~27 LST PUSCHMCS: CELL=小区名; // 将最大MCS放开到27（256QAM） MOD PUSCHMCS: CELL=小区名, MAXMCS=27;参数放开的逻辑很简单：让调度器有更多选择空间。但有一个非常容易忽略的点——上行256QAM需要足够好的SINR，通常SINR要大于22dB左右才能用高码率256QAM。700M低频场景下，近点能做到，中远点很难。所以放开maxMCS不影响近点组合增益，但也不会让中远点速率凭空长起来，它只是去除上限，不负责改善信道。
还要检查SRS周期与带宽。SRS是基站估信道用的，周期太长或者带宽太窄，基站对信道估计不准，就会倾向于用保守MCS。把SRS周期从20ms缩短到10ms甚至5ms，经常能换来一到两个MCS等级。代价是SRS在时频资源上的开销变大，对上行容量有损耗，低速率单用户场景下划算，高话务小区要权衡。
3.3 调度资源：PUCCH/SRS压缩与MU-MIMO配对
很多时候参数全对，速率起不来，是“资源被杂项吃掉了”。上行明明只有100个PRB，PUCCH和SRS又占掉边带一部分，PUSCH的调度灵活度就下降。典型表现是PRB利用率不高，但用户能分到的连续RB就是少。
PUCCH是承载UCI（调度请求、HARQ反馈、CSI）的物理信道，通常配置在带宽边缘。如果PUCCH周期短、资源块多，它会占掉不少上行边带RB。700M上行带宽本来就窄，这块油水值得挤一挤。做法是查看PUCCH资源配置，把周期调大些、把每个周期的RB数压一压，前提是不影响HARQ反馈和CSI上报的实时性。注意不要压太狠，否则下行吞吐会跟着遭殃，因为HARQ反馈跟不上会引发更多下行重传。
SRS同样有压缩空间。SRS周期拉长、带宽收窄，都能省出RB给PUSCH。但对于上行MCS敏感的小区，SRS砍太多反而让链路估计变差，这个度要在现场试，我一般按“先看MCS有没有下降”来判断SRS是否砍过头了。
上行MU-MIMO是另一条路。当小区激活用户多、PRB利用率高但单用户RB少时，开启上行多用户配对，两个用户可以在相同RB上同时传输，前提是信道正交性好。700M低频大天线间距下，配对成功率通常高于高频。开启后看两个指标：配对增益和SINR损耗。如果配对后小区吞吐涨了而单用户速率没掉太多，就值得保留。
4. 干扰与终端侧：两个最容易被700M上行吞速率的隐形因素
4.1 底噪抬升与PIM：上行速率指标往往差在看不见的干扰
上行速率对干扰极其敏感，因为干扰直接压SINR，SINR压MCS，MCS压速率。700M的麻烦在于它频段干净，但“干净”只是纸面上的——广电清频之后，附近仍可能有广播电台、模拟电视残留信号、私装放大器的杂散信号在700M上行频段里冒头。天气变化、对流层传播、大风引起天线摆动，都会让这些底噪时有时无，非常难抓。
干扰排查的第一步是看网管里上行PRB级干扰统计的时间趋势和频域位置。窄带干扰通常固定出现在几个RB上，宽带干扰则是整段抬升。如果干扰电平随时间变化明显，和早晚话务、风速、雨后温度变化关联，就要怀疑是外部系统干扰而非本小区自干扰。
另一种常见且隐蔽的干扰是PIM（无源互调）。症状非常典型：小区下行流量越高，上行底噪越高；下行一闲，上行干扰就回落。这是塔上天线、馈线接头、双工器或其它金属件在强下行信号激励下产生的互调产物，正好落入上行接收频段。判断方法很简单：在网管里把小区下行发射功率降3dB（或直接闭掉部分下行通道），观察上行干扰是否同步下降。下降量明显，基本可以锁定PIM。解决手段是排查射频链路——紧固接头、更换老化的双工器或天线，网优侧能做的只是定位，最终得靠硬件整治。
| 干扰类型 | 典型特征 | 排查手段 |
|---|---|---|
| 系统外宽带干扰 | 全PRB底噪抬升、波动大 | 频谱仪扫描、扫频测试 |
| 系统外窄带干扰 | 固定RB位置干扰突出 | 看PRB级干扰图、识别规律 |
| PIM无源互调 | 干扰随下行流量变化 | 降功率观察相关性、检查射频器件 |
| 系统内同频干扰 | 忙时明显、邻区负载相关 | 看邻区干扰协调配置、降功率验证 |
4.2 终端能力差异：单发双发决定用户上行上限
后台参数调得再漂亮，用户终端不支持也白搭。700M低频上行的一大痛点是很多手机只支持单发（1T1R），低频段天线尺寸大，终端内部塞下第二路发射链路有物理限制。少数机型支持1T2R，但多数中低端机在n28上就是单发。
看网管里的终端能力上报最直接：
// 查看用户终端上行能力分布（按最大发射功率和发射通道数统计） LST UE CAPABILITY: CELL=小区名; // 查看PHR报告，区分功率受限用户比例 LST PHR STAT: CELL=小区名;这两条命令的用途不一样。终端能力分布用于判断小区用户群的“硬件上限”，如果小区里大量用户是低功率等级终端（最大发射功率23dBm，对应PC3），那即便把P0调到天际，这些用户的PUSCH功率顶格也就那么多，上行速率注定有硬上限。
典型的用户体感差异是：同一位置，A手机上行能跑50Mbps，B手机只能跑20Mbps。不是网络问题，是终端2T和1T、PC2和PC3的差别。这种问题网优只能识别、上报，不能靠参数解决，但识别得越早，就越不会在参数上浪费工时。
4.3 语音业务抢占与锚点策略
VoNR通话对上行资源的抢占是隐形的“速率杀手”。NR里语音承载优先级高，调度器会优先保证语音的RB和时延，数据业务只能在剩余资源里挤。用户拿着手机一边打电话一边传视频，上行速率掉到几M是正常的。
测速前一定要确认测试终端没有驻留语音通话，后台统计时也要把语音业务时段的数据剔除。还有一个更隐蔽的问题是EPS Fallback：SA终端发起语音时回落到4G，如果回落锚点选在了覆盖差或负载高的4G小区，通话结束后终端可能没有及时返回5G，用户还在4G频段，自然测不到700M上行速率。这种场景查定时器和回落策略就能解决，不用动700M本身。
5. 700M上行低速率优化避坑：5条踩出来的经验
5.1 调高P0后速率反而降了
- 现象：弱场用户占比高，PHR=0比例超过30%，把P0从-95调到-85之后，平均上行速率不升反降，邻区上报干扰抬升。
- 原因：P0抬高让所有用户提高发射功率，近点用户受益有限，中远点用户已经顶到功率天花板没变化，反而抬高了本小区对同频邻区的干扰，邻区用户的SINR被压制，MCS整体回落。
- 解决：先分层看PHR分布，P0调整只针对“RSRP中等但PHR偏低”的用户群才有效率。如果PHR=0集中在极远点，应该先处理覆盖而不是调功控；如果集中在近点，多半是终端功率等级限制，调参没用。高话务小区建议配合ICIC或降低alpha，避免全小区功率同时爬升。
5.2 干扰统计正常，现场却跑不动
- 现象：网管里上行PRB级干扰平均值低于-115dBm，“看着很干净”，但现场连续测速都上不去，MCS普遍在10以下。
- 原因：网管干扰统计是15分钟或小时级平均，PIM和外部干扰往往是突发性的，偶发干扰被平均统计抹平了。另一种情况是干扰只出现在个别PRB上，平均值拉低但峰值一直在踩PUSCH的实际调度资源。
- 解决：把干扰统计粒度切到分钟级，看峰值趋势而不是平均值；把PRB级干扰图和PDSCH/PUSCH调度RB位置叠起来看，确认干扰是否正好落在调度频繁的RB上。现场用频谱仪扫天线口，能抓到网管上看不到的信号。
5.3 参数和邻区一模一样，速率差一倍
- 现象：两个同型小区覆盖相邻，功控、MCS、调度参数完全一致，邻区上行平均40Mbps，工单小区只有15Mbps，误块率也不高。
- 原因：参数一致但带宽资源不一致。常见的是BWP配置只分配了部分带宽（例如只配了20MHz），或者PUCCH和PRACH资源在带宽边缘挤占太多，调度器能分给PUSCH的有效RB比邻区少一大截。
- 解决：核对BWP大小和PUCCH/SRS/PRACH资源配置，把带宽和开销摊开算一遍实际可用PUSCH RB数。这类问题靠看参数表就能发现，但很容易被“参数一致”的假象带偏，忘了比可用资源。
5.4 换了一批终端后上行集体变慢
- 现象：某个月开始，小区上行速率分布整体下跌，基站无告警、干扰无变化，翻PHR也没看到功率受限。
- 原因：用户终端换机潮导致机型占比变化。有些新机型在700M上只上报64QAM上行能力、或发射功率等级低于老款，整网用户能力下限被拉低，平均速率自然走跌。
- 解决：拉终端能力分布按周对比，看看是不是某个机型或某类能力等级的设备占比突增。确认后如实写进优化报告，这类问题该推动终端侧解决就推动终端侧解决，基站参数再怎么调也变不出终端没有的能力。
5.5 单点测速“很好”，全网指标“翻车”
- 现象：优化后现场单点测速峰值涨了20Mbps，但后台“上行低速率用户占比”指标纹丝不动，甚至小幅恶化。
- 原因：单点测速选在信号最好的位置、用的高端测试终端、还挑的是闲时。全网用户集中在室内、中远点、中低端终端上，单点达标根本代表不了用户分布。
- 解决：验证优化效果要看用户分布视角，把小区用户按RSRP分箱统计每档速率，至少看P10（最低10%用户）有没有抬升。只盯峰值或均值，优化方向就会被带偏。
6. 用调度速率验证优化效果：比单点测速更稳的复盘方法
参数调整后怎么确认有效，我的习惯是看“调度速率”而不是看测速软件的瞬时值。所谓调度速率，就是把小区上行MAC层吞吐除以实际参与调度的时隙数，或者直接用平均调度RB数乘以平均每RB有效比特再折算出来。它排除了用户数、业务模型的影响，体现的是这个小区当前“愿意给用户多快的上行能力”，比任何单点测速都稳定。
具体做法是优化前后各取三天的同一时段（比如每天上午10点到11点），记录四组数：平均RB数、平均MCS、误块率、PHR分布。四组里RB数和MCS抬升、误块率不涨，基本可以断定参数方向正确。如果只看最终速率，用户多寡和业务大小会把信号淹没。
我还有个习惯是给测试结果做RSRP分箱统计。按“RSRP大于-85”、“-95到-85”、“-105到-95”、“小于-105”四档分别算平均速率和MCS分布。这能清楚看出参数调整到底惠及了哪段用户，避免近点速率涨了、中远点反而跌了这种“局部优化”。第10百分位用户速率，比平均值更能代表投诉用户的真实感受。
回到开头那个工单：700M上行低速率这个问题，从来没有“一把参数调好”的银弹。它需要后台指标定位、现场复测交叉验证、功控MCS调度逐项试、干扰终端逐个排除，最后再用数据确认收益。我做这类优化最大的教训是：不要拿到网管速率低就急着动参数，先花半天把指标拆干净，动手时反而快。希望这些排障路径和踩坑经验帮到你，让你下次接到700M上行低速率工单时，能少走几段弯路。
本文还有配套的精品资源，点击获取
