# 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引入的关键增强包括： | SBA演进特性 | Rel-15/16 | Rel-18 | Rel-19 | |---|---|---|---| | 服务发现 | NRF中心化 | NRF + 本地缓存 | 分布式NRF联邦 + 本地Mesh | | 服务通信 | HTTP/2直连 | HTTP/2 + Service Mesh | HTTP/3(QUIC) + gRPC可选 | | 服务治理 | 手动配置 | 基于策略 | **Intent-Driven意图驱动** | | NF生命周期 | 独立管理 | 容器编排集成 | **NF即代码（NFaaS）** | | 可观测性 | 基础日志 | 分布式追踪 | **AI驱动的主动感知** | ### 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定义的意图格式）： ```yaml 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之间的长连接效率**。 | 特性 | HTTP/2 (当前) | HTTP/3/QUIC (Rel-19研究) | |---|---|---| | 传输层 | TCP | UDP | | 队头阻塞 | 存在（TCP级别） | 不存在（独立流） | | 连接建立 | TCP 3-way + TLS 1.3 | 0-RTT / 1-RTT | | 切换恢复 | 慢（TCP重传） | 快（Connection ID迁移） | | 多路复用 | Stream级别 | 更细粒度的QUIC Stream | 对于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的可行性。其核心设计原则如下： | 设计原则 | 说明 | 对应的技术机制 | |---|---|---| | 数据与逻辑解耦 | NF不再直接管理数据存储 | 数据访问通过统一API | | 联邦数据管理 | 跨PLMN/跨域数据查询 | Federated Query Engine | | 数据虚拟化 | 屏蔽数据源异构性 | Common Data Service (CDS) | | AI/ML就绪 | 统一数据为AI训练服务 | 特征工程、数据管道 | | 数据治理 | GDPR合规、访问控制 | 策略驱动的数据访问授权 | ### 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$：状态操作功耗系数（会话建立/释放、切换等） | NF类型 | 空闲功耗占比 | 负载功耗占比 | 状态操作功耗占比 | |---|---|---|---| | AMF | 40% | 35% | 25% | | SMF | 35% | 45% | 20% | | UPF | 25% | 65% | 10% | | NWDAF | 50% | 40% | 10% | | PCF | 55% | 35% | 10% | **关键洞察**：AMF、NWDAF、PCF等NF的空闲功耗占比高达40%-55%，这意味着**弹性缩放（Scale to Zero）是最大的节能机会**。 ### 3.2 3GPP能量感知标准框架 3GPP在TS 28.310（Energy Efficiency of 5G）中定义了核心网能量管理的标准框架： **能量感知管理的四层模型**：  > *图表 4* **TS 28.310定义的核心节能策略**： | 策略名称 | 触发条件 | 动作 | 预期节能效果 | |---|---|---|---| | NF实例缩放 | 负载 < 阈值 | 减少NF副本数 | 20%-40% | | NF实例休眠 | 负载 = 0 持续T秒 | 容器冻结/停止 | 40%-60% | | NF合并迁移 | 多区域低负载 | NF实例合并到少数节点 | 30%-50% | | UPF重定位 | 用户面流量低谷 | UPF下沉→汇聚点回收 | 25%-35% | | SMF池化调整 | 会话数下降 | SMF pool收缩 | 15%-25% | ### 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实例的缩放操作： ```python # 伪代码：预测性缩放决策 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%核心网节能方案，核心技术栈包括： | 技术层面 | 具体措施 | 贡献节能比例 | |---|---|---| | 硬件层 | COTS服务器替代专用设备 | 15%-20% | | 虚拟化层 | 容器化替代VM，K8s细粒度调度 | 15%-20% | | 应用层 | 云原生NF实现，无状态设计 | 10%-15% | | 编排层 | AI驱动的弹性缩放 + 休眠策略 | 10%-15% | | 平台层 | 水平Telco Cloud统一资源池 | 5%-10% | **关键架构决策**：DT采用了**水平电信云（Horizontal Telco Cloud）**架构，将RAN、Core、BSS运行在统一的云基础设施上。这打破了传统"烟囱式"专有硬件部署模式，使得资源共享和弹性调度成为可能。 --- ## 四、三大技术方向的协同效应 SBA演进、NDL和能量感知核心网并非独立的技术路线，它们之间存在深度的协同关系： | 协同点 | SBA演进 | NDL | 能量感知 | |---|---|---|---| | 数据基础 | SBI接口产生海量服务调用数据 | NDL统一采集和治理这些数据 | 能量感知决策依赖NDL提供的分析 | | 决策执行 | Intent驱动的SBA策略下发 | NDL为NWDAF提供训练数据 | NWDAF分析驱动弹性缩放 | | 反馈闭环 | NF执行结果反馈给Intent系统 | NDL记录执行结果 | 能耗变化数据回流NDL |  > *图表 5* 这个闭环系统的目标是实现**L4级自智网络**（根据TM Forum定义），即网络在有限人工干预下，能够自动感知、分析、决策和执行。 --- ## 五、部署实战建议 ### 5.1 演进路线图 | 阶段 | 时间窗口 | 核心任务 | 依赖 | |---|---|---|---| | Phase 1 | 2026 Q1-Q2 | SBA基础增强：NRF联邦、Service Mesh引入 | K8s集群就绪 | | Phase 2 | 2026 Q3-Q4 | NWDAF增强 + NDL概念验证 | Phase 1完成 | | Phase 3 | 2027 Q1-Q2 | Intent管理试点 + 能量感知编排 | NWDAF数据管道就绪 | | Phase 4 | 2027 Q3-Q4 | 全自动化闭环 + AI驱动运维 | Phase 3稳定运行 | ### 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弹性缩放参数建议 | 参数 | AMF | SMF | UPF | NWDAF | PCF | |---|---|---|---|---|---| | 缩放冷却时间 | 120s | 90s | 60s | 180s | 150s | | 最小实例数 | 2 | 2 | 1 | 1 | 1 | | 最大实例数 | 32 | 16 | 64 | 8 | 4 | | 单实例容量(QPS) | 10K | 50K | 100K | 5K | 20K | | 休眠触发阈值 | <5% load 持续300s | <5% load 持续300s | <3% load 持续600s | <10% load 持续180s | <10% load 持续300s | | 冷启动时间 | 3-5s | 2-4s | 1-3s | 5-10s | 3-5s | ### 相关3GPP规范速查表 | 规范编号 | 标题 | 关键内容 | |---|---|---| | TS 23.501 | 5G系统架构 | SBA基础架构定义 | | TS 23.502 | 5G系统流程 | NF间信令交互流程 | | TS 28.310 | 5G能量效率管理 | 节能策略和管理框架 | | TS 28.312 | 意图驱动管理 | Intent模型和接口定义 | | TS 29.500 | SBI技术基础 | HTTP/2 REST API设计原则 | | TS 29.510 | NRF服务接口 | 服务发现和注册接口 | | TR 23.700-86 | NDL可行性研究 | 网络数据层架构研究 | | TR 23.700-80 | AI/ML服务支持 | 核心网AI/ML框架研究 | | TS 23.288 | NWDAF架构和接口 | 网络数据分析功能定义 | --- ## 常见问题 **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 等场景全覆盖。