## 引言：从"连接管道"到"智能数据中枢" 3GPP Release 19于2025年12月正式冻结，标志着5G-Advanced核心网演进进入深水区。如果说Rel-15/16定义了5G核心网（5GC）的"骨骼"——服务化架构（SBA），那么Rel-18/19则在重塑核心网的"神经系统"（数据层）和"代谢系统"（能量感知）。 本文聚焦5G-Advanced核心网三大核心演进方向：**SBA 2.0架构增强**、**网络数据层（NDL）重构**、**能量感知核心网**，从协议层原理出发，深入剖析每项技术的底层设计逻辑。 --- ## 一、SBA 2.0：从服务化到意图驱动 ### 1.1 传统SBA的局限 5GC在Rel-15引入的SBA架构将网络功能（NF）拆分为微服务，通过RESTful SBI（Service-Based Interface）交互。但经过数年商用部署，三大痛点逐渐暴露： | 问题维度 | 具体表现 | 根因 | |---------|---------|------| | **粒度固化** | NF服务接口按"功能"划分，缺乏按"意图"组织的能力 | TS 29.501定义的SBI以CRUD操作为中心 | | **跨域协调难** | 多PLMN、多切片场景下SBA仅支持单域服务发现 | NRF无联邦发现机制 | | **状态耦合** | NF实例与状态数据绑定，弹性伸缩效率低 | 无状态外置机制（UDSF）未充分使用 | ### 1.2 Rel-18/19 SBA增强架构 Rel-18在TS 23.501/29.500中引入了一系列SBA增强，Rel-19进一步扩展。核心变化可归纳为三个层面：  > *图表 1* #### 关键增强一：意图驱动SBI（Intent-Driven SBI） Rel-18引入的意图驱动管理框架（TS 28.312）将"做什么"与"怎么做"分离。传统SBI调用链为： ``` Consumer → GET /namf-comm/v1/ue-contexts/{supi} → AMF处理 → 返回结果 ``` 意图驱动模式下： ``` Consumer → POST /intent/v1/sessions "intent": "确保切片X的端到端时延<10ms" → 意图解析引擎 → 自动分解为多NF操作 → 执行 → 反馈 ``` 这种范式的本质变化在于：**NF不再是被动响应CRUD请求的资源服务器，而是能理解业务意图并自主决策的智能实体**。 #### 关键增强二：SBI安全增强 Rel-19在TS 33.501中强化了SBI安全框架： - **OAuth 2.0增强**：引入细粒度的scope控制，支持NF服务级授权（而非仅NF级） - **mTLS双向认证**：所有SBI通信强制TLS 1.3 - **API流量审计**：SOIF（Service Operation Invocation Filtering）支持基于策略的API调用过滤 伪代码表示SBI鉴权流程： ```python def authorize_sbi_request(consumer_nf, producer_nf, service_op): # Step 1: NRF颁发的访问令牌验证 token = validate_oauth_token(consumer_nf.access_token) if not token.valid: raise AuthError("Invalid token") # Step 2: 细粒度scope检查（Rel-19新增） required_scope = f"{producer_nf.type}.{service_op}" if required_scope not in token.scopes: raise AuthError(f"Missing scope: {required_scope}") # Step 3: SOIF策略过滤 policy = load_soif_policy(producer_nf.id) if not policy.allow(consumer_nf.id, service_op): raise PolicyError("Blocked by SOIF") return Authorization(granted=True) ``` ### 1.3 NRF联邦发现机制 Rel-19引入的NRF Federation是解决跨运营商、跨PLMN服务发现的关键增强。其信令流程如下：  > *图表 2* 核心协议参考：TS 29.510（NRF Service）Rel-19版本新增了`Nnrf_NFFederation`服务操作，支持跨PLMN的NF Profile查询和订阅通知。 --- ## 二、网络数据层（NDL）：从"孤岛数据"到"统一数据中枢" ### 2.1 传统数据架构的问题 5GC中数据分散在多个NF中，形成"数据孤岛"： ``` UDM → 存储签约数据（SUPI、切片信息、QoS Profile） UDR → 结构化数据仓库（策略数据、应用数据） UDSF → 非结构化数据（NF状态上下文、会话信息） PCF → 策略决策缓存 NWDAF → 分析结果缓存 ``` 这种架构导致三个核心问题： 1. **数据冗余**：同一用户数据在UDM/UDR/AMF/SMF中多处缓存 2. **一致性难保**：分布式缓存缺乏统一的同步机制 3. **分析效率低**：NWDAF需要从多个NF逐个收集数据（O(n)复杂度） ### 2.2 NDL架构设计原理 NGMN（Next Generation Mobile Networks）联盟提出的Network Data Layer概念，被3GPP在Rel-19中通过增强NWDAF和UDR架构逐步落地。其核心思想是：**将所有网络数据统一存储在一层共享数据基础设施中，NF变为无状态计算引擎**。  > *图表 3* ### 2.3 关键技术：UDSF增强与无状态化 NDL的基石是**NF无状态化**（Stateless NF）。3GPP在TS 29.598中定义了UDSF（Unstructured Data Storage Function）接口，Rel-19对其进行了重大增强： #### UDSF核心数据模型 ``` // UDSF数据记录结构（TS 29.598 Rel-19增强） { "recordId": "uuid-xxxx", "nfId": "AMF-instance-01", // 所属NF实例 "dataType": "ue-context", // 数据类型 "tags": { // Rel-19新增标签索引 "supi": "imsi-460001234567890", "s-nssai": "01-FFFFFF", "tac": "12345" }, "ttl": 3600, // 生存时间 "data": { // 实际上下文数据 "mmState": "REGISTERED", "taiList": ["TAC-001", "TAC-002"], "nssai": {...} }, "version": "v3", // Rel-19新增版本控制 "checksum": "sha256-xxxxx" // Rel-19新增完整性保护 } ``` #### 无状态化对弹性伸缩的影响 传统有状态NF的伸缩需要迁移上下文，时间复杂度为O(n×m)（n个实例×m个会话）。NDL架构下： | 操作 | 传统有状态NF | NDL无状态NF | |------|------------|-------------| | Scale-out | 需要同步会话表 | 新实例直接从UDSF读取 | | Scale-in | 需要逐会话迁移 | 直接终止实例 | | 故障恢复 | 需要主备切换 | 备份实例接管，读UDSF恢复上下文 | | 恢复时间 | 分钟级（迁移会话） | 秒级（读UDSF） | 数学表述：设NF管理N个会话，每个会话上下文大小为S bytes，网络带宽为B bps： - **传统恢复时间**：$T_{traditional} = \frac{N \times S \times 8}{B} + T_{failover}$ - **NDL恢复时间**：$T_{NDL} = \frac{S_{active} \times 8}{B_{internal}} + T_{read}$ 其中$S_{active} << N \times S$（仅加载活跃会话），$B_{internal}$为内部总线带宽（远高于外部网络带宽）。 ### 2.4 NWDAF深度集成 Rel-19对TS 23.288进行了重大更新，NWDAF从"旁路分析"变为"内嵌智能"。关键增强包括： #### AnLF与MTLF分离架构 Rel-19将NWDAF拆分为两个逻辑功能： - **MTLF（Model Training Logical Function）**：负责ML模型训练 - **AnLF（Analytics Logical Function）**：负责推理和分析输出 ``` // NWDAF分析请求（TS 23.288 Rel-19） NWDAF_AnalyticsInfo_Request { analyticsId: "load_level_info", // 分析类型 targetNfType: "AMF", // 目标NF analysisFilter: { tai: "TAC-001", // 跟踪区 snssai: "01-FFFFFF", // 切片 timeWindow: "2026-05-17T08:00/12:00" // 时间窗口 }, outputStrategy: "NOTIFY_PERIODIC", // 输出策略 accuracy: "HIGH" // Rel-19新增精度要求 } ``` #### 数据收集协调增强 Rel-19引入了**DCRF（Data Collection Coordination Function）**概念，解决了NWDAF数据收集的"N+1"问题： - **Rel-17/18**：每个NWDAF实例独立向NF收集数据，造成N倍数据请求 - **Rel-19**：DCRF协调多个NWDAF实例的数据收集，合并请求，去重数据 这对大规模网络的影响是显著的——假设有K个NWDAF实例监控M个NF，数据收集请求从$K \times M$降为$M + K$（每个NF仅收到一个协调后的请求）。 --- ## 三、能量感知核心网：从"永远在线"到"按需唤醒" ### 3.1 核心网能耗现状 根据GSMA 2025年报告，5G网络端到端能耗中，核心网占比约15-20%。虽然低于RAN（60-70%），但核心网的能耗优化有以下独特价值： 1. **核心网流量承载量持续增长**：DNN、AI应用推动核心网数据面流量指数增长 2. **云化部署带来弹性空间**：NF的scale-in/scale-out天然适配节能场景 3. **24/7在线的NF大量浪费**：凌晨2:00-6:00的业务低谷期，NF资源利用率可能低于5% ### 3.2 3GPP能量感知框架 3GPP在TS 28.310（Management and orchestration; Energy efficiency of 5G）中定义了核心网能量感知管理框架。Rel-19版本引入了**意图驱动的节能管理**。  > *图表 4* ### 3.3 核心NF节能策略详解 #### 策略一：AMF Pool动态缩容 AMF作为所有UE的锚点NF，其节能优化最具挑战性。Rel-19引入的AMF Pool节能流程： ``` 阶段1：负载评估（持续） NWDAF → 预测未来1h AMF Pool负载 < 阈值T1 阶段2：会话迁移准备 ESC → 目标AMF选择（保留实例） ESC → 源AMF发起UE上下文迁移 N1 N2 Message Transfer (Rel-19新增节能迁移指示) 阶段3：实例休眠 ESC → 通知NRF：源AMF状态 = DORMANT NRF → 停止向该实例分配新UE ESC → 容器平台缩容（减少Pod副本数） 阶段4：唤醒恢复 NWDAF → 预测负载 > 阈值T2 ESC → 容器平台扩容 NRF → 实例状态恢复 = REGISTERED ``` 关键参数配置建议： | 参数 | 推荐值 | 说明 | |------|-------|------| | T1（缩容阈值） | 30% | 低于30%时触发缩容评估 | | T2（扩容阈值） | 70% | 高于70%时触发扩容 | | 迁移窗口 | 凌晨1:00-5:00 | 业务低谷期执行 | | 保留实例数 | ceil(N×0.3) | 至少保留30%实例 | | 预测窗口 | 60分钟 | 提前60分钟预测 | #### 策略二：UPF智能睡眠模式 UPF是核心网中资源消耗最大的NF（处理全部用户面流量）。Rel-19在TS 23.501中引入了UPF节能增强： **核心原理**：利用N4 Session Management接口的会话统计功能，结合NWDAF的流量预测，在低流量时段将UPF实例分级休眠。 ``` // UPF节能等级定义 enum UPF_EnergyState { ACTIVE_FULL, // 全功率运行 ACTIVE_LOW, // 低功耗模式（减少CPU核心） LIGHT_SLEEP, // 轻度睡眠（保持N4心跳） DEEP_SLEEP, // 深度睡眠（仅保留管理接口） POWERED_OFF // 完全关机（需分钟级恢复） } // 状态转换条件 transitions = { ACTIVE_FULL → ACTIVE_LOW: "流量 < 40% 容量 持续15min" ACTIVE_LOW → LIGHT_SLEEP: "流量 < 15% 容量 持续30min" LIGHT_SLEEP → DEEP_SLEEP: "流量 < 5% 容量 持续1h 且 凌晨" DEEP_SLEEP → ACTIVE_FULL: "NWDAF预测流量 > 30% 或 告警触发" } ``` #### 策略三：SCP（Service Communication Proxy）节能路由 Rel-19增强的SCP在节能场景中扮演关键角色。SCP作为所有SBI通信的代理，可以： 1. **集中感知NF负载状态**：实时掌握所有NF实例的CPU/内存利用率 2. **路由决策优化**：将请求路由到"活跃"NF，避免唤醒休眠NF 3. **批量合并**：将多个小请求合并，减少被休眠NF的唤醒次数 ### 3.4 能量感知与SLA保障的平衡 节能优化的核心挑战是**不损害用户体验**。Rel-19引入的SLA保障机制： ```python def evaluate_energy_action(action, current_sla_metrics): """ 能量感知决策引擎核心逻辑 基于TS 28.310 Rel-19意图框架 """ # SLA约束检查 for metric, threshold in SLA_THRESHOLDS.items(): if current_sla_metrics[metric] > threshold.warning: if action.impact(metric) > 0: # 该指标已接近告警阈值，禁止可能恶化的节能操作 return Decision( allowed=False, reason=f"SLA risk: {metric} at {current_sla_metrics[metric]}" ) # 能耗收益评估 energy_saving = estimate_saving(action) recovery_time = estimate_recovery(action) # 成本效益比 if energy_saving / recovery_time > COST_BENEFIT_RATIO: return Decision(allowed=True, confidence=0.85) return Decision(allowed=False, reason="Insufficient cost-benefit ratio") ``` --- ## 四、三大演进方向的协同关系 SBA 2.0、NDL、能量感知并非孤立演进，三者形成协同闭环：  > *图表 5* **协同场景举例**：在凌晨业务低谷期—— 1. **NWDAF**（依托NDL就地分析数据）预测未来2小时AMF负载将降至20% 2. **意图引擎**（SBA 2.0）将"网络可用性>99.99%"的意图翻译为具体节能策略 3. **Energy Saving Coordinator**执行AMF Pool缩容，迁移UE上下文到保留实例 4. **NDL**的UDSF确保迁移过程无缝，因为状态数据已在共享数据层 5. **SCP**将新请求路由到活跃实例，避免唤醒已休眠NF 整个流程自动化执行，无需人工干预，且保证SLA不降级。 --- ## 五、实战部署建议 ### 5.1 NDL部署路径 | 阶段 | 目标 | 关键动作 | 预期收益 | |------|------|---------|---------| | Phase 1 | UDSF统一化 | 部署集中式UDSF，AMF/SMF状态外置 | 故障恢复时间缩短80% | | Phase 2 | 数据湖集成 | UDR+UDSF+数据湖三层架构 | NWDAF分析效率提升3x | | Phase 3 | 全面无状态 | 所有CP NF完成无状态化改造 | 弹性伸缩达到秒级 | ### 5.2 能量感知部署注意事项 1. **预测模型准确性**：NWDAF负载预测的准确率需>85%，否则频繁缩放反而增加能耗。建议先在非关键切片试点。 2. **UDSF性能瓶颈**：无状态化后UDSF成为性能关键点，建议使用内存数据库（如Redis Cluster）+持久化存储（Cassandra）的混合架构。 3. **NRF一致性**：NF休眠/唤醒期间NRF状态同步延迟可能导致请求失败。建议配置SCP的fallback重试机制（TS 29.500 Rel-19）。 4. **监控告警**：必须建立独立的能耗监控Dashboard，实时跟踪PUE（Power Usage Effectiveness）和每用户能耗指标。 ### 5.3 技术参数对比总览 | 特性 | Rel-17 | Rel-18 | Rel-19 | |------|--------|--------|--------| | SBA安全 | NF级OAuth | 服务级scope | SOIF+细粒度授权 | | NRF | 单域发现 | PLMN间发现 | 联邦发现+NRF Group | | NWDAF | 单实例分析 | 多实例 | MTLF+AnLF分离+DCRF | | 数据存储 | UDR/UDSF独立 | UDR增强 | NDL统一数据层 | | 节能管理 | RAN侧节能 | 核心网感知 | 意图驱动全链路节能 | | NF状态 | 有状态为主 | 混合模式 | 全面无状态化 | --- ## 常见问题 **Q: SBA 2.0和传统SBA是否兼容？现有NF是否需要重写？** A: Rel-18/19的SBA增强是增量式的，遵循向后兼容原则。现有NF只需升级SBI协议栈（增加新的服务操作），无需重写核心逻辑。意图驱动框架是叠加层，不影响现有SBI接口的持续使用。但建议在升级路线图中优先改造NRF和SCP，因为它们是所有SBI通信的枢纽。 **Q: NDL和现有UDR/UDSF是什么关系？需要替换吗？** A: NDL不是替代UDR/UDSF，而是将它们重新定位为统一数据层中的存储后端。UDR继续负责结构化数据（签约、策略），UDSF负责非结构化数据（NF上下文），但上层增加统一的数据访问层（Data Access Layer），对NF提供统一的数据读写接口。这种"数据虚拟化"方式避免了"推倒重来"的风险。 **Q: 能量感知核心网对UPF的节能效果有多大？** A: 根据ETSI TR 132 972（Rel-19）的研究数据，在典型运营商网络中，UPF节能策略可降低核心网能耗20-35%。主要收益来自：(1) 深度睡眠模式节省空闲CPU功耗；(2) 智能路由减少不必要的包处理。但实际效果高度依赖业务模式——IoT密集型网络（大量小包）的节能空间小于视频密集型网络（可预测的流量低谷）。 **Q: 无状态化是否会增加数据面的延迟？** A: 理论上会增加，但影响可控。每次NF处理请求需要从UDSF读取上下文，增加一次内部存储访问延迟（通常<1ms，内存数据库场景下<100μs）。Rel-19引入的UDSF热点缓存机制和预取策略，可将常用上下文的访问延迟降至接近本地内存访问水平。对于99%的5GC信令流程，增加的延迟在用户不可感知范围内。 **Q: 三大演进方向应该优先部署哪个？** A: 推荐路径是：**先NDL（基础） → 再能量感知（价值） → 最后SBA 2.0增强（完善）**。原因：NDL的无状态化是能量感知的前提条件（NF必须能快速伸缩才能节能），而SBA 2.0的意图驱动框架则建立在NWDAF（依赖NDL数据）的智能分析能力之上。 --- > 本文由「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 等场景全覆盖。