跳转至

CloudRIC: Open Radio Access Network (O-RAN) Virtualization with Shared Heterogeneous Computing

本文重点内容一语概括:

  1. 问题: 当前的 vRAN（虚拟化无线接入网）依赖昂贵且高能耗的专用硬件加速器 (HA)
  2. 方案: 论文提出通过 在多个DU(分布式单元)之间共享一个异构处理器池, 来替代专用的硬件, 从而降低成本和能耗
  3. 系统: CloudRIC
  4. 成果: CloudRIC 利用轻量级数据模型来协调资源访问和无线调度
    • 实验证明, 该系统能在保证 99.999% 可靠性的同时, 将平均能效提升3倍, 成本效益提升15倍

另外, 我们从本文开始学习, SIGMOBILE系统仿真平台类文章的行文框架

本文是典型的类型1
  • Introduction
    • 背景是什么 (很火热)
    • 问题是什么 (很棘手, 很重要)
    • 解决方案是什么 (很牛b)
    • 核心贡献是什么 (实验效果特别好)
  • Background
    • “系统”的背景工作, 科普性质
  • Analysis
    • 观点证明: 说明自己"前面的说法"没问题
    • 可行性分析: 由于XXX (时延很短/开销很小...), 它的确可以参与我们最终的“系统构成”
  • CloudRIC System Design
    • 总述: "组件/系统" 的 overview
    • Workflow: 整个系统如何工作 (step 1 2 3 4)
    • Detailed Design: 一些重要的内部组件如何工作 (采用了XXX算法)
  • Implementation
    • 上面的 System Design 如何用真实的系统部署 (nvidia XXX卡, Xeon CPU, ...)
    • User Plane: 侧重于 DataFlow
    • Ctrl Plane:
  • Evaluation
  • Related Work
  • Conclusions

Introduction 重点内容:

(1) 核心问题

行业当前的 vRAN(虚拟化无线接入网) 方案为每个 DU(分布式单元) 都配备了专用的硬件加速器 (HA), 如 GPU、FPGA

  • 原因:
    • CPU 无法独自满足 5G 物理层(PHY)任务所需极其严格的实时(1-3ms) 和高可靠性（99.999%）要求
    • alt text
  • 缺陷:
    • 这些专用的 HA 非常昂贵、极其耗电（例如一个 GPU 功耗高达 250W）
    • 且在真实的 RAN 工作负载下，它们的利用率其实非常低，造成了巨大的浪费

(2) "出发点"

为了解决上述成本和能耗问题，论文提出了一种更高效的资源利用方式，基于两个核心思想:

  1. 处理器池化 (Processor Pooling):

    • 不再为每个 DU 单独配备 HA，而是建立一个由 CPU 和 HA 组成的共享资源池，让多个 DU 共享使用。这可以摊销昂贵 HA 的成本

  2. 机会性 HA 卸载 (Opportunistic HA Offloading):

    • 不总是使用高能耗的 HA
    • 论文证明，CPU（利用 SIMD 等优化）完全有能力在时限内可靠地处理很大一部分 5G 任务 (e.g. 较小的传输块)
    • 因此, 系统应智能地平衡负载: CPU 能处理的就用 CPU(更节能), CPU 搞不定的再交给 HA

(3) 解决方案与结果

  1. 系统设计 (CloudRIC):

    • 作者设计了一个名为 CloudRIC 的系统来管理这个共享池
    • 它通过两个组件协同工作，以确保在资源共享的情况下仍能满足 99.999% 的可靠性:
      • AAL Broker (代理): 实时决定一个任务应该分配给 CPU 还是 HA（执行"机会性卸载"）
      • RT-RIC (智能控制器): 执行“计算感知”的无线调度策略，确保 DU 的调度决策与后端计算资源（CPU/HA）的实时状况相匹配

  2. 实验成果:

    原型机测试表明，CloudRIC 系统在满足 99.999% 可靠性的前提下，与行业标准（DU 专用 HA）相比:

    • 能效平均提升 3 倍
    • 成本效益平均提升 15 倍

Background 重点内容:

主要说明 "为什么现有的 O-RAN 架构无法实现高效的资源共享"

  1. 5G New Radio (2.1):

    • 介绍了 5G DU 的数据处理Pipeline (FEC/LDPC 编解码)
    • 强调了最关键的限制: DU 处理这些任务必须满足极其严格的实时 deadline（1-3 毫秒内完成）和极高（99.999%）的可靠性要求

  2. 硬件加速 (2.2):

    • 两种硬件加速 (HA) 模式:
      • in-line: 感知无线信号, 不需要软件干预
        • 内联, 快但僵化(限制了虚拟化)
      • look-aside: 由软件控制器管理, 操作数据
        • 旁路, 灵活, 由软件控制
    • 指出 look-aside 模式因其灵活性, 正变得越来越主流

  3. O-RAN 架构 (2.3):

    • 这是本章最关键的部分。它指出了当前 O-RAN 标准的核心局限性
    • alt text
    • O-RAN 架构虽然提供了 O-Cloud（资源池）和 AAL（加速抽象层）来管理 CPU 和 HA，但它的设计阻碍了高效的实时共享
    • 主要原因:
      • (AAL 隔离): AAL 将资源（LPU）通过独立的 FIFO 队列分配给每个网络功能 (NF)
        • 这意味着, 即使多个 DU 物理上共享同一个 GPU, 它们也无法感知彼此的队列状态，无法协同工作
      • (RIC 太慢): O-RAN 用来管理资源的 RIC（智能控制器）其响应时间（>100ms 或 >1s）太慢，远不能满足 5G 所需的亚毫秒级的实时协调

O-RAN架构层次解析:

  • 控制层:
    • Non-RT RIC: 时延较长
    • Near-RT RIC: 时延很短
  • 数据层: O-Cloud: alt text
    • [向上看] 通过AAL为上层NFs服务
    • 抽象计算资源为 LPUs, 每个LPU专用于一个NF
    • [往下看] 通过底层驱动, 调用实际计算资源 HAs
RIC: RAN Intelligent Controller

RIC: RAN Intelligent Controller. 无线接入网智能控制器

RIC是O-RAN架构控制平面的关键组成部分. O-RAN联盟定义了RIC, 用于实现开放的RAN架构

RIC 主要负责管理网络功能 (NFs), 例如分布式单元 (DUs):

  • Non-Real-Time RIC (Non-RT RIC): 操作时间尺度较慢, 通常在 >1 秒
  • Near-Real-Time RIC (Near-RT RIC): 操作时间尺度较快, 但仍属于非实时范围, 通常在 >100 毫秒

Analysis 重点内容:

CPU 和 HA 共享池是可行且必要的, 但这必须依赖一个超越 O-RAN 现有能力的、能够"联合控制无线与计算"的新系统

这一章主要是在证明必要性, 其实没啥新东西, 不太需要看

(1) 证明了“机会性卸载”的可行性 (§3.1, §3.2)

  • CPU 的价值被低估:
    • 实验首先确认了业界的担忧——单独使用 CPU 确实无法在高负载下保证 99.999% 的可靠性
    • 但是，实验也证明，在很大一部分真实世界的低负载场景下（例如“x1”配置），CPU 的处理速度完全“足够快”（能满足 1-3ms 时限）
    • 而在这些场景下，CPU 的能耗远低于 GPU (HA)（最多可低 28 倍）
  • 结论: 这证明了“机会性卸载”（即 CPU 能处理的就交给 CPU，以节省能源）是完全可行的

(2) 证明了“资源池化”的必要性 (§3.3)

  • HA 存在巨大浪费: 实验显示，在真实世界的 workload 下，一个专用于单个 DU 的高性能 GPU (HA)，其利用率极低
    • 例如，在“x1”配置、10 个并发用户时，利用率也低于 12%
  • 结论: 为每个 DU 单独配备 HA 是巨大的成本浪费。将多个 DU 聚合起来, 共享一个 HA 资源池是合理且必要的

(3) 证明了“新型协调策略”的必需性 (§3.4)

这是本章最重要的洞察。作者模拟了在共享池上运行的各种策略:

  • 当前 O-RAN 策略会失败:
    • 标准的 O-RAN 策略("O-Greedy"), 由于各个 DU 之间缺乏协调(只看自己的队列). 在负载稍高时, 可靠性会迅速崩溃, 降至 0%
  • 仅协调还不够:
    • 即使是 更高级的、有协调的策略("C-MWT") 或 感知截止时间的策略("C-DA"), 虽然性能更好, 但由于真实流量的“突发性”(burstiness), 它们依然无法保证 99.999% 的可靠性
  • 核心发现: 唯一能成功的策略("C-R-DA")是, 必须将“无线调度”和“计算资源”联合控制
    • 当计算资源（CPU/HA）即将过载时, 该策略会主动"限制"无线端的任务分配(radio grants)
    • 以此牺牲少量吞吐量来确保 99.999% 的可靠性

总而言之, 这一部分通过实验证明:

CPU 和 HA 共享池是可行且必要的(§3.1-3.3), 但这必须依赖一个超越 O-RAN 现有能力的、能够"联合控制无线与计算"的新系统(§3.4)

CloudRIC System Design 重点内容:

最重要的一节, 架构设计与核心机制解析!

本节介绍了 CloudRIC 系统，它在 O-RAN 架构上增加了两个关键组件，目标是按优先级顺序实现:

  1. 99.999% 的可靠性
  2. 吞吐量最大化
  3. 能耗最小化

(1) 新增组件:

  • RT-RIC (实时 RIC): 一个实时的控制器
    • 当 O-Cloud 出现拥塞时, RT-RIC 会主动限制无线电授权 (throttling down radio grants), 将工作负载调整到处理能力范围内
    • 它审查 DU 发出的无线资源请求，确保这些请求不会导致后端计算过载。实现了“计算感知”的无线策略
  • AAL-BRoker (AAL 代理): 一个中央协调器
    • AAL-B UP [用户平面]:
      • 充当 DU 与 O-RAN AAL 之间的代理. 将所有共享的 CPU 和 HA 资源(LPU) "打包" 成一个虚拟资源池
      • 主要职责是根据控制平面的分配将传入的传输块 (TB) 路由到预分配的 LPU
    • AAL-B CP [控制平面]:
      • 负责 LPU 分配. 使用预测模型和队列时间估计器来做出调度决策
      • 负责决定一个任务（TB）到底应该交给哪个 CPU or HA 处理

alt text

形象化理解这个系统设计:

RT-RIC像"智能交通管制中心", AAL broker像"车库调度员"

  1. 交通管制中心(RT-RIC) 会实时监控主干道(O-Cloud) 的拥堵情况:
    • "严格控制进入量. 确保里面够应付"
    • 如果拥堵（计算负荷）过大，它会暂时减少进入高速公路（无线电授权）的汽车数量，以确保所有已进入的车辆都能在规定的时间内到达目的地（保证 99.999% 的可靠性）
  2. 车库调度员(AAL Broker) 负责:
    • "把里面的赶紧往外调度"
    • 根据每辆车（传输块）的类型和每种处理器（CPU 或 HA）的能效及当前等待时间，智能地将其分配给最经济且能及时完成任务的工位

(2) Workflow:

本节详细描述了 CloudRIC 处理一个上行链路请求的 6 步工作流:

alt text

  1. 临时请求 (Temporary grants):
    • DU 发出一个“临时”的资源请求
  2. 延迟估计 (Latency estimation):
    • RT-RIC 立即从 AAL-B 获取当前所有 LPU (CPU/HA) 队列的"预计等待时间"
  3. 无线策略 (Radio policy):
    • RT-RIC 的“策略代理”
    • 根据等待时间, 决定是否"限制"这个临时请求 (e.g. 批准 100% 或只批准 50%)
  4. 最终请求 (Final grant):
    • 系统生成一个被批准的"最终请求", 并通知 DU 和 AAL-B

  5. LPU 分配 (LPU allocation):

    AAL-B 收到“最终请求”后, 使用 LPU 模型来预测此任务在每个 CPU/HA 上的处理时间和能耗. 它的分配算法是:

    • (a) 剔除所有无法在ddl内完成的 LPU (aka. 等待时间 + 预测处理时间 > Deadline)
    • (b) 在剩余的、能满足时限的 LPU 中, 选择那个"预测能耗最低"的

  6. LPU 处理 (LPU processing):

    • 任务被发送到（5）中选定的 LPU 队列中等待处理

(3) 重要组件详细讲解:

无线策略代理 (Radio policy agent)

回应上述 "决定是否'限制'这个临时请求"

  • 方案: 由于决策（是否限制）非常复杂且依赖实时状态，作者使用了一种数据驱动模型
  • 实现: 采用“强化学习”中的 Soft Actor-Critic 算法
  • 工作方式:
    • RL 代理（actor）会根据系统状态输出一个决策
    • 它根据一个“奖励函数”进行在线学习: 如果任务按时完成，则获得正奖励；如果超时，则获得负惩罚

LPU 模型 (LPU Models)

回应上述 "使用 LPU 模型来预测此任务在每个 CPU/HA 上的处理时间和能耗"

  • 目的: LPU 模型用于预测一个特定任务（grant）在某个特定 LPU（如 GPU-1 或 CPU-3）上将花费的处理时间（\(\hat{d}_n^{(i)}\)）和能耗（\(\hat{e}_n^{(i)}\)）
  • 实现: 使用简单的前馈神经网络, 通过 §3 中的实验数据进行离线训练
  • 核心设计:
    • 预测能耗: 用标准的 MAE 损失函数
    • 预测延迟: 用一个特殊的“不对称损失函数” (WCET loss)
  • 原因:
    • 系统绝对不能 underestimate 处理时间, 因为这会导致任务超时 (这是灾难性的)
    • “高估”一点则问题不大
    • 这个 WCET 损失函数会“重罚”低估的预测, 从而确保模型倾向于保守估计，保证 99.999% 的可靠性

(4) 与现有设计的对比分析:

笔者总结一下, "现有O-RAN"和"新设计提出来的Cloud-RAN"的区别

alt text

Implementation 重点内容:

整理一下实验条件:

  • 硬件: 在一台多 DU(基站)服务器上实现，该服务器配备了异构处理器(1 个 GPU + 1 个 16 核 SIMD-CPU)
  • 软件栈: 基于 O-RAN AAL 构建
  • 工作负载: 模拟 RU(无线单元) 和 UE(用户设备), 使用 §3 中采集的真实且具有突发性的流量数据来生成负载

User Plane: AAL-B-UP 的实现

  • 技术实现:
    • 使用约 2000 行 C++ 代码
    • 依赖 DPDK (EAL) 来实现高效的线程和内存管理
  • 核心功能:
    • 作为数据路由的“代理”
    • 它运行一个主线程, 负责接收 TB(数据包), 并根据“控制平面”的指令, 将其路由到预先分配好的 LPU 队列

Control Plane: AAL-B-CP 和 RT-RIC 的实现

  • 技术实现:
    • 使用约 1500 行 C++ 代码
    • 使用 DPDK 进行高效通信
    • 使用 ONNX Runtime (ORT) 来加速神经网络的推理
  • 组件功能:
    • RT-RIC (无线策略): 运行基于强化学习的 Actor-Critic 神经网络, 实时决定是否“限制”无线请求
    • AAL-B-CP (LPU 分配): 运行 LPU 模型(3层神经网络), 实时预测每个任务在 CPU/GPU 上的延迟和能耗, 以做出最优分配

关键实验验证:

  • ✅ WCET 损失函数的有效性
  • ✅ 系统延迟开销非常低, 均在 um 级别

Related Work 和 Conclusion 重点内容:

强相关工作归纳为三类, 它们的局限性:

  1. 通用的任务调度器

    • 例如: Shinjuku, Shenango, Snap
    • 局限性: 这些调度器虽然延迟很低(微秒级), 但它们是“通用”的, 不了解 vRAN中“无线调度”的特定需求。无法在 vRAN 平台上可靠地共享异构（CPU+HA）资源

  2. 现有的 vRAN/DU 调度器

    • 例如：Agora, Concordia, Nuberu, GPF 等
    • 局限性: 这些方案各有缺陷，都无法解决本文的核心问题
      • Agora: 只支持 CPU，且依赖“专用” (dedicated) CPU 核，因此不适用于“共享” (shared) 平台
      • Concordia: 无法管理异构（CPU+HA）资源池；更重要的是，它不控制“无线”资源，因此在多 DU 共享时无法保证可靠性
      • Nuberu: 只优化单个 DU，无法“协调”多个 DU，也未优化计算资源的使用
      • GPF: 没有解决本文最关键的“计算与无线联合控制”问题

  3. O-RAN 编排 (Orchestration) 方案

    • 例如: ColO-RAN, OrchestRAN
    • 局限性: 它们的工作时间粒度太慢(秒级/分钟级)
    • 问题在于:
      • 正如 §3 所示，vRAN 的真实流量具有极强的“亚毫秒级”突发性 (bursty)
      • 这些“慢速”的编排方案根本无法应对这种突发流量，因此无法在保证 99.999% 可靠性的同时，实现 CloudRIC 所能达到的高资源复用增益

TLDR, 本文的最最核心是:

  1. 问题: 当前的 vRAN 依赖昂贵且高能耗的专用硬件加速器 (HA) 来保证可靠性
  2. 方案: 论文提出了 CloudRIC 系统
    • 它扩展了 O-RAN 架构, 通过让多个 DU（基站）共享 HA 来降低成本, 并利用低成本的 CPU 来降低能耗
  3. 成果: CloudRIC（基于 DPDK 和轻量级数据模型实现）开销很低, 并且与行业标准相比, 平均提升了 3 倍的能效和 15 倍的成本效益