简介面向5G通信、网络优化及通信工程建设人员这份《LTE容量优化高负荷小区优化指导书》聚焦LTE热点区域高负荷问题围绕高负荷小区给出从定义、筛选到处理流程的完整优化闭环。内容系统讲解覆盖优化、参数调整、功能算法调整三大优化原则以及小区分裂、载频扩容、新建站扩容等扩容策略同时针对网络资源不足、PRB承载效率低、高用户数、低用户高流量等典型场景分别给出调整方案并附参考信号调整、重选优先级调整、负荷均衡等实操案例便于读者对照实施。文档按背景、定义、流程、优化原则、扩容原则、场景分类、案例、附件等模块清晰编排目录完整作为单个docx文件约258KB方便查阅与打印。适合网络优化工程师、技术支撑人员及通信工程相关从业者作为日常容量优化与方案编写的参考手册目前已有161人学习使用。1. LTE 容量优化里最容易被误判的一类小区高负荷不等于必须扩容做 LTE 容量优化的人最常踩进的一个坑是一看到“高负荷小区”四个字脑子里就自动弹出“扩容”两个字。这份指导书开篇就给出一个反直觉的结论高负荷只是一个现象背后可能是真的资源不足也可能只是覆盖没控好、参数没配好、用户被过度吸入。直接扩容是最贵的手段放最后用。整份文档的核心是先按“利用率、用户数、吞吐量”三个维度把高负荷小区切成七种场景再决定动手方向是调覆盖、调参数、开算法还是扩容建站。这份资源适合正在做 LTE 日常优化和容量专项的人尤其是需要批量处理高负荷小区清单的网优工程师读完能直接把判据和参数表拿去当工作手册用。2. 高负荷小区的判定逻辑三指标、两个门限、一个忙时时段的组合2.1 高负荷判定不能只看 PRB 利用率很多新人做高负荷筛选只盯着上行或下行 PRB 平均利用率超没超 50%这是最常见的片面做法。PRB 利用率高只能说明资源被占用得多但看不到是谁在占用、占用得有没有效率。一个全是边缘用户、都在用低阶 MCS 的小区PRB 利用率可能很高但吞吐量很低这种小区你去扩容等于给一个漏水的桶加水加多少漏多少。这份指导书的判定体系是三维的PRB 利用率、有效 RRC 连接平均数、小区忙时吞吐量。三个维度组合起来才能判断一个小区是“真缺资源”还是“资源在被低效消耗”。先看系统忙时的定义这是后面所有筛选的前提。2.2 系统忙时怎么定、门限值怎么设文档里的做法是取 24 小时每个小区 MAX(上行 PRB 平均利用率下行 PRB 平均利用率) 最大的时段作为系统忙时。也就是说忙时不是固定的晚高峰而是每个小区自己负荷最高的那个小时这样后面所有的判定都建立在最恶劣的情况下不会因为选错时段而漏掉真正的高负荷小区。门限值方面信道利用率门限是 50%有效 RRC 平均连接数门限分机型中兴和诺基亚是 50华为、爱立信、大唐是 30小区吞吐量门限是上行 1GB 或下行 5GB。注意这两类门限的组合方式直接决定场景划分我一般会先整理一张对照表防止记混指标维度门限适用机型信道利用率PRB 平均利用率50%全机型有效 RRC 平均连接数50 / 30中兴、诺基亚 / 华为、爱立信、大唐小区忙时上行吞吐量1GB全机型小区忙时下行吞吐量5GB全机型有效 RRC 连接最大数200超过即触发高负荷待扩容2.3 高负荷小区筛选三步走文档给出的筛选流程可以拆成三步这三步也是日常工作中最常被跳过的部分# 伪代码按三指标组合做场景分类 for cell in 小区列表: # step1: 定位系统忙时取该小时指标 busy_hour 全天24小时中 MAX(上行PRB利用率, 下行PRB利用率) 最大的时刻 prb MAX(busy_hour.上行PRB利用率, busy_hour.下行PRB利用率) rrc busy_hour.有效RRC连接平均数 throughput MAX(busy_hour.上行流量, busy_hour.下行流量) # step2: 高负荷待扩容判定 if prb 50 and rrc 门限 and throughput 门限: 场景 网络资源不足 - 扩容 elif prb 50 and throughput 门限: 场景 PRB承载效率低 - 覆盖/参数优化 elif rrc 门限 and prb 50: 场景 高用户数小业务 - 负荷均衡 elif prb 50 and rrc 门限 and throughput 门限: 场景 低用户高流量 - 无需调整 else: 场景 网络资源富余 - 持续监控这段逻辑的价值在于把“高负荷”拆成可执行的动作条件一满足时走扩容流程条件一满足但条件三不满足时说明资源被低效吃掉走参数和覆盖优化条件二满足但条件一不满足时说明人多但流量小走负荷均衡和重选调整。代码里的 prb、rrc、throughput 三个变量对应文档里的三套门限实际使用时把“门限”替换成对应机型的数值即可。2.4 数据获取的常见做法文档里提到通过 FTP 服务器下载核查结果一般是用 FTP 客户端连服务器用户名密码登录后取 D 盘 kettle 输出目录下的结果文件。日常项目里我习惯把核查脚本做成定时任务每天凌晨自动跑 kettle 流程早上直接看输出的场景分类表。如果取数链路不稳定优先检查服务器磁盘路径权限和按时段取数的逻辑而不是怀疑小区本身有问题。文件格式是 xlsx 的话用 Excel 透视表按小区维度聚合即可。3. 覆盖优化与参数优化先动射频再动参数最后才动算法3.1 参考信号功率调整的幅度与前提文档给出的射频优化手段主要有两个参考信号功率调整和天线覆盖范围调整。参考信号功率调整适用于“良好覆盖的热点区域数据量或用户数相差达到 50% 的主邻小区间”调整幅度是 3dB 一档。它的原理是通过改变导频功率来收缩或扩展小区的实际覆盖边界把边缘用户让给邻区。案例 8.1 里软件园湖北科技职业学院旁的 ZLH-3 小区RRC 用户数和激活用户数明显高于周边核查完覆盖、邻区、参数都没问题后把参考信号功率从 15 调到 12相当于收缩了 3dB 覆盖。调整后源小区用户数和数据量明显下降邻区增长量基本等于源小区减少量说明用户只是换了个小区驻留并没有丢失。我知道很多人在这个环节容易犯一个错光是调功率不先做邻区核查和切换关系分析。如果邻区关系不完整或者切换最多的那几个小区本身就覆盖不到位功率一压下来边缘用户直接掉线而不是切换走。3.2 天线调整的三个幅度参数天线覆盖范围调整适用场景是高站过覆盖或需要收缩覆盖的小区。文档明确写了三组幅度下倾角以 3 度为单位调方位角以 10 度为单位调。这个幅度不是随便定的下倾角调 1 度对覆盖距离的影响在 10 到 20 米量级工程上为了可复测可回退统一用 3 度步长更稳妥。方位角 10 度则是因为天线水平波瓣宽度通常 65 度左右一次调太小看不出效果一次调太大容易把主覆盖方向直接甩到另一个小区的地盘上。我在处理高站过覆盖时一般先做一轮扫频或 MR 定位确认过覆盖方向到底是哪个扇区造成的再结合被干扰小区的投诉数据决定往哪个方向转、转多少度。盲调天馈在 4G 优化里是翻车率最高的操作之一尤其是宏站密集区域一个站的天馈动了周边五六个站的切换带都会跟着变。3.3 参数优化里的五个可调项与应用场景这部分的参数体系比较细文档列了五个方向我按日常出镜率排一下小区重选优先级调整适用于 FD 共站址或共覆盖热点区域把高负荷小区的频内重选优先级从 7 调到 6 或 5同时降低低负荷邻区的频间重选优先级让用户更愿意驻留到异频低负荷小区。案例 8.2 里地大后勤的 F 频段小区用户数 130 以上D 频段同覆盖小区基本闲置因为同功率下 F 频段信号更强用户全被吸过去了。处理方式就是 F 频段优先级 7→5D 频段优先级 7→5同时把异频重选低门限从 16 调到 10放宽 D 频段被选中的条件。切换偏置、迟滞、偏移和时延调整面向高负荷小区切换最多的前三个邻区调整切换难易度让用户提前切到低负荷小区。最小单位量调整。A1/A2/A3/A4 门限调整主要用在室内外小区之间加快室外向室内或室内向外室的驻留切换。注意这里的异频切换测量门限和重选门限是两套体系别混。小区重选迟滞同频小区间用。降低高负荷小区的重选迟滞、升高低负荷小区的重选迟滞让用户更容易从高负荷小区走到低负荷小区。频间频率偏移异频小区间用降低高负荷小区的频间频率偏移加快向异频小区重选。这些参数涉及具体厂家、具体参数名的对照表文档里已经整理了参数分厂家统计表实操时以那个表为准。我一般会把同类参数按厂家各存一份本地库调参数前先查这个小区的历史参数配置防止重复调同一个方向造成过调。4. 负荷均衡算法调整两大机型的触发模式与落地参数4.1 中兴和华为的均衡触发逻辑差异这部分是整个优化手段里最体现技术含量的一块。文档明确了中兴和华为在负荷均衡上的触发依据完全不同中兴机型以 PRB 利用率为条件当小区 PRB 利用率到 70%且邻区 PRB 利用率低于 65% 时启动华为机型以用户数为条件当小区用户数到 40 且邻区用户数低于 20 时启动。这两种触发机制的差异意味着如果你用同一套参数思路去操作两家设备一定会出问题。中兴系的负荷均衡执行门限、邻区过负荷门限、候选目标小区判断门限都是围绕 PRB 利用率。适用的场景是同覆盖双载波小区FD 共站址。华为系则围绕用户数设置触发门限和偏置。4.2 华为与中兴的参数对照表文档里给了两张参数表我提炼成下面的核心字段厂家参数名称推荐值说明华为异频 MLB 开关 InterFreqMlbSwitch1打开异频负荷均衡华为负载均衡触发模式 MLBTriggerModeUE_NUMBER_ONLY按用户数触发华为异频负载均衡用户数门限40触发侧用户数华为负载均衡用户数偏置20目标侧用户数差值华为基于负载的异频 RSRP 触发门限-99dBm负载均衡时满足信号质量的门限华为基于覆盖的异频 RSRP 触发门限-95dBm覆盖切换的兜底门限中兴负荷均衡算法开关 ucLBSwch22 为基于事件测量切换方式中兴上行 ZTE 无线负荷均衡执行门限30原 65执行侧上行 PRB 利用率中兴下行 ZTE 无线负荷均衡执行门限30原 65执行侧下行 PRB 利用率中兴Intra-LTE 邻区过负荷门限25原 60候选邻区的负荷上限注意华为的 -99 和 -95 两个门限一个是用于负载均衡触发的 A4 门限一个是用于覆盖切换的 A4 门限。文档推荐值 -99 比 -95 更严苛也就是说负载均衡触发的信号质量要求更高避免把用户赶到信号太差的地方。案例 8.3 里给的是一个路口覆盖的 FD 共址站负荷均衡开关从 Close 调到 2中兴系上行执行门限从 65 调到 30邻区过负荷门限从 60 调到 25之后忙时 PRB 利用率降到 50% 以下RRC 连接用户从平均 54 降到 37。4.3 负荷均衡开关的两种模式的取舍中南区厂商的做法一般是开始阶段先不开盲切换先把基于事件测量的方式打开让 UE 在满足 A4 测量条件时才切到邻区这样至少保证目标小区的信号质量是够的。盲切换模式虽然可以快速把用户导过去但对目标小区的覆盖质量完全不设防容易批量制造掉线。案例里的调整是把开关从 0 调到 22 对应基于事件测量的切换方式说明这里没有选择盲切换常规项目我也更建议这么做。还有告警上的注意点开了负荷均衡后同站邻区的 X2 链路和小区状态必须核查否则均衡算法找不到候选目标小区功能等于没开。5. 避坑注意扩容前的判断、参数回退与均衡误伤5.1 不是所有高负荷都该扩容现象小区 PRB 利用率超了 50%但吞吐量只有几百 MB有效 RRC 用户数也不高仍然被列入扩容清单扩容后资源利用率还是下不来。原因这是典型的“PRB 承载效率低”场景资源被低阶 MCS 吃掉本质上不是缺资源而是覆盖质量差、干扰严重或者边缘用户太多。解决按文档的场景判读这种情况走射频优化和参数优化把低阶 MCS 占比降下来PRB 利用率自然回落。扩容是在这个动作做完之后还压不住才考虑。5.2 参考信号功率调完用户数降了但投诉也来了现象参考信号功率下调 3dB 后目标小区用户数明显下降但边缘区域用户反映信号变差、上网变慢。原因功率下调会收缩覆盖范围如果切换关系里没有足够的邻区兜底或者邻区本身覆盖有空洞边缘用户不会平滑切换而是留在原小区强撑着弱信号。解决调功率之前先核查切换关系确认需要承接用户的邻区都进行了双向邻区配置并且目标邻区的覆盖在调整后依旧能接住边缘用户。调整后至少观察一周的切换成功率与掉线率不能只看用户数。5.3 负荷均衡后出现用户乒乓切换现象开启负荷均衡后小区间切换次数突然翻倍用户在两个小区之间来回切换感知反而变差。原因触发门限和回退门限之间没有留出滞回空间用户被 A 小区赶去 B 小区B 小区的负荷均衡又觉得用户数多把用户赶回来。这种情况在华为系按用户数触发的模式下更常见因为用户数波动比 PRB 利用率快。解决要么设置合理的用户数偏置要么把均衡触发门限和释放门限拉开距离让均衡动作有回差。中兴系则可以把过负荷门限调低一些让候选邻区更容易被排除少一些无效均衡。5.4 高负荷处理后只看忙时指标忽略全天曲线现象忙时指标恢复了但全天其他时段的用户感知却下降了比如午休时段出现拥塞。原因参数调整和均衡算法只针对忙时场景设计没有考虑负荷的时间分布特征。解决处理高负荷小区时至少导出全天 24 小时曲线确认调整后每个小时的负荷都处于可接受范围而不是把忙时的负荷挪到了另一个时段。5.5 为了压指标把重选优先级调整过猛现象把高负荷小区的重选优先级直接从 7 调到 3用户确实大量迁出但低负荷小区很快变成新的高负荷小区问题原地转移。原因优先级调整幅度越大用户的迁移速度越快但目标小区的承接能力没有被评估。解决文档里的调整建议是每次调一个档位即从 7 调到 6 或 5观察后再决定要不要继续调。不要一次性跨太多档低负荷区的容量余量要先根据 RRC 连接数和 PRB 利用率预估。5.6 扩容后没有核查设备能力现象载频扩容后新加的小区起不来或者起来后频繁故障。原因RRU 能力不支持当前配置的载频数或者基带板资源不够。解决扩容前先核查设备的 RRU 型号支持的最大载频数和基带资源剩余量确认无误再操作。文档里明确写了频点扩容需严格按照 RRU 能力实施这一条是原则不是建议。6. 把场景判读做成一张表五个指标看懂一个小区该不该动最后分享一个我处理高负荷小区时用到的核心技巧把场景判读表压缩成一张“五格图”每次收到小区清单先按这张图过一遍再决定动手方向。判读的五个维度是上行 PRB 利用率、下行 PRB 利用率、有效 RRC 连接平均数、上行吞吐量、下行吞吐量。对每个小区先取系统忙时数据然后按以下顺序做组合判定。场景名称PRB利用率有效RRC连接数小区吞吐量第一动作备选动作网络资源不足高高高扩容小区分裂、新建站PRB承载效率低-A高低低射频优化干扰整治PRB承载效率低-B高高低参数优化负荷均衡高用户数小区低高不限负荷均衡重选优先级低用户高流量不限低高无需调整监控网络资源富余低低低不动监控判读的顺序有个小技巧先看吞吐量。如果下行吞吐量已经超过 5GB说明这个小区真的在承载大流量用户感知是有的这时再看 PRB 利用率。如果 PRB 利用率也高、用户数也高那就是资源不足扩容逻辑成立如果 PRB 利用率高但吞吐量低那就是典型的“有流量但效率低”先查 MCS 分布和 CQI再查干扰。如果吞吐量小于 1GB说明小区本身没什么数据压力这时候 PRB 利用率高只有一个解释控制信道开销大或者用户都在做小包业务这种场景开负荷均衡比扩容管用。我一直要求自己每次处理完一个高负荷小区都把判读结果和最终动作回填到一张跟踪表里持续观察两周。两周后如果指标稳定才算这个小区闭环如果指标反弹回查判读过程往往能发现当初有个指标被忽视。从那以后我每次拿到高负荷小区清单都强制自己先走一遍这张图不管时间多紧都先判场景再谈方案希望帮到你。本文还有配套的精品资源点击获取