Open5GS中NRF通信模型C与D的技术解析与实现优化

核心问题背景

在5G核心网架构中，服务通信代理(SCP)与网络存储功能(NRF)的交互模式是一个关键设计点。3GPP标准23.501定义了四种服务通信模型，其中模型C（间接通信无委托发现）和模型D（间接通信带委托发现）的实现细节在标准中未完全明确。

标准规范解读

根据3GPP 23.501附件E的描述：

• 模型B：NF与NRF直接通信
• 模型C：NF与NRF间通过SCP进行间接通信，但发现过程直接进行
• 模型D：NF与NRF间通过SCP进行间接通信，且发现过程也委托给SCP

然而标准对NRF管理接口(nnrf-nfm)的具体通信路径（如注册、心跳、注销等）未做明确规定，这导致了不同厂商实现上的差异。

Open5GS的原实现分析

在Open5GS v2.7.1版本中：

• 发现过程(discovery)会根据配置决定是否通过SCP代理
• 但NRF管理接口(nnrf-nfm)统一采用SCP代理方式
• 使用ogs_sbi_send_notification_request()函数处理NRF通知请求时，会无条件通过SCP转发

这种实现限制了部署灵活性，特别是在模型C场景下，理论上发现过程应直接进行，但管理接口却被强制通过SCP代理。

技术优化方案

项目维护者采纳了社区建议，实现了更灵活的通信模式控制机制：

1. 配置分离：将NRF管理功能和发现功能的代理设置解耦

2. 精细控制：新增delegated配置段，可独立控制：

   • nrf.nfm：NRF管理功能代理设置
   • nrf.disc：NRF发现功能代理设置
   • scp.next：下一跳通信代理设置

3. 典型配置示例：

sbi:
  client:
    nrf:
      - uri: http://127.0.0.10:7777/
    scp:
      - uri: http://127.0.0.200:7777/
    delegated:
      nrf:
        nfm: no    # NRF管理功能直连
        disc: no   # NRF发现功能直连
      scp:
        next: no   # 不通过SCP代理下一跳

技术价值与影响

这一优化带来了以下优势：

1. 标准符合性：严格区分模型C和模型D的实现差异
2. 部署灵活性：运营商可根据需要混合使用不同通信模式
3. 性能优化：关键管理接口可绕过SCP直接通信，降低时延
4. 架构清晰：各功能模块的通信路径明确可配置

最佳实践建议

对于不同部署场景：

1. 模型C实现：NRF管理和发现均设为直连
2. 模型D实现：NRF管理和发现均设为代理
3. 混合模式：可灵活组合，如管理直连+发现代理

这项改进体现了开源项目对标准解读的严谨性和架构设计的灵活性，为5G核心网部署提供了更多可能性。