跳转至

Towards Energy Efficient 5G vRAN Servers

核心问题:

在不影响性能的前提下,如何提升 5G 虚拟化无线接入网(vRAN)分布式单元(vDU)服务器的 CPU 能效

TLDR:

它在不修改专有黑盒代码且保障亚毫秒级严格实时性的前提下,通过协同 MAC 层限速与透明的内核级(eBPF)任务执行时间测量,动态降低低负载时段的 CPU 频率,从而显著提升了 5G vRAN 服务器的能效

背景与技术挑战

尽管蜂窝网络在大部分运营时间内都处于低负载状态,但直接采用传统 CPU 节能技术(如休眠或动态调频)在 vRAN 服务器上行不通

主要存在两大挑战:

  • 亚毫秒级严格实时性

    • vRAN 软件(如物理层和 MAC 层)必须在极短的传输时间间隔(TTI,例如 500 μs 或更低)内完成处理,错过截止期限会导致严重的系统崩溃或掉线
    • 传统 CPU 休眠状态(如 C6)的唤醒延迟过高,无法满足要求
  • 专有黑盒特性

    • vRAN 软件通常由专业供应商以闭源二进制文件的形式提供给运营商
    • 这使得运营商极难直接在源代码层面测量和调整任务处理时间
  • 现状

    • 目前的 vRAN 部署通常会完全禁用这些优化功能,强制 CPU 始终处于高频运行状态,造成巨大的能源浪费

核心解决方案:RENC 系统

为了突破这些限制,论文提出了 RENC 系统。该系统能够根据亚秒级的蜂窝网络负载变化动态调整 CPU 频率

其核心设计包含三个创新点:

  • 建立与分离安全的“低负载”区间

    • RENC 将低负载定义为数据流量低于设定阈值(例如 1%)且无控制平面操作的时期
    • 为了防止在低频状态下遇到突发流量导致任务超时,RENC 采用“先在 MAC 层限制速率,再降低 CPU 频率”的保守策略
    • 只有在 CPU 升频完全生效后,才会解除 MAC 层的限速
  • 透明测量截止期限宽裕度 (Deadline Slack)

    • 为找出安全的最低 CPU 频率,RENC 创新地在内核层面测量任务剩余时间
    • 对于中断驱动的线程,通过 Linux 内核调度器中的 eBPF 钩子计算宽裕度,完全不需要修改 vRAN 源代码
    • 对于不让出操作系统的轮询线程,则使用轻量级二进制重写技术(dyninst)进行监测
  • 处理控制平面操作引发的算力峰值

    • 像用户设备(UE)接入等控制平面操作,会导致 CPU 负载激增
    • RENC 通过分析 vRAN 的少量公开遥测接口(如 FAPI 或 F1AP)被动检测这些信令,并临时提升 CPU 频率来应对

Background

alt text

整体架构与部署

在一个包含 RENC 的典型 vRAN 部署中,无线电单元(RU)通过以太网前传链路与分布在蜂窝站点附近或小型数据中心的 DU(分布式单元)服务器相连

多个 DU 服务器会连接到一个负责处理非实时、计算密集度较低的协议栈层的 CU(集中式单元)服务器

DU 内部的协议栈

DU 负责运行 vRAN 协议栈的底层,具体包含进行无线信号处理的 PHY(物理)层、负责分配无线资源的 MAC(媒体访问控制)层,以及处理可靠传输的 RLC(无线链路控制)层

RENC 作为用户态代理运行在 DU 外部,并带有一个位于操作系统的内核 eBPF 组件

耗电大户

蜂窝网络消耗大量能源,其中基站(特别是 RU 和 DU)占据了主导地位

虽然部分基站组件如 4x4 室内无线电设备耗电在 45 W 左右,但单台 DU 服务器的功耗高达 236 W 左右

本文的优化目标正是这些极其耗电的 DU 服务器

2.1 vRAN DU 的两大独特性质

  • 严苛的实时截止期限 (Real-time deadlines)
    • 与传统可以通过排队积压任务的应用不同,DU 中运行的底层 vRAN 软件有极为严格的硬性时间期限
    • 绝大多数线程的截止期限就是无线协议的传输时间间隔(TTI),在主流的 5G sub-6 GHz 频段中,这个时间极短,仅为 500 µs(毫米波中甚至低至 125 µs)
    • 一旦处理超时,轻则导致通话掉线,重则引发 vRAN 软件崩溃,导致整个基站瘫痪
  • 黑盒特性 (Black-box nature)
    • vRAN 软件通常是由专业供应商提供给运营商的专有、闭源二进制文件
    • 这种黑盒特性让直接在代码中测量和利用“截止期限宽裕度”(deadline slack)来降低 CPU 速度变得异常困难

2.2/2.3 传统基站与操作系统的节能手段局限性

  • 传统基站睡眠模式不可用
    • 非虚拟化的传统基站往往可以通过关闭特定硬件组件来节能,且部分具有高度定制化的硬件休眠机制
    • 然而,通用 CPU 只有通用的休眠模式,难以直接应用于虚拟化、通用服务器化的 vRAN 系统
  • CPU 电源管理机制失效
    • CPU 的动态能耗管理主要依赖动态频率缩放(P-states)和睡眠状态(C-states)
    • 但是,由于上述严苛的实时性要求,当今的 vRAN 部署通常会简单粗暴地禁用这些节能特性,强制 CPU 始终保持高频满负荷运行,造成巨大浪费
  • eBPF 技术的引入
    • 为了能在“黑盒”状态下监测宽裕度,RENC 创造性地使用了 Linux 操作系统的 eBPF 框架
    • eBPF 允许将用户编写的安全代码(codelets)在不修改原二进制文件的情况下,注入到预定义的内核钩子(hooks)中运行,这为透明测量 vRAN 线程状态提供了极高性能的可编程方案

alt text

Warning

别的内容笔者不是很关心了, 因此略过

我学到了什么

  1. 复习了 CU/DU/RU
  2. fig.1 画的不错: PHY / MAC / RLC ...
  3. 复习 eBPF 的妙用