简介5G网络优化场景下高负荷小区负载均衡是保障用户体验和频谱效率的关键环节。这份PDF面向移动网络优化工程师、5G运维人员及通信专业学习者系统梳理负载均衡从测量、判决到执行的三阶段流程并以华为设备为例给出小区级负载均衡开关、RSRP门限、触发参数等可落地的配置命令与参数解释。资源以1份PDF形式打包整包约1.37MB全文约5页便于快速查阅与对照实验。已有781人学习下载。文档还包含UE选择策略、候选邻区条件及判决周期处理规则并强调现场参数需结合实际情况调整可帮助读者建立从原理、配置到调优的完整认知框架。1. 5G 高负荷小区负载均衡先分清是无线侧 MLB不是 Nginx 那套凌晨一点KPI 通报群里弹出一条告警某 5G 小区 PRB 利用率 80%持续了快半小时。后台同事的第一反应通常是两个字「开负载均衡」。但用户说「开负载均衡」到底是要在机房里配 Nginx 反向代理加 upstream 权重还是在无线网管上把用户从热小区迁到闲小区这两个东西名字都叫负载均衡骨子里完全不同。这份《5G高负荷小区如何开启负载均衡.pdf》讲的是RAN 侧那套核心是 MLBMobility Load Balancing移动性负载均衡靠 A4/A5 测量事件、CIO 和切换参数驱动把高负荷小区的业务分流给邻区。适合后台网优、集团指标对接以及刚转 5G 想搞懂 MLB 参数的新人。先把定义对齐后面才不会被参数绕晕。2. 高负荷判定与 MLB 原理为什么不能无脑开负载均衡无线侧的负载均衡不是机房里的流量分配器它发生在空口是通过 RRC 层的测量事件和切换流程把用户从一个资源紧张的 5G 小区迁移到资源空闲的邻区。它能在不加硬件的前提下提升整网吞吐但也只是在「真实业务过载」时才值得开。判断错了场景MLB 反而会把网络指标搞得更差。顺带说一个概念差异IT 圈常见的 Nginx、LVS、网卡绑定那类负载均衡管的是连接转发和带宽聚合均衡对象是服务器。无线侧 MLB 的均衡对象是小区下的驻留用户走的流程是空口信令周期在秒级。很多从数据中心转过来的同事第一次接触 MLB容易拿机房那套思维去理解结果对着网管参数表一脸懵。在项目里我一般会先回答三个问题再动参数这个小区是不是真的过载有没有可迁移的邻区迁移之后会不会引发覆盖或干扰问题这三件事分别对应 PRB 利用率、邻区关系和 MR 覆盖必须逐项过一遍。2.1 高负荷判定PRB 利用率、用户数与 CQI 三个维度高负荷小区不是凭一张话统截图拍板的通常我会用三个口径互相印证。第一个是 PRB 平均利用率。它统计的是调度器实际占用的物理资源块占可用资源块的比例一条数据通常按 15 分钟取平均。无线侧看负荷就看它因为它直接反映空口资源是否被占满。常见口径是连续 15 分钟平均 PRB 利用率超过 50% 就进入重点盯防超过 30% 算预警。如果只看峰值利用率的瞬间值一个 5G 大包业务就能把单帧利用率打满但这不是持续拥塞。注意 PRB 利用率和峰值速率计算是两个口径峰值速率算的是理想空口的极限能力利用率算的是资源被实际调度占用的比例别把网管里这两个指标混在一起分析。第二个是用户数。具体看 RRC 连接用户数和激活用户数。RRC 连接用户数是 UE 在小区建立连接的数量但里面包含大量没有业务流量的「挂机」用户激活用户数是指正在有上下行业务调度的用户这个数更接近真实负荷。后台指标里两个都要拉判据常见是「RRC 连接用户数连续 15 分钟超过 200 且激活用户数超过 20」。不同设备厂商对 RRC 用户上限的设定不一样具体超没超要看设备的用户面能力表。第三个是 CQI也就是信道质量指示。这个维度最容易漏。弱覆盖小区因为信道质量差MCS 选阶低为了维持速率得多占 PRB于是 PRB 利用率虚高。如果 CQI 06 占比明显偏高说明是信道质量差导致的「被动高负荷」此时开 MLB 把用户迁到覆盖更差的邻区只会换一种方式掉线。我一般会加看 MR 覆盖率确认源小区覆盖无大问题后再走下一步。三个维度都对齐后整理成一张判定表方便每次汇报口径一致判定维度常用指标常见门限口径作用空口资源下行 PRB 平均利用率预警 30%重点 50%连续 15 分钟判断空口资源是否过载用户承载RRC 连接用户数 / 激活用户数RRC 用户数 200激活用户数按设备能力判断接入和调度压力信道质量CQI 06 占比 / MR 覆盖率CQI 差值占比、MR 覆盖率排除弱覆盖引起的虚高负荷时间粒度也要选对。15 分钟粒度适合盯忙时小时级粒度适合写周报。只取忙时 8 小时的均值会漏掉瞬时拥塞只取单条 15 分钟峰值又会被边缘毛刺干扰。我习惯的做法是先按 15 分钟粒度筛出连续 4 条以上超门限的小区再回看这 4 条对应的激活用户数和 CQI三个维度一起进判定清单。有些同事只看 PRB 利用率就冲上去改参数结果改完 MLB 后切换成功率掉了两三个百分点回头查才发现那小区本来就在弱覆盖边缘负荷是被低 MCS 顶上去的。这个误用我在现场见过太多次所以每次判定时都把「先排除覆盖」写在第一步。2.2 MLB 触发原理A4/A5 事件、CIO 与 TTT 的配合明确高负荷后再谈 MLB 怎么干活。无线侧负载均衡的核心想法很简单一个小区吃不下就把一部分用户「推」到周围负荷低的小区去。推的动作不是核心网调度而是 RRC 层的测量控制和切换流程所以它天然依赖测量事件、邻区关系和切换参数。5G 里常用的测量事件是 A4 和 A5。A4 事件描述的是「邻区质量高于一个绝对门限」比如邻区 RSRP 高于 -100 dBm 就上报A5 事件是「服务小区质量低于门限 1 且邻区质量高于门限 2」的双条件事件。MLB 场景里我习惯先配 A4 作为测量开关让用户开始评估邻区信号再用 A5 或 A4 结合 CIO 做切换判决。这两类事件在任何厂商网管里都能见到逻辑一致参数名略有差异。这背后的测量流程其实就是 5G 协议栈里 RRC 层的一部分懂协议栈的人看这些事件会很快对上号。真正影响均衡效果的是三个参数。CIOCell Individual Offset小区个体偏移直接给目标小区的测量结果「加分」把切换边界往外推CIO 每加 13 dB边缘用户就更倾向切过去TTTTime to Trigger触发延时时长控制事件上报后要稳定多久才触发切换TTT 调大能抑制乒乓迟滞Hysteresis给事件加回差带避免信号在门限附近抖动反复进出。三个参数的配合逻辑是CIO 控制迁移量TTT 和迟滞控制迁移稳定性。常见参数这样起步再现场调整参数作用建议起步值调整步长MLB 开关总开关控制是否允许负荷均衡切换ON—A4 门限异频邻区测量启动门限-105-100 dBm2 dBCIO目标小区个体偏移03 dB12 dBTTT触发延时时长320 ms160 ms迟滞事件回差2 dB1 dB为什么不建议一上来就开大因为 MLB 的「均衡」是靠打破小区边界实现的。CIO 给得太高等于把更多本由源小区服务的边缘用户推向目标小区目标小区负荷立刻上来源小区回落随后目标小区又变成热小区来回折腾。更麻烦的是同频邻区之间如果 CIO 调得过大信号本就差不多用户会在两个小区间反复切换全网切换次数翻倍用户感知却更差。还有一点容易被忽略MLB 和常规基于覆盖的切换共用一套移动性参数。如果目标小区只是负荷低但覆盖不占优常规切换判决根本不会把用户分过去。所以有些同事发现 CIO 加了没效果其实是目标小区在边界处始终不满足 A4/A5 条件。这时候先做覆盖差异化再谈负荷均衡。移动性管理本来就是 5G 关键技术里最影响用户感知的一环MLB 只是把传统切换策略多接了一个负荷维度。3. 开启负载均衡的实操流程参数配置与邻区校验判定完毕、原理对齐进入改参数。这一步我跟所有同事的建议一样先截图保存现网参数再一步步来。MLB 涉及的是移动性参数改错一个键值对影响的是整片区域用户的切换行为没有后悔药就麻烦了。3.1 网管参数配置MLB 开关、A4 门限与 CIO 建议值不同厂商的网管入口不同但通常在小区级移动性管理或负载均衡菜单下能找到「负荷均衡开关」「MLB 模式」「同频/异频 MLB 使能」这类参数。华为、中兴、爱立信三代网管的命名差异不小按下面的逻辑路径找进入小区配置打开负载均衡功能开关确认支持异频 MLB配置 A4 事件门限先给 -105 dBm 起测给目标邻区配置 CIO建议 2 dB 起步核对 TTT 和迟滞维持 320 ms 和 2 dB保存并激活增量包确认命令下发成功。这几步各有用途。MLB 开关是总闸不开它下面配的全白费A4 门限决定用户什么时候开始评估邻区门限太低会漏掉本该迁移的用户门限太高则所有边缘用户都触发上报CIO 决定迁移力度直接关系目标小区会不会被「填满」TTT 和迟滞是防抖的边缘信号一波动就会反复上下报设置小了切换次数直接爆炸。我在现场一般先用一个小脚本记录当前关键参数的取值改完有争议时能快速回看基线。写成一个自用记录模板大概是这样params { mlb_switch: ON, a4_threshold_dbm: -105, cio_db: 2, ttt_ms: 320, hysteresis_db: 2, lb_user_limit: 200, neighbor_cell: 501-603-1 } for key, value in params.items(): print(f{key} {value})这段脚本的作用不是自动改网管而是把当前改动基线落到文件里。回头话统异常先对照这批参数排查是不是自己改出来的。参数 dict 里的每一项都能直接对应网管表单a4_threshold_dbm 是 A4 门限cio_db 是邻区偏移ttt_ms 是触发延时时长hysteresis_db 是迟滞lb_user_limit 是激活用户数门限。这些参数要按小区场景分开记录别把商业区和高铁站用同一套。注意参数改完后一定要看网管返回的下发结果。增量包下发成功不等于参数已生效部分厂商还有等待下一个统计周期才生效的逻辑。改完 1015 分钟后再查一遍实际生效的参数值。3.2 目标小区筛选邻区关系、MR 覆盖与同频干扰三重校验参数只是手段迁移目标小区才是胜负手。一个高负荷小区往往不止一个邻区但并不是每个邻区都适合接用户。我会按三步筛选。第一步核查邻区关系。在网管里看小区级邻区列表确认目标邻区存在且外部小区定义完整如果邻区遗漏用户想迁也迁不过去。第二步取 MR 覆盖数据检查服务小区和目标邻区是否有足够的重叠覆盖区域。重叠覆盖地带才是真正能通过切换迁移用户的区域如果两个小区是孤岛式覆盖切换请求会因信号达不到门限而失败。第三步看目标小区的现网负荷和干扰。目标小区自己都快 50% 了迁移过去只会让第二个小区进高负荷清单对同频邻区还要额外关注 SSB 频点重叠情况同频重叠覆盖区域过大时负载均衡会导致干扰抬升、MCS 下跌指标两边都难看。邻区关系这一步最常见的坑是 ANR 自动加出来的同频邻区。ANR 本意是自动补邻区但它补出来的邻区不一定适合做 MLB 迁移目标。我会在开 MLB 前把自动加邻区的策略收紧必要时关闭异频 ANR改成人工按规划表核查。自动补的邻区做常规切换够用做负荷均衡就可能给你「盲迁」。这三步落成一张校验表给后台同事核对用校验项校验方法异常处理邻区关系网管邻区列表、外部小区定义补齐邻区和外部小区收紧 ANR 策略重叠覆盖MR 数据看两小区采样点分布没有重叠区域则放弃该目标小区目标小区负荷目标小区 PRB 利用率和用户数目标负荷过高时换候选小区干扰风险同频邻区关系、SSB 频点重叠情况异频优先或降低 CIO选好目标小区后再回到上一节的参数表只针对这一个目标邻区配 CIO而不是把所有邻区都统一加偏移。局部的负载均衡从来都是「点对点」的优化不是「一把梭」对全网调。4. 负载均衡排查避坑乒乓切换、掉线与参数不生效MLB 上线后问题通常在三个时间点出现改完半小时内的即时异常多半是参数生效问题当晚忙时的话统异常多半是乒乓切换三天后的 KPI 周报异常基本跑不掉干扰或掉线。排查时先按时间轴定位是哪一类再动手。4.1 乒乓切换与掉线率上升两个最常见的调整过度先说调整过度造成的两类问题它们都直接和 CIO、TTT 的取值有关。踩坑一切换次数暴增负荷没降。现象开启 MLB 后小区间切换请求次数翻了将近一倍但源小区 PRB 利用率纹丝不动目标小区负荷反而跟着涨。 原因CIO 加太大A4 门限又放得太低边缘信号波动 3 dB 的用户反复触发迁移形成乒乓切换。每次切换都伴随测量重配和随机接入资源照样被消耗等于白切了。 解决把 CIO 降到 12 dBTTT 从 160 ms 调回 320 ms迟滞维持 2 dB 起步再观察两小时话统如果切换次数仍在高位进一步把 A4 门限收紧到 -100 dBm。调整原则是一次只动一个参数等两个统计周期再评估。踩坑二掉线率上升无线链路失败变多。现象目标小区掉线率涨了 0.3 个百分点以上用户投诉「一切过去就没网」。 原因目标小区覆盖有空洞或者源小区迁移过去的方向根本没有重叠覆盖。切换时的 RACH 冲突和重配失败都可能在切换点爆发。 解决把 MR 覆盖图拉出来凡是目标小区在迁移边缘覆盖差的一律移出候选同时核查目标小区的随机接入资源是否充足。这个问题的根因经常不在参数而在选区参数怎么回退都没用换目标小区才是正解。4.2 参数不生效与同频干扰检查顺序决定翻车概率参数没生效和同频干扰是另外两类问题它们的坑点不在参数本身而在检查顺序。踩坑三参数改完话统里一条负载均衡切换都没有。现象MLB 开关已开、CIO 已配但统计周期内零迁移高负荷依旧。 原因一是增量包没有真正激活网管显示下发成功但现网实际未生效二是异频测量对象没配上A4 事件没有可测的邻区频点事件根本触发不了三是 A4 门限设得比目标小区实际 RSRP 还高条件永远不成立。 解决先查开关生效状态再看异频测量配置和频点优先级最后核对 A4 门限是否高于目标小区 RSRP。检查顺序按「开关 → 测量对象 → 门限 → CIO」走不要一上来就怀疑 CIO。踩坑四同频邻区之间开了 MLBSINR 和 MCS 双双下跌。现象源小区和目标小区负荷都降了但平均 SINR 掉了几个 dB用户速率反而更差。 原因同频同覆盖的小区之间开 MLB迁移过去后信号来源并未改变反而在重叠覆盖区引入更多同频干扰MCS 选阶被拉低。这不是切换问题是无线环境问题。 解决高负荷小区优先选择异频邻区作为迁移目标如果整网只有一个频点那迁移对象只能选重叠覆盖小的同频邻区CIO 必须压低。回退 CIO 或直接在同频邻区上关闭负载均衡功能效果立竿见影。这四类问题互有牵连乒乓切换和掉线率上升经常同时出现参数不生效和同频干扰又会在排查阶段互相误导。我在排查时会先把参数基线截图拿出来对比再决定动哪个旋钮。特别注意不要一发现问题就关 MLB。很多同事在掉线率一升时直接关总闸结果高负荷回来了问题没根治。正确做法是先定位掉线发生在哪个切换对回退那一个邻区的 CIO保留其他方向的负载均衡。5. 效果验证与参数微调盯三天话统不如画一张趋势图开调之后验证不是看某一小时的指标而是看一条趋势线。我通常以调整时刻为分界点取前后各 24 小时的小区级话统对比四个指标PRB 平均利用率、切换成功率、掉线率、平均用户速率。判定标准很直白源小区 PRB 利用率明显回落且波动收敛目标小区利用率升温但不超过源小区原值全网掉线率不上升。三个条件同时成立MLB 就是成功的如果源小区降了但目标小区飙了那是迁移量过大把 CIO 或均衡权重往回缩一档。对比话统我用一个随手写的 Python 脚本两段 CSV 一读就输出结论import csv def load_kpi(path): with open(path) as f: rows list(csv.DictReader(f)) prb sum(float(r[prb_util]) for r in rows) / len(rows) rrc max(float(r[rrc_users]) for r in rows) return prb, rrc before load_kpi(before_mlb.csv) after load_kpi(after_mlb.csv) print(fPRB 利用率: {before[0]:.1f}% - {after[0]:.1f}%) print(fRRC 用户峰值: {before[1]:.0f} - {after[1]:.0f})脚本只做两件事读 CSV 求 PRB 平均利用率、取 RRC 用户峰值然后打印。数据列名是 prb_util 和 rrc_users如果你网管导出的列名不一样改 DictReader 对应的字段名就行。前后两份文件放在同一目录方便保留历次记录下次同类小区可以直接复用同一套脚本。趋势确认稳定后微调阶段遵循「一次只动一个参数」的铁律。今天只调 CIO明天再看同期话统TTT 和迟滞不要同一天同时改否则出了问题分不清是谁引起的。参数收敛后把最终配置快照和起调前快照一起归档作为该场景的参数模板。从那以后我每次做 5G 负载均衡都强制走一遍「判负荷 → 查邻区 → 调参数 → 盯趋势」四步再也不会跳过邻区校验直接去加 CIO——那是我交过的学费里最贵的一笔。希望帮到你。本文还有配套的精品资源点击获取
