首页 › deep-tech › 5G-A核心网三大演进:SBA2.0与数据层重构

引言:从"连接管道"到"智能数据中枢"

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

图表 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安全框架:

伪代码表示SBI鉴权流程:

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

图表 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

图表 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:

其中$S_{active} << N \times S$(仅加载活跃会话),$B_{internal}$为内部总线带宽(远高于外部网络带宽)。

2.4 NWDAF深度集成

Rel-19对TS 23.288进行了重大更新,NWDAF从"旁路分析"变为"内嵌智能"。关键增强包括:

AnLF与MTLF分离架构

Rel-19将NWDAF拆分为两个逻辑功能:

// 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"问题:

这对大规模网络的影响是显著的——假设有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

图表 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保障机制:

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

图表 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 等场景全覆盖。

51学通信知识星球海报-扫码加入