企业官网建设流程全解析

简介：移动性负载均衡（MLB）配置方案专项文档，聚焦5G/LTE网络中的小区负荷不均衡问题，面向网优工程师、系统工程师及项目交付人员。文档从MLB的定义与触发背景切入，系统讲解方案分析、配置原则、均衡执行和方案实施，重点展开异频同步态用户数均衡（转移同步态用户）、异频同步态用户数均衡（转移空闲态用户）与异频空闲态UE预均衡三种模式的参数配置、RRC切换/释放流程及优缺点对比，并给出候选邻区识别、负载信息交互、目标小区选择等关键配置建议。同时穿插载波聚合、干扰管理与FDD电调核查等关联优化知识，便于在实际容量与覆盖协同优化中灵活参考。包体包含1个docx文件，大小1.21MB，排版清晰、步骤完整，可直接作为5G网络优化项目组内培训材料或现场排障手册。目前已有119人浏览学习，适合需要系统掌握MLB策略并快速落地的网优人员。

1. MLB不是调几个偏移量那么简单

NSA/SA组网下常见这样一个抓狂现场：一个5G小区忙时PRB利用率冲到85%，同站另外两个小区却只有20%，用户视频卡在缓冲里，投诉电话一个接一个。把CIO调大两圈之后，负载总算是摊下去了，但切换成功率掉了一个百分点，边缘用户又开始投诉掉话，最终只能回退参数。这种现场每天都在5G网络优化里出现，也是移动性负载均衡（MLB）被低估的原因。MLB的实质是利用移动性参数引导边缘用户从高负载小区迁移到低负载邻区，但要真正生效，测量事件、负载判决、站间信令、定时器和邻区关系少一个都不行。这篇文章按“原理—参数—现网落地—排障—验证”的顺序，把5G MLB配置方案完整拆开。

2. 移动性负载均衡的触发链路：从负载检测到测量事件

2.1 MLB在5G里解决什么，和LTE有什么本质区别

MLB不是新概念，LTE时代就在eNodeB之间通过X2接口交换负载信息，靠CIO调整实现小区间话务迁移。到了5G，情况复杂在三个层面：频率层变多、波束引入、组网模式叠加。一个5G基站可能同时开3.5GHz、2.6GHz和700MHz等多个频段，每个小区还配了多个SSB波束，小区平均PRB利用率不能代表某个波束方向的拥塞程度。所以MLB配置首先要明确粒度：现网多数实现仍然以小区为最小单位，波束级的负载均衡通常由设备商自己的调度算法处理，外部配置介入空间不大。

第二个变化是NSA与SA共存。NSA终端走双连接，控制面在LTE，数据面在5G；SA终端全程由NR服务。当整网处于NSA/SA混跑状态时，MLB触发出来的切换可能跨系统、跨锚点，CIO调整的影响范围与纯SA场景完全不同。因此在任何MLB配置方案启动前，先确认目标小区是SA小区还是NSA小区，以及邻区关系中是否包含LTE锚点站。忽略这一条，后面所有参数调整都可能作用在错误对象上，这也是多个5G网络优化项目里MLB“配置了但没效果”的首要原因。

2.2 A3/A4/A5事件在MLB里怎么选

MLB不定义新测量事件，它复用NR移动性测量里的A3、A4、A5事件。A3是同频切换的核心事件，触发公式满足 Mn + Ocn - Hys > Ms + Ocs + Off，其中Ocn是邻区CIO，Ocs是服务小区CIO。把Ocn调大，相当于抬高了邻区测量值，让终端更早满足上报条件；把Ocs调大则反过来延迟切换。MLB最常见的执行方式就是周期性步进调整CIO，改变A3触发的提前量，从而把边缘用户迁到低负载邻区。

A5事件使用两个绝对门限：服务小区RSRP低于门限1，同时邻区RSRP高于门限2，两个条件同时满足才会触发上报。A5更保守，适合异频和异系统场景，因为可以对目标邻区的绝对信号质量设下限，避免把用户切到信号很差的异频小区。A4事件只判断邻区信号是否高于绝对门限，适合在执行迁移前对候选低负载邻区做快速筛选。异频MLB我常用的组合是：源小区下发A4测量筛选可用邻区，再用A5做最终切换判决；纯单频宏站同频场景则直接使用A3加CIO调整，不引入A5。

下表给出三个事件在MLB里的定位，方便做配置方案时快速选型：

事件选型决定后续CIO调整是否有效。遇到过某个项目用A5做同频MLB，门限1设到-100dBm，服务小区RSRP还在-95dBm就触发上报，目标小区又是共站近点，切换过去覆盖反而变差。这不是MLB参数本身的问题，而是事件模型与场景不匹配。

2.3 负载信息从哪来：PRB利用率、用户数和Xn信令

MLB要决策，前提是知道本小区和邻区的负载。基站通常同时统计三类信息：空口PRB利用率、传输网络层TNL负载、硬件资源负载。PRB利用率是最常用指标，但它无法单独代表业务压力。一个小区PRB利用率75%、在线用户80个、激活用户只有6个，属于典型的“资源占用高但业务不忙”；相反PRB利用率60%、激活用户40个，调度队列已经开始排队，体验反而更差。所以实践中要把PRB利用率和激活用户占比合在一起看：激活用户占在线用户数比例超过一定值，同时PRB超过门限，才判定小区确实拥塞。

小区间负载信息交换，SA走Xn接口的RESOURCE STATUS UPDATE流程，NSA走X2接口，上报内容包含DL/UL PRB利用率、TNL负载和硬件负载。MLB配置前要检查邻接基站间的资源状态协商是否打开，上报周期通常建议5到10秒。周期太短，地铁、高铁等快变场景里参数会频繁抖动；周期太长，负载均衡动作滞后，拥塞窗口已经结束才把用户切走，徒增无效切换。

2.4 MLB启动、停止与迟滞判断

MLB的启动和停止需要有迟滞，避免负载在门限附近抖动时反复调整CIO。常见做法是连续3个统计周期PRB利用率都高于启动门限才启动，连续3个周期都低于停止门限才停止。启动门限取70%、停止门限取50%的好处是中间有一段保持区，系统不因单次波动就改变状态。下面的状态机用一个紧凑的Python函数就能复现：

def judge_mlb_state(prb_history, start_th=70, stop_th=50, hold_period=3): window = prb_history[-hold_period:] if len(window) < hold_period: return "hold" if all(p >= start_th for p in window): return "start" if all(p <= stop_th for p in window): return "stop" return "hold"

这段逻辑的要点是：最近3个统计周期的PRB利用率全部超过70%才置为start，全部回到50%以下才置为stop，其他情况一律返回hold。hold表示保持当前状态不变化，这是防止参数反复调整的关键。实际使用时，把每个周期的PRB利用率按时间顺序喂给prb_history，返回值就是MLB需要执行的状态。停止门限比启动门限低约20个百分点，这个迟滞宽度在多数5G场景够用；如果小区负荷本身波动剧烈，可以把门限差拉大到30个百分点。

3. 5G MLB参数配置：可直接套用的取值与联动关系

3.1 一套可落地的MLB参数表

MLB参数在现网设备上命名有差异，但语义基本一致。想快速搭出一套可用的配置，我会从下面这张表开始，再根据厂商命令映射到具体字段：

表里容易忽略的两个点：边缘用户RSRP门限的作用是只让弱场用户参与均衡，因为在强场区域强行切走用户，对负载贡献有限，用户速率却会明显下降。CIO调整范围限制在±6dB，是因为超过6dB后实际切换边界严重偏离真实覆盖边界，继续增大换来的往往是切换失败率上升而不是负载下降。

3.2 同频和异频MLB的配置差异

同频MLB最简单，A3事件加CIO步进就能工作。两个邻区工作在同一频点，终端不需要配置异频GAP，测量是连续的，TTT可以给到480ms，切换可靠性优先。实际操作时把同频MLB的CIO步长设为0.5dB，以15分钟为一个调整周期，观察负载差是否收敛；不收敛再改为1dB步长。同频场景乒乓风险高，TTT尽量不要低于320ms。

异频MLB复杂很多。终端必须配置测量GAP，GAP期间不能调度业务，所以异频测量本身会带来吞吐损失。配置上先开A4事件做候选邻区筛选，再在目标侧用A5事件确认切换条件。GAP周期建议配成40ms、持续6ms的pattern，兼顾异频测量速度和业务调度开销。异频MLB的CIO调整同样有效，但由于测量是周期性的，TTT要缩短到320ms左右，否则从测量到上报再到切换，时延积累下来会明显变长，负载均衡效果滞后。

3.3 CIO与定时器联动：T304、T310、TTT在信令流程中的位置

调整CIO不是孤立行为，它直接改变切换在信令流程里的触发点。完整切换流程大致是：终端上报测量报告，源基站向目标基站发起切换准备，目标基站确认后源基站向终端下发RRC重配置消息，终端在目标小区发起随机接入，完成后回复RRC重配置完成。MLB把CIO调大后，切换点会外推，终端在更差的无线环境下做随机接入，此时T304定时器的影响就被放大。

T304从RRC重配置消息下发开始计时，到终端完成目标小区随机接入为止，超时即判定切换失败。现网里T304超时最常见的原因不是定时器太短，而是目标小区接入条件差。T310则监测服务小区链路质量，物理层连续失步到一定次数后启动，超时进入RLF。CIO过大时，服务小区信号在切换点附近已经较弱，T310可能先于T304超时，终端直接进入RRC重建流程。所以MLB参数与定时器需要一起考虑：CIO最大做到±6dB的同时，T304保持现网默认值，T310按RLF率决定是否调整，TTT按同频480ms、异频320ms的基准做微调。

提示：切换失败日志里“T304超时”和“随机接入失败”经常同时出现，定位时先看是接入失败导致超时，还是超时后随机接入被打断，处理方向完全不同。

3.4 用Python脚本做MLB参数一致性检查

MLB参数经过多轮修改后，很容易出现同站参数漂移：三个小区门限不一致、CIO步长不统一，后续问题定位极难。我习惯把配置导出成CSV后，用Python做一致性校验。下面这段脚本按基站分组，检查同站小区在PRB门限和CIO步长上的差异：

import csv def check_mlb_consistency(csv_path): with open(csv_path, newline='', encoding='utf-8') as f: rows = list(csv.DictReader(f)) by_gnb = {} for r in rows: by_gnb.setdefault(r['gNodeB'], []).append(r) for gnb, cells in by_gnb.items(): dl_thrs = {c['dl_prb_th'] for c in cells} cio_step = {c['cio_step'] for c in cells} if len(dl_thrs) > 1 or len(cio_step) > 1: print(f"{gnb}: PRB门限={dl_thrs}, CIO步长={cio_step}")

脚本先把带gNodeB、小区ID、DL PRB门限、CIO步长的CSV读进来，按基站分组，再用集合去重；同站出现多个不同取值，就把异常打印出来。同站三个小区覆盖连续，负载均衡行为必须对称，门限和步长不一致会让边缘用户被切到某一侧后又切回来，形成循环切换。整网跑一遍这个检查只花几十秒，是MLB改动后值得纳入例行巡检的兜底操作。

4. 现网MLB落地：邻区筛选、切换失败与全网排障

4.1 从邻区表到MR：圈定候选小区的正确顺序（5G邻区添加案例的坑）

参数配好了，不等于MLB就能跑。真正落地时第一步是确定哪些邻区可以作为负载迁移目标。不建议把邻区表里所有小区都放进MLB候选，否则乒乓关系数量会爆炸。筛选顺序通常是：先导出邻区关系表，保留同站小区和同覆盖方向的异站小区；再结合MR测量数据，确认两个小区之间存在一定规模的边缘重叠区域；最后用网管KPI排除长期存在高干扰或高切换失败率的邻区。

5G邻区添加案例里最容易犯的错是只加邻区不进异频组。比如主小区在3.5GHz，邻区是2.6GHz小区，邻区表里已经添加，但终端没有下发异频GAP和A4/A5测量控制，MR里根本看不到该邻区的信号，MLB自然不触发。查这类问题要看信令里的measConfig，确认异频测量对象和GAP配置已经下发。另一个常见坑是邻区同级不同频时优先级配置错误，终端测量到信号很好，上报后切换却被系统判为不合法。

4.2 切换失败排障：T304超时、PRACH和准入拥塞

MLB调完一周后，如果发现切换成功率掉了一个点，先别急着怀疑CIO，把失败句柄拆开看。

如果失败集中在执行阶段，重点看RACH。5G PRACH的preamble格式分长格式和短格式：长格式覆盖能力强，适合大半径小区，但单位时间接入容量低；短格式适合小覆盖、高并发场景。MLB把边缘用户迁到覆盖半径很大的邻区时，目标小区PRACH格式与实际覆盖不匹配，就会反复出现随机接入失败。这种情况单纯调CIO没有意义，要先修正PRACH配置，或者把MLB迁移范围收敛到覆盖可控的邻区。

排查时把切换失败日志拉下来，用下面的Python片段快速统计失败原因分布：

from collections import Counter def ho_fail_reason(log_lines): reasons = Counter() for line in log_lines: if "HOFail" not in line: continue if "T304" in line: reasons["t304_timeout"] += 1 elif "RAProblem" in line: reasons["rach_fail"] += 1 elif "AdmissionReject" in line: reasons["admission_reject"] += 1 else: reasons["unknown"] += 1 return reasons

统计结果里，t304_timeout和rach_fail占比高，基本锁定为目标小区随机接入侧的问题；admission_reject占比高，则是目标小区业务准入受限。两条处理路径完全不同：前者动PRACH和覆盖相关配置，后者要检查容量license和用户面资源。多网元同步排查时，这套分类能让全网排障效率提升不少。

4.3 乒乓切换、边缘过迁与车联网场景的抑制策略

MLB引入后的另一个典型问题是乒乓切换。反反复复切来切去，浪费信令资源，也直接影响用户感知。抑制手段从四个层面下手：TTT不低于320ms；CIO每步不超过0.5dB；邻区负载差门限提高到10%以上；配置切换禁止回切时间窗，短时间内不允许反向切换。

车联网这类连续高速移动场景对乒乓尤其敏感，MLB配置要比普通城区更保守。我的做法是把邻区负载差门限从10%提高到15%，TTT进一步提到640ms，宁可让负载均衡收敛慢一些，也不能让高速移动中频繁切换。边缘用户过迁同样要盯：边缘用户RSRP门限如果设到-100dBm，一些强场用户也会被迁走，切到邻区后覆盖变差，速率明显下降。建议门限取-108dBm到-105dBm，只对真正处于边缘的用户启用MLB。

5. MLB配置后的验证指标与按天收敛技巧

5.1 忙时验证盯四个指标

MLB配置后，验证不能只看负载有没有均衡，更要看均衡代价。忙时2小时窗口内重点盯四个指标：PRB利用率标准差、切换成功率、乒乓切换率、用户体验速率。标准差下降说明负载更均匀；切换成功率不降是底线；乒乓率上升说明参数过激；体验速率持平或上升才算有效均衡。四个指标放在同一张报表里看，单个指标单独好看没有意义。

5.2 用Python输出日均均衡指数

人工盯数据容易漏，每天跑一段脚本自动汇总均衡指数，会更稳定。均衡指数可以用1减去“标准差的归一化值”来表示，越接近1说明小区间负载越均匀。

import pandas as pd df = pd.read_csv("busy_hour_kpi.csv") df["load_balance_index"] = 1 - df["prb_std"] / df["prb_mean"] daily = df.groupby("date")["load_balance_index"].mean() daily.to_csv("mlb_balance_daily.csv")

这份日均均衡指数能直接反映MLB是否在长期起作用。数值连续三天下降，回查是邻区关系变化还是门限被改动；数值稳定在高位时，就该考虑收敛CIO调整参数，减少不必要的切换信令。

5.3 CIO按天收敛的自优化方法

MLB参数不用天天调，按天粒度收敛就够了。参考做法是：每天忙时结束后对比当天的均衡指数，相比前一天改善小于2%，就把CIO步长减半，直到0.25dB为止；如果均衡变差，立即回退当天的CIO调整值，并把这个时段标记为敏感时段，后续不再触发。两三周跑下来，CIO会收敛到一套稳定取值，把这套值固化进现网参数模板，后续新开站可以直接继承，不需要重新走完整轮MLB调优。

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