企业官网建设流程全解析

简介：移动性负载均衡（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% 附近。人工去调切换参数能做，但要等到凌晨操作、白天观察，改一组邻区往往要两三天。移动性负载均衡（MLB，Mobility Load Balancing）解决的问题就是这个：网管周期统计小区负载，发现邻区间负载差超过门限后，自动调整切换或重选参数，把用户从忙小区引导到空闲小区，整个过程不需要载波扩容。这篇按网络优化里最常见的落地路径来讲：先看负载怎么量，再拆 MLB 的开关、门限和偏置参数，然后给出现网实施与排障的具体方法。适合日常做参数优化和开站入网的工程师，也适合在 5G 全网排障时顺手把 MLB 一起查了的人。

2. 负载均衡前要先回答的问题：用哪条指标判断“哪个小区更忙”

MLB 的“负载”在现网统计里不是一个数。直接用某个指标可能会误判：有的小区 RRC 连接用户很多，但基本都是挂在网上的即时通信流量，PRB 占用并不高；有的小区用户不多，却在下大文件，PRB 接近打满。给 MLB 配负载门限之前，先要把统计口径想清楚。

2.1 PRB 利用率和 RRC 连接数：两个口径各盯什么

从 PM 统计角度看，最常用的四个量是：下行 PRB 利用率、上行 PRB 利用率、RRC 平均连接数、CCE 利用率。它们反映的资源维度不同，适合的业务场景也不同。

日常优化里，我一般把下行 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 事件和 CIO（Cell 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_SWITCH=ON, LOAD_BALANCE_SWITCH=ON, MLB_TRIGGER_TIMER=5; LST MLB:;

MLB_SWITCH=ON 是总开关，LOAD_BALANCE_SWITCH=ON 表示允许执行基于负载的切换调整。有的设备还会区分“基于切换的负载均衡”和“基于小区重选的负载均衡”，前者针对连接态用户，后者针对空闲态用户。如果只做 5G 连接态的负载均衡，空闲态开关可以不打开，避免大规模改变重选参数后，终端在空闲态就已经待错了小区，反而增加后续切换开销。

参数里的 MLB_TRIGGER_TIMER 是触发定时器，意思是负载差值连续持续 5 秒才触发一次均衡动作。这个值不建议设成 1 秒，否则一个瞬时流量脉冲就能让两个小区间来回搬用户。LST MLB 用来查询已生效配置，我在每次修改后都会先查一遍再离开网管。

3.2 负载差门限、触发时延和 CIO：一张参数表说清推荐值

第二层是判决参数。不同厂家提供的参数名不同，但都会围绕负载差门限、触发持续时间、CIO 调整步长、CIO 上限这几个量做配置。下面是我在现网里常用的一组起始值：

对应到命令行上，会是这样一组设置：

SET MLB: LOAD_DIFF_THD=15, TRIGGER_TIME=5, CIO_STEP=0.5, CIO_MAX=6, MIN_HO_TIME=3;

这组值的关键在“步长小、上限低”。CIO_STEP=0.5 表示每次负载均衡只把偏置调 0.5 dB，看起来见效慢，但不会一次性把边界上的用户全部赶走。CIO_MAX=6 是安全锁，即使目标小区一直很空闲，源小区的偏置也不可能无限增大。MIN_HO_TIME 解决刚切过去又被切回来的问题，停留不足 3 秒的终端不允许立刻触发下一次 MLB 切换。

3.3 按邻区粒度配置 CIO，避免一把梭式全局调整

第三层是执行参数，按邻区粒度设置。CIO 不是小区级参数，而是邻区关系上的参数：同一个源小区，到邻区 A 的 CIO 和到邻区 B 的 CIO 可以完全不同。这样配置的好处是影响面可控，一旦出现问题只需要回退这一条命令。

SET NRELATION: SRC_CELL=19-519-101, DST_CELL=19-519-102, CIO=1.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_th=60, low_th=30): rows = list(csv.DictReader(open(csv_file, encoding='utf-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(key=lambda x: x['diff'], reverse=True) return pairs

脚本里 high_th 和 low_th 是一对高低门限，取值应当和 MLB 判决使用的负载差门限错开。比如 MLB 要求差值 15% 才触发，那 high_th 取 60、low_th 取 30，既能保证候选对真实存在调整空间，又不会把大量“刚好超过门限”的小区拉进来。adjacent_cells 字段在报表里用分号拼接，脚本按分号拆开后，逐个和高负载小区配对。最后按差值降序排序，差得越多的排越前，优先处理收益最明显的组合。

4.2 初始 CIO 根据重叠覆盖度推算

拿到候选对后，下一步是算初始 CIO。不能直接拿“负载差值 20%”除以某个系数得到 4 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 配置没触发：先核对邻区、外部小区和资源状态通道

先看开关，再看消息通道，最后看邻区关系。我用一张表总结常见三类现象：

排障时容易被忽略的是外部小区定义。有些站点换过 PCI 或天线型号，外部小区参数没有同步更新，导致 UE 上报目标小区测量结果后，源小区找不到对应的外部小区配置，切换准备失败，表现就是负载没均衡反而切换成功率下降。核查邻区的命令大致如下：

LST NRELATION: SRC_CELL=19-519-101; LST EXTERNALCELL: EXT_CELL=19-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 ',' '$1=="19-519-101" && $2=="19-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 才算调到“可交付”的状态。

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