# 5G-Advanced核心网三大演进方向深度解析：SBA架构增强、NDL数据层与能量感知网络 ## 引言 5G核心网（5GC）自Rel-15首次引入基于服务的架构（SBA）以来，已经历了四个大版本的迭代。进入5G-Advanced时代（Rel-18/19），核心网的演进不再局限于简单的功能叠加，而是从三个根本性维度展开重构：**架构层的SBA服务化增强**、**数据层的NDL统一数据框架**、以及**运维层的能量感知核心网**。这三个方向分别解决了5GC在**弹性伸缩**、**数据资产化**和**绿色可持续**三个维度上的根本性挑战。 本文从协议层原理出发，结合3GPP TS 23.501、TS 29.500、TS 23.519、TR 23.700-85等核心规范，深度解析这三大演进方向的技术本质。 --- ## 一、SBA架构增强：从"连通"到"智联" ### 1.1 传统SBA的瓶颈 Rel-15定义的SBA架构（TS 23.501）采用HTTP/2 RESTful接口实现NF（网络功能）间的服务化通信。其核心模型是**NF Producer/NF Consumer**直连模式——Consumer通过NRF（NF Repository Function）发现Producer，然后直接发起HTTP/2请求。 这一模型在早期部署中暴露出三大问题：  > *图表 1* | 瓶颈维度 | 具体表现 | 影响 | |----------|---------|------| | **连接规模** | N个NF间需O(N²)个HTTP/2连接 | 大规模部署时连接数爆炸 | | **路由灵活性** | Consumer硬编码路由逻辑 | 新增NF实例需修改Consumer配置 | | **安全边界** | 所有NF间直接暴露API | 安全攻击面过大 | | **可观测性** | 缺乏统一流量采集点 | 难以实现端到端追踪 | ### 1.2 SCP间接通信模型（Rel-16引入，Rel-18/19增强） 为解决上述问题，3GPP从Rel-16开始引入**SCP（Service Communication Proxy）**，定义了两种间接通信模式（TS 29.500 Section 6.10）： **模式A：无委托发现（Indirect Communication without Delegated Discovery）** Consumer仍通过NRF发现Producer，但所有请求经由SCP转发： ``` Consumer → SCP（转发） → Producer ↑ | └── NRF（发现）────────┘ ``` **模式B：委托发现（Indirect Communication with Delegated Discovery）** Consumer将发现和选择全部委托给SCP，这是Rel-18/19重点增强的模式： ``` Consumer → SCP（发现+选择+转发） → Producer ``` 委托发现模式下，SCP的核心处理流程伪代码如下： ```python def scp_handle_request(consumer_req): # Step 1: 解析目标Service Name service_name = consumer_req.headers["3gpp-Sbi-Target-Nf-Id"] # Step 2: 向NRF查询可用Producer实例 nf_instances = query_nrf(service_name, target_nf_type=consumer_req.target_nf_type, preferred_locality=consumer_req.locality) # Step 3: 基于策略执行实例选择（负载均衡/亲和性/容量） selected_instance = select_instance(nf_instances, policy=load_balancing_policy) # Step 4: 转发请求到选定的Producer response = forward_request(selected_instance.uri, consumer_req) # Step 5: 返回响应 return response ``` ### 1.3 Rel-18/19 SBA增强要点 Rel-18和Rel-19对SBA架构的增强主要体现在以下维度： | 增强项 | Rel-18 | Rel-19 | 规范依据 | |--------|--------|--------|---------| | **SCP路由增强** | 支持基于Slice的路由 | 支持Intent-driven路由 | TS 29.500 | | **NF集（NF Set）** | 支持NF Set级别的弹性伸缩 | 增强跨DC的NF Set协调 | TS 23.501 | | **API版本协商** | HTTP/2多版本共存机制 | API版本自动迁移 | TS 29.500 | | **服务化授权** | 基于OAuth 2.0的NF间授权 | 增强细粒度API授权 | TS 33.511 | | **批量订阅/通知** | 支持多个NF一次性订阅 | 增强事件过滤和聚合 | TS 29.510 | ### 1.4 SBA演进的整体架构  > *图表 2* **SCP本质上扮演了云原生架构中Service Mesh（如Istio）的角色**，但其设计完全遵循3GPP SBI规范，而非通用云原生框架。这一设计选择意味着运营商可以不依赖Kubernetes Service Mesh，在裸金属或VM部署中同样获得流量治理能力。 ### 1.5 实战部署考量 **坑1：SCP成为单点故障** SCP集中转发所有NF间流量，其可用性直接决定网络整体可用性。建议： - 部署SCP集群，至少3个实例跨AZ分布 - SCP间通过一致性哈希同步会话状态 - 监控SCP的HTTP/2连接池利用率，阈值建议≤70% **坑2：委托发现模式下的NRF压力** 模式B将所有发现请求集中在SCP→NRF链路。在高并发场景（如大规模注册风暴），NRF可能成为瓶颈： - 启用NRF本地缓存（SCP侧缓存NF Profile），TTL建议30-60秒 - NRF按Slice分区部署 - 监控NRF的`Nnrf_NFDiscovery`响应时延，P99应<50ms --- ## 二、NDL网络数据层：5GC的数据中台化 ### 2.1 NDL的设计动机 传统5GC中，数据分散在UDM（签约数据）、UDR（结构化数据）、UDSF（非结构化数据）、PCF（策略数据）、NWDAF（分析数据）等多个NF中。这导致： - **数据孤岛**：各NF数据模型不统一，跨NF数据关联困难 - **分析瓶颈**：NWDAF需逐个从多个NF采集数据，接口复杂 - **外部暴露困难**：第三方应用难以获取统一的网络数据视图 NDL（Network Data Layer）在Rel-18引入（TS 23.519 Stage 2 / TS 29.519 Stage 3），旨在构建一个**统一的数据存储、查询和暴露框架**。 ### 2.2 NDL架构与核心概念  > *图表 3* NDL定义了三类核心服务操作（TS 29.519）： | 操作 | HTTP方法 | URI模式 | 功能说明 | |------|---------|---------|---------| | **Nndl_DataManagement_Query** | GET | `/ndl/v1/data/{dataKey}` | 按条件查询数据 | | **Nndl_DataManagement_Create/Update** | POST/PUT | `/ndl/v1/data` | 创建/更新数据记录 | | **Nndl_DataManagement_Subscribe/Notify** | POST/SUBSCRIBE | `/ndl/v1/subscriptions` | 订阅数据变更通知 | ### 2.3 NDL数据模型原理 NDL的核心抽象是**Data Object**，它统一了不同来源的数据表示： ```json { "dataObjectId": "ndladrift://5gc/slice/460-01/ue-mobility/202605171000", "dataType": "ueMobilityAnalytics", "sourceNF": "NWDAF", "dataScope": { "sNssai": {"sst": 1, "sd": "010203"}, "plmnId": {"mcc": "460", "mnc": "01"}, "timeRange": {"startTime": "2026-05-17T10:00:00Z", "endTime": "2026-05-17T11:00:00Z"} }, "dataContent": { "ueCount": 12580, "avgSpeed": 15.3, "handoverRate": 0.023, "cellLoadDistribution": [ {"cellId": "460-01-A1", "load": 0.72}, {"cellId": "460-01-A2", "load": 0.45} ] }, "metadata": { "validity": 3600, "confidence": 0.95, "collectionTimestamp": "2026-05-17T10:05:00Z" } } ``` 这一模型的精妙之处在于将**数据内容（dataContent）**与**数据范围（dataScope）**分离。Consumer可以只关心dataScope（"我要某Slice某时间段的数据"），而不需要知道数据存储在哪个NF中——这正是**数据虚拟化**的核心思想。 ### 2.4 NDL与NWDAF的协同 NDL不是替代NWDAF，而是为NWDAF提供更高效的数据底座。其协作关系如下：  > *图表 4* ### 2.5 NDL的API设计哲学 NDL API遵循3GPP SBI统一设计原则（TS 29.501）： 1. **RESTful资源模型**：每个Data Object对应一个URI资源 2. **HTTP/2传输**：利用多路复用降低延迟 3. **JSON Schema验证**：请求/响应体使用OpenAPI 3.0定义 4. **事件驱动**：支持数据变更的订阅/通知机制 5. **分页与过滤**：大数据集查询支持`limit`/`offset`和属性过滤 **关键对比**： | 维度 | 传统方式（无NDL） | NDL方式 | |------|-------------------|---------| | 数据获取 | NWDAF逐个调用Nnrf→Namf→Nsmf→Nudr | 一次Nndl_Query获取聚合视图 | | 数据模型 | 每个NF定义自己的数据模型 | 统一Data Object模型 | | 数据订阅 | 分别向多个NF订阅 | 统一向NDL订阅，NDL内部聚合 | | 扩展性 | 新增数据源需修改Consumer逻辑 | 新增数据源只需注册到NDL | | 外部暴露 | 需逐个通过NEF暴露 | NDL提供统一暴露接口 | --- ## 三、能量感知核心网：从"能效"到"意图驱动的节能" ### 3.1 核心网能耗现状 根据Ericsson和Nokia的白皮书数据，核心网（含云基础设施和支撑系统）在移动网络总能耗中占比约**15-20%**。虽然绝对占比不如RAN（70-80%），但核心网的节能具有独特价值： - **核心网7×24运行**：无"深夜关站"的自然节能窗口 - **虚拟化弹性**：NFV/云原生架构为节能提供了天然的伸缩能力 - **AI驱动**：核心网控制面流量模式高度可预测，适合ML驱动的节能 ### 3.2 3GPP节能标准框架 3GPP在Rel-18/19中定义了系统性的节能框架： | 规范 | 内容 | 阶段 | |------|------|------| | **TR 23.700-85** | Study on Energy Saving for 5GS | Rel-18 Study Item | | **TS 28.310** | Energy Efficiency Management | Rel-18 | | **TS 23.501** (Rel-19 update) | 5GS能量感知架构定义 | Rel-19 | | **TR 128.913** | EE KPI新方面研究 | Rel-18 | ### 3.3 核心网节能三大机制 #### 机制1：NF实例弹性伸缩（NF Scaling） 核心思路是根据负载动态调整NF实例数量： $$P_{total} = \sum_{i=1}^{N_{active}} P_{base}^{(i)} + P_{load}^{(i)}$$ 其中 $P_{base}^{(i)}$ 为第 $i$ 个NF实例的基准功耗，$P_{load}^{(i)}$ 为负载相关功耗。节能目标是： $$\min N_{active} \quad s.t. \quad \text{SLA满足率} \geq 99.99\%$$ 具体伸缩策略： ```python def nf_scaling_decision(current_load, historical_pattern): """ 基于负载预测的NF伸缩决策 """ # 基于历史模式预测未来15分钟负载 predicted_load = ml_predict(historical_pattern, horizon=900) # 计算所需最小实例数 capacity_per_instance = get_instance_capacity() # 如AMF: 50万UE/实例 required_instances = math.ceil(predicted_load / (capacity_per_instance * safety_factor)) # 考虑伸缩冷却时间（防止振荡） if abs(required_instances - current_instance_count) <= 1: if time_since_last_scaling < cooldown_period: return "HOLD" # 避免频繁伸缩 # 选择缩容目标实例（优先选择低负载实例） if required_instances < current_instance_count: target = select_lowest_load_instance() # 迁移该实例上的所有会话 drain_instance(target) return "SCALE_IN" return "SCALE_OUT" if required_instances > current_instance_count else "HOLD" ``` #### 机制2：UPF节能重定位 UPF是核心网中资源消耗最大的NF。节能重定位的核心思想： **高峰时段**：UPF分布式部署到边缘（低延迟，高吞吐） **低峰时段**：UPF汇聚到中心节点（减少运行实例数）  > *图表 5* UPF重定位涉及的关键信令流程（基于TS 23.502 Section 4.3.5增强）： 1. SMF检测到当前UPF所在区域负载低于阈值 2. SMF通过N4 Session Modification将UE会话从边缘UPF迁移到中心UPF 3. 迁移完成后，SMF通知AMF释放边缘UPF实例 4. OAM系统执行VNF/PNF缩容 #### 机制3：控制面NF休眠 AMF、SMF等控制面NF在低负载时可以进入**休眠模式**： | NF类型 | 休眠策略 | 唤醒触发 | |--------|---------|---------| | **AMF** | 非主用AMF进入Standby | 主用AMF负载>70%或故障 | | **SMF** | 空闲SMF实例进入Sleep | 新PDU Session建立请求 | | **PCF** | 低优先级Slice的PCF实例休眠 | 该Slice有新的策略请求 | | **NRF** | 备用NRF只保留缓存数据 | 主用NRF心跳丢失 | ### 3.4 NWDAF驱动的智能节能闭环 将上述三大机制整合，形成NWDAF驱动的智能节能闭环：  > *图表 6* ### 3.5 能效KPI体系 3GPP TS 28.310定义了5GC的能效KPI框架： $$EE_{NF} = \frac{V_{NF}}{P_{NF}} = \frac{\text{有效业务量（sessions/transactions）}}{\text{功耗（Watt）}}$$ | KPI | 定义 | 典型基线（参考值） | |-----|------|------------------| | **EE_AMF** | 每瓦特处理的注册/切换事务数 | ~5000 transactions/W | | **EE_UPF** | 每瓦特转发的数据量 | ~50 Mbps/W | | **EE_SMF** | 每瓦特处理的会话管理事务数 | ~8000 sessions/W | | **5GC总能耗** | 所有NF实例功耗之和 | 视规模而定 | | **节能比** | (P_peak - P_low)/P_peak × 100% | 目标≥30% | --- ## 四、三大演进的融合架构 SBA增强、NDL、能量感知并非独立发展，它们在5G-Advanced核心网中形成深度融合：  > *图表 7* **融合逻辑**： 1. **NDL为NWDAF提供数据**：所有NF的负载数据、能耗数据通过NDL统一汇聚 2. **NWDAF输出节能策略**：基于NDL数据，NWDAF生成Scaling/Relocation/Sleep决策 3. **SCP执行路由调整**：NF缩容后，SCP自动更新路由表，将流量引导到活跃实例 4. **意图层约束**：PCF确保节能策略不违反业务SLA --- ## 五、实战部署指南 ### 5.1 部署优先级建议 | 阶段 | 建议部署 | 投入产出比 | 风险等级 | |------|---------|-----------|---------| | **Phase 1** | SCP模式B部署 + NRF缓存 | 高（立即减少连接数50%+） | 低 | | **Phase 2** | AMF/SMF弹性伸缩 + NWDAF负载预测 | 高（节能20-30%） | 中 | | **Phase 3** | UPF节能重定位 | 中（节能10-15%，但信令复杂） | 中高 | | **Phase 4** | NDL统一数据层 | 中（长期收益大，短期投入高） | 中 | ### 5.2 参数配置建议 **SCP配置**： ``` # SCP关键参数 scp.connection_pool.max_per_host = 1000 scp.nrf_cache.ttl = 30s scp.nrf_cache.max_entries = 100000 scp.retry.max_attempts = 3 scp.retry.backoff_interval = 100ms scp.circuit_breaker.failure_threshold = 50% scp.circuit_breaker.recovery_timeout = 30s ``` **NF弹性伸缩配置**： ``` # AMF Scaling Policy amf.scaling.min_instances = 2 # 高可用最低要求 amf.scaling.max_instances = 8 amf.scaling.scale_out_threshold = 70% # CPU利用率 amf.scaling.scale_in_threshold = 30% amf.scaling.cooldown_period = 300s # 防止振荡 amf.scaling.prediction_window = 900s # 15分钟预测 ``` **UPF节能重定位**： ``` # UPF Energy Saving Policy upf.energy.consolidation_start_hour = 23:00 upf.energy.consolidation_end_hour = 06:00 upf.energy.load_threshold_low = 20% # 低于20%触发合并 upf.energy.migration_batch_size = 100 # 每批迁移100个会话 upf.energy.migration_interval = 10s # 批次间隔 ``` ### 5.3 部署避坑清单 | 坑 | 原因 | 解决方案 | |----|------|---------| | SCP升级导致全阻 | SCP是所有NF通信的枢纽 | 采用灰度升级：先升级备SCP，流量切换验证后再升级主SCP | | NRF缓存不一致 | NF实例变化后SCP缓存未更新 | 配置NRF的NF Status Notify订阅，SCP实时刷新缓存 | | AMF缩容导致UE掉线 | 缩容时UE Context未迁移 | 先执行UE Context Transfer（TS 23.502 4.11.1），确认完成后再缩容 | | UPF重定位触发大量Handover | 边缘UPF下线导致所有UE需要切换 | 分批执行，每批不超过总UE数的5% | | NWDAF误判导致过度节能 | 预测模型对突发流量不准确 | 设置安全余量（safety_factor≥1.3），并保留突发扩容能力 | --- ## 常见问题 **Q: SCP和Kubernetes Service Mesh（如Istio）有什么区别？能共存吗？** A: SCP是3GPP标准定义的5GC专用通信代理，它理解NF Profile、Slice信息、SBI语义；Istio是通用云原生Service Mesh，只理解TCP/HTTP层。两者可以共存：SCP处理5GC SBI层的路由和发现，Istio处理底层的基础设施级流量管理（如mTLS、限流）。实际上，很多供应商的SCP实现就是基于Envoy/Istio的扩展。 **Q: NDL和UDR的关系是什么？NDL会替代UDR吗？** A: NDL不会替代UDR。UDR仍然是具体的结构化数据存储（签约数据、策略数据等），NDL是位于UDR之上的**数据虚拟化层**。NDL通过统一API屏蔽了底层多个数据存储（UDR/UDSF/NF Local Store）的差异。类比数据库领域，UDR是具体的MySQL/PostgreSQL实例，NDL是上层的数据中台/数据湖。 **Q: 在现网中如何从Rel-15/16升级到5G-Advanced核心网架构？** A: 建议分步走：(1) 先部署SCP，将NF间通信从直连模式切换到间接通信模式B——这是无中断的，因为SCP对NF是透明的；(2) 引入NWDAF和基础负载分析；(3) 启用AMF/SMF弹性伸缩；(4) 部署NDL统一数据层。关键原则是**所有增强都是增量式的**，Rel-15 NF可以与Rel-18 NF共存（通过API版本协商机制）。 **Q: 能量感知核心网对终端用户有影响吗？** A: 设计上不应有任何负面影响。3GPP的节能框架要求所有节能操作必须在**保证SLA的前提下**执行。例如，UPF合并到中心节点后，如果某Slice的SLA要求<5ms延迟，则该Slice的UPF不会被合并。PCF在节能决策环路中扮演SLA守门人的角色——任何违反SLA的节能建议都会被PCF拒绝。 **Q: NDL对第三方应用开发者有什么价值？** A: NDL通过NEF（Network Exposure Function）向第三方暴露统一的网络数据API。开发者不再需要理解AMF/SMF/UDR等内部NF的数据模型，只需要通过NDL的统一Data Object接口查询所需数据。例如，一个视频应用可以通过NDL查询当前网络的带宽预测数据来优化码率选择，而不需要知道这些数据来自NWDAF还是UPF。 --- > 本文由「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 等场景全覆盖。