企业官网建设流程全解析

简介：LTE容量优化高负荷小区优化指导书.docx 是一份面向通信网络优化工程师的实操型文档，针对4G LTE热点区域高负荷问题，系统讲解高负荷小区定义、筛选标准、处理流程与扩容原则，涵盖覆盖优化、参数优化、功能算法调整及小区分裂、载频扩容、新建站扩容等方案，并给出参考信号调整、重选优先级调整、负荷均衡等典型优化案例，适合从事LTE/5G网络优化与通信工程建设的人员学习使用。文件包仅含1个docx文档，大小258KB，目录结构清晰，按背景、高负荷定义、指标筛选、处理流程、参数优化原则、扩容原则、场景分类及优化案例等章节组织，便于按需查阅。资源已有159人学习浏览，能够帮助读者快速建立高负荷小区优化的完整方法论，掌握从指标监控、问题定位到参数调整与扩容落地的闭环思路。

1. 先别急着扩容：LTE容量优化高负荷小区优化从“要不要动参数”开始

很多LTE外场测试报告里，一出现“高负荷小区”，第一反应都是“扩带宽、加CA、上双载波”。真正把LTE容量优化高负荷小区优化做过一轮的人会告诉你，高负荷和拥塞之间不能画等号。我处理过的小区里，有一大半是“资源很忙、效率不高”的假高负荷：覆盖过远导致边缘用户用低MCS消耗大量PRB，或者大量CPE、无线路由器类型终端持续在线，把RRC连接数撑得很高，但吞吐量很低。如果不对特征做区分就直接开MLB或者调功率，忙时很可能会出现切换失败、VoLTE回落，指标更难看。这篇按“筛选口径—参数调整—工程协同—效果验证”的顺序来写，把能直接复用的判断逻辑和操作步骤拆开。适合网优、规划、KPI监控工程师，也适合做自动化优化系统的人参考。

2. LTE容量优化的第一步：高负荷小区筛选口径与特征提取

高负荷小区优化最容易被带偏的环节不是调参，而是第一步的“筛选口径”。只看单个PRB利用率峰值，会把很多潮汐小区、邻区故障吸收话务的小区误判成高负荷，导致后续优化方向完全错误。所以我一般把筛选拆成三个维度：资源占用、用户规模、频谱效率。三者同时看，才能判断这个小区是纯粹容量不足，还是“资源被低效吃掉”。

2.1 高负荷小区的三套判断指标：资源、用户和频谱效率

资源类指标回答“空口忙不忙”，用户类指标回答“多少人挤在上面”，效率类指标回答“忙成这样到底出了多少量”。以LTE FDD常见配置为例，我常用的起始阈值如下，实际落地按全网分布做分位值修正更稳：

注意，PRB利用率高不代表拥塞。如果RRC用户数高但激活用户数低，说明大量终端只是在线保活，对容量影响有限。如果PRB和CCE都高、MCS也高，那才是真正的“资源刚性需求”，参数优化空间很小，应当直接考虑扩容。最需要优化的，是PRB高、MCS低、IoT高的组合，这种高负荷是“可逆的”。

2.2 从MR和计数器提取高负荷小区特征：一份可复用的筛选脚本

日常KPI监控里，我不会只看网管界面的实时曲线，而是把小区级小时粒度指标拉下来，用脚本做批量筛。下面这份Python脚本按“忙时+均值+峰值+效率”四个条件过滤，适合直接接在从北向接口导出的CSV后面：

import pandas as pd # 每条记录是小区每小时的聚合KPI df = pd.read_csv("lte_cell_kpis.csv", parse_dates=["time"]) df["hour"] = df["time"].dt.hour # 先限定忙时窗口，避免全天均值把峰值稀释掉 busy = df[(df["hour"] >= 11) & (df["hour"] <= 13)] # 按小区聚合忙时特征 attr = busy.groupby("cell_id").agg( avg_dl_prb=("dl_prb_util", "mean"), peak_dl_prb=("dl_prb_util", "max"), peak_rrc=("rrc_users", "max"), avg_mcs=("dl_mcs", "mean"), avg_iot=("ul_interference", "mean") ) # 第一步：资源高占且未到绝对拥塞 candidate = attr[(attr["avg_dl_prb"] > 50) & (attr["avg_dl_prb"] < 80)] # 第二步：用户数确实高 candidate = candidate[candidate["peak_rrc"] > 200] # 第三步：区分效率型还是资源型 efficiency_low = candidate[ (candidate["avg_mcs"] < 15) | (candidate["avg_iot"] > -110) ] print(efficiency_low.sort_values("avg_dl_prb", ascending=False).to_string())

这段脚本的关键在于第三个过滤条件：avg_mcs < 15或avg_iot > -110。前者表示小区里大多数用户在低速率档位做业务，后者表示上行已经出现明显干扰抬升。这类小区即使PRB利用率只有50%，用户感知也往往很差，是参数优化和RF优化最容易见效的对象。avg_dl_prb的取值单位是百分数，0到100；ul_interference单位是dBm，-110意味着接近抬升门限，低于-120才算干净。

如果筛出来的小区avg_dl_prb高、MCS也高，说明终端信道质量不差，纯粹是高需求。这种小区不需要调MLB，直接把目标放到载波聚合或新增载波上，省得把切换参数调乱。

2.3 单点峰值说明不了问题：用持续时长把“忙时”定义出来

高负荷小区优化里另一个常见误判，是把某一小时突发的PRB峰值当成持续高负荷。比如某小区前一天因为邻区故障吸收了对方话务，当天晚忙时PRB到了80%，第二天恢复正常。这种情况如果直接进优化清单，会白白消耗RF和参数修改资源。

我会用“连续超阈值小时数”做二次确认：

# 统计各小区一天内PRB利用率超过70%且持续超过1小时的时段数 over_hour = (df[df["dl_prb_util"] > 70] .groupby("cell_id")["time"] .count() .rename("over_70_hours")) result = attr.join(over_hour, how="left").fillna(0) target = result[result["over_70_hours"] >= 2]

over_70_hours表达的是“超阈值小时数”而不是峰值点。持续2小时以上才有优化价值，单小时超阈值先查告警、故障切换和周边站点状态。这里的“2小时”是我常用的下限，如果你所在网格白天、晚忙时是两个独立业务高峰，也可以改成“一天内至少两个不同时段触发”，避免把早忙时和晚忙时当作同一波持续负荷。

3. 参数侧的高负荷小区优化：MLB、调度器与功率参数的调整顺序

参数侧的高负荷小区优化有个铁律：先做负载均衡，再做调度权重，最后动功率。顺序不能反。一上来就调功率，虽然能缩小小区覆盖、降低远处用户进入的频率，但一旦下倾角或者RS功率压太狠，边缘用户MCS继续恶化，反而加重PRB占用。所以我会先让话务在邻区间“流起来”，再看还剩下多少硬占资源。

3.1 负载均衡参数怎么调：从切换门限到MLB偏移

MLB（Mobile Load Balancing）是高负荷小区优化里见效最快的一类参数。它的核心逻辑是：当本小区PRB利用率高于设定门限时，通过调低本小区对邻区的切换偏置，把边缘用户“推”到低负荷邻区去。这里有个关键认知：MLB只能搬走边缘可切换的用户，搬不走小区中心的刚性业务。如果把门槛设得太低，你会看到切换请求暴增，但PRB利用率只降两三个点。

下面这个MML风格模板用来表达参数口径，实际落地以你设备商的命令行手册为准：

MOD CELLMLB: LocalCellId=101, MlbSwitch=UL_DL_PRB, TriggerThreshold=50, OffsetStep=2, MaxOffset=6; MOD CELLHOPARA: LocalCellId=101, HoEvent=A5, A5Threshold1=-105, A5Threshold2=-110; MOD CELLID: LocalCellId=101, CellIndividualOffset=0;

参数说明：MlbSwitch=UL_DL_PRB表示以上下行PRB利用率作为负载测量量；TriggerThreshold=50是触发MLB的PRB利用率门限，高于50%启动负载均衡；OffsetStep=2是每次调整的功率/偏置步长；MaxOffset=6限制了最大小区偏置，防止把用户推到覆盖不可用的邻区。A5事件里的两个阈值分别代表“服务小区低于-105dBm且邻区高于-110dBm”，这种双条件比A3更适合做负荷均衡，能够限制边缘用户迁移范围。

调整MLB后，必须在下一小时看两个反向指标：切换成功率是否下降，邻区PRB是否被拉高。如果邻区PRB也到了60%以上，说明这个“低负荷邻区”并不低，需要把该邻区的MLB排除关系加上，不能让它继续接收转移话务。

3.2 调度器与资源分配参数：QCI权重和最小保证速率

负载均衡做完后，PRB还是高，接下来该优化调度器。LTE调度器的本质是“决定谁在哪个子帧用哪个PRB”。不同厂商调度算法不同，但核心可调参数通常包括：调度模式（比例公平PF、最大C/I、轮询RR）、各QCI的调度权重、GBR承载的最低保证速率。

我一般建议把调度模式保持在比例公平（PF），不要为了提升单用户速率改成最大C/I，否则会严重牺牲边缘用户。高负荷场景下真正需要调的是QCI权重。比如QCI9承载的是普通上网业务，如果某个小区里视频大包流量占比高，适当提高QCI9的调度权重，可以避免视频业务和VoLTE抢资源。反过来，如果RRC连接用户数很高但大多数是低频小包，则要把小包业务的调度优先级降一点，防止信令和小包把CCE占满。

用文字描述就是：网管侧把某个QCI的调度权重从默认值调整到目标值后，观察“该QCI承载的速率是否上升、其他QCI是否受损”。如果发现VoLTE下行丢包率上升，说明权重调整过度，回退一半再观察。不要在一天内同时改权重和MLB，否则无法定位是哪个参数产生了副作用。

3.3 功率参数：降低“无效覆盖”来换容量

高负荷小区优化里的“功率”，指的是小区最大发射功率、RS参考信号功率和上行P0标称值。最常见的场景是：小区覆盖过远，周边两三个站的边缘用户都驻留到这个小区，PRB被低MCS占用。这时候调MLB无效，因为这些用户没有合适的低负荷邻区可迁移，正确做法是先压覆盖。

压覆盖的优先级我习惯这样定：先查天线电子下倾角是否已到机械角上限，如果倾角没空间，再调低RS功率。RS功率降1dB，覆盖半径大约缩小百分之几，但不要指望线性。每一次降功率都要求工参和扫频数据支持，防止在某个方向打出覆盖弱区。上行IoT偏高的场景，需要配合调整P0标称值，降低边缘用户的发射功率，但要注意这会在一定程度上下调边缘速率。

MOD CELLPOWER: LocalCellId=101, RSPower=152, MaxTransmitPower=480; MOD CELLULPC: LocalCellId=101, P0NominalPUSCH=-80;

上面的参数中，RSPower=152指的是参考信号功率按0.1dBm粒度量化后的值，MaxTransmitPower=480对应48dBm（约64W）小区最大发射功率；P0NominalPUSCH=-80是上行信道的标称接收功率，调低后会抬升用户发射功率，需要谨慎。这套组合更适合“覆盖过远但硬件正常”的小区，调完后要扫一遍道路测试，确认没有深弱区被新造出来。

提示：功率参数优化必须纳入变更管理。每次只动一个功率参数，保留改动前后两天的调用级指标和MR数据，否则割接后出现投诉无法回溯。

4. 高负荷小区优化的组合拳：从RF覆盖调整到CA裂频

当参数调整已经把能搬的话务都搬完、能压的覆盖都压到位，PRB利用率依然在50%以上，就要进入工程与策略协同的阶段。这个阶段不是“参数不行就扩容”的二选一，而是把RF调整、载波聚合、异频组网和邻区关系放在一张图上统筹看。

4.1 覆盖与容量互换：下倾角、方位角和RS功率的现场顺序

现场高负荷小区中，有相当一部分是“越区覆盖”造成的。天线挂高过高、下倾角不足、前方有水面或高楼反射，都会让某一个小区的覆盖面积超出它本应负责的范围。覆盖大意味着用户多，用户多意味着PRB占用高，但真正令人头疼的是：这些远端用户MCS很低，一个用户消耗的资源顶得上近处用户好几个。

我一般按“工参核查—邻区测量报告（MR）分析—RF调整”的顺序处理。先用MR数据找出本小区和邻小区的过度重叠区域，再看小区每根天线的方位角和电子倾角。如果是定向小区过覆盖，优先把电子下倾角压2度，不行再调机械下倾角；如果是全向站，优先考虑换电子下倾角更大、波束更窄的天线型号。RF调整的颗粒度不是“小区”，而是“扇区”。同一个小区不同扇区覆盖环境差别很大，不要整个小区统一调。

RF调整后的验证不能只看PRB。还要看本小区MR里的TA（时间提前量）分布：如果远端TA占比下降，近段用户占比上升，说明覆盖收缩有效；如果总用户数没减少但平均下行MCS抬升了3到5个阶数，那才是真正把这个高负荷小区的“无效用户”筛了出去。

4.2 载波聚合与异频组网：高负荷小区优化的LTE Band扩容量策略

在参数和RF都做完之后，如果忙时PRB仍然超过60%，就需要考虑扩容，最常用的两种手段是载波聚合和异频新增小区。载波聚合的思路不是新建物理小区，而是在现网站点上增加一个LTE Band载波作为辅小区（SCell），把业务分流到第二载波上。

但CA不是“开了就涨容量”。我见过不少小区开了CA后，平均吞吐量没有明显提升，原因在于SCell的添加门限设得过高，只有中心用户能聚合，边缘用户依然全部挤在主载波上。常见做法是把SCell添加门限从RSRP低于-110dBm才添加，调整到-100dBm左右，让更多边缘用户能接入辅载波。同时需要确认终端支持率，如果现网只有不到50%的终端支持CA，那CA只是锦上添花，不能当主力扩容手段。

使用LTE Band组合时，我通常会避开同频段的插花干扰。比如Band3作为主载波时，辅载波选Band1频段，尽量避免Band3+Band3的同频叠加载波。不同LTE Band组合的覆盖半径不同，Band1在低频段覆盖好，Band3或Band40高频段容量大，高低频搭配才是高负荷小区优化里容量和覆盖兼顾的做法。异频组网下同样可以叠加MLB，把异频测量触发门限调低，让用户更容易在忙时到空闲频段上去。

4.3 邻区关系和切换参数复核：防止把负荷搬进死角

工程手段上完后，指标有时候会出现“本小区下来了，邻区上去了”的假性优化。检验是否真的优化，关键看邻区切换成功率和高负荷转移目标是否合理。我会拉一份两两邻区对的小时级切换统计，筛出异常对：

# ho_pair.csv列顺序: 源小区,目标小区,切换次数,切换成功率 awk -F',' 'NR>1 && $4 < 95 && $3 > 100 {print $1,$2,$3,$4}' ho_pair.csv | sort -k3 -nr | head

这个命令的意思是：找出切换次数超过100次但成功率低于95%的小区对，按切换次数降序输出。如果这些异常邻区恰好是MLB的主要目标小区，那就说明用户被“推”进了一个射频或者容量状况更差的地方，需要立刻回退对应邻区对的CIO或MLB偏移量。如果异常邻区不是MLB目标，则优先排查覆盖孤立、缺邻区定义和目标小区是否存在故障告警。

5. 验证闭环：用四个指标确认LTE容量优化没有白做

高负荷小区优化不是“改完参数看一次PRB”就结束，我一般用一套固定的验证矩阵来闭环，防止把问题从一个小区的PRB搬到另一个小区的掉线率上。

第一，忙时PRB利用率。看同一忙时时段、同一星期的平均值和峰值变化，避免拿周一对周五、晴雨天不同话务来比。第二，忙时平均吞吐量。这个指标用来确认容量被释放后有没有真正变成用户速率，而不是单纯把用户“请出”小区。第三，切换成功率。只要动过MLB和CIO，这个指标必须进验证清单，尤其关注忙时切换成功率有没有掉0.5个百分点以上。第四，用户感知类指标，包括RRC连接建立成功率、E-RAB掉线率以及VoLTE语音质量。高负荷优化可以损失一点PRB利用率，但不能损失业务连续性。

对比时我用下面的方式，把改造前后两份小时级数据按小区ID和小时对齐，直接算差值：

# before_after.csv列顺序: 小区,小时,改造前PRB,改造后PRB,改造前吞吐,改造后吞吐 awk -F',' 'NR>1 {printf "%s %s PRB:%+.1f%% THP:%+.1fMbps\n", $1, $2, $3-$4, $5-$6}' before_after.csv

如果看到PRB下降但吞吐量也下降，要回去看是不是把“边缘可迁移用户”迁走了，还是把覆盖压出了死角，导致远端用户链路质量变差；如果PRB下降不多但吞吐量上升，说明调度和扩载波的方向有效；如果切换成功率下降超过0.5%，优先回退CIO和MLB，再看功率参数。最后一个容易被忽视的动作是：验证至少覆盖两个完整忙时周期，尤其要包含周末。很多高负荷小区忙时模型只在周中成立，周末数据不落下去，周一重启优化就找不到基线了。

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