51学通信

深度解析 3GPP TS 23.501：5GC的“中后台铁三角” - NEF, NRF, UDM

20分钟阅读

本文技术原理深度参考了3GPP TS 2

3.501 V18.9.0 (2025-03) Release 18规范中，关于“6.2.5 NEF (Network Exposure Function)”、“6.2.6 NRF (Network Repository Function)”和“6.2.7 UDM (Unified Data Management)”的核心章节，旨在为读者提供一个5G核心网“中后台铁三角”——NEF、NRF、UDM——如何协同工作，实现网络能力开放、服务发现与注册、以及用户数据统一管理的全景视图。本文是解读“6 Network Functions”系列的第四部分。

深度解析 3GPP TS 23.501：5GC的“中后台铁三角” - NEF, NRF, UDM

欢迎来到“解构5G核心网”的NF深度解析系列。在前面的文章中，我们已经详细剖析了站在台前的三大主角：AMF（接入与移动性）、SMF（会话管理）和PCF（策略控制）。它们直接与UE的连接、会话和策略相关，构成了5G服务的“前台”。然而，一个高效运转的现代化系统，离不开强大而稳健的“中后台”支持。

今天，我们将深入5G核心网的后台，揭秘构成其服务化架构基石的“铁三角”——NEF、NRF和UDM。这三个网络功能（NF）虽然不直接处理用户的数据包，但它们是整个5GC能够灵活、智能、开放地运转的根本保障。

  • NEF (Network Exposure Function): 5GC与外部世界沟通的“外交部”与“安全网关”。

  • NRF (Network Repository Function): 5GC内部所有服务的“注册中心”与“黄页目录”。

  • UDM (Unified Data Management): 5GC的用户数据“中央银行”，掌管着所有用户的“数字身份”和“签约档案”。

为了将这三者的复杂关系具象化，让我们回到**“未来城市（Future City）”**的场景。

  • 一家名为**“SwiftLogistics”**的第三方物流公司，希望调用“未来城市”5G网络的能力，实时追踪其无人配送车的位置，并为其规划最优路径。

  • 城市网络内部，新上线了一个**NWDAF（网络数据分析功能）**实例，它需要向全网“宣告”自己的存在，并说明自己能提供哪些数据分析服务。

  • 我们的老朋友小晴，刚刚办理了一项新的“云游戏加速”业务包，她的签约信息需要被安全、准确地更新。

我们将通过这三个看似独立的事件，来串联起NEF、NRF和UDM是如何在幕后协同工作，支撑起整个5G服务的生态体系的。

1. “外交部”与“安全网关”：NEF (6.2.5 Network Exposure Function)

NEF是5G能力开放的核心，它使得5G网络不再是一个封闭的“黑盒”，而是能够将其强大的通信、定位、计算能力，安全地开放给第三方应用（AF）使用。

The Network Exposure Function (NEF) supports the following independent functionality:

  • Exposure of capabilities and events.
  • Secure provision of information from external application to 3GPP network.
  • Translation of internal-external information.

1.1 NEF的三大核心职责

  1. 向外暴露 (Exposure): NEF将内部网络功能（如AMF、SMF、PCF）的能力，抽象并封装成一组标准化的、安全的API接口，供外部的AF调用。AF无需了解5GC内部复杂的信令流程，只需调用NEF提供的简单API即可。

  2. 安全接入 (Secure Provision): NEF是外部应用进入5GC的唯一安全入口。它负责对AF进行认证和授权，确保只有合法的、经过授权的应用才能访问网络能力。同时，它还能对AF的请求进行节流（Throttling），防止恶意或过量的API调用冲击核心网。

  3. 信息翻译 (Translation): NEF扮演了“翻译官”的角色。它将外部AF使用的标识符（如应用特定的用户ID），翻译成5GC内部能理解的标识符（如SUPI或GPSI）；反之亦然。同时，它还会屏蔽网络内部的拓扑和用户的敏感信息，保护网络安全和用户隐私。

1.2 场景代入：“SwiftLogistics”的物流追踪请求

  1. API调用： “SwiftLogistics”的后台应用（AF），向“未来城市”5G网络的NEF发起了一个API调用（例如，一个HTTPS请求）：POST /api/v1/location/request，请求内容是：“请告诉我车辆ID为‘SL-V007’的实时位置”。

  2. NEF的安全检查与翻译：

    • NEF首先检查API请求头中的认证令牌，确认“SwiftLogistics”是合法应用，并有权调用位置服务。

    • NEF将外部的“车辆ID ‘SL-V007’”翻译成5GC内部的UE标识符（例如，通过查询UDM，找到对应的GPSI或SUPI）。

  3. NEF与内部NF交互： NEF向AMF发起一个Namf_Location_ProvideLocation服务请求，获取该UE的精确位置信息。

  4. 返回结果： AMF返回位置信息后，NEF将其封装成API响应的格式，返回给“SwiftLogistics”的AF。

整个过程中，“SwiftLogistics”完全不知道AMF的存在，它的请求被NEF安全、透明地处理了。

2. “注册中心”与“黄页”：NRF (6.2.6 Network Repository Function)

在服务化架构下，网络功能实例是动态创建、扩展和消亡的。一个NF如何知道去哪里找到另一个NF来调用其服务？这就是NRF要解决的问题。

The Network Repository Function (NRF) supports the following functionality:

  • Supports service discovery function. Receive NF Discovery Request from NF instance or SCP and provides the information of the discovered NF instances…
  • Maintains the NF profile of available NF instances and their supported services.

2.1 NRF的核心职责

  1. NF注册 (NF Register): 任何一个NF实例在上线时，都必须向NRF进行注册。它需要提交一份详细的**“NF Profile”**，这份Profile就像是它的“名片”，包含了：

    • 我是谁： NF实例ID, NF类型（AMF, SMF…）。

    • 我在哪： FQDN或IP地址。

    • 我能做什么： 支持的服务列表（如nssf-nsselection, namf-comm）。

    • 我的服务范围： 支持的S-NSSAI、DNN、TAI列表等。

  2. NF发现 (NF Discovery): 当一个NF（消费者）需要调用另一个NF（生产者）的服务时，它会向NRF发起一个发现请求。请求中包含它想找的NF的条件，例如：“请帮我找一个能够服务于S-NSSAI={SST=1, SD=1}和DNN=“internet”的SMF”。

  3. 返回结果： NRF会查询自己的“注册表”，将所有满足条件的NF实例的Profile返回给请求者。请求者再根据返回的列表（可能包含多个实例），根据负载均衡等策略，选择一个进行调用。

  4. 状态维护与通知： NRF还负责维护NF实例的“健康状态”（心跳机制），并在一个NF实例下线或更新时，通知所有订阅了该状态变化的NF。

2.2 场景代入：新上线的NWDAF“广而告之”

  1. 注册： 张工在“未来城市”网络中新部署了一个NWDAF实例，用于网络拥塞分析。该实例启动后，立即向NRF发起注册，提交的NF Profile中声明：“我是NWDAF-03，我能提供的分析服务是‘网络切片负载分析’（Analytics ID=5），我服务的S-NSSAI是{SST=1}”。

  2. 发现： 一段时间后，一个NSSF（网络切片选择功能）在为UE选择切片时，需要考虑网络负载。它向NRF发起发现请求：“请帮我找一个能提供‘网络切片负载分析’服务的NWDAF”。

  3. 调用： NRF将NWDAF-03的Profile返回给了NSSF。NSSF随即向NWDAF-03发起订阅，请求获取实时的切片负载信息。

通过NRF这个动态的“注册与发现”中心，5GC实现了真正的即插即用和灵活扩展。任何一个新的NF实例，只要向NRF注册，就能立刻被全网发现和使用。

3. “中央银行”：UDM (6.2.7 Unified Data Management)

UDM是5G核心网中用户数据的权威来源。它整合了4G时代HSS的大部分功能，并以服务化的方式对外提供。

The Unified Data Management (UDM) includes support for the following functionality:

  • Generation of 3GPP AKA Authentication Credentials.
  • User Identification Handling (e.g. storage and management of SUPI for each subscriber in the 5G system).
  • Support of de-concealment of privacy-protected subscription identifier (SUCI).
  • Access authorization based on subscription data (e.g. roaming restrictions).
  • UE’s Serving NF Registration Management…

3.1 UDM的核心职责

  1. 鉴权凭证生成 (Authentication Credential Generation): UDM是安全体系的根源。它存储着每个用户的永久密钥（K），并负责生成用于AKA鉴权的鉴权向量（AV）。

  2. 身份管理 (User Identification Handling): UDM是SUPI（永久身份）和SUCI（加密身份）之间转换的唯一场所。它存储了SUPI与SUCI解密密钥的对应关系，负责对AMF上报的SUCI进行“解密”，还原出用户的真实身份SUPI。

  3. 签约数据管理 (Subscription Management): 这是UDM最庞大的功能。它存储了用户的所有签约数据，并以服务化的形式（如Nudm_SDM服务）提供给其他NF查询和订阅。这些数据包括：

    • 接入与移动性数据 (AM Data): 漫游权限、接入限制等，供AMF使用。

    • 会话管理数据 (SM Data): 签约的S-NSSAI列表、DNN列表、默认QoS、Session-AMBR等，供SMF使用。

    • 策略数据 (UE Policy Data): URSP规则等，供PCF使用。

  4. 服务NF注册管理 (Serving NF Registration): UDM记录了当前为某个UE服务的核心NF实例的地址，主要是AMF和SMF的地址。这使得核心网能够在需要时（如MT来电）找到正确的服务节点。

3.2 场景代入：小晴的“云游戏加速”业务开通

  1. 业务办理： 小晴通过运营商的APP，购买了“云游戏加速”包月服务。

  2. 后台操作（BSS/OSS → UDM）： 运营商的业务支撑系统，通过网管接口，在UDM中更新了小晴的签约档案：

    • 在Subscribed S-NSSAIs列表中，增加了一个新的S-NSSAI：{SST=1, SD=GAME}。

    • 为这个新的S-NSSAI关联了一个专用的DNN："cloud-gaming.operator.com"。

    • 更新了她的URSP规则，增加一条：“如果应用是‘星际战甲’ → 路由到{S-NSSAI={SST=1, SD=GAME}, DNN=“cloud-gaming.operator.com”}”。

  3. UDM通知AMF/PCF： 由于AMF和PCF都订阅了小晴签约数据的变更，UDM立即向当前为小晴服务的AMF和PCF推送了更新通知。

  4. PCF更新UE策略： PCF收到通知后，生成了新的URSP规则，并通过AMF，使用“UE Configuration Update”流程，将新的规则推送给了小晴的手机。

  5. 业务生效： 小晴下次打开“星际战甲”游戏时，她的手机会根据新的URSP规则，自动请求建立一个使用{SST=1, SD=GAME}切片和cloud-gaming.operator.com DNN的PDU会话，从而享受到由SMF和UPF提供的低时延、高优先级的游戏加速服务。

5. FAQ

Q1: NEF和AF（应用功能）是什么关系？AF是核心网的一部分吗？

A:

AF不是5G核心网的一部分，它是位于核心网外部的、属于第三方或运营商自己的应用服务器。NEF是连接AF和5GC的桥梁。

  • AF (Application Function): 任何需要与5G网络能力进行交互的应用后端，都可以被称为AF。例如，“SwiftLogistics”的物流调度服务器、“City Brain”的AI平台、云游戏的服务端。

  • NEF (Network Exposure Function): 它是5GC的一个标准网络功能，其职责就是为这些外部的AF提供一个标准、安全、可控的API网关。

AF通过公共互联网或专用网络连接到NEF，而NEF再通过5GC内部的服务化接口与其他NF（AMF, SMF, PCF等）通信。

Q2: NRF在服务化架构中如此重要，如果NRF故障了会怎么样？

A:

NRF的故障会对网络的动态性和灵活性造成严重影响，因此NRF自身必须被设计为高可用的。

  • 影响： 如果NRF故障，新的NF实例将无法注册，NF消费者也无法发现新的服务实例。这会导致网络无法进行扩容、升级或故障切换。对于正在运行的服务，如果NF消费者本地缓存了生产者的地址，那么通信可以暂时维持；但如果缓存过期或需要寻找新的实例，服务就会中断。

  • 高可用性方案：

    • 集群化部署： NRF通常会以一个高可用的集群形式部署，包含多个实例，互为备份。

    • 分级部署： 在大规模网络中，可以部署分级的NRF（如Slice-specific NRF, PLMN-level NRF），分散风险。

    • 本地缓存： NF消费者在从NRF发现服务后，会在本地缓存一段时间。这可以在NRF短暂故障时，维持现有服务的运行。

Q3: UDM和4G的HSS有什么区别？为什么还需要一个UDR？

A:

UDM可以看作是HSS在5G服务化架构下的演进，主要区别在于架构和接口。

  • 功能分离： UDM主要负责数据管理的逻辑，而将实际的数据存储功能进一步解耦到了UDR（Unified Data Repository）。UDM本身可以是一个无状态的功能，它从UDR中读取数据，并执行用户管理、鉴权生成等逻辑。

  • 服务化接口： UDM通过SBI（如Nudm_SDM, Nudm_UECM, Nudm_UEAU）对外提供服务，而HSS主要使用Diameter协议。

  • UDR (Unified Data Repository): 它是真正的“数据库”层面。它提供了一个统一的数据存储服务（Nudr_DM），不仅UDM可以从中读写签约数据，PCF也可以从中读写策略数据，NEF也可以从中读写应用数据。这种“存算分离”的架构，使得5G的用户数据管理更加灵活、可扩展和可靠。

Q4: 当我从A市移动到B市，我的签约数据会从A市的UDM复制到B市的UDM吗？

A:

不会。UDM是一个中心化的逻辑功能，它存储的是用户的永久签约数据。无论您漫游到世界何处，为您的签约数据负责的，始终是您归属运营商（HPLMN）的UDM。

当您漫游到B市（VPLMN）时：

  1. B市的AMF会通过漫游接口，联系您HPLMN的NRF，找到您归属的UDM。

  2. B市的AMF会向您归属的UDM发起请求，获取您的漫游权限等签约信息。

  3. 同样，B市的V-SMF也会向您归属的H-UDM请求会话相关的签约数据。

用户的签约数据始终集中存储在HPLMN的UDM/UDR中，实现了“数据不动，服务随行”。

Q5: NEF, NRF, UDM这三者之间是如何交互的？

A:

它们之间存在着紧密的协同关系。

  • NEF → UDM: 当NEF需要将外部的AF请求与具体用户关联时，它需要向UDM查询，将AF提供的外部标识符（如GPSI）解析为内部的SUPI。

  • NRF → UDR: 在某些高级发现场景下，例如，当一个NF需要寻找一个服务于特定用户群组（由Group ID标识）的UDM时，NRF可能需要向UDR查询，以解析这个Group ID，找到对应的UDM实例。

  • 其他NF → NRF → [NEF, UDM]: 当一个AMF或SMF需要寻找NEF或UDM时，它们都会向NRF发起发现请求。NRF会告诉它们去哪里找到对应的NEF或UDM实例。

这个“铁三角”共同构成了5GC的“大脑中枢”和“对外窗口”，是整个服务化架构得以运转的根基。

关系图谱