5GC实践篇之切片篇第16篇：通过配置更新流程下发Configured NSSAI与Allowed NSSAI

运营商新部署了一个S-NSSAI=5的URLLC切片，需要将已在线的工业终端加入该切片
企业用户的签约切片套餐升级，从eMBB切片扩展到同时支持eMBB+URLLC
运营商缩频退网某个试验切片，需要通知所有相关终端移除该切片
AMF扩容或切片配置更新后，支持的切片集合发生变化

本篇测试目标

验证当网络侧修改切片配置或UE签约数据变更后，AMF能够通过UE Configuration Update Command消息将变化后的Allowed NSSAI和Configured NSSAI（可选）下发给UE，并正确指示UE执行重新注册流程。

2 协议规范与关键技术

2.1 UE Configuration Update流程概述

UE Configuration Update流程定义在3GPP TS 24.501第5.4.4节，是5G NAS层的重要配置管理流程。与4G相比，5G新增了NSSAI相关配置的动态更新能力。

该流程由网络侧（AMF）发起，用于在UE已注册状态下更新以下信息：

Allowed NSSAI：UE当前被允许使用的网络切片集合
Configured NSSAI：为UE配置的可用切片集合（可选）
Network Name：网络名称信息（可选）
5G-GUTI：新的临时标识（可选）

2.2 触发条件

根据3GPP TS 23.501第5.15.9节和TS 29.509的规范，AMF在以下情况下会发起UE Configuration Update：


flowchart TD

    A[AMF检测到NSSAI变化] --> B{变化类型判断}

    B --> C[签约数据变更]

    B --> D[网络配置变更]

    B --> E[AMF切片支持能力变更]

    C --> F[UDM通过Nudm_SDM_Notification通知AMF]

    D --> G[运维修改AMF支持的S-NSSAI列表]

    E --> H[AMF重配置或扩容]

    F --> I[AMF计算新的Allowed NSSAI]

    G --> I

    H --> I

    I --> J[发起UE Configuration Update]

2.3 关键协议参考

协议文档	相关章节	内容
TS 24.501	5.4.4	UE Configuration Update流程定义
TS 24.501	8.2.8	CONFIGURATION UPDATE COMMAND消息格式
TS 24.501	8.2.9	CONFIGURATION UPDATE COMPLETE消息格式
TS 23.501	5.15.9	NSSAI管理相关流程
TS 29.509	5.3	NSSF服务接口定义
TS 29.531	5.2	Nnssf_NSSAIAvailability服务
TS 38.413	8.7	NGAP Slice相关信元

2.4 NSSAI类型回顾

在理解本篇流程前，快速回顾5G中与UE相关的几种NSSAI：

NSSAI类型	生成方	作用	存储位置
Subscribed S-NSSAI(s)	UDM/UDR	用户签约的切片	UDM
Configured NSSAI	AMF/NSSF	配置给UE的可用切片	UE + AMF
Requested NSSAI	UE	UE请求使用的切片	UE发起
Allowed NSSAI	AMF	当前PLMN下允许的切片	UE + AMF
Rejected NSSAI	AMF	当前PLMN下拒绝的切片	UE

3 消息流程与详细解读

3.1 整体流程概览

本篇的完整信令流程如下：


sequenceDiagram

    participant OAM as OAM/运维系统

    participant UDM as UDM

    participant AMF as AMF

    participant RAN as gNB

    participant UE as UE

    Note over UE,AMF: 前提：UE已注册，网络已下发Allowed NSSAI

    OAM->>UDM: 修改UE签约切片数据

    UDM->>AMF: Nudm_SDM_Notification(签约数据变更)

    AMF->>AMF: 计算新的Allowed NSSAI<br/>和Configured NSSAI

    AMF->>RAN: NAS: CONFIGURATION UPDATE COMMAND<br/>Allowed NSSAI + Configured NSSAI(可选)<br/>Configuration Update Indication

    RAN->>UE: NAS: CONFIGURATION UPDATE COMMAND

    UE->>UE: 保存新的NSSAI信息

    UE->>RAN: NAS: CONFIGURATION UPDATE COMPLETE

    RAN->>AMF: NAS: CONFIGURATION UPDATE COMPLETE

    Note over UE,AMF: UE根据指示发起重新注册

    UE->>RAN: Registration Request(GUTI, Requested NSSAI)

    RAN->>AMF: Registration Request

    AMF->>AMF: 切片选择验证

    AMF->>RAN: Registration Accept(Allowed NSSAI)

    RAN->>UE: Registration Accept

3.2 阶段一：网络侧检测到NSSAI变化

当运维人员在OAM系统修改了AMF支持的切片配置，或通过UDM修改了UE的签约数据时，AMF需要重新计算UE的Allowed NSSAI。

场景A：签约数据变更触发

UDM检测到UE的Subscribed S-NSSAI发生变化后，通过Nudm_SDM_Notification服务通知AMF：


Nudm_SDM_Notification

{

  "ueId": "imsi-4608800000XXXXXX",

  "subscriptionData": {

    "nssai": {

      "subscribedSnssai": [

        {"sst": 1, "sd": "010203"},

        {"sst": 2, "sd": "010204"},

        {"sst": 3}

      ]

    }

  }

}

场景B：AMF配置变更触发

运维通过管理面修改AMF支持的切片列表，AMF在配置生效后，遍历当前所有在线UE，对每个UE重新计算Allowed NSSAI。

3.3 阶段二：AMF重新计算Allowed NSSAI

AMF的Allowed NSSAI计算逻辑遵循以下原则：

取 UE签约的S-NSSAI 与 AMF支持的S-NSSAI 的交集
如果交集为空，AMF需要联系NSSF获取切片信息
计算新的Allowed NSSAI与旧的Allowed NSSAI是否不同
如果不同，触发UE Configuration Update流程


flowchart TD

    A[AMF收到变更通知] --> B[获取UE签约S-NSSAI列表]

    B --> C[获取AMF支持的S-NSSAI列表]

    C --> D[计算交集]

    D --> E{交集是否为空}

    E -->|是| F[联系NSSF获取切片映射]

    E -->|否| G[得到新的Allowed NSSAI]

    F --> G

    G --> H{与旧Allowed NSSAI不同}

    H -->|是| I[触发UE Configuration Update]

    H -->|否| J[无需更新，结束]

3.4 阶段三：下发CONFIGURATION UPDATE COMMAND

AMF构造NAS消息CONFIGURATION UPDATE COMMAND，通过NGAP下行NAS传输消息发送给UE。

NAS消息结构（简化）：


CONFIGURATION UPDATE COMMAND

  -- Protocol Discriminator: 5GS Mobility Management

  -- Security Header Type: Integrity Protected and Ciphered

  -- Message Type: Configuration Update Command (0x54)

  -- Allowed NSSAI (IE)

    -- S-NSSAI 1: SST=1, SD=010203

    -- S-NSSAI 2: SST=2, SD=010204

  -- Configured NSSAI for the Serving PLMN (IE, 可选)

    -- S-NSSAI 1: SST=1, SD=010203

    -- S-NSSAI 2: SST=2, SD=010204

    -- S-NSSAI 3: SST=3

  -- Configuration Update Indication (IE)

    -- Redirection indicator: UE需要重新注册

    -- ACK indicator: 需要UE回复COMPLETE

关键参数解读：

Configuration Update Indication信元是本流程的核心控制参数，包含两个关键比特：

比特位	名称	含义
Bit 1	Registration Required	置1表示UE必须发起重新注册
Bit 2	Acknowledgement Required	置1表示UE必须回复COMPLETE消息

在本测试场景中，两个比特均置为1，即UE必须回复确认并重新注册。

3.5 阶段四：UE处理与响应

UE收到CONFIGURATION UPDATE COMMAND后：

验证完整性保护：检查NAS消息的MAC是否正确
更新本地NSSAI存储：
将新的Allowed NSSAI替换旧值
如果包含Configured NSSAI，同样更新保存
检查Configuration Update Indication：
ACK Required置1 → 必须发送CONFIGURATION UPDATE COMPLETE
Registration Required置1 → 完成确认后必须发起Registration流程
发送CONFIGURATION UPDATE COMPLETE回复AMF

3.6 阶段五：UE发起重新注册

由于Configuration Update Indication中要求UE重新注册，UE在发送COMPLETE后：

构造Registration Request消息
根据新获取的Allowed NSSAI，携带Requested NSSAI
不携带GUTI信息（网络指示UE以No GUTI方式重新注册，获取新的上下文）
完成完整的注册流程，获取最终的Allowed NSSAI

4 关键信令参数分析

4.1 CONFIGURATION UPDATE COMMAND消息解析

以下是本测试中抓取的实际NAS消息关键字段（脱敏处理）：

Allowed NSSAI信元：


Allowed NSSAI (Length = 7)

  S-NSSAI Value 1:

    SST: 1 (eMBB)

    SD: 010203

  S-NSSAI Value 2:

    SST: 2 (URLLC)

    SD: 010204

Configured NSSAI信元（可选）：


Configured NSSAI for Serving PLMN (Length = 10)

  S-NSSAI Value 1:

    SST: 1

    SD: 010203

  S-NSSAI Value 2:

    SST: 2

    SD: 010204

  S-NSSAI Value 3:

    SST: 3 (MIoT)

    SD: absent

Configuration Update Indication：


Configuration Update Indication

  Registration required: 1 (Registration required)

  Acknowledgement required: 1 (Acknowledgement required)

4.2 NSSAI计算示例

假设本测试中：

UE签约的S-NSSAI：{SST:1/SD:010203, SST:2/SD:010204, SST:3}
旧AMF支持的S-NSSAI：{SST:1/SD:010203}
新AMF支持的S-NSSAI：{SST:1/SD:010203, SST:2/SD:010204}

计算过程：


旧Allowed NSSAI = 签约 ∩ AMF支持 = {SST:1/SD:010203}

新Allowed NSSAI = 签约 ∩ 新AMF支持 = {SST:1/SD:010203, SST:2/SD:010204}

差集 = {SST:2/SD:010204} → 新增切片

→ 触发UE Configuration Update

4.3 NGAP承载分析

在NGAP层面，CONFIGURATION UPDATE COMMAND通过Downlink NAS Transport消息传输：


NGAP Downlink NAS Transport

  -- AMF UE NGAP ID: 12345678

  -- RAN UE NGAP ID: 87654321

  -- NAS-PDU:

    -- CONFIGURATION UPDATE COMMAND (加密后)

  -- Allowed NSSAI (NGAP层面也携带):

    -- S-NSSAI 1: SST=1, SD=010203

    -- S-NSSAI 2: SST=2, SD=010204

注意：根据TS 38.413规范，NGAP的Downlink NAS Transport消息中也包含Allowed NSSAI信元。这是为了在RAN侧也感知UE最新的切片信息，以便后续PDU Session建立时进行切片感知的NG-RAN资源分配。

4.4 安全保护机制

CONFIGURATION UPDATE COMMAND消息必须经过完整性保护和加密：

安全特性	说明
完整性保护	必须应用，UE会验证MAC-I
加密	必须应用，保护NSSAI信息不被窃听
NAS Security Context	使用当前注册流程建立的安全上下文

如果UE验证完整性保护失败，将丢弃该消息，不进行任何处理。

5 测试验证与数据解读

5.1 测试预置条件

本测试的预置条件：

网元要求：终端、RAN、AMF、UDM、NSSF等网元均支持切片选择功能
环境配置：
环境已配置好相关的切片信息
UE在UDM成功签约了切片数据
PCF上配置了DNN以及S-NSSAI的对应数据
AMF上配置了支持的切片信息
RAN支持在NG Setup流程与AMF交互切片信息
初始状态：
UE已成功在5G网络注册
网络侧已将Allowed NSSAI以及Configured NSSAI（可选）下发给UE
UE已保存在终端上
跟踪配置：在各逻辑网元上建立接口跟踪和用户跟踪

5.2 测试执行步骤

步骤1：确认UE当前的Allowed NSSAI

修改前，通过AMF查询UE上下文，确认当前Allowed NSSAI：


UE Context (修改前):

  SUPI: imsi-4608800000XXXXXX

  Allowed NSSAI: 

    - SST:1, SD:010203 (eMBB)

  Configured NSSAI:

    - SST:1, SD:010203

步骤2：修改网络配置或签约数据

通过AMF修改支持的切片信息，或修改UE在UDM的签约切片数据：


修改操作：

  AMF新增支持的S-NSSAI: SST:2, SD:010204 (URLLC)

  或

  UDM为UE新增签约S-NSSAI: SST:2, SD:010204

步骤3：观察AMF行为

AMF检测到配置变更后：

重新计算Allowed NSSAI
发现Allowed NSSAI发生变化
发起UE Configuration Update流程

步骤4：检查消息跟踪

验证CONFIGURATION UPDATE COMMAND消息中包含正确的NSSAI信息。

步骤5：检查UE上下文

修改后，确认UE上下文中的Allowed NSSAI已更新：


UE Context (修改后):

  SUPI: imsi-4608800000XXXXXX

  Allowed NSSAI:

    - SST:1, SD:010203 (eMBB)

    - SST:2, SD:010204 (URLLC)  ← 新增

  Configured NSSAI:

    - SST:1, SD:010203

    - SST:2, SD:010204

5.3 验证检查点

序号	检查项	预期结果	验证方法
1	签约/配置变更触发	AMF收到变更通知	检查AMF日志/跟踪
2	AMF计算新Allowed NSSAI	与旧值不同	AMF内部日志
3	CONFIGURATION UPDATE COMMAND下发	消息中包含新Allowed NSSAI	NAS消息跟踪
4	Configuration Update Indication	Registration=1, ACK=1	NAS消息解码
5	UE回复COMPLETE	UE正确响应	NAS消息跟踪
6	UE发起重新注册	UE发送Registration Request	NAS消息跟踪
7	UE不携带GUTI	Registration Request中无GUTI	NAS消息解码
8	重新注册成功	Registration Accept包含新Allowed NSSAI	NAS消息跟踪

5.4 测试结果

测试验证结果：

UE的Allowed NSSAI发生变化后，AMF成功通过UE Configuration Update流程通知UE
AMF在CONFIGURATION UPDATE COMMAND消息中正确携带了变化后的Allowed NSSAI
Configuration Update Indication正确指示UE需要重新Registration
同时指示UE在重新注册时不要携带GUTI信息
UE正确响应CONFIGURATION UPDATE COMPLETE消息
UE随后发起重新注册流程，成功获取新的Allowed NSSAI

6 小结与思考

6.1 核心要点总结

本篇验证了5G核心网中网络驱动的NSSAI动态更新机制。核心流程可以概括为三个步骤：

感知变化：AMF通过UDM通知或配置变更感知到UE的Allowed NSSAI需要更新
推送更新：通过UE Configuration Update Command将新NSSAI推送给UE
确认生效：指示UE重新注册，完成新切片的正式激活

6.2 与4G的对比思考

在4G LTE时代，PDN连接的APN配置相对静态，主要通过HSS的签约数据和PCRF的策略来管理。5G引入切片概念后，NSSAI的动态管理变得至关重要：

维度	4G LTE	5G NR
服务差异化	APN + QCI	S-NSSAI + DNN + 5QI
动态配置更新	无标准流程	UE Configuration Update
网络切片感知	不支持	端到端切片感知
多切片并发	多PDN连接	多PDU Session + 多S-NSSAI

6.3 实际部署注意事项

UE兼容性：部分早期5G终端可能不完全支持Configuration Update流程中的NSSAI更新，需要确认终端软件版本
RAN协同：gNB需要通过NG Setup获取AMF的切片支持信息，并在Paging等流程中正确使用切片信息
NSSF部署：在多PLMN共享场景下，NSSF的正确配置至关重要，它决定了切片映射的准确性
计费影响：切片变更可能导致计费规则变化，PCF需要同步更新相应的PCC规则

6.4 延伸思考

如果Allowed NSSAI被缩减（删除了某个S-NSSAI），那么UE上该切片对应的PDU Session会如何处理？根据TS 23.501规范，网络需要在去注册该切片前，先释放该切片下的所有PDU Session。这涉及到SMF和UPF的会话释放流程，将在后续文章中进一步探讨。

关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101

5GC实践篇之切片篇第16篇：通过配置更新流程下发Configured NSSAI与Allowed NSSAI

5GC实践篇之切片篇第16篇：通过配置更新流程下发Configured NSSAI与Allowed NSSAI

1 测试背景与用例简介

本篇测试目标

2 协议规范与关键技术

2.1 UE Configuration Update流程概述

2.2 触发条件

2.3 关键协议参考

2.4 NSSAI类型回顾

3 消息流程与详细解读

3.1 整体流程概览

3.2 阶段一：网络侧检测到NSSAI变化

3.3 阶段二：AMF重新计算Allowed NSSAI

3.4 阶段三：下发CONFIGURATION UPDATE COMMAND

3.5 阶段四：UE处理与响应

3.6 阶段五：UE发起重新注册

4 关键信令参数分析

4.1 CONFIGURATION UPDATE COMMAND消息解析

4.2 NSSAI计算示例

4.3 NGAP承载分析

4.4 安全保护机制

5 测试验证与数据解读

5.1 测试预置条件

5.2 测试执行步骤

5.3 验证检查点

5.4 测试结果

6 小结与思考

6.1 核心要点总结

6.2 与4G的对比思考

6.3 实际部署注意事项

6.4 延伸思考

查看完整内容