Motivation and Background¶

2.1 A primer on virtualized RANs¶

vRAN 的核心组件构成：

典型的 5G vRAN 部署包含三个主要组件：无线电单元 (RU)、分布式单元 (DU) 和集中式单元 (CU)

其中，RU 通常由专用硬件（如 ASIC 或 FPGA）实现，而 DU 和 CU 则是运行在商用服务器上的软件应用程序

alt text

RAN 协议栈的层级划分：
- DU 负责实现具有严格实时要求的底层协议，包含用于无线信号处理的物理层 (PHY) 以及负责调度无线电资源的媒体访问控制层 (MAC)
- CU 则负责实现对延迟较不敏感的更高层级，例如负责管理无线设备操作（包括网络切换）的无线电资源控制层 (RRC)
开放式接口规范：
- 各个组件通过 3GPP 和 O-RAN 联盟等标准化的接口进行通信
- 其中与 DU 相关的关键接口包括:
  - 连接 RU 的具有实时要求的前传接口 (xRAN/Fronthaul)
  - 连接 CU 的中传接口 (F1-C/Midhaul)
  - 连接智能控制器 (RIC) 的 E2 接口

蜂窝网络是支持公共安全等关键应用的重要基础设施，尽管移动核心网和 CU 的弹性机制已有广泛研究，但由于 DU 的严格实时性和黑盒特性，目前尚未有针对 DU 的弹性解决方案

计划内事件（日常维护）：
- vRAN 的优势之一在于便于推送功能更新、操作系统/安全补丁或进行硬件维护
- 但由于缺乏针对 DU 的弹性机制，这些常规更新会导致长达数秒至数分钟的严重服务中断，迫使运营商只能在深夜安排停机窗口
计划外事件（突发故障）：
- 服务器硬件故障或软件崩溃在数据中心难以避免
- 发生此类故障时，为了保障网络高可用性，必须迅速将受影响的用户设备 (UE) 迁移至其他正常的 DU 服务器

将停机时间降至最低：
- 在计划内的弹性事件中应做到真正的零停机时间
- 在面临故障时，其停机中断时间也必须控制在与用户日常因信号盲区导致的“切换失败”相当的极短时间内
最小化计算开销与成本：
- 在网络正常运行时，系统所引入的延迟和 CPU 开销必须接近于零
- 由于 DU 节点的部署规模极大（常多达数千个站点），必须严格控制冗余成本
具备供应商无关性 (Vendor agnostic)：
- 由于商用的 DU 软件极其复杂（动辄数十万行代码）且由领域专家编写的闭源协议，重新开发并不现实
- 因此，弹性方案必须能兼容并直接应用于任何符合标准的现有 vRAN 实现，而无需去修改其底层源代码

向邻近小区卸载用户 (Neighbor cell offload)：
- 传统的故障转移依赖将用户分配给附近的基站。但这要求极高的小区覆盖重叠密度（偏远地区或企业网中通常不具备）
- 其次，这种硬切换不仅会导致吞吐量严重下降，在突发故障时现有的 5G 协议更无法保证用户能稳定重连
- 此外，这也违背了虚拟化中将多个 DU 集中池化管理的初衷
依赖容错的状态存储机制 (Fault-tolerant state store)：
- 像核心网使用的通过将状态提取到键值数据库的方法并不适用
- 首先它需要大规模修改商业源码
- 其次，键值数据库约 100 微秒的延迟会直接挤占 DU 原本就极度紧张的处理时间窗口（如每 500 微秒一次的 MAC 调度）
直接创建全新的 DU 实例：
- 如果依赖像 Kubernetes 这样的集群编排工具来重启或新建一个 DU 容器，其长达数十秒（经测试超过 50 秒）的启动延迟对于实时系统而言是完全无法接受的断网灾难
向热备 DU 的无状态迁移：
- 部分现有工作（如 Slingshot）能在两个服务器之间无缝迁移无状态的底层 PHY 信号处理
- 但 DU 更高层级（如 MAC 和 RLC 层）实际上维护着用户的长效状态（如确认消息的跟踪），单纯开启一个热备 DU 仍会导致连接完全中断长达 3 秒以上