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¶

整体架构与部署:
在一个包含 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 线程状态提供了极高性能的可编程方案

Warning
别的内容笔者不是很关心了, 因此略过
我学到了什么¶
- 复习了 CU/DU/RU
- fig.1 画的不错: PHY / MAC / RLC ...
- 复习 eBPF 的妙用