企业官网建设流程全解析

简介：面向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。注意这两类门限的组合方式直接决定场景划分，我一般会先整理一张对照表防止记混：

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 参数优化里的五个可调项与应用场景

这部分的参数体系比较细，文档列了五个方向，我按日常出镜率排一下：

小区重选优先级调整：适用于 F+D 共站址或共覆盖热点区域，把高负荷小区的频内重选优先级从 7 调到 6 或 5，同时降低低负荷邻区的频间重选优先级，让用户更愿意驻留到异频低负荷小区。案例 8.2 里地大后勤的 F 频段小区用户数 130 以上，D 频段同覆盖小区基本闲置，因为同功率下 F 频段信号更强，用户全被吸过去了。处理方式就是 F 频段优先级 7→5，D 频段优先级 7→5，同时把异频重选低门限从 16 调到 10，放宽 D 频段被选中的条件。

切换偏置、迟滞、偏移和时延调整：面向高负荷小区切换最多的前三个邻区，调整切换难易度，让用户提前切到低负荷小区。最小单位量调整。

A1/A2/A3/A4 门限调整：主要用在室内外小区之间，加快室外向室内或室内向外室的驻留切换。注意这里的异频切换测量门限和重选门限是两套体系，别混。

小区重选迟滞：同频小区间用。降低高负荷小区的重选迟滞、升高低负荷小区的重选迟滞，让用户更容易从高负荷小区走到低负荷小区。频间频率偏移：异频小区间用，降低高负荷小区的频间频率偏移，加快向异频小区重选。

这些参数涉及具体厂家、具体参数名的对照表，文档里已经整理了参数分厂家统计表，实操时以那个表为准。我一般会把同类参数按厂家各存一份本地库，调参数前先查这个小区的历史参数配置，防止重复调同一个方向造成过调。

4. 负荷均衡算法调整：两大机型的触发模式与落地参数

4.1 中兴和华为的均衡触发逻辑差异

这部分是整个优化手段里最体现技术含量的一块。文档明确了中兴和华为在负荷均衡上的触发依据完全不同：中兴机型以 PRB 利用率为条件，当小区 PRB 利用率到 70%，且邻区 PRB 利用率低于 65% 时启动；华为机型以用户数为条件，当小区用户数到 40 且邻区用户数低于 20 时启动。这两种触发机制的差异，意味着如果你用同一套参数思路去操作两家设备，一定会出问题。

中兴系的负荷均衡执行门限、邻区过负荷门限、候选目标小区判断门限都是围绕 PRB 利用率。适用的场景是同覆盖双载波小区，F+D 共站址。华为系则围绕用户数设置触发门限和偏置。

4.2 华为与中兴的参数对照表

文档里给了两张参数表，我提炼成下面的核心字段：

注意华为的 -99 和 -95 两个门限，一个是用于负载均衡触发的 A4 门限，一个是用于覆盖切换的 A4 门限。文档推荐值 -99 比 -95 更严苛，也就是说负载均衡触发的信号质量要求更高，避免把用户赶到信号太差的地方。案例 8.3 里给的是一个路口覆盖的 F+D 共址站，负荷均衡开关从 Close 调到 2，中兴系上行执行门限从 65 调到 30，邻区过负荷门限从 60 调到 25，之后忙时 PRB 利用率降到 50% 以下，RRC 连接用户从平均 54 降到 37。

4.3 负荷均衡开关的两种模式的取舍

中南区厂商的做法一般是开始阶段先不开盲切换，先把基于事件测量的方式打开，让 UE 在满足 A4 测量条件时才切到邻区，这样至少保证目标小区的信号质量是够的。盲切换模式虽然可以快速把用户导过去，但对目标小区的覆盖质量完全不设防，容易批量制造掉线。案例里的调整是把开关从 0 调到 2，2 对应基于事件测量的切换方式，说明这里没有选择盲切换，常规项目我也更建议这么做。还有告警上的注意点：开了负荷均衡后，同站邻区的 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 连接平均数、上行吞吐量、下行吞吐量。对每个小区，先取系统忙时数据，然后按以下顺序做组合判定。

判读的顺序有个小技巧：先看吞吐量。如果下行吞吐量已经超过 5GB，说明这个小区真的在承载大流量，用户感知是有的，这时再看 PRB 利用率。如果 PRB 利用率也高、用户数也高，那就是资源不足，扩容逻辑成立；如果 PRB 利用率高但吞吐量低，那就是典型的“有流量但效率低”，先查 MCS 分布和 CQI，再查干扰。如果吞吐量小于 1GB，说明小区本身没什么数据压力，这时候 PRB 利用率高只有一个解释：控制信道开销大或者用户都在做小包业务，这种场景开负荷均衡比扩容管用。

我一直要求自己每次处理完一个高负荷小区，都把判读结果和最终动作回填到一张跟踪表里，持续观察两周。两周后如果指标稳定，才算这个小区闭环；如果指标反弹，回查判读过程，往往能发现当初有个指标被忽视。从那以后，我每次拿到高负荷小区清单，都强制自己先走一遍这张图，不管时间多紧都先判场景再谈方案，希望帮到你。

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