《5G核心网原理与实践》实践篇 · NSSF 网元功能
作者：爱卫生
在上一篇（第13篇）中，我们详细讨论了AMF如何通过Nnssf_NSSAIAvailability_Update服务操作，将自身支持的切片可用性信息上报给NSSF。这是AMF向NSSF"注册"切片能力的流程。而在本篇中，我们将讨论这个流程的反面操作——当AMF需要下线、维护或重置时，如何通过Nnssf_NSSAIAvailability_Delete服务操作，将自己之前上报的切片可用性信息从NSSF中删除。
在5G核心网的实际运营中，AMF并不是永远在线的。以下场景需要AMF从NSSF中删除其可用性信息：
AMF计划性维护：运维人员需要对AMF进行版本升级、补丁安装或硬件维护，AMF需要主动下线。在下线之前，AMF应通知NSSF删除其切片可用性信息，避免NSSF在后续的切片选择中仍然将该AMF作为候选目标——否则会导致UE被路由到一个不可用的AMF，造成注册失败。
AMF故障/重启：当AMF发生故障需要重启时，虽然不是主动下线，但在重启过程中AMF的切片服务能力暂时不可用。部分厂商的实现中，AMF在重启前会尝试发送Delete操作清理NSSF中的记录。
AMF退网：在NF（Network Function）的生命周期管理中，当AMF实例被永久移除（退网）时，需要清理其在NSSF中的注册信息。
切片配置完全变更：当AMF的切片配置发生根本性变化，需要先删除旧信息再重新上报新信息时，也可以先执行Delete操作。
Delete操作和Update操作是Nnssf_NSSAIAvailability服务的一对互补操作：
flowchart LR
subgraph "AMF上线/配置变更"
UPDATE["Nnssf_NSSAIAvailability_Update<br/>PUT/POST<br/>上报切片可用性"]
end
subgraph "NSSF数据库"
DB["NSSF维护的切片<br/>可用性数据库"]
end
subgraph "AMF下线/维护"
DELETE["Nnssf_NSSAIAvailability_Delete<br/>DELETE<br/>删除切片可用性"]
end
UPDATE -->|"注册"| DB
DELETE -->|"清理"| DB
style UPDATE fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
style DELETE fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style DB fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
sequenceDiagram
participant OAM as 运维系统/OAM
participant AMF
participant NSSF
Note over OAM, NSSF: 阶段1: 触发删除
rect rgb(230, 245, 255)
OAM->>AMF: 执行退网/维护操作
Note left of OAM: 运维人员通过OAM系统<br/>触发AMF退网或维护
end
Note over OAM, NSSF: 阶段2: AMF向NSSF删除可用性信息
rect rgb(255, 245, 230)
AMF->>NSSF: Nnssf_NSSAIAvailability_Delete<br/>DELETE {NFid}
Note right of AMF: HTTP DELETE请求<br/>URI中包含AMF的NF Instance ID<br/>无请求体
Note over NSSF: NSSF删除该AMF的<br/>所有切片可用性记录
NSSF-->>AMF: 204 No Content
Note left of NSSF: 删除成功<br/>无返回消息体
end
Note over OAM, NSSF: 阶段3: AMF确认清理完成
AMF-->>OAM: 退网/维护操作完成
flowchart TD
A["AMF执行Delete操作"] --> B["NSSF删除该AMF的所有切片记录"]
B --> C["NSSF数据库更新: 该AMF不再出现在任何TA的切片映射中"]
C --> D["后续UE注册时"]
D --> E["NSSF执行NSSelection_Get查询"]
E --> F["NSSF不再将该AMF作为候选目标"]
F --> G["UE被路由到其他可用AMF<br/>或注册失败(无可用AMF)"]
style A fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style C fill:#fff3e0,stroke:#e65100,stroke-width:2px
style G fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
验证AMF和NSSF支持可用性服务删除操作。当AMF执行退网/维护操作时，AMF能够通过Nnssf_NSSAIAvailability_Delete服务操作将自己之前上报的切片可用性信息从NSSF中删除，NSSF正确响应并清理数据库。
硬件平台完成上电，工作状态正常。
AMF与NG-RAN对接数据配置完成。
AMF配置了对接的NSSF信息（NSSF的SBI地址和端口）。
RAN支持基于TA粒度的切片信息上报AMF。
AMF已经向NSSF成功更新过本AMF对应的切片信息（即第13篇的Update操作已成功执行）。
各个接口的信令监控和跟踪工具已建立。
在AMF上执行退网配置操作，触发Delete服务流程。
检查AMF向NSSF发送的DELETE请求消息，验证消息中携带的NFid是否正确。
检查NSSF返回的响应消息，验证NSSF是否成功删除了该AMF的相关信息。
确认AMF退网配置操作执行成功。
AMF向NSSF发送Nnssf_NSSAIAvailability_Delete消息，HTTP方法为DELETE，URI中包含该AMF的NF Instance ID。
NSSF收到DELETE请求后，从数据库中删除该AMF相关的所有切片可用性记录。
NSSF返回204 No Content，表示删除成功。
AMF退网配置操作执行成功。
在本测试中，整个流程相对简洁——AMF向NSSF发送一个HTTP DELETE请求，NSSF删除对应的记录并返回204 No Content。虽然流程简单，但其背后的语义和影响非常重要：删除操作意味着该AMF将从NSSF的切片选择候选池中被移除，后续的UE注册请求不会再被路由到该AMF。
（注：为保护网络安全，以下log中的NF Instance ID、网元IP等敏感信息已做严格脱敏处理）
运维人员通过OAM系统在AMF上执行退网配置操作。这个操作可以是计划性的（如版本升级前的主动下线），也可以是紧急的（如发现AMF异常需要隔离）。
sequenceDiagram
participant OAM as 运维系统
participant AMF
Note over OAM, AMF: 运维人员触发AMF退网
OAM->>AMF: 执行退网配置操作
Note left of OAM: 可能的操作类型:<br/>1. AMF版本升级<br/>2. 硬件维护<br/>3. AMF退网<br/>4. 紧急隔离
Note over AMF: AMF收到退网指令后<br/>开始执行清理流程:<br/>1. 停止接受新UE注册<br/>2. 通知关联的RAN<br/>3. 向NSSF发送Delete<br/>4. 清理本地资源
AMF退网前的清理步骤：
AMF收到退网指令后的执行序列：
Step 1: 标记自身为"barred"状态，不再接受新的UE注册请求
Step 2: 对已注册的UE执行Registraion Redirect或等待UE自然离开
Step 3: 向关联的gNB发送NG RESET或RAN Configuration Update
Step 4: 向NSSF发送Delete请求，删除切片可用性信息
Step 5: 向NRF发起Deregister（注销NF实例）
Step 6: 清理本地资源，完成退网
注意：向NSSF发送Delete是AMF退网流程中的关键步骤之一。如果不执行Delete操作，NSSF的数据库中仍然保留着该AMF的切片可用性信息，后续的Nnssf_NSSelection_Get查询可能仍然会将UE路由到这个已经下线的AMF，导致注册失败。
AMF向NSSF发送HTTP DELETE请求，URI中包含该AMF的NF Instance ID。
sequenceDiagram
participant AMF
participant NSSF
Note over AMF, NSSF: Nnssf_NSSAIAvailability_Delete
AMF->>NSSF: DELETE /nnssf-nssaiavailability/v1/<br/>amfInstances/{NFid}
Note right of AMF: HTTP DELETE请求<br/>URI包含AMF的NF Instance ID<br/>无请求体（不需要额外信息）<br/>NFid唯一标识该AMF实例
Note over NSSF: NSSF处理:<br/>1. 根据NFid查找数据库记录<br/>2. 删除该AMF的所有切片可用性数据<br/>3. 释放相关资源
NSSF-->>AMF: 204 No Content
Note left of NSSF: 删除成功<br/>响应无消息体
信令抓包解析：
# 1. AMF -> NSSF（删除可用性信息 DELETE请求）
Frame: 4001
HEADERS[6]: DELETE /nnssf-nssaiavailability/v1/amfInstances/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Host: 10.XX.XX.XX:8081
Accept: application/json
# HTTP方法: DELETE
# 服务名称: nnssf-nssaiavailability
# API版本: v1
# 资源路径: /amfInstances/{NFid}
# NFid: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
# AMF的NF Instance ID（UUID，已脱敏）
# 这是该AMF在NRF注册时获得的唯一标识
# NSSF通过此ID定位该AMF的所有切片可用性记录
#
# NSSF地址: 10.XX.XX.XX:8081（已脱敏）
#
# 关键特征: 无请求体（Request Body为空）
# DELETE操作不需要携带任何请求体，
# 所有定位信息都通过URL中的NFid完成
Delete请求的关键特征：
| 特征 | 说明 |
|---|---|
| HTTP方法 | DELETE |
| URI | /nnssf-nssaiavailability/v1/amfInstances/{NFid} |
| 请求体 | 无（空） |
| 核心参数 | NFid（AMF的NF Instance ID，通过URL传递） |
| 幂等性 | 幂等（多次删除同一NFid结果一致） |
为什么Delete不需要请求体？ 因为Delete操作的目标是删除某个AMF的全部切片可用性记录。AMF的NF Instance ID已经唯一标识了该AMF的所有记录，NSSF只需要根据NFid定位并删除所有相关数据即可，不需要额外的参数来指定删除哪些具体的TAI或切片。
NSSF收到DELETE请求后，执行以下处理步骤：
flowchart TD
A["NSSF收到DELETE请求"] --> B["从URI中提取NFid"]
B --> C["在数据库中查找该NFid的所有记录"]
C --> D["记录是否存在"]
D -->|"存在"| E["删除该AMF的所有切片可用性记录"]
D -->|"不存在"| F["仍然返回204 No Content"]
E --> G["释放相关资源"]
G --> H["返回204 No Content"]
F --> H
style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style E fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style H fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
NSSF的处理逻辑：
NSSF收到DELETE /amfInstances/{NFid}后的处理流程：
1. 从URI中提取NFid = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
2. 在可用性数据库中查找NFid对应的所有记录
3. 查找结果:
- 记录1: TA1 (TAC=0001) -> 切片1, 切片2
- 记录2: TA2 (TAC=0002) -> 切片1
（这是第13篇中AMF上报的切片信息）
4. 删除所有找到的记录
5. 释放相关资源
6. 返回204 No Content
信令抓包解析——NSSF响应：
# 2. NSSF -> AMF（删除成功响应）
Frame: 4003
HEADERS[3]: 204 No Content
Date: Thu, 17 Apr 2026 10:30:00 GMT
# HTTP状态码: 204 No Content
# 含义: 服务器成功处理了请求，但没有返回任何内容
#
# 204 No Content是DELETE操作成功的标准响应
# - 表示NSSF已成功删除该AMF的所有记录
# - 响应体为空（没有消息体）
# - 不需要额外的确认信息
#
# 与Update操作的200 OK不同：
# - Update返回200 OK + 完整的可用性数据（确认更新结果）
# - Delete返回204 No Content（仅确认删除成功）
协议参考：根据3GPP TS 29.531第5.3.2.3节，Nnssf_NSSAIAvailability_Delete操作的成功响应为204 No Content。HTTP 204状态码的含义是"服务器成功处理了请求但不需要返回任何实体"，这与RESTful API中DELETE操作的标准语义一致。
Delete操作执行后，NSSF内部的数据库发生了明确的变化——该AMF的所有切片可用性记录被清除。
删除前（第13篇Update后的状态）：
| AMF NF Instance ID | TAI | 支持的切片 |
|---|---|---|
| UUID-XXX1 | PLMN1/TA1 (TAC=0001) | 切片1, 切片2 |
| UUID-XXX1 | PLMN1/TA2 (TAC=0002) | 切片1 |
删除后（本篇Delete后的状态）：
| AMF NF Instance ID | TAI | 支持的切片 |
|---|---|---|
| (空 - 已删除) | (空) | (空) |
|---|---|---|
-i |
- | 在输出中包含HTTP响应头 |
-X DELETE |
DELETE | HTTP方法为DELETE |
| URL | http://10.XX.XX.XX:8081/nnssf-nssaiavailability/v1/amfInstances/{NFid} | NSSF的SBI接口地址 |
NSSF返回的204 No Content响应（预期）：
HTTP/1.1 204 No Content
Date: Thu, 17 Apr 2026 10:30:00 GMT
Server: NSSF/1.0
（无响应体）
Delete操作排障要点：
检查NFid：确保URL中的NFid与要删除的AMF实例一致。如果NFid错误，NSSF可能不会返回错误（因为DELETE是幂等的），但实际删除的是错误AMF的记录，导致数据不一致。
检查NSSF可达性：如果curl连接超时或返回Connection Refused，检查NSSF的SBI地址和端口是否正确，以及网络连通性。
验证删除结果：Delete操作完成后，可以通过Nnssf_NSSAIAvailability_Get查询来验证该AMF的记录是否已被成功删除。如果查询返回空结果或404，说明删除成功。
注意时序：Delete操作应在AMF完全停止服务之前执行。如果AMF已经完全下线，但NSSF中仍保留其记录，可能导致短暂的切片选择错误。
验证Delete成功的查询操作：
# 删除后，查询该AMF的可用性信息，应返回空结果
curl -i -X GET http://10.XX.XX.XX:8081/nnssf-nssaiavailability/v1/amfInstances/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
如果返回404 Not Found或空的可用性数据，说明Delete操作已成功。
将Update（第13篇）和Delete（本篇）放在一起，可以看到Nnssf_NSSAIAvailability服务的完整生命周期管理：
flowchart TD
A["AMF实例启动"] --> B["AMF向NRF注册NF Profile"]
B --> C["AMF与gNB建立NG连接<br/>NG Setup流程"]
C --> D["AMF向NSSF执行Update<br/>上报切片可用性"]
D --> E["NSSF数据库: 该AMF可参与切片选择"]
E --> F["AMF正常运行<br/>为UE提供切片服务"]
F --> G["AMF需要下线/维护"]
G --> H["AMF向NSSF执行Delete<br/>删除切片可用性"]
H --> I["NSSF数据库: 该AMF不再参与切片选择"]
I --> J["AMF向NRF注销NF Profile"]
J --> K["AMF实例停止"]
E -.->|"配置变更"| L["AMF重新执行Update<br/>更新切片可用性"]
L --> E
style D fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
style H fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style E fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style I fill:#fff3e0,stroke:#e65100,stroke-width:2px
可用性服务操作的完整对比：
| 操作 | HTTP方法 | URI | 请求体 | 成功响应 | 触发时机 |
|---|---|---|---|---|---|
| Update(全量) | PUT | /amfInstances/{NFid}/supportedNSSAIavailabilityData | 完整的可用性数据 | 200 OK + 数据 | NG Setup后 |
| Update(增量) | POST | /amfInstances/{NFid}/supportedNSSAIavailabilityData | 变更的可用性数据 | 200 OK + 数据 | RAN配置变更 |
| Delete | DELETE | /amfInstances/{NFid} | 无 | 204 No Content | AMF下线/维护 |
| Get | GET | /amfInstances/{NFid}/supportedNSSAIavailabilityData | 无 | 200 OK + 数据 | 查询验证 |
协议参考：根据3GPP TS 29.531第5.3节，Nnssf_NSSAIAvailability服务支持以上四种操作。TS 29.510第6.2节定义了NSSF的NF Profile和资源结构。TS 23.501第5.15节定义了网络切片的整体架构和可用性管理要求。
在实际网络中，Delete操作可能因各种原因失败。以下是一些常见的异常场景及其处理建议：
异常场景1: NSSF不可达
AMF发送DELETE请求后，TCP连接超时或被拒绝。
可能原因:
- NSSF服务未启动或已崩溃
- 网络故障导致SBI接口不可达
- 防火墙规则阻止了SBI流量
处理建议:
- 检查NSSF服务状态和日志
- 验证网络连通性
- 检查防火墙配置
异常场景2: NSSF返回错误响应
NSSF返回4xx或5xx错误码。
可能的错误码:
- 400 Bad Request: 请求格式错误
- 401 Unauthorized: 认证失败
- 403 Forbidden: AMF没有权限执行Delete
- 500 Internal Server Error: NSSF内部错误
- 503 Service Unavailable: NSSF暂时不可用
处理建议:
- 根据错误码进行针对性排查
- 检查AMF的SBI认证配置
- 查看NSSF的错误日志
异常场景3: Delete后NSSF数据残留
AMF发送Delete并收到204，但后续查询发现NSSF中仍有该AMF的记录。
可能原因:
- NSSF数据库同步延迟（如主备NSSF场景）
- NSSF实现缺陷
处理建议:
- 等待一段时间后重新查询
- 手动在NSSF上清理残留数据
- 联系设备厂商排查
| 验证项 | 结果 | 说明 |
|---|---|---|
| AMF执行退网操作 | OK | 运维人员通过OAM系统触发AMF退网/维护操作 |
| AMF发送Delete请求 | OK | HTTP DELETE方法，URI中包含正确的NF Instance ID |
| NSSF成功处理Delete | OK | 从数据库中删除该AMF的所有切片可用性记录 |
| NSSF返回正确响应 | OK | 204 No Content，无消息体 |
| AMF退网操作完成 | OK | 退网配置操作成功执行 |
| 信令流程符合3GPP规范 | OK | 符合TS 29.531第5.3.2.3节的定义 |
本测试用例完美验证了NSSF可用性服务删除操作的完整流程。当AMF执行退网/维护操作时，AMF能够通过Nnssf_NSSAIAvailability_Delete服务操作（HTTP DELETE）将自己之前上报的切片可用性信息从NSSF中删除，NSSF正确处理请求并返回204 No Content。
关键收获总结：
Delete与Update互补：Delete操作是Update操作的逆操作，两者共同构成了NSSF可用性服务的完整生命周期管理——AMF上线时Update注册切片信息，下线时Delete清理切片信息；
HTTP DELETE语义：Delete操作使用HTTP DELETE方法，URI中包含NFid，无请求体，成功返回204 No Content。DELETE的幂等性保证了重复请求不会导致错误；
删除的影响范围：Delete操作删除指定AMF在所有TA中的全部切片可用性记录，不是部分删除。如果只需要删除某个TA的切片信息，应使用Update操作（PUT或POST）而非Delete操作；
运维时序重要性：Delete操作应在AMF完全停止服务之前执行，确保NSSF不会将已下线的AMF作为切片选择的候选目标；
可恢复性：Delete操作是可逆的。当AMF重新上线后，可以通过Update操作重新上报切片可用性信息，恢复NSSF中的数据。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101
本文为《5G核心网原理与实践》实践篇之NSSF系列。该系列持续更新，关注「51学通信」不错过每篇更新。