<!-- title: NRF服务注册发现与性能实测 -->
<!-- domain: core-network -->

# 5G NRF服务注册发现信令流与大规模组网性能实测分析

## 一、NRF在5GC SBA架构中的核心定位

5G核心网采用服务化架构（Service-Based Architecture, SBA），彻底改变了4G EPC中点对点接口的静态连接模式。在这个架构中，**NRF（Network Repository Function）** 扮演着整个服务治理框架的"中枢神经"角色——所有NF（Network Function）实例上线时必须向NRF注册自身能力，任何NF在需要调用其他NF服务时必须通过NRF发现目标实例。

根据 **3GPP TS 29.510 V18.10.0（2025-03）** 的定义，NRF对外暴露三个核心服务：

| 服务名称 | 功能 | TS 29.510章节 | HTTP方法 |
|---------|------|-------------|---------|
| Nnrf_NFManagement | NF注册/更新/注销/订阅/通知 | Section 5.2 | PUT/POST/DELETE/PATCH |
| Nnrf_NFDiscovery | NF实例发现 | Section 5.3 | GET |
| Nnrf_AccessToken | OAuth2.0访问令牌 | Section 5.4 | POST |

NRF的架构定位可以从下面的SBA服务交互全景图中清晰看到：


![图表1](images/telecom-3gpp-1959-mermaid-0.png)

> *图表 1*


**设计意图**：NRF将4G中网元之间的硬编码连接关系，解耦为动态的服务注册与发现模式。这带来三个核心优势：（1）NF实例可以随时弹性扩缩容，新实例注册即可被其他NF发现；（2）通过NFProfile中的容量/负载信息实现负载均衡；（3）支持网络切片感知的服务路由——发现请求可携带S-NSSAI参数，NRF只返回匹配切片的NF实例。

## 二、Nnrf_NFManagement：NF注册完整信令流

### 2.1 NF注册流程（NFRegister）

当一个新的NF实例（如AMF）启动时，它必须首先向NRF发送注册请求。这个过程在 **TS 29.510 Section 5.2.2.2** 中定义。


![图表2](images/telecom-3gpp-1959-mermaid-1.png)

> *图表 2*


### 2.2 NFProfile核心IE详解

NFProfile是NRF中存储的最核心数据结构，定义在 **TS 29.510 Section 6.1.6.2.3**。下表列出关键字段：

| IE名称 | 类型 | 必选/可选 | 说明 | 示例值 |
|--------|------|---------|------|--------|
| nfInstanceId | UUID | 必选 | NF实例唯一标识，UUIDv4格式 | "3fa85f64-5717-4562-b3fc-2c963f66afa6" |
| nfType | Enum | 必选 | NF类型枚举值 | AMF/SMF/UPF/PCF/UDM/AUSF/NSSF/NRF |
| nfStatus | Enum | 必选 | 实例当前状态 | REGISTERED/SUSPENDED/UNDISCOVERABLE |
| heartBeatTimer | Integer | 可选 | 心跳间隔（秒） | 30 |
| sNssaiList | Array | 可选 | 支持的切片列表 | [{"sst":1,"sd":"010203"}] |
| plmnList | Array | 条件必选 | PLMN标识 | [{"mcc":"460","mnc":"00"}] |
| plmnIdList | Array | 条件必选 | 支持的PLMN列表（NRF特定） | [{"mcc":"460","mnc":"00"}] |
| nfServiceList | Array | 可选 | 该NF提供的服务列表 | Namf_Communication, Namf_EventExposure |
| capacity | Integer(0..65535) | 可选 | 静态容量指标 | 100 |
| load | Integer(0..100) | 可选 | 动态负载百分比 | 60 |
| fqdn | FQDN | 可选 | 全限定域名 | "amf1.5gc.mnc00.mcc460.3gppnetwork.org" |
| interPlmnFqdn | FQDN | 可选 | 跨PLMN通信的FQDN | — |
| ipv4Addresses | Array | 可选 | IPv4地址列表 | ["10.0.1.1"] |
| ipv6Addresses | Array | 可选 | IPv6地址列表 | ["2001:db8::1"] |
| allowedNfTypes | Array | 可选 | 允许发现该NF的NF类型 | [SMF, PCF] |
| priority | Integer(0..65535) | 可选 | 同类型NF中的优先级 | 10（数值越小优先级越高） |
| recoveryTime | DateTime | 可选 | NF恢复时间戳 | "2026-05-18T10:00:00Z" |
| nfServiceProviderName | String | 可选 | 厂商标识（R18新增） | "VendorA" |

一个实际的AMF NFProfile JSON示例如下：

```json
{
  "nfInstanceId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "nfType": "AMF",
  "nfStatus": "REGISTERED",
  "heartBeatTimer": 30,
  "sNssaiList": [
    {"sst": 1, "sd": "010203"},
    {"sst": 2, "sd": "040506"}
  ],
  "plmnList": [{"mcc": "460", "mnc": "00"}],
  "nfServiceList": [
    {
      "serviceInstanceId": "namf-comm-1",
      "serviceName": "namf-comm",
      "versions": [{"apiVersionInUri": "v1", "apiFullVersion": "1.0.0"}],
      "scheme": "https",
      "nfServiceStatus": "REGISTERED",
      "ipEndPoints": [{"ipv4Address": "10.0.1.1", "port": 8443}]
    }
  ],
  "capacity": 100,
  "load": 60,
  "priority": 10,
  "fqdn": "amf1.5gc.mnc00.mcc460.3gppnetwork.org",
  "allowedNfTypes": ["SMF", "PCF", "NSSF"]
}
```

### 2.3 心跳机制：NRF的"生死检测"

心跳机制是NRF判断NF实例存活状态的核心手段，定义在 **TS 29.510 Section 5.2.2.2.3**。其工作原理如下：

1. **初始心跳周期**：NF注册时NFProfile中携带 `heartBeatTimer` 字段（默认30秒）
2. **NRF动态调整**：NRF可在心跳响应中修改 `heartBeatTimer` 值（如从30秒调整为10秒，加速故障检测）
3. **超时判定**：如果NRF在3倍heartBeatTimer时间内未收到心跳，将NF标记为 `SUSPENDED` 或触发隐式注销（Implicit Deregistration）
4. **通知机制**：NRF向订阅了该NF状态的其他NF发送Status Notification

**设计意图**：心跳周期需要在"故障检测速度"和"NRF信令负载"之间取得平衡。在free5GC的实现中，NRF将NFProfile数据存储在MongoDB中，心跳超时后通过MongoDB TTL索引机制自动清理过期记录。Open5GS的实现则使用内存哈希表管理NFProfile，通过定时器扫描检测超时。

NFProfile中与心跳相关的状态转换图如下：


![图表3](images/telecom-3gpp-1959-mermaid-2.png)

> *图表 3*

## 三、Nnrf_NFDiscovery：服务发现信令流

### 3.1 发现请求流程

Nnrf_NFDiscovery服务定义在 **TS 29.510 Section 5.3**。这是5GC中调用频次最高的接口之一——每一次UE触发的注册、PDU会话建立、策略请求等流程中，都可能触发多次NF Discovery。


![图表4](images/telecom-3gpp-1959-mermaid-3.png)

> *图表 4*


### 3.2 Discovery查询参数详解

Nnrf_NFDiscovery_Request的查询参数是NRF实现智能路由的关键。以下表格列出最重要的过滤参数：

| 查询参数 | 类型 | 说明 | 过滤逻辑 |
|---------|------|------|---------|
| target-nf-type | Enum | 目标NF类型 | 精确匹配NFProfile.nfType |
| requester-nf-type | Enum | 请求方NF类型 | NRF检查NFProfile.allowedNfTypes |
| target-nf-instance-id | UUID | 指定NF实例ID | 精确匹配 |
| service-names | Array | 目标服务名列表 | 匹配NFProfile.nfServiceList |
| snssais | Array | 切片标识 | 匹配NFProfile.sNssaiList |
| dnn | String | 数据网络名 | 匹配NFProfile.dnnList |
| plmn-id | Object | PLMN标识 | 匹配NFProfile.plmnList |
| tai | Array | 跟踪区标识 | 匹配NFProfile.taiList |
| preferred-locality | String | 优先位置区域 | 匹配NFProfile.locality |
| nf-status | Enum | NF状态过滤 | 默认只返回REGISTERED |

**free5GC的实现细节**：在free5GC中，NRF将NFProfile存储在MongoDB的 `NfProfile` 集合中。当收到Discovery请求时，NRF的 `NFDiscoveryProcedure` 模块调用 `buildFilter` 函数将HTTP查询参数转换为MongoDB查询条件。例如，查询 `target-nf-type=PCF&snssais={"sst":1}` 会被转换为：

```javascript
// free5GC NRF MongoDB查询构建（简化）
db.NfProfile.find({
  "nfType": "PCF",
  "nfStatus": "REGISTERED",
  "sNssaiList": {"$elemMatch": {"sst": 1, "sd": "010203"}},
  "nfServiceList.serviceName": {"$in": ["npcf-smpolicycontrol"]}
})
```

**性能隐患**：如果没有为MongoDB建立合适的复合索引，当NF实例数超过数百时，Discovery查询延迟会急剧上升。这正是H-NRF等研究项目的出发点。

## 四、Nnrf_AccessToken：OAuth2.0授权流

在5GC SBA中，NF之间的服务调用需要经过OAuth2.0授权。NRF作为Authorization Server，提供 `Nnrf_AccessToken` 服务（TS 29.510 Section 5.4）。


![图表5](images/telecom-3gpp-1959-mermaid-4.png)

> *图表 5*


**关键设计**：Access Token采用JWT（JSON Web Token）格式，包含 `nfInstanceId`（颁发对象）、`targetNfType`（目标NF类型）、`scope`（授权范围）、`exp`（过期时间）等Claims。NF Producer通过验证JWT签名来确认请求者的身份和权限，无需每次都向NRF查询。

## 五、SCP通信模型与NRF的协作

在大型5GC部署中，NRF与SCP（Service Communication Proxy）的配合至关重要。3GPP TS 23.501 Annex E定义了四种通信模型：

| 模型 | 发现方式 | 通信方式 | NRF交互 | 适用场景 |
|------|---------|---------|---------|---------|
| Model A | 直接发现 | 直接通信 | NF→NRF→NF→NF | 小规模部署 |
| Model B | 无需发现 | 直接通信 | 无（静态配置） | 极简部署 |
| Model C | 直接发现 | 间接通信（经SCP路由） | NF→NRF→NF→SCP→NF | 中等规模 |
| Model D | 委托发现 | 间接通信（经SCP路由） | SCP→NRF（代替NF） | **大规模部署（推荐）** |

在 **Model D** 模式下，NF Consumer完全不与NRF直接交互。SCP代替NF完成Discovery，并根据发现结果直接路由请求到目标NF Producer。这大幅降低了NRF的信令压力——在大规模组网中，NRF的Discovery请求量可减少约 **70-80%**。


![图表6](images/telecom-3gpp-1959-mermaid-5.png)

> *图表 6*

## 六、大规模组网性能实测与分析

### 6.1 性能瓶颈分析

NRF作为5GC中的"注册中心"，在大规模部署中面临严峻的性能挑战。根据 **H-NRF论文（ACM APNet 2025）** 和 **H2-NRF论文（Computer Networks 2026）** 的研究数据：

| 性能维度 | 瓶颈表现 | 影响范围 |
|---------|---------|---------|
| NF注册吞吐量 | free5GC原生NRF在100+NF并发注册时，注册延迟从<10ms上升到>500ms | 网络恢复场景、批量扩容 |
| Discovery查询延迟 | 当NFProfile数量>1000时，MongoDB查询延迟线性增长 | 每次UE注册/PDU会话建立 |
| 心跳信令风暴 | 数百NF同时启动时，心跳消息洪泛导致NRF CPU过载 | 灾难恢复场景 |
| 单点故障风险 | NRF宕机→全网NF无法注册/发现→服务中断 | 全局影响 |

### 6.2 开源实现性能对比

根据 **Mukute et al. (IEEE 2024)** 对OpenAirInterface、Open5GS、free5GC三大开源5GC的控制面性能基准测试数据：

| 指标 | free5GC v3.x | Open5GS v2.x | OAI CN5G |
|------|-------------|-------------|---------|
| NF注册延迟（单实例） | 5-8ms | 3-6ms | 8-12ms |
| NF注册延迟（100实例并发） | 200-500ms | 100-300ms | 300-800ms |
| Discovery查询延迟（100条Profile） | 8-15ms | 5-10ms | 12-20ms |
| Discovery查询延迟（1000条Profile） | 80-150ms | 40-80ms | 100-200ms |
| 心跳处理吞吐量 | ~200 TPS | ~500 TPS | ~150 TPS |
| 数据存储后端 | MongoDB | 内存/DB | 嵌入式 |
| 内存占用（100NF） | ~512MB | ~256MB | ~768MB |

> 注：以上数据综合自多篇论文的测试环境（单节点，8核CPU，16GB RAM），实际商用部署性能会有显著差异。

### 6.3 H-NRF性能优化方案

H-NRF（ACM APNet 2025）提出了一种分层索引框架，在free5GC基础上实现了数量级的性能提升：

**核心优化策略**：

1. **层次化索引结构**：按 `nfType → sNssai → plmnId` 建立三级索引树，将Discovery查询从MongoDB全表扫描优化为O(1)的哈希查找
2. **内存映射注册表**：将热点NFProfile数据常驻内存，避免每次查询都访问MongoDB
3. **批量心跳处理**：合并同一NF类型的心跳更新，减少数据库写操作

| 测试场景 | free5GC原生NRF | H-NRF | 提升倍数 |
|---------|--------------|-------|---------|
| NF注册（单实例延迟） | 6.5ms | 0.8ms | 8.1x |
| NF注册（1000实例吞吐） | 150 TPS | 12,000 TPS | 80x |
| Discovery查询（1000条Profile） | 120ms | 1.5ms | 80x |
| Discovery查询（10000条Profile） | >1000ms | 2.1ms | >476x |
| 内存占用（1000 NF） | ~1.2GB | ~450MB | 节省62% |

### 6.4 5GC-Bench压力测试框架

**5GC-Bench（IEEE Wireless Communications 2025）** 提供了专门的5GC VNF压力测试框架。针对NRF的关键测试场景包括：

- **风暴注册测试**：模拟1000个NF实例在5秒内同时发起注册（灾难恢复场景）
- **高频Discovery测试**：以10000 RPS速率发送Discovery请求（模拟高峰时段）
- **心跳风暴测试**：模拟心跳周期缩短至1秒时的NRF表现
- **混合负载测试**：注册+发现+心跳+通知同时进行

实测发现，在混合负载下，free5GC NRF的CPU利用率在约300 TPS时达到90%瓶颈，而采用H-NRF优化后可承受超过10000 TPS。

## 七、NRF分层部署架构

针对大规模运营商网络，爱立信、华为等厂商推荐**NRF分级部署**策略：


![图表7](images/telecom-3gpp-1959-mermaid-6.png)

> *图表 7*


**分级部署的优势**：
- 本域NF发现（如AMF发现同域SMF）仅需查询Regional NRF，延迟<2ms
- 跨域NF发现（如华东SMF发现华南PCF）通过Central NRF中转，延迟约10-20ms
- Regional NRF故障仅影响本域，不波及其他区域
- 可按切片维度进一步划分NRF实例（如URLLC切片部署专用NRF）

## 八、实战抓包识别与故障排查

### 8.1 抓包识别NRF交互

在5GC中抓包分析NRF信令，主要关注以下HTTP/2流：

```
# 过滤NRF注册/发现/心跳消息
tcp.port == 8443 && http2

# 识别NF注册（PUT方法）
http2.headers.method == "PUT" && http2.headers.path contains "nf-instances"

# 识别NF发现（GET方法）
http2.headers.method == "GET" && http2.headers.path contains "nnrf-disc"

# 识别心跳（PATCH方法）
http2.headers.method == "PATCH" && http2.headers.path contains "nf-instances"
```

### 8.2 常见故障与排错

| 故障现象 | 可能原因 | 排错思路 |
|---------|---------|---------|
| NF注册失败（HTTP 503） | NRF过载或存储后端不可用 | 检查NRF资源使用率、MongoDB连接状态 |
| Discovery无结果返回 | NFProfile中sNssai/PLMN不匹配 | 对比请求参数与已注册NFProfile的字段 |
| 心跳超时导致NF被注销 | 网络抖动或NF CPU过载无法按时发送心跳 | 检查NF→NRF链路RTT，考虑增大heartBeatTimer |
| Access Token验证失败 | JWT过期或NRF证书更新 | 检查Token的exp字段，确认NRF公钥是否最新 |
| 大量NF同时SUSPENDED | 心跳信令风暴或NRF CPU瓶颈 | 检查是否大批NF同时启动，考虑分批注册策略 |
## 九、常见问题

**Q1: NRF的Nnrf_NFManagement和Nnrf_NFDiscovery的区别是什么？**

A: Nnrf_NFManagement是"写"接口，NF通过它向NRF注册、更新、注销自己的Profile，以及订阅其他NF的状态变更通知。Nnrf_NFDiscovery是"读"接口，NF通过它查询满足特定条件的NF实例列表。简而言之，Management管的是"我自己"，Discovery查的是"别人"。

**Q2: Model C和Model D的核心区别是什么？运营商应如何选择？**

A: Model C中，NF Consumer自己向NRF发起Discovery请求，获取目标NF地址后通过SCP路由。Model D中，NF Consumer完全不感知NRF，由SCP代替完成Discovery和路由。选择依据：（1）NF数量<200时两者性能差异不大，Model C更简单；（2）NF数量>500时强烈建议Model D，NRF信令负载可降低70%以上；（3）Model D要求SCP具备Discovery能力，对SCP实现要求更高。

**Q3: NRF宕机会导致整个5GC瘫痪吗？**

A: 理论上是的——新NF无法注册、新Discovery请求无法处理。但实际商用部署有多重保护：（1）NRF采用主备或集群部署，单实例故障自动切换；（2）NF Consumer有本地Discovery结果缓存（Cache），短时间内可继续使用缓存的目标NF地址；（3）SCP Model D模式下，SCP也有Discovery结果缓存。因此短暂NRF故障通常不会导致业务立即中断，但如果故障持续超过缓存TTL（通常5-15分钟），新会话将无法建立。

**Q4: 心跳周期设置多少合适？**

A: TS 29.510规定默认30秒，但可由NRF动态调整。建议策略：（1）核心NF（AMF/SMF）设置10-15秒，快速检测故障；（2）辅助NF（UDM/AUSF）设置30秒，降低信令开销；（3）灾难恢复场景可临时缩短至5秒。注意：心跳周期过短会显著增加NRF负载——1000个NF×每10秒1次心跳 = 100 TPS纯心跳流量。

**Q5: free5GC和Open5GS的NRF实现哪个性能更好？**

A: 综合多篇论文的基准测试数据，Open5GS的NRF在大多数场景下性能优于free5GC，主要原因：（1）Open5GS使用内存数据结构管理NFProfile，避免了free5GC的MongoDB查询开销；（2）Open5GS的事件驱动架构更适合处理高并发HTTP/2请求。但free5GC的数据持久化方案更适合NF数量频繁变化的场景（如MEC边缘计算）。H-NRF研究在free5GC基础上实现了80倍的性能提升，说明通过优化索引和缓存策略，两种实现的性能差距可以被大幅缩小。

## 参考来源

1. [3GPP TS 29.510 V18.10.0 (2025-03)](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3345) — Network Function Repository Services; Stage 3（核心规范，定义NRF三大服务的API和信令流程）
2. [H-NRF: A High-performance and Evolutive NRF Framework for Large-scale Mobile Core Network (ACM APNet 2025)](https://dl.acm.org/doi/10.1145/3735358.3735367) — NRF分层索引优化框架，提供详细的性能基准数据
3. [H2-NRF: A high-performance and evolvable NRF with hierarchical indexing (Computer Networks 2026)](https://www.sciencedirect.com/science/article/abs/pii/S1389128626003932) — 在H-NRF基础上的进一步优化，含单核CPU性能极限测试
4. [Mukute et al., Control Plane Performance Benchmarking of Open-Source 5G Core Networks (IEEE 2024)](https://ieeexplore.ieee.org/document/10633278) — OAI/Open5GS/free5GC三大开源5GC控制面性能基准测试
5. [5GC-Bench: A Framework for Stress-Testing and Benchmarking 5G Core VNFs (IEEE Wireless Communications 2025)](https://arxiv.org/abs/2509.18443) — 5GC VNF压力测试框架，含NRF专项测试场景

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)