# 5G-Advanced核心网三大演进架构深度解析 5G-Advanced（Rel-18/19）不仅是无线接入网的性能提升，更是核心网架构的一次深刻变革。本文聚焦**服务化架构（SBA）通信模型演进**、**NWDAF数据分析体系重构**和**能量感知核心网**三大核心技术方向，从协议原理层面解读其设计动机与工程实现要点。 --- ## 一、SBA通信模型演进：从直连到委托代理 ### 1.1 设计动机 5G Rel-15引入的SBA架构，要求所有NF（Network Function）通过NRF进行服务发现，再直接与目标NF建立HTTP/2连接。这种**模型A（直连通信）**在NF数量较少的试验网中可以工作，但在商用网络中暴露出致命问题： - **NRF成为性能瓶颈**：每次服务调用前都需要查询NRF，高并发场景下NRF承载大量发现请求 - **NF间耦合过紧**：每个NF需要维护到所有可能对端NF的HTTP连接池，连接管理复杂度O(N²) - **安全策略难以集中**：NF直连模式下，安全认证和授权需要在每个NF中实现 Rel-16引入的SCP（Service Communication Proxy，TS 29.500）从根本上改变了这一架构。 ### 1.2 四种通信模型对比 3GPP TS 23.501定义了四种SBA通信模型： ``` 模型A：NF ←→ NRF ←→ NF（无SCP，直连发现+直连通信） 模型B：NF ←→ SCP ←→ NF（无NRF发现，SCP内嵌路由表） 模型C：NF ←→ SCP ←→ NRF ←→ SCP ←→ NF（SCP代理发现+通信） 模型D：NF ←→ SCP ←→ NF（NF直接查NRF，通过SCP通信） ``` | 特性 | 模型A | 模型B | 模型C | 模型D | |------|-------|-------|-------|-------| | 服务发现 | NF直接查NRF | SCP内置路由 | SCP代理查NRF | NF直接查NRF | | 服务通信 | NF直连 | SCP中转 | SCP中转 | SCP中转 | | NRF负载 | 高 | 无 | 低 | 中 | | NF改造量 | 大 | 大 | 小 | 中 | | 适用场景 | 实验室 | 小型专网 | 运营商商用网 | 混合部署 |  > *图表 1* ### 1.3 SCP委托发现的核心机制 模型C中SCP最关键的能力是**委托发现（Discovery Delegation）**，其工作流程如下（TS 29.500 Section 6.2）： 1. NF Consumer发送服务请求到SCP，携带目标NF类型和期望的服务参数 2. SCP判断本地路由缓存是否命中，若未命中则代理查询NRF 3. NRF返回匹配的NF Profile列表（含NF Instance ID、FQDN、负载信息等） 4. SCP根据负载均衡策略选择目标NF实例 5. SCP将请求转发至选定的NF Producer ``` 伪代码：SCP路由决策逻辑 func RouteRequest(req ServiceRequest): target_nf_type = req.headers["3gpp-Sbi-Target-Nf-Type"] service_name = req.headers["3gpp-Sbi-Service-Name"] // Step 1: 查询本地路由缓存 cached_instances = RouteCache.Lookup(target_nf_type, service_name) if cached_instances is empty: // Step 2: 委托NRF发现 nf_profiles = NRF.Discover( target_nf_type = target_nf_type, service_name = service_name, snssai_list = req.headers["3gpp-Sbi-Snssai"], dnn = req.headers["3gpp-Sbi-Dnn"] ) // Step 3: 过滤+缓存 cached_instances = FilterByCapacity(nf_profiles) RouteCache.Update(target_nf_type, service_name, cached_instances) // Step 4: 负载均衡选择 target = LoadBalancer.Select(cached_instances, strategy="round-robin") // Step 5: 转发 return Forward(req, target.endpoint) ``` ### 1.4 Rel-18/19增强 Rel-18对SCP架构进行了多项增强（TS 23.501 Rel-18 Section 6.2.2）： - **多SCP域间路由**：支持跨PLMN或跨网络切片的SCP级联 - **SCP路由策略增强**：支持基于S-NSSAI、DNN、TAI的细粒度路由 - **服务网格集成**：与Istio等服务网格技术的兼容性增强 Rel-19进一步推进： - **5GS_CDIR（5G System Communication Enhancement for Data Reporting）**：优化数据上报的SBA通信路径 - **SBA安全增强**：OAuth 2.0令牌在SCP代理链中的传递机制优化 ### 1.5 部署实战建议 > **坑点1：SCP路由缓存TTL设置** > NRF返回的NF Profile有validity period（默认30秒），SCP的路由缓存必须遵守此TTL，否则会将流量转发到已下线的NF实例。建议TTL设置为NRF返回值的80%，留出缓冲。 > **坑点2：HTTP/2连接复用** > SCP需要维护到NF Producer的长连接池。当NF实例扩缩容时，SCP需要及时更新连接池。建议开启HTTP/2 GOAWAY帧处理，配合NF实例的graceful shutdown。 --- ## 二、NWDAF数据分析体系重构 ### 2.1 NWDAF演进路线 NWDAF（Network Data Analytics Function）是5G-Advanced核心网最关键的智能化组件，其架构在Rel-15到Rel-19经历了根本性重构： | 版本 | 架构变化 | 关键能力 | |------|---------|---------| | Rel-15 | 单一NWDAF实体 | 网络负载分析 | | Rel-16 | 引入ML模型管理 | QoE预测、移动性预测 | | Rel-17 | 拆分AnLF+MTLF | 分析逻辑与模型训练分离 | | Rel-18 | 引入ADRF、增强数据采集 | 闭环自动化、联邦学习支持 | | Rel-19 | 端到端智能闭环 | NWDAF驱动的网络自优化 | ### 2.2 AnLF/MTLF架构原理 Rel-17将原NWDAF拆分为两个逻辑功能（TS 23.288 Section 6.2）： **AnLF（Analytics Logical Function）— 分析逻辑功能** - 接收NF/AF的分析订阅请求 - 调用MTLF训练的ML模型执行推理 - 向消费者提供分析结果（如UE移动性预测、网络拥塞预测） - 支持有状态和无状态两种分析模式 **MTLF（ML Model Training Logical Function）— 模型训练逻辑功能** - 从NF、OAM、ADRF收集训练数据 - 执行ML模型训练和更新 - 通过Nnwdaf_MLModelProvision服务向AnLF分发模型 - 支持联邦学习（Federated Learning）框架  > *图表 2* ### 2.3 ADRF：分析数据仓库 Rel-18引入的ADRF（Analytics Data Repository Function）是NWDAF体系的重要补充（TS 23.288 Rel-18 Section 6.2.3）： - **数据持久化**：存储历史分析数据和训练数据集 - **数据治理**：支持数据保留策略、匿名化处理 - **联邦数据共享**：跨NWDAF实例的数据交换 - **数据质量保证**：数据清洗、异常值处理 ADRF的出现解决了此前NWDAF的一个关键问题：**训练数据的生命周期管理**。Rel-16/17中，ML模型训练所需的数据仅保存在NWDAF内存中，NWDAF重启后需要重新积累训练数据，导致模型冷启动时间长。ADRF提供持久化存储后，新部署的AnLF可以从ADRF快速加载历史数据，将冷启动时间从数小时缩短到分钟级。 ### 2.4 NWDAF分析服务类型 3GPP TS 23.288定义了丰富的分析ID（Analytics ID），覆盖网络运维的各个方面： | Analytics ID | 描述 | 典型消费者 | 引入版本 | |-------------|------|-----------|---------| | load level info | NF负载水平分析 | PCF, AMF | Rel-15 | | NF load | 各NF实例负载 | SMF, AMF | Rel-16 | | network performance | 网络性能统计 | PCF, OAM | Rel-16 | | UE mobility | UE移动性预测 | AMF, PCF, SMF | Rel-16 | | UE communication | UE通信模式预测 | PCF, SMF | Rel-16 | | QoE prediction | 业务体验预测 | PCF, AF | Rel-17 | | disp. area info | UE分布区域分析 | AMF, RAN | Rel-17 | | redundant UE info | 冗余UE组分析 | SMF | Rel-18 | | DN performance | 数据网络性能 | PCF, AF | Rel-18 | | FED learning | 联邦学习协调 | MTLF | Rel-18 | ### 2.5 闭环自动化信令流程 Rel-18/19的NWDAF核心目标是实现闭环（Closed-Loop）自动化。以**网络拥塞自动缓解**为例，完整的信令交互如下（基于TS 23.288 Section 5.2）：  > *图表 3* ### 2.6 部署实战要点 > **坑点1：AnLF/MTLF部署比例** > AnLF与MTLF可以独立伸缩。实际部署中，AnLF通常需要较多实例（因为要处理实时推理请求），而MTLF可以1-2个实例（训练是批处理任务）。推荐比例AnLF:MTLF = 3:1到5:1。 > **坑点2：数据采集粒度** > NWDAF的数据采集频率直接影响分析精度和系统开销。移动性预测建议采集粒度为1-5秒（通过Nnwdaf_DataManagement的事件订阅），NF负载分析建议粒度为30秒。粒度过细会导致信令风暴。 > **坑点3：ADRF存储规划** > ADRF存储需求与网络规模正相关。大型运营商网络建议按100万用户约500GB/天的原始数据量规划。需要配置数据保留策略（如原始数据保留7天，聚合数据保留90天）。 --- ## 三、能量感知核心网架构 ### 3.1 背景：核心网能耗占比不容忽视 业界通常认为无线接入网（RAN）占移动网络总能耗的70-80%，但核心网的能耗占比随着流量增长呈上升趋势。根据Intel与运营商的联合测试数据，云原生5GC在满载状态下，单个SMF实例功耗可达200-400W，AMF实例功耗150-300W。在全网维度，核心网能耗占比可达15-25%，优化空间显著。 ### 3.2 3GPP能量管理架构 3GPP SA5工作组在Rel-18/19中建立了完整的能量效率管理框架： - **TS 28.310**：5G系统能量效率管理框架 - **TS 28.311**：能量效率管理服务和通知 - **TS 28.313**：网络能量节省（NES）管理 核心网能量感知的关键原则是**"在不影响SLA的前提下，最小化激活资源"**。 ### 3.3 核心网节能三大机制 #### 机制一：NF实例动态伸缩（Elastic Scaling） 核心思想：根据实时负载动态调整NF实例数量。 ``` 伸缩决策算法伪代码： func AutoScaleSMF(current_load, time_window): // 获取NWDAF负载预测 prediction = NWDAF.GetAnalytics( analytics_id = "NF load", target_nf = "SMF", time_window = time_window ) active_instances = GetActiveSMFCount() if prediction.peak_load < current_load * 0.3: // 低负载预测：缩容 target_count = max(active_instances - 1, min_instances) for i in range(active_instances - target_count): SMF[oldest].GracefulDrain() // 迁移现有会话 SMF[oldest].DeregisterFromNRF() elif prediction.peak_load > current_load * 0.8: // 高负载预测：扩容 target_count = active_instances + ceil(prediction.peak_load / target_load_per_instance) for i in range(target_count - active_instances): NewSMF = DeploySMFInstance() NewSMF.RegisterToNRF() return target_count ``` **关键参数配置建议**： | 参数 | 推荐值 | 说明 | |------|--------|------| | 缩容冷却时间 | 15-30分钟 | 防止负载波动导致频繁伸缩 | | 扩容触发阈值 | 70-80% CPU | 留出会话迁移时间窗口 | | 缩容触发阈值 | 20-30% CPU | 保留足够余量应对突发 | | 最小实例数 | 2 | 保证高可用 | | 会话迁移超时 | 300秒 | Graceful Drain最大等待时间 | #### 机制二：NF计算资源休眠（Compute Power Management） 当NF实例无法完全缩容时（如保留最小实例数），可以对实例内部计算资源进行节能调度： - **CPU频率调节**：利用DVFS（Dynamic Voltage and Frequency Scaling）降低空闲vCPU频率 - **容器资源限制调整**：动态修改容器CPU/Memory limit - **批处理任务调度**：将非实时任务（如计费数据上报、日志聚合）推迟到低负载时段 #### 机制三：UPF选择性激活 用户面功能（UPF）是核心网中实例数量最多的NF。在低流量时段（如凌晨2:00-6:00），大量边缘UPF处于低负载状态。能量感知机制支持： - **UPF合并**：将多个低负载UPF的流量汇聚到中心UPF - **UPF休眠**：关闭边缘UPF实例，通过DNS/NRF更新路由 - **QoS保障**：合并/休眠操作前，NWDAF预测对时延敏感业务的影响 ### 3.4 NWDAF驱动的能量优化闭环  > *图表 4* ### 3.5 Rel-19能量感知核心网增强 Rel-19在核心网能量管理方面引入了以下新能力（对应Work Item 5GS_EAS，3GPP SP-231005）： - **NF能耗度量标准化**：定义各NF类型的能耗测量模型（Power Model），为NWDAF提供能耗分析基础 - **能量感知会话管理**：SMF在选择UPF时，将能耗作为路由决策因素之一 - **跨域协调节能**：RAN节能决策与核心网NF伸缩联动（如基站休眠时同步缩容关联AMF/SMF） - **NWDAF新Analytics ID**：新增"energy saving"分析类型，预测最优节能操作时间窗口 ### 3.6 实际部署中的注意事项 > **坑点1：NRF缓存一致性** > NF实例缩容后，其他NF的NRF发现结果缓存可能仍指向已关闭实例。必须确保缩容前执行完整的NRF Deregistration，并设置合理的缓存过期时间（建议≤30秒）。 > **坑点2：UPF合并导致的时延增加** > 边缘UPF合并到中心UPF后，端到端时延可能增加10-30ms。需要在PCF中配置差异化的QoS策略，确保URLLC等低时延业务的PDU Session不被迁移。 > **坑点3：定时模式与突发流量的矛盾** > 节能策略通常基于历史流量模式（如凌晨低负载），但突发事件（如大型活动直播）可能导致流量突然飙升。建议NWDAF的预测窗口设置多级告警，在预测偏差超过20%时立即触发扩容。 --- ## 四、三大技术方向的协同关系 上述三个方向并非孤立发展，而是形成了紧密的协同关系：  > *图表 5* **协同逻辑**： 1. **SCP为NWDAF提供高效数据通道**：SCP的间接通信模型减少了NWDAF采集数据时的信令开销，SCP内嵌的路由缓存避免了每次数据采集都查询NRF 2. **NWDAF为能量感知提供决策依据**：AnLF的负载预测和流量模式分析是NF伸缩、UPF休眠的核心输入 3. **能量感知操作通过SBA通知机制传播**：NF实例伸缩后通过NRF Deregistration/Registration通知所有相关NF --- ## 五、关键规范参考索引 | 规范编号 | 标题 | 核心内容 | |---------|------|---------| | TS 23.501 | 5G系统架构 | SBA通信模型定义、SCP架构 | | TS 23.502 | 5G系统流程 | NWDAF相关信令流程 | | TS 23.288 | 5G数据分析架构增强 | NWDAF/AnLF/MTLF/ADRF完整定义 | | TS 29.500 | 5G SBI技术基础 | HTTP/2、RESTful API设计原则 | | TS 29.510 | NRF服务接口 | Nnrf服务定义 | | TS 29.520 | NWDAF服务接口 | Nnwdaf服务定义 | | TS 28.310 | 能量效率管理 | 5G能量管理框架 | | TS 28.313 | 网络节能管理 | NES管理服务 | | TS 33.521 | NWDAF安全保障 | NWDAF SCAS安全要求 | | TR 23.700-87 | 数据处理增强研究 | NDL可行性研究 | --- ## 常见问题 **Q: SCP和传统Diameter信令代理有什么本质区别？** A: 核心区别在于代理粒度和协议层。Diameter代理工作在Diameter协议层，主要做消息路由和中继；SCP工作在HTTP/2应用层，不仅做消息路由，还承担服务发现委托、负载均衡、安全认证、流量监控等功能。SCP理解SBI语义（如解析3gpp-Sbi-*头部），能做更智能的路由决策。从部署模式看，Diameter代理通常是一对一的中继，而SCP可以作为整个NF集合的通信枢纽，实现集中化的流量管理。 **Q: AnLF和MTLF必须部署在不同物理节点上吗？** A: 不必须。3GPP TS 23.288将AnLF和MTLF定义为逻辑功能，它们可以共部署在同一个物理节点上（小规模网络推荐），也可以分别部署（大规模运营商推荐）。分离部署的核心优势是：AnLF可以水平扩展以应对高并发的推理请求，而MTLF可以配置GPU等加速硬件专注于模型训练。两种部署模式通过Nnwdaf_MLModelProvision服务接口统一交互。 **Q: 在现网中如何从Rel-15/16核心网平滑升级到Rel-18/19架构？** A: 推荐分阶段演进策略： - **Phase 1**：部署SCP，将现有NF从模型A迁移到模型D（NF仍直查NRF，但通过SCP通信）。此阶段NF改动最小，只需配置SCP地址 - **Phase 2**：部署NWDAF AnLF实例，先接入移动性预测和NF负载分析两个Analytics ID，验证数据采集和分析精度 - **Phase 3**：部署MTLF和ADRF，启用ML模型训练，逐步增加分析维度 - **Phase 4**：开启能量感知功能，从SMF/AMF伸缩开始，逐步扩展到UPF合并 **Q: NWDAF的ML模型如何避免"灾难性遗忘"？** A: 这是NWDAF在长期运行中的关键问题。当网络拓扑或流量模式发生变化时（如新基站开通、大型活动），新训练的ML模型可能在新模式上表现优异但在旧模式上退化。TS 23.288 Rel-18引入了ML模型版本管理机制：MTLF通过Nnwdaf_MLModelProvision分发模型时携带模型版本号和适用条件（Applicability Criteria），AnLF可以根据输入数据的特征选择合适的模型版本。此外，ADRF中的历史数据可以用于回退训练，确保旧模型能力不丢失。 **Q: 核心网能量感知功能需要终端配合吗？** A: 核心网侧的NF伸缩和UPF合并对终端是透明的——PDU Session迁移通过SMF/UPF间的信令完成，终端感知不到。但有两种场景需要终端配合：一是跨AMF的Registration迁移（Rel-19引入的AMF间UE上下文迁移），需要终端发起Mobility Registration Update；二是UPF合并后PDU Session的IP地址可能变化，需要通过IPv6多前缀或双栈机制保证业务连续性。总体而言，核心网节能操作对终端的要求很低，这是其相对于RAN节能（需要终端测量上报配合）的重要优势。 --- > 本文由「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 等场景全覆盖。