# 5G NSSF网络切片选择与S-NSSAI映射全链拆解 网络切片是5G系统区别于4G的核心特性之一，而**NSSF（Network Slice Selection Function）**作为切片选择的"裁判官"，决定了UE能否接入正确的切片实例。本文将深入拆解NSSF如何通过S-NSSAI执行切片选择、Allowed NSSAI的确定逻辑、HPLMN-VPLMN的S-NSSAI映射机制，以及AMF与NSSF之间的完整SBI交互信令流。核心规范依据：**TS 23.501 Section 5.15**（切片架构定义）、**TS 23.502 Section 4.2.2.2**（注册流程中的切片选择）、**TS 29.531**（Nnssf服务定义）。 --- ## 一、S-NSSAI数据结构：切片标识的最小单元 ### 1.1 S-NSSAI编码格式 S-NSSAI（Single Network Slice Selection Assistance Information）是5G系统中标识一个网络切片的基本数据结构，定义于**TS 23.501 Section 5.15.2.1**。 | 字段 | 长度 | 必选/可选 | 说明 | |------|------|----------|------| | **SST（Slice/Service Type）** | 8 bits | 必选 | 标准化切片服务类型，标识切片的宏观业务类别 | | **SD（Slice Differentiator）** | 24 bits | 可选 | 在同一SST值内进一步区分不同切片实例 | SST的8位长度意味着最多256种标准化切片类型。3GPP在**TS 23.501 Section 5.15.2.2**中定义了4种标准化SST值： | SST值 | 切片类型 | 典型业务场景 | |-------|---------|------------| | **1** | eMBB | 高清视频、大文件下载、VR/AR | | **2** | URLLC | 工业自动化、远程手术、智能电网 | | **3** | MIoT | 传感器网络、智慧城市、海量设备连接 | | **4** | V2X | 车联网、自动驾驶、车辆编队 | 运营商可使用值128~127（标准化范围之外的SST值）定义自己的非标准化切片。当同一SST下需要区分多个切片时，通过SD字段实现——例如SST=1、SD=0x010203与SST=1、SD=0x040506虽然同为eMBB切片，但对应完全不同的切片实例和资源隔离策略。 ### 1.2 六种NSSAI类型及其生命周期 5G系统中定义了6种NSSAI（Network Slice Selection Assistance Information），它们在UE注册和会话管理生命周期中扮演不同角色，定义于**TS 23.501 Section 5.15.2**和**Section 5.15.4**： ```mermaid flowchart TB subgraph 签约阶段 A[UDM/UDR
Subscribed S-NSSAI
用户签约切片列表] --> B[Default S-NSSAI
标记为默认的签约切片] end subgraph 注册阶段 C[Configured NSSAI
HPLMN或VPLMN配置的可用切片] --> D[Requested NSSAI
UE在Registration Request中携带] D --> E[NSSF切片选择] A --> E E --> F[Allowed NSSAI
当前TA中允许使用的切片] E --> G[Rejected NSSAI
被拒绝的切片] end subgraph 会话阶段 F --> H[PDU Session建立
使用Allowed NSSAI中的S-NSSAI] end style A fill:#e1f5fe style F fill:#c8e6c9 style G fill:#ffcdd2 style E fill:#fff9c4 ``` | NSSAI类型 | 生成方 | 下发时机 | 核心作用 | |-----------|-------|---------|---------| | **Subscribed S-NSSAI(s)** | UDM/UDR | AMF通过Nudm_SDM_Get获取 | 用户签约的切片全集，包含Default标记 | | **Default S-NSSAI(s)** | UDM（签约数据标记） | 随Subscribed NSSAI获取 | 当UE未请求特定切片时自动使用 | | **Configured NSSAI** | AMF/NSSF | Registration Accept中下发 | UE在当前PLMN可使用的S-NSSAI集合 | | **Requested NSSAI** | UE | Registration Request中携带 | UE主动请求使用的切片列表 | | **Allowed NSSAI** | AMF（基于NSSF决策） | Registration Accept中下发 | 当前TA+接入类型下实际允许的切片 | | **Rejected NSSAI** | AMF | Registration Accept/Reject中携带 | PLMN级或TA级被拒绝的切片 | **设计意图**：这种分层设计确保了（1）运营商通过签约数据控制用户可用切片的边界；（2）网络通过NSSF根据当前TA资源状况动态决定实际可用的切片；（3）UE只需关心Allowed NSSAI，无需感知底层切片实例的具体拓扑。 --- ## 二、NSSF在注册流程中的完整信令交互 ### 2.1 注册流程中NSSF切片选择时序图 以下时序图展示了非漫游场景下，AMF在初始注册过程中调用NSSF执行切片选择的完整信令流（基于**TS 23.502 Section 4.2.2.2**）： ```mermaid sequenceDiagram participant UE participant RAN as (R)AN participant AMF participant NSSF participant UDM participant NRF UE->>RAN: NAS Registration Request
Requested NSSAI=[SST:1, SST:2] RAN->>AMF: N2 Initial UE Message
含Requested NSSAI + TAI rect rgb(255, 243, 224) Note over AMF: Step 1: AMF本地检查
Requested NSSAI是否全部在Supported NSSAI中 end AMF->>UDM: Nudm_SDM_Get(supi, dataTypeId=nssai) UDM-->>AMF: Subscribed S-NSSAI(s)
=[{SST:1,SD:001(Default)}, {SST:2}, {SST:3}] rect rgb(232, 245, 233) Note over AMF,NSSF: Step 2: AMF调用NSSF进行切片选择 end AMF->>NSSF: GET /nnssf-nsselection/v1/network-slice-information
?nf-type=AMF&nf-id=amf-001
&slice-info-request-for-registration={...}
&tai={PLMN-46000,TAC-1234} rect rgb(255, 249, 196) Note over NSSF: Step 3: NSSF切片选择算法
Requested ∩ Subscribed ∩ TA-Supported end NSSF-->>AMF: 200 OK
{allowedNssai, targetAmfSet,
rejectedNssaiInTa, nsiInformationList} rect rgb(227, 242, 253) Note over AMF: Step 4: 判断是否需要AMF重定向
当前AMF是否在targetAmfSet中 end alt 当前AMF在targetAmfSet中 AMF->>UE: Registration Accept
Allowed NSSAI=[{SST:1,SD:001}] else 当前AMF不在targetAmfSet中 AMF->>RAN: Namf_Communication_N2InfoTransfer
触发AMF重定向 RAN->>AMF: 路由到targetAmfSet中的新AMF AMF->>UE: Registration Accept
Allowed NSSAI=[{SST:1,SD:001}] end ``` ### 2.2 Nnssf_NSSelection_Get请求消息关键IE详解 **Nnssf_NSSelection_Get**是NSSF提供的核心SBI服务操作（定义于**TS 29.531 Section 6**），使用HTTP GET方法，URI为`/network-slice-information`。 **注册场景请求参数表**（SliceInfoForRegistration结构）： | 参数名 | 类型 | 必选 | TS 29.531章节 | 说明 | |-------|------|------|-------------|------| | `nf-type` | NFType | M | 6.1.5.2 | 发起请求的NF类型，注册场景为`AMF` | | `nf-id` | NfInstanceId | M | 6.1.5.2 | AMF实例的NF Instance ID | | `slice-info-request-for-registration` | SliceInfoForRegistration | C | 6.1.5.2.2 | 注册场景专用，包含签约和请求的NSSAI | | `tai` | Tai | C | 6.1.5.2 | 当前跟踪区标识，NSSF按TA评估切片可用性 | | `home-plmn-id` | PlmnId | C(漫游) | 6.1.5.2 | 漫游时HPLMN标识 | | `target-plmn-id` | PlmnId | O | 6.1.5.2 | 目标PLMN标识 | | `roaming-indication` | RoamingIndication | C(漫游) | 6.1.5.2 | 漫游类型指示 | **SliceInfoForRegistration内部结构**（TS 29.531 Section 6.1.6.2.4）： | 字段 | 类型 | 说明 | |------|------|------| | `subscribedNssai` | array(Nssai) | 从UDM获取的签约NSSAI列表 | | `requestedNssai` | array(Snssai) | UE在Registration Request中携带的请求NSSAI | | `defaultConfiguredNssaiIndication` | boolean | 指示是否使用默认配置NSSAI | | `mappingOfNssai` | array(NssaiMapping) | HPLMN-VPLMN S-NSSAI映射关系表 | | `supportedFeatures` | SupportedFeatures | 特性协商 | ### 2.3 Nnssf_NSSelection_Get响应消息关键IE详解 **成功响应（200 OK）参数表**（TS 29.531 Section 6.2.2）： | 参数名 | 类型 | 说明 | |-------|------|------| | `allowedNssai` | AllowedNssai | **按接入类型分别返回**的Allowed NSSAI列表 | | `targetAmfSet` | string | 目标AMF Set标识，用于AMF重定向 | | `candidateAmfList` | array(AmfInfo) | 候选AMF实例列表 | | `rejectedNssaiInPlmn` | array(Snssai) | **PLMN级别**被拒绝的S-NSSAI | | `rejectedNssaiInTa` | array(Snssai) | **TA级别**被拒绝的S-NSSAI | | `configuredNssai` | Nssai | 为UE配置的NSSAI | | `mappingOfNssai` | array(NssaiMapping) | HPLMN-VPLMN S-NSSAI映射关系 | | `nsiInformationList` | array(NsiInformation) | 网络切片实例信息列表 | | `networkSliceInfoValue` | NetworkSliceInfo | 切片信息值 | **NsiInformation结构**（TS 29.531 Section 6.1.6.2.8）是连接切片选择与NF发现的关键桥梁： | 字段 | 类型 | 说明 | |------|------|------| | `nrfId` | string | 管理该NSI的NRF的URI | | `nsiId` | string | 网络切片实例的唯一标识 | **设计意图**：NsiInformation中返回的NRF地址是"切片专属NRF"——AMF拿到这个NRF地址后，会向其发起SMF发现请求，从而确保选择的SMF属于正确的网络切片实例。这是5G实现切片隔离的核心机制之一。 --- ## 三、NSSF切片选择算法：Allowed NSSAI的确定逻辑 ### 3.1 非漫游场景Allowed NSSAI计算 NSSF确定Allowed NSSAI的核心算法是一个**三重交集**运算： ``` Allowed NSSAI = Requested NSSAI ∩ Subscribed S-NSSAI(s) ∩ TA-Supported S-NSSAI(s) ``` ```mermaid flowchart TD A[输入: Requested NSSAI
从UE获取] --> D{NSSF切片选择算法} B[输入: Subscribed S-NSSAI
从UDM获取] --> D C[输入: TA-Supported S-NSSAI
NSSF本地配置] --> D D --> E[三重交集运算] E --> F{交集是否为空?} F -->|非空| G[Allowed NSSAI = 交集结果] G --> H[计算Rejected NSSAI
= Requested - Allowed] H --> I[确定targetAmfSet
支持Allowed NSSAI的AMF集合] I --> J[返回NsiInformationList
每个S-NSSAI对应的NSI信息] F -->|为空| K{是否存在Default S-NSSAI?} K -->|是| L[Allowed NSSAI = Default S-NSSAI] K -->|否| M[返回错误
无可用切片] style G fill:#c8e6c9 style L fill:#fff9c4 style M fill:#ffcdd2 style D fill:#e1bee7 ``` **具体示例**： 假设： - Subscribed S-NSSAI = `[{SST:1, SD:001, Default=true}, {SST:2}, {SST:3, SD:010}]` - Requested NSSAI = `[{SST:1}, {SST:2}, {SST:4}]` - TA(TAC=1234) Supported = `[{SST:1, SD:001}, {SST:2}, {SST:5}]` 计算过程： 1. **Requested ∩ Subscribed** = `[{SST:1}, {SST:2}]`（SST:4不在签约中，被过滤） 2. **结果 ∩ TA-Supported** = `[{SST:1, SD:001}, {SST:2}]`（SST:1匹配到带SD的签约切片） 3. **Allowed NSSAI** = `[{SST:1, SD:001}, {SST:2}]` 4. **Rejected in TA** = `[{SST:4}]`（非签约切片） 5. **targetAmfSet** = 支持SST:1和SST:2的AMF集合 ### 3.2 漫游场景：HPLMN-VPLMN S-NSSAI映射 漫游场景下的切片选择需要额外的**S-NSSAI映射**步骤（定义于**TS 23.501 Section 5.15.6**），这是NSSF功能中最复杂的部分。 ```mermaid sequenceDiagram participant UE participant VAMF as V-AMF participant VNSSF as V-NSSF participant UDM as H-UDM UE->>VAMF: Registration Request
Requested NSSAI(VPLMN)=[{SST:1}] VAMF->>UDM: Nudm_SDM_Get UDM-->>VAMF: Subscribed S-NSSAI(HPLMN)
=[{SST:1,SD:100},{SST:2,SD:200}] rect rgb(255, 243, 224) Note over VAMF,VNSSF: 漫游场景NSSF切片选择 end VAMF->>VNSSF: Nnssf_NSSelection_Get
home-plmn-id={460,00}
target-plmn-id={460,01}
roaming-indication=ROAMING
mappingOfNssai=[{hplmn:{SST:1,SD:100}↔vplmn:{SST:1}}] rect rgb(232, 245, 233) Note over VNSSF: Step 1: VPLMN S-NSSAI→HPLMN S-NSSAI映射
{SST:1}→{SST:1,SD:100}
Step 2: 映射结果∩Subscribed
={SST:1,SD:100} ✓
Step 3: 映射回VPLMN S-NSSAI
={SST:1}
Step 4: ∩VPLMN TA-Supported end VNSSF-->>VAMF: allowedNssai=[{SST:1}]
mappingOfNssai=[{hplmn:{SST:1,SD:100}↔vplmn:{SST:1}}]
configuredNssai(for VPLMN) VAMF->>UE: Registration Accept
Allowed NSSAI(VPLMN)=[{SST:1}]
Configured NSSAI(for VPLMN) ``` **NssaiMapping结构**（TS 29.531 Section 6.1.6.2.9）： | 字段 | 类型 | 说明 | |------|------|------| | `hplmnS-nssai` | Snssai | HPLMN中的S-NSSAI | | `vplmnS-nssai` | Snssai | VPLMN中映射后的S-NSSAI | | `mappedHomeSnssai` | Snssai | VPLMN向HPLMN映射回的S-NSSAI | **为什么需要映射？** 因为不同运营商可能对同一类业务使用不同的SST/SD编码。例如HPLMN的URLLC切片用`{SST:2, SD:100}`，而VPLMN可能仅用`{SST:2}`，或者两个运营商的私有SST完全不同。映射关系由NSSF的本地配置或运营商间的漫游协议决定。 --- ## 四、NSSF的两大SBI服务全景 ### 4.1 Nnssf_NSSelection服务 vs Nnssf_NSSAIAvailability服务 NSSF提供两个SBI服务（TS 29.531），分别服务于不同场景： | 维度 | Nnssf_NSSelection | Nnssf_NSSAIAvailability | |------|-------------------|------------------------| | **参考点** | N22（AMF-NSSF） | N22（AMF-NSSF） | | **核心功能** | 切片选择决策 | NSSAI可用性管理 | | **调用方** | AMF | AMF | | **调用时机** | 注册、PDU会话建立 | TA变更、NF状态变化 | | **服务操作数** | 1个（Get） | 4个（Get/Update/Subscribe/Unsubscribe） | | **TS 29.531章节** | Section 5-8 | Section 9-12 | | **输出** | Allowed NSSAI + NSI信息 | 可用NSSAI列表 + 变更通知 | ### 4.2 Nnssf_NSSAIAvailability服务操作详解 | 操作 | HTTP方法 | URI | 说明 | |------|---------|-----|------| | **Get** | GET | `/nssai-availability` | 查询指定AMF的NSSAI可用性 | | **Update** | PUT | `/nssai-availability/{amfId}` | AMF更新其支持的NSSAI可用性信息 | | **Subscribe** | POST | `/nssai-availability/subscriptions` | 订阅NSSAI可用性变更通知 | | **Unsubscribe** | DELETE | `/nssai-availability/subscriptions/{subId}` | 取消订阅 | | **Notify** | POST（回调） | NRF→AMF的通知URI | NSSAI可用性变更时通知订阅者 | **设计意图**：Nnssf_NSSAIAvailability的订阅/通知机制实现了**动态切片可用性管理**。当某个TA的切片资源状况发生变化（如切片负载过高需要限制新接入），NSSF可以通过通知机制主动告知AMF，AMF据此在后续的注册请求中调整切片选择策略。 --- ## 五、Rejected NSSAI的两级拒绝机制 NSSF在响应中可能返回两种级别的Rejected NSSAI，UE对其处理方式截然不同（**TS 23.501 Section 5.15.6.3**）： | 拒绝级别 | 含义 | UE行为 | 典型原因 | |---------|------|-------|---------| | **Rejected NSSAI in PLMN** | S-NSSAI在整个PLMN中不可用 | UE在**该PLMN内永久不再请求**此S-NSSAI，直到Configured NSSAI更新 | 切片在PLMN未部署、用户未签约 | | **Rejected NSSAI in TA** | S-NSSAI仅在当前TA中不可用 | UE离开当前TA后**可重新请求**此S-NSSAI | 该TA的gNB不支持该切片、TA内切片资源不足 | **NAS层编码**：在Registration Accept消息中（TS 24.501 Section 9.11.3.x），Rejected NSSAI携带拒绝原因值： - 原因值`0x01`：S-NSSAI在当前PLMN不可用 - 原因值`0x02`：S-NSSAI在当前注册区（Registration Area）不可用 --- ## 六、PDU会话建立中的NSSF交互 在PDU会话建立过程中，AMF也需要调用NSSF获取NSI信息，以确保SMF属于正确的切片实例（**TS 23.502 Section 4.3.2.2.1**）。 ```mermaid sequenceDiagram participant UE participant AMF participant NSSF participant NRF as 切片专属NRF participant SMF UE->>AMF: NAS PDU Session Establishment Request
DNN=internet, S-NSSAI={SST:1,SD:001} rect rgb(232, 245, 233) Note over AMF: AMF检查S-NSSAI是否在Allowed NSSAI中 end AMF->>NSSF: GET /network-slice-information
slice-info-request-for-pdu-session={
sNssai:{SST:1,SD:001},
roamingIndication:NON_ROAMING}
tai={PLMN-46000,TAC-1234} NSSF-->>AMF: 200 OK
nsiInformationList=[{
nsiId:"nsi-001",
nrfId:"https://nrf-slice1.operator.com/nnrf-nfm"
}] rect rgb(227, 242, 253) Note over AMF,NRF: AMF使用NSI专属NRF发现SMF end AMF->>NRF: GET /nnrf-disc/v1/nf-instances
target-nf-type=SMF
sNssai={SST:1,SD:001}
dnn=internet NRF-->>AMF: SMF Profile(s)
（仅属于nsi-001的SMF实例） AMF->>SMF: Nsmf_PDUSession_CreateSMContext
DNN + S-NSSAI + SUPI + N2 SM Info ``` **SliceInfoForPDUSession结构**（TS 29.531 Section 6.1.6.2.5）： | 字段 | 类型 | 说明 | |------|------|------| | `sNssai` | Snssai | PDU会话请求的S-NSSAI | | `roamingIndication` | RoamingIndication | 漫游状态指示 | | `homePlmnId` | PlmnId | HPLMN标识（漫游时） | **关键设计点**：PDU会话场景中，NSSF不再返回Allowed NSSAI（已在注册阶段确定），而是返回**NsiInformation**——即该S-NSSAI对应的网络切片实例所关联的NRF地址。AMF使用这个"切片专属NRF"来发现属于该切片的SMF，从架构层面保证了切片间的NF隔离。 --- ## 七、AMF重定向：切片驱动的AMF选择 当NSSF返回的`targetAmfSet`与当前AMF不匹配时，触发AMF重定向（**TS 23.502 Section 4.2.2.2.3**）。这是网络切片影响5G路由架构的核心体现。 ### 7.1 AMF Set与切片的关系 ```mermaid flowchart LR subgraph 切片部署架构 direction TB S1[AMF Set-1
支持SST:1 eMBB] --> A1[AMF-1a] S1 --> A2[AMF-1b] S2[AMF Set-2
支持SST:2 URLLC] --> A3[AMF-2a] S2 --> A4[AMF-2b] S3[AMF Set-3
支持SST:1+SST:3
eMBB+MIoT] --> A5[AMF-3a] end subgraph RAN侧路由 RAN[gNB] -->|切片1流量| S1 RAN -->|切片2流量| S2 RAN -->|切片3流量| S3 end ``` **AMF重定向触发条件与处理流程**： | 条件 | 处理方式 | |------|---------| | UE的Allowed NSSAI全部在当前AMF支持范围内 | 无需重定向，继续处理 | | UE的Allowed NSSAI部分或全部不在当前AMF支持范围 | NSSF返回targetAmfSet，触发重定向 | | 当前AMF不在targetAmfSet中 | 通过RAN路由到目标AMF（N2重定向） | | 当前AMF在targetAmfSet中 | 无需重定向 | **RAN侧切片信息**：gNB在N2消息中携带**SliceSupportList**（TS 38.413），列出了gNB支持的S-NSSAI列表。RAN可以利用这个信息在初始UE消息路由时就选择合适的AMF，减少后续重定向。 --- ## 八、free5GC实现对照：代码级映射 free5GC作为3GPP R16/R17标准的开源参考实现，其NSSF模块的代码结构直接映射了规范要求： | 3GPP规范功能 | free5GC代码路径 | 说明 | |-------------|---------------|------| | NSSF全局上下文（SupportedSnssaiList等） | `NFs/nssf/internal/context/context.go` | 含支持的S-NSSAI列表和默认S-NSSAI配置 | | Nnssf_NSSelection_Get核心逻辑 | `NFs/nssf/internal/sbi/processor/nsselection_network_slice_information.go` | 26678行，包含完整的三重交集算法 | | NSSAI可用性存储 | `NFs/nssf/internal/sbi/processor/nssaiavailability_store.go` | NSSAI可用性数据的CRUD操作 | | NSSAI可用性订阅管理 | `NFs/nssf/internal/sbi/processor/nssaiavailability_subscription.go` | 处理订阅/取消订阅/通知 | | NSSF配置模型 | `NFs/nssf/pkg/factory/config.go` | 配置文件中定义支持的S-NSSAI和AMF Set映射 | | AMF调用NSSF的消费者代码 | `NFs/amf/internal/sbi/consumer/nssf_service.go` | AMF侧构造HTTP GET请求调用NSSF | **free5GC中NSSF的关键配置示例**（简化版）： ```yaml # nssfconfig.yaml (简化) nssf: supportedNssaiInPlmn: - plmnId: {mcc: "460", mnc: "00"} supportedSnssaiList: - {sst: 1, sd: "010203"} - {sst: 2} - {sst: 3} nsiprofiles: - nsiId: "nsi-001" sNssai: {sst: 1, sd: "010203"} nrfId: "https://nrf-slice1.free5gc.org:8000" - nsiId: "nsi-002" sNssai: {sst: 2} nrfId: "https://nrf-slice2.free5gc.org:8000" amfSetList: - amfSetId: "amf-set-1" supportedSnssaiList: [{sst: 1, sd: "010203"}, {sst: 3}] - amfSetId: "amf-set-2" supportedSnssaiList: [{sst: 2}] ``` --- ## 九、抓包识别与故障排查 ### 9.1 抓包识别要点 | 协议层 | 抓包过滤表达式 | 关键字段 | |-------|-------------|---------| | **NAS层（UE↔AMF）** | `nas-5gs.message_type == 0x41`（Registration Request） | Requested NSSAI IE | | **NAS层** | `nas-5gs.message_type == 0x42`（Registration Accept） | Allowed NSSAI IE, Rejected NSSAI IE | | **SBI层（AMF↔NSSF）** | `http.request.uri contains "network-slice-information"` | 完整的Nnssf_NSSelection_Get请求 | | **SBI层** | `http.response.code == 200 && http.request.uri contains "nnssf"` | NSSF响应中的allowedNssai | | **NGAP层（RAN↔AMF）** | `ngap.protocolIE_ID == 79`（SliceSupportList） | gNB支持的切片列表 | ### 9.2 常见故障场景 | 故障现象 | 可能原因 | 排查思路 | |---------|---------|---------| | **Allowed NSSAI为空** | UE请求的S-NSSAI不在Subscribed NSSAI中 | 检查UDM签约数据，确认SST/SD是否正确 | | **NSSF返回HTTP 404** | 当前TA没有配置支持的S-NSSAI | 检查NSSF配置中该TAC对应的Supported NSSAI | | **反复触发AMF重定向** | RAN初始路由选择的AMF不匹配切片 | 检查gNB的SliceSupportList和AMF Set配置 | | **漫游时Allowed NSSAI为空** | HPLMN-VPLMN映射关系缺失 | 检查NSSF中NssaiMapping配置 | | **PDU会话建立失败（无SMF）** | NsiInformation中NRF地址不可达 | 验证切片专属NRF是否正常运行 | | **Registration Reject（#62）** | UE请求的所有S-NSSAI都被拒绝且无Default | 确认UDM中是否配置了Default S-NSSAI | ## 常见问题 **Q1: NSSF和UDM在切片选择中的职责边界是什么？** A: UDM负责提供用户的**签约切片全集**（Subscribed S-NSSAI），这是静态数据，由运营商在用户开户时配置。NSSF负责基于**当前网络状态**（TA支持情况、切片资源可用性、AMF Set映射）做动态的切片选择决策，输出Allowed NSSAI。简单说：UDM决定"用户有权使用哪些切片"，NSSF决定"用户当前实际能使用哪些切片"。 **Q2: Configured NSSAI和Allowed NSSAI的区别是什么？为什么需要两个？** A: Configured NSSAI是UE在某个PLMN中**可以尝试请求**的S-NSSAI集合，它由签约数据与PLMN支持切片的交集确定，相对稳定。Allowed NSSAI是UE在**当前注册区**中**实际被授权使用**的S-NSSAI集合，由NSSF根据TA级别的切片可用性动态确定，UE移动到新TA后可能变化。Configured NSSAI为UE提供了请求切片的"候选菜单"，Allowed NSSAI是"上桌的菜品"。 **Q3: 如果UE不携带Requested NSSAI会发生什么？** A: 如果UE在Registration Request中不携带Requested NSSAI，AMF会使用用户签约数据中的**Default S-NSSAI**作为Requested NSSAI的替代。NSSF会将Default S-NSSAI作为Allowed NSSAI返回。如果用户没有任何Default S-NSSAI，AMF可能返回Registration Reject（原因值#62——没有合适的网络切片）。这确保了即使用户终端不感知切片概念，也能接入运营商的默认切片。 **Q4: 为什么PDU会话建立时还需要再次调用NSSF？注册时不是已经确定了切片吗？** A: 注册阶段确定了Allowed NSSAI（UE可以使用哪些切片），但PDU会话建立阶段需要获取**NsiInformation**——即该S-NSSAI对应的网络切片实例的NRF地址。这是因为在大型运营商网络中，同一个S-NSSAI可能对应多个NSI（不同地域部署不同的切片实例），AMF需要通过NRF发现属于正确NSI的SMF。两个阶段回答的是不同的问题：注册阶段回答"能用哪个切片"，PDU会话阶段回答"切片在哪里"。 **Q5: NSSAI可用性变更通知机制在什么场景下最有价值？** A: 主要在以下场景：（1）**切片扩缩容**——某切片实例负载过高，NSSF通知AMF暂停该切片的新接入；（2）**切片故障恢复**——某NSI对应的NRF恢复，NSSF通知AMF该切片可用；（3）**运维操作**——运营商临时关闭某个切片进行维护。这个机制让5G网络能够**实时感知切片状态变化**，而不需要等待UE重新注册。 --- ## 参考来源 1. [3GPP TS 23.501 V18.x.x](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.15（网络切片架构）、Section 5.15.2（NSSAI类型定义）、Section 5.15.6（S-NSSAI映射） 2. [3GPP TS 23.502 V18.x.x](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.2.2.2（注册流程中的切片选择）、Section 4.2.2.2.3（AMF重定向）、Section 4.3.2.2.1（PDU会话与切片选择） 3. [3GPP TS 29.531 V18.x.x](https://www.3gpp.org/DynaReport/29531.htm) — Section 5-8（Nnssf_NSSelection服务定义）、Section 9-12（Nnssf_NSSAIAvailability服务定义） 4. [3GPP TS 38.413 V18.x.x](https://www.3gpp.org/DynaReport/38413.htm) — NGAP SliceSupportList IE定义，RAN侧切片路由信令 5. [free5GC NSSF Module](https://github.com/free5gc/nssf) — NSSF开源参考实现，切片选择算法的代码级参考 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 to-End](https://www.5g6gacademy.com/learn/what-is-nssf) — NSSF端到端选择机制解析 5. [Network Function NSSF Introduction - free5GC](https://free5gc.org/blog/20260128/20260128/) — free5GC开源NSSF实现分析 6. [Network Slicing - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_NetworkSlicing.html) — 5G切片信令流程图解 7. [free5GC Network Slicing DeepWiki](https://deepwiki.com/free5gc/free5gc.github.io/10-network-slicing) — free5GC切片实现架构分析 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。