# 5GC SBA架构Rel-19核心网四大演进深度解析 3GPP Release 19已于2025年12月完成标准冻结，作为5G-Advanced的第二个版本，它在5G核心网（5GC）的服务化架构（SBA）层面引入了系统性的能力跃升。本文聚焦Rel-19对核心网架构影响最深远的四大领域：**NWDAF AI/ML架构增强**、**Ambient IoT与AIoTF新网络功能**、**SCP间接通信模型演进**以及**边缘计算与UPF流量编排增强**，深入解读TS 23.501、TS 23.288、TS 29.500等核心规范的具体变更。 --- ## 一、Rel-19核心网架构全景：从SBA到AI-Native Rel-19并非对5GC架构的推倒重来，而是在Rel-15/16/17/18奠定的SBA基础上，向**AI原生网络**和**全域融合**两个方向深度演进。TS 23.501 V19.x.x在架构参考模型中新增和修改了以下关键要素：  > *图表 1* ### Rel-19 核心网关键时间线 | 里程碑 | 时间 | 内容 | |--------|------|------| | Stage 1冻结 | 2025年3月 | TS 22系列需求规范冻结 | | Stage 2冻结 | 2025年6-9月 | TS 23系列架构规范冻结 | | Stage 3冻结 | 2025年12月 | TS 24/29系列协议规范冻结 | | 规范可用 | 2025年12月 | 完整可实施规范发布 | Rel-19在SA2工作组（架构组）下的核心网相关Work Items超过20个，涵盖了从AI/ML原生架构、Ambient IoT、NTN Phase 3到网络切片增强的完整技术栈。以下逐一剖析四大关键演进方向。 --- ## 二、NWDAF AI/ML架构增强：从数据分析到AI原生 ### 2.1 架构分离：MTLF与AnLF的职责细化 TS 23.288 V19.x.x对NWDAF架构进行了重要重构。Rel-18引入的**MTLF（Model Training Logical Function）**和**AnLF（Analytics Logical Function）**分离架构在Rel-19中得到全面强化：  > *图表 2* **MTLF**负责ML模型的全生命周期管理——训练、验证、部署和更新。**AnLF**则专注于使用训练好的模型执行实时推理分析，输出分析结果供其他NF消费。 Rel-19在此架构上引入了三项关键增强： **（1）联邦学习支持** TS 23.288 Section 6.2A新增了分布式NWDAF实例间的联邦学习协作机制。多个MTLF实例可以在不共享原始数据的前提下协作训练全局模型，这对跨PLMN或多数据中心部署至关重要。具体实现上，MTLF通过Nnwdaf_MLModelProvision服务的参数`federated_learning_config`协商联邦学习的轮次、聚合算法（如FedAvg）和隐私保护策略（如差分隐私参数ε）。 **（2）Analytics ID扩展** Rel-19新增了多个Analytics ID（分析标识），扩展了NWDAF的分析覆盖范围： | Analytics ID | 新增/增强 | 描述 | |-------------|----------|------| | `nf_load` | 增强 | 细粒度NF负载预测，支持CPU/内存/会话数多维指标 | | `slice_load_level` | 增强 | 端到端切片负载分析，含RAN+CN+Transport | | `ue_mobility` | 增强 | 增加轨迹预测能力，支持时间序列预测 | | `qoS_sustainability` | 增强 | QoS退化预测，新增时间窗口参数 | | `dispersion_analytics` | 新增(Rel-19) | UE分散性分析，用于覆盖优化 | | `dn_performance` | 增强 | DN性能分析，增加RTT/丢包/吞吐量维度 | | `red_cap_analytics` | 新增(Rel-19) | RedCap终端行为分析与异常检测 | **（3）NWDAF与O-RAN的端到端分析协调** TS 23.501 Section 6.2.3新增了NWDAF与RAN智能控制器（RIC）的交互接口，通过Adaptation Function协调核心网侧分析与RAN侧分析，实现真正意义上的端到端网络智能。这一设计考虑了O-RAN架构中A1策略接口和E2数据接口的映射关系。 ### 2.2 现网部署影响 对于运营商而言，NWDAF的MTLF/AnLF分离架构意味着： - **部署灵活性**：MTLF可集中部署于区域数据中心，AnLF可分布式部署于边缘，降低推理延迟 - **模型管理**：需建立ML模型版本管理和灰度发布机制 - **数据合规**：联邦学习机制帮助满足数据不出域的监管要求（如GDPR、数据安全法） - **资源规划**：MTLF训练需要GPU/NPU资源，AnLF推理需要低延迟存储（如Redis缓存分析结果） --- ## 三、Ambient IoT与AIoTF：全新网络功能 ### 3.1 Ambient IoT的架构挑战 Ambient IoT（A-IoT，环境物联网）是Rel-19最具突破性的架构创新之一。A-IoT设备无电池，通过能量收集（backscatter通信）工作，其协议栈极简，无法运行完整的NAS协议栈。 3GPP在TS 23.501 Section 4.2.9和Section 6.x中引入了全新的网络功能——**AIoTF（Ambient IoT Function）**，专门处理A-IoT设备的注册、识别和数据传输。 ### 3.2 AIoTF架构设计  > *图表 3* AIoTF的核心设计理念是**代理模式**：由于A-IoT设备无法运行NAS信令，AIoTF代表这些设备与5GC其他NF交互。具体机制包括： **（1）设备标识与认证** TS 23.501 Section 5.9.12定义了A-IoT设备的标识体系。A-IoT设备使用简化的设备标识符（A-IoT Device ID），由AIoTF映射为5GC内部的GMPI（Guami-based Mobile Equipment Identifier）。认证方面，A-IoT设备无需USIM，AIoTF基于预配置的密钥或backscatter信号特征进行轻量级认证。 **（2）数据传输模式** AIoTF支持两种数据传输模式： | 模式 | 描述 | 适用场景 | |------|------|---------| | 透明传输 | A-IoT数据通过gNB中继，经UPF转发至AF | 物流追踪、资产盘点 | | AIoTF代理模式 | AIoTF解析A-IoT数据，通过NEF暴露给AF | 智能零售、环境监测 | **（3）Naiotf服务接口** AIoTF定义了新的SBI接口`Naiotf`，包含以下服务操作： - **Naiotf_DeviceRegistration**：A-IoT设备注册/去注册 - **Naiotf_DataTransfer**：上下行数据传输 - **Naiotf_DeviceManagement**：设备群组管理和批量操作 - **Naiotf_Notification**：事件通知（设备进入/离开覆盖区） ### 3.3 与现有NF的交互 AIoTF与AMF的交互是Rel-19架构设计的精妙之处。当gNB检测到A-IoT设备的backscatter信号时，gNB通过N2接口将A-IoT特定的NAS承载信息（含A-IoT Device ID和负载payload）发送给AMF。AMF根据A-IoT标识路由选择规则（TS 23.501 Section 6.3.15），将请求转发至对应的AIoTF实例。 AIoTF随后执行： 1. 向UDM查询A-IoT设备订阅信息 2. 创建/更新A-IoT设备上下文 3. 通过SMF建立数据传输通道（PDU Session复用或专用承载） 4. 将数据通过UPF/NEF路由至AF --- ## 四、SCP间接通信模型演进 ### 4.1 四种通信模型的演进路径 TS 29.500 V19.x.x定义了NF服务消费者与生产者之间的四种通信模型。Rel-19在此基础上对**Model D（间接通信+委托发现）**进行了关键增强。 | 模型 | 发现方式 | 通信路径 | Rel-19变化 | |------|---------|---------|-----------| | Model A | 直接(NRF) | 直接(Consumer→Producer) | 无变化 | | Model B | 直接(NRF) | 间接(Consumer→SCP→Producer) | 增强SCP链式路由 | | Model C | 委托(SCP) | 间接(Consumer→SCP→Producer) | 增强负载均衡 | | Model D | 委托(SCP) | 直接(Consumer→Producer) | **新增多SCP协调** | Rel-19对SCP架构的增强主要体现在三个维度： **（1）多SCP协调与链式路由** 在大规模部署中，不同NF实例可能注册在不同的SCP域中。Rel-19引入了**SCP Chaining**机制（TS 29.500 Section 6.1.2.3），允许请求跨越多个SCP实例路由。当SCP-A收到请求但目标NF不在其服务范围内时，SCP-A可以转发至SCP-B，形成路由链。 SCP间的路由信息通过`3gpp-Sbi-Target-Scope` Header和`3gpp-Sbi-RouteInfo` Header传递，避免了每个SCP需要维护全量NF路由表的问题。 **（2）委托发现的增强** Model D中，SCP代替消费者向NRF发起发现请求（Nnrf_NFDiscovery），然后将发现结果（目标Producer的URI）返回给消费者。Rel-19增强了此流程： - **批量发现**：一次发现请求可返回多个候选Producer，消费者自行选择 - **发现结果缓存**：SCP可缓存发现结果，减少NRF查询次数 - **优先级路由**：SCP根据负载、时延、地理位置等因素为消费者推荐最优Producer **（3）SCP安全增强** TS 33.522 V19.0.0（5G SCAS for SCP）对SCP安全提出了新要求： - SCP必须支持OAuth 2.0 token的中继和验证 - 支持mTLS双向认证 - SCP间通信需要独立的安全通道 ### 4.2 SCP通信模型对比  > *图表 4* ### 4.3 现网部署建议 | 场景 | 推荐模型 | 理由 | |------|---------|------| | 小规模单数据中心 | Model A | 简单直接，无额外组件 | | 多数据中心 | Model C | SCP集中路由，减少跨域NRF查询 | | 边缘+中心混合 | Model D | 边缘Consumer发现后直连，减少SCP转发延迟 | | 运营商间漫游 | Model C + SCP Chaining | 跨PLMN路由由SCP链处理 | --- ## 五、边缘计算与UPF流量编排增强 ### 5.1 EAS发现与重定位增强 Rel-19在TS 23.558和TS 29.556（V19.4.0）中对Edge Application Server（EAS）发现和重定位机制进行了系统性增强。 **EAS Discovery增强要点：** - **计算感知发现**：EAS发现不仅考虑网络拓扑距离，还纳入EAS的计算负载和可用资源。TS 29.556新增`computing_status`参数，SMF在做EAS选择时可将计算因素纳入决策 - **EAS Rediscovery触发条件扩展**：新增UE移动性事件、EAS计算过载、UPF路径变化作为重发现触发条件 - **多EAS并行发现**：支持一次发现请求返回多个候选EAS，供SMF/UPF做智能选择 ### 5.2 UPF流量编排增强 TS 23.501 Section 6.4.3和TS 29.244（PFCP协议）在Rel-19中引入了以下UPF增强： | 特性 | Rel-18 | Rel-19增强 | |------|--------|-----------| | ULCL/BP | 静态配置 | 动态按需创建，支持会话内切换 | | Traffic Steering | 基于FAR规则 | 增加计算负载感知路由 | | QoS Monitoring | 基本QoS监控 | 增加实时QoS预测 | | Multi-access PDU | MA-PDU基本框架 | 增强ATSSS多路径编排 | | Data Collection | 基于N4报告 | 增强与NWDAF的数据对接 | **动态ULCL创建流程**是Rel-19边缘计算的核心场景：  > *图表 5* ### 5.3 UPF与NWDAF的数据闭环 Rel-19的一个重要设计理念是建立**UPF数据收集→NWDAF分析→SMF/PCF策略调整**的闭环。具体机制： 1. **UPF数据收集增强**：TS 29.244 PFCP协议新增`Measurement Method = COMPUTING_LOAD`，UPF可上报关联EAS的计算负载 2. **NWDAF分析输入**：NWDAF通过DCCF（Data Collection Coordination Function）订阅UPF的QoS监控报告和流量统计 3. **策略闭环**：SMF订阅NWDAF的`dn_performance` Analytics ID，根据分析结果动态调整ULCL/BP规则 这一闭环使得边缘计算从"静态配置"走向"动态优化"，是实现自驱动网络的关键技术基础。 --- ## 六、其他重要架构变更 ### 6.1 Personal IoT Network (PIN) Rel-19引入了**个人IoT网络（PIN）**概念（TS 23.501 Section 4.2.13）。PIN是一组由用户管理的IoT设备集合，通过PIN Element（具有5GC连接能力的网关设备）接入5G网络。架构上： - PIN Element通过标准Uu接口接入gNB，与AMF交互完成注册 - PIN内设备通过非3GPP接入方式（如Bluetooth、Wi-Fi、Zigbee）连接PIN Element - PIN Element通过Npin接口与5GC交互，实现PIN内设备的身份映射和数据路由 ### 6.2 NTN Phase 3核心网支持 Rel-19的NTN增强对核心网的影响主要集中在AMF和SMF： - **AMF增强**：支持卫星移动性管理，包括store-and-forward模式下的注册区管理、卫星切换时的Registration Area更新优化 - **SMF增强**：支持NTN场景下的PDU Session连续性，包括卫星间切换时的会话迁移和时延补偿QoS调整 - **时间同步**：TS 23.501新增NTN时间信息（卫星星历、传播时延）作为AMF和SMF的输入参数 ### 6.3 网络切片增强 Rel-19对网络切片的增强（TS 23.501 Section 5.15）主要体现在： - **切片级计算资源管理**：每个切片可独立配置计算资源配额，由NWDAF监控使用率 - **切片间资源隔离增强**：引入了更严格的隔离等级定义（soft/isolation/hard），影响UPF和SMF的部署策略 - **e2e切片管理**：增强与Management System（TS 28.541）的协同，支持切片实例的自动扩缩容 --- ## 七、规范关联与迁移路线图 ### 7.1 核心规范关联矩阵 | 主规范 | 关联规范 | Rel-19关键变更 | |--------|---------|---------------| | TS 23.501 (架构) | TS 23.502 (流程) | 新增AIoTF/PIN架构、NTN增强 | | TS 23.288 (NWDAF) | TS 29.520/29.521 | MTLF/AnLF分离、联邦学习 | | TS 29.500 (SBA实现) | TS 29.510 (NRF) | SCP Model D增强、多SCP协调 | | TS 29.244 (PFCP) | TS 23.501 | UPF计算感知路由、NWDAF数据闭环 | | TS 29.556 (EAS发现) | TS 23.558 (边缘架构) | 计算感知EAS发现 | | TS 33.522 (SCP安全) | TS 33.501 (安全架构) | SCP安全增强 | ### 7.2 从Rel-18升级到Rel-19的迁移考量 对于计划从Rel-18升级到Rel-19的运营商，以下关键点需重点关注： **第一阶段：基础架构升级（3-6个月）** - SCP升级：支持Model D和多SCP协调，需更新SCP软件和配置 - NRF增强：支持Rel-19的NF Profile新增字段（如AIoTF注册信息） - 升级PFCP协议栈：支持新增IE **第二阶段：AI/ML能力部署（6-12个月）** - 部署NWDAF MTLF/AnLF分离架构 - 训练初始ML模型，建立数据管道 - 配置DCCF数据采集策略 **第三阶段：新特性引入（12-18个月）** - 按需部署AIoTF（如有A-IoT业务需求） - 启用边缘计算增强功能 - 开启NTN Phase 3支持 --- ## 常见问题 **Q: NWDAF的MTLF和AnLF必须分离部署吗？** A: 不是必须的。规范允许MTLF和AnLF合设于同一NWDAF实例中（TS 23.288 Section 5.1）。分离部署是推荐的最佳实践，适用于大规模网络或多数据中心场景。对于中小规模网络，合设部署可降低运维复杂度。 **Q: AIoTF是必选的网络功能吗？运营商没有A-IoT业务需求是否需要部署？** A: AIoTF是可选网络功能。只有运营商计划提供Ambient IoT服务时才需要部署。但需注意，如果终端厂商推出A-IoT设备，gNB侧的软件需要升级以支持backscatter信号的中继处理。 **Q: SCP的Model D和Model C在实际部署中如何选择？** A: Model C适合集中管控场景，所有NF间通信经过SCP，便于统一监控和策略执行。Model D适合对时延敏感的场景，Consumer在SCP辅助发现后直接与Producer通信，减少一跳转发延迟。混合部署也是可行的——核心NF间用Model C，边缘NF用Model D。 **Q: Rel-19的边缘计算增强对现有MEC平台有什么影响？** A: Rel-19主要增强了EAS发现和UPF流量编排的智能化水平。现有MEC平台需要升级以支持计算感知发现接口（暴露`computing_status`），UPF需要支持动态ULCL/BP创建。如果现有部署使用静态ULCL配置，需要规划向动态编排的迁移路径。 **Q: Rel-19核心网升级是否需要终端配合？** A: 大部分核心网增强（如SCP、NWDAF、UPF流量编排）不需要终端升级。但A-IoT、PIN、NTN增强等特性需要终端支持相应的Rel-19协议栈。建议运营商根据业务需求分阶段推进终端生态。 --- > 本文由「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 等场景全覆盖。