3GPP Release 19 核心网架构深度演进：SBA、SCP与网络数据层全解析

一、从Rel-18到Rel-19：5GC核心网的又一次质变

3GPP Release 19作为5G-Advanced的第二个版本，已于2025年底完成版本冻结。如果说Rel-18是5G-Advanced的奠基之作，那么Rel-19则是在此基础上的全面深化——尤其在核心网架构层面，SBA（Service-Based Architecture）体系从"能用"走向"好用"，从"静态配置"走向"智能驱动"。

本文基于TS 23.501 V19.x、TS 23.502 V19.x、TS 29.500系列等核心规范，系统解读Rel-19在5GC架构上的关键演进，覆盖SBA通信模型增强、SCP代理模式演进、网络数据层（NDL）体系、以及AMF/SMF/UPF等核心NF的能力扩展。

二、SBA架构：从直连通信到全代理化

2.1 通信模式的演进脉络

5G核心网自Rel-15引入SBA架构以来，NF之间的通信模式经历了三个阶段的演进：

在TS 23.501 Section 4.2.2中明确定义了5G系统架构包含的网络实体，SCP和SEPP作为两大网络实体（非NF）被列为核心架构组件：

"The 5G System architecture also comprises the following network entities: Service Communication Proxy (SCP); Security Edge Protection Proxy (SEPP)." — TS 23.501 Section 4.2.2

2.2 SCP四大通信模型解析

SCP的引入彻底改变了5GC控制面的信令拓扑。根据TS 29.500 Section 6.10的定义，SCP支持以下通信模型：

图表 1

Model C和Model D是Rel-19重点增强的模式。在Model C中，SCP代理了NRF发现过程（Delegated Discovery），NF Consumer无需感知实际的服务提供者。TS 29.500 Section 6.10.3详细规定了Delegated Discovery的流程：

1. NF Consumer向SCP发送请求，携带3gpp-Sbi-Target-apiRoot头部
2. SCP从请求中提取目标API信息，向NRF发起发现请求
3. NRF返回匹配的NF Profile列表
4. SCP根据负载均衡、位置亲和性等策略选择目标NF
5. SCP将请求路由至选定的NF Producer

TS 29.500 Section 6.10.2.5定义了关键的3gpp-Sbi-Target-apiRoot头部：

"This header shall be included by the NF Service Consumer when sending a request using indirect communication with delegated discovery." — TS 29.500 Section 6.10.2.5

2.3 SCP Domain与路由绑定

Rel-19在TS 23.501 Section 6.3中增强了SCP Domain的概念：

"SCP Domain: A configured group of one or more SCP(s) and zero or more NF instances(s). An SCP within the group can communicate with any NF instance or SCP within the same group directly, i.e. without passing through an intermediate SCP." — TS 23.501 Section 3.1

Routing Binding Indication（路由绑定指示） 是SCP高效路由的关键机制。当NF Producer在响应中包含Binding Indication时，SCP据此在后续请求中直接路由至同一Producer实例，避免重复发现。TS 23.501 Section 6.3.1.0定义了Binding的三种作用域：

• NF Instance级别：绑定到特定NF实例
• NF Set级别：绑定到一组可互换的NF实例
• NF Service Set级别：绑定到特定NF服务实例组

图表 2

三、网络数据层（NDL）：5GC的智能大脑

3.1 从NWDAF到完整数据层体系

Rel-18引入了完整的数据分析架构，Rel-19进一步深化。根据TS 23.501 Section 4.2.2的定义，5GC的数据分析相关功能包含四个核心组件：

TS 23.501 Section 4.2.2的NOTE中明确指出：

"The functionalities provided by DCCF and/or ADRF can also be hosted by an NWDAF." — TS 23.501 Section 4.2.2 NOTE

这意味着运营商可以根据部署规模灵活选择——小型网络可以将所有数据分析功能集中在NWDAF实例中，大型网络则可以独立部署各功能。

3.2 NDL架构全景

图表 3

3.3 UPF信息暴露：用户面数据直达分析层

Rel-18/19的一个重要架构增强是UPF通过SBI接口（Nupf）直接向NWDAF/DCCF/MFAF暴露用户面事件。TS 23.501 Section 4.2.16定义了这一架构：

"The 5G System architecture allows user plane information exposure to some NFs via service-based interface in UPF... only NWDAF/DCCF/MFAF, NEF/AF and TSNAF/TSCTSF are considered as the receiver of the UPF event notifications." — TS 23.501 Section 4.2.16

这一设计的工程意义在于：

1. 降低SMF负担：此前UPF的事件通知必须经由PFCP（N4接口）先报给SMF，再由SMF转发。现在UPF可以直接向NWDAF报告，SMF不再作为数据中继
2. 实时性提升：端到端延迟减少一跳，对于时延敏感的分析场景（如异常流量检测）至关重要
3. 数据量不受限：UPF直接暴露的数据类型更加丰富，包括QoS监测信息、流量统计等

但需要注意，UPF的SBI暴露并非替代PFCP报告——TS 23.501明确指出"UPF information exposure is not restricted to SBI interface, i.e. reporting via PFCP over N4 to SMF is still applicable"。

3.4 NWDAF分析能力演进

从Rel-15到Rel-19，NWDAF支持的分析类型持续扩展：

TS 23.501 Section 5.3.5定义了AMF向NWDAF订阅分析信息的触发条件：

"Triggers for the AMF to request for or subscribe to the analytics information from the NWDAF are internal logic in the AMF and may include for example: analytics information received. When a trigger condition happens, the AMF may decide if any analytics information is needed and if so, request for or subscription to the analytics information from the NWDAF." — TS 23.501 Section 5.3.5

四、AMF/SMF/UPF核心NF能力增强

4.1 AMF增强

Rel-19中AMF的关键增强集中在以下几个方面：

（1）NTN移动性管理增强

针对非地面网络（Non-Terrestrial Network）中卫星高速移动带来的TA管理问题，AMF需要处理动态TAI列表更新和频繁的Registration Area重分配。这与TS 23.501 Section 5.3.2中定义的移动性管理框架一脉相承。

（2）NWDAF驱动的智能寻呼

TS 23.501 Section 5.3.4.3定义了AMF的寻呼策略，Rel-19增强了NWDAF分析辅助寻呼：

"If NWDAF is deployed, the AMF may also use analytics (i.e. statistics or predictions) on the UE's mobility as provided by NWDAF." — TS 23.501 Section 5.3.4.3

这意味着AMF在发起寻呼时，可以参考NWDAF提供的UE移动性预测，缩小寻呼范围、降低空口信令开销。

（3）RedCap/Ambient IoT设备优化

针对RedCap（Reduced Capability）和Ambient IoT设备，AMF需要支持轻量级注册流程和简化的移动性管理，降低这类设备的信令开销和功耗。

4.2 SMF增强

（1）灵活的UPF选择与重选

TS 23.501 Section 6.3.3定义了UPF选择机制。Rel-19增强了SMF的UPF选择能力，支持基于DNAI（DN Access Identifier）的更精细化选择策略，特别是边缘计算场景下的本地UPF插入/移除。

（2）LADN与NWDAF联动

"SMF may make use of UE mobility analytics provided by NWDAF... to determine UE presence pattern in LADN service area and take a decision how to handle LADN PDU Session." — TS 23.501 Section 5.6.10

SMF可利用NWDAF提供的UE移动性分析，预判UE是否即将离开LADN服务区，从而主动释放PDU Session而非等待超时。

（3）ATSSS增强

TS 23.501 Section 4.2.10定义的ATSSS（Access Traffic Steering, Switching & Splitting）架构在Rel-19中进一步增强：

• MPQUIC Proxy功能：UPF支持QUIC多路径代理（RFC 9000 + draft-ietf-quic-multipath）
• ATSSS-LL功能：支持Ethernet类型MA PDU Session的底层流量分流
• PMF性能测量：UE可通过用户面获取接入性能数据

4.3 UPF增强

（1）SBI接口暴露（Nupf）

前文已述，UPF新增Nupf SBI接口直接向NWDAF等NF暴露事件。

（2）Paging Policy Differentiation

TS 23.501 Section 5.3.4.3定义了UPF参与寻呼策略分化的机制：

"The UPF shall include the DSCP in TOS (IPv4) / TC (IPv6) value from the IP header of the downlink packet and an indication of the corresponding QoS Flow in the Downlink Data Report sent to the SMF. When PPD applies, the SMF determines the Paging Policy Indicator (PPI) based on the DSCP received from the UPF."

UPF通过DSCP标记下行数据包的优先级，SMF据此生成PPI，最终影响NG-RAN的寻呼策略——例如IMS语音数据包触发高优先级寻呼。

（3）Rel-19确定性网络支持

UPF增强了对Time Sensitive Networking（TSN）和确定性通信的支持，通过TSCTSF（Time Sensitive Communication and Time Synchronization Function）协同，实现工业IoT场景下的精确时间同步和流量调度。

五、Rel-19新增网络功能与架构变更一览

六、实战部署建议

6.1 SCP部署策略

根据TS 23.501 Annex G的SCP部署示例，推荐以下部署模型：

方案一：Service Mesh集成部署

将SCP功能与云原生Service Mesh（如Istio）集成，利用Service Mesh的流量管理、安全、可观测能力，SCP作为mesh内的sidecar或gateway运行。优势是与云原生生态天然融合，劣势是对传统NF的改造要求较高。

方案二：独立代理部署

SCP作为独立网元部署，NF通过配置指向SCP的FQDN。优势是部署灵活、可渐进式引入，劣势是需要维护独立的SCP集群。

方案三：基于DNS路由的部署

利用DNS返回SCP地址（Model D模式），NF无需显式感知SCP的存在。优势是对NF零侵入，劣势是DNS层面的可观测性较弱。

6.2 NWDAF/NDL部署路径

6.3 迁移注意事项

1. SCP引入的灰度策略：建议先在非关键业务切片中部署SCP Model B（无Delegated Discovery），验证信令路由正确性后再切换到Model C
2. NWDAF的数据量评估：NWDAF订阅的数据量可能显著增加5GC内部SBI流量，建议在网络规划阶段评估SBI带宽需求
3. UPF SBI暴露的安全边界：UPF通过Nupf直接暴露数据给NWDAF，需要确保安全策略覆盖这一新接口
4. 与Rel-18的兼容性：Rel-19规范在设计上保持了与Rel-18 NF的互操作性，SCP的Model A（Direct Communication）始终可用

七、关键规范版本与章节速查

常见问题

Q: SCP的Model C（Delegated Discovery）和Model D有什么本质区别？

A: Model C中NF知道SCP的存在，主动向SCP发送请求，由SCP代为进行NRF Discovery。Model D中NF甚至不知道SCP的存在——NF通过DNS解析目标NF的FQDN，但DNS返回的是SCP的地址，SCP透明代理所有请求。Model D的侵入性最低，但对DNS基础设施有额外要求。实际上两者的代理逻辑相同，区别仅在NF是否感知SCP。

Q: DCCF/NWDAF/ADRF必须独立部署吗？

A: 不必须。TS 23.501 Section 4.2.2的NOTE明确指出"The functionalities provided by DCCF and/or ADRF can also be hosted by an NWDAF"。小型运营商可以将DCCF和ADRF合设于NWDAF内部；大型网络建议独立部署，便于水平扩展和故障隔离。关键判断依据是网络中NF实例数量和数据采集规模。

Q: UPF的Nupf SBI接口是否会替代N4/PFCP接口？

A: 不会。TS 23.501 Section 4.2.16明确指出"UPF information exposure is not restricted to SBI interface, i.e. reporting via PFCP over N4 to SMF is still applicable"。Nupf SBI是N4/PFCP的补充而非替代。PFCP仍然承担用户面会话管理（PDU Session建立、QoS enforcement等），Nupf SBI仅用于事件通知（QoS监测数据、流量统计等）。

Q: Rel-19核心网升级对终端有什么影响？

A: 大部分5GC架构增强对终端透明（如SCP部署、NWDAF增强）。但以下特性需要终端配合：ATSSS增强需要终端支持MPQUIC功能；Ambient IoT设备需要新的NAS简化流程；RedCap优化需要终端声明其能力。对于普通5G智能手机用户，核心网升级完全无感。

Q: 在现网中引入SCP会不会成为单点故障？

A: 不会，前提是正确部署。SCP支持多实例部署和SCP Domain概念。在一个SCP Domain内，多个SCP实例可以组成集群，通过负载均衡实现高可用。同时，SCP的引入是可选的——即使SCP全部故障，NF可以回退到Direct Communication模式（前提是配置了fallback策略）。建议在部署时同时配置Direct和Indirect两种通信模式。

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