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通信）

图表 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经历了根本性重构：

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），覆盖网络运维的各个方面：

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

关键参数配置建议：

机制二：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

五、关键规范参考索引

常见问题

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 等场景全覆盖。