简介移动性负载均衡MLB配置方案文档聚焦5G/LTE网络中小区的容量均衡问题是面向网络优化工程师、基站督导及后台参数配置人员的专项技术资料适用于日常优化、扩容评估和容量均衡专项等场景。文档以华为BTS3900 LTE设备为实例针对部分小区用户数或PRB利用率接近容量极限、而周边小区资源空闲的场景系统梳理MLB的实现机制先通过MlbAlgoSwitch等开关识别候选邻区并交互负载信息再确定目标小区列表最后按同步态或空闲态用户分别采用切换或RRC connection release方式完成负载转移同时明确了候选邻区确定、负载信息交互、目标小区选择等关键配置原则。资源为单个docx文件压缩包大小1.21MB共1个文档正文含背景描述、方案分析、实施步骤和配置建议等完整章节。方案实施部分特别对比了异频同步态用户数均衡在转移同步态用户、转移空闲态用户两种场景以及异频空闲态UE预均衡共三种方式的优缺点并给出A4事件测量、IMMCI信元下发、重选优先级调整等可操作细节。已有119人学习下载适合需要掌握MLB参数配置思路并指导现网落地的5G优化人员。1. 当 5G 基站越密MLB 就不再是“可选功能”城市商圈晚高峰的时候两个相邻 5G 基站的小区负载经常一个冲到 80%另一个还在 20% 附近。人工去调切换参数能做但要等到凌晨操作、白天观察改一组邻区往往要两三天。移动性负载均衡MLBMobility Load Balancing解决的问题就是这个网管周期统计小区负载发现邻区间负载差超过门限后自动调整切换或重选参数把用户从忙小区引导到空闲小区整个过程不需要载波扩容。这篇按网络优化里最常见的落地路径来讲先看负载怎么量再拆 MLB 的开关、门限和偏置参数然后给出现网实施与排障的具体方法。适合日常做参数优化和开站入网的工程师也适合在 5G 全网排障时顺手把 MLB 一起查了的人。2. 负载均衡前要先回答的问题用哪条指标判断“哪个小区更忙”MLB 的“负载”在现网统计里不是一个数。直接用某个指标可能会误判有的小区 RRC 连接用户很多但基本都是挂在网上的即时通信流量PRB 占用并不高有的小区用户不多却在下大文件PRB 接近打满。给 MLB 配负载门限之前先要把统计口径想清楚。2.1 PRB 利用率和 RRC 连接数两个口径各盯什么从 PM 统计角度看最常用的四个量是下行 PRB 利用率、上行 PRB 利用率、RRC 平均连接数、CCE 利用率。它们反映的资源维度不同适合的业务场景也不同。指标反映内容建议使用场景下行 PRB 利用率下行物理资源块占用程度视频、下载等大包业务为主的区域上行 PRB 利用率上行调度与干扰情况直播、文件上传类业务RRC 平均连接数接入用户数和在线时长即时通信、低速率驻留用户CCE 利用率PDCCH 控制信道负载高话务、大容量配置的密集市区日常优化里我一般把下行 PRB 利用率当主判据RRC 连接数当辅助判据。原因很简单PRB 利用率直接反映资源是否被占满这才是需要触发负载均衡的直接原因RRC 连接数高但 PRB 低多半是终端处于 idle 或小流量状态即便搬走也释放不了多少资源。反过来如果某个小区 RRC 连接数很低但 PRB 很高则要看是不是单用户大流量这时候 MLB 能帮的忙有限优先考虑查用户数和业务模型。有的厂家把负载同步消息做成“资源状态更新”里面对每个小区上报的就包含这几个量。配置 MLB 时先选定主判据不要把所有指标都叠加进判决条件否则会出现“指标 A 没超但指标 B 超了均衡不触发”的情况。2.2 用一条 SQL 把全网小区负载拍平从 PM 数据里筛出失衡小区判断候选小区不需要等网管生成专门报表直接把 PM 表拉出来按小时聚合就行。下面这条 SQL 是我常用的格式作用是把晚忙时负载超过 50% 的小区全部列出来同时带上上行利用率和 RRC 连接数方便后续人工挑配对。-- 统计晚忙时小区平均负载 SELECT cell_id, AVG(dl_prb_util) AS avg_dl_prb, AVG(ul_prb_util) AS avg_ul_prb, MAX(rrc_conn_avg) AS max_rrc_conn, SUM(flow_volume) AS total_flow FROM pm_cell_load_hour WHERE date 2025-01-08 AND hour BETWEEN 20 AND 22 GROUP BY cell_id HAVING total_flow 100 -- 丢弃业务量过小的异常小区 AND avg_dl_prb 50 ORDER BY avg_dl_prb DESC;这里有几个参数需要说明。时间范围我取晚忙时连续两小时的平均值而不是取 15 分钟粒度因为 MLB 判决本身有触发定时器单点峰值会造成误判平均值更接近真实负载。total_flow 100 是过滤刚开站或处于测试期的小区这类小区业务量低、PRB 利用率没有参考价值。HAVING 里的 avg_dl_prb 50 是初筛阈值实际做配置时这个值会和负载差门限错开来不会出现“源小区和目标小区都在 50% 附近但差 5% 也触发”的情况。拿到这份清单后再把每个小区的邻区表、外部小区定义导入就能开始配对。2.3 MLB 的判断与执行机制从 A3/A5 事件到 CIO 偏置5G 基站之间通过 Xn 接口的资源状态请求、响应、更新流程互相传递负载信息。源小区发现自己的负载持续高于目标小区一定门限后MLB 功能开始动作。动作的核心不是直接下令切换而是修改切换事件的评估偏置让 UE 的测量结果更偏向目标小区。这个机制落到无线侧就是 A3/A5 事件和 CIOCell Individual Offset。A3 事件是“邻区质量比服务小区好到某个程度”即触发适合重叠覆盖比较规整的场景A5 事件则要求在服务小区低于绝对门限、邻区高于绝对门限同时成立时才触发更适合重叠覆盖范围大、或者异频部署的场景。MLB 用 A5 时有一个好处只有处于本小区边缘、信号质量不理想的用户才会被迁移不会把小区中心体验良好的用户也一起带走。CIO 是即时可调的执行手段。把源小区到目标小区的 CIO 调成正数等于在 UE 测量评估时给目标小区“加人情分”A3/A5 更容易满足切换也就更容易发生。反过来调成负数则抑制向该目标小区切换。整套 MLB 的执行效果就是循环做“统计负载 - 发现差值 - 微调 CIO - 观察切换量”的过程。常见的 5G 邻区添加案例里有个坑邻区关系漏配了MLB 配置再完整也没有对象可用。所以做 MLB 之前先核查源小区和目标小区是否双向邻区、外部小区里的 PCI/频点/物理小区标识是否一致这一步放到第 5 章排障部分展开。3. MLB 配置方案拆解开关、门限和事件偏置是三层现网设备的 MLB 配置项很多但大致可以分三层功能开关负责“开不开”负载门限负责“什么时候开”CIO 和事件偏置负责“怎么搬”。按这个层次去配置定位问题也方便不会出现“全打开了但不知道哪个参数生效”的局面。3.1 总开关和链路承载开关先把 MLB 打开再决定让哪类承载参与第一层是功能开关。常见的命令格式大致如下具体关键字以设备厂家为准SET MLB: MLB_SWITCHON, LOAD_BALANCE_SWITCHON, MLB_TRIGGER_TIMER5; LST MLB:;MLB_SWITCHON 是总开关LOAD_BALANCE_SWITCHON 表示允许执行基于负载的切换调整。有的设备还会区分“基于切换的负载均衡”和“基于小区重选的负载均衡”前者针对连接态用户后者针对空闲态用户。如果只做 5G 连接态的负载均衡空闲态开关可以不打开避免大规模改变重选参数后终端在空闲态就已经待错了小区反而增加后续切换开销。参数里的 MLB_TRIGGER_TIMER 是触发定时器意思是负载差值连续持续 5 秒才触发一次均衡动作。这个值不建议设成 1 秒否则一个瞬时流量脉冲就能让两个小区间来回搬用户。LST MLB 用来查询已生效配置我在每次修改后都会先查一遍再离开网管。3.2 负载差门限、触发时延和 CIO一张参数表说清推荐值第二层是判决参数。不同厂家提供的参数名不同但都会围绕负载差门限、触发持续时间、CIO 调整步长、CIO 上限这几个量做配置。下面是我在现网里常用的一组起始值参数项常见推荐值配置说明负载差门限10% ~ 15%源小区与目标小区 PRB 利用率差值低于此值不触发触发持续时间3 ~ 5 秒抗瞬时抖动防止乒乓CIO 单次调整步长0.5 ~ 1 dB每次调整量步长过大会出现批量误切换CIO 调整上限3 ~ 6 dB防止单个邻区偏置被推到无限大最小驻留时间3 ~ 5 秒UE 切换到目标小区后需要停留的最短时间对应到命令行上会是这样一组设置SET MLB: LOAD_DIFF_THD15, TRIGGER_TIME5, CIO_STEP0.5, CIO_MAX6, MIN_HO_TIME3;这组值的关键在“步长小、上限低”。CIO_STEP0.5 表示每次负载均衡只把偏置调 0.5 dB看起来见效慢但不会一次性把边界上的用户全部赶走。CIO_MAX6 是安全锁即使目标小区一直很空闲源小区的偏置也不可能无限增大。MIN_HO_TIME 解决刚切过去又被切回来的问题停留不足 3 秒的终端不允许立刻触发下一次 MLB 切换。3.3 按邻区粒度配置 CIO避免一把梭式全局调整第三层是执行参数按邻区粒度设置。CIO 不是小区级参数而是邻区关系上的参数同一个源小区到邻区 A 的 CIO 和到邻区 B 的 CIO 可以完全不同。这样配置的好处是影响面可控一旦出现问题只需要回退这一条命令。SET NRELATION: SRC_CELL19-519-101, DST_CELL19-519-102, CIO1.5;这条命令把源小区 19-519-101 到目标小区 19-519-102 的 CIO 设为 1.5 dB。正值表示更容易切向该目标小区负值表示抑制。MLB 自动执行时也只会调整参与均衡的那一对邻区不会去动与负载调整无关的关系。配置时必须注意一点CIO 是成对存在的。如果只把源小区到目标小区的 CIO 调大而目标小区到源小区没有同样调整UE 从目标小区向源小区切换时评估路径不同就可能出现“大量用户被搬过去后因为目标小区到源小区的偏置不变少数用户立刻被切回来”的不对称现象。因此检查命令时我会把两条方向的 CIO 都拉出来一起看。4. 从“参数表”到“现网上线”MLB 配置的实施流程参数定了下一步是找候选小区、算初始值、分批上线。直接全量推参数风险最高因为每个小区的重叠覆盖情况不一样盲目套同一组 CIO 会在某些边界上引发切换问题。4.1 用脚本批量筛选候选小区组合候选小区筛选的思路是源小区负载超过高门限目标小区负载低于低门限且二者存在双向邻区关系。手工看几十个小区还能接受全网几百个站就得靠脚本。下面这段 Python 脚本可以基于 CSV 快速生成候选对import csv def build_mlb_pairs(csv_file, high_th60, low_th30): rows list(csv.DictReader(open(csv_file, encodingutf-8))) heavy [r for r in rows if float(r[dl_prb]) high_th] light {r[cell_id]: r for r in rows if float(r[dl_prb]) low_th} pairs [] for src in heavy: adj src.get(adjacent_cells, ).split(;) for dst_id in adj: dst light.get(dst_id) if not dst: continue diff float(src[dl_prb]) - float(dst[dl_prb]) pairs.append({ src: src[cell_id], dst: dst_id, diff: round(diff, 1) }) pairs.sort(keylambda x: x[diff], reverseTrue) return pairs脚本里 high_th 和 low_th 是一对高低门限取值应当和 MLB 判决使用的负载差门限错开。比如 MLB 要求差值 15% 才触发那 high_th 取 60、low_th 取 30既能保证候选对真实存在调整空间又不会把大量“刚好超过门限”的小区拉进来。adjacent_cells 字段在报表里用分号拼接脚本按分号拆开后逐个和高负载小区配对。最后按差值降序排序差得越多的排越前优先处理收益最明显的组合。4.2 初始 CIO 根据重叠覆盖度推算拿到候选对后下一步是算初始 CIO。不能直接拿“负载差值 20%”除以某个系数得到 4 dB因为负载差和偏置之间没有线性关系最终决定用户能否迁移的是边界区用户占比和信号差。常见做法是先按差值估一个基础值再用重叠覆盖度修正。负载差值初始 CIO 建议修正方向10% ~ 15%1.0 ~ 1.5 dB目标小区与源小区重叠覆盖小时取下限15% ~ 20%1.5 ~ 2.0 dB重叠覆盖范围大时可取上限20% 以上2.0 ~ 3.0 dB同时检查是否重叠但忙区覆盖均衡修正时我会看 MR 数据里两个小区之间的 RSRP 差值分布。如果目标小区在边缘区域的 RSRP 比源小区低 3 dB 以上CIO 值就要减半否则用户被强行带到信号很差的目标小区切换完成率会明显下降。如果两个小区在覆盖带上几乎重叠CIO 可以放宽到上限附近因为迁移过去的用户多数仍然处于良好覆盖内。4.3 用灰度分批的方式把调整落地配置下发不是一次性全线推而是一对一对来。我一般按以下顺序操作先选一对差值最大、且目标小区负载最低的组合在晚忙时前半小时下发两小时后抓取这对邻区的切换次数、切换成功率、源和目标小区的 PRB 利用率确认三个指标都正常后第二天再扩展到 5 对组合全部稳定一周后再批量下发剩余组合。批量下发时不要手输命令把命令写入文件后循环执行方便留痕和回退while read cmd; do echo $cmd | mml_client mml_result_$(date %H%M%S).log sleep 1 done mlb_commands.txt每条命令之间加 sleep 1 秒避免大量 MML 命令同时压到网管造成信令风暴。执行完的日志按时间命名一旦某条命令失败或出现异常可以直接从日志中定位是哪一条、什么时候执行。这里要特别提醒的是如果候选对里包含异频小区还要先确认异频测量配置的生效时机否则 A5 的邻区测量还没来得及上报切换就已经被判定失败。提示目标小区的负载判断必须取调整前至少两小时的平均值不能拿实时值去做初始 CIO 计算否则刚上线的业务波动会导致偏置设置偏离真实需求。5. 5G 全网排障MLB 配置生效但负载没均衡怎么办MLB 配置完成后最常听到的问题是“开关开了门限量了但还是调不动”。这种时候不要急着再加大 CIO先按现象分类排查。5.1 配置没触发先核对邻区、外部小区和资源状态通道先看开关再看消息通道最后看邻区关系。我用一张表总结常见三类现象现象可能原因排查动作MLB 从未触发小区级 MLB 开关未开或负载上报接口异常LST MLB 查询开关状态清点资源状态更新消息计数触发了但迁移量很少目标小区信号太弱或 CIO 太小查看 MR 分布比较两小区 RSRP 差值触发的切换失败率极高外部小区参数错误核对目标小区 PCI、频点、物理小区标识排障时容易被忽略的是外部小区定义。有些站点换过 PCI 或天线型号外部小区参数没有同步更新导致 UE 上报目标小区测量结果后源小区找不到对应的外部小区配置切换准备失败表现就是负载没均衡反而切换成功率下降。核查邻区的命令大致如下LST NRELATION: SRC_CELL19-519-101; LST EXTERNALCELL: EXT_CELL19-519-102;第一条命令列出源小区的所有邻区第二条查看外部小区配置。如果邻区存在但外部小区里的 PCI 与实际目标小区对不上这就是直接原因。5.2 乒乓切换和 T304 超时CIO 调整幅度过大的典型症状另一种典型故障是调整后出现乒乓切换。所谓乒乓就是 UE 刚切换到目标小区很快又因为目标小区信号变差、源小区信号恢复而切了回来来回切换导致信令负荷上升严重时演变成 T304 超时。T304 是切换完成定时器UE 收到切换命令后开始计时必须在定时器到期前完成与目标小区的上行同步超时后 UE 会回退到原小区并发起 RRC 重建用户感知直接是卡顿或掉线。MLB 场景下出现大量 T304 超时基本可以断定 CIO 单次调整跨度过大把原本处于源小区良好覆盖区的用户也强制迁了出去。处理办法是往回收敛参数。把 CIO_STEP 从 1.0 dB 降到 0.5 dB把 MIN_HO_TIME 从 3 秒提到 5 秒触发持续时间 TRIGGER_TIME 也可以从 3 秒提到 5 秒。参数调整后要回看原小区和目标小区的切换出/入成功率确认不再出现大规模失败再继续下一步。也可以配合 MR 数据把 CIO 超过 3 dB 的邻区逐一检查是否都存在较大范围的差覆盖区间。5.3 从统计表定位一次失败的调整判断一次 MLB 调整到底是好是坏只看 PRB 利用率还不够要把切换统计数据按邻区拆开看。下面这条命令从 CSV 格式的邻区切换统计中过滤出指定的源、目标小区awk -F , $119-519-101 $219-519-102 {print $1,$2,$5,$6} ho_stats_20250109.csv | head -20这里 $5 是切换尝试次数$6 是切换成功次数。调整前后对比同一组邻区的切换尝试次数如果尝试次数明显上升但成功次数没有同步上升说明该邻区的偏置设置可能超出了实际覆盖条件的承受范围如果尝试次数没有变化但两个小区的负载差仍然存在说明调整还没真正作用到用户迁移的边界需要继续加大 CIO 或检查测量上报条件。这个“对比尝试次数和成功次数”的口径比单纯看负载均值更接近问题的本质。负载均衡做得成功的表现是切换尝试次数适度增加、成功率基本不降而不是切换次数暴涨。6. 调优验证用三个指标确认 MLB 真的把负载“搬”过去了6.1 先把全小区负载的方差和极差算出来一个很直观的验证方式是看负载离散度。把调整前后同一个统计时段内所有小区的下行 PRB 利用率取出来算方差和极差。方差下降说明负载分布更均匀了。import csv def load_prb(csv_file): return [float(r[dl_prb]) for r in csv.DictReader(open(csv_file))] def variance(vals): mean sum(vals) / len(vals) return sum((v - mean) ** 2 for v in vals) / len(vals) before load_prb(before_mlb.csv) after load_prb(after_mlb.csv) print(before variance:, round(variance(before), 2)) print(after variance:, round(variance(after), 2))我一般在调整前取 3 个工作日、调整后取 3 个工作日同样取晚忙时两个小时的平均值再算。原因是相邻日期的业务模型不同只拿一天对比说服力不够。同时把极差也算出来看看MAX 利用率从 85% 降到 70% 以内即使方差变化不大也说明高负载尖峰得到了缓解。6.2 再看负载均衡有没有透支切换质量第二个指标是切换成功率。MLB 的核心代价是切换次数增加只要切换成功率能维持在 99.5% 以上、T304 超时次数没有明显上涨就说明这部分代价可接受。如果方差降了但切换成功率跌破 99%说明 CIO 调过了应该回调一个步长。第三个指标是看目标小区最终是否真的受益。验证时把参与均衡的目标小区单独拿出来看它们调整后的 PRB 利用率是否仍然低于 50%。如果目标小区也逼近 50%说明周边已经没有真正的空闲容量这时候继续加大 CIO 只是把拥塞从 A 小区挪到 B 小区对全网没有任何增益。我会把目标小区按调整后的负载排序凡是超过 50% 的小区一律从 MLB 候选列表里先拿掉再回到容量规划去看是否需要扩载或增加载波。用这个标准收尾MLB 才算调到“可交付”的状态。本文还有配套的精品资源点击获取