3GPP Release 19作为5G-Advanced的第二个版本，于2025年底完成Stage 3冻结，标志着5G核心网从"功能可用"走向"智能自治"。如果说Release 18是SBA架构的成年礼——引入了增强的Service Communication Proxy（SCP）通信模型、NWDAF基础分析能力、以及初步的网络自动化框架，那么Release 19则是一次系统性的质变：AI/ML从辅助工具升级为核心架构的一等公民，Service Proxy从消息路由器演变为智能服务网格，而整个数据架构层被重新定义以支撑闭环自动化。
本文聚焦TS 23.501 V19.x、TS 23.502 V19.x、TS 29.500系列规范中的核心变化，深入解读SBA架构在Release 19中的关键演进，涵盖SCP通信模型增强、NWDAF AI/ML服务扩展、AMF/SMF/UPF新功能，以及Network Data Layer（NDL）的概念框架。
Release 19的5GC SBA架构在TS 23.501 Section 6中定义，保持了Release 15以来确立的服务化架构范式——所有网络功能（NF）通过RESTful API（SBI接口）交互，使用HTTP/2作为传输协议，JSON作为数据序列化格式。但在R19中，架构的内生智能能力被显著增强。
图表 1
| 维度 | Release 18 | Release 19 |
|---|---|---|
| SCP通信模型 | Model A/B/C/D（TS 23.501 Section 6.2.6） | 新增Model E/F增强模式，支持委托发现+链式转发 |
| NWDAF架构 | 包含AnLF和MTLF逻辑功能（TS 23.288） | 引入DCCF（数据收集协调）和AdRF（AI模型仓库），形成完整AI数据管线 |
| NF间通信 | HTTP/2 + JSON | 保持HTTP/2，新增Structured Event Notification机制（TS 29.500） |
| 数据架构 | 各NF独立维护数据存储 | 引入NDL概念框架，统一数据采集、存储、分析和暴露 |
| AI/ML集成 | 有限的分析服务（负载、移动性） | AI/ML作为架构内生能力，支持闭环自动化 |
| 服务发现 | NRF直接查询或SCP代理查询 | 增强NRF，支持基于AI预测的NF实例优先排序 |
SCP在5GC SBA中的定位由TS 23.501 Section 6.2.6和TS 29.500 Section 6定义。Release 18已定义了Model A到D四种通信模型，Release 19在此基础上进行了关键增强。
Release 18定义的四种模型：
Release 19新增增强：
TS 23.501 V19.x Section 6.2.6.2引入了通信模型的细化增强，主要体现在：
Delegated Discovery with Context Awareness（上下文感知委托发现）：SCP在执行NF发现时，能够结合NWDAF提供的分析信息（如NF实例负载预测、服务质ᄁ评分），实现智能化的NF实例选择。
Chained Indirect Communication（链式间接通信）：允许SCP将请求转发给另一个SCP域，支持跨PLMN或跨网络切片的SCP级联场景。
Service Mesh Capability（服务网格能力）：SCP增强为具备服务网格特征的中控组件，支持流量管理（流量分割、金丝雀发布）、服务韧性（熔断、重试策略）、以及可观测性（分布式追踪）。
图表 2
| 参数/IE | 规范章节 | R18定义 | R19变化 |
|---|---|---|---|
3gpp-Sbi-Discovery-* headers |
TS 29.500 Section 6.10 | 支持基本NF发现参数 | 新增3gpp-Sbi-Discovery-analytics-assistance指示，允许Consumer请求SCP结合分析数据选择 |
| SCP routing policy | TS 29.500 Section 6.10.2 | 基于配置的静态路由 | 新增动态路由策略，支持基于实时负载和AI预测的路由决策 |
NfRoutingRequirement IE |
TS 29.500 Section 6.10.3 | NF类型、切片、DNN维度 | 新增analyticsAssistanceReq布尔标志和preferredNfInstanceList |
| Error handling | TS 29.500 Section 6.11 | 基本重试逻辑 | 增强为支持熔断机制，当某个NF实例连续失败达到阈值后自动排除 |
在运营商现网部署中，SCP是5GC信令平面的关键枢纽。从R18升级到R19的SCP增强时，需注意：
渐进式部署策略：SCP的AI辅助发现功能（Model D Enhanced）是可选特性，可与原有Model D并存。建议先在非关键切片（如eMBB测试切片）启用AI辅助路由，验证NWDAF分析准确性后再推广到全网。
SCP容灾设计：R19的SCP服务网格特性增加了熔断机制，但这也引入了新的故障模式——如果NWDAF分析服务不可用，SCP需回退到R18的基本路由策略。部署时必须确保NWDAF不可用场景下的优雅降级路径。
性能影响评估：SCP在转发前额外查询NWDAF会增加信令时延（典型增加5-15ms）。对于超低延迟场景（如URLLC切片），可配置为跳过AI辅助发现，直接使用缓存的NF实例列表。
NWDAF（Network Data Analytics Function）在Release 18中已包含AnLF（Analytics Logic Function）和MTLF（ML Model Training Function）两个逻辑组件（TS 23.288）。Release 19在此基础上引入了两个关键的新组件：
DCCF（Data Collection Coordination Function）：定义在TS 23.501 V19.x Section 6.2.9A，DCCF负责统一协调网络中的数据收集过程。在R18中，每个NWDAF实例可能独立向各NF发起数据订阅，造成大量重复数据收集。DCCF的引入实现了"一次采集、多处消费"的模式——它作为数据收集的唯一入口，将采集到的数据分发给所有需要的NWDAF实例及其他消费者。
AdRF（AI/ML Data Repository Function）：定义在TS 23.501 V19.x Section 6.2.9B，AdRF作为AI/ML模型和训练数据的集中存储库。它解决了R18中ML模型在NWDAF实例间无法共享的问题——训练好的模型可以存入AdRF，由其他NWDAF实例加载使用。
图表 3
TS 23.288 V19.x在R18已定义的分析服务基础上，新增了以下关键Analytics IDs：
| Analytics ID | 描述 | 新增/增强 | 典型消费者 |
|---|---|---|---|
NF_LOAD |
NF实例负载分析 | R19增强：新增预测性负载分析，支持多步预测 | SCP、PCF |
NETWORK_PERFORMANCE |
网络性能分析 | R19增强：新增切片级粒度性能指标 | OAM、PCF |
UE_MOBILITY |
UE移动性分析 | R19增强：支持群组级移动性预测 | AMF、PCF |
QOS_SUSTAINABILITY |
QoS可持续性分析 | R19增强：新增QoS降质预测 | PCF、SMF |
REDUNDANT_TRANSMISSION_EXP |
冗余传输体验分析 | R19新增 | SMF、UPF |
SSL_OR_DISPERSION |
服务体验或业务分布 | R19新增：支持AI/ML模型驱动的分析 | PCF、AF |
PFD_SESSION_INFO |
PFD会话信息分析 | R19新增：用于智能业务分类 | SMF、UPF |
NF_RESOURCE_UTILIZATION |
NF资源利用率预测 | R19新增：面向云原生NF的弹性伸缩 | OAM |
Release 19最重要的架构理念转变是从开环辅助走向闭环自动化。在R18中，NWDAF提供分析信息，但决策和执行仍由人工或外部OSS完成。R19引入了闭环自动化的框架定义：
TS 23.501 V19.x Section 6.2.10定义了闭环自动化的三个层次：
Level 1 - Monitoring（监控）：NWDAF监测网络状态，当指标超过阈值时向消费者NF发送通知。这是R18已有的基本能力。
Level 2 - Recommendation（建议）：NWDAF不仅监测，还给出具体的操作建议。例如"建议将SMF-2上的会话迁移到SMF-3以均衡负载"。决策权仍在运营商。
Level 3 - Closed-Loop（闭环）：NWDAF直接触发NF执行操作。例如自动触发AMF执行负载重均衡，或自动调整SMF的会话分配策略。此层次需要严格的策略授权和回滚机制。
现网部署中，建议从Level 1逐步演进：先在监控场景验证NWDAF分析准确性，再开启建议模式进行人工审核，最后在可控范围内（如测试切片）验证闭环操作。
多SIM/Multi-Device管理增强（TS 23.501 Section 5.9A）：R19增强了多SIM场景下的AMF行为。当同一个SUPI关联多个UE设备时，AMF需要维护这些设备的联动状态——例如当主设备进入CM-IDLE状态时，辅助设备的寻呼策略需要相应调整。这在可穿戴设备+手机的场景中尤其重要。
NTN移动性管理增强（TS 23.501 Section 5.4.4）：针对非地面网络（Non-Terrestrial Network），AMF新增了对卫星馈电链路切换（feeder link handover）的支持。当卫星从一个地面站切换到另一个地面站时，AMF需要在无需UE参与的情况下完成服务NF的重定位。
AI辅助移动性优化：AMF可订阅NWDAF的UE移动性预测分析（UE_MOBILITY Analytics ID），提前预判UE的移动轨迹，预先完成目标gNB的资源准备和切换准备。这可显著减少切换时延，对URLLC场景意义重大。
增强型PDU会话管理（TS 23.501 Section 5.6.2）：R19在PDU会话管理中引入了以下增强：
Multi-UPF PDU Session：一个PDU会话可关联多个UPF，支持更灵活的流量分流拓扑。这在边缘计算场景中允许SMF将同一会话的流量分别导向本地UPF和集中式UPF。
ATSSS（Access Traffic Steering, Switching and Splitting）增强：R19扩展了ATSSS的功能，支持更细粒度的多路径流量控制。新增了"基于业务类型的分流策略"——不同的应用流量可以通过不同的接入路径（3GPP vs Non-3GPP）传输。
QoS监控增强：SMF可配置UPF执行端到端QoS监控，并将监控数据上报给NWDAF进行QoS可持续性分析。
SSC Mode增强：Session and Service Continuity模式在R19中新增了对SSC Mode 2b的定义——当UPF需要重定位时，SMF可以先建立新的UPF路径再释放旧路径，实现"先建后拆"的无缝切换。这在MEC（多接入边缘计算）场景中的应用迁移中特别有用。
In-Network Computing感知（TS 23.501 Section 5.8.2）：R19在UPF中引入了对计算资源的感知能力。UPF不仅做数据包转发，还能感知后端计算资源（Edge Application Server）的可用性和负载状态。当EAS过载时，UPF可将流量重定向到备选EAS。
UPF数据处理能力增强：R19新增了UPF的本地数据处理规则，允许UPF在用户平面直接执行特定的数据处理操作（如数据聚合、过滤、格式转换），而无需将原始数据发送到AF。这减少了回传带宽消耗和端到端时延。
GTP-U Path Enhancement（TS 29.281）：UPF间的GTP-U隧道在R19中增加了路径质量监控能力——通过周期性的Echo Request/Response交换，UPF可以测量路径的丢包率、时延和抖动，并上报给SMF/NWDAF。
| NF | 增强特性 | 规范章节 | R18状态 | R19变化 | 部署影响 |
|---|---|---|---|---|---|
| AMF | Multi-SIM联动管理 | TS 23.501 Section 5.9A | 基本Multi-SIM | 增强联动状态管理 | 需升级UE context数据模型 |
| AMF | NTN馈电链路切换 | TS 23.501 Section 5.4.4 | 不支持 | 新增透明切换流程 | 需配合卫星gNB升级 |
| AMF | AI辅助移动性 | TS 23.288 Section 6.5 | 不支持 | 订阅NWDAF移动性分析 | 需NWDAF部署 |
| SMF | Multi-UPF会话 | TS 23.501 Section 5.6.2 | 单UPF | 支持多UPF关联 | 信令流程变更，需兼容旧UPF |
| SMF | SSC Mode 2b | TS 23.501 Section 5.6.9 | SSC 1/2/3 | 新增先建后拆模式 | 会话连续性策略升级 |
| SMF | ATSSS增强 | TS 23.501 Section 5.32 | 基本ATSSS | 基于业务类型分流 | 需终端支持 |
| UPF | 计算感知 | TS 23.501 Section 5.8.2 | 不支持 | EAS负载感知和重定向 | 需EAS与UPF协同 |
| UPF | 本地数据处理 | TS 23.501 Section 5.8.2 | 基本UL CL | 增强处理规则 | UPF功能扩展 |
| UPF | GTP-U路径监控 | TS 29.281 Section 7.3 | 基本Echo | 增强质量度量 | 无兼容性问题 |
在Release 18及之前的架构中，5GC的数据管理呈现碎片化特征：
这种碎片化导致了数据冗余采集、数据一致性难以保证、以及跨域数据分析困难。Release 19在SA2工作组中启动了Network Data Layer的研究，旨在建立统一的数据架构框架。
NDL不是一个独立的网络功能，而是一个架构框架（Architectural Framework），定义在TS 23.501 V19.x Section 6.2.12中。其核心原则包括：
Data as a Service（DaaS）：网络数据被视为可被发现、订阅和消费的服务，任何授权的NF都可以通过标准化接口获取所需数据。
统一数据采集：通过DCCF（Data Collection Coordination Function）实现一次采集、多处消费，避免各NF独立重复采集相同的数据。
数据生命周期管理：从数据采集、处理、存储到过期清理，NDL定义了完整的数据生命周期管理策略。
数据治理：包括数据访问控制、数据脱敏、数据审计等治理能力，确保数据在采集和使用过程中符合隐私和安全要求。
图表 4
NDL框架的设计涉及多个3GPP规范的协调：
| 规范 | 关联关系 |
|---|---|
| TS 23.501 | 定义NDL架构框架和数据服务接口 |
| TS 23.288 | 定义NWDAF的数据采集和分析服务，是NDL的核心数据消费者 |
| TS 23.502 | 定义DCCF相关的新流程 |
| TS 29.5xx系列 | 定义数据服务API的Stage 3接口细节 |
| TS 28.5xx系列 | 管理数据服务（MDAF）与NDL的北向接口 |
| TS 33.501 | NDL数据访问的安全和隐私保护机制 |
Release 19在TS 29.500 Section 4.8中引入了结构化事件通知机制。在R18中，NF之间的通知是简单的HTTP回调，消费者NF无法精确控制接收哪些事件以及事件的粒度。R19允许消费者在订阅时指定结构化过滤条件：
这一增强显著减少了不必要的通知消息量，对于大规模网络中的事件处理效率至关重要。
TS 29.500 V19.x对API版本管理策略进行了优化。新增了API-versions查询参数，允许NF Consumer在发现NF Producer时获取其支持的完整API版本列表。这解决了R18中版本协商效率低下的问题——在R18中，Consumer只能通过尝试调用来探测Producer支持的版本。
R19的NRF（TS 23.501 Section 6.2.6.3）增加了与NWDAF的交互接口。当NF Consumer通过NRF发现目标NF实例时，NRF可以在返回的NF Profile中附带NWDAF提供的实时分析信息（如实例健康度评分、负载预测值）。这使得Consumer在做出NF选择决策时能够基于更丰富的信息。
TS 29.510 V19.x扩展了Nnrf_NFManagement服务的NF Profile数据结构，新增以下IE：
| 新增IE | 类型 | 描述 |
|---|---|---|
analyticsSupport |
array(AnalyticsId) | NF实例可提供的分析数据类型列表 |
computeResourceStatus |
ComputeResourceStatus | NF实例所在计算资源的实时状态（CPU/内存利用率） |
servingScopeAI |
ServingScopeAI | AI增强的服务范围信息，包含预测的服务覆盖区域 |
nfLoadPrediction |
NfLoadPrediction | NWDAF提供的未来负载预测值 |
modelRegistrationList |
array(ModelId) | AdRF中注册的ML模型ID列表（仅MTLF） |
5GC从R18升级到R19是一个渐进式过程。关键考虑点包括：
Phase 1 - 数据基础建设：优先部署DCCF和AdRF，建立统一数据采集框架。这不需要修改现有NF的R18行为，但为后续AI/ML功能奠定数据基础。
Phase 2 - 分析能力增强：升级NWDAF以支持新增的Analytics IDs，部署MTLF的增强训练能力。此阶段NWDAF可与现有NF并行运行。
Phase 3 - SCP智能路由：升级SCP以支持AI辅助发现和动态路由策略。建议在隔离的测试环境中充分验证后再切换生产流量。
Phase 4 - 闭环自动化：在验证分析准确性后，逐步开启Level 2和Level 3的闭环自动化能力。初期应限制在低风险场景（如负载均衡、会话重分配）。
R19的SBA架构保持了与R18的向后兼容性。关键兼容原则：
但需注意：Multi-UPF PDU Session、SSC Mode 2b等SMF增强特性要求UPF也升级到R19版本。如果现网UPF仍为R18版本，SMF应回退到单UPF模式。
Release 19代表了5GC SBA架构从"功能完善"到"智能原生"的关键转折点。三个核心变化构成了这一转折的基石：
Service Proxy从路由器到服务网格：SCP的AI辅助路由、熔断机制和链式通信使其成为5GC信令平面的"智能枢纽"，而不仅仅是消息转发器。
AI/ML从外挂到内生：DCCF+MTLF+AnLF+AdRF构成的AI/ML数据管线，使5GC具备了从数据采集、模型训练、推理分析到闭环执行的完整AI能力链。
数据架构的统一化：NDL概念框架解决了数据碎片化问题，为6G时代的"数据驱动网络"奠定了基础。
这些变化的共同主题是：将智能能力嵌入架构的每一层，使网络从"被动响应"走向"主动预判"。
Q: Release 19的SCP增强是否需要替换现有SCP设备？ A: 不需要。R19的SCP增强是在现有Model A-D基础上新增可选功能。现有SCP设备可通过软件升级支持R19特性，不需要硬件替换。但AI辅助路由功能需要SCP与NWDAF之间建立新的SBI连接，需确保SCP支持Nnwdaf服务接口。
Q: DCCF是否是强制部署的新网络功能？ A: 不是。DCCF是可选的网络功能。在小规模部署中，NWDAF可以直接与NF交互采集数据。DCCF主要在大规模网络中发挥价值——当存在多个NWDAF实例且需要采集相同数据时，DCCF可以显著减少重复数据采集。运营商可根据网络规模和数据分析需求决定是否部署。
Q: R19的闭环自动化是否意味着网络完全自治？ A: 不是。R19的闭环自动化框架定义了三个层次，Level 3（完全闭环）仅适用于低风险的操作场景（如负载均衡）。对于高风险操作（如网络切片重配置、策略变更），仍然需要人工审批。3GPP的设计理念是"人机协同"而非"机器替代人"。
Q: R19的Multi-UPF PDU Session与R18的UL CL/Branching UPF有什么区别？ A: R18的UL CL/Branching UPF是同一个PDU会话内通过上行分类器（Uplink Classifier）实现流量分流，所有UPF在同一个PDU会话的数据路径上。R19的Multi-UPF PDU Session允许一个PDU会话真正关联多个独立的UPF实例，SMF可以独立管理每个UPF的生命周期，支持更灵活的拓扑组合。
Q: NDL（Network Data Layer）在R19中是完整的规范还是概念框架？ A: R19中的NDL主要是概念框架（Conceptual Framework），定义了统一数据架构的设计原则和关键接口。完整的Stage 2和Stage 3规范预计在后续Release中完善。但R19已定义了DCCF和AdRF的详细功能和接口，这些是NDL框架的核心组件，可以在R19中实际部署使用。
本文由「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 等场景全覆盖。
