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等核心规范，深度解析这三大演进方向的技术本质。
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 | 安全攻击面过大 |
| 可观测性 | 缺乏统一流量采集点 | 难以实现端到端追踪 |
为解决上述问题，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的核心处理流程伪代码如下：
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
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 |
图表 2
SCP本质上扮演了云原生架构中Service Mesh（如Istio）的角色，但其设计完全遵循3GPP SBI规范，而非通用云原生框架。这一设计选择意味着运营商可以不依赖Kubernetes Service Mesh，在裸金属或VM部署中同样获得流量治理能力。
坑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
传统5GC中，数据分散在UDM（签约数据）、UDR（结构化数据）、UDSF（非结构化数据）、PCF（策略数据）、NWDAF（分析数据）等多个NF中。这导致：
NDL（Network Data Layer）在Rel-18引入（TS 23.519 Stage 2 / TS 29.519 Stage 3），旨在构建一个统一的数据存储、查询和暴露框架。
图表 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 |
订阅数据变更通知 |
NDL的核心抽象是Data Object，它统一了不同来源的数据表示：
{
"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中——这正是数据虚拟化的核心思想。
NDL不是替代NWDAF，而是为NWDAF提供更高效的数据底座。其协作关系如下：
图表 4
NDL API遵循3GPP SBI统一设计原则（TS 29.501）：
limit/offset和属性过滤关键对比：
| 维度 | 传统方式（无NDL） | NDL方式 |
|---|---|---|
| 数据获取 | NWDAF逐个调用Nnrf→Namf→Nsmf→Nudr | 一次Nndl_Query获取聚合视图 |
| 数据模型 | 每个NF定义自己的数据模型 | 统一Data Object模型 |
| 数据订阅 | 分别向多个NF订阅 | 统一向NDL订阅，NDL内部聚合 |
| 扩展性 | 新增数据源需修改Consumer逻辑 | 新增数据源只需注册到NDL |
| 外部暴露 | 需逐个通过NEF暴露 | NDL提供统一暴露接口 |
根据Ericsson和Nokia的白皮书数据，核心网（含云基础设施和支撑系统）在移动网络总能耗中占比约15-20%。虽然绝对占比不如RAN（70-80%），但核心网的节能具有独特价值：
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 |
核心思路是根据负载动态调整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\%$$
具体伸缩策略：
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"
UPF是核心网中资源消耗最大的NF。节能重定位的核心思想：
高峰时段：UPF分布式部署到边缘（低延迟，高吞吐） 低峰时段：UPF汇聚到中心节点（减少运行实例数）
图表 5
UPF重定位涉及的关键信令流程（基于TS 23.502 Section 4.3.5增强）：
AMF、SMF等控制面NF在低负载时可以进入休眠模式：
| NF类型 | 休眠策略 | 唤醒触发 |
|---|---|---|
| AMF | 非主用AMF进入Standby | 主用AMF负载>70%或故障 |
| SMF | 空闲SMF实例进入Sleep | 新PDU Session建立请求 |
| PCF | 低优先级Slice的PCF实例休眠 | 该Slice有新的策略请求 |
| NRF | 备用NRF只保留缓存数据 | 主用NRF心跳丢失 |
将上述三大机制整合，形成NWDAF驱动的智能节能闭环：
图表 6
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
融合逻辑：
| 阶段 | 建议部署 | 投入产出比 | 风险等级 |
|---|---|---|---|
| Phase 1 | SCP模式B部署 + NRF缓存 | 高（立即减少连接数50%+） | 低 |
| Phase 2 | AMF/SMF弹性伸缩 + NWDAF负载预测 | 高（节能20-30%） | 中 |
| Phase 3 | UPF节能重定位 | 中（节能10-15%，但信令复杂） | 中高 |
| Phase 4 | NDL统一数据层 | 中（长期收益大，短期投入高） | 中 |
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 # 批次间隔
| 坑 | 原因 | 解决方案 |
|---|---|---|
| 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 等场景全覆盖。
