<!-- title: 5G UE配置更新命令信令机制拆解 -->
<!-- domain: core-network -->

# 5G UE 配置更新命令（UCU）信令全链拆解

## 一、为什么需要"配置更新命令"这条信令

5G UE 在初始注册（Registration）成功后，AMF 会把一套"注册态上下文"下发给 UE——包括临时身份 5G-GUTI、注册区（TAI List）、允许切片 Allowed NSSAI、NITZ 时间/时区、MICO 模式、运营商定义的接入类别等。然而，UE 处于已注册态（RM-REGISTERED）期间，网络侧的签约数据、切片配置、移动性限制、灾难漫游策略会**动态变化**。如果每一次配置变化都强制 UE 重新发起一次完整的 Registration Procedure，信令开销和时延都不可接受。

为此，3GPP 在 TS 23.502 第 4.2.4 节定义了 **UE Configuration Update（UCU）过程**：这是一个**纯网络侧（AMF）发起**的轻量级 NAS 过程，用于在**不要求 UE 重新注册的前提下**，把变化了的接入与移动性管理相关参数推送给 UE；只有在配置变化确实影响到 UE 当前连接时，AMF 才通过 Configuration Update Indication 指示 UE"随后发起一次移动性注册更新"。

需要特别强调一个常见误解：UCU（4.2.4.2）与 UE Policy（4.2.4.3，URSP 策略下发）是**两个不同的过程**，虽然都借 NAS 通道下发。UCU 由 AMF 主导、更新"接入与移动性参数"；UE Policy 由 PCF 主导、更新"UE 策略（URSP）"，二者消息体、触发方、确认语义都不同。本文聚焦前者。

> 注：Steering of Roaming（SoR）信息虽然也承载在 CONFIGURATION UPDATE COMMAND 消息的 SoR 透明容器中下发，但它是一个独立的过程（TS 23.122 / TS 24.501），本文不展开。

---

## 二、UCU 到底能更新哪些配置（TS 23.502 4.2.4.1）

理解 UCU 的第一步，是搞清楚它"管什么、不管什么"。下表按类别归纳了 4.2.4.1 中定义的 UE 配置范围：

| 配置类别 | 典型 IE | 决定/提供方 | 说明 |
|---|---|---|---|
| 身份与注册区 | 5G-GUTI、TAI List（注册区） | AMF | 5G-GUTI 重分配、RA 调整 |
| 网络切片 | Allowed NSSAI 及映射、Partial Allowed NSSAI 及映射、Configured NSSAI 及映射、Rejected S-NSSAI、NSSRG、NSAG、切片使用策略、替代 S-NSSAI 映射 | AMF（基于 UDM/NSSF） | 切片动态调整的核心通道 |
| 移动性限制 | Mobility Restrictions（含 Service Area、Forbidden TAI、CAG 列表） | AMF（基于 UDM） | 同步给 NG-RAN 用于接入控制 |
| 本地数据网 | LADN Information（每 DNN / 每 S-NSSAI） | AMF | LADN 可用性/服务区更新 |
| 节能与覆盖 | MICO 模式、Enhanced Coverage Restriction、Service Interval Time | AMF | CIoT/覆盖受限场景 |
| 接入控制 | Operator-defined Access Category Definitions | AMF | TS 22.261 统一接入控制 |
| RACS | PLMN-assigned UE Radio Capability ID（及其删除指示） | AMF（配合 UCMF） | TS 23.501 5.4.4.1a |
| 时间同步 | NITZ、UE Re-connection Indication（NG-RAN 时间同步变化）、Maximum Offset of Time | AMF | TS 23.501 4.15.9.4 / 5.4.13.5 |
| 优先级与服务 | MPS/MCX 优先级、UAS 服务指示、SMS Subscription | AMF（基于 UDM） | 优先级变化通知 |
| 灾难漫游 | 灾难情况下使用的 PLMN 列表、灾难漫游等待范围 | AMF | TS 23.501 5.40.5 |
| MBSR/IAB-UE | MBSR 授权信息、S-NSSAI 位置可用性信息 | AMF | TS 23.501 5.35A.4 |

**设计要点**：UCU 的触发源于以下几类事件——UE 移动性变化、网络策略变更、来自 UDM 的 `Nudm_SDM_Notification`（签约数据变更）、切片配置变化（NSSRG/NSAG/切片使用策略更新）、切片注销非活动定时器到期移除 S-NSSAI、NSSAA 认证后被 AAA 撤销授权、需要分配 UE Radio Capability ID 等。

---

## 三、核心信令时序（TS 23.502 图 4.2.4.2-1）

下图给出一条完整的、带确认的 UCU 流程，涵盖 **CM-IDLE 寻呼分支**与**CM-CONNECTED 直送分支**，以及随后的**条件性 N2 更新、PDU 会话释放、重注册**等分支：

```mermaid
sequenceDiagram
    autonumber
    participant UE
    participant NG as NG-RAN(gNB)
    participant AMF
    participant UDM
    participant SMF

    Note over AMF: 步骤0：AMF 决定更新 UE 配置<br/>(签约变更/切片变化/移动性变化等)

    alt UE 处于 CM-IDLE
        AMF->>NG: N2 Paging（或等待UE进入CM-CONNECTED）
        NG->>UE: Uu 寻呼
        UE->>NG: Service Request
        NG->>AMF: N2 Initial UE Message / NAS(Service Request)
        Note over UE,AMF: 进入 CM-CONNECTED（网络触发业务请求，TS 23.502 4.2.3.3）
    end

    Note over AMF: 构造 CONFIGURATION UPDATE COMMAND
    AMF->>NG: NGAP Downlink NAS Transport<br/>(NAS: CONFIGURATION UPDATE COMMAND + 可选 Mobility Restrictions/RFSP/Target NSSAI)
    NG->>UE: RRC DLInformationTransfer(NAS 命令)
    Note over UE: UE 更新本地配置<br/>(GUTI/RA/Allowed NSSAI/MICO等)

    opt 命令要求确认（除仅含 NITZ 外均要求）
        UE->>NG: RRC ULInformationTransfer(NAS: CONFIGURATION UPDATE COMPLETE)
        NG->>AMF: NGAP Uplink NAS Transport(NAS: COMPLETE)
        AMF->>AMF: 停止确认重传定时器 T3555
    end

    opt 步骤2b：CAG/切片订阅已变更
        AMF->>UDM: Nudm_SDM_Info（通知 UE 已接收并应用）
    end

    opt 步骤2c：AS 侧需同步
        AMF->>NG: UE Context Modification<br/>(新 UE Identity Index / UE Radio Capability ID / Mobility Restrictions)
        Note right of NG: 用于 RRC_INACTIVE 寻呼帧计算与接入控制
    end

    opt 步骤3b：有 S-NSSAI 不再被允许
        AMF->>SMF: 释放对应 PDU 会话(4.3.4.2)
    end

    opt 步骤3c+4：变化影响当前连接，需重注册
        AMF->>NG: AN Release（释放 NAS 信令连接）
        NG->>UE: RRC Release → UE 进入 CM-IDLE
        Note over UE: 进入 CM-IDLE 后发起移动性注册更新<br/>(Initial UE Message 不带 5G-S-TMSI/GUAMI，按 TS 23.501 5.15.9 带 Requested NSSAI)
        UE->>AMF: Mobility Registration Update
    end
```

### 关键步骤逐条解析

- **步骤 0（触发判定）**：AMF 内部决策"是否需要更新 UE 配置"。若 UE 处于 CM-IDLE，AMF 有两种选择——**等待** UE 自行进入 CM-CONNECTED（如下行数据触发的 Service Request），或**主动发起网络触发业务请求**（Network Triggered Service Request，TS 23.502 4.2.3.3）把 UE 呼叫出来。具体选哪种取决于网络实现（规范注 1 明确这一点）。这是 UCU 抓包时"命令前先出现寻呼"的根因。

- **步骤 1（下行命令）**：AMF 构造 **CONFIGURATION UPDATE COMMAND**（TS 24.501 第 8.2.18 节），经 NGAP **Downlink NAS Transport** 发给 NG-RAN，NG-RAN 通过 RRC **DLInformationTransfer** 透传给 UE。该消息的安全头类型为"完整性保护且加密"——因为 UE 已处于注册态，必有 NAS 安全上下文。AMF 可在承载该命令的 N2 消息中顺带携带 Mobility Restrictions、RFSP Index、目标 NSSAI（用于切片专用频段重定向），让 NG-RAN 同步更新。

- **步骤 2a（确认）**：规范规定，**AMF 应对几乎所有 UCU 命令请求确认，唯独"仅下发 NITZ"不要求确认**。具体必须请求确认的包括：NSSAI 类信息、5G-GUTI、TAI List、移动性限制、LADN、MICO、运营商定义接入类别定义、UE Radio Capability ID、S-NSSAI 位置可用性信息、SMS 订阅。UE 处理后回送 **CONFIGURATION UPDATE COMPLETE**。

- **步骤 2b（向 UDM 回执）**：若更新涉及 CAG 信息或网络切片订阅变更指示，AMF 通过 `Nudm_SDM_Info` 通知 UDM"UE 已接收并应用"——这是为了让 UDM/UDR 维护准确的签约一致性。

- **步骤 2c（向 NG-RAN 同步 AS 侧信息）**：这是 UCU 最容易被忽视的一环。当 5G-GUTI 被重分配时，AMF 在收到确认后必须把**新的 UE Identity Index**（5G-S-TMSI 的一部分）告知 NG-RAN，因为 NG-RAN 在 RRC_INACTIVE 状态下用该索引计算寻呼帧（TS 38.304）。同理，UE Radio Capability ID、更新的 Mobility Restrictions 也要在此同步给 NG-RAN。

- **步骤 3a/3b/3c+4（重注册判定）**：AMF 根据配置变化是否影响"UE 与 AMF 的现有连接"，决定是否指示 UE 重注册：
  - **3a**：仅更新 MICO 模式、增强覆盖限制等"需在注册时协商的 NAS 参数"——UE 确认后立即发起注册重协商。
  - **3b**：新 Allowed NSSAI 不影响现有连接（如只是切片集合扩张）——UE 立即可用新切片，无需重注册；但若某些已建立 PDU 会话的 S-NSSAI 不再被允许，AMF 指示 SMF 按 4.3.4.2 释放这些会话。
  - **3c+4**：变化影响现有连接——AMF 指示 UE 重注册，收到确认后**触发 AN Release**，UE 进入 CM-IDLE 再发起移动性注册更新。

---

## 四、Configuration Update Indication：一条 IE 决定 UE 行为

UCU 命令中真正"指挥"UE 后续动作的，是 **Configuration Update Indication** 这个 IE（TS 24.501）。它语义上携带三个关键标志，下图刻画了 UE 收到命令后的决策逻辑：

```mermaid
flowchart TD
    A[UE 收到 CONFIGURATION UPDATE COMMAND] --> B{是否请求确认 ACK?}
    B -- 是 --> C[回送 CONFIGURATION UPDATE COMPLETE<br/>AMF 侧停 T3555]
    B -- 否 --> D[不回 COMPLETE]
    C --> E{是否指示 Network Slicing<br/>Subscription Change?}
    E -- 是 --> F[本地清除所有 PLMN 的<br/>全部切片配置并按新信息重建]
    E -- 否 --> G[保留现有切片配置]
    F --> H{是否指示 Registration Requested?}
    G --> H
    D --> H
    H -- 是 --> I[按 3a/3b/3c+4 分支<br/>发起移动性注册更新]
    H -- 否 --> J[立即应用新配置<br/>流程结束]
```

| Indication 标志 | 含义 | 触发 UE 行为 |
|---|---|---|
| Acknowledgement（ACK）requested | 是否要求 UE 回 COMPLETE | 除仅 NITZ 外均置位；置位则 AMF 启动 T3555 重传 |
| Network Slicing Subscription Change | 切片签约是否变更 | UE 清除所有 PLMN 的全部网络切片配置并重建 |
| Registration Requested | 是否需要 UE 随后重注册 | 决定 3a/3b/3c+4 分支与 AN Release |

特别地，当 AMF 同时下发新的 **Configured NSSAI** 时，规范要求它一并携带**新的 Allowed NSSAI**（及映射）——除非 AMF 在更新签约 S-NSSAI 后无法确定新 Allowed NSSAI（此时命令中不含任何 Allowed NSSAI，强制 UE 重注册后由新注册过程确定）。

---

## 五、NAS 消息 IE 结构与确认矩阵（TS 24.501 8.2.18）

CONFIGURATION UPDATE COMMAND 是一条"按需组装"的消息，AMF 只放本次需要更新的 IE。下表列出工程实践中最常出现的 IE 及其确认要求：

| IE | 含义 | 是否要求 UE 确认 |
|---|---|---|
| Configuration Update Indication | ACK/重注册/切片订阅变更指示 | — |
| 5G-GUTI | 新临时身份 | 是 |
| TAI List（Registration Area） | 新注册区 | 是 |
| Allowed NSSAI + Mapping | 允许切片及映射 | 是 |
| Partial Allowed NSSAI（及 RA 内 TAI List） | 部分允许切片 | 是 |
| Configured NSSAI（及映射） | 配置切片 | 是 |
| Rejected S-NSSAI（及部分拒绝 RA） | 拒绝切片 | 是 |
| NSSRG / NSAG | 切片漫游组 / 切片 AS 组 | 是（NSAG 必须确认） |
| NITZ | 网络标识与时区 | **否**（唯一不要求确认） |
| Mobility Restrictions | 移动性限制 | 是 |
| LADN Information | 本地数据网 | 是 |
| MICO Indication | MICO 模式 | 是 |
| Operator-defined Access Category Definitions | 运营商接入类别 | 是 |
| PLMN-assigned UE Radio Capability ID | 无线能力 ID | 是 |
| SMS Subscription Indication | 短信订阅 | 是 |
| Maximum Offset of Time / UE Re-connection Indication | 时间偏移/重连指示 | 视情况 |

**确认机制要点**：当 AMF 请求确认时，启动确认重传定时器（NAS 实现中通常记为 **T3555**）；超时未收到 COMPLETE 则重传命令，达到最大重传次数后 AMF 可释放 NAS 信令连接或将 UE 去注册。这也是抓包中"同一条 CONFIGURATION UPDATE COMMAND 连续出现 N 次"的常见解释。

---

## 六、与注册、UE Policy 过程的边界

下表厘清 UCU 与相邻过程的关系，避免工程中混淆：

| 维度 | UE Configuration Update（4.2.4.2） | Registration（4.2.2.2） | UE Policy Update（4.2.4.3 / URSP） |
|---|---|---|---|
| 发起方 | AMF（网络发起） | UE（用户发起） | PCF（经 AMF 下发） |
| 主要更新内容 | 接入与移动性参数、切片、移动性限制 | 完整注册上下文（首次建立） | UE 策略（URSP 路由规则） |
| NAS 消息 | CONFIGURATION UPDATE COMMAND/COMPLETE | REGISTRATION REQUEST/ACCEPT 等 | MANAGE UE POLICY COMMAND/COMPLETE |
| 是否触发重注册 | 可能（Indication 决定） | — | 否（独立通道） |
| 典型时延 | 轻量、单轮交互 | 较重、多消息 | 轻量 |

UCU 与注册的关系是"补丁"而非"重做"：UCU 只下发变化的增量；当变化触及"连接根基"时，UCU 退化为"指示 UE 去重注册"的触发器，由随后的 Registration 完成真正重构。

---

## 七、抓包识别与故障排查

### 抓包如何识别 UCU

- **NGAP 侧**：看到 `Downlink NAS Transport` 携带的 NAS 消息 message type 为 *Configuration Update Command*（TS 24.501 第 8.2.18 节定义），紧随其后通常有 `Uplink NAS Transport` 携带 *Configuration Update Complete*。
- **RRC 侧**：`DLInformationTransfer` / `ULInformationTransfer` 透传上述 NAS PDU。
- **特征判据**：消息出现在 UE 已注册之后（非注册流程内）；安全头为完整性保护且加密；命令前若有 Paging + Service Request，说明 UE 当时 CM-IDLE。

### 常见故障点

1. **Allowed NSSAI 更新后 UE 业务中断**：检查命令是否携带 Registration Requested 指示，以及 3b 分支中是否有 PDU 会话被 SMF 释放（被移除切片对应的会话）。若 UE 未收到 COMPLETE，AMF 会重传，排查空口或 UE 处理逻辑。
2. **RRC_INACTIVE 下寻呼错位**：5G-GUTI 重分配后，若步骤 2c 未把新 UE Identity Index 同步给 NG-RAN，会引发寻呼帧计算错误（TS 38.304）。
3. **CAG/移动性限制未生效**：步骤 2c 的 Mobility Restrictions 须在 N2 侧同步；若 AMF 走的是条件 5/6（AN Release 而非更新 NG-RAN），UE 行为会按释放后重新接入处理。
4. **T3555 反复重传**：通常是 UE 未回 COMPLETE——可能是 UE 实现缺陷、消息解码失败或安全上下文不匹配。
5. **灾难漫游/灾难返回切换异常**：检查"灾难情况下使用的 PLMN 列表"等 IE 是否正确下发与 UE 是否正确切换。
## 八、常见问题

**Q1：UCU 和 Registration 都能下发 5G-GUTI/Allowed NSSAI，区别是什么？**
A：Registration 是 UE 发起、用于"建立或重建"完整注册上下文的过程；UCU 是 AMF 发起的"增量补丁"，只在已注册态更新变化的参数。当变化触及连接根基时，UCU 会通过 Registration Requested 指示把"真正重建"交给随后的 Registration 完成，二者职责互补而非重复。

**Q2：为什么只有 NITZ 不要求 UE 确认？**
A：NITZ（网络标识与时区）是单向的时间信息广播类参数，UE 是否应用不影响网络状态一致性，也没有后续依赖流程，因此 AMF 不请求确认；其余参数（GUTI、切片、移动性限制等）都涉及网络与 UE 的一致性同步，必须确认。

**Q3：UCU 会不会触发 UE 重新注册？什么情况下会？**
A：会。当配置更新影响 UE 与 AMF 的现有连接（如切片重映射导致连接失效）、或仅更新需在注册时协商的 NAS 参数（MICO 模式）时，AMF 在 Configuration Update Indication 中置 Registration Requested，UE 在确认（或被 AN Release 进入 CM-IDLE）后发起移动性注册更新。

**Q4：UCU 命令中同时更新 GUTI 和切片，UE 的处理顺序如何？**
A：UE 先应用全部参数更新，再按 Indication 决定是否回 COMPLETE 与是否重注册。5G-GUTI 的应用会通过步骤 2d 传递给下层（影响 RRC_INACTIVE 寻呼），AMF 收到确认后再经步骤 2c 把新 UE Identity Index 同步给 NG-RAN——这个时序保证寻呼帧计算不出错。

**Q5：抓包看到 CONFIGURATION UPDATE COMMAND 连续出现多次，是什么原因？**
A：最常见是 UE 未回送 CONFIGURATION UPDATE COMPLETE，AMF 侧确认重传定时器 T3555 超时后重传。应重点检查空口质量、UE 的消息处理逻辑与安全上下文是否匹配；若持续失败，AMF 最终会释放连接或将 UE 去注册。

---

## 参考来源

1. [3GPP TS 23.502 — Procedures for the 5G System, Section 4.2.4 UE Configuration Update](https://www.3gpp.org/dynareport/23502.htm) — UCU 过程定义、图 4.2.4.2-1 与步骤级语义
2. [3GPP TS 24.501 — NAS protocol for 5GS, Section 8.2.18 CONFIGURATION UPDATE COMMAND](https://www.3gpp.org/dynareport/24501.htm) — NAS 消息体与 IE 编码、5.4.4 UE侧行为
3. [3GPP TS 23.501 — System architecture for the 5G System](https://www.3gpp.org/dynareport/23501.htm) — 5.15 切片（NSSRG/NSAG/切片使用策略）、5.4.4.1a RACS、5.40 灾难漫游
4. [3GLTEInfo — 5G NAS Configuration Update Command](https://www.3glteinfo.com/messages/5g/nas/configuration-update-command/) — 消息说明、T3555 定时器与 IE 速查
5. [Cisco UCC 5G AMF Configuration and Administration Guide — UE Configuration Management Procedures](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2022-04/config-and-admin/b_ucc-5g-amf-config-and-admin-guide_2022-04/m_amf_ue_configuration_managment_procedure.pdf) — T3555 确认重传与 AMF 实现细节

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
