Colosseum: Large-Scale Wireless Experimentation Through Hardware-in-the-Loop Network Emulation

注意, 这篇文章是 colosseum 最早版本. 跟 MobiCom'21 不完全一样, 后者更偏向于产品说明书. 细节介绍还是更推荐本文.

Colosseum: 目前世界上最大的 Hardware-in-the-Loop 无线网络仿真器

• 定义: Colosseum是一个开放接入的, 公开的大规模无线测试平台, 它通过完全可编程的"白盒"平台上的虚拟化和软件化波形及协议栈进行实验研究.

• 规模: 包含 256个 软件定义无线电（SDR）和 128个 远程可访问的计算节点.

• 历史: 最初由 DARPA(美国国防部高级研究计划局) 和 JHU应用物理实验室 为"频谱协作挑战赛"（SC2）建造, 现由 Northeastern University 无线物联网研究所在NSF资助下扩展并运营.

• 核心优势:

  • 能够模拟几乎任何场景, 在各种部署和信道条件下大规模设计, 开发和测试解决方案
  • 不仅用于实验, 还是一个 Wireless Data Factory, 用于为AI/ML生成大规模数据集

什么是 Hardware-in-the-Loop

在 Wireless Networking 的语境下, Hardware-in-the-Loop (HIL, 硬件在环) 是一种介于"纯软件仿真"和"真实外场测试"之间的测试与验证方法.

简单来说, 它的核心逻辑是: 把真实的无线电通信设备 (Hardware), 接入到一个由计算机模拟产生的虚拟无线环境 (Loop/Simulation) 中进行运行.

(1) HIL 的出现背景

在 HIL 出现之前, 无线研究通常只有两个极端:

• 纯软件仿真 (Simulation): 例如使用 MATLAB 或 ns-3.
  • 优点: 便宜, 可重复, 易于控制.
  • 缺点: 不够真实. 软件很难完美模拟真实硬件的物理特性 (如放大器的非线性失真, 时钟漂移, 处理延迟) 以及复杂的无线信道干扰.
• 真实外场测试 (Field Test): 拿着设备去室外跑.
  • 优点: 绝对真实.
  • 缺点: 不可控且不可重复. 外场环境千变万化, 难以复现相同的无线条件; 而且外场测试通常成本高昂, 难以大规模部署.

HIL 就是为了融合两者的优点: 既有真实硬件的物理特性, 又有仿真环境的可控性和可重复性.

(2) HIL 系统如何工作

在一个典型的无线 HIL 系统 (如 Colosseum) 中, 通常包含三个部分:

1. Real Hardware: 指被测设备 (Device Under Test, DUT)

   • 在 Colosseum/COSMOS 中, 这通常是 SDR (软件定义无线电, 如 USRP) 或者真实的商用基站/手机芯片.
   • 这些设备运行着真实的协议栈 (从物理层到应用层), 发射和接收真实的射频信号.

2. Emulated "Loop" / Channel: 指模拟的环境/信道

   • 这些真实的无线电设备并没有连接天线把信号发射到空气中, 而是通过射频线缆连接到了一个巨大的信道模拟器.
   • 这个模拟器 (通常由高性能 FPGA 组成) 会实时计算信号在传播过程中的变化.
   • 例子: 如果你在仿真一个"繁忙的纽约街道", 当设备 A 发信号给设备 B 时, 模拟器会根据预设的数学模型, 实时地给信号加上路径损耗, 多径效应, 多普勒频移 (如果模拟移动), 以及建筑物遮挡效果, 然后再把处理过的信号传给设备 B.

3. Closed Loop Feedback

   • 设备 A 真的以为自己在发信号, 设备 B 真的以为自己从空气中收到了信号.
   • 根据收到的信号质量, 设备 B 可能会调整自己的发射功率或调制方式, 这个反应会再次进入模拟器, 形成一个闭环.

---

Introduction 核心内容

• 无线技术发展的挑战与需求:

  • 无线技术 (5G, Wi-Fi, 无人机等) 正在以前所未有的速度发展, 这一领域越来越需要可编程, 大规模的实验测试平台, 以便在逼真的环境中验证新技术.
  • 然而, 高保真的测试平台往往难以获得或成本高昂.
  • 现有的测试手段存在局限性: 数值模拟往往缺乏对硬件限制和信道变化的逼真建模; 而小型实验室环境虽然能捕捉硬件特征, 但无法模拟大规模商业部署的动态和真实干扰条件.

• 现有的实验平台工作:

  • 为了弥补这一差距, 美国NSF发起了PAWR计划, 旨在开发城市规模的可编程无线平台 (如POWDER-RENEW, COSMOS, AERPAW, ARA).
  • 欧洲的5GENESIS项目也在进行类似努力, 但其侧重于5G生态系统而忽略了非蜂窝技术.
  • 室内的小规模测试平台 (如Drexel Grid, ORBIT, Arena) 虽然提供了良好的室内传播环境, 但在规模上难以捕捉大型真实部署的动态.

• Colosseum 的核心能力:

  • 硬件规模: 拥有 256 个软件定义无线电 (SDRs) 和 128 个远程可访问的计算节点与 GPU.
  • 仿真能力: 能够通过真实的硬件设备测试全协议栈解决方案, 并提供包含复杂信道交互 (如路径损耗, 衰落, 多径) 的逼真仿真环境.
  • AI 与数据: 除了实验功能, 它还可以作为 AI 演练场和无线数据工厂, 用于创建大规模数据集并在安全受控的环境中训练/测试解决方案.

---

Colosseum Architecture 核心内容

该章节主要介绍了 Colosseum 的硬件组成, 信号处理流程及管理架构:

• 整体架构组成:

  • 标准无线电节点 (SRNs)
  • 大规模信道仿真器 (MCHEM)
  • 射频 (RF) 场景服务器
  • 流量生成器 (TGEN)
  • 管理基础设施组成

• 标准无线电节点 (SRNs):

  • 硬件配置: 每个 SRN 都是一台高性能服务器, 配备 48 核 Intel Xeon CPU 和 NVIDIA Tesla K40m GPU, 并驱动一个 NI/Ettus USRP X310 无线电设备.
  • 部署方式: SRN 分为四个象限, 通过层级 OctoClock 进行时频同步.
  • 软件环境: 支持用户通过 Linux 容器 (LXC) 自动部署软件化的协议栈并控制各层参数.

• 大规模信道仿真器 (MCHEM):

  • 核心功能: 负责信道仿真. 它包含 FPGA 模块阵列, 并驱动与 SRN 一一对应的 128 个 USRP X310.
  • 仿真原理: 发射信号经过模数转换后, 进入 FPGA 通过有限脉冲响应 (FIR) 滤波器处理.
  • 信号处理: 滤波器使用 512 个预计算的复数值抽头 (taps) 来模拟信道脉冲响应 (CIR). MCHEM 通过卷积运算 (\(y_{j} = \sum_{i=1}^{N} x_{i} * h_{i,j}\)) 聚合所有信号, 从而逼真地模拟现实中的干扰和多节点信号叠加效应.

• RF 场景服务器:

  • 维护 RF 场景目录, 并在运行时向信道仿真器提供信道抽头参数.
  • 能够模拟 1 平方公里地形内, 带宽高达 80 MHz 的无线信道效应 (如路径损耗和衰落).
  • 支持并发仿真, 允许多个用户同时在不同实验中运行不同的场景.

• 流量生成器 (TGEN):

  • 基于 MGEN 开发, 用于模拟 SRN 之间的 IP 流量流 (包括数据包速率, 大小和分布).
  • 生成的流量数据包会被传送给 SRN, 由用户定义的协议栈 (如蜂窝网络或 Wi-Fi) 进行处理.

• Management Infrastructure: 提供辅助服务

  • 用于预订资源的网站
  • 资源管理器
  • 访问网关
  • 全测试床的时间同步服务
  • 用于存储镜像和实验数据的 900 TB 网络附加存储 (NAS)

---

Experimental Scenarios in Colosseum 核心内容

实验场景(RF Scenario + Traffic Scenario) 是 Colosseum 的核心. RF 场景能够模拟高达 65,535 个无线信道, 仿真区域可达 1 平方公里

Colosseum 提供了一系列大规模场景:

1. Alleys of Austin (奥斯汀小巷)
   • 模拟德克萨斯州奥斯汀市中心的城市区域
2. SCE Qualification (SCE 资格赛场景)
3. Cellular Scenarios (蜂窝场景)
   • 基于 OpenCelliD 数据库, 复现了罗马, 波士顿和盐湖城 (POWDER 测试床) 的真实基站位置

---

Operational Modes of Colosseum 核心内容

分成两种模式:

1. Interactive Mode (实时交互)
   • 用户可以实时登录 SRN, 直接控制无线电和协议栈, 适合调试和小规模实验.
   • 支持实时监控和数据采集.
2. Batch Mode (批处理)
   • 用户使用 config file 提交预定义的实验作业, 系统自动分配资源并运行实验.
   • 适合大规模实验和长时间运行的测试.

Interactive Mode

用户通过 Web 界面预订资源, 然后通过 SSH 直接登录 SRN 进行实验.

(1) Reservation Phase

这是实验的起点, 用户主要与 Website 交互.

• 预订资源: 用户通过 Colosseum 网站预订所需数量的 SRNs (Standard Radio Nodes).
• 指定镜像:
  • 在预订时, 用户需指定在 SRN 上加载的 LXC 镜像 (Container Image).
  • 这可以是系统提供的镜像, 也可以是用户通过 SSH Gateway 预先上传或创建的自定义镜像.
• 代币计费: 系统采用基于代币 Token 的机制来分配资源, 占用资源会消耗每小时一定数量的代币, 以确保公平使用.

(2) Allocation Phase

这一步由系统自动完成, 将 NAS 中的数据部署到硬件上.

• 分配资源: 网站确认预订后, 指示系统分配具体的 SRN 资源 (Allocate Resources).
• 实例化容器: Colosseum 自动从文件存储 (NAS) 中提取选定的镜像, 并在裸机 SRN 上实例化 LXC 容器.

(3) Experiment Phase

这是实验的核心部分, 用户通过 SSH Gateway 直接控制 SRN, 并与仿真组件交互.

• 建立连接: 用户通过 SSH 登录到 SSH Gateway, 进而访问分配给他们的 SRN 容器.
• 运行实验: 用户在 SRN 上通过命令行 (如 colosseumcli API) 控制实验.
  • RF 交互: SRN 控制 USRP X310 与 MCHEM (大规模信道仿真器) 进行射频信号交互.
  • 流量交互: SRN 与 TGEN (流量生成器) 交互以模拟网络流量.
• 保存快照: 在实验过程中, 用户可以随时制作容器的快照, 将其作为新的 LXC 镜像保存回 NAS, 供后续使用.

(4) Termination & Data Phase

实验结束后的数据处理与资源清理.

• 保存数据: 实验结束后, SRN 上的 /logs 目录内容会自动被复制并保存到 File Proxy & NAS.
• 资源释放: 分配的计算和无线电资源被系统回收.
• 获取数据: 用户可以通过 SSH Gateway 访问 File Proxy, 将实验产生的数据和日志下载到本地进行分析.

Batch Mode

主要用于自动化的大规模实验 (基准测试/数据收集), 用户通过配置文件提交作业, 系统自动调度和执行.

(1) Configuration Phase

这是用户介入的主要阶段, 通过定义配置文件来设定实验参数, 而非手动操作.

• 创建配置文件: 用户需编写 JSON 格式的文件来配置批处理作业.
• 定义参数: 配置文件中需指定以下关键信息:
  • 实验持续时间 (Experiment duration).
  • 运行的 RF 和流量场景 (RF and traffic scenarios).
  • 分配的 SRN 数量 (Number of SRNs).
  • 实例化的 LXC 镜像 (LXC images).
  • 传递给用户程序的额外自定义参数.

(2) Scheduling Phase

作业提交后, 进入系统自动管理的队列.

• 进入队列: 作业被调度后插入队列中等待.
• 自动启动: 系统根据当前的资源可用性 (Resource availability) 自动触发作业开始.

(3) Automated Execution Phase

实验开始后, Colosseum 接管控制权, 自动完成环境搭建与实验运行.

• 环境实例化: Colosseum 自动负责在 SRN 上实例化容器, 并运行指定的仿真场景 (Emulation scenario).
• 脚本触发: 系统调用用户定义的启动脚本 (Startup scripts).
• 实验运行: 实际的实验过程在脚本引导下自动执行.

(4) Termination & Data Phase

实验结束后, 系统自动处理数据回收, 机制与交互模式类似.

• 数据复制: 批处理作业结束后, 系统自动将 SRN 容器内 /logs 目录下的数据和日志复制到 NAS 存储中.
• 数据获取: 用户随后可从 NAS 中检索实验结果.