企业官网建设流程全解析

简介：5G网络优化场景下，高负荷小区负载均衡是保障用户体验和频谱效率的关键环节。这份PDF面向移动网络优化工程师、5G运维人员及通信专业学习者，系统梳理负载均衡从测量、判决到执行的三阶段流程，并以华为设备为例给出小区级负载均衡开关、RSRP门限、触发参数等可落地的配置命令与参数解释。资源以1份PDF形式打包，整包约1.37MB，全文约5页，便于快速查阅与对照实验。已有781人学习下载。文档还包含UE选择策略、候选邻区条件及判决周期处理规则，并强调现场参数需结合实际情况调整，可帮助读者建立从原理、配置到调优的完整认知框架。

1. 5G 高负荷小区负载均衡：先分清是无线侧 MLB，不是 Nginx 那套

凌晨一点，KPI 通报群里弹出一条告警：某 5G 小区 PRB 利用率 80%，持续了快半小时。后台同事的第一反应通常是两个字：「开负载均衡」。但用户说「开负载均衡」，到底是要在机房里配 Nginx 反向代理加 upstream 权重，还是在无线网管上把用户从热小区迁到闲小区？这两个东西名字都叫负载均衡，骨子里完全不同。这份《5G高负荷小区如何开启负载均衡.pdf》讲的是RAN 侧那套，核心是 MLB（Mobility 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 0～6 占比明显偏高，说明是信道质量差导致的「被动高负荷」，此时开 MLB 把用户迁到覆盖更差的邻区，只会换一种方式掉线。我一般会加看 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 层的一部分，懂协议栈的人看这些事件会很快对上号。

真正影响均衡效果的是三个参数。CIO（Cell Individual Offset，小区个体偏移）直接给目标小区的测量结果「加分」，把切换边界往外推，CIO 每加 1～3 dB，边缘用户就更倾向切过去；TTT（Time to Trigger，触发延时时长）控制事件上报后要稳定多久才触发切换，TTT 调大能抑制乒乓；迟滞（Hysteresis）给事件加回差带，避免信号在门限附近抖动反复进出。三个参数的配合逻辑是：CIO 控制迁移量，TTT 和迟滞控制迁移稳定性。

常见参数这样起步再现场调整：

为什么不建议一上来就开大？因为 MLB 的「均衡」是靠打破小区边界实现的。CIO 给得太高，等于把更多本由源小区服务的边缘用户推向目标小区，目标小区负荷立刻上来，源小区回落，随后目标小区又变成热小区，来回折腾。更麻烦的是，同频邻区之间如果 CIO 调得过大，信号本就差不多，用户会在两个小区间反复切换，全网切换次数翻倍，用户感知却更差。

还有一点容易被忽略：MLB 和常规基于覆盖的切换共用一套移动性参数。如果目标小区只是负荷低但覆盖不占优，常规切换判决根本不会把用户分过去。所以有些同事发现 CIO 加了没效果，其实是目标小区在边界处始终不满足 A4/A5 条件。这时候先做覆盖差异化，再谈负荷均衡。移动性管理本来就是 5G 关键技术里最影响用户感知的一环，MLB 只是把传统切换策略多接了一个负荷维度。

3. 开启负载均衡的实操流程：参数配置与邻区校验

判定完毕、原理对齐，进入改参数。这一步我跟所有同事的建议一样：先截图保存现网参数，再一步步来。MLB 涉及的是移动性参数，改错一个键值对，影响的是整片区域用户的切换行为，没有后悔药就麻烦了。

3.1 网管参数配置：MLB 开关、A4 门限与 CIO 建议值

不同厂商的网管入口不同，但通常在小区级移动性管理或负载均衡菜单下能找到「负荷均衡开关」「MLB 模式」「同频/异频 MLB 使能」这类参数。华为、中兴、爱立信三代网管的命名差异不小，按下面的逻辑路径找：

1. 进入小区配置，打开负载均衡功能开关，确认支持异频 MLB；
2. 配置 A4 事件门限，先给 -105 dBm 起测；
3. 给目标邻区配置 CIO，建议 2 dB 起步；
4. 核对 TTT 和迟滞，维持 320 ms 和 2 dB；
5. 保存并激活增量包，确认命令下发成功。

这几步各有用途。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 是激活用户数门限。这些参数要按小区场景分开记录，别把商业区和高铁站用同一套。

注意：参数改完后，一定要看网管返回的下发结果。增量包下发成功不等于参数已生效，部分厂商还有等待下一个统计周期才生效的逻辑。改完 10～15 分钟后再查一遍实际生效的参数值。

3.2 目标小区筛选：邻区关系、MR 覆盖与同频干扰三重校验

参数只是手段，迁移目标小区才是胜负手。一个高负荷小区往往不止一个邻区，但并不是每个邻区都适合接用户。

我会按三步筛选。第一步，核查邻区关系。在网管里看小区级邻区列表，确认目标邻区存在且外部小区定义完整；如果邻区遗漏，用户想迁也迁不过去。第二步，取 MR 覆盖数据，检查服务小区和目标邻区是否有足够的重叠覆盖区域。重叠覆盖地带才是真正能通过切换迁移用户的区域，如果两个小区是孤岛式覆盖，切换请求会因信号达不到门限而失败。第三步，看目标小区的现网负荷和干扰。目标小区自己都快 50% 了，迁移过去只会让第二个小区进高负荷清单；对同频邻区还要额外关注 SSB 频点重叠情况，同频重叠覆盖区域过大时，负载均衡会导致干扰抬升、MCS 下跌，指标两边都难看。

邻区关系这一步最常见的坑是 ANR 自动加出来的同频邻区。ANR 本意是自动补邻区，但它补出来的邻区不一定适合做 MLB 迁移目标。我会在开 MLB 前把自动加邻区的策略收紧，必要时关闭异频 ANR，改成人工按规划表核查。自动补的邻区做常规切换够用，做负荷均衡就可能给你「盲迁」。

这三步落成一张校验表，给后台同事核对用：

选好目标小区后，再回到上一节的参数表，只针对这一个目标邻区配 CIO，而不是把所有邻区都统一加偏移。局部的负载均衡从来都是「点对点」的优化，不是「一把梭」对全网调。

4. 负载均衡排查避坑：乒乓切换、掉线与参数不生效

MLB 上线后，问题通常在三个时间点出现：改完半小时内的即时异常，多半是参数生效问题；当晚忙时的话统异常，多半是乒乓切换；三天后的 KPI 周报异常，基本跑不掉干扰或掉线。排查时先按时间轴定位是哪一类，再动手。

4.1 乒乓切换与掉线率上升：两个最常见的调整过度

先说调整过度造成的两类问题，它们都直接和 CIO、TTT 的取值有关。

踩坑一：切换次数暴增，负荷没降。

现象：开启 MLB 后，小区间切换请求次数翻了将近一倍，但源小区 PRB 利用率纹丝不动，目标小区负荷反而跟着涨。 原因：CIO 加太大，A4 门限又放得太低，边缘信号波动 3 dB 的用户反复触发迁移，形成乒乓切换。每次切换都伴随测量重配和随机接入，资源照样被消耗，等于白切了。 解决：把 CIO 降到 1～2 dB，TTT 从 160 ms 调回 320 ms，迟滞维持 2 dB 起步；再观察两小时话统，如果切换次数仍在高位，进一步把 A4 门限收紧到 -100 dBm。调整原则是一次只动一个参数，等两个统计周期再评估。

踩坑二：掉线率上升，无线链路失败变多。

现象：目标小区掉线率涨了 0.3 个百分点以上，用户投诉「一切过去就没网」。 原因：目标小区覆盖有空洞，或者源小区迁移过去的方向根本没有重叠覆盖。切换时的 RACH 冲突和重配失败都可能在切换点爆发。 解决：把 MR 覆盖图拉出来，凡是目标小区在迁移边缘覆盖差的，一律移出候选；同时核查目标小区的随机接入资源是否充足。这个问题的根因经常不在参数而在选区，参数怎么回退都没用，换目标小区才是正解。

4.2 参数不生效与同频干扰：检查顺序决定翻车概率

参数没生效和同频干扰是另外两类问题，它们的坑点不在参数本身，而在检查顺序。

踩坑三：参数改完，话统里一条负载均衡切换都没有。

现象：MLB 开关已开、CIO 已配，但统计周期内零迁移，高负荷依旧。 原因：一是增量包没有真正激活，网管显示下发成功但现网实际未生效；二是异频测量对象没配上，A4 事件没有可测的邻区频点，事件根本触发不了；三是 A4 门限设得比目标小区实际 RSRP 还高，条件永远不成立。 解决：先查开关生效状态，再看异频测量配置和频点优先级，最后核对 A4 门限是否高于目标小区 RSRP。检查顺序按「开关 → 测量对象 → 门限 → CIO」走，不要一上来就怀疑 CIO。

踩坑四：同频邻区之间开了 MLB，SINR 和 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(f"PRB 利用率: {before[0]:.1f}% -> {after[0]:.1f}%") print(f"RRC 用户峰值: {before[1]:.0f} -> {after[1]:.0f}")

脚本只做两件事：读 CSV 求 PRB 平均利用率、取 RRC 用户峰值，然后打印。数据列名是 prb_util 和 rrc_users，如果你网管导出的列名不一样，改 DictReader 对应的字段名就行。前后两份文件放在同一目录，方便保留历次记录，下次同类小区可以直接复用同一套脚本。

趋势确认稳定后，微调阶段遵循「一次只动一个参数」的铁律。今天只调 CIO，明天再看同期话统；TTT 和迟滞不要同一天同时改，否则出了问题分不清是谁引起的。参数收敛后把最终配置快照和起调前快照一起归档，作为该场景的参数模板。

从那以后我每次做 5G 负载均衡，都强制走一遍「判负荷 → 查邻区 → 调参数 → 盯趋势」四步，再也不会跳过邻区校验直接去加 CIO——那是我交过的学费里最贵的一笔。希望帮到你。

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