5G核心网学习平台
网络切片 实践篇 #18

5GC实践篇之切片篇第8篇:NSSF确定目标AMF与Allowed NSSAI(AMF未收到请求NSSAI且不能为所有默认签约S-NSSAI提供服务)

《5G核心网原理与实践》实践篇 · 网络切片 网元功能

5GC实践篇之切片篇第8篇:NSSF确定目标AMF与Allowed NSSAI(AMF未收到请求NSSAI,且不能为所有默认签约S-NSSAI提供服务)

作者:爱卫生


1 测试背景与用例简介

在本系列第6篇中,我们讨论了"AMF独立处理"的场景:UE未携带Requested NSSAI,AMF可以将Default NSSAI作为隐式请求,并成功为所有默认签约S-NSSAI提供服务。在第7篇中,UE携带了Requested NSSAI,但被路由到不支持请求切片的AMF,AMF需要向NSSF查询目标AMF。

本篇讨论的是第三个子场景,也是前两种场景的"交叉":UE未携带Requested NSSAI(与第6篇相同),但AMF无法为所有默认签约S-NSSAI提供服务(与第7篇相同),因此AMF需要向NSSF查询目标AMF信息。

这个场景的典型触发条件是:新开户用户首次开机注册,UE发送Registration Request时携带SUCI但不携带Requested NSSAI(因为终端没有任何已保存的切片信息)。由于NG-RAN的链路故障或AMF选择策略,UE被路由到AMF1,而AMF1不支持UE签约的Default NSSAI中的部分或全部S-NSSAI。此时,AMF1必须向NSSF查询,由NSSF确定目标AMF并生成Allowed NSSAI。

本场景的特别之处在于: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的处理逻辑如下:

  1. NSSF检查请求中的Subscribed S-NSSAI参数,获取UE的签约切片信息;

  2. NSSF从签约数据中识别Default NSSAI(通过签约数据中标记为default的S-NSSAI);

  3. NSSF计算Allowed NSSAI = Default NSSAI与NSSF配置的可用切片的交集;

  4. NSSF计算Configured NSSAI = Subscribed NSSAI与NSSF配置的NSSAI的交集;

  5. 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。消息中携带:

  • SUCI:UE的签约永久标识的加密形式;

  • 无Requested NSSAI:由于终端从未收到过Configured NSSAI,无法构造Requested NSSAI。

由于没有Requested NSSAI和GUTI可供参考,RAN无法基于切片或GUAMI信息选择AMF,只能根据默认策略(如负载均衡)选择AMF。

步骤2:RAN路由到Initial AMF

本场景的触发条件是RAN将UE路由到一个不支持UE默认签约切片的AMF。例如:

  • RAN的AMF选择策略为轮询负载均衡,不区分切片能力;

  • 或者AMF2(支持Default NSSAI)暂时不可达,RAN将UE路由到AMF1。

步骤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执行以下判断:

  1. UE未携带Requested NSSAI,AMF将Default NSSAI [SST=1, SST=2] 作为隐式请求;

  2. AMF检查自身切片支持列表,例如AMF1仅支持[SST=1];

  3. AMF发现Default NSSAI中的SST=2(URLLC)不在自身支持列表中;

  4. 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为空时的处理逻辑:

  1. NSSF从Subscribed S-NSSAI中提取Default NSSAI(标记为default的S-NSSAI);

  2. NSSF计算Allowed NSSAI = Default NSSAI与NSSF配置的可用切片的交集;

  3. NSSF计算Configured NSSAI = Subscribed NSSAI与NSSF配置的NSSAI的交集;

  4. 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日志中确认:

  • AMF成功从UDM获取签约数据;

  • AMF正确将Default NSSAI作为隐式请求;

  • AMF检测到SST=2不在自身支持列表中。

验证点4:NSSF正确处理空Requested NSSAI

在Nnssf_NSSelection_Get接口跟踪中确认:

  • 请求消息中Requested NSSAI为空;

  • NSSF仍然能返回正确的Allowed NSSAI和目标AMF信息;

  • Allowed NSSAI基于Default NSSAI生成。

验证点5:注册最终成功

在Target AMF上确认:

  • UE的RM State为RM-REGISTERED;

  • Allowed NSSAI和Configured NSSAI已正确保存并下发。

5.2 数据解读

通过分析消息跟踪数据,可以得出以下关键结论:

  1. AMF的Default NSSAI匹配逻辑:与第7篇不同,本场景中AMF不需要处理UE的Requested NSSAI,而是直接将Default NSSAI作为匹配基准。这简化了AMF侧的判断逻辑,但增加了对签约数据准确性的依赖。

  2. NSSF在空请求下的处理能力:NSSF在Requested NSSAI为空时,能够基于签约数据中的Default标记自动识别默认切片,并以此为基准生成Allowed NSSAI。这说明NSSF的实现必须具备解析签约数据中Default标记的能力,而不仅仅是做简单的集合交集运算。

  3. 新用户注册的特殊性:新用户首次注册是一个重要场景。运营商应确保新用户的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提供服务。关键流程包括:

  1. 新用户首次注册,UE携带SUCI但不携带Requested NSSAI;

  2. RAN将UE路由到不支持其Default NSSAI的AMF;

  3. AMF从UDM获取签约数据,将Default NSSAI作为隐式请求,判断自身无法提供服务;

  4. AMF向NSSF查询,请求中Requested NSSAI为空,NSSF基于签约数据生成Allowed NSSAI并确定目标AMF;

  5. 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+文章等你来。

← 返回 网络切片 实践篇