《5G核心网原理与实践》实践篇 · NSSF 网元功能
作者：爱卫生
在5GC服务化架构的生命周期管理中，NF的注册与去注册（Deregistration）是两个对称且同样重要的操作。当NSSF因升级、维护、卸载等原因需要下线时，它必须主动向NRF发起去注册请求，以通知NRF将该NF实例从服务目录中移除。如果NSSF不执行去注册操作，NRF中将持续保留该实例的"幽灵"记录，导致其他NF仍尝试向已下线的NSSF发送请求，从而引发服务调用失败。
本文将详细讲解NSSF向NRF发起去注册的完整流程，包括去注册的触发条件、去注册请求的构造、NRF的清理逻辑以及去注册后的状态验证。通过本文的学习，读者将深入理解5GC中NF生命周期管理中去注册机制的重要性与实现细节。
相关3GPP规范：
TS 29.510：NF Service Framework（NF服务框架），定义了Nnrf_NFManagement服务接口
TS 23.501：5G系统架构，定义了NSSF的功能与接口
TS 29.531：NSSF服务接口规范
关键SBI接口：
Nnrf_NFManagement_NFDeregister：NF去注册服务操作（HTTP DELETE）
flowchart TD
A[确认NSSF在NRF中的注册状态] --> B[NSSF触发去注册流程]
B --> C[NSSF发起升级或卸载操作]
C --> D[NSSF发送Nnrf_NFManagement_NFDeregister DELETE请求]
D --> E[NRF接收并验证去注册请求]
E --> F{验证NF Instance ID有效}
F -- 否 --> G[NRF返回404 Not Found]
F -- 是 --> H[NRF删除NF Profile存储记录]
H --> I[NRF清除相关服务索引]
I --> J[NRF返回204 No Content响应]
J --> K[通过维护界面确认NSSF信息已删除]
K --> L[其他NF无法再通过NRF发现该NSSF]
验证NSSF在下线（升级或卸载）时，能够主动向NRF发起去注册请求，完成NF实例信息的清除。具体验证点包括：
NSSF在NRF中处于已注册状态；
NSSF升级或卸载时，向NRF发送Deregistration Request请求，请求消息中携带对应的网络功能信息（如NSSF注册标识/NF Instance ID）；
NRF通过NSSF Deregistration Response响应去注册已完成；
通过操作维护命令或界面查看到NSSF实例信息已被删除；
去注册完成后，其他NF无法通过NRF发现该NSSF实例。
| 序号 | 前置条件 |
|---|---|
| 1 | NSSF已在NRF成功完成服务注册，注册状态正常 |
| 2 | NRF服务运行正常，可接受NF去注册请求 |
| 3 | NSSF实例运行正常，心跳机制工作正常 |
| 4 | 网络连通性正常，NSSF与NRF之间的SBI接口可达 |
| 5 | 已建立各接口信令跟踪和用户跟踪 |
| 6 | NSSF升级或卸载计划已就绪 |
在发起去注册之前，首先确认NSSF当前在NRF中的注册状态，确保NSSF处于已注册状态。
查询NRF上的NSSF注册信息：
GET /nnrf-nfm/v1/nf-instances?nf-type=NSSF HTTP/1.1
Host: 10.XX.XX.XX:8443
Accept: application/json
预期返回信息：
{
"nfInstances": [
{
"nfInstanceId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"nfType": "NSSF",
"nfStatus": "REGISTERED",
"heartBeatTimer": 30,
"sbi": {
"scheme": "https",
"addresses": [
{
"ipv4Address": "10.XX.XX.XX",
"port": 8443
}
]
},
"nsiList": [
{
"snssai": {"sst": 1, "sd": "010203"},
"nsiId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}
],
"plmnList": [{"mcc": "460", "mnc": "XX"}]
}
]
}
确认项：
NSSF的NF Instance ID：XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
NF Status：REGISTERED
注册信息完整，包含NF Profile、服务列表、切片信息等
通过切片管理平台或操作维护界面，对NSSF发起升级或卸载操作。NSSF在收到升级/卸载指令后，将自动触发向NRF的去注册流程。
升级场景：
NSSF软件版本升级（滚动升级或全量升级）
NSSF配置批量变更需要重启
卸载场景：
网络切片退服，NSSF不再需要
网络维护，临时下线NSSF
NSSF在关闭进程前，主动向NRF发送去注册请求。
去注册流程完成后，通过以下方式确认NSSF实例信息已从NRF中删除：
NRF查询验证：向NRF发送查询请求，确认NSSF不再出现在NF实例列表中
信令跟踪验证：查看NSSF与NRF之间的信令消息，确认去注册请求和响应正常
操作维护界面验证：在管理界面上查看NF注册列表，确认NSSF记录已清除
验证查询：
GET /nnrf-nfm/v1/nf-instances/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX HTTP/1.1
Host: 10.XX.XX.XX:8443
Accept: application/json
预期返回：
HTTP/1.1 404 Not Found
Content-Type: application/problem+json
{
"type": "NF_INSTANCE_NOT_FOUND",
"title": "NF instance not found",
"status": 404,
"detail": "The NF instance with the given NF Instance ID does not exist.",
"instanceId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}
NSSF在升级或卸载时，主动向NRF发送Deregistration Request请求，请求消息中携带对应的网络功能信息（如NSSF注册标识/NF Instance ID）。
Nnrf_NFManagement_NFDeregister请求消息：
DELETE /nnrf-nfm/v1/nf-instances/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX HTTP/1.1
Host: 10.XX.XX.XX:8443
Accept: application/json
Frame 1：NSSF -> NRF，Nnrf_NFManagement_NFDeregister DELETE请求，URI中携带NF Instance ID
请求说明：
HTTP方法：DELETE
URI：/nnrf-nfm/v1/nf-instances/{nfInstanceId}
请求参数：
nfInstanceId（路径参数）：NSSF的NF实例唯一标识，即注册时使用的UUID
该请求通常不需要Request Body，NF Instance ID已包含在URI中
NRF收到NSSF的去注册请求后，验证NF Instance ID的有效性，然后删除对应的NF Profile记录，并通过Deregistration Response响应去注册已完成。
Nnrf_NFManagement_NFDeregister响应消息：
HTTP/1.1 204 No Content
Frame 2：NRF -> NSSF，Nnrf_NFManagement_NFDeregister 204 No Content响应，确认去注册完成
响应说明：
HTTP状态码：204 No Content，表示请求成功且不返回内容
NRF已成功删除NSSF的NF Profile记录
与该NSSF相关的服务索引已清除
异常响应场景：
| 状态码 | 含义 | 场景 |
|---|---|---|
| 204 No Content | 去注册成功 | 正常流程 |
| 404 Not Found | NF实例不存在 | NF Instance ID未注册或已去注册 |
| 403 Forbidden | 权限不足 | 请求方非NF所有者 |
| 500 Internal Server Error | 服务器内部错误 | NRF处理异常 |
通过操作维护命令或界面查看到NSSF实例信息已经被删除。
去注册前NRF上的NF列表：
NF Instance List:
1. AMF - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
2. SMF - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
3. UDM - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
4. NSSF - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED <-- 待去注册
5. AUSF - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
去注册后NRF上的NF列表：
NF Instance List:
1. AMF - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
2. SMF - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
3. UDM - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
4. AUSF - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - REGISTERED
NSSF记录已从列表中移除，其他NF通过NRF的NFDiscovery服务将无法再发现该NSSF实例。
根据3GPP TS 29.510规范，Nnrf_NFManagement_NFDeregister服务操作用于已注册的NF向NRF发起去注册，请求NRF删除该NF的Profile信息。该操作使用HTTP DELETE方法：
DELETE /nnrf-nfm/v1/nf-instances/{nfInstanceId}
NSSF去注册通常在以下场景触发：
1) 主动去注册
NSSF软件升级（滚动升级中旧实例下线）
NSSF卸载/退服
管理员手动触发
NSSF配置变更需要重启
2) 被动去注册（NRF发起）
NSSF心跳超时（连续3次未收到心跳）
NRF检测到NSSF不可达
NRF执行NF状态轮检发现NSSF无响应
NRF收到NSSF的去注册请求后，执行以下处理：
验证NF Instance ID：检查请求中的NF Instance ID是否存在于已注册的NF记录中
权限验证：验证请求方是否有权限删除该NF实例
删除NF Profile：从NRF数据库中删除该NF实例的完整Profile记录
清除服务索引：从服务名到NF实例的索引中移除该NSSF的所有条目
通知订阅者：如果其他NF订阅了该NSSF的状态变更通知，NRF会发送通知
返回结果：通过204 No Content响应确认去注册完成
时间轴 消息方向 消息名称
---------------------------------------------------------
T0 管理员/系统 发起NSSF升级或卸载
T1 NSSF 收到下线指令，准备去注册
T2 NSSF --> NRF DELETE /nnrf-nfm/v1/nf-instances/{id}
T3 NRF 验证NF Instance ID
T4 NRF 删除NF Profile记录
T5 NRF 清除服务索引
T6 NRF --> NSSF 204 No Content
T7 NRF 通知订阅了状态变更的NF
T8 NSSF 进程优雅关闭
如果NSSF因异常（如进程崩溃、网络中断等）未能主动发起去注册，NRF将通过心跳超时机制进行被动去注册：
时间轴 事件
---------------------------------------------------------
T0 NSSF最后一次心跳成功
T1 心跳超时（heartBeatTimer x 1），NRF标记NSSF为SUSPENDED
T2 心跳超时（heartBeatTimer x 2），NRF标记NSSF为UNREGISTERED
T3 心跳超时（heartBeatTimer x 3），NRF删除NSSF记录
T4 NRF通知订阅了状态变更的NF
被动去注册的风险：
存在时间窗口（3倍心跳时间），期间其他NF可能仍尝试调用已不可用的NSSF
可能导致服务调用失败和错误日志
最佳实践：
NSSF应优先使用主动去注册，确保NRF及时更新
应用优雅关闭（Graceful Shutdown）机制，在进程退出前完成去注册
心跳间隔不宜设置过长，建议30秒以内
NSSF去注册后，NRF需要确保NFDiscovery服务不再返回该NSSF的信息：
已缓存的发现结果：其他NF之前缓存的NSSF发现结果可能仍有效
订阅通知机制：如果AMF等NF订阅了NSSF的状态变更通知，NRF会通过Nnrf_NFManagement_NFStatusNotify发送通知
发现请求的实时查询：新的NFDiscovery请求将不再返回已去注册的NSSF
NSSF去注册后，如果需要恢复服务，需要重新执行NFRegister流程：
1. NSSF重新部署或启动
2. NSSF发送PUT /nnrf-nfm/v1/nf-instances/{nfInstanceId}
3. NRF返回201 Created
4. NSSF注册恢复，其他NF可重新发现
| 状态码 | 含义 | 对应操作 |
|---|---|---|
| 204 No Content | 去注册成功 | DELETE成功，无返回Body |
| 404 Not Found | 实例不存在 | NF Instance ID未找到 |
| 403 Forbidden | 权限不足 | 非NF所有者 |
| 503 Service Unavailable | 服务不可用 | NRF过载 |
现象：NSSF已发送去注册请求并收到204响应，但查询NRF仍返回NSSF信息。
可能原因：
NRF的数据库同步延迟（集群部署场景）
NRF缓存未及时刷新
去注册请求被中间代理缓存
排查步骤：
等待数秒后重新查询
检查NRF集群的同步状态
清除NRF缓存后重试
现象：NSSF进程崩溃，NRF中仍保留NSSF的注册信息。
影响：
其他NF可能尝试调用已不可用的NSSF，导致请求失败
在3倍心跳时间后NRF才会被动去注册
解决方案：
优化NSSF的优雅关闭机制，确保进程退出前发送去注册请求
缩短心跳间隔，减少被动去注册的延迟
使用进程管理器（如K8s的preStop hook）在容器终止前执行去注册
现象：NSSF发送去注册请求后，NRF返回404 Not Found。
可能原因：
NSSF的注册已过期（心跳超时导致NRF已删除记录）
NF Instance ID不正确
NSSF注册到了不同的NRF实例（集群环境）
排查步骤：
确认NF Instance ID是否正确
检查NSSF是否向正确的NRF发送请求
查看NRF日志确认NF记录状态
本测试用例验证了NSSF向NRF发起去注册的完整流程。测试结果表明：
NSSF在NRF中处于已注册状态，注册信息完整；
NSSF在升级或卸载时，能够主动向NRF发送Nnrf_NFManagement_NFDeregister请求（HTTP DELETE），请求消息中携带NF Instance ID作为去注册标识；
NRF收到去注册请求后，成功删除NSSF的NF Profile记录和相关服务索引，并通过204 No Content响应确认去注册完成；
通过操作维护命令或界面可确认NSSF实例信息已从NRF中删除；
去注册完成后，其他NF无法再通过NRF的NFDiscovery服务发现该NSSF实例。
该测试用例验证了3GPP TS 29.510中定义的NF去注册机制在NSSF上的正确实现。建议在实际部署中优先使用主动去注册（而非依赖心跳超时的被动去注册），以保证NF服务目录的准确性和实时性。
数据脱敏声明：本文中所有SUPI、IP地址、NF Instance ID等敏感信息均已做脱敏处理（如SUPI显示为"imsi-460XX00000XXXX"，IP显示为"10.XX.XX.XX"，Instance ID显示为"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"），不影响技术原理的理解与分析。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101