5G-Advanced核心网架构演进原理深度解析

从3GPP Release 18到Release 19，5G核心网经历了自Rel-15以来最深刻的架构变革。这不是简单的功能叠加，而是三股力量的交汇——服务化架构（SBA）的深度重构、网络数据层（NDL）的范式转移、以及能量感知核心网的系统工程。本文将从协议层原理出发，剖析这三大技术方向的设计哲学与工程实现。

一、SBA演进的三个阶段论

1.1 从"服务化接口"到"服务化网格"

5G核心网在Rel-15引入的SBA架构，本质上是将传统网元拆解为通过RESTful API（HTTP/2）通信的微服务网络功能（NF）。但Rel-15/16的SBA存在一个核心矛盾：NRF作为中心化的服务发现实体，在超大规模部署中成为瓶颈。

Rel-18/19对SBA的演进可以用"去中心化 + 意图驱动"概括：

传统SBA (Rel-15/16):
NF_A → NRF(服务发现) → NF_B
       ↑ 单点瓶颈

演进SBA (Rel-18/19):
NF_A ↔ Service Mesh (Sidecar Proxy) ↔ NF_B
         ↕ 本地服务发现缓存
         ↕ 意图策略注入
         ↕ 可观测性采集

Rel-19引入的关键增强包括：

1.2 Intent-Driven Networking的协议原理

3GPP TS 28.312定义的意图驱动管理（Intent Driven Management）是Rel-19最具革命性的核心网管理范式。其核心思想是：运维人员只需声明"期望的网络状态"，而非具体的配置命令。

意图模型采用分层结构（TS 28.312 V19.x）：

Intent (意图)
  ├── IntentExpectation (期望)
  │     ├── Target (目标对象)
  │     ├── Context (上下文条件)
  │     └── ExpectationTarget (量化指标)
  └── IntentReport (意图执行报告)
        ├── FulfillmentStatus (满足状态)
        └── ViolationReport (违规报告)

关键信令流程——意图生命周期管理的时序如下：

图表 1

Intent声明的伪代码示例（基于TS 28.312定义的意图格式）：

Intent:
  name: "Slice_QoS_Guarantee_For_URLLC"
  target:
    type: NetworkSlice
    sliceId: "SST:1 SD:010203"
  expectations:
    - type: QoS
      metric: "latency < 5ms (99.999%)"
      context:
        timeWindow: "business_hours"
        geography: "factory_floor_zone_A"
    - type: Reliability
      metric: "availability > 99.999%"
  priority: HIGH
  validity:
    start: "2026-01-01T00:00:00Z"
    end: "2026-12-31T23:59:59Z"

Intent管理系统的核心算法是一个闭环控制回路：

$$ u(t) = K_p \cdot e(t) + K_i \cdot \int_0^t e(\tau) d\tau + K_d \cdot \frac{de(t)}{dt} $$

其中 $e(t) = r(t) - y(t)$ 是意图目标值与实际测量值的偏差，$u(t)$ 是下发给NF的配置调整指令。这个PID控制器的参数由NWDAF根据历史数据动态调优。

1.3 服务通信协议演进：HTTP/2到HTTP/3

Rel-19开始研究在SBA接口中引入HTTP/3（基于QUIC）。这不是简单的协议升级，而是解决了一个关键问题——核心网NF之间的长连接效率。

对于SBA中高频的NF间服务调用（如AMF→SMF的PDU会话建立），HTTP/3的0-RTT恢复能力可以将切换后的服务恢复时间降低30%-50%。

二、网络数据层（NDL）：数据范式的范式转移

2.1 NDL要解决的根本问题

在5G核心网中，数据散落在至少8类不同的存储实体中：

图表 2

3GPP SA2在Rel-18/19期间通过TR 23.700-86等研究项目，系统性地探讨了NDL的可行性。其核心设计原则如下：

2.2 NDL的核心架构组件

NDL的架构可分解为四个功能层：

第一层：数据采集与接入层（Data Ingestion）

负责从各类NF和OAM系统收集原始数据。关键技术点：

• 统一数据模型：基于TS 29.571定义的Common Data Type，扩展为NDL统一Schema
• 实时流式接入：通过Nnwdaf_EventsSubscription的扩展接口，支持高吞吐事件流
• 批量数据同步：利用UDR（TS 29.505）的数据暴露能力，做定期批量快照

第二层：数据存储与管理层（Data Storage & Management）

• 分布式数据湖：支持结构化（SQL）、半结构化（JSON）、非结构化（日志）数据的统一存储
• 数据分区策略：按用户标识（SUPI/SUPI）、时间窗口、地理区域进行数据分区
• 数据生命周期管理：热数据（实时分析）→ 温数据（历史查询）→ 冷数据（合规存档）

第三层：数据处理与分析层（Data Processing）

原始事件流 → [数据清洗] → [特征提取] → [聚合计算] → [分析输出]
                  ↓              ↓             ↓
              去重/去噪      ML Feature    统计/预测
              格式标准化     Engineering   模型推理

第四层：数据服务暴露层（Data Exposure）

通过标准化的SBI接口对外提供数据服务：

• Nndl_DataAccess：同步数据查询
• Nndl_StreamSubscription：异步数据流订阅
• Nndl_AnalyticsRequest：分析结果请求
• Nndl_FederatedQuery：跨域联邦查询

2.3 NDL与NWDAF的协同机制

NDL不是要替代NWDAF，而是为NWDAF提供"弹药"。其协同关系如下：

图表 3

关键改进点：在传统架构中，NWDAF需要分别从各个NF收集数据（通过Nnf_EventExposure等接口），这导致了：

1. 数据孤岛：NWDAF只获取了部分NF的数据
2. 数据不一致：各NF数据格式和时间戳不统一
3. 扩展性差：新增数据源需要修改NWDAF的采集逻辑

NDL通过统一数据抽象，使NWDAF只需对接一个标准化的数据服务接口，而非N个NF的Event Exposure接口。

2.4 NDL的数据治理与隐私保护

NDL引入了属性基访问控制（ABAC）机制：

$$ Access(NF_i, Data_j, Op_k) = \begin{cases} \text{Allow} & \text{if } Policy(NF_i.\text{role}, Data_j.\text{sensitivity}, Op_k) = \text{true} \ \text{Deny} & \text{otherwise} \end{cases} $$

具体实现包括： - 数据脱敏：SUPI/SUCI等敏感字段在进入NDL时做k-匿名化处理 - 差分隐私：对统计查询添加拉普拉斯噪声 $\mathcal{L}(0, \Delta f / \epsilon)$，其中$\epsilon$是隐私预算 - 联邦学习：跨PLMN的数据分析不直接传输原始数据，而是交换模型梯度

三、能量感知核心网：从"绿色口号"到"系统工程"

3.1 核心网能耗问题的量化分析

传统讨论5G能耗往往聚焦于无线接入网（RAN），但核心网的能耗占比正在快速上升。根据Deutsche Telekom 2026年2月发布的实测数据，其通过云原生架构改造，在5G核心网实现了最高65%的节能。这一数据揭示了核心网节能的巨大潜力。

核心网NF的能耗模型可以简化为：

$$ P_{NF}(t) = P_{idle} + \alpha \cdot Load(t) + \beta \cdot State_Ops(t) $$

其中： - $P_{idle}$：NF空闲功耗（容器运行但无业务） - $\alpha$：业务负载功耗系数（每单位QPS的功耗增量） - $\beta$：状态操作功耗系数（会话建立/释放、切换等）

关键洞察：AMF、NWDAF、PCF等NF的空闲功耗占比高达40%-55%，这意味着弹性缩放（Scale to Zero）是最大的节能机会。

3.2 3GPP能量感知标准框架

3GPP在TS 28.310（Energy Efficiency of 5G）中定义了核心网能量管理的标准框架：

能量感知管理的四层模型：

图表 4

TS 28.310定义的核心节能策略：

3.3 能量感知的核心网架构设计

基于云原生核心网的最佳实践（参考DT/Mavenir联合方案），能量感知核心网包含以下核心组件：

（1）能耗感知编排器（Energy-Aware Orchestrator）

在传统NFV MANO（ETSIGS NFV 002）基础上，增加能耗维度的编排决策：

传统编排决策函数:
  Score = w1 * latency + w2 * cost + w3 * reliability

能量感知编排决策函数:
  Score = w1 * latency + w2 * cost + w3 * reliability + w4 * energy_efficiency

  其中:
  energy_efficiency = Throughput(per TPS) / Power(per Watt)

编排器的核心决策算法是一个多目标优化问题：

$$ \min_{x \in \mathcal{X}} \left[ f_1(x) = \sum_{i} P_{NF_i}(x), \quad f_2(x) = \max_{(s,d)} D(s,d|x), \quad f_3(x) = C(x) \right] $$

其中$x$是NF部署方案，$P$是总功耗，$D$是端到端时延，$C$是运营成本。使用加权和法或Pareto前沿搜索求解。

（2）弹性NF实例管理（Elastic NF Scaling）

核心是预测性缩放——基于NWDAF提供的流量预测分析，提前进行NF实例的缩放操作：

# 伪代码：预测性缩放决策
def predictive_scaling(nwdaf_analytics, current_capacity):
    # 获取未来15分钟的流量预测
    predicted_load = nwdaf_analytics.get_load_prediction(
        horizon="15min", 
        confidence=0.95
    )

    # 计算所需NF实例数（含安全裕度）
    required_instances = ceil(
        predicted_load.peak_qps / PER_INSTANCE_CAPACITY * SAFETY_MARGIN
    )

    # 计算当前实例数
    current_instances = current_capacity.active_count

    if required_instances < current_instances:
        # 缩容：逐步释放，确保会话优雅迁移
        instances_to_remove = current_instances - required_instances
        for inst in select_idle_instances(instances_to_remove):
            drain_sessions(inst)  # 优雅排空会话
            sleep(inst)           # 进入休眠
            report_energy_saving()  # 上报节能效果

    elif required_instances > current_instances:
        # 扩容：优先唤醒休眠实例
        wake_from_sleep(required_instances - current_instances)

（3）UPF动态重定位（Dynamic UPF Relocation for Energy Saving）

UPF是核心网中功耗占比最大的NF（尤其在高流量场景）。节能策略的核心是在流量低谷时回收边缘UPF实例：

• 白天高峰：边缘站点部署轻量UPF，就近处理流量
• 夜间低谷：边缘UPF休眠，流量回传至区域中心UPF
• 切换触发：NWDAF检测到某区域流量低于阈值，触发UPF重定位

UPF重定位的信令流程（基于TS 23.502 Section 4.23）：

NWDAF → SMF: AnalyticsNotify(UPF_Energy_Optimization_Suggestion)
SMF → UPF_old: 发送End Marker
SMF → UPF_new: 建立新PFCP Session
UPF_new ↔ UPF_old: 数据转发
SMF → AMF: N1N2Transfer(UPF变更通知)
UE ← → UPF_new: 后续数据通过新UPF
SMF → UPF_old: 释放PFCP Session → 容器休眠

3.4 Deutsche Telekom案例的技术解构

DT在2026年公布的65%核心网节能方案，核心技术栈包括：

关键架构决策：DT采用了水平电信云（Horizontal Telco Cloud）架构，将RAN、Core、BSS运行在统一的云基础设施上。这打破了传统"烟囱式"专有硬件部署模式，使得资源共享和弹性调度成为可能。

四、三大技术方向的协同效应

SBA演进、NDL和能量感知核心网并非独立的技术路线，它们之间存在深度的协同关系：

图表 5

这个闭环系统的目标是实现L4级自智网络（根据TM Forum定义），即网络在有限人工干预下，能够自动感知、分析、决策和执行。

五、部署实战建议

5.1 演进路线图

5.2 实际部署中的"坑"

坑1：NRF联邦的一致性问题

在多区域NRF联邦部署中，服务实例的注册/注销信息在NRF之间的同步存在延迟（通常100ms-1s），可能导致：

• 刚注销的NF仍然被调用（引起HTTP 503）
• 新注册的NF未被发现（负载不均衡）

解决方案：在Service Mesh层实现本地服务发现缓存，配合健康检查探针，TTL设置建议不超过5秒。

坑2：NF缩放到零后的"冷启动"问题

当NF实例被完全缩放到零后，新业务请求到来时需要从冷状态启动，可能引入数秒级延迟。

解决方案： - 保留最小1个"温"实例（低功耗待命状态） - 使用NWDAF预测性扩容，在流量上升前预热 - 对于SLA敏感场景，设置minReplicas: 1硬约束

坑3：UPF重定位过程中的包丢失

边缘UPF休眠触发的UPF重定位，在切换过程中可能导致短暂丢包。

解决方案： - 严格遵循TS 23.502 Section 4.23定义的UPF重定位流程 - 在End Marker机制基础上，增加50ms的数据转发缓冲 - 重定位窗口选择在业务低峰（如凌晨2:00-5:00）

坑4：NDL数据一致性 vs 实时性的权衡

NDL的数据聚合需要跨多个NF收集数据，在CAP定理约束下，强一致性和低延迟无法同时保证。

解决方案： - 对实时性要求高的场景（如负载均衡决策）：采用最终一致性模型，容忍短暂不一致 - 对一致性要求高的场景（如计费数据）：采用同步确认机制，牺牲部分延迟 - 数据分级：热数据（秒级同步）、温数据（分钟级）、冷数据（小时级）

六、关键技术参数参考

核心网NF弹性缩放参数建议

相关3GPP规范速查表

常见问题

Q: Intent驱动和传统策略管理的本质区别是什么？

A: 传统策略管理（如PCF下发的QoS策略）是命令式的——明确指定"做什么"（如"给这个会话分配5Mbps带宽"）。Intent驱动是声明式的——只声明"想要什么结果"（如"这个切片的用户体验评分不低于4.5分"），由系统自动推导具体的策略组合。这类似于编程语言中"汇编语言"vs"高级语言"的区别。从工程实现上，Intent需要一个翻译层将声明式意图分解为具体的策略规则，这个翻译层依赖NWDAF的分析能力和NDL的数据支撑。

Q: NDL是替代UDR还是叠加在UDR之上？

A: NDL不替代任何现有NF的数据存储功能。NDL是一个数据抽象层，类似于数据库中间件。UDR仍然负责用户签约数据的权威存储，NDL通过UDR的数据暴露接口获取数据，并与其他数据源的数据进行关联和治理。类比IT架构中的"数据湖"概念——各业务系统（NF）仍然有自己的数据库（UDR等），NDL在上面构建统一的数据湖，提供跨系统的数据服务和分析能力。

Q: 在现网中如何开始部署能量感知核心网？

A: 建议分三步走。第一步（1-3个月）：部署能耗监控系统，在K8s集群中启用Prometheus + 自定义功耗采集，建立NF级功耗基线。第二步（3-6个月）：实现基于规则的弹性缩放（HPA/VPA），配合业务低谷时段的主动休眠策略。第三步（6-12个月）：引入NWDAF流量预测能力，升级为AI驱动的预测性缩放。关键是第一步的监控基线——没有准确的功耗数据，后续所有优化都是盲目的。

Q: Release 19的核心网特性对终端用户有什么直接影响？

A: 对终端用户的直接影响主要体现在三个方面。第一：Intent驱动管理使网络切片的服务质量更加稳定（减少人为配置错误导致的质量波动）。第二：能量感知架构在流量低谷时可能触发UPF重定位，理论上会增加几毫秒到几十毫秒的额外时延（但在实际部署中通常选择在用户无感知的凌晨时段执行）。第三：NDL支撑的AI分析能力使网络能更快速地适应用户行为变化，例如大型集会场景下的快速容量调整。

Q: SBA从HTTP/2迁移到HTTP/3需要改哪些接口？

A: Rel-19阶段HTTP/3在SBA中仍处于研究阶段，尚未正式标准化。从技术准备角度，需要修改的层面包括：TS 29.500（SBI通用原则）中的传输协议定义、各NF服务接口（Nsmf、Namf等）的编解码层适配、以及NRF的服务发现协议扩展。对于运营商和设备商，建议在Rel-19 Stage 3完成后开始原型验证，重点关注QUIC在NF间通信中的性能表现，特别是0-RTT恢复对切换场景的增益。

本文由「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 等场景全覆盖。