简介：这是面向4G/5G网络优化工程师与技术人员的LTE负荷均衡（MLB）技术文档，系统讲解Intra-LTE与Inter-RAT两类负荷均衡原理、测量-判决-执行三阶段流程，以及异频切换开关、MLB算法开关、触发模式等关键参数配置，可用于日常网络负荷均衡参数调优、容量优化与现网维护排障。压缩包内仅含1个doc文档，约111KB，内容完整覆盖从原理到实操的完整链路，携带便捷。已有96人浏览学习。文档对负载报告、基于切换的负载均衡、切换参数自适应调整、PRB模式与用户数模式触发门限、负载偏置等均有展开说明，并给出MOD命令示例，能为读者节省反复查阅资料时间，直接对照现网场景验证参数效果，也适合新入职的网优人员快速建立参数级认知。
1. 先聊场景：双载波部署到位，负荷却还是偏的，问题出在哪
做LTE负荷均衡参数实施这件事，最常遇到的不是命令敲不下去，而是明明双载波已经部署完，两个同覆盖小区一个忙到PRB利用率冲到70%以上，另一个闲到只有十几，用户却还堆在热点载波上。加了一个载波，投诉率一点没降，后台一看切换次数少得可怜——这时候问题基本不在覆盖，而在负荷均衡（MLB）算法压根没按场景配置起来。这份资源是一份很典型的LTE负荷均衡参数实施方案，覆盖从算法原理到MML命令的完整链路，适合正在做双载波同覆盖优化、扩容后用户不迁移、忙时负荷不均三类场景的优化和基站侧操作人员。把它的配置思路吃透，等于拿到了把第二载波真正用起来的操作手册。
2. MLB原理拆解：三阶段循环与intra-LTE五步，先把算法怎么干活讲清楚
2.1 三阶段的职责划分：测量、判决、执行各自看什么数据
负荷均衡不是一拍脑袋就把用户切走的。从算法内部看，它始终在跑一个“测量-判决-执行”的循环，三个阶段各有各的输入和输出。
测量阶段负责持续监控本小区和邻区的负荷状态。这里有个容易被忽略的细节：异站邻区的负荷信息走X2接口获取，默认每5秒请求一次，周期在后台可以改；同基站邻区不走X2，直接内部消息拿，时延更短。这个5秒的粒度决定了所有判决都不会是瞬时的——就算你把触发门限调得很低，负荷信息本身仍有最多5秒的滞后，调参数时心里要有这个底。
判决阶段拿测量数据做判断：本小区是不是高负荷？如果没达到高负荷标准，就继续等下一个周期的测量结果；达到了，才进入执行阶段。高负荷怎么定义，完全取决于你在网管里配的MLB触发模式，用户数模式看上行同步态用户数，PRB模式看PRB利用率，后面会展开讲。
执行阶段才是真正动用户的时候。基于UE测量切换的方式，先给UE下发A4异频测量，上报RSRP满足门限后把选定用户切到低负荷邻区；盲切换方式不发测量，直接把用户切过去。两种方式各有利弊，后面专门对比。
2.2 intra-LTE MLB的五步循环：从高负载识别到邻区选择
intra-LTE MLB的执行过程可以拆成五步：
- 周期性监测本小区负载；
- 本小区负载到达高负载状态，开始收集邻区负载情况；
- 从邻区里挑出合适的候选目标；
- 与目标邻区做参数协商并调整；
- 高负载状态缓解了就回到第1步继续监测；没缓解就继续选下一个邻区操作。
这个循环最有价值的地方在于它不是一次性的“切完就完”，而是带反馈的闭环。第5步的“返回”很关键——很多现场翻车就翻在只做了第3步和第4步，没有回头确认高负载是否真正缓解，结果切完一轮，用户又慢慢回流到原小区，形成隐性乒乓。
我在实际项目里会额外关注第4步的“参数协商”。LTE的MLB在切换参数自优化时，会动态调整目标小区的切换偏置，让后续用户的切换判决更偏向低负荷侧。这个动态调整的过程如果没有在后台打开对应开关，第4步实际上只做了一部分，均衡效果会打折扣。
2.3 两种执行方式对比：盲切换与基于UE测量切换的适用边界
文档里明确提到负荷均衡有三种状态：关闭、打开（基于UE盲切换）、打开（基于UE测量切换）。后两种是执行阶段的核心差异。
基于UE盲切换的好处是快，信令开销小，不需要UE上报测量报告，系统直接选目标小区。坏处也很明显——你根本不知道UE在目标频点上是否具备足够的信号强度，万一异频邻区覆盖有空洞，用户就会被“盲扔”到弱覆盖区，掉话风险直线上升。我一般只在两种场景下用盲切换：一是大面积话务突发，优先把负荷压下来再说；二是异频邻区覆盖质量已经通过路测和MR统计确认过，覆盖连续有保证。
基于UE测量切换是现网更稳妥的默认选择。流程是选定候选用户后下发A4测量，UE上报目标频点RSRP，超过设定的门限才执行切换。慢一点，但每次切换都对信号质量有交代。这个A4门限怎么设，直接影响触发判断，文档给的经验值是首先要保证RSRP不能太低，否则异频信号本来就差还硬切，等于把用户从好的覆盖搬到差的覆盖。
3. 打开功能前的开关配置：异频覆盖开关、MLB算法开关与目标频点过滤
3.1 先开异频覆盖切换开关，业务连续性才有基础
在做任何MLB参数之前，先确认异频覆盖切换算法是开着的。
MOD ENODEBALGOSWITCH: HoAlgoSwitch=InterFreqCoverHoSwitch-1;
这条命令打开的是基于覆盖的异频切换算法开关。它和MLB是两层逻辑：MLB负责“因为负荷不均衡而把用户搬到异频”，异频覆盖切换负责“UE到了异频之后，后续移动过程中业务能正常切换和保持”。如果这个开关是OFF，MLB把用户切过去之后，用户后续上下行业务连续性没有算法兜底，很容易出现切过去就掉线或者无法切换的情况。
现网里这个开关基本都已经是全开状态。但数据配置这种事，默认全开不等于现场就是开着的，尤其是经过多轮脚本更新、批量数据修改之后，难免有小区参数被改回去。稳妥的做法是用查询命令拉一遍现网配置，确认InterFreqCoverHoSwitch的值，再往下走。
3.2 MLB算法开关：控制的不只是一个功能，而是一组子开关
MLB算法开关在后台是一个复合开关，通过MOD CELLALGOSWITCH配置，命令格式如下：
MOD CELLALGOSWITCH: LocalCellId=XXX, MlbAlgoSwitch=InterFreqMlbSwitch-1;
MlbAlgoSwitch这个参数名下其实挂着一组开关，包括同频负载平衡、同频空闲态负载平衡、异频负载平衡、异频空闲态负载平衡、异频盲负载平衡、UTRAN系统负载平衡、GERAN系统负载平衡、CDMA系统负载平衡、PRB评估值负载平衡、基于邻区负载状态的负载平衡等。
双载波场景下，最常用的是异频负载平衡和异频空闲态负载平衡两个子开关。没有大话务保障需求时，现网通常把这两个设为ON——文档里关于这个开关的影响说得很直白：异频负载平衡设为OFF之后，本小区负载再高、异频邻区再空，也没法把业务分担过去，系统过载率会上升，接入成功率和吞吐量都会下降。
这里要特别提醒一个全网一致性要求：同频空闲态负载平衡开关必须在全网统一配置，要么全开要么全关。原因很现实——空闲态UE不占用业务信道，但如果相邻两个小区的空闲态负载平衡策略不一致，UE在小区重选的时候会被来回“推搡”，频繁重选，信令负荷和用户感知都会变差。这种全网一致性问题往往是做批量脚本时无意引入的，排查起来最费时间。
3.3 异频频点是否允许做负载均衡目标，是一个保护性开关
有了算法开关还不够，还要告诉系统哪些异频频点有资格当负载均衡目标。
MOD EUTRANINTERNFREQ: LocalCellId=XXX, DLEARFCN=38350, MLBTARGETIND=ALLOWED;
MLBTARGETIND取值为ALLOWED或NOT_ALLOWED。ALLOWED表示该频点可以作为负载均衡目标；NOT_ALLOWED表示不允许向这个频点做负荷转移。
这个开关的实际意义在于频点级保护。实际组网中，双载波的两个频点未必在所有区域都是同覆盖的，某个异频频点可能只有部分区域覆盖良好。如果允许向一个覆盖不连续的频点做负荷均衡，用户被搬过去之后可能很快进入弱覆盖，得不偿失。现场常做的操作是把覆盖质量存疑的频点先设为NOT_ALLOWED，等路测数据确认覆盖连续再加回来。
也要注意它的副作用——文档明确写了，配置为不允许时，这个异频频点下面的邻区全部不能参与负荷均衡，算法可选目标变少，均衡效率会下降。所以这个开关是“保护优先”的一个设计，它宁可不均衡，也不能把用户切到没覆盖的频点。
4. 参数怎么设才不翻车：CELLMLB触发模式与关键参数逐项拆解
4.1 触发模式选型：PRB_ONLY、UE_NUMBER_ONLY还是PRB_OR_UE_NUMBER
先选触发模式，所有门限参数都挂在它下面。
MOD CELLMLB: LOCALCELLID=XXX, MLBTRIGGERMODE=UE_NUMBER_ONLY;
MLBTRIGGERMODE有三个取值：PRB_ONLY、UE_NUMBER_ONLY、PRB_OR_UE_NUMBER。
PRB_ONLY模式把PRB利用率当作唯一的触发判据，适合数据业务占绝对主导、用户数不多但单用户流量大的场景。这种场景下PRB是真正稀缺的资源，用PRB衡量负荷最准确。
UE_NUMBER_ONLY模式只看上行同步态用户数，适合用户数多、等待时延敏感的场景，比如高校、交通枢纽、商业区。这类场景里用户数先于PRB达到瓶颈，用户体验差主要是因为用户排队，而不是资源真正用满。
PRB_OR_UE_NUMBER是“两个条件谁先满足就触发”，现场用起来更灵活。缺点是逻辑相对复杂，排查触发原因时得多看一层数据。我给普通双载波场景的建议是先从PRB_OR_UE_NUMBER起步，随后根据实际触发记录往单一模式收敛。
4.2 PRB模式参数：门限、偏置、负载差如何联动
PRB模式触发参数用下面这条命令配置：
MOD CELLMLB: LOCALCELLID=XXX, INTERFREQMLBTHD=60, LOADOFFSET=8, LOADDIFFTHD=15;
三个参数的作用要放在一起读：INTERFREQMLBTHD是异频负载平衡启动门限，LOADOFFSET是PRB负载偏置，LOADDIFFTHD是负载差门限。
实际触发值不是INTERFREQMLBTHD本身，而是它和LOADOFFSET之和。例子里，PRB利用率要大于等于60%+8%=68%才触发均衡；退出条件是PRB利用率回落到60%以下。这中间留了8%的滞回带，就是为了防止算法在临界点反复触发和退出。LOADOFFSET设太大，高负载得不到及时平衡；设太小，均衡刚启动就退出，反复横跳。
LOADDIFFTHD管的是“邻区有没有资格接活”。它要求服务小区PRB利用率减去邻区PRB利用率的结果大于15%，该邻区才能作为目标。这个值设大了，一个周期内转出去的负载比较多、吞吐率改善明显，但过大可能筛不出任何邻区；设小了，能选出一堆邻区，但每个周期转出的负载量很少，改善不温不火。建议先保持10到20之间，根据目标邻区实际吸收情况做微调。
参数逻辑可以用下面这张表梳理：
| 参数 | 默认含义 | 设大的影响 | 设小的影响 |
|---|---|---|---|
| INTERFREQMLBTHD | 启动门限基准值 | 启动晚，转移前吞吐率受损时间长 | 启动频繁，信令和CPU负担上升 |
| LOADOFFSET | 触发偏置，形成滞回带 | 高负载无法及时平衡，停止不干脆 | 均衡频繁触发和停止，形成振荡 |
| LOADDIFFTHD | 服务小区-邻区负载差门限 | 单周期转移负载多，但可能选不到邻区 | 单周期转移负载少，改善不明显 |
4.3 用户数模式参数：从触发门限到最大切换用户数的完整MOD命令
用户数模式的核心命令比PRB模式长得多，一次把所有参数配齐：
MOD CELLMLB: LOCALCELLID=129, MLBTRIGGERMODE=UE_NUMBER_ONLY, INTERFREQMLBUENUMTHD=300, MLBUENUMOFFSET=20, MLBMAXUENUM=5, MLBUESELECTPRBTHD=30, UENUMDIFFTHD=15, INTERFREQUETRSFTYPE=SynchronizedUE-1&IdleUE-1, INTERFREQIDLEMLBUENUMTHD=300, INTERFREQLOADEVALPRD=10, FREQSELECTSTRATEGY=FAIRSTRATEGY, LOADBALANCENCELLSCOPE=ADAPTIVE, IDLEUESELFREQSCOPE=LOADINFOFREQ;
逐一拆解关键项：
INTERFREQMLBUENUMTHD和MLBUENUMOFFSET这一对与PRB模式的“基准门限+偏置”逻辑相同，实际触发用户数是300+20=320。退出条件是回落到300以下。
MLBMAXUENUM是最容易被无视的一个参数。它限制一个负载均衡周期内最多切换出多少用户，例子里是5。它的存在是为了防止本小区一次切出过多用户把邻区直接“灌满”。设大了邻区用户数上升快，设小了本小区负载下降慢。
MLBUESELECTPRBTHD=30表示选用户时优先挑选当前PRB占用率不低于30%的用户，保证切出去的是真正消耗资源的用户，而不是刚接入还没开始传数据的小流量用户。
UENUMDIFFTHD=15是用户数差门限，服务小区用户数与邻区用户数之差要大于15，该邻区才能成为目标。这个门槛和PRB模式下的LOADDIFFTHD是同一类设计。
INTERFREQUETRSFTYPE=SynchronizedUE-1&IdleUE-1表示同步态用户和空闲态用户都参与异频负荷均衡。如果只想处理在线业务，可以只保留SynchronizedUE。INTERFREQIDLEMLBUENUMTHD=300是空闲态用户数的独立触发门限。INTERFREQLOADEVALPRD=10是负荷评估周期，10秒一次，周期越短算法越灵敏，但信令交互越频繁。FREQSELECTSTRATEGY=FAIRSTRATEGY和LOADBALANCENCELLSCOPE=ADAPTIVE属于策略型参数，一般按默认走，除非你已经明确知道要改变频点选择逻辑。
我见过不少现场把MLBMAXUENUM调到20甚至更大的，理由是“想让负荷降得快一点”。结果邻区几分钟内从20%用户数冲到75%，随后邻区也触发均衡往外切，形成多小区连环切换。对用户数模式，我一般建议从5到8起步，宁可多跑几个均衡周期，也别一波把人全搬走。
4.4 A4门限的边界：基于负载的RSRP触发门限，太松太紧都出事
MLB触发的异频测量用A4事件，门限通过下面这条命令设置：
MOD INTERFREQHOGROUP: LOCALCELLID=XXX, INTERFREQHOGROUPID=0, INTERFREQLOADBASEDHOA4THDRSRP=-87;
INTERFREQLOADBASEDHOA4THDRSRP表示RSRP测量结果超过该门限才上报A4事件，后续切换才有依据。例子里给的是-87dBm，现场常用值通常在-100到-85之间。
这个门限的坑在两端。设得太大（数值接近-85或更高），A4触发难度增加，UE迟迟报不上来，异频测量形同虚设；设得太小（比如-100），随便一个异频小区信号都能上报，切换增多，误判和乒乓切换随之而来。
这里有一个基于覆盖的异频切换和基于负载的异频测量门限的配合问题。基于覆盖的异频切换门限，管的是“信号差的用户赶紧搬到异频”；而基于负载的A4门限，管的是“信号足够好的用户从高负荷搬到低负荷”。后者通常要比前者更严格，保证优先把信号有富余的用户均衡出去。如果两个门限配置混乱，会出现高负荷小区把信号边缘用户切到异频，用户感知不升反降的怪象。
5. 避坑记录：负荷均衡实施中常见的六类翻车现场
5.1 现象一：双载波部署完，第二载波始终没有用户分摊
现场表现：同覆盖两个频点，一个忙时PRB利用率80%以上，另一个长期只有20%左右，用户基本不往第二个载波上走，切换统计里异频切换次数接近于零。
原因排查：第一优先怀疑MLB总开关或异频负载平衡子开关是OFF状态。第二怀疑异频频点的MLBTARGETIND配成了NOT_ALLOWED，算法根本没有合法的异频目标。第三才是门限问题。
解决办法：依次执行MOD CELLALGOSWITCH打开异频负载平衡开关、MOD EUTRANINTERNFREQ确认目标频点为ALLOWED，再回到CELLMLB检查触发模式和门限。这三个检查做完，大部分“第二载波闲置”的问题能定位。
5.2 现象二：均衡完用户的感知反而变差，掉线率上升
现场表现：MLB动作之后，被切到异频的用户RSRP明显低于在源小区时的水平，部分用户掉线率上升，用户投诉“信号满格但网速慢”。
原因排查：盲切换方式下没有测量报告保障，用户被切到异频弱覆盖区域；或者基于测量切换方式下A4门限设得过低（比如-100dBm），信号其实不达标也触发了上报和切换。
解决办法：执行方式从盲切换改为基于UE测量切换；把INTERFREQLOADBASEDHOA4THDRSRP往高调，建议从-87起步，观察异频切换成功率和切换后RSRP分布再做微调。
5.3 现象三：负荷均衡频繁触发、反复切换，形成乒乓
现场表现：后台看负荷曲线在触发门限附近来回穿越，切换统计里异频切换次数短期激增，但两个小区的平均负荷并没有明显改善。
原因排查：LOADOFFSET设得太小，比如只设了1或2，触发门限68%、退出门限60%这个滞回带太窄，系统在临界点反复切换；或者INTERFREQLOADEVALPRD设得太短，评估周期过密，算法来不及稳定又进入下一轮判决。
解决办法：LOADOFFSET调整到5到10之间，保证触发和退出之间有足够间隔；负荷评估周期控制在10秒以上，给切换执行和负荷更新留出响应时间。
5.4 现象四：本小区负荷降下来了，目标小区被灌到过载
现场表现：一次均衡周期之后，源小区PRB从80%降到50%，目标小区从20%冲到85%，没过多久目标小区也开始往外切用户，切换链乱成一团。
原因排查：MLBMAXUENUM设得过大，单个周期切出用户数超出邻区吸收能力；或者UENUMDIFFTHD、LOADDIFFTHD设得太小，导致多个低负荷邻区同时成为目标，负荷分配缺乏主次。
解决办法：用户数模式下MLBMAXUENUM从5到8起调，等确认邻区有余量再逐步增加；负载差门限保持在10以上。观察两个周期后再决定是否加量。
5.5 现象五：空闲态UE频繁重选，小区更新信令激增
现场表现：没有明显业务波动，但小区更新、位置更新的信令量突然上升，后台跟踪发现空闲态UE在两个异频小区之间反复重选。
原因排查：空闲态负载平衡开关在相邻小区配置不一致，或者IDLEUESELFREQSCOPE配置范围过大，把覆盖质量一般的频点也纳入了空闲态均衡范围。
解决办法：全网统一空闲态负载平衡开关状态，不允许相邻小区一开一关；IDLEUESELFREQSCOPE优先采用LOADINFOFREQ，只允许空闲态均衡到负荷确实低的频点。
5.6 现象六：参数整批下发后才发现个别小区配置回退
现场表现：KPI统计发现大部分小区均衡正常，个别小区完全不触发，查询配置后发现MLB参数还是旧值。
原因排查：批量脚本执行时个别小区命令执行失败被跳过，或者后续例行脚本覆盖了下发值。
解决办法：每次参数批量修改后，养成习惯拉一遍全量查询，对比目标值和实际值两个集合是否一致。这是成本最低的后悔药。
6. 实施后的验证与参数迭代：看什么指标、怎么判断参数合不合理
6.1 验证指标不只看均衡度，还要看切换质量
参数下发不等于功能生效，需要靠指标验证。重点看三组：第一组是忙时PRB利用率和用户数的均衡度，目标是把两个同覆盖小区的忙时PRB差值收到10个百分点以内；第二组是切换质量，异频切换成功率要保持在正常区间，切换前后RSRP不能明显劣化；第三组是系统整体性能，接入成功率、用户面吞吐量在均衡前后只能上升不能下降。
我习惯按三天一个观察窗口来做对比。调参前先取三天的平均值，调整后再取三天的平均值，放在同一张表里对比。三个观测点不够，因为负荷均衡涉及切换和重选，切换用户需要一定时间在新小区稳定下来。
6.2 参数迭代坚持单变量原则，每次只动一组参数
这是最容易犯的错——一次调整里同时改了触发模式、门限、偏置、最大切换用户数，出了异常根本不知道是哪个参数引起的。我现在的做法是：先在后台网管把修改前参数查询回显存成文本，再对比修改后的回显，把改动点锁定在一组参数上。
# 修改前把查询回显保存为快照文件 # 修改后再查一次，与快照对比 grep -E "MLBTRIGGERMODE|INTERFREQMLBTHD|LOADOFFSET|MLBMAXUENUM|INTERFREQLOADBASEDHOA4THDRSRP" mlb_before.txt > cfg_before.txt grep -E "MLBTRIGGERMODE|INTERFREQMLBTHD|LOADOFFSET|MLBMAXUENUM|INTERFREQLOADBASEDHOA4THDRSRP" mlb_after.txt > cfg_after.txt diff -u cfg_before.txt cfg_after.txt这段脚本的思路很简单：把修改前后的MML查询回显统一过滤到关键参数字段，再用diff看差异。有了diff结果，就能清楚判断本次改动涉及的参数范围，回退时也知道要恢复哪些字段。脚本本身不依赖特定网管命令，只要有查询回显文本就能用。
6.3 参数调整的节奏：先门限后偏置，先覆盖后容量
参数优先级上，建议先确认覆盖类参数正确（异频覆盖切换开关、A4门限），再动容量类参数（触发门限、偏置、最大切换用户数）。如果A4门限本身就低得不合理，后面所有负荷均衡动作都建立在不可靠的测量基础上。
每次调整完，顺手把调整原因、变更值、预期效果记在工单里。等三天后的验证数据出来，能对上就保留，对不上就回退。从那以后，我每次做MLB参数调整都会强制走一遍这个流程：快照、单变量修改、三天观察、对比验证。没有这套习惯，参数越调越乱，最后连自己都不确定改过什么。希望帮到你。
本文还有配套的精品资源，点击获取
