《5G核心网原理与实践》实践篇 · 网络切片 网元功能
作者：爱卫生
注册流程是5G终端接入网络的第一步，也是切片信息首次下发的关键时刻。 UE在发起5G注册请求时，通过Requested NSSAI告知网络自己希望使用哪些切片；AMF根据UE的签约数据、AMF自身支持的切片能力以及NSSF的切片选择结果，计算出Allowed NSSAI和Configured NSSAI，并通过Registration Accept消息下发给UE。
本篇是切片系列的收官之作，回到最基础也最重要的场景：验证UE在5G注册流程中，AMF如何根据UE的Requested NSSAI、签约数据和网络配置，正确计算并下发Allowed NSSAI和Configured NSSAI。
flowchart TD
A[UE发起注册] --> B[携带Requested NSSAI]
B --> C[AMF收到Registration Request]
C --> D{Requested NSSAI有效}
D -->|是| E[查询UDM签约数据]
D -->|否| F[使用Default S-NSSAI]
E --> G[计算Allowed NSSAI]
F --> G
G --> H{需要NSSF}
H -->|是| I[联系NSSF进行切片选择]
H -->|否| J[AMF本地计算]
I --> J
J --> K[Registration Accept下发NSSAI]
K --> L[UE保存并确认]
验证UE在Registration Request中正确携带Requested NSSAI
验证AMF正确计算Allowed NSSAI（取Requested NSSAI与签约数据的交集）
验证AMF正确计算Configured NSSAI（取AMF配置的NSSAI与签约数据的交集）
验证UE正确保存Allowed NSSAI和Configured NSSAI
验证注册完成后UE的状态为RM-REGISTERED
5G注册流程中的NSSAI处理涉及多个网元的协同，完整框架定义在3GPP TS 23.501第5.15.9节和TS 23.502第4.2.2节。
核心处理逻辑：
Allowed NSSAI = UE签约S-NSSAI ∩ UE Requested S-NSSAI ∩ AMF支持的S-NSSAI
Configured NSSAI = UE签约S-NSSAI ∩ AMF配置给该PLMN的S-NSSAI
在注册流程中，不同的NSSAI类型扮演不同角色：
| NSSAI类型 | 方向 | 携带位置 | 作用 |
|---|---|---|---|
| Requested NSSAI | UE→Network | Registration Request | UE告知网络期望使用的切片 |
| Subscribed S-NSSAI | UDM→AMF | Nudm_SDM_Get响应 | 用户签约的切片列表 |
| Allowed NSSAI | Network→UE | Registration Accept | 网络允许UE使用的切片 |
| Configured NSSAI | Network→UE | Registration Accept | 为UE配置的PLMN级切片 |
| Rejected NSSAI | Network→UE | Registration Accept | 在当前PLMN被拒绝的切片 |
AMF在注册流程中处理NSSAI的完整决策流程：
flowchart TD
A[AMF收到Registration Request] --> B{是否携带Requested NSSAI}
B -->|是| C[解析Requested NSSAI]
B -->|否| D[使用Default S-NSSAI或全部签约切片]
C --> E[从UDM获取签约S-NSSAI]
D --> E
E --> F[取Requested NSSAI与签约S-NSSAI的交集]
F --> G{交集是否为空}
G -->|是| H[联系NSSF进行切片选择]
G -->|否| I[与AMF支持的S-NSSAI取交集]
H --> I
I --> J{最终结果是否为空}
J -->|是| K[注册失败: S-NSSAI not supported]
J -->|否| L[得到Allowed NSSAI]
L --> M[计算Configured NSSAI]
M --> N[通过Registration Accept下发]
| 协议文档 | 章节 | 内容 |
|---|---|---|
| TS 23.501 | 5.15.9 | NSSAI管理框架 |
| TS 23.502 | 4.2.2 | 注册流程详细步骤 |
| TS 24.501 | 5.5.1 | Registration Request消息 |
| TS 24.501 | 5.5.2 | Registration Accept消息 |
| TS 24.501 | 9.11.3.35 | Allowed NSSAI信元编码 |
| TS 24.501 | 9.11.3.8 | Configured NSSAI信元编码 |
| TS 29.503 | 5.2.2 | UDM签约数据管理 |
| TS 29.531 | 5.2 | NSSF切片选择服务 |
| TS 38.413 | 8.7 | NGAP切片相关信元 |
在注册流程的NGAP层面，切片信息通过以下方式传递：
Initial UE Message：gNB在转发UE注册请求时，可以携带Selected PLMN和切片相关信息
NG Setup：gNB与AMF建立NG连接时，AMF告知gNB自己支持的切片列表
Initial Context Setup：AMF在建立UE上下文时，通过Allowed NSSAI信元告知gNB该UE可用的切片
sequenceDiagram
participant UE as UE
participant RAN as gNB
participant AMF as AMF
participant UDM as UDM
participant NSSF as NSSF
participant PCF as PCF
UE->>UE: 构造Requested NSSAI<br/>基于本地Configured NSSAI<br/>或默认配置
UE->>RAN: RRC: RRCSetupRequest
UE->>RAN: NAS: Registration Request<br/>5G-GUTI + Requested NSSAI
RAN->>AMF: NGAP: Initial UE Message<br/>NAS: Registration Request
AMF->>AMF: 解析Requested NSSAI<br/>识别GUTI获取UE上下文
AMF->>UDM: Nudm_SDM_Get<br/>获取UE签约数据
UDM-->>AMF: Nudm_SDM_Get Response<br/>签约S-NSSAI列表
AMF->>AMF: 计算Allowed NSSAI<br/>Requested NSSAI与签约数据交集
alt 需要NSSF协助
AMF->>NSSF: Nnssf_NSSelection_Get
NSSF-->>AMF: 切片选择结果
end
AMF->>AMF: 计算Configured NSSAI
AMF->>PCF: Npcf_UEPolicyControl_Get
PCF-->>AMF: NSSP策略
AMF->>RAN: NGAP: Initial Context Setup Request<br/>Allowed NSSAI + NAS: Registration Accept
RAN->>UE: NAS: Registration Accept<br/>Allowed NSSAI + Configured NSSAI + NSSP
UE->>UE: 保存Allowed NSSAI<br/>保存Configured NSSAI<br/>保存NSSP策略
UE->>RAN: NAS: Registration Complete
RAN->>AMF: NGAP: Uplink NAS Transport<br/>NAS: Registration Complete
UE在发起5G注册时，构造Registration Request消息。本测试场景中UE使用GUTI标识，并携带Requested NSSAI：
Registration Request消息：
5GS Registration Request
-- 5GS Registration Type: Initial Registration
-- Mobile Identity: 5G-GUTI
-- MCC: 460
-- MNC: 88
-- AMF Region ID: 0x01
-- AMF Set ID: 0x001
-- AMF Pointer: 0x00
-- TMSI: 0x12345678
-- Requested NSSAI:
-- S-NSSAI 1:
-- SST: 1 (eMBB)
-- SD: 010203
-- S-NSSAI 2:
-- SST: 2 (URLLC)
-- SD: 010204
-- UE Security Capability:
-- 5G-EA: NEA0, NEA1, NEA2, NEA3
-- 5G-IA: NIA0, NIA1, NIA2, NIA3
关键点：
UE必须携带5G-GUTI（Global Unique Temporary Identity）供AMF识别UE身份
Requested NSSAI中包含UE希望使用的切片列表
UE的Requested NSSAI通常基于之前网络下发的Configured NSSAI或本地配置
AMF收到Registration Request后，通过GUTI识别UE身份，然后向UDM获取签约数据。
Nudm_SDM_Get请求：
Nudm_SDM_Get Request
Method: GET
URI: /nudm-sdm/v2/imsi-4608800000XXXXXX/sm-data
Query Parameters:
-- plmn-id: {"mcc":"460","mnc":"88"}
Nudm_SDM_Get响应（签约数据）：
{
"nssai": {
"subscribedSnssai": [
{"sst": 1, "sd": "010203", "defaultIndication": true},
{"sst": 2, "sd": "010204"},
{"sst": 3}
]
}
}
Allowed NSSAI计算过程：
Requested NSSAI = {SST:1/SD:010203, SST:2/SD:010204}
签约S-NSSAI = {SST:1/SD:010203, SST:2/SD:010204, SST:3}
AMF支持的S-NSSAI = {SST:1/SD:010203, SST:2/SD:010204}
Allowed NSSAI = Requested ∩ 签约 ∩ AMF支持
= {SST:1/SD:010203, SST:2/SD:010204}
Configured NSSAI的计算逻辑与Allowed NSSAI不同：
AMF配置给PLMN的NSSAI = {SST:1/SD:010203, SST:2/SD:010204, SST:3}
签约S-NSSAI = {SST:1/SD:010203, SST:2/SD:010204, SST:3}
Configured NSSAI = AMF配置 ∩ 签约
= {SST:1/SD:010203, SST:2/SD:010204, SST:3}
注意：Configured NSSAI可能比Allowed NSSAI包含更多的S-NSSAI。在本例中，SST:3（MIoT）虽然在Configured NSSAI中，但不在Requested NSSAI中，因此不在Allowed NSSAI中。这意味着UE知道SST:3切片的存在，但本次注册中未使用它。
AMF构造Registration Accept消息，携带计算好的NSSAI信息：
Registration Accept消息：
5GS Registration Accept
-- 5G Registration Result: 3GPP Access Registered
-- 5G-GUTI: (新分配)
-- MCC: 460, MNC: 88
-- AMF Region ID: 0x01
-- AMF Set ID: 0x001
-- AMF Pointer: 0x00
-- TMSI: 0xAABBCCDD
-- Allowed NSSAI:
-- S-NSSAI 1:
-- SST: 1
-- SD: 010203
-- S-NSSAI 2:
-- SST: 2
-- SD: 010204
-- Configured NSSAI for Serving PLMN:
-- S-NSSAI 1:
-- SST: 1
-- SD: 010203
-- S-NSSAI 2:
-- SST: 2
-- SD: 010204
-- S-NSSAI 3:
-- SST: 3
-- Rejected NSSAI for Serving PLMN: (空，本例无拒绝的切片)
-- UE Policy (NAS容器):
-- NSSP规则
关键点解读：
Allowed NSSAI = {SST:1/SD:010203, SST:2/SD:010204}——UE本次被允许使用的切片
Configured NSSAI = {SST:1/SD:010203, SST:2/SD:010204, SST:3}——UE在该PLMN下可用的全部切片
新的5G-GUTI已分配给UE
NSSP策略通过UE Policy容器下发
UE收到Registration Accept后：
保存5G-GUTI：作为后续信令交互的临时标识
保存Allowed NSSAI：后续PDU Session建立只能使用这些切片
保存Configured NSSAI：作为下次注册时构造Requested NSSAI的参考
保存NSSP策略：用于指导业务到切片的映射
发送Registration Complete：确认注册完成
Registration Complete消息：
5GS Registration Complete
-- Security Header Type: Integrity Protected and Ciphered
-- Message Type: Registration Complete (0x43)
注册流程在NGAP层面的关键交互：
步骤1：Initial UE Message（gNB→AMF）
NGAP Initial UE Message
-- RAN UE NGAP ID: 87654321
-- User Location Information: TAC=xxxxx, Cell ID=xxxxx
-- RRC Establishment Cause: mo-Signalling
-- NAS-PDU: Registration Request (含Requested NSSAI)
-- Selected PLMN: MCC=460, MNC=88
步骤2：Initial Context Setup Request（AMF→gNB）
NGAP Initial Context Setup Request
-- AMF UE NGAP ID: 12345678
-- RAN UE NGAP ID: 87654321
-- UE Aggregate Maximum Bit Rate
-- Allowed NSSAI:
-- S-NSSAI 1: SST=1, SD=010203
-- S-NSSAI 2: SST=2, SD=010204
-- NAS-PDU: Registration Accept
-- Security Key
gNB收到Initial Context Setup Request后，知道了UE的Allowed NSSAI，后续PDU Session建立时将据此进行切片感知的资源分配。
UE如何决定在Registration Request中携带哪些S-NSSAI？
flowchart TD
A[UE准备发起注册] --> B{本地有Configured NSSAI}
B -->|是| C[使用Configured NSSAI作为Requested NSSAI]
B -->|否| D{本地有默认S-NSSAI配置}
D -->|是| E[使用默认S-NSSAI作为Requested NSSAI]
D -->|否| F[不携带Requested NSSAI]
C --> G[发起Registration Request]
E --> G
F --> G
Allowed NSSAI的计算是一个三重交集操作：
Allowed NSSAI = Requested NSSAI
∩ Subscribed S-NSSAI (from UDM)
∩ AMF Supported S-NSSAI
特殊情况处理：
1. 如果UE不携带Requested NSSAI → 使用签约的Default S-NSSAI
2. 如果交集为空 → 联系NSSF获取切片映射
3. 如果NSSF也无法提供 → 注册失败（原因值：#62 S-NSSAI not supported）
两者的区别和关系：
| 维度 | Configured NSSAI | Allowed NSSAI |
|---|---|---|
| 范围 | PLMN级别 | 注册区域级别 |
| 值 | 通常较大 | 通常较小或相等 |
| 用途 | 下次注册的参考 | 当前可用的切片 |
| 更新时机 | 注册时或配置更新时 | 每次注册或切换时 |
| 存储位置 | UE非易失存储 | UE易失存储 |
在UDM的签约数据中，某个S-NSSAI可以被标记为Default（默认切片）。Default S-NSSAI的作用：
当UE不携带Requested NSSAI时，AMF使用Default S-NSSAI
当PDU Session建立时UE不指定S-NSSAI，SMF使用Default S-NSSAI
一个UE可以有多个Default S-NSSAI（针对不同DNN）
本测试中，签约数据标记SST:1/SD:010203为Default S-NSSAI：
{
"sst": 1,
"sd": "010203",
"defaultIndication": true,
"subscribedDnnList": ["internet"]
}
如果AMF计算Allowed NSSAI为空，注册将失败：
Registration Reject
-- 5GMM Cause: #62 (Serving network not authorized for this network slice)
常见原因：
UE请求的所有S-NSSAI都不在签约数据中
UE请求的所有S-NSSAI都不被AMF支持
签约数据中未配置任何S-NSSAI
本测试的预置条件：
终端支持5G NAS协议且支持NSSAI相关功能
RAN（gNB）支持切片感知功能
AMF已正确配置支持的切片信息
UDM中已正确配置UE的签约切片数据
PCF已配置DNN与S-NSSAI的对应关系
AMF与NSSF之间的接口正常
RAN通过NG Setup已获取AMF支持的切片列表
检查点1：UE发起Registration Request携带GUTI和Requested NSSAI
验证Registration Request消息中：
Mobile Identity类型为5G-GUTI
包含Requested NSSAI信元
Requested NSSAI中的S-NSSAI值正确
检查点2：AMF获取签约数据并计算切片
验证AMF：
通过GUTI识别UE身份
向UDM获取签约S-NSSAI列表成功
正确计算Allowed NSSAI（Requested ∩ 签约）
检查点3：Registration Accept包含正确的NSSAI
验证Registration Accept消息：
Allowed NSSAI = Requested NSSAI与签约数据的交集
Configured NSSAI = AMF配置的NSSAI与签约数据的交集
包含新分配的5G-GUTI
检查点4：UE保存NSSAI并回复Registration Complete
验证UE行为：
UE正确保存Allowed NSSAI
UE正确保存Configured NSSAI
UE发送Registration Complete消息
检查点5：UE上下文状态正确
通过AMF管理面查看UE上下文：
UE Context (注册成功后):
SUPI: imsi-4608800000XXXXXX
GPSI: 86138000XXXXXX
RM State: RM-REGISTERED
CM State: CM-CONNECTED
Allowed NSSAI: {SST:1/SD:010203, SST:2/SD:010204}
Configured NSSAI: {SST:1/SD:010203, SST:2/SD:010204, SST:3}
Registration Type: Initial Registration
Access Type: 3GPP Access
| 序号 | 验证项 | 预期结果 |
|---|---|---|
| 1 | UE发起注册携带GUTI | Registration Request包含5G-GUTI |
| 2 | UE携带Requested NSSAI | 包含SST:1/SD:010203和SST:2/SD:010204 |
| 3 | AMF获取签约数据 | 成功获取3个签约S-NSSAI |
| 4 | Allowed NSSAI计算 | {SST:1/SD:010203, SST:2/SD:010204} |
| 5 | Configured NSSAI计算 | {SST:1/SD:010203, SST:2/SD:010204, SST:3} |
| 6 | Registration Accept下发 | 包含正确的Allowed NSSAI和Configured NSSAI |
| 7 | UE回复Complete | Registration Complete正确发送 |
| 8 | 注册成功 | UE状态为RM-REGISTERED |
为了全面验证注册时NSSAI下发的健壮性，建议补充以下异常场景测试：
| 场景 | 测试方法 | 预期结果 |
|---|---|---|
| UE不携带Requested NSSAI | 在Registration Request中省略NSSAI | AMF使用Default S-NSSAI |
| UE携带未签约的S-NSSAI | Requested NSSAI包含未签约切片 | 仅允许已签约的部分 |
| UE携带所有S-NSSAI都未签约 | Requested NSSAI全部无效 | 注册被拒绝（Cause #62） |
| 签约数据中无Default S-NSSAI | UDM配置无default标记 | AMF请求NSSF协助 |
本篇验证了5G注册流程中NSSAI的首次下发机制，这是整个切片管理链路的起点：
UE主动请求：UE通过Requested NSSAI告知网络期望使用的切片
网络精确计算：AMF基于三重交集（请求×签约×能力）计算Allowed NSSAI
双NSSAI下发：同时下发Allowed NSSAI（当前可用）和Configured NSSAI（PLMN级配置）
策略同步下发：PCF通过注册流程下发NSSP策略，指导后续业务选择切片
UE完整保存：UE保存所有信息，为后续PDU Session建立做准备
本篇作为切片系列的收官，回顾整个系列的逻辑链路：
flowchart LR
A[第19篇<br/>注册时下发NSSAI] -->|UE已注册| B[第16篇<br/>配置更新下发新NSSAI]
B -->|切片变更| C[第18篇<br/>配置更新变更NSSAI]
A -->|多切片允许| D[第17篇<br/>并发多切片接入]
D -->|业务运行中| C
第19篇（本篇）：注册流程是切片管理的入口，一切从这里开始
第16篇：当网络配置变化时，如何在线更新已注册UE的切片配置
第17篇：获取到多切片权限后，如何并发建立多个PDU Session
第18篇：已有切片配置的动态更新（增删改）
从运维角度，5G切片管理相比4G的APN管理有了质的飞跃：
| 维度 | 4G APN | 5G S-NSSAI |
|---|---|---|
| 差异化维度 | 主要靠QCI | SST+SD+5QI，粒度更细 |
| 动态调整 | 静态为主，需重新附着 | 配置更新流程，无需去附着 |
| 多连接 | 多PDN连接 | 多PDU Session + 切片隔离 |
| 网络自动化 | 有限 | NSSP策略驱动，NSSF自动选择 |
| 端到端隔离 | 无 | RAN+TN+CN端到端隔离 |
抓包验证：在日常工作中遇到切片问题时，首先通过NAS抓包确认UE是否正确携带了Requested NSSAI，AMF是否正确下发了Allowed NSSAI
签约数据排查：Allowed NSSAI为空的常见原因是UDM签约数据未正确配置S-NSSAI，排查时先查签约数据
NSSF日志：当AMF无法独立完成切片选择时，NSSF的日志是排查问题的关键
NGAP层面的Allowed NSSAI：别忘了gNB也需要知道UE的Allowed NSSAI，如果gNB侧切片资源分配异常，检查NGAP Initial Context Setup中的Allowed NSSAI是否正确
版本兼容性：不同厂商的AMF对NSSAI处理逻辑的细节实现可能略有差异，异厂商组网时需重点验证
至此，5GC实践篇切片系列的4篇文章全部完成。从注册时的首次下发、到配置更新的动态推送、到并发多切片的业务实践、再到配置变更的在线更新，这4篇文章覆盖了5G网络切片管理中最核心的实践场景。
掌握这些流程，不仅有助于理解3GPP规范中的切片机制，更能在实际运维中快速定位和解决切片相关问题。5G切片技术仍在不断演进，Release 18/19中引入的增强切片管理功能（如切片即服务、跨域切片编排等）值得持续关注。