51学通信

深度解析 3GPP TS 23.501：7 & 8 服务化接口与协议栈 (SBA的语言与语法)

22分钟阅读

本文技术原理深度参考了3GPP TS 23.501 V18.9.0 (2025-03) Release 18规范中，关于“7 Network Function Services and descriptions”和“8 Control and User Plane Protocol Stacks”的核心章节，旨在为读者提供一个5G服务化架构（SBA）的“语言”与“语法”的全景视图，揭示网络功能之间如何进行交互，以及这些交互是如何通过底层的协议栈来承载和实现的。本文是解读“6 Network Functions”系列的第六部分。

深度解析 3GPP TS 23.501：7 & 8 服务化接口与协议栈 (SBA的语言与语法)

欢迎来到“解构5G核心网”的NF深度解析系列。在前面的文章中，我们已经详细介绍了5G核心网的各位“演员”——AMF、SMF、PCF、UPF、UDM等。我们知道，5G是一个服务化架构（SBA），这些网络功能（NF）不再是孤立的“盒子”，而是像一个个提供专业能力的微服务，通过API相互调用，协同完成复杂的通信任务。

那么，这些“微服务”之间沟通的“语言”是什么？它们对话的“语法规则”又是怎样的？这些对话又是通过怎样的“通信线路”来传递的？

今天，我们将深入探讨规范中两个在架构层面至关重要的章节：第7章“网络功能服务与描述”和第8章“控制面与用户面协议栈”。这两章共同定义了5GC通信的“软件”与“硬件”基础：

  • 第7章 定义了**“说什么”和“怎么说”，即SBA的语言**。它详细描述了每个NF能提供哪些服务（Service），以及调用这些服务的方式（Request-Response, Subscribe-Notify）。

  • 第8章 定义了**“通过什么说”，即SBA的语法和物理载体**。它详细描绘了承载这些服务化交互的底层控制面和用户面协议栈。

为了将这两个高度抽象的章节具象化，让我们引入今天的场景。一家名为**“ConnectX”的创新公司，正在为“未来城市”国际马拉松比赛**开发一款官方APP。这款APP的核心开发者，Ava，需要利用5G网络的能力，为用户提供两种高级功能：

  1. 实时选手追踪： 用户可以在地图上实时查询任何一名选手当前的位置。

  2. “加油区”智能提醒： 当用户订阅的选手进入赛道旁的特定“加油区”（一个地理围栏）时，APP会自动推送一条通知。

Ava在设计应用后端（AF）时，她必须深入理解5GC提供的服务“API文档”（第7章），并清楚这些API调用是如何在复杂的网络协议（第8章）中被可靠传递的。我们将跟随Ava的开发思路，来解构5G服务化架构的“语言”与“语法”。

1. 5G的“API文档”：网络功能服务框架 (7.1 Network Function Service Framework)

第7章的核心，是为5GC的所有交互，建立了一套类似现代IT领域微服务架构的“API调用框架”。

An NF service is one type of capability exposed by an NF (NF Service Producer) to other authorized NF (NF Service Consumer) through a service-based interface. A Network Function may expose one or more NF services.

这意味着，每个NF都被视为一个或多个服务的生产者（Producer），而需要使用这些功能的其他NF，则扮演了消费者（Consumer）的角色。它们之间的交互，不再是私有的、点对点的协议，而是标准化的、可重用的服务化接口（Service-Based Interface, SBI）。

1.1 两种基本的“对话模式” (7.1.2 NF Service Consumer - NF Service Producer interactions)

规范定义了两种基本的NF服务交互机制，这构成了SBA中所有复杂流程的基础。

1.1.1 “一问一答”模式：请求-响应 (Request-Response)

这是最简单、最直接的交互模式，用于一次性的信息查询或操作请求。

“Request-response”: A Control Plane NF_B (NF Service Producer) is requested by another Control Plane NF_A (NF Service Consumer) to provide a certain NF service, which either performs an action or provides information or both. NF_B provides an NF service based on the request by NF_A.

核心逻辑： 消费者发起一个请求，生产者处理后返回一个响应。

场景代入： Ava需要实现“实时选手追踪”功能。

  1. 用户操作： 用户在ConnectX APP中点击查询“选手A”的位置。

  2. AF（消费者）发起请求： ConnectX的后台应用（AF）向PCF（或通过NEF）发起一个Request，请求获取“选手A”的实时位置。

  3. PCF/AMF（生产者）处理并响应： PCF将请求转化为对AMF的位置查询。AMF作为位置服务的最终提供者，查询UE的上下文，获取其当前的Cell ID，然后将位置信息封装在Response中，逐级返回给AF。

  4. APP显示结果： APP在地图上更新了“选手A”的位置图标。

这是一个典型的“一问一答”过程，AF请求，AMF响应。

Figure 7.1.2-1: "Request-response" NF Service illustration

(规范原文中的“Figure 7.1.2-1: “Request-response” NF Service illustration”清晰地展示了这种交互模型)

1.1.2 “订阅-通知”模式：Subscribe-Notify

这是SBA最具威力的机制之一，它将一次性的查询，变为了持续的状态监控和事件驱动。

“Subscribe-Notify”: A Control Plane NF_A (NF Service Consumer) subscribes to NF Service offered by another Control Plane NF_B (NF Service Producer)… NF_B notifies the results of this NF service to the interested NF(s) that subscribed to this NF service.

核心逻辑： 消费者向生产者订阅一个特定的事件。当这个事件在生产者侧发生时，生产者会主动向所有订阅了该事件的消费者发送通知。

场景代入： Ava需要实现“加油区”智能提醒功能。

  1. 用户操作： 用户在ConnectX APP中点击“订阅选手A进入加油区的提醒”。

  2. AF（消费者）发起订阅： ConnectX的后台应用（AF）向PCF（或通过NEF）发起一个Subscribe请求。请求内容是：“请订阅‘选手A’的位置变更事件，监控区域为‘加油区’（由一组TAI或Cell ID定义），当该UE进入此区域时，请通过我提供的回调地址（Notification Endpoint）通知我”。

  3. PCF/AMF（生产者）建立订阅： PCF将此请求转化为对AMF的Namf_EventExposure_Subscribe服务调用。AMF在“选手A”的UE上下文中，记录下这个订阅关系。

  4. 事件发生与通知： “选手A”跑入了“加油区”，手机发生了一次TAU（跟踪区更新）。

  5. AMF在处理TAU时，检查UE上下文，发现这个位置变更事件命中了AF的订阅。AMF立即主动向AF注册的回调地址，发送一个Notify消息：“‘选手A’已进入加油区”。

  6. APP推送提醒： ConnectX的后台收到通知，立即向用户的手机APP推送了一条消息：“您关注的选手A已进入加油区，快为他加油吧！”

Figure 7.1.2-2: "Subscribe-Notify" NF Service illustration 1

(规范原文中的“Figure 7.1.2-2: “Subscribe-Notify” NF Service illustration 1”展示了这种强大的事件驱动模型)

1.2 5GC的“API服务目录” (7.2 Network Function Services)

第7.2节是规范的核心，它就像一本详细的“API文档”，列出了每个核心NF对外提供的所有标准化服务。

AMF服务 (Namf_Service)

| Service Name | Description |

| :--- | :--- |

| Namf_Communication | 允许其他NF（主要是SMF）通过AMF与UE或RAN进行通信，例如下发NAS消息或N2消息。 |

| Namf_EventExposure | 允许其他NF订阅UE的移动性事件，如位置变更、可达性状态（IDLE/CONNECTED）变化等。 |

| Namf_MT | 提供UE可达性服务，例如，在寻呼UE时，由AMF负责执行寻呼流程。 |

| Namf_Location | 提供UE位置查询服务，响应来自GMLC等NF的位置请求。 |

SMF服务 (Nsmf_Service)

| Service Name | Description |

| :--- | :--- |

| Nsmf_PDUSession | 提供PDU会话的全生命周期管理，包括创建、修改、释放。这是SMF最核心的服务。 |

| Nsmf_EventExposure | 允许其他NF订阅PDU会话相关的事件，例如，PDU会话的建立/释放、IP地址变更等。 |

通过这个“服务目录”，Ava可以清晰地知道，要实现“位置查询”功能，她最终需要调用AMF的Namf_Location服务；要实现“地理围栏提醒”，她需要调用AMF的Namf_EventExposure服务。

2. 5G的“语法与物理层”：协议栈 (8 Control and User Plane Protocol Stacks)

如果说第7章定义了“说什么”，那么第8章就定义了这些“话”是如何被组织和传递的。它详细描述了5G控制面和用户面的协议栈。

2.1 控制面协议栈 (8.2 Control Plane Protocol Stacks)

控制面信令的传递路径是多样的，每一段路径都有其专属的协议栈。

2.1.1 SBI接口协议栈：NF之间的“通用语言”

The control plane protocol(s) for the service-based interfaces listed in clause 4.2.6 is defined in the TS 29.500.

所有NF之间（以及AF与NEF之间）的SBI，都采用了统一的、基于现代Web技术的协议栈：

  • 应用层： RESTful API (基于HTTP/2)

  • 传输层： TCP

  • 网络层： IP

这使得5GC的控制面在本质上变成了一个巨大的、分布式的Web服务系统。Ava的AF向NEF发起的API调用，就是一个标准的HTTPS请求，这极大地降低了第三方应用与5G网络集成的门槛。

2.1.2 N1/N2接口协议栈：UE/RAN与AMF的“专属通道”

UE ←> AMF (N1):

  • NAS (Non-Access Stratum): 这是UE与AMF之间沟通的核心信令协议，负责注册、鉴权、安全等。

  • 承载： NAS消息被“捎带”在RAN的RRC信令和核心网的N2信令中。

RAN ←> AMF (N2):

  • NGAP (NG Application Protocol): RAN与AMF之间专用的应用层协议。

  • SCTP (Stream Control Transmission Protocol): 一种比TCP更适合信令传输的、可靠的传输层协议。

  • IP: 网络层。

场景代入：

Ava的“加油区提醒”订阅请求，在网络中的传递路径和协议栈如下：

  1. AF → NEF → PCF → AMF: 这一段路程，全程使用SBI协议栈（HTTP/2 over TCP/IP）。

  2. AMF → UE (如果需要更新策略): 如果AMF需要向UE下发更新的移动性策略，它会将NAS消息通过**N2接口（NGAP over SCTP/IP）发送给RAN，RAN再通过空口协议栈（RRC/PDCP/RLC/MAC）**将NAS消息传递给UE。

2.2 用户面协议栈 (8.3 User Plane Protocol Stacks)

用户面的目标只有一个：高效、可靠地传输数据包。其协议栈也为此做了最大程度的简化。

GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol supports tunnelling user data over N3 (i.e. between the 5G-AN node and the UPF) and N9 (i.e. between different UPFs of the 5GC) in the backbone network… GTP shall encapsulate all end user PDUs.

Figure 8.3.1-1: User Plane Protocol Stack

(规范原文中的“Figure 8.3.1-1: User Plane Protocol Stack”清晰地展示了用户面“隧道”的概念)

核心：GTP-U隧道

  • PDU Layer: 这是最顶层的、用户的原始IP包或以太网帧。

  • GTP-U (GPRS Tunnelling Protocol - User Plane): 核心的隧道协议。UPF和RAN会将用户的PDU封装在一个GTP-U包头之后。这个包头中包含了关键的QFI（QoS Flow Identifier），用于在隧道内部区分不同的QoS流，以及隧道端点标识（TEID），用于标识这条隧道。

  • UDP/IP: GTP-U通常封装在UDP包中，以便于在IP骨干网上进行路由。

  • 底层： 物理的传输网络，如光纤。

场景代入：

安保无人机回传的4K视频流，其数据包在5G网络中的旅程如下：

  1. 无人机 → gNB: 视频IP包通过空口协议栈发送给基站。

  2. gNB → UPF (N3接口): gNB将收到的IP包，封装上一个GTP-U头（其中QFI被标记为安保视频流对应的QFI），再封装上UDP/IP头，通过N3隧道发送给UPF。

  3. UPF → DN (N6接口): UPF解开GTP-U隧道，取出原始的IP包，然后根据路由表，从N6接口将其转发给安保中心的数据网络。

5. FAQ

Q1: 为什么5G核心网的SBI要选择HTTP/2协议，而不是其他专门的电信协议？

A:

这是一个革命性的改变，其核心目的是拥抱IT化和云原生，带来了巨大好处：

  1. 技术生态成熟： HTTP/2是整个互联网行业最成熟、应用最广泛的应用层协议之一。这意味着5G核心网的开发可以直接利用海量的、成熟的开源工具、框架和开发人才，大大降低了开发和运维成本。

  2. 高性能： HTTP/2支持多路复用、头部压缩、服务器推送等高级特性，非常适合SBA中大量并发、低延迟的API调用场景。

  3. 易于集成： 使用标准的HTTP/2和RESTful API，使得第三方应用（AF）与NEF的集成变得异常简单，就像调用任何一个互联网公司的Web API一样，极大地促进了5G的生态建设。

  4. 易于观测和管理： 标准的HTTP协议栈使得网络的监控、日志、追踪等运维工具可以直接复用IT领域的成熟方案。

Q2: 请求-响应和订阅-通知，这两种模式可以结合使用吗？

A:

是的，它们经常被结合使用，以实现更复杂的业务逻辑。

一个典型的例子是PCF对SMF的策略控制：

  1. 订阅-通知 (Subscribe-Notify): 在PDU会话建立时，PCF会向SMF订阅一系列事件，例如，“当UE的位置发生改变时，请通知我”。

  2. 请求-响应 (Request-Response): 当SMF收到来自AMF的UE位置变更通知后，它会触发对PCF的通知。PCF收到通知后，可能会根据新的位置信息，重新进行策略决策，然后通过一次请求-响应式的交互（Npcf_SMPolicyControl_Update），向SMF下发更新后的PCC规则。

通过这两种模式的结合，PCF实现了对PDU会话的动态、闭环控制。

Q3: 在用户面协议栈中，为什么要在IP包外面再套一层GTP-U，再套一层UDP/IP？这不是很冗余吗？

A:

这层封装是实现用户面隧道化和QoS管理的核心，看似冗余，实则至关重要。

  1. 解耦： GTP-U隧道将用户的IP网络（UE的IP地址和DN的IP地址）与运营商的承载网络（gNB和UPF的IP地址）完全解耦。承载网只需要根据GTP-U隧道的IP地址进行路由，完全不关心隧道内部传输的是什么数据。这使得UE的IP地址可以在移动时保持不变。

  2. QoS标识： GTP-U头中携带的QFI，是用户面QoS的唯一标识。RAN和UPF都是通过识别GTP-U头中的QFI，来知道这个数据包应该享受什么样的QoS待遇（如调度优先级、速率保障等），而不是去解析用户IP包头中的DSCP等信息。

  3. 多会话复用： 多个来自不同UE的PDU会话，可以复用同一个N3接口（即gNB和UPF之间的物理连接），通过不同的GTP-U隧道（由TEID区分）进行隔离。

Q4: 所有的NF服务调用都必须经过NRF的发现吗？

A:

不。除了本地配置外，一个非常重要的优化机制是Binding Indication（绑定指示）。

当一个NF消费者（如AMF）首次通过NRF发现并选择了一个生产者（如SMF）后，这个SMF可以在响应中返回一个“绑定指示”。这个指示告诉AMF：“对于这个PDU会话后续的所有请求，请直接来找我，不要再去NRF问了”。AMF会缓存这个绑定关系。这样，后续的交互就可以跳过NRF的发现步骤，直接点对点进行，大大提高了效率。只有当这个绑定的SMF出现故障时，AMF才会重新去NRF进行发现。

Q5: 5G的服务化接口（SBI）和我们常说的API有什么区别？

A:

在5G的语境下，可以认为它们是高度相关的概念。

  • API (Application Programming Interface): 是一个更通用的软件工程概念，指一组定义了软件组件之间如何交互的规则和协议。

  • SBI (Service-Based Interface): 是3GPP为5GC定义的、符合SBA原则的API的具体实现。它规定了这些API必须是：

    • 基于服务的： 以N<NF>_<Service>的形式命名，暴露的是网络能力，而非内部实现。

    • 协议统一： 基于HTTP/2和RESTful风格。

    • 可发现、可注册： 通过NRF进行管理。

可以通俗地理解为，SBI就是5GC这套庞大分布式系统的“官方API规范集”。Ava作为应用开发者，她学习和调用的，正是由NEF对外暴露的、经过安全封装的SBI。

关系图谱