本场景的特别之处在于:NSSF收到的请求中Requested NSSAI为空。NSSF需要在没有UE明确请求的情况下,基于UE的签约数据和NSSF配置,独立决定Allowed NSSAI和目标AMF。这比第7篇中NSSF有明确的Requested NSSAI可供参考的情况更具挑战性。
理解这三个子场景(第6/7/8篇)的异同,是掌握5G切片选择全貌的关键。
2 协议规范与关键技术
2.1 相关协议规范
本篇涉及的协议规范与第7篇基本相同,但在NSSF处理逻辑上存在重要差异:
-
TS 23.501 第5.15节:网络切片选择框架。特别关注当Requested NSSAI为空时,NSSF如何基于签约数据做出切片选择决策。
-
TS 23.502 第4.2.2.2.2节:注册过程中的切片选择流程。步骤4中AMF将Default NSSAI作为隐式请求后,步骤5触发NSSF查询。
-
TS 29.531:NSSF服务的API定义。重点关注Nnssf_NSSelection_Get请求中Requested NSSAI为空时NSSF的处理行为。
-
TS 29.510:NRF服务接口,用于AMF发现目标AMF。
-
TS 29.518:AMF服务接口,用于AMF间NAS消息转发。
-
TS 29.503:UDM服务接口,Nudm_SDM_Get获取签约NSSAI数据。
-
TS 38.413:NGAP协议,NG Setup流程中的AMF切片能力交互。
2.2 关键技术差异:本场景 vs 第7篇
本场景与第7篇的核心差异体现在以下方面:
| 差异维度 |
第7篇 |
本篇(第8篇) |
| UE是否携带Requested NSSAI |
是 |
否 |
| AMF触发NSSF查询的原因 |
AMF不支持Requested NSSAI中的S-NSSAI |
AMF不支持Default NSSAI中的S-NSSAI |
NSSF收到的Requested NSSAI: 非空 |
为空 |
| NSSF生成Allowed NSSAI的依据 |
Requested NSSAI与Subscribed NSSAI的交集 |
Default NSSAI与Subscribed NSSAI的交集 |
| 隐式请求的生成方 |
不需要(UE已明确请求) |
AMF(将Default NSSAI作为隐式请求) |
2.3 Requested NSSAI为空时NSSF的处理逻辑
当NSSF收到的Nnssf_NSSelection_Get请求中Requested NSSAI为空时,NSSF的处理逻辑如下:
-
NSSF检查请求中的Subscribed S-NSSAI参数,获取UE的签约切片信息;
-
NSSF从签约数据中识别Default NSSAI(通过签约数据中标记为default的S-NSSAI);
-
NSSF计算Allowed NSSAI = Default NSSAI与NSSF配置的可用切片的交集;
-
NSSF计算Configured NSSAI = Subscribed NSSAI与NSSF配置的NSSAI的交集;
-
NSSF根据Allowed NSSAI查找支持这些切片的AMF集合。
注意:NSSF在Requested NSSAI为空时,不会直接使用全部Subscribed NSSAI作为Allowed NSSAI,而是以Default NSSAI为基准。这是因为Default NSSAI是运营商为UE配置的"最小可用切片集",在没有UE明确请求的情况下,网络应按照运营商预设的默认策略服务UE。
3 消息流程与详细解读
3.1 整体流程概览
sequenceDiagram
participant UE
participant RAN as NG-RAN
participant IAMF as Initial AMF
participant NSSF
participant NRF
participant TAMF as Target AMF
participant UDM
UE->>RAN: RRC Connection + NAS Registration Request(SUCI)
Note over UE,RAN: 未携带Requested NSSAI
Note over UE,RAN: 新开户用户首次注册
RAN->>IAMF: Initial UE Message(NAS Registration Request)
Note over RAN,IAMF: RAN因链路故障路由到
不支持Default NSSAI的AMF
IAMF->>UDM: Nudm_SDM_Get(SUPI/NSSAI)
Note over IAMF,UDM: 步骤3a:获取UE签约切片数据
UDM-->>IAMF: Nudm_SDM_Get Response(Subscribed NSSAI + Default NSSAI)
Note over IAMF: 步骤4:将Default NSSAI作为隐式请求
判断本AMF无法提供
所有Default S-NSSAI服务
IAMF->>NSSF: Nnssf_NSSelection_Get(Requested NSSAI为空, Subscribed S-NSSAI, PLMN ID, TAI, NF Type)
Note over IAMF,NSSF: 步骤5a:向NSSF查询
Requested NSSAI为空
NSSF-->>IAMF: Nnssf_NSSelection_Get Response(AuthorizedNetworkSliceInfo)
Note over NSSF,IAMF: 步骤5b:NSSF基于签约数据
返回目标AMF和Allowed NSSAI
IAMF->>NRF: Nnrf_NFDiscovery_Request
Note over IAMF,NRF: 步骤6a:查询目标AMF地址
NRF-->>IAMF: Nnrf_NFDiscovery_Response
alt 方式一:AMF直接转发
IAMF->>TAMF: Namf_Communication_N1MessageNotify(NAS Registration Request)
else 方式二:通过RAN转发
IAMF->>RAN: N2 Message(Reroute NAS Message)
RAN->>TAMF: Initial UE Message(NAS Registration Request)
end
Note over TAMF: Target AMF继续Registration流程
TAMF->>RAN: Registration Accept(Allowed NSSAI, Configured NSSAI)
RAN->>UE: NAS Registration Accept
3.2 流程详细解读
步骤1:UE发起不带Requested NSSAI的注册请求
本场景中,UE为新开户用户,首次发起Registration Request。消息中携带:
由于没有Requested NSSAI和GUTI可供参考,RAN无法基于切片或GUAMI信息选择AMF,只能根据默认策略(如负载均衡)选择AMF。
步骤2:RAN路由到Initial AMF
本场景的触发条件是RAN将UE路由到一个不支持UE默认签约切片的AMF。例如:
步骤3:Initial AMF获取签约数据
Initial AMF收到Registration Request后,由于是首次注册,本地没有UE的任何上下文。AMF向UDM发起Nudm_SDM_Get请求,路径为/{supi}/nssai,获取UE签约的NSSAI数据。
UDM返回的数据中包含Subscribed NSSAI和Default NSSAI。例如:
-
Subscribed NSSAI: [SST=1(eMBB), SST=2(URLLC), SST=1/SD=000001(Custom-eMBB)]
-
Default NSSAI: [SST=1(eMBB), SST=2(URLLC)]
步骤4:Initial AMF判断无法提供服务
这是本场景的关键决策步骤。Initial AMF执行以下判断:
-
UE未携带Requested NSSAI,AMF将Default NSSAI [SST=1, SST=2] 作为隐式请求;
-
AMF检查自身切片支持列表,例如AMF1仅支持[SST=1];
-
AMF发现Default NSSAI中的SST=2(URLLC)不在自身支持列表中;
-
AMF判定无法为UE提供完整的默认切片服务,需要向NSSF查询。
与第7篇不同的是,这里的"不匹配"不是UE的明确请求与AMF能力之间的矛盾,而是运营商为UE预设的默认切片与AMF能力之间的矛盾。从网络运营角度看,这种情况更需要重视,因为它意味着即使UE没有提出任何特殊切片需求,网络也无法满足运营商设定的基本服务承诺。
步骤5:Initial AMF向NSSF查询(Requested NSSAI为空)
Initial AMF调用Nnssf_NSSelection_Get服务操作。本场景的关键特征是Requested NSSAI参数为空:
请求参数:
-
Requested NSSAI:空(这是与第7篇的核心区别)
-
Subscribed S-NSSAI:[SST=1, SST=2, SST=1/SD=000001]
-
PLMN ID of SUPI:460-88(可选)
-
TAI:UE当前跟踪区域
-
NF Type:AMF
步骤5b:NSSF响应(Requested NSSAI为空的处理)
NSSF在Requested NSSAI为空时的处理逻辑:
-
NSSF从Subscribed S-NSSAI中提取Default NSSAI(标记为default的S-NSSAI);
-
NSSF计算Allowed NSSAI = Default NSSAI与NSSF配置的可用切片的交集;
-
NSSF计算Configured NSSAI = Subscribed NSSAI与NSSF配置的NSSAI的交集;
-
NSSF根据Allowed NSSAI查找目标AMF。
响应参数:
-
Allowed NSSAI: [SST=1, SST=2]
-
Configured NSSAI: [SST=1, SST=2, SST=1/SD=000001]
-
Target AMF: AMF-Set-2(支持SST=1和SST=2的AMF集合)
步骤6-8:与第7篇相同
查询NRF获取目标AMF地址,选择重定向方式(直接转发或RAN转发),目标AMF继续注册流程。这些步骤与第7篇完全一致。
3.3 AMF内部决策流程
flowchart TD
A[收到Registration Request] --> B[检查Requested NSSAI]
B --> C[Requested NSSAI为空]
C --> D[向UDM获取签约数据]
D --> E[获取Subscribed NSSAI和Default NSSAI]
E --> F[将Default NSSAI作为隐式Requested NSSAI]
F --> G[检查本AMF是否支持所有Default S-NSSAI]
G --> H[不支持:需查询NSSF]
G --> I[支持:AMF可独立处理 - 见第6篇]
H --> J[调用Nnssf_NSSelection_Get]
Note right of J: Requested NSSAI参数为空
J --> K[获取目标AMF和Allowed NSSAI]
K --> L[查询NRF获取目标AMF地址]
L --> M[选择重定向方式]
M --> N[方式一:AMF直接转发]
M --> O[方式二:通过RAN转发]
N --> P[Target AMF继续注册流程]
O --> P
P --> Q[注册完成]
4 关键信令参数分析
4.1 Registration Request消息参数
| 参数名称 |
是否携带 |
说明 |
| SUCI |
是 |
新开户用户首次注册,使用SUCI标识 |
| Requested NSSAI |
否 |
本场景关键特征:UE未携带请求切片信息 |
| 5G-GUTI |
否 |
首次注册无GUTI |
| Registration Type |
是 |
初始注册 |
| UE security capability |
是 |
UE支持的安全算法列表 |
4.2 Nudm_SDM_Get请求/响应参数
请求消息:
| 参数 |
值 |
说明 |
| Supi |
imsi-4608800000XXXXXX |
UE的签约永久标识(已脱敏) |
| data-type |
nssai |
请求数据类型为NSSAI |
响应消息(200 OK):
| 参数 |
示例值 |
说明 |
| Subscribed NSSAI |
[SST:1, SST:2, SST:1/SD:000001] |
UE签约的全部S-NSSAI |
| Default NSSAI |
[SST:1, SST:2] |
标记为default的S-NSSAI子集 |
4.3 Nnssf_NSSelection_Get请求/响应参数
请求消息(注意Requested NSSAI为空):
| Requested-NSSAI | 空 | 本场景核心特征:UE未请求任何切片
| Subscribed-S-NSSAI |
[SST:1, SST:2, SST:1/SD:000001] |
UE签约的切片集合 |
| PLMN-ID |
460-88 |
SUPI所属PLMN(可选) |
| TAI |
TAC=0001, PLMN=460-88 |
UE当前跟踪区域 |
| NF-Type |
AMF |
请求方网元类型 |
响应消息(AuthorizedNetworkSliceInfo):
| 参数 |
示例值 |
说明 |
| Allowed NSSAI |
[SST:1, SST:2] |
NSSF基于Default NSSAI生成 |
| Configured NSSAI |
[SST:1, SST:2, SST:1/SD=000001] |
签约与NSSF配置的交集 |
| Target AMF Set |
AMF-Set-2 |
目标AMF集合标识 |
4.4 CLI验证数据
Initial AMF日志(脱敏):
# Initial AMF - Slice Selection Log
Time: 2026-04-17 14:20:30.567
SUPI: imsi-4608800000XXXXXX
GPSI: 86138000XXXXXX
Received Registration Request:
SUCI: (concealed)
Requested NSSAI: Not Present
Registration Type: Initial Registration
Note: New subscriber, no previous context
AMF Slice Support: [SST=1]
Default NSSAI from UDM: [SST=1, SST=2]
Default S-NSSAI not supported by this AMF: SST=2
Action: Query NSSF for target AMF
Nnssf_NSSelection_Get Request:
Requested-NSSAI: EMPTY
Subscribed-S-NSSAI: [SST=1, SST=2, SST=1/SD=000001]
TAI: TAC=0001, PLMN=460-88
NF-Type: AMF
Nnssf_NSSelection_Get Response (200 OK):
Allowed NSSAI: [SST=1, SST=2]
Configured NSSAI: [SST=1, SST=2, SST=1/SD=000001]
Target AMF: AMF-Set-2
NRF Discovery:
Target AMF Address: 10.0.1.52 (amf2.5gc.mnc088.mcc460.3gppnetwork.org)
Action: Redirect to Target AMF via AMF direct forwarding
Target AMF日志(脱敏):
# Target AMF - Registration Processing
Time: 2026-04-17 14:20:30.890
SUPI: imsi-4608800000XXXXXX
Source: Initial AMF (Direct Forwarding)
Received Redirected Registration Request:
NAS: Registration Request (SUCI)
Allowed NSSAI from NSSF: [SST=1, SST=2]
AMF Slice Support: [SST=1, SST=2]
All Default S-NSSAI supported: YES
Action: Continue Registration Processing
[Authentication and Security Mode procedures...]
Registration Accept Sent:
GUTI: 460-88-2-1-0-0000000003
Allowed NSSAI: [SST=1, SST=2]
Configured NSSAI: [SST=1, SST=2, SST=1/SD=000001]
UE RM State: RM-REGISTERED
5 测试验证与数据解读
5.1 验证要点
验证点1:Registration Request不含Requested NSSAI
在NAS消息跟踪中确认UE发送的Registration Request中未携带Requested NSSAI信元。同时确认消息中携带了SUCI(非GUTI),表明这是新用户的首次注册。
验证点2:RAN将消息路由到不支持Default NSSAI的AMF
通过构造以下测试条件:
-
AMF1配置为不支持SST=2(URLLC)切片;
-
UE在UDM的签约数据中Default NSSAI包含SST=2;
-
确保RAN将UE路由到AMF1(可通过配置RAN的默认AMF选择策略或模拟链路故障)。
验证点3:AMF正确识别切片不匹配
在Initial AMF日志中确认:
验证点4:NSSF正确处理空Requested NSSAI
在Nnssf_NSSelection_Get接口跟踪中确认:
验证点5:注册最终成功
在Target AMF上确认:
5.2 数据解读
通过分析消息跟踪数据,可以得出以下关键结论:
-
AMF的Default NSSAI匹配逻辑:与第7篇不同,本场景中AMF不需要处理UE的Requested NSSAI,而是直接将Default NSSAI作为匹配基准。这简化了AMF侧的判断逻辑,但增加了对签约数据准确性的依赖。
-
NSSF在空请求下的处理能力:NSSF在Requested NSSAI为空时,能够基于签约数据中的Default标记自动识别默认切片,并以此为基准生成Allowed NSSAI。这说明NSSF的实现必须具备解析签约数据中Default标记的能力,而不仅仅是做简单的集合交集运算。
-
新用户注册的特殊性:新用户首次注册是一个重要场景。运营商应确保新用户的Default NSSAI与网络部署的AMF切片能力相匹配,否则新用户可能无法完成注册。
5.3 三场景完整对比
| 对比维度 |
第6篇 |
第7篇 |
本篇(第8篇) |
| UE携带Requested NSSAI |
否 |
是 |
否 |
| AMF能否服务请求切片 |
能(Default NSSAI) |
不能(Requested NSSAI) |
不能(Default NSSAI) |
| 是否查询NSSF |
否 |
是 |
是 |
| NSSF收到的Requested NSSAI |
N/A |
非空 |
空 |
| Allowed NSSAI生成依据 |
Default NSSAI与AMF交集 |
Requested NSSAI与签约交集 |
Default NSSAI与NSSF配置交集 |
| 是否需要AMF重定向 |
否 |
是 |
是 |
6 小结与思考
6.1 本篇小结
本篇详细分析了5G切片选择的第三个子场景:UE未携带Requested NSSAI,且AMF无法为所有默认签约S-NSSAI提供服务。关键流程包括:
-
新用户首次注册,UE携带SUCI但不携带Requested NSSAI;
-
RAN将UE路由到不支持其Default NSSAI的AMF;
-
AMF从UDM获取签约数据,将Default NSSAI作为隐式请求,判断自身无法提供服务;
-
AMF向NSSF查询,请求中Requested NSSAI为空,NSSF基于签约数据生成Allowed NSSAI并确定目标AMF;
-
AMF重定向到目标AMF,完成注册。
至此,第6/7/8三篇构成了AMF/NSSF确定目标AMF与Allowed NSSAI的完整知识体系,覆盖了全部三种子场景。
6.2 延伸思考
思考1:新用户注册失败的常见原因
在实际部署中,新用户注册失败的一个常见原因是:运营商在UDM中为新用户配置了Default NSSAI,但网络中没有部署支持所有Default S-NSSAI的AMF。例如,运营商在Default NSSAI中包含了URLLC(SST=2),但只部署了支持eMBB(SST=1)的AMF。这种情况下,即使用户处于网络覆盖范围内,也无法完成注册。建议运营商在规划切片部署时,确保Default NSSAI中的每个S-NSSAI都有对应的AMF支持。
思考2:为什么NSSF不直接使用全部Subscribed NSSAI作为Allowed NSSAI?
如果NSSF在Requested NSSAI为空时使用全部Subscribed NSSAI作为Allowed NSSAI,可能导致UE被授权使用其不需要或不应该默认使用的切片。Default NSSAI的设计确保了UE在没有任何明确请求时,只获得运营商为其配置的"最小必要切片集",这是一种最小权限原则的体现。
思考3:后续预告
第9篇和第10篇将从切片选择转向切片拒绝场景:AMF如何拒绝UE请求的未签约S-NSSAI。第9篇讨论注册过程中的拒绝,第10篇讨论PDU会话建立过程中的拒绝。这两个场景将展示5G切片机制中的另一个重要维度:安全与策略控制。
51学通信(微信:gprshome201101)——专注5G核心网与IMS技术教学,已帮助10000+通信工程师提升技能。知识星球搜"51学通信",200+小时视频+3000+文章等你来。