5G自组织网络：基站如何做到自配置、自优化、自愈

想象你是一名新入职的基站工程师，第一天上班就接到任务：给50个新开站的基站配置邻区关系。每个基站平均有30个邻区，你需要在工参表里逐一比对经纬度、方位角、频段信息，手动填入每个邻区的PCI、频点、CGI……按经验，一个熟练工程师配置一个基站的邻区大约需要20分钟，50个站就是将近17个小时——而且，只要一个数字抄错，就可能引发用户掉话投诉。

这就是自组织网络（SON，Self-Organizing Network）要解决的核心问题。让基站自己配自己、自己优化自己、自己修复自己——把工程师从重复劳动中解放出来，同时减少人为错误。

一、SON的三大支柱：自配置、自优化、自愈

SON不是一个单一功能，而是一个框架。它包含三大类功能，分别对应基站生命周期的不同阶段：

graph TB
    SON["SON自组织网络"] --> SC["自配置<br/>Self-Configuration"]
    SON --> SO["自优化<br/>Self-Optimization"]
    SON --> SH["自愈合<br/>Self-Healing"]

    SC --> PCI["PCI自分配"]
    SC --> AAP["自动邻区发现ANR"]
    SC --> APC["自动物理信道配置"]

    SO --> MRO["移动鲁棒性优化MRO"]
    SO --> MLB["移动负载均衡MLB"]
    SO --> CCO["覆盖与容量优化CCO"]
    SO --> RO["RACH优化"]
    SO --> ESC["节能优化"]

    SH --> COD["小区故障检测"]
    SH --> COC["小区故障补偿"]

    style SON fill:#1a73e8,color:#fff
    style SC fill:#34a853,color:#fff
    style SO fill:#fbbc04,color:#333
    style SH fill:#ea4335,color:#fff

为什么5G比4G更需要SON？ 因为5G网络的复杂度呈指数级增长：基站数量翻倍、频段从sub-6GHz扩展到毫米波、 Massive MIMO引入了波束级管理、NSA/SA双模带来跨制式邻区管理。如果还靠人工配置，运维成本将不可承受。

二、SON的三种部署架构

在深入每个功能之前，先理解SON的部署方式，因为这直接决定了功能的实时性和准确性。

graph LR
    subgraph "集中式 C-SON"
        OAM["OAM/SON服务器"] -->|统一下发策略| GNB1["gNB"]
        OAM -->|统一下发策略| GNB2["gNB"]
    end

    subgraph "分布式 D-SON"
        GNB3["gNB"] <-->|Xn接口直接协调| GNB4["gNB"]
        GNB3 -->|本地决策| LOC1["本地算法"]
        GNB4 -->|本地决策| LOC2["本地算法"]
    end

    subgraph "混合式 H-SON"
        OAM2["OAM"] -->|全局策略| GNB5["gNB"]
        OAM2 -->|全局策略| GNB6["gNB"]
        GNB5 <-->|实时交互| GNB6
        GNB5 -->|本地快速优化| LOC3["本地算法"]
    end

打个比方：C-SON像总部经理——看得远但反应慢；D-SON像门店店长——反应快但视野有限；H-SON则是总部给店长定KPI，店长在框架内自主决策——兼顾全局和实时性。5G中多数SON功能采用混合式部署。

三、自配置：PCI自动分配——给基站发"身份证号"

什么是PCI？

PCI（Physical Cell Identity，物理小区标识）是基站的"短身份证号"。手机在搜索小区时，首先通过主同步信号（PSS）和辅同步信号（SSS）解出PCI，才能进一步读取系统信息。

5G NR的PCI范围是 0~1007（共1008个），而4G LTE只有 0~503（共504个）。PCI由两部分计算得到：

$$PCI = 3 \times N_{SSS_ID} + N_{PSS_ID}$$

其中 $N_{PSS_ID} \in {0, 1, 2}$，$N_{SSS_ID} \in {0, 1, ..., 335}$。

PCI冲突与混淆

虽然1008个PCI看起来不少，但在一个城市的几万个基站中，PCI必然要重复使用。问题出在"重复使用的方式"上：

graph TD
    subgraph "PCI冲突"
        A1["小区A<br/>PCI=42"] ---|"同频邻区"| B1["小区B<br/>PCI=42"]
        U1["手机"] -->|"都能收到信号<br/>无法区分"| A1
        U1 -->|"都能收到信号<br/>无法区分"| B1
    end

    subgraph "PCI混淆"
        C1["小区C"] -->|"邻区"| D1["小区D<br/>PCI=100"]
        C1 -->|"邻区"| E1["小区E<br/>PCI=100"]
        F1["手机想切换到PCI=100<br/>但不知道是D还是E"]
    end

PCI自配置流程

新基站上电后，PCI自动分配的过程：

1. OAM下发PCI候选池：网管为新站分配一个可用PCI列表
2. 新站扫描周围环境：通过自身接收机或让UE上报，检测周围小区的PCI
3. 冲突/混淆检测：将候选PCI与检测到的邻区PCI比对，排除冲突和混淆的PCI
4. 选择最优PCI：从剩余候选中选一个（通常选择与最强邻区PCI模3不同的值，避免PSS冲突导致的参考信号干扰）
5. 确认并生效：向OAM报告选定的PCI，正式开始广播

$$\text{优选条件: } PCI_{\text{new}} \mod 3 \neq PCI_{\text{strongest_neighbor}} \mod 3$$

实战经验：PCI模3（或模6、模30）冲突是现网中最常见的干扰源之一。很多工程师在处理"某个区域速率一直上不去"的投诉时，最终发现是两个邻区PCI模3相同，导致参考信号互相干扰。SON的PCI自优化功能会持续监测这类问题并自动调整。

四、自优化核心：ANR——基站如何"自动认识邻居"

ANR（Automatic Neighbor Relation，自动邻区关系）是SON中最实用、影响最广的功能。在2G/3G时代，邻区关系全靠人工配置；到了4G/5G，ANR让基站自动发现和管理邻居。

为什么邻区关系如此重要？

手机从A小区移动到B小区时需要执行切换，而切换的前提是：A小区必须知道B小区的存在。如果邻区漏配，手机走到边缘也无法切换，最终信号越来越弱——掉话。

传统人工配邻区的痛点： - 新站开通时，需要工程师手动添加所有邻区 - 周围新增基站时，老站的邻区表也要更新 - 5G时代还有跨制式邻区（5G↔4G），更复杂 - 网络一旦变化（比如某个小区方位角调整），邻区关系就可能失效

ANR的工作流程

sequenceDiagram
    participant UE as 手机(UE)
    participant gNB as 服务基站(gNB)
    participant Tgt as 目标基站(Target gNB)
    participant OAM as 网管(OAM)

    Note over UE,gNB: 步骤1: 手机测量并上报未知PCI
    gNB->>UE: 下发测量配置(含ANR触发条件)
    UE->>UE: 测量到邻区信号PCI=88
    UE->>gNB: 上报测量报告(PCI=88,未知小区)

    Note over gNB: gNB发现PCI=88不在邻区表NRT中

    Note over UE,gNB: 步骤2: gNB指示UE读取目标小区的CGI
    gNB->>UE: 下发CGI读取指示(读取PCI=88的SIB1)
    UE->>UE: 在gNB分配的gap期间去读SIB1
    Note over UE: 解码NCGI=<MCC><MNC><gNB-ID><Cell-ID>
    UE->>gNB: 上报NCGI完整信息

    Note over gNB,OAM: 步骤3: 更新邻区表并建立Xn连接
    gNB->>gNB: 在NRT中创建新条目(NCGI→PCI=88)
    gNB->>OAM: 上报新发现的邻区关系
    gNB->>Tgt: 通过Xn接口获取目标小区参数
    Tgt->>gNB: 返回频段、带宽、SSB配置等

    Note over gNB: 步骤4: 启用切换
    gNB->>gNB: 将邻区标记为"允许切换"

关键细节解读：

为什么需要UE去读CGI？ 因为PCI只有1008个值，必然重复，仅凭PCI无法唯一标识一个小区。而NCGI（NR Cell Global Identity）是全球唯一的，格式为：<MCC><MNC><gNB ID><Cell ID>，比如 46000-00-123456-0。gNB拿到NCGI后才能精确识别这是哪个小区。

UE什么时候去读SIB1？ gNB会配置一个"测量间隙"（measurement gap），在这段时间内UE暂时不与服务小区通信，转而去接收目标小区的广播信息。这个gap通常为6ms，周期为40ms或80ms。读CGI的过程会短暂影响用户数据传输，所以ANR不能对同一UE频繁触发。

ANR也有"删除"功能：如果一个邻区关系长期没有任何切换发生（比如超过7天），ANR可以自动将其从NRT中移除，避免邻区表膨胀。

ANR在5G中的特殊考虑

五、自优化核心：MRO——让切换不再"早退"或"迟到"

MRO（Mobility Robustness Optimization，移动鲁棒性优化）专门解决切换参数不合理导致的问题。通俗地说，就是自动调节"什么时候该切换"这个判断标准。

切换的三种失败模式

graph TD
    HO["切换问题"] --> TL["切换太晚<br/>Too-Late HO"]
    HO --> TE["切换太早<br/>Too-Early HO"]
    HO --> WC["切换到错误小区<br/>Wrong-Cell HO"]

    TL --> TL1["手机已经快掉线了才触发切换"]
    TL --> TL2["结果：在源小区发生RLF掉话"]

    TE --> TE1["手机信号还很好就开始切换"]
    TE --> TE2["结果：切过去又弹回来，乒乓切换"]

    WC --> WC1["切换到了错误的目标小区"]
    WC --> WC2["结果：需要二次切换，增加时延和失败率"]

MRO如何检测问题？

MRO的核心数据来源是RLF报告（Radio Link Failure Report）和切换报告（Handover Report）。

"切换太晚"的判定逻辑：

手机在小区A发生RLF掉话，重新连接到小区B。如果从RLF报告中发现：掉话前小区A的信号已经很弱（低于某个门限），而且小区B的信号很好——这就说明切换触发得太晚了。

MRO检测到这种情况后，会自动减小切换迟滞值（Hys）或缩短Time-to-Trigger（TTT），让下次切换提前触发。

MRO调节的参数

$$\text{切换触发条件: } Mn + O_{fn} + O_{cn} - Hys > Ms + O_{fs} + O_{cs} + Off$$

其中： - $Mn$：邻区测量值（RSRP/RSINR） - $Ms$：服务小区测量值 - $O_{fn}$：邻区频率偏移 - $O_{fs}$：服务小区频率偏移 - $O_{cn}$：邻区特定偏移（CIO，Cell Individual Offset） - $O_{cs}$：服务小区特定偏移 - $Hys$：迟滞值 - $Off$：事件偏移量

MRO通过调整 $Hys$、$TTT$、$O_{cn}$（CIO）三个关键参数来优化切换行为：

实战经验：MRO最常见的调试场景是"高速场景乒乓切换"。在高铁沿线，手机高速移动，但切换参数如果设得太激进，手机可能在两个小区间反复切换——每次切换都有几十毫秒的数据中断。MRO会通过分析切换历史，自动识别乒乓模式，增大迟滞值来稳定切换行为。

六、自优化核心：MLB——让忙的小区别那么忙，闲的别闲着

MLB（Mobility Load Balancing，移动负载均衡）解决的是"旱的旱死、涝的涝死"的问题。

为什么需要负载均衡？

在5G网络中，用户分布极不均匀： - 商业区中午时段PRB利用率可能超过90% - 相邻的住宅区同时段利用率可能只有20% - 演唱会、体育赛事会制造突发性热点

如果不做负载均衡，热点小区的用户体验急剧恶化（速率下降、时延增大），而周围的小区却在"晒太阳"。

MLB的工作机制

sequenceDiagram
    participant A as 热点小区A<br/>(负载90%)
    participant B as 邻区B<br/>(负载20%)
    participant Xn as Xn接口

    Note over A: 阶段1: 负载信息交换
    A->>Xn: 上报负载信息(PRB利用率=90%,<br/>在线UE数=180)
    Xn->>B: 转发小区A负载
    B->>Xn: 上报负载信息(PRB利用率=20%,<br/>在线UE数=35)
    Xn->>A: 转发小区B负载

    Note over A,B: 阶段2: 负载均衡决策
    A->>A: 判断自身过载<br/>识别可转移的边缘UE
    A->>A: 选择目标小区B<br/>计算需要调整的切换参数

    Note over A,B: 阶段3: 参数调整与转移
    A->>A: 增大对小区B的CIO偏移<br/>(如从0dB调到+3dB)
    A->>B: 通知参数调整请求
    B->>A: 确认接受参数调整

    Note over A,B: 阶段4: 用户迁移
    A->>A: 边缘UE的测量报告<br/>触发向小区B的切换
    Note over A,B: 部分用户平滑切换到小区B

    Note over A,B: 阶段5: 负载稳定后恢复
    A->>A: PRB利用率降到65%→停止调整
    A->>B: 通知恢复原始切换参数
    B->>A: 确认恢复

MLB的关键在于：不是强制切换用户，而是通过微调切换参数，让边缘用户"自然地"倾向于切换到轻载小区。这种方式对用户是透明的，不会造成业务中断。

负载信息交互的内容（通过Xn接口的RESOURCE STATUS REPORT）：

七、RACH优化——让"敲门"更高效

手机要接入基站，第一步是发送随机接入前导码（Preamble）——就像敲门。RACH优化的目标是让这个"敲门"过程更高效，减少碰撞和等待。

RACH有什么问题？

RACH优化的核心逻辑：

基站收集RACH统计信息（碰撞率、接入成功率、接入时延），自动调整以下参数：

• 前导码分组：将64个前导码分为"竞争"和"非竞争"两组，高负载时增大竞争组比例
• 功率攀升步长：如果初次接入失败，下一次发送功率增加多少dB
• 回退参数：碰撞后等待多长时间再重试

$$P_{\text{PRACH}} = \min{P_{\text{CMAX}}, P_{\text{target}} + \text{PL} + (N_{\text{retry}} - 1) \times \Delta P}$$

其中 $P_{\text{CMAX}}$ 是UE最大发射功率，$P_{\text{target}}$ 是目标接收功率，$\text{PL}$ 是路径损耗估计值，$\Delta P$ 是功率攀升步长，$N_{\text{retry}}$ 是重试次数。

八、自愈合：基站"生病"了怎么办

自愈合（Self-Healing）是SON中最"智能"的部分。它包含两个子功能：小区故障检测（COD）和小区故障补偿（COC）。

故障检测（COD）

系统通过多种信号判断一个小区是否"宕机"：

故障补偿（COC）

检测到小区故障后，周围正常小区会自动调整参数来"补位"：

1. 增大发射功率：周围小区提升参考信号功率和业务信道功率
2. 调整天线倾角：通过电调（RET）调整下倾角，扩大覆盖范围
3. 调整波束权重（5G Massive MIMO）：展宽波束覆盖故障区域
4. 修改切换参数：降低边缘门限，留住原本属于故障小区的UE

graph TD
    subgraph "正常状态"
        A1["小区A<br/>正常覆盖"]
        B1["小区B<br/>正常覆盖"]
        C1["小区C<br/>正常覆盖"]
    end

    subgraph "故障发生"
        A2["小区A<br/>⚡故障!"]
        B2["小区B"]
        C2["小区C"]
        D2["覆盖空洞!"]
    end

    subgraph "自动补偿"
        A3["小区A<br/>⚡故障"]
        B3["小区B<br/>功率↑<br/>倾角调整"]
        C3["小区C<br/>功率↑<br/>波束展宽"]
        D3["补偿覆盖<br/>网络可用"]
    end

    A1 --> A2
    B1 --> B2
    C1 --> C3

实战注意点：补偿覆盖是一种"临时方案"，不是长久之计。因为周围小区增大功率意味着更大的干扰和更快的电量消耗（对电池供电的小站尤为重要）。SON系统会在OAM告警通知工程师维修的同时，持续执行补偿直到故障修复。

九、5G SON与AI的融合趋势

5G Release 18/19引入了AI/ML for RAN的概念，SON正在从"基于规则"走向"基于学习"：

SON功能间的冲突问题：这是工程实践中最头疼的问题之一。比如： - MRO增大了迟滞值来防止乒乓切换 - 但MLB同时减小了迟滞值来促进负载均衡 - 两个功能"打架"，效果互相抵消

解决方案是引入SON协调器（SON Coordinator），对所有SON功能的参数调整进行统一仲裁，确保不会出现矛盾指令。

十、工程师实战指南：SON在现网中的应用

1. ANR调试

典型场景：用户投诉"走到某个区域就掉话"，排查发现邻区漏配。

排查步骤： - 查看NRT表，确认问题区域是否有漏配邻区 - 检查ANR功能是否开启（部分运营商出于稳定性考虑，只开启ANR自动添加，不允许自动删除） - 检查UE测量配置是否正确（频间/制式间ANR需要配置对应的测量gap） - 查看ANR日志，确认是否有CGI读取失败的记录

常见陷阱：ANR读取CGI需要UE处于连接态且基站分配测量gap。如果网络负载很高、gap资源紧张，ANR可能迟迟无法发现新邻区。

2. MRO调优

典型场景：某段高速路上频繁掉话或乒乓切换。

排查步骤： - 收集RLF报告，分析掉话位置和原因 - 查看MRO日志中"Too-Late"和"Too-Early"事件的统计 - 检查MRO调整后的参数是否生效（注意MRO有调整幅度限制，不会一步到位） - 对于高速场景，可能需要手动设置高速场景专用的切换参数模板

3. MLB监控

典型场景：某个区域用户速率突然下降，但小区的PRB利用率并不高。

可能原因：MLB可能过于激进地把用户推到了信号质量较差的小区。负载均衡不等于用户体验最优——一个信号较弱的轻载小区，用户体验可能比一个信号较好的忙小区更差。

监控指标：不仅要看负载均衡度，还要看MLB执行后的用户吞吐量变化。如果负载降了但速率也降了，说明MLB策略需要优化。

常见问题

Q: ANR发现邻区后，是否立刻允许切换？ A: 不一定。很多运营商配置为"ANR发现→自动添加→人工审核后允许切换"的两步模式，防止误添加不合适的邻区关系（如跨地市的远距离邻区）。

Q: MRO和手动优化切换参数，哪个优先？ A: MRO是自动调优，调整幅度有限且渐进式（每次调0.5~1dB）。对于已知问题场景（如高铁、海域覆盖），建议先手动配置专用参数模板，再让MRO在模板基础上做微调。手动配置的参数MRO不会覆盖。

Q: SON功能间的冲突怎么解决？ A: 3GPP定义了SON Coordination机制。实际设备中通常通过"功能优先级"来解决——比如规定MRO的切换参数调整优先级高于MLB。此外，部分厂商提供"SON冲突检测"功能，当检测到多个SON功能同时调整同一参数时会触发告警。

Q: 开启ANR后还需要人工规划邻区吗？ A: 建网初期仍建议做基础的邻区规划。ANR擅长发现"漏掉"的邻区，但它的发现速度取决于UE的测量上报，新建站初期UE较少时可能无法快速发现所有邻区。成熟网络可以完全依赖ANR自动维护。

Q: 5G的SON和4G的SON有什么主要区别？ A: 核心原理相同，但5G SON需要处理更多维度：波束级管理（Massive MIMO）、多制式双连接（EN-DC/NR-DC）、更灵活的帧结构参数、以及更大的PCI空间。此外，5G Release 18引入了L1/L2移动性（LTM），为SON带来了新的优化空间。

参考来源

2. 3GPP SON技术专题页 — 3GPP官方SON标准进展
3. Comprehensive survey on self-organizing cellular network approaches — SON算法综述论文
4. 5G SON MRO优化PoC - GitHub — MRO算法实现参考
5. 5G NR智能优化：MRO, MLB, RACH与MDT技术详解 - CSDN — SON功能技术解析

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。