3GPP Release 19是5G-Advanced的第二个标准版本，于2025年12月完成Stage 3冻结，被业界公认为5G向6G过渡的关键桥梁。如果说Release 18（5G-Advanced的首个版本）奠定了AI/ML进入移动通信网络的基础框架，那么Release 19则将这些框架真正"内生化"——AI不再是外挂的分析模块，而是渗透到每一个网络功能的设计逻辑中。
在核心网架构层面，TS 23.501 V19.x.x相比R18的变化幅度是系统性的。SA2工作组在本轮引入了多个新的架构课题（Study Items）和工作项目（Work Items），其中对5GC架构影响最深远的包括：
| Work Item编号 | 课题名称 | 核心网影响范围 |
|---|---|---|
| SP-231187 | Net4AI – 网络对AI/ML服务的原生支持 | NWDAF/AnLF/MTLF架构重构、新增ADRF |
| SP-2401xx | Ambient IoT 架构支持 | 新增AIoTF网络功能 |
| SP-2310xx | eNS_Phase3 增强网络切片 | 切片管理架构优化 |
| SP-2312xx | NTN Core增强 | AMF/SMF卫星场景适配 |
| SP-2405xx | 5GC节能 网络功能级节能 | AMF/SMF/UPF节能态 |
| SP-2309xx | SCP增强 通信模型优化 | SCP Model D增强 |
图表 1
NWDAF（Network Data Analytics Function）的演进是理解R19核心网AI原生化的关键线索：
R19中SA2通过Net4AI项目，将NWDAF及其周边组件的概念升格为网络数据层（Network Data Layer, NDL）。NDL不再只是一个"分析功能"，而是一套横跨控制面、用户面和管理面的数据基础设施。
TS 23.501 V19 Section 6.2.x 对NDL的架构定义如下：
图表 2
| 特性维度 | Release 18 | Release 19 |
|---|---|---|
| 分析ID（Analytics ID）数量 | 约30个 | 扩展至45+，新增NF负载预测、节能分析、AIoT设备密度分析等 |
| ML模型管理 | 基本的上传/下载 | 完整的ML生命周期管理（训练→验证→部署→退化检测→重训练） |
| 数据采集范围 | NF级粒度 | 支持NF实例级、切片实例级的细粒度采集 |
| 联邦学习 | NWDAF间直连联邦训练 | 支持跨PLMN联邦、ADRF作为中间数据聚合点 |
| 实时分析能力 | 秒级~分钟级 | 引入流式分析框架，支持毫秒级异常检测 |
| 数据存储 | ADRF仅存分析结果 | ADRF作为统一数据湖，存储原始数据+特征+模型+分析结果 |
实战部署考量：ADRF在R19中的角色变化意味着运营商需要重新评估数据存储架构。R18时代ADRF可以是一个轻量级的分析结果缓存，R19中ADRF需要支撑全量数据湖的职责，存储容量规划需要按PB级考量（一个中等规模运营商每秒产生的5GC信令数据可达数百万条）。
Ambient IoT（环境物联网，也称零能物联网）是R19引入的革命性概念。这类设备不依赖电池供电，而是通过能量收集（Energy Harvesting）——如射频反向散射（Backscatter Communication）、太阳能、热能等方式获取工作能量。
这带来了一系列核心网架构挑战：
TS 23.501 V19 Section 4.x.x（Ambient IoT相关架构）引入了AIoTF（Ambient IoT Function）作为新的网络功能：
图表 3
AIoTF提供以下服务化接口（SBI）：
| SBI服务操作 | 服务类型 | 说明 |
|---|---|---|
Naiotf_DeviceRegistration |
注册 | Ambient IoT设备的简化注册，支持批量注册 |
Naiotf_DeviceAuthentication |
认证 | 针对不同设备等级的差异化认证（Class A可能仅需设备ID验证） |
Naiotf_DataReporting |
数据上报 | 设备数据（温度、位置等）的聚合上报至AF |
Naiotf_DeviceManagement |
设备管理 | 设备配置更新、固件OTA（仅Class C支持） |
Naiotf_Discovery |
发现 | 允许AF查询特定区域/类型的Ambient IoT设备 |
关键设计决策：AIoTF为什么是独立NF而不是AMF/NEF的功能扩展？SA2的讨论记录（S2-24xxxx系列文档）揭示了三个原因：
3GPP自R16引入SCP以来，定义了四种通信模型：
| 模型 | 发现方式 | 通信路径 | 适用场景 |
|---|---|---|---|
| Model A | NF直连NRF发现 | NF→NF直连 | 传统模型，无SCP参与 |
| Model B | NF→NRF发现，经SCP路由 | NF→SCP→NF | 控制面集中管理 |
| Model C | NF→NRF发现，SCP仅转发 | NF→SCP→NF | 不委托发现的间接通信 |
| Model D | SCP代理发现+路由 | NF→SCP→NF | 完全委托模式，NF无需知NRF |
TS 23.501 V19 Section 6.2.x 和 TS 29.500 V19 对SCP的增强主要体现在：
（1）增强Model D——智能路由能力
R19中SCP在Model D基础上增加了基于网络拓扑和实时负载的智能路由决策能力。SCP不再只是简单的"发现+转发"，而是能够：
（2）SCP级联（SCP Chaining）
R19允许SCP的级联部署，适应大型运营商的多层级网络拓扑：
图表 4
（3）SCP的节能感知路由
R19新增了SCP与NWDAF的联动——SCP可以根据NWDAF提供的负载分析结果，将流量集中路由到少数活跃NF实例，从而允许其他实例进入节能态。这是5GC节能（5GC Energy Saving）工作项的核心机制之一。
| 能力维度 | R18 SCP | R19 SCP |
|---|---|---|
| 路由决策 | 静态配置 + NRF发现结果 | 动态路由（拓扑+负载+亲和性） |
| 级联部署 | 不支持 | 支持多级SCP级联 |
| 节能感知 | 无 | 与NWDAF联动，支持节能路由 |
| 安全 | TLS + OAuth2.0 | 增强令牌传递、支持跨域信任代理 |
| 故障恢复 | 基本重试 | 支持备用SCP自动切换、请求重放 |
R19对AMF的增强主要集中在三个方面：
（1）AMF节能态（Energy Saving Mode）
TS 23.501 V19 Section 5.x.x定义了AMF实例的节能状态机。当NWDAF分析判定某AMF实例所在区域的负载低于阈值时，可通过管理面触发该实例进入节能态：
（2）Ambient IoT设备注册优化
AMF新增了对Ambient IoT设备的批量注册支持。传统注册流程中每UE需要独立的NAS信令交互（Registration Request → Identity Request → Authentication → Security Mode → Registration Accept），对于百万级IoT设备而言信令风暴不可避免。R19引入了Bulk Registration机制，Reader可以为一批设备发送合并的注册请求。
（3）NTN场景增强
AMF对卫星场景的支持进一步增强： - 支持基于卫星ephemeris（星历数据）的TA（Tracking Area）动态调整 - 增强的移动性约束处理，支持卫星波束覆盖范围的不规则形状
（1）增强的PDU会话管理
R19中SMF的PDU会话管理能力增强包括：
（2）切片感知的会话管理
eNS_Phase3项目为SMF带来了更精细的切片感知能力： - 支持同一S-NSSAI下的子切片（Sub-Slice）概念，SMF可以根据子切片ID选择不同的UPF路径 - 增强的UL CL（Uplink Classifier）和BP（Branching Point）机制，支持更灵活的本地分流
（1）UPF节能机制
UPF在R19中引入了用户面节能态：
| UPF状态 | 描述 | 触发条件 |
|---|---|---|
| Active | 正常处理所有N4会话和用户面流量 | 默认状态 |
| Light Sleep | 关闭部分端口/队列，保留活跃会话 | 负载 < 30% |
| Deep Sleep | 迁移所有N4会话至同Set内其他UPF，完全休眠 | 负载 < 5% 持续N分钟 |
| Wake-up | 快速恢复能力 | 检测到新PDU Session建立需求 |
（2）UPF数据面加速增强
R19在TS 29.244（PFCP协议）中增加了新的PFCP IE，支持： - GTP-U的硬件卸载标记（Hardware Offload Indication），允许SMF指示UPF将特定流量的封装/解封装卸载至SmartNIC/DPU - 增强的QoS Enforcement Report，支持逐包时延测量报告
以下展示一个典型的Ambient IoT设备通过Reader接入5GC的完整信令流程，涉及AIoTF的简化认证机制：
图表 5
R18及之前，NRF的NF发现（Nnrf_NFDiscovery）基于静态的NF Profile匹配——消费者提供目标NF类型、切片信息、TAI等参数，NRF返回匹配的NF实例列表。这种机制有几个痛点：
R19通过以下机制增强NRF发现：
| 增强特性 | 描述 | 相关TS章节 |
|---|---|---|
| NWDAF辅助发现 | NRF可以从NWDAF获取NF实例的实时负载信息，在发现结果中附带负载指标 | TS 23.501 Section 6.3.x |
| 亲和性发现 | 支持"与某NF实例保持亲和"的发现偏好，用于SMF Set/AMF Set内的一致性选择 | TS 29.510 Section 6.2.x |
| 拓扑感知路由 | SCP在转发发现请求时，可以基于网络拓扑信息优先返回拓扑距离近的NF实例 | TS 23.501 Section 6.2.x |
| 批量发现 | 允许一次请求查询多种NF类型，减少信令交互次数 | TS 29.510 Section 6.1.x |
对于已经在R18/R17基础上部署5GC的运营商，R19的升级影响可以分为三个层级：
Level 1 — 软件升级即可支持（低风险）： - NWDAF新增Analytics ID（主要是配置+数据模型更新） - SCP Model D增强（路由策略更新） - AMF/SMF/UPF的协议扩展（新增IE兼容处理）
Level 2 — 需要架构调整（中风险）： - ADRF从轻量缓存升级为数据湖（存储架构重构） - NRF智能化发现（需要NRF与NWDAF的数据通道打通） - 5GC节能机制（需要OAM与SCP/NWDAF的联动编排）
Level 3 — 需要新建网络功能（高投入）： - AIoTF部署（全新NF，需要评估是否有Ambient IoT业务需求） - SCP级联部署（网络拓扑重构，适合大规模运营商）
| 参数 | 建议值 | 说明 |
|---|---|---|
| AMF节能态触发阈值 | 负载 < 20% 持续15分钟 | 根据本地业务模式调整 |
| UPF Deep Sleep触发延迟 | N = 10分钟 | 避免频繁状态切换 |
| NWDAF分析周期（负载分析） | 30秒 | 节能场景需要较高频率 |
| SCP路由表更新周期 | 60秒 | 与NWDAF分析周期对齐 |
| ADRF数据保留策略 | 原始数据7天/聚合数据90天 | 根据法规和ML训练需求调整 |
Q: AIoTF是否必须在R19部署？没有Ambient IoT业务需求的话可以不部署吗？
A: AIoTF是可选网络功能。如果运营商没有Ambient IoT业务计划，完全可以不在R19中部署AIoTF。3GPP规范中AIoTF的相关流程均标记为"conditional"——仅在运营商声明支持Ambient IoT时才需要实现。但需要注意的是，如果未来计划支持智能物流、工业标签等场景，提前预留AIoTF的接口和计算资源是明智的。
Q: NWDAF的"数据湖"与传统大数据平台（如Hadoop/Spark）是什么关系？ADRF会替代它们吗？
A: 两者是互补关系而非替代关系。ADRF是3GPP标准化的数据存储功能，主要存储5GC内部的结构化分析数据（Analytics数据、ML模型参数等）。运营商现有的Hadoop/Spark等大数据平台负责海量原始信令的离线分析。在实际部署中，ADRF通常作为5GC内部的数据层，通过北向接口与外部大数据平台对接——ADRF提供实时/准实时的标准化分析能力，大数据平台提供全量的深度挖掘能力。
Q: SCP级联部署会不会增加信令时延？如何控制？
A: 级联确实会增加额外的跳数，但R19的SCP设计中包含了多级缓存机制。边缘层SCP（SCP-L1）会缓存热点NF实例的路由信息，大部分请求在SCP-L1即可完成路由决策，无需每条请求都穿透到汇聚层SCP-L2。实际测量表明，在合理配置缓存策略的情况下（缓存命中率 > 95%），额外时延可控制在1ms以内。建议缓存TTL设置为60-120秒，与NWDAF分析周期对齐。
Q: 5GC节能机制与现网已经实现的"缩容"有什么区别？
A: 现网常见的NF缩容是通过OAM手动或定时触发的，通常基于日间/夜间的流量模式进行预定义的实例增减。R19的5GC节能是自动化、闭环的——NWDAF实时分析负载趋势，通过SCP的节能感知路由自动将流量集中到活跃实例，达到节能阈值后自动触发实例休眠，并在负载回升时自动唤醒。关键区别在于：①实时性（分钟级而非小时级响应）；②闭环自动化（无需人工干预）；③跨NF协调（AMF+SMF+UPF协同节能，而非单NF独立操作）。
Q: R19核心网对终端有什么新要求？现有R18/R17终端能否接入R19网络？
A: R19核心网完全后向兼容现有终端。R15/R16/R17/R18终端可以正常接入R19网络，所有新功能对旧终端是透明的。唯一例外是Ambient IoT——这需要专用的Ambient IoT设备（Class A/B/C），传统手机不支持。对于R19新引入的终端侧特性（如增强的NAS能力），需要R19终端配合，但核心网侧会通过能力协商（Capability Negotiation）自动适配终端版本。
本文由「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 等场景全覆盖。
