# 3GPP Release 19 核心网架构演进：5GC迈向AI原生与天地融合 3GPP Release 19作为5G-Advanced的第二版标准，已于2025年底完成Stage 3冻结，标志着5G核心网进入了一个全新的发展阶段。如果说Rel-18是5G-Advanced的开篇之作，那么Rel-19则是对5GC架构的一次系统性重塑——从AI原生网络智能到天地一体化接入，从Ambient IoT新网元到绿色节能架构，核心网正在经历自Rel-15 SBA引入以来最深刻的一次变革。 本文基于TS 23.501 V19.x、TS 23.502 V19.x、TS 23.288 V19.x等核心规范，深入解读Rel-19 5GC架构的六大关键演进方向。 --- ## 一、总体架构视图：Rel-19 5GC全景 Rel-19的5GC架构在Rel-18的基础上，新增和增强了大量网络功能。下图展示了Rel-19核心网的主要架构变化：  > *图表 1* TS 23.501 V19.x在Section 6中对网络功能进行了系统性更新。与Rel-18相比，Rel-19 5GC架构的核心理念可以概括为三个关键词：**AI原生（AI-Native）**、**天地融合（TN-NTN Convergence）**和**极致物联（Ultra-IoT）**。 --- ## 二、eSBA与SCP演进：Service Mesh理念落地核心网 ### 2.1 Service Communication Proxy（SCP）的架构定位 Rel-18首次引入了Service Communication Proxy（SCP）和Service Mesh的概念到3GPP规范中。Rel-19在此基础上进行了实质性增强，体现在TS 23.501 Section 6.2.6对SCP的重新定义。 SCP在5GC SBA架构中承担着三重角色： | 角色 | 功能描述 | 规范章节 | |------|----------|----------| | **间接通信代理** | NF间SBI消息的转发代理，支持请求路由 | TS 23.501 §6.2.6.2 | | **服务发现增强** | 结合NRF实现智能服务实例选择与负载均衡 | TS 29.500 §6.2 | | **安全策略执行点** | 执行NF间通信的授权、加密策略 | TS 33.501 §13.x | Rel-19对SCP的关键增强包括： **1. 服务路由策略（Service Routing Policy）** SCP在Rel-19中支持基于策略的服务路由。当NF Consumer发起服务请求时，SCP可以根据以下维度进行路由决策：  > *图表 2* **2. 无NRF模式（Delegated Discovery）** Rel-19引入了SCP可以代理NRF进行服务发现的能力。在边缘部署场景中，边缘SCP可以缓存NRF的服务注册信息，在本地完成服务发现，避免每次请求都访问中心NRF，显著降低时延。这在TS 23.501 V19 Section 6.2.6.3中详细规定。 ### 2.2 eSBA对现网部署的影响 对于运营商而言，SCP的引入改变了NF间通信模型： | 对比维度 | Direct Communication
（Rel-15/16） | Indirect via SCP
（Rel-18/19） | |----------|--------------------------------------|-------------------------------------| | **通信模型** | NF→NF 直连 | NF→SCP→NF 代理 | | **服务发现** | 每次查询NRF | SCP缓存+按需查询 | | **安全** | NF间直接TLS | SCP可集中执行安全策略 | | **运维复杂度** | 点对点管理 | 集中化流量管理 | | **扩展性** | N²连接问题 | 线性扩展 | | **边缘适用性** | 需要本地NRF | SCP代理发现 | **现网部署建议**：对于已部署Rel-16/17 5GC的运营商，引入SCP应采用渐进式策略——先在边缘计算场景部署SCP解决NRF查询时延问题，再逐步将中心NF间通信迁移到SCP代理模式。SCP本身应采用高可用部署（Active-Active），避免成为单点故障。 --- ## 三、NWDAF演进：从数据分析到AI原生网络智能 ### 3.1 NWDAF内部架构拆解 Rel-19中NWDAF的架构演进是最值得关注的核心网变革之一。TS 23.288 V19.x定义了NWDAF的功能拆分模型： **NWDAF在Rel-19中明确拆分为两大逻辑功能：** - **MTLF（ML Training Function）**：负责机器学习模型的训练和管理 - **AnLF（Analytics Logical Function）**：负责基于训练好的模型进行推理和提供分析服务  > *图表 3* ### 3.2 联邦学习（Federated Learning）的引入 Rel-19在TS 23.288 Section 6.2C中定义了多NWDAF之间的联邦学习机制，这是3GPP首次在核心网架构中引入分布式机器学习框架。 **联邦学习的核心设计意图：** 1. **数据隐私保护**：不同PLMN或不同切片的NWDAF之间无需共享原始数据，仅交换模型参数 2. **跨域模型优化**：在多运营商漫游场景下，漫游地的NWDAF可以为归属地提供本地化模型增强 3. **合规性**：满足数据不出域的监管要求（如GDPR） 联邦学习的信令流程在TS 23.288 V19 Section 6.2C.2中定义，主要包括： - FL协商阶段：参与方协商训练参数、迭代轮次 - 本地训练阶段：各MTLF基于本地数据进行训练 - 参数聚合阶段：Leader MTLF收集各方模型参数进行聚合 - 模型分发阶段：聚合后的全局模型分发给各参与方 ### 3.3 NWDAF分析能力扩展 Rel-19新增的分析ID（Analytics ID）包括： | Analytics ID | 描述 | 新增Release | 典型消费者 | |-------------|------|------------|-----------| | `UE_COMMUNICATION` | UE通信模式分析 | Rel-15 | PCF, AMF | | `NETWORK_PERFORMANCE` | 网络性能分析 | Rel-15 | OAM | | `NF_LOAD` | NF负载分析 | Rel-16 | SCP, AMF | | `SERVICE_EXPERIENCE` | 业务体验分析 | Rel-16 | PCF, AF | | `UE_MOBILITY` | UE移动性分析 | Rel-16 | AMF | | `DISPERSION` | 分散性分析 | Rel-17 | PCF | | `RED_CAP_UES_PARAMS` | RedCap UE参数分析 | Rel-18 | AMF | | **`NETWORK_ENERGY_SAVING`** | **网络节能分析** | **Rel-19** | **OAM, PCF** | | **`NTN_MOBILITY_PREDICTION`** | **NTN移动性预测** | **Rel-19** | **AMF** | | **`AI_ML_MODEL_PERFORMANCE`** | **AI/ML模型性能监控** | **Rel-19** | **OAM** | Rel-19中NWDAF的一个重要增强是其与SCP的联动。SCP可以向NWDAF订阅NF负载分析，实现基于AI预测的动态服务路由——这是"AI-Native"架构理念的直接体现。 --- ## 四、NTN核心网增强：天地一体化接入管理 ### 4.1 AMF对NTN的适配 Rel-19对NTN的支持从Rel-17的"接入层适配"深入到了"核心网架构级支持"。TS 23.501 V19 Section 5.4.2新增了对卫星接入场景的AMF行为规范。 **关键变化包括：** **1. 卫星覆盖区域与TA映射** 在NTN场景中，由于LEO卫星的高速运动，传统的固定TA（Tracking Area）概念不再适用。Rel-19引入了**动态TA映射机制**——AMF需要根据卫星星历（ephemeris data）动态更新TA与卫星波束的映射关系。 具体而言，AMF从以下来源获取卫星信息： - gNB通过NGAP上报的卫星辅助信息（Satellite Assistance Information） - OAM配置的星历数据 - NEF/AF提供的卫星覆盖预测 **2. 条件切换（Conditional Handover）的核心网支持** Rel-19在TS 23.502中增强了AMF对NTN条件切换的处理流程。对于LEO卫星间切换，核心网需要支持： | 参数 | 地面网络 | NTN网络（Rel-19） | |------|---------|-------------------| | 切换触发 | 信号质量下降 | 卫星仰角+信号质量 | | 切换准备时间 | 毫秒级 | 秒级（卫星预测） | | TA更新频度 | 低（固定TA） | 高（动态TA） | | 注册区域 | 固定 | 随卫星运动变化 | | 寻呼范围 | 固定TA列表 | 卫星覆盖预测区域 | ### 4.2 SMF/UPF对NTN的适配 **1. PDU Session的NTN感知** SMF在Rel-19中新增了对卫星传输时延的感知能力。对于NTN接入的PDU Session，SMF可以： - 根据卫星类型（GEO/LEO/MEO）调整QoS参数中的时延预算 - 对LEO场景支持基于卫星切换的UPF重定位 - 与PCF联动调整策略，适配卫星链路的带宽波动 **2. UPF在卫星上的部署** Rel-19的NTN架构允许UPF部署在卫星载荷上，这对数据面架构有重大影响：  > *图表 4* 当UPF部署在卫星上时，本地流量可以在卫星上进行交换（Local Breakout），减少地面往返时延。SMF需要通过N4接口管理卫星UPF，并处理卫星间切换时的UPF迁移。 **现网部署考虑**：卫星UPF的部署需要解决N4接口的时延问题。SMF对卫星UPF的管理信令需要适配数百毫秒的传播时延，建议对PFCP会话建立/修改等流程设置合理的超时和重传参数。 --- ## 五、AIoTF：Ambient IoT Function——5GC全新网元 ### 5.1 一个全新网络功能的诞生 Rel-19引入了一个全新的核心网网络功能——**AIoTF（Ambient IoT Function）**，用于支持环境物联网（Ambient IoT，A-IoT）设备。这是继Rel-15定义5GC基础NF之后，3GPP首次在核心网架构中新增一个完整的网络功能。 AIoTF的引入背景是Ambient IoT设备的特殊性： - **无电池/极低功耗**：通过射频能量采集供电 - **极简通信能力**：仅支持简单的反射调制或后向散射通信 - **单向或极简双向通信**：不适合传统NAS信令 - **海量连接**：单小区可支持数万设备 TS 23.501 V19 Section 6.x定义了AIoTF的功能集： | AIoTF功能 | 描述 | 对应接口 | |-----------|------|---------| | **A-IoT设备管理** | 设备注册、鉴权、上下文管理 | Naiotf | | **数据中继** | 将A-IoT设备数据转发至AF/NEF | Naiotf-to-NEF | | **群组管理** | A-IoT设备的批量操作 | Naiotf-Group | | **触发管理** | 处理下行触发指令（如盘点命令） | Naiotf-Trigger | | **位置关联** | 与LMF协同提供A-IoT设备定位 | Naiotf-to-LMF | ### 5.2 AIoTF在架构中的位置 AIoTF通过SBI接口与NRF注册，与其他NF（AMF、NEF、UDM、LMF）进行交互。其独特之处在于，A-IoT设备不直接与AMF交互NAS信令，而是通过gNB的中继将A-IoT数据传递给AIoTF处理。  > *图表 5* **设计意图解析**：AIoTF不挂在AMF之下的原因是——Ambient IoT设备没有USIM，不执行传统NAS注册流程。gNB通过新的逻辑信道将A-IoT数据直接转发给AIoTF，AIoTF基于设备标识（如EPC编码）进行设备管理和数据路由。这种设计避免了为海量低能力设备引入复杂的NAS/MME处理逻辑。 --- ## 六、绿色核心网：网络节能的NF级支持 ### 6.1 NF Energy Saving的架构增强 Rel-19在核心网层面引入了系统性的节能框架。TS 23.501 V19 Section 6.x和TS 28.62x系列规范定义了核心网NF的节能能力。 **核心思路**：NWDAF提供网络级的节能分析建议，各NF据此执行节能动作。 **NF级节能操作包括：** | NF | 节能操作 | 触发条件 | |----|---------|---------| | **AMF** | 缩小注册区域、合并寻呼、进入节能态 | 低负载时段NWDAF建议 | | **SMF** | 批量处理PDU Session操作、延迟非紧急操作 | 负载低于阈值 | | **UPF** | 深度休眠模式（Deep Sleep Mode）、流量合并 | 无活跃会话 | | **NRF** | 标记NF实例为"节能态"、停止向其路由 | OAM触发 | | **SCP** | 避开节能态NF实例路由 | NRF通知 | ### 6.2 NWDAF Network Energy Saving分析 Rel-19新增的`NETWORK_ENERGY_SAVING`分析ID允许NWDAF基于历史流量模式和预测模型，为NF生成节能建议。其分析输出包含： - 推荐进入节能的NF实例列表 - 推荐的节能时间窗口 - 预期的能耗节省比例 - 对服务质量的影响评估 NWDAF通过Nnwdaf_AnalyticsInfo service向OAM系统或PCF提供这些分析结果，触发相应的节能策略。 --- ## 七、TSC/TSN增强：确定性网络的核心网支撑 Rel-19在TS 23.501 Section 5.27和TS 23.502中增强了对时间敏感通信（TSC）的支持，主要聚焦在SMF和UPF的增强： **1. SMF增强**： - 支持更精确的TSCAI（TSN Communication Assistance Information）配置 - 增强了与TSC Central Network Function（TSCTSF）的交互，支持动态QoS调整 - 新增对DetNet（确定性网络）IP流的处理能力 **2. UPF增强**： - 支持时间感知的包调度（Time-Aware Scheduling） - 增强了gPTP（generalized Precision Time Protocol）透明时钟功能 - 支持跨UPF的时间同步精度保障 **部署场景**：在工业4.0场景中，5G系统作为TSN网络的逻辑网桥。SMF在PDU Session建立时获取TSC辅助信息，并通过N4接口配置UPF的时隙调度参数。UPF作为TSN桥的端口，需要精确到微秒级的调度精度。 --- ## 八、Rel-18 vs Rel-19 核心网关键特性对比 | 特性领域 | Rel-18 | Rel-19 | |---------|--------|--------| | **NWDAF** | AnLF/MTLF分离定义，基础联邦学习 | 增强联邦学习，新增节能/NTN/ML性能分析 | | **SCP** | 基础间接通信、NRF查询代理 | 路由策略、代理发现、NWDAF联动 | | **NTN 5GC** | 基础卫星接入支持 | 动态TA、条件切换、卫星UPF部署 | | **AI/ML** | RAN侧AI/ML框架 | 核心网AI-Native架构、ML模型管理 | | **IoT** | RedCap增强 | AIoTF新增、Ambient IoT全栈支持 | | **节能** | RAN侧节能为主 | NF级系统性节能框架 | | **TSC** | 基础TSC支持 | DetNet集成、动态TSCAI | | **定位** | Rel-16/17/18逐步增强 | V2X定位、高精度定位增强 | | **多USIM** | 基础Multi-SIM | 增强Dual SIM并发管理 | --- ## 九、规范关联矩阵 Rel-19核心网架构的变更涉及多个规范的联动更新： | 主规范 | 关联规范 | 涉及内容 | |--------|---------|---------| | TS 23.501 V19 | TS 29.500/501 | SBI接口增强（SCP相关） | | TS 23.501 V19 | TS 29.518 | AMF服务接口增强（NTN） | | TS 23.501 V19 | TS 29.502 | SMF服务接口增强（TSC/NTN） | | TS 23.501 V19 | TS 29.244 | PFCP增强（UPF TSC/节能） | | TS 23.288 V19 | TS 29.520 | NWDAF服务接口（联邦学习） | | TS 23.501 V19 | TS 29.571 | 通用数据模型（新增IE） | | TS 33.501 V19 | TS 29.509 | AUSF安全增强 | | TS 23.501 V19 | TS 38.331/38.300 | NTN RAN-CN交互 | --- ## 常见问题 **Q: Rel-19的SCP和云原生Service Mesh（如Istio）是什么关系？** A: 3GPP SCP和云原生Service Mesh在理念上高度一致——都提供NF间通信的代理、路由、安全和可观测性。区别在于：SCP是3GPP标准化的、感知5GC语义的代理（理解SBI/NRF/Nnrf），而Istio等是通用的服务网格。实际部署中，SCP可以在Kubernetes环境中以Sidecar或独立网关的形式实现，底层可以复用Envoy等开源组件。推荐的做法是SCP作为5GC级别的逻辑功能，底层技术实现可以借鉴Service Mesh生态。 **Q: NWDAF的联邦学习在跨运营商场景中如何工作？** A: 跨运营商联邦学习在漫游架构下实现。VPLMN的NWDAF-MTLF和HPLMN的NWDAF-MTLF通过Nnwdaf接口交换模型参数（而非原始数据）。Rel-19定义了Leader-Follower和全对等两种联邦学习拓扑。在漫游场景中，通常由HPLMN的MTLF作为Leader进行参数聚合。关键是SEPP需要在两个PLMN间中转联邦学习信令，TS 33.501对这部分的安全性有明确规定。 **Q: AIoTF与传统的物联网架构（如NEF+AF）有何区别？** A: 核心区别在于Ambient IoT设备没有USIM、不执行NAS流程、不建立PDU Session。传统IoT设备通过NAS注册→PDU Session建立→数据传输的路径工作，而A-IoT设备通过gNB的读写器功能直接将数据传给AIoTF，AIoTF完成设备识别、数据路由和应用层对接。AIoTF更像是一个"轻量级的IoT网关+管理平台"，位于5GC内部，享受5GC的安全和管理框架。 **Q: 现网从Rel-18升级到Rel-19核心网，最大的挑战是什么？** A: 主要挑战有三方面：（1）SCP的引入改变了NF间通信模型，需要所有NF升级支持间接通信模式；（2）NWDAF的联邦学习功能需要跨域的数据协作机制，涉及安全策略和SEPP配置的更新；（3）NTN动态TA和卫星UPF需要AMF/SMF的协议栈改造。建议采用渐进式升级——先升级SCP和NWDAF（这些对现有业务影响最小），再分阶段引入NTN和AIoTF。 **Q: Rel-19的NF节能功能在实际网络中能节省多少能耗？** A: 根据3GPP TR 32.972的评估，在低负载时段（如凌晨），通过NWDAF引导的NF级节能操作，核心网侧可实现约15-30%的能耗节省。但具体效果取决于：（1）NF的虚拟化粒度（细粒度容器化更易于缩容）；（2）流量模式的可预测性；（3）节能策略的激进程度（深度休眠 vs 轻度缩容）。需要注意的是，UPF的节能操作要格外谨慎，因为UPF承载用户面流量，过度节能可能导致业务中断。 --- ## 延伸阅读 - 3GPP TS 23.501 V19.x — 5G System Architecture (Release 19) - 3GPP TS 23.288 V19.x — Architecture Enhancements for 5GS to Support Network Data Analytics Services - 3GPP TS 23.502 V19.x — Procedures for the 5G System - 3GPP TS 29.500 V19.x — Technical Realization of Service Based Architecture - 3GPP TR 23.700-07 — Study on 5GS Enhancement for Ambient IoT - arXiv:2512.03728 — AI/ML in 3GPP 5G Advanced: Services and Architecture - 3GPP TR 32.972 V19.x — Study on Enhancement of Service Based Management Architecture --- > 本文由「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 等场景全覆盖。