# NSSF切片选择双阶段决策机制深度解析
## 1. 引言：为什么切片选择是5GC最复杂的控制面决策
5G网络切片（Network Slicing）是3GPP SA2架构设计中最具颠覆性的特性之一。在EPC时代，APN/DNN作为业务分流手段，仅能做到"数据面"级别的业务隔离。而5GS引入S-NSSAI（Single-Network Slice Selection Assistance Information）后，实现了从**接入网→传输网→核心网**全链路的端到端逻辑隔离。
NSSF（Network Slice Selection Function）是5GC SBA架构中唯一一个**只为切片服务**的专用NF。它的核心职责看似简单——为UE确定Allowed NSSAI并指示AMF Set——但实际上，NSSF的决策逻辑涉及**订阅数据交集运算、PLMN间S-NSSAI映射、TA可用性过滤、AMF能力匹配**四重博弈，且必须在Registration和PDU Session Establishment两个阶段分别执行不同的决策逻辑。
本文基于**TS 23.501 V19.x.x Section 5.15**、**TS 23.502 V19.x.x Section 4.2.2.2**和**TS 29.531 V19.x.x**，完整拆解NSSF切片选择的双阶段决策机制。
---
## 2. S-NSSAI结构体与NSSAI类型体系
### 2.1 S-NSSAI二进制结构
S-NSSAI由两个字段组成：
```
┌──────────────────┬──────────────────────┐
│ SST (8 bits) │ SD (24 bits, 可选) │
└──────────────────┴──────────────────────┘
```
| 字段 | 长度 | 范围 | 说明 |
|------|------|------|------|
| **SST** | 8 bit | 0~127（标准值）/ 128~255（PLMN专用） | 标识切片业务类型 |
| **SD** | 24 bit | 任意值（可选） | 区分同SST下的不同切片实例 |
3GPP定义了四个标准SST值（TS 23.501 Table 5.15.2.2-1）：
| SST值 | 业务类型 | 典型场景 |
|-------|----------|----------|
| 1 | eMBB | 手机宽带、视频流媒体 |
| 2 | URLLC | 工业自动化、远程手术 |
| 3 | mMTC | 海量物联网传感器 |
| 4 | V2X | 车联网 |
### 2.2 七种NSSAI类型的决策链
在UE与网络之间，NSSAI存在**七种**不同语义的类型，理解它们的关系是掌握NSSF决策逻辑的前提：
```mermaid
graph LR
A[Subscribed S-NSSAI
UDM签约数据] --> B[Requested NSSAI
UE请求的切片]
A --> C[Configured NSSAI
网络配置给UE的切片]
B --> D[Allowed NSSAI
网络允许的切片]
A --> E[Default S-NSSAI
默认切片]
F[Rejected S-NSSAI
被拒绝的切片] --> G[Pending NSSAI
等待NSSAA认证]
style A fill:#4a90d9,color:#fff
style D fill:#2ecc71,color:#fff
style F fill:#e74c3c,color:#fff
style G fill:#f39c12,color:#fff
```
| NSSAI类型 | 生成方 | 作用阶段 | 关键约束 |
|-----------|--------|----------|----------|
| Subscribed S-NSSAI | UDM/UDR | 全生命周期 | 每个PLMN最多16个 |
| Configured NSSAI | AMF/NSSF | Registration | UE未提供时由网络配置 |
| Requested NSSAI | UE | Registration | 当前TA可用切片的子集 |
| Allowed NSSAI | NSSF/AMF | Registration Accept | ≤8个，必须在当前TA可用 |
| Default S-NSSAI | UDM签约 | 无Requested NSSAI时 | 确保UE始终有服务 |
| Rejected S-NSSAI | AMF | Registration | 当前PLMN/TA不支持 |
| Pending NSSAI | AMF | NSSAA阶段 | 等待切片级二次认证 |
---
## 3. 双阶段决策架构：Registration阶段 vs PDU Session阶段
NSSF的决策分为两个完全不同的阶段，这是很多工程师容易混淆的地方。
### 3.1 阶段一：Registration阶段的切片选择
**触发条件**：UE发送Registration Request，AMF需要确定Allowed NSSAI。
**决策输入**：
- UE提供的Requested NSSAI + Mapping of Requested NSSAI
- UDM中的Subscribed S-NSSAIs
- 当前TA的可用S-NSSAI列表
- 运营商策略（如漫游协议、切片优先级）
**决策输出**：
- Allowed NSSAI
- Target AMF Set / AMF（如果需要AMF重选）
- NSI Information（Network Slice Instance标识 + 对应NRF）
- Rejected NSSAI in PLMN
- Configured NSSAI for UE（如果需要更新）
### 3.2 阶段二：PDU Session Establishment阶段的切片验证
**触发条件**：UE发起PDU Session Establishment，请求一个具体的S-NSSAI。
**决策逻辑**（相对简单）：
- 验证请求的S-NSSAI是否在Allowed NSSAI中
- 如果是漫游场景，NSSF可能需要进一步映射
- 如果S-NSSAI需要NSSAA且尚未完成，触发二次认证
```mermaid
sequenceDiagram
participant UE
participant RAN as (R)AN
participant AMF
participant NSSF
participant UDM
participant NRF
Note over UE,NRF: 阶段一：Registration切片选择
UE->>RAN: Registration Request
+ Requested NSSAI
+ Mapping of Requested NSSAI
RAN->>AMF: N2 Message
+ Registration Request
rect rgb(240,248,255)
Note over AMF: AMF本地检查
是否能服务Requested NSSAI
end
AMF->>UDM: Nudm_SDM_Get
(Subscribed S-NSSAIs)
UDM-->>AMF: Subscribed S-NSSAIs
+ Default S-NSSAI
AMF->>NSSF: Nnssf_NSSelection_Get
slice-info-request-for-registration
rect rgb(255,250,240)
Note over NSSF: NSSF四重决策:
1.订阅交集运算
2.S-NSSAI映射(HPLMN↔VPLMN)
3.TA可用性过滤
4.AMF能力匹配
end
NSSF-->>AMF: Allowed NSSAI
+ Target AMF Set
+ NSI Information
+ NRF for NSI
alt 需要AMF重选
AMF->>AMF: 触发AMF Reselection
(转发Registration Context)
Note over AMF: 通过Namf_Communication
转发到Target AMF
end
AMF-->>RAN: Registration Accept
+ Allowed NSSAI
+ Configured NSSAI(如需)
RAN-->>UE: Registration Accept
+ Allowed NSSAI
Note over UE,NRF: 阶段二：PDU Session切片验证
UE->>AMF: PDU Session Establishment Request
+ S-NSSAI
AMF->>AMF: 校验S-NSSAI ∈ Allowed NSSAI
alt S-NSSAI需要NSSAA且未完成
AMF->>AMF: 触发NSSAA流程
(TS 33.501)
end
AMF->>NSSF: Nnssf_NSSelection_Get
slice-info-request-for-pdu-session
NSSF-->>AMF: NSI Information
+ SMF Set for slice
AMF->>NRF: Nnrf_NFDiscovery
(SMF for S-NSSAI + DNN)
NRF-->>AMF: SMF Instance(s)
```
---
## 4. Nnssf_NSSelection_Get服务操作全参数拆解
### 4.1 请求参数（TS 29.531 Section 6.1.3.2.3.1）
AMF向NSSF发送`GET /nnssf-nsselection/v1/network-slice-information`，关键Query Parameters：
| 参数名 | 类型 | 必选 | 说明 |
|--------|------|------|------|
| `nf-id` | string | 条件必选 | 请求NF的实例ID |
| `nf-type` | NFType | 条件必选 | 请求NF类型（通常为AMF） |
| `slice-info-request-for-registration` | object | 条件必选 | Registration阶段请求体 |
| `slice-info-request-for-pdu-session` | object | 条件必选 | PDU Session阶段请求体 |
| `home-plmn-id` | PlmnId | 否 | HPLMN标识（漫游场景必选） |
| `target-plmn-id` | PlmnId | 否 | 目标PLMN标识 |
| `roaming-indication` | enum | 否 | 漫游指示（NON_ROAMING/LOCAL_BREAKOUT/HOME_ROUTED） |
| `s-nssai` | Snssai | 否 | 指定查询的S-NSSAI |
| `supported-features` | string | 否 | 支持的特性集（Feature bitmask） |
| `tai` | Tai | 否 | 当前跟踪区标识 |
**Registration请求体内部结构**（`slice-info-request-for-registration`）：
```json
{
"subscribedNssai": [
{"sst": 1, "sd": "000001"},
{"sst": 2, "sd": "000002"},
{"sst": 3}
],
"requestedNssai": [
{"sst": 1, "sd": "000001"},
{"sst": 2}
],
"mappingOfRequestedNssai": [
{"sst": 1, "sd": "000001", "mappedSst": 1, "mappedSd": "010101"},
{"sst": 2, "mappedSst": 2, "mappedSd": "020202"}
],
"defaultConfiguredNssaiIndication": false,
"ueUseSliceMbr": true
}
```
### 4.2 响应参数（TS 29.531 Section 6.1.3.2.3.2）
NSSF返回的`NssfSliceSelection`数据结构：
| 字段名 | 类型 | 说明 |
|--------|------|------|
| `allowedNssai` | map> | 每个PLMN的Allowed S-NSSAI列表 |
| `configuredNssai` | map> | 网络为UE配置的NSSAI |
| `targetAmfSet` | string | 目标AMF Set标识 |
| `targetAmf` | string | 目标AMF实例标识 |
| `candidateAmfList` | array | 候选AMF列表 |
| `nsiInformation` | array | 网络切片实例信息 |
| `rejectedNssaiInPlmn` | array | PLMN级被拒绝的S-NSSAI |
| `rejectedNssaiInTa` | array | TA级被拒绝的S-NSSAI |
| `mappingOfAllowedNssai` | array | Allowed NSSAI的S-NSSAI映射 |
| `mappingOfConfiguredNssai` | array | Configured NSSAI的映射 |
| `nrfAmfSet` | string | AMF Set对应的NRF地址 |
| `nrfAmf` | string | 目标AMF对应的NRF地址 |
**NSI Information内部结构**：
```
┌─────────────────────────────────────────────────┐
│ NsiInformation │
├─────────────────────────────────────────────────┤
│ nsiId: string (切片实例标识) │
│ nrfId: string (该NSI对应的NRF URI) │
│ nsApiRoot: string (该NSI的API根路径) │
│ supportedSnssaiList: (该NSI支持的S-NSSAI) │
│ ┌──────────────────────────────────┐ │
│ │ Snssai: │ │
│ │ sst: integer (0-255) │ │
│ │ sd: string (可选, HEX) │ │
│ └──────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
```
---
## 5. NSSF四重决策引擎：从订阅到AMF的完整推演
### 5.1 决策一：订阅交集运算
NSSF首先计算**Requested NSSAI ∩ Subscribed S-NSSAI**的交集：
```
输入:
Requested NSSAI = [{SST:1, SD:000001}, {SST:2}, {SST:5, SD:000005}]
Subscribed S-NSSAI = [{SST:1, SD:000001}, {SST:2, SD:000002}, {SST:3}]
运算规则:
1. 精确匹配: SST+SD完全一致 → 匹配
2. SST匹配: Requested中无SD, Subscribed中有SD → 以Subscribed为准
3. Default S-NSSAI: 如果交集为空, 使用Default S-NSSAI
结果:
初始Allowed = [{SST:1, SD:000001}, {SST:2, SD:000002}]
Rejected = [{SST:5, SD:000005}] (不在签约中)
```
### 5.2 决策二：S-NSSAI映射（漫游场景核心）
在漫游场景下，VPLMN和HPLMN的S-NSSAI值可能不同（特别是非标准SST 128~255），NSSF需要执行双向映射：
```mermaid
graph TB
subgraph HPLMN["HPLMN S-NSSAI"]
H1["SST:128, SD:AABBCC
运营商A的URLLC"]
H2["SST:1
标准eMBB"]
end
subgraph NSSF_Mapping["NSSF映射引擎"]
M["S-NSSAI Mapping Table"]
end
subgraph VPLMN["VPLMN S-NSSAI"]
V1["SST:2, SD:112233
VPLMN的URLLC"]
V2["SST:1
标准eMBB(直通)"]
end
H1 -->|"映射规则#1"| M
H2 -->|"标准值直通"| M
M --> V1
M --> V2
style NSSF_Mapping fill:#fff3cd
style HPLMN fill:#d4edda
style VPLMN fill:#cce5ff
```
**映射规则**（TS 23.501 Section 5.15.8）：
| 规则 | 场景 | 映射方向 |
|------|------|----------|
| 标准SST直通 | SST=1,2,3,4 | 无需映射，HPLMN和VPLMN一致 |
| 运营商自定义映射 | SST=128~255 | HPLMN S-NSSAI ↔ VPLMN S-NSSAI |
| Configured NSSAI映射 | UE漫游到新PLMN | 返回Mapped Configured NSSAI |
| NSSAA触发映射 | 切片需二次认证 | 映射后仍需认证确认 |
### 5.3 决策三：TA可用性过滤
NSSF维护每个TA支持哪些S-NSSAI的信息（称为**TA NSSAI Availability**）。在初始Allowed集合基础上，进一步过滤当前TA不支持的切片：
```
步骤:
1. 从初始Allowed = [{SST:1, SD:000001}, {SST:2, SD:000002}]出发
2. 查询TA NSSAI Availability:
TAC=0x0001 → 支持 [{SST:1, SD:000001}, {SST:3}]
3. 过滤结果:
Allowed NSSAI = [{SST:1, SD:000001}] (SST:2在当前TA不可用)
4. 被TA拒绝的: [{SST:2, SD:000002}] → 放入rejectedNssaiInTa
```
### 5.4 决策四：AMF能力匹配与AMF Set选择
NSSF确定Allowed NSSAI后，需要判断当前AMF是否能够服务这些切片：
```mermaid
stateDiagram-v2
[*] --> Check_Current_AMF: AMF查询NSSF
state Check_Current_AMF {
[*] --> AMF_Supports_All: S-NSSAI ⊆ AMF能力
[*] --> AMF_Partial: 部分S-NSSAI不支持
[*] --> AMF_None: 完全不支持
}
AMF_Supports_All --> Return_Allowed: 直接返回Allowed NSSAI
AMF_Partial --> Check_Slice_Aware_AMF: 需要评估AMF重选
AMF_None --> Must_Reselect: 必须AMF重选
state Check_Slice_Aware_AMF {
[*] --> Find_AMF_Set: 查询支持目标切片的AMF Set
Find_AMF_Set --> Single_Set: 唯一AMF Set
Find_AMF_Set --> Multiple_Sets: 多个候选AMF Set
Single_Set --> Return_Target_Set
Multiple_Sets --> Prioritize: 按负载/优先级排序
}
Return_Target_Set --> AMF_Reselection: 返回targetAmfSet + NRF
Prioritize --> AMF_Reselection
AMF_Reselection --> [*]
Return_Allowed --> [*]
```
AMF Set的选择遵循以下优先级（TS 23.501 Section 6.3.5）：
| 优先级 | 策略 | 说明 |
|--------|------|------|
| 1 | 精确匹配 | 支持全部Allowed S-NSSAI的AMF Set |
| 2 | 最大覆盖 | 支持最多Allowed S-NSSAI的AMF Set |
| 3 | 默认切片优先 | 至少支持Default S-NSSAI的AMF Set |
| 4 | 分割处理 | 将Allowed NSSAI拆分到多个AMF（极端场景） |
---
## 6. AMF重选的双路径机制
当NSSF指示需要AMF重选时，TS 23.502 Section 4.2.2.2.3定义了两种路径：
### 6.1 路径A：AMF-to-AMF重定向（推荐）
初始AMF通过`Namf_Communication_RegistrationContextTransfer`将Registration Context转发到Target AMF，UE无感知。
```
Initial AMF → Target AMF:
Namf_Communication_RegistrationContextTransfer
{
"ueContext": {
"supi": "imsi-460001234567890",
"allowedNssai": [...],
"registrationRequest": { ... },
"nssfInfo": { "targetAmfSet": "AMF-Set-2" }
}
}
```
**优点**：UE无感知，延迟低，不占用空口资源
**缺点**：需要Initial AMF和Target AMF间有NRF发现能力
### 6.2 路径B：RAN重路由（fallback）
Initial AMF通过N2接口指示RAN重路由到Target AMF。
```
Initial AMF → RAN: Reroute NAS Request
(包含Target AMF的GUAMI或AMF Set ID)
RAN → Target AMF: N2 NAS Forward
(原始Registration Request)
```
**优点**：适用于AMF间无SBI连接的场景
**缺点**：增加RAN信令开销，UE可能有短暂中断
### 6.3 两种路径对比
| 维度 | 路径A（AMF间SBI） | 路径B（RAN重路由） |
|------|-------------------|-------------------|
| UE感知 | 无 | 无 |
| 信令路径 | AMF→AMF直连 | AMF→RAN→AMF |
| 延迟 | 10~50ms | 50~200ms |
| 实现复杂度 | 需NRF发现+Context Transfer | 需RAN支持Reroute NAS |
| 适用场景 | 同PLMN内 | 跨AMF Set/跨DC |
| 信令消息数 | 2（Request+Response） | 4（AMF→RAN→AMF→UE） |
---
## 7. 漫游场景下的NSSF双节点协作
漫游场景下，VPLMN NSSF和HPLMN NSSF需要协同完成切片选择。TS 23.501 Section 5.15.5定义了两种漫游模型：
### 7.1 Home-Routed漫游切片选择
```mermaid
sequenceDiagram
participant UE
participant V_RAN as VPLMN (R)AN
participant V_AMF as VPLMN AMF
participant V_NSSF as VPLMN NSSF
participant H_NSSF as HPLMN NSSF
participant UDM as HPLMN UDM
UE->>V_RAN: Registration Request
+ Requested NSSAI(VPLMN值)
V_RAN->>V_AMF: N2 + Registration Request
V_AMF->>UDM: Nudm_SDM_Get
(获取Subscribed S-NSSAI)
UDM-->>V_AMF: Subscribed S-NSSAI
(HPLMN格式)
V_AMF->>V_NSSF: Nnssf_NSSelection_Get
+ home-plmn-id
+ roaming-indication=HOME_ROUTED
V_NSSF->>H_NSSF: Nnssf_NSSelection_Get
(跨PLMN查询HPLMN切片策略)
H_NSSF-->>V_NSSF: HPLMN切片映射规则
+ HPLMN Allowed NSSAI
rect rgb(255,245,238)
Note over V_NSSF: VPLMN NSSF执行:
1.HPLMN S-NSSAI → VPLMN S-NSSAI映射
2.过滤VPLMN TA可用的切片
3.确定VPLMN的AMF Set
end
V_NSSF-->>V_AMF: Allowed NSSAI(VPLMN格式)
+ Mapping of Allowed NSSAI
+ Target AMF Set
V_AMF-->>UE: Registration Accept
+ Allowed NSSAI
```
### 7.2 Local Breakout漫游切片选择
在LBO模式下，VPLMN NSSF独立决策，但仍需参考HPLMN签约数据：
| 对比维度 | Home-Routed | Local Breakout |
|----------|-------------|----------------|
| NSSF查询 | V-NSSF → H-NSSF | 仅V-NSSF |
| S-NSSAI映射 | HPLMN→VPLMN双向 | 仅VPLMN内部 |
| 数据面锚点 | HPLMN UPF | VPLMN UPF |
| 切片策略来源 | HPLMN主导 | VPLMN自主 |
| 延迟 | 高（数据回到HPLMN） | 低（本地breakout） |
---
## 8. NSSAA：切片级二次认证与授权
TS 33.501定义了**NSSAA（Network Slice-Specific Authentication and Authorization）**机制。当某些S-NSSAI需要切片级认证时（例如企业专网切片），Allowed NSSAI中对应的S-NSSAI被标记为"Pending"，需要完成EAP-based二次认证后才能使用。
### 8.1 NSSAA状态机
```mermaid
stateDiagram-v2
[*] --> Non_Pending: S-NSSAI无需NSSAA
[*] --> Pending: S-NSSAI需NSSAA
state Pending {
[*] --> EAP_Started: AMF触发EAP
EAP_Started --> EAP_Success: 认证成功
EAP_Started --> EAP_Failure: 认证失败
EAP_Success --> Authorized: 加入Allowed NSSAI
EAP_Failure --> Rejected: 从Allowed NSSAI移除
}
Authorized --> [*]
Non_Pending --> [*]
Rejected --> [*]
```
### 8.2 NSSAA信令流程
NSSAA流程中，AMF作为EAP Authenticator，AAA-S（第三方认证服务器）通过NSSAAF（NSSAA Function）与AMF交互：
| 步骤 | 消息 | 方向 | 关键IE |
|------|------|------|--------|
| 1 | Registration Accept | AMF→UE | 携带Pending NSSAI列表 |
| 2 | NSSAA NAS Message | UE→AMF | EAP-Response/Identity |
| 3 | Nssaaf_NSSAA_EAP | AMF→NSSAAF | EAP payload + S-NSSAI |
| 4 | Diameter EAP | NSSAAF→AAA-S | EAP + 切片标识 |
| 5 | EAP-Success | AAA-S→AMF | 授权结果 + 切片QoS策略 |
| 6 | Configuration Update | AMF→UE | 更新Allowed NSSAI（移除Pending标记） |
---
## 9. 实战抓包识别NSSF信令
### 9.1 抓包过滤规则
| 场景 | Wireshark过滤表达式 | 说明 |
|------|---------------------|------|
| SBI接口 | `http.request.uri contains "nnssf-nsselection"` | 捕获所有NSSF选择请求 |
| Registration阶段 | `http.request.uri contains "slice-info-request-for-registration"` | 仅捕获注册阶段 |
| PDU Session阶段 | `http.request.uri contains "slice-info-request-for-pdu-session"` | 仅捕获会话阶段 |
| 漫游场景 | `http.request.uri contains "roaming-indication"` | 捕获漫游相关请求 |
| 指定S-NSSAI | `http.request.uri contains "sst"` | 按切片类型过滤 |
### 9.2 常见故障点与排错
| 故障现象 | 根因分析 | 排错步骤 |
|----------|----------|----------|
| Allowed NSSAI为空 | Requested NSSAI ∩ Subscribed = ∅ | 1. 检查UDM中Subscribed S-NSSAI
2. 确认Requested NSSAI格式正确 |
| 触发AMF重选循环 | AMF Set配置错误或NRF注册异常 | 1. 检查NRF中AMF的S-NSSAI注册
2. 确认AMF Set的GUAMI池不重叠 |
| 漫游场景切片不可用 | VPLMN未配置HPLMN映射规则 | 1. 检查V-NSSF的映射表
2. 确认HPLMN漫游协议包含切片 |
| NSSAA持续Pending | AAA-S不可达或EAP超时 | 1. 检查NSSAAF→AAA-S连通性
2. 查看AMF的NSSAA定时器 |
| PDU Session被拒 | S-NSSAI不在Allowed NSSAI中 | 1. 对比Registration Accept中的Allowed
2. 检查TA变更后Allowed是否变化 |
## 10. R18/R19增强：NSSF机制的演进方向
3GPP Release 18和Release 19对NSSF切片选择机制引入了多项增强：
| 特性 | Release | TS参考 | 说明 |
|------|---------|--------|------|
| 切片SLA监控 | Rel-18 | TS 28.554 | NSSF向MDAF上报切片KPI |
| Edge Computing集成 | Rel-18 | TS 23.548 | NSSF参与EAS Discovery的切片决策 |
| Non-Public Network增强 | Rel-18 | TS 23.501 | SNPN场景下的独立NSSF |
| 切片自动伸缩 | Rel-19 | TS 28.533 | NSSF与MDA闭环联动 |
| AI辅助切片选择 | Rel-19 | Study Item | 基于UE行为预测的预分配 |
| 跨域切片编排 | Rel-19 | TS 28.541 | NSSF与Transport Slicing联动 |
---
## 常见问题
**Q: Allowed NSSAI为什么最多只有8个S-NSSAI？**
A: 这是NAS信令编码的限制（TS 24.501 Section 9.11.3.37），NSSAI信息元素使用4bit长度字段编码S-NSSAI数量，最大值为8。实际运营商部署中，一个UE同时使用的切片通常不超过3~4个。
**Q: AMF本地能否不查询NSSF直接确定Allowed NSSAI？**
A: 可以。如果AMF本地缓存了UE的Subscribed S-NSSAI（通过UDM订阅通知获取），且AMF能够独立完成订阅交集+TA过滤+AMF能力匹配，则可以不查询NSSF。但漫游场景、需要AMF重选、需要NSI信息时必须查询NSSF（TS 23.501 Section 6.3.6）。
**Q: NSSF和NRF的关系是什么？NSSF返回的NRF有什么用？**
A: NSSF是切片选择的决策者，NRF是NF实例的注册发现服务。NSSF返回的`nsiInformation`中包含特定NSI对应的NRF地址，AMF使用这个NRF来发现服务于该切片的SMF、UPF等NF实例。不同切片实例可能有不同的NRF，实现切片间NF实例的物理隔离。
**Q: Default S-NSSAI和Allowed NSSAI为空时UE怎么办？**
A: 如果Allowed NSSAI为空且存在Default S-NSSAI，网络自动将Default S-NSSAI加入Allowed NSSAI。Default S-NSSAI在UDM签约数据中标记，通常是eMBB（SST:1）。如果既没有Allowed也没有Default，UE会收到Registration Reject（Cause #62: No suitable cells in tracking area）或Cause #73: S-NSSAI not available，需要更换TA或PLMN。
**Q: NSSAA和5G AKA是什么关系？能否互相替代？**
A: 两者完全不同。5G AKA（TS 33.501 Section 6.1）是**主认证**，验证SIM卡和网络的合法性，所有UE必须完成。NSSAA是**切片级二次认证**，在主认证之后触发，由第三方（如企业IT）通过EAP协议验证UE是否有权接入特定切片。NSSAA不能替代5G AKA，且只有签约了需要NSSAA的切片时才触发。
---
## 参考来源
1. [3GPP TS 23.501 V19.x.x](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.15 Network Slicing, Section 6.3.6 NSSF
2. [3GPP TS 23.502 V19.x.x](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.2.2.2 Registration with AMF reselection, Section 4.2.2.2.3
3. [3GPP TS 29.531 V19.x.x](https://www.3gpp.org/DynaReport/29531.htm) — Nnssf_NSSelection Service API, Section 6.1.3
4. [3GPP TS 33.501 V19.x.x](https://www.3gpp.org/DynaReport/33501.htm) — Section 14 NSSAA机制
5. [free5GC NSSF Introduction](https://free5gc.org/blog/20260128/20260128/) — NSSF开源实现分析
---
> 本文由「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 等场景全覆盖。
