理解本场景是掌握更复杂切片选择流程的基础。后续第7篇、第8篇将逐步引入NSSF参与的场景，形成完整的切片选择知识体系。
2 协议规范与关键技术
2.1 相关协议规范
本篇涉及的3GPP协议规范主要包括：
-
TS 23.501：5G系统架构描述，定义了NSSAI、切片选择框架、Allowed NSSAI生成规则等核心概念。第5.15节详细描述了网络切片选择的总体机制。
-
TS 23.502：5G系统流程，第4.2.2.2.2节描述了注册过程中切片选择的详细步骤，包括AMF自行确定Allowed NSSAI的条件。
-
TS 29.509：NSSF服务的API定义，虽然本场景不涉及NSSF，但理解其接口有助于对比后续场景。
-
TS 24.501：NAS协议规范，定义了Registration Request、Registration Accept等消息中NSSAI相关信元的编码格式。
-
TS 29.503：UDM服务接口，定义了Nudm_SDM_Get服务操作，用于AMF获取UE签约的NSSAI数据。
2.2 关键技术概念
NSSAI（Network Slice Selection Assistance Information）是5G切片选择的核心数据结构。一个NSSAI由一个或多个S-NSSAI组成，每个S-NSSAI包含：
Default NSSAI是运营商为UE在签约数据中配置的默认切片集合。当UE未携带Requested NSSAI时，AMF使用签约数据中的Default NSSAI作为UE的请求切片。这是本场景的关键处理逻辑。
Allowed NSSAI是网络侧最终授权给UE使用的切片集合。其生成规则为：Requested NSSAI（或Default NSSAI）与UE签约的S-NSSAI以及AMF支持的S-NSSAI三者的交集。
2.3 AMF自行确定Allowed NSSAI的条件
根据TS 23.502第4.2.2.2.2节，当满足以下所有条件时，AMF可以不查询NSSF，自行确定Allowed NSSAI：
-
AMF未从UE收到Requested NSSAI（即Requested NSSAI为空）；
-
AMF可以为UE签约数据中所有Default S-NSSAI提供服务；
-
不存在需要NSSF参与的运营商策略触发条件。
这三个条件缺一不可。本篇场景恰好满足全部条件，因此AMF可以独立完成处理。
3 消息流程与详细解读
3.1 整体流程概览
sequenceDiagram
participant UE
participant RAN as NG-RAN
participant AMF
participant UDM
UE->>RAN: RRC Connection + NAS Registration Request(SUCI)
Note over UE,RAN: 未携带Requested NSSAI
RAN->>AMF: Initial UE Message(NAS Registration Request)
AMF->>UDM: Nudm_SDM_Get(SUPI/NSSAI)
Note over AMF,UDM: 获取UE签约切片数据
UDM-->>AMF: Nudm_SDM_Get Response(Subscribed NSSAI)
Note over AMF: 将Default NSSAI作为<br/>Requested NSSAI<br/>判断本AMF可支持<br/>所有Default S-NSSAI<br/>无需查询NSSF
AMF->>RAN: NGAP Initial Context Setup Request
Note over AMF,RAN: 携带Allowed NSSAI<br/>和Configured NSSAI(可选)
RAN->>UE: NAS Registration Accept(GUTI,Allowed NSSAI,Configured NSSAI)
UE-->>RAN: NAS Registration Complete
RAN-->>AMF: NGAP Initial Context Setup Response
3.2 流程详细解读
步骤1：UE发起注册请求
UE开机或从无覆盖区域恢复后，发起Registration Request消息。本场景的关键特征是UE在NAS消息中不携带Requested NSSAI。这种情况通常发生在以下几种场景：
UE在Registration Request中携带SUCI（Subscription Permanent Concealed Identifier），用于身份标识。由于未携带Requested NSSAI，RAN侧无法基于切片信息选择AMF，将根据默认策略或负载均衡策略选择AMF。
步骤2：AMF向UDM获取签约数据
AMF收到Registration Request后，发现本地没有该UE的签约上下文（新注册场景），需要向UDM获取签约数据。AMF调用Nudm_SDM_Get服务操作，请求路径为/{supi}/nssai，获取UE签约的NSSAI信息。
UDM返回的签约数据中包含：
步骤3：AMF判断切片服务能力
AMF收到签约数据后，执行以下判断逻辑：
-
由于UE未携带Requested NSSAI，AMF将签约数据中的Default NSSAI作为UE的隐式Requested NSSAI；
-
AMF检查自身配置的切片支持列表，确认是否支持Default NSSAI中的所有S-NSSAI；
-
本场景下，AMF确认可以支持所有Default S-NSSAI，无需查询NSSF。
步骤4：AMF生成Allowed NSSAI
AMF通过以下交集运算生成Allowed NSSAI：
同时，AMF可选地生成Configured NSSAI。Configured NSSAI是AMF配置的NSSAI与UE签约的NSSAI的交集，用于后续UE发起PDU会话或重注册时作为Requested NSSAI使用。
步骤5：下发Registration Accept
AMF通过Registration Accept消息将Allowed NSSAI和Configured NSSAI（可选）下发给UE。同时消息中还携带5G-GUTI，用于后续UE的身份标识。
步骤6：UE完成注册
UE收到Registration Accept后，保存Allowed NSSAI和Configured NSSAI，并回复Registration Complete消息确认注册完成。
3.3 AMF内部决策流程
flowchart TD
A[收到Registration Request] --> B[检查Requested NSSAI]
B --> C[Requested NSSAI为空]
C --> D[向UDM获取签约数据]
D --> E[将Default NSSAI作为隐式Requested NSSAI]
E --> F[检查本AMF是否支持所有Default S-NSSAI]
F --> G[是：AMF可独立处理]
F --> H[否：需查询NSSF - 见第8篇]
G --> I[生成Allowed NSSAI]
I --> J[生成Configured NSSAI可选]
J --> K[下发Registration Accept]
K --> L[注册完成]
4 关键信令参数分析
4.1 Registration Request消息参数
| 参数名称 |
是否携带 |
说明 |
| SUCI |
是 |
UE的身份标识，用于首次注册或GUTI无效场景 |
| Requested NSSAI |
否 |
本场景关键特征：UE未携带请求切片信息 |
| 5G-GUTI |
否 |
首次注册或无有效GUTI时不携带 |
| Registration Type |
是 |
初始注册 |
| UE security capability |
是 |
UE支持的安全算法列表 |
4.2 Nudm_SDM_Get请求/响应参数
请求消息（Nudm_SDM_Get Request）：
| 参数 |
值 |
说明 |
| Supi |
imsi-4608800000XXXXXX |
UE的签约永久标识（已脱敏） |
| data-type |
nssai |
请求数据类型为NSSAI |
响应消息（Nudm_SDM_Get Response）：
| 参数 |
示例值 |
说明 |
| Subscribed NSSAI |
[SST:1, SST:2, SST:1/SD:000001] |
UE签约的全部S-NSSAI列表 |
| Default NSSAI |
[SST:1, SST:2] |
运营商配置的默认S-NSSAI子集 |
4.3 Registration Accept消息参数
| 参数名称 |
是否携带 |
说明 |
| 5G-GUTI |
是 |
AMF分配的临时标识 |
| Allowed NSSAI |
是 |
网络授权的切片集合 |
| Configured NSSAI |
可选 |
网络配置的切片集合 |
| Rejected NSSAI |
否 |
本场景无被拒绝的切片 |
Allowed NSSAI示例：
Allowed NSSAI:
- S-NSSAI 1: SST=1 (eMBB)
- S-NSSAI 2: SST=2 (URLLC)
在本场景中，由于AMF支持UE的所有Default S-NSSAI，Allowed NSSAI等于Default NSSAI，不存在被拒绝的切片。
4.4 CLI验证数据（AMF侧）
以下是AMF上查询UE上下文的脱敏输出示例：
# AMF UE Context Query
IMSI: 4608800000XXXXXX
GPSI: 86138000XXXXXX
RM State: RM-REGISTERED
CM State: CM-CONNECTED
Serving AMF: AMF-1
GUAMI: PLMN(460-88), AMF Region(1), AMF Set(1), AMF Pointer(0)
Subscribed NSSAI:
[1] SST=1 (eMBB), SD=N/A
[2] SST=2 (URLLC), SD=N/A
[3] SST=1, SD=000001 (Custom-eMBB)
Default NSSAI:
[1] SST=1 (eMBB)
[2] SST=2 (URLLC)
Allowed NSSAI:
[1] SST=1 (eMBB)
[2] SST=2 (URLLC)
Configured NSSAI:
[1] SST=1 (eMBB)
[2] SST=2 (URLLC)
[3] SST=1, SD=000001 (Custom-eMBB)
NSSF Query: Not Required (AMF supports all Default S-NSSAI)
Target AMF Redirect: None
从上述输出可以看出，AMF在未查询NSSF的情况下，成功为UE生成了Allowed NSSAI。Allowed NSSAI等于Default NSSAI，说明AMF支持UE的所有默认签约切片。
5 测试验证与数据解读
5.1 验证要点
本场景的验证主要关注以下几个关键点：
验证点1：Registration Request不含Requested NSSAI
在NAS消息跟踪中确认UE发送的Registration Request消息中未携带Requested NSSAI信元。这是触发本场景处理逻辑的前提条件。
验证点2：AMF成功获取签约数据
在Nudm_SDM_Get接口跟踪中确认：
-
AMF向UDM成功发起Nudm_SDM_Get请求，路径包含/{supi}/nssai；
-
UDM返回200 OK，消息体中包含Subscribed NSSAI和Default NSSAI；
-
Default NSSAI中至少包含一个S-NSSAI。
验证点3：AMF未查询NSSF
在Nnssf_NSSelection_Get接口跟踪中确认该接口未被调用。这是判断AMF自行处理切片选择的关键证据。
验证点4：Registration Accept包含正确的Allowed NSSAI
在NAS消息跟踪中确认：
验证点5：UE上下文状态正确
在AMF上查询UE上下文，确认：
-
RM State为RM-REGISTERED；
-
Allowed NSSAI已正确保存。
5.2 数据解读
通过对消息跟踪数据的分析，可以得出以下结论：
-
AMF的切片匹配逻辑：AMF将Default NSSAI中的每个S-NSSAI与自身配置的支持列表进行逐一比对。本场景中，Default NSSAI包含SST=1（eMBB）和SST=2（URLLC），AMF的切片支持列表中也包含这两种SST值，匹配结果为全部支持。
-
Allowed NSSAI的生成规则：由于不存在不支持的情况，Allowed NSSAI直接等于Default NSSAI，无需任何过滤操作。这从侧面验证了AMF的交集运算逻辑是正确的。
-
Configured NSSAI的作用：虽然本场景中Configured NSSAI为可选下发，但建议在实际部署中始终下发，以便UE在后续注册或PDU会话建立时可以主动携带Requested NSSAI，提高切片选择效率。
5.3 常见异常与排查
| 异常现象 |
可能原因 |
排查方法 |
| UE注册失败 |
UDM签约数据未配置NSSAI |
检查UDM中UE的切片签约数据 |
| Allowed NSSAI为空 |
AMF配置的切片支持列表不包含Default NSSAI |
检查AMF的切片配置 |
| UE收到Rejected NSSAI |
AMF仅支持部分Default S-NSSAI |
检查AMF切片配置与签约数据的匹配情况 |
| NSSF被意外调用 |
AMF判断逻辑触发NSSF查询条件 |
检查运营商策略配置 |
6 小结与思考
6.1 本篇小结
本篇详细分析了5G切片选择中最基础的一个子场景：UE未携带Requested NSSAI，且AMF可以为所有默认签约S-NSSAI提供服务。在这个场景下：
-
AMF收到不携带Requested NSSAI的Registration Request后，向UDM获取签约数据；
-
AMF将Default NSSAI作为UE的隐式请求切片；
-
AMF检查自身能力，确认支持所有Default S-NSSAI后，直接生成Allowed NSSAI；
-
整个过程无需NSSF参与，流程最为简洁。
这是理解切片选择的起点。掌握了本场景中AMF的处理逻辑，后续理解NSSF参与的复杂场景将事半功倍。
6.2 延伸思考
思考1：为什么需要Default NSSAI？
Default NSSAI的存在确保了即使UE不携带Requested NSSAI，网络也能为其分配合适的切片。这是5G切片机制的一个重要设计理念：网络侧始终有兜底方案。在4G网络中，没有类似的切片概念，所有用户默认使用相同的"切片"（即PDN连接类型），而5G通过Default NSSAI实现了更加灵活的默认服务策略。
思考2：AMF如何知道自身支持哪些切片？
AMF在出厂配置或网管配置时，会设定自身支持的S-NSSAI列表。这个列表与GUAMI（Globally Unique AMF Identifier）关联。在NG Setup流程中，AMF会将GUAMI与支持切片的对应关系通知给RAN，以便RAN在后续Initial UE Message路由时可以基于切片信息选择合适的AMF。
思考3：与后续场景的对比预告
本场景是AMF独立处理的"理想"情况。在实际网络中，尤其是多AMF组网场景下，UE经常会被路由到不支持其请求切片的AMF。第7篇将讨论UE携带了Requested NSSAI但AMF无法提供服务的场景，第8篇将讨论UE未携带Requested NSSAI且AMF无法提供服务的场景。这两个场景都需要NSSF介入，流程将明显复杂化。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101