简介面向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% 的属于业务量不足速率低可能是样本太少直接进优化清单会浪费人力。层级主要指标候选阈值示例数据来源小区级上行平均速率、上行 PRB 利用率、上行平均 MCS、PHR速率 5MbpsPRB 利用率 20%~80%MCS 均值 10PHR 均值 5dB网管 KPI / MR 统计用户级单用户上行体验速率、上行调度 TBS、重传率体验速率 1Mbps、重传率 5% 的用户占比超 20%话单 / MDT / 用户级 trace会话级灌包速率、TCP 窗口、RTT、RLC 分段灌包速率明显低于小区调度能力路测 / 定点测试 / 抓包用户级这一层很容易被跳过。小区级筛出的 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 干扰上行慢的头号杀手先看 IoT700M 上行对干扰极其敏感。上行干扰直接抬升底噪基站侧接收到的 SINR 下降MCS 被压低速率断崖式下跌。最典型的就是 IoT干扰噪声抬升指标拿小区忙时 IoT 均值和底噪对比看。IoT 抬升情况相对底噪判定建议动作小于 3dB底噪约 -120dBm/PRB基本正常不处理3~6dB抬升明显轻度干扰查外部干扰源、邻区参数大于 10dB抬升剧烈严重干扰紧急排查、资源协调判断干扰来源要看干扰的时间特征和频域特征。整段频带持续抬升优先怀疑外部干扰源只在某些 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覆盖受限PHR 低、MCS 低天馈调整上倾角/方位角增强上行覆盖提高 P0 或调大 α但要盯 IoTB干扰受限IoT 高、PHR 正常外部干扰源排查扫频弱化邻区互调、错开 PUCCH 资源C容量受限PRB 利用率高、用户多上行负载均衡把大流量用户分到附近小区开上行 MU-MIMO、加大带宽若可配A 类里天馈调整比功控调整更安全。700M 天线的电下倾角、机械下倾角对覆盖半径影响很大每调整 1 度下倾角覆盖边缘的 RSRP 可能变化 2~3dB。如果条件允许优先做天馈而不是直接动 P0因为天馈调整不动底噪不会引入系统内干扰。4.2 上行功控与调度的关键参数一张表看懂起调与边界以下参数在多数厂商网管里都能找到名称可能略有差异。需要特别说明的是参数调整必须从小步长开始每次只动一个参数观察 24 小时再决定是否继续。参数作用建议起始值边界与风险P0 Nominal PUSCH目标接收功率基准由 -100dBm 逐步上调每次 2dB上调超过 6dB 要重点盯 IoTAlphaα路损补偿系数0.8~1.0弱场小区可到 1.0边缘与近点相互影响α1 时功率控制补偿最强上行 MCS 下限/上限MCS 调度范围下限 0上限视小区能力上限抬高能提峰值但 BLER 会跟着涨SR 周期调度请求周期10ms 起步低速率小区可缩到 5ms太短增大信令开销短包业务才划算PHR 周期功率余量上报频率10ms~20ms太短增加上行开销过长收敛慢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, oncell_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 类场景的翻车进入验证通过名单。如果数据量不大甚至不用 pandasExcel 直接 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 变化结论700M_A_0013.2Mbps7.8Mbps1.2dB有效覆盖增益700M_B_0144.1Mbps5.2Mbps4.8dB无效存在干扰抬升需复核那张表的妙处在于结论不是「有效」两个字而是必须写出依据。速率提升、IoT 变化、PHR 变化三个数放在一起评审的人一眼就能看出这个优化结论是靠覆盖改善拿到的还是靠拉高功率换来的。后者虽然速率涨了但在干扰受限场景里是不可持续的必须标成「需复核」。我现在的习惯是每轮优化只列一次这张表并且把第 5 章的五个坑编成验证规则嵌在表里。比如「有干扰但结论写有效的直接打回」。这个规则很土但好用因为网优这件事的翻车往往不在理论而在细节没盯住。700M 上行低速率优化做得好不好最后比的不是谁懂更多公式而是谁能在验证表里多拦住一个假有效。希望帮到你。本文还有配套的精品资源点击获取