简介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利用率忙时均值50%峰值70%是否存在连续整小时高占资源类PDCCH CCE利用率50%小包多、控制信道挤压时容易漏看用户类RRC连接用户数忙时峰值200大量无线路由器终端在线时这个值很高用户类激活业务用户数忙时峰值30真正参与PDSCH/PUSCH调度的用户效率类平均下行MCS15资源被低阶调制大量占用效率类上行IoT噪声抬升大于-110dBm干扰受限加CA效果会打折扣注意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, ascendingFalse).to_string())这段脚本的关键在于第三个过滤条件avg_mcs 15或avg_iot -110。前者表示小区里大多数用户在低速率档位做业务后者表示上行已经出现明显干扰抬升。这类小区即使PRB利用率只有50%用户感知也往往很差是参数优化和RF优化最容易见效的对象。avg_dl_prb的取值单位是百分数0到100ul_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, howleft).fillna(0) target result[result[over_70_hours] 2]over_70_hours表达的是“超阈值小时数”而不是峰值点。持续2小时以上才有优化价值单小时超阈值先查告警、故障切换和周边站点状态。这里的“2小时”是我常用的下限如果你所在网格白天、晚忙时是两个独立业务高峰也可以改成“一天内至少两个不同时段触发”避免把早忙时和晚忙时当作同一波持续负荷。3. 参数侧的高负荷小区优化MLB、调度器与功率参数的调整顺序参数侧的高负荷小区优化有个铁律先做负载均衡再做调度权重最后动功率。顺序不能反。一上来就调功率虽然能缩小小区覆盖、降低远处用户进入的频率但一旦下倾角或者RS功率压太狠边缘用户MCS继续恶化反而加重PRB占用。所以我会先让话务在邻区间“流起来”再看还剩下多少硬占资源。3.1 负载均衡参数怎么调从切换门限到MLB偏移MLBMobile Load Balancing是高负荷小区优化里见效最快的一类参数。它的核心逻辑是当本小区PRB利用率高于设定门限时通过调低本小区对邻区的切换偏置把边缘用户“推”到低负荷邻区去。这里有个关键认知MLB只能搬走边缘可切换的用户搬不走小区中心的刚性业务。如果把门槛设得太低你会看到切换请求暴增但PRB利用率只降两三个点。下面这个MML风格模板用来表达参数口径实际落地以你设备商的命令行手册为准MOD CELLMLB: LocalCellId101, MlbSwitchUL_DL_PRB, TriggerThreshold50, OffsetStep2, MaxOffset6; MOD CELLHOPARA: LocalCellId101, HoEventA5, A5Threshold1-105, A5Threshold2-110; MOD CELLID: LocalCellId101, CellIndividualOffset0;参数说明MlbSwitchUL_DL_PRB表示以上下行PRB利用率作为负载测量量TriggerThreshold50是触发MLB的PRB利用率门限高于50%启动负载均衡OffsetStep2是每次调整的功率/偏置步长MaxOffset6限制了最大小区偏置防止把用户推到覆盖不可用的邻区。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: LocalCellId101, RSPower152, MaxTransmitPower480; MOD CELLULPC: LocalCellId101, P0NominalPUSCH-80;上面的参数中RSPower152指的是参考信号功率按0.1dBm粒度量化后的值MaxTransmitPower480对应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频段尽量避免Band3Band3的同频叠加载波。不同LTE Band组合的覆盖半径不同Band1在低频段覆盖好Band3或Band40高频段容量大高低频搭配才是高负荷小区优化里容量和覆盖兼顾的做法。异频组网下同样可以叠加MLB把异频测量触发门限调低让用户更容易在忙时到空闲频段上去。4.3 邻区关系和切换参数复核防止把负荷搬进死角工程手段上完后指标有时候会出现“本小区下来了邻区上去了”的假性优化。检验是否真的优化关键看邻区切换成功率和高负荷转移目标是否合理。我会拉一份两两邻区对的小时级切换统计筛出异常对# ho_pair.csv列顺序: 源小区,目标小区,切换次数,切换成功率 awk -F, NR1 $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, NR1 {printf %s %s PRB:%.1f%% THP:%.1fMbps\n, $1, $2, $3-$4, $5-$6} before_after.csv如果看到PRB下降但吞吐量也下降要回去看是不是把“边缘可迁移用户”迁走了还是把覆盖压出了死角导致远端用户链路质量变差如果PRB下降不多但吞吐量上升说明调度和扩载波的方向有效如果切换成功率下降超过0.5%优先回退CIO和MLB再看功率参数。最后一个容易被忽视的动作是验证至少覆盖两个完整忙时周期尤其要包含周末。很多高负荷小区忙时模型只在周中成立周末数据不落下去周一重启优化就找不到基线了。本文还有配套的精品资源点击获取