700M上行低速率小区优化：从指标筛选到参数避坑全指南

简介：面向5G网络优化工程师的700M上行低速率小区专项优化文档，聚焦上行低于2Mbps、下行低于30Mbps的低速率场景判定与参数调优。资源系统梳理低速率小区定义、CCE配比自适应、PDCCH聚合级别、PUSCH功率控制、上行波形自适应等20余项关键参数，给出默认值、商用推荐值及MML调整命令，并附有上行AMC优化、关闭256QAM等典型手段，适合从事700M频段网络优化、干扰排查与KPI提升的工程师参考。包体为docx格式文档，共1个文件，大小约30KB，内容结构清晰，可直接作为优化指导手册使用。目前已有131人学习下载，对正在处理低速率TOP小区或准备集团通报材料的人员具有实用价值。

1. 700M 上行低速率小区优化不是玄学：先弄清问题到底卡在哪

700M 上行低速率小区优化，表面看就是把网管里那批上传不达标的小区挑出来，调调功控、动动天馈。但我有一次从晚上十点忙到凌晨三点的返工：一个 700M 小区下行 RSRP 报表漂亮得很，用户却反复说图片发不出去、视频上传转圈，上行速率常年压在 1~2 Mbps。后来排查发现根本不是覆盖弱，而是上行干扰抬升叠加功控参数被上一轮调得太激进，功率越加，IoT 越高，速率越慢。这个场景几乎能代表这一类优化：700M 低频覆盖好，但带宽窄、上行受限多，低速率问题往往不是单一原因，而是一串因素叠出来的。

标题挂的是「700M 上行低速率小区优化.docx」这类方案文档的壳，但壳里的肉永远是五件事：先定位问题小区，再判断根因，然后把动作落到参数和天馈上，同时留好后路，最后用一张验证表确认优化真的生效。这篇就按这条线展开，适合负责 4/5G 协同优化、指标盯盘和现场调整的网优工程师；新手能照着筛小区，熟手可以直接看参数边界和踩坑。

2. 先把问题小区找出来：上行低速率小区的指标口径与四步筛选法

2.1 为什么不能只看“上行速率”这一个指标

很多同事拿到指标第一时间就按上行速率排序，谁低点谁。这个习惯会带来两个误判：一是小区平均速率被大流量用户拉高，真正体验差的用户被淹没；二是只看速率不看上下文，速率低到底因为没用户、没调度、还是调度了但传不动，完全分不出来。上行速率是一个结果指标，背后至少有四个过程指标跟着联动：PRB 调度情况、MCS 选择水平、HARQ 重传与丢包率、功率余量 PHR。把这四个过程指标和应用速率放一起看，才能定位低速率的原因层级。

700M 频段的特殊性进一步放大了这个需求。低频覆盖好、穿透强，下行 RSRP 通常不会太差；但上行链路预算受限，终端发射功率只有 23dBm 左右，带宽又窄，一旦出现路径损耗大、干扰抬升或者功控收敛异常，上行速率会断崖式下跌，而下行指标可能完全正常。所以筛选 700M 上行低速率小区，不能只拉一张速率表，得按「小区级 → 用户级 → 会话级」三层去筛。

2.2 三层筛选口径：用表格把候选小区框出来

我一般先拿连续 7 天、每日 6 个忙时的数据做小区级筛选。忙时取 11~13 点和 18~21 点，能覆盖白天和晚高峰两类业务模型。候选阈值可以这样定：上行平均速率低于 5Mbps，同时上行 PRB 利用率在 20%~80% 之间。之所以卡 PRB 利用率，是为了把两类小区分开：利用率超过 80% 的属于高负荷拥塞，处理方式偏容量；利用率低于 20% 的属于业务量不足，速率低可能是样本太少，直接进优化清单会浪费人力。

用户级这一层很容易被跳过。小区级筛出的 100 个小区里，真正值得动手的往往只有一半；另一半是少数弱场用户把平均值拖下来，或者某类低端终端占比高造成的。用用户级指标复核一遍，能把「小区病了」和「小区里几个用户病了」分开。会话级则用于现场复测时做对照，确认优化前后在同等无线环境下的速率变化。

2.3 用一条 SQL 把候选小区拉出来

小区级筛选完全可以用网管导出或数据仓库的 SQL 完成。不同厂商字段名有差异，但逻辑一致，以下按常见 KPI 表结构写：

SELECT cell_id, AVG(ul_throughput_mbps) AS avg_ul_rate, AVG(ul_prb_util) AS avg_ul_prb_util, AVG(ul_mcs) AS avg_ul_mcs, AVG(ul_bler) AS avg_ul_bler, AVG(pusch_phr_db) AS avg_phr, COUNT(DISTINCT ue_id) AS active_ue_cnt FROM kpi_daily WHERE stats_date BETWEEN '2025-01-06' AND '2025-01-12' AND busy_hour IN (11, 12, 13, 18, 19, 20, 21) GROUP BY cell_id HAVING avg_ul_rate < 5 AND avg_ul_prb_util BETWEEN 20 AND 80 ORDER BY avg_ul_rate ASC;

这条查询做了四件事：限定 7 天忙时窗口，计算每个小区在上行速率、PRB 利用率、MCS、BLER、PHR 上的忙时均值，然后用 HAVING 过滤出速率低于 5Mbps 且 PRB 利用率处于 20%~80% 的小区。PHR 均值和 MCS 均值先不设硬条件，而是放进结果里一起看，因为这两个指标对下一步根因判断很有用：PHR 普遍低，指向上行覆盖或功率受限；PHR 高但速率低，更可能是干扰或调度问题。

注意 busy_hour 这个字段在不同平台的命名可能不同，有的按小时整数存，有的按「忙时标识」存。如果平台上没有现成的忙时标签，建议直接在代码里用 HOUR(timestamp) 做过滤，避免取到凌晨低业务时段的数据，凌晨一两个小时的大流量下载能把全天均值拉到一个失真的水平。

2.4 筛完之后按场景分 A/B/C 类

拿到候选清单后先别急着调参数，按场景分一下类，后面的动作才不会乱。我一般分三类：

• A 类：速率低 + PHR 低 + MCS 低，指向上行覆盖受限，重头戏在天馈和功率控制。
• B 类：速率低 + PHR 正常 + IoT 抬升，指向干扰，重头戏在干扰排查和资源协调。
• C 类：速率低 + PRB 利用率高 + 用户数多，指向容量，重头戏在负载均衡和容量方案。

分完类再动手，能避免一类经典翻车：明明是 B 类干扰问题，却按 A 类去加功率，结果干扰更高，速率更低。第 3 章就按这个分类讲根因验证。

3. 根因判断分四路：覆盖、干扰、功率控制与终端配合分别怎么验证

3.1 覆盖：700M 上行链路预算的物理底子

700M 的优势在覆盖半径大、穿透损耗小，但这对下行更有利。上行链路里，基站发射功率可以做到单载波 80W 甚至更高，而终端发射功率上限只有 23dBm。低频路径损耗虽然小，同样 1000 米覆盖半径下，基站侧接收到的上行信号强度仍然可能很勉强。这就是为什么 700M 小区经常出现「下行满格、上行拉胯」的现象：下行覆盖好不代表上行链路预算够。

验证上行覆盖是否受限，最直接的一组数据是 RSRP 分布加上 PHR 分布。正常情况下，700M 小区内 PHR 均值能在 10dB 以上；如果大量用户 PHR 集中在 0~3dB，说明终端已经逼近最大发射功率，这时候上行速率上不去，第一个嫌疑就是覆盖。另一个办法是做一次定点路测：在小区边缘找几个点，分别测 RSRP 和上行灌包速率，看两者之间的对应关系。RSRP 在 -100dBm 附近而灌包速率掉到 1Mbps 以下，基本可以判定上行覆盖受限。

3.2 干扰：上行慢的头号杀手，先看 IoT

700M 上行对干扰极其敏感。上行干扰直接抬升底噪，基站侧接收到的 SINR 下降，MCS 被压低，速率断崖式下跌。最典型的就是 IoT（干扰噪声抬升）指标，拿小区忙时 IoT 均值和底噪对比看。

判断干扰来源要看干扰的时间特征和频域特征。整段频带持续抬升，优先怀疑外部干扰源；只在某些 PRB 上周期性出现，优先怀疑系统内干扰，比如邻区配置问题或 PUCCH/PUSCH 资源碰撞。700M 频段还要多留一个心眼：和广播、电视等大功率台站的杂散信号偶发碰撞，现场扫频排查往往比参数调整更有效。

3.3 功率控制：越调越慢的常见原因

上行功控参数是 700M 上行低速率优化里最容易被调错的一组参数。PUSCH 功控的核心公式可以简化为：发射功率 = P0 + α × 路损 + 其他修正项。P0 决定目标接收功率，α 决定对路损的补偿程度。α 越大，越边缘的用户越拼命抬功率；P0 越高，整个小区用户的目标接收功率都越高。

问题出在这是一个正反馈过程。P0 调高 2dB，所有用户的发射功率都会上涨，小区底噪随之抬升，基站侧测到的 SINR 不一定变好；更麻烦的是，700M 上行是干扰受限场景，功率一起抬，邻区间的干扰也跟着抬，最后可能是全网一起慢。我见过一次优化记录：为了拉边缘速率把 P0 从 -100 调到 -90，边缘速率短期涨了，三天后全小区 IoT 抬了 5dB，平均速率反而比优化前更低。这种「越调越慢」在低频上行场景里不是小概率事件。

3.4 终端配合：同一小区两只手机速率差一倍

还有一个经常被忽略的变量是终端。700M NR 上行速率上限和终端能力强相关：支持双发（上行 2 流）的终端在弱场明显优于单发终端；支持 256QAM 调制的终端峰值更高，但在边缘场景优势有限；SA 和 NSA 模式下，上行调度策略不同，速率表现也会有差异。

验证方法不复杂：在同一个测试点，用两部不同档位的终端做对比灌包。如果两部终端的速率差异超过 50%，先别着急改网络参数，查一下终端能力上报里的上行 MIMO 层数、SRS 天线数、PHR 周期设置。我一般会在优化方案里加一句「同一场景下对比测试需标注终端型号」，这一句能省掉大量重复返工。把覆盖、干扰、功控和终端四路分开验证完，再进入第 4 章的参数和天馈动作。

4. 把优化动作落到参数和天馈上：六类动作与两轮验证周期

4.1 先分场景再动手：A/B/C 类小区各做点什么

第 2 章分出的 A/B/C 类，到这一章变成动作清单。我的习惯是每个小区只动一类主参数，不要在一次变更里同时改功控、改调度、又改天馈，否则后面根本不知道是哪个动作起的效果。

A 类里天馈调整比功控调整更安全。700M 天线的电下倾角、机械下倾角对覆盖半径影响很大，每调整 1 度下倾角，覆盖边缘的 RSRP 可能变化 2~3dB。如果条件允许，优先做天馈而不是直接动 P0，因为天馈调整不动底噪，不会引入系统内干扰。

4.2 上行功控与调度的关键参数：一张表看懂起调与边界

以下参数在多数厂商网管里都能找到，名称可能略有差异。需要特别说明的是，参数调整必须从小步长开始，每次只动一个参数，观察 24 小时再决定是否继续。

P0 和 α 的关系一句话就能说清：α 决定「边缘用户补偿多少」，P0 决定「所有人都参照的基准线是多少」。700M 低频场景普遍弱场用户多，我一般先固定 α=1，再小幅调 P0，每次 2dB，观察 IoT 和边缘用户速率。如果 IoT 抬升超过 3dB 而边缘速率没跟上，就立刻停手，说明已经过了临界点。

4.3 一个不用网管命令行的批量对比脚本

参数和天馈动作落完后，需要把优化前后的 KPI 合并成一张对比表。网管平台导出的 CSV 往往命名混乱，我习惯用一段简单脚本处理。以下脚本读取两个导出的 CSV，按小区 ID 做合并，输出关键指标的差值和符号方向：

import pandas as pd before = pd.read_csv("ul_rate_before.csv") after = pd.read_csv("ul_rate_after.csv") merged = before.merge(after, on="cell_id", suffixes=("_before", "_after")) merged["rate_delta"] = merged["ul_rate_after"] - merged["ul_rate_before"] merged["iot_delta"] = merged["iot_after"] - merged["iot_before"] hit = (merged["rate_delta"] > 1) & (merged["iot_delta"] < 2) merged["result"] = hit.map({True: "有效", False: "需复核"}) print(merged[["cell_id", "rate_delta", "iot_delta", "result"]])

这个脚本的逻辑是：优化生效的判定条件设为「上行速率提升超过 1Mbps，且 IoT 抬升小于 2dB」。第二条很关键，它能自动把「靠拉高干扰换来的速率提升」识别成需复核，防止 B 类场景的翻车进入验证通过名单。如果数据量不大，甚至不用 pandas，Excel 直接 VLOOKUP 也能做同样的事，但脚本的好处是结果可以留档，回头复盘时不会因为换电脑丢了中间结果。

4.4 两轮验证：7 天观察和一次现场复测

参数调整不能当天就下结论。第一天速率上涨可能只是功率抬升的短期效应，三天后干扰抬升才会显现。我一般按两轮来验证：第一轮是网管侧 7 天观察，只看忙时均值，重点盯上行速率、IoT、PHR 三个指标；第二轮是现场复测，挑一个优化前问题最严重的点，用同一部终端、同一条路线做灌包测试，和优化前的数据进行点对点对比。

这个节奏也是给后续留余地。7 天内发现问题，可以快速回退参数；超过 7 天业务模型变化，再比较就不公平了。验证通过的小区，标记为「已闭环」；验证不通过的，回到第 3 章重新做根因分析，而不是继续堆参数。

5. 避坑：700M 上行优化最容易翻车的五个场景与回退办法

优化做多了就会发现，问题小区翻车的套路就那么几种。把高频坑写进方案文档的「风险与回退」章节，比写多少条优化原则都管用。以下五个场景我基本都遇到过，每条按现象、原因、解决三句话说清。

5.1 场景一：P0 加过头，IoT 抬升后越调越慢

现象：优化当天上行平均速率从 4Mbps 涨到 6Mbps，三天后回落甚至跌破原来水平，边缘用户投诉变多。

原因：P0 上调带动全网终端发射功率普涨，小区底噪和邻区间上行干扰同步抬升。短期边缘速率的改善被长期 SINR 恶化抵消，700M 属干扰受限场景，这个过程常常在 48~72 小时后才显现。

解决：P0 每次只加 2dB，最多连续调两次；每次调整后 24 小时看 IoT。如果 IoT 抬升超过 3dB 而平均速率没有持续上涨，立即回退到上一个值。回退不用等 7 天，参数取反即可，但要在网管变更记录里写明原因。

5.2 场景二：拿平均速率当用户体验，漏掉多用户吞吞吐量

现象：小区平均上行速率 8Mbps，指标排在前面，但单个用户的体验速率只有几百 kbps，用户投诉不断。

原因：平均速率被少数大流量用户拉高。700M 小区带宽窄，一个用户占满上行 PRB 时，其余用户只能等调度；如果上行 active 用户数多，平均速率根本反映不了真实体验。

解决：筛选阶段必须加用户级指标：统计上行体验速率低于 1Mbps 的用户占比，超过 20% 就进优化清单，哪怕平均速率达标。优化时优先做用户数相关的容量判断，别急着动功控，先查是不是有用户长期占着上行资源。

5.3 场景三：只看 MCS 不看 BLER 和重传，速率虚高

现象：优化后 MCS 从 8 升到 14，报表很漂亮，但灌包速率没涨多少，RLC 层重传率却在上升。

原因：MCS 只是调制编码方式的期望值，实际传输效果要看 BLER。功控或 SRS 参数调整让基站误以为信道质量更好，调高了 MCS，但实际 SINR 撑不住，触发大量 HARQ 重传，空口资源被重传吃掉。

解决：看指标必须三件套一起看：MCS、BLER、重传率。正常经优化的上行 BLER 目标一般控制在 5%~10%，如果 BLER 超过 15% 且重传率同步上升，说明 MCS 目标调得高于实际信道质量，把 MCS 上限往回压一档，比继续加功率更有效。

5.4 场景四：终端差异被当成网络问题反复返工

现象：同一小区、同一位置，终端 A 灌包速率 20Mbps，终端 B 只有 8Mbps，现场反复调参无果。

原因：终端能力差异，尤其是上行双发、SRS 天线端口数、是否支持 256QAM 的差异。700M 上行对终端能力敏感，弱场下单发终端速率可能只有双发终端的一半。

解决：所有现场测试都标注终端型号和软件版本；对比测试必须用同一终端。如果确认是终端能力差异，在方案文档里如实标注「该小区非网络受限，属终端能力上限」，别让优化组为终端特性背锅。

5.5 场景五：参数改完不留快照，出了问题没有后悔药

现象：一版参数调了半个月，某天速率骤降，想回退却想不起原始值，只能靠猜。

原因：网管参数修改没有做变更快照，人员变动后原始参数丢失。优化动作越多，越记不住哪些参数动过、动了几次。

解决：每次修改前导出该小区的参数全量快照，存到按日期命名的目录里；每次修改记录一条变更日志，至少包含参数名、旧值、新值、修改人、修改时间。回退时直接恢复快照文件，再做一次 24 小时观察。这个习惯成本极低，能挡掉大半返工。

6. 用一张验证表确认优化真的生效：我留给自己看的检查单

优化方案的最后一节，我从来不放套话，只放一张检查单。表头固定几列：小区编号、优化前速率、优化后速率、IoT 变化、PHR 变化、MCS 变化、BLER、结论。逐条填完，方案才算收口。

那张表的妙处在于：结论不是「有效」两个字，而是必须写出依据。速率提升、IoT 变化、PHR 变化三个数放在一起，评审的人一眼就能看出这个优化结论是靠覆盖改善拿到的，还是靠拉高功率换来的。后者虽然速率涨了，但在干扰受限场景里是不可持续的，必须标成「需复核」。

我现在的习惯是：每轮优化只列一次这张表，并且把第 5 章的五个坑编成验证规则嵌在表里。比如「有干扰但结论写有效的，直接打回」。这个规则很土，但好用，因为网优这件事的翻车往往不在理论，而在细节没盯住。700M 上行低速率优化做得好不好，最后比的不是谁懂更多公式，而是谁能在验证表里多拦住一个假有效。希望帮到你。

本文还有配套的精品资源，点击获取