SCOPE: an open and softwarized prototyping platform for NextG systems¶
(1) BGD and Motivation
- 网络转型: 蜂窝网络生态系统正通过开放性, 软件化和虚拟化原则发生根本性变革, 转向基于"白盒"基础设施的 NextG 网络
- 智能化需求: 电信运营商将能够根据实时条件和流量需求, 动态地部署和调整网络元素, 从而实现真正的网络智能化
- 当前痛点: 部署这些智能解决方案需要广泛的原型设计和测试流程, 但目前这方面非常欠缺
(2) 核心贡献: SCOPE 平台
为了解决上述问题, 文章介绍了 SCOPE: 一个用于 NextG 系统的开放式软件化原型平台.
该平台由四个关键部分组成:
- 虚拟化容器: 一个即用型, 便携的开源容器, 用于实例化软件化和可编程的蜂窝网络元素 (如基站和用户)
- 仿真模块: 用于模拟多样的真实部署, 信道和流量条件, 以便测试新方案
- 数据收集模块: 专为AI和ML的应用, 提供"数据采集"接口
- 开放 APIs: 一组允许用户实时控制网络元素功能的接口
(3) 平台价值与验证
- 应用场景: 研究人员可以在将 NextG 解决方案部署到商业基础设施之前, 利用 SCOPE 在各种大规模场景中进行测试和验证
- 实验验证: 文章在世界上最大的无线网络仿真器 Colosseum 中展示了 SCOPE 的能力
- 平台独立性: 作者还将解决方案移植到了室内测试床 (Arena) 和室外测试床 (POWDER), 证明了 SCOPE 具有跨平台的独立性和可移植性
scope | colosseum | arena | powder 区别是什么
TODO
Introduction 核心内容
- 蜂窝网络向开放和软件化转型的背景
- 面临的测试挑战
- 本文提出的解决方案 SCOPE
背景:
-
网络转型与智能化趋势
- 蜂窝网络正从传统的"黑盒"架构向基于"白盒"硬件和开放软件的可编程基础设施转变
- 这一变革主要由开放可编程性, 软件化和虚拟化驱动, 旨在满足未来 (NextG) 系统的需求
- 这种转变使电信运营商能够将网络功能抽象为虚拟功能以实现快速控制, 通过网络切片实施差异化服务策略, 并部署自定义算法进行实时网络优化
-
测试验证的挑战
- 尽管开放架构加速了系统的发展, 但在商业部署前必须验证新软件解决方案的有效性, 可靠性和稳定性
- 直接在商业网络上测试风险高且成本昂贵, 而小型实验室环境无法捕捉大规模的射频场景
- 尽管已存在如 PAWR (POWDER, COSMOS) 和 Colosseum 这样的大规模测试平台, 但由于缺乏统一的访问接口, 利用这些平台进行设计和原型开发并不容易
解决方案: SCOPE 平台的提出
为了解决上述问题, 本文介绍了 SCOPE (软件化蜂窝开放原型环境), 这是一个专为 NextG 蜂窝无线接入网 (RAN) 设计的开发环境, 旨在促进平台无关的设计
SCOPE 包含虚拟化容器和仿真环境, 具有以下四个主要特征:
-
开放和可移植的实现:
- SCOPE 提供了一个基于 srsLTE 改进的开源软件化基站实现, 增加了网络切片, MAC 层和物理层功能 (如调度策略选择, MCS 微调等)
- 这些功能可通过开源代码直接控制, 或通过一组 API 进行实时重配置
- 封装在 Linux 容器 (LXC) 中以实现跨平台部署
-
数据收集能力:
- 内置数据收集模块, 用于自动记录网络性能
- 收集的数据可用于运行时自适应设计或离线辅助 AI/ML 算法的训练与测试
-
射频和流量场景原型设计:
- 开发了一套可在 Colosseum 仿真器上运行的真实世界射频和流量场景
- 研究人员利用这些场景可以在多样化的信道条件 (如位置, 移动性) 和网络部署下大规模测试算法
-
大规模的可重复性与复现性:
- 所有 SCOPE 场景的执行都是确定性的, 确保不同实验在相同的信道和流量条件下运行, 从而支持在大规模可重复环境中对解决方案进行微调
验证与应用:
文章将通过分析不同城市场景的统计特性以及展示机器学习和优化应用案例来证明 SCOPE 的有效性
此外, 还将展示如何将 SCOPE 原型移植到 Arena(室内) 和 POWDER(室外) 等异构真实测试平台上, 证明其平台独立性和可移植性
Experimenting with SCOPE 核心内容
即:
SCOPE <-> Colosseum具体步骤, 相当于workflow! 特别重要, 值得借鉴学习

Step 1: 用户下载 SCOPE到本地机器
- 动作: 用户从 Colosseum 域下载 SCOPE 容器的副本到本地机器 (用户域)
- 内容: 该容器包含用于实例化基站 (BSs) 和用户设备 (UEs) 的代码, 以及用于在运行时控制软件化基站关键功能的 SCOPE APIs
Step 2: 本地添加控制逻辑与算法, 形成实例
- 动作: 在本地机器 (用户域) 上, 用户将所需的控制逻辑和算法添加到容器中.
- 方式: 这可以通过调用 SCOPE APIs 或直接修改开源代码来实现, 从而创建一个"定制化"的 SCOPE 实例.
Step 3: 在 Colosseum GUI 选择场景
- 动作: 用户通过专用的图形用户界面 (GUI), 从 Colosseum 提供的现有场景集中选择实验所需的射频 (RF) 和流量场景.
Step 4: 用户上传定制化 SCOPE 至 Colosseum
- 动作: 用户==将包含自定义控制逻辑的定制化容器从用户域上传至 Colosseum 域== (作为 User Containers).
Step 5: 调度与运行实验
- 动作: 用户通过 Colosseum 的 Web GUI 调度实验, 指定节点数量等参数.
- 执行: 用户配置完成后, Colosseum 会自动将容器部署到选定的标准无线电节点 (SRNs) 上并开始运行实验.
Step 6: 获取数据
- 动作: 实验产生的数据从 Colosseum 域传输回用户域.
- 内容: 网络运行时指标以 CSV 格式保存在性能数据集中.
- 用途:
- 可在runtime实时查询数据作为反馈回路
- 也可在实验结束后统一下载数据以优化控制逻辑
Scope Virtualized Container 核心内容
这部分内容详细介绍了 SCOPE 虚拟化容器 的架构, 核心组件及其功能. SCOPE 容器基于 LXC 技术实现, 是一个灵活的原型设计工具包, 主要包含以下三个核心组件:
(1) Softwarized Protocol Stack
SCOPE 的协议栈基于开源软件 srsLTE (现为 srsRAN) 构建, 并对其功能进行了显著扩展, 以增强可编程性和虚拟化能力.
- 网络切片 (Network Slicing):
- 支持在同一基础设施上共存多个切片, 每个切片可针对特定流量类别 (如高数据率或低 QoS 需求) 进行定制
- 资源分配, 通过指定分配给每个切片的下行链路资源块组 (RBGs) 来实现, 并支持通过分配矩阵精确选择频谱位置
- 这些分配都可在 runtime 动态修改
- MAC 层调度 (MAC-layer Scheduling):
- 除了默认的轮询 (Round-Robin) 算法外, SCOPE 新增了 注水 (Waterfilling) 和 比例公平 (Proportionally Fair) 调度算法
- 用户还可以插入自定义调度算法, 并通过 API 在运行时为整个网络或特定切片重新配置策略
- 物理层能力 (PHY-layer Capabilities):
- 支持在运行时微调每个用户的下行链路传输功率和调制编码策略 (MCS). MCS 可以在 [0, 28] 范围内调整, 对应不同的调制方式 (QPSK, 16QAM, 64QAM) 和编码率
(2) Data Collection Module
该模块旨在解决研究界缺乏用于训练 ML 模型的大规模数据集的问题.
- 大规模数据生成: 结合 Colosseum 仿真器, SCOPE 能够在 hardware-in-the-loop 的执行环境中, 利用可重构的 RF 信道模拟几乎无限的场景和信道条件
- 指标记录: 该模块会自动记录, 并以 CSV 格式存储详细的统计数据 (thpt, MCS, buff, 切片 PRBs). 这些数据不仅用于离线训练, 还可被实时读取以实现闭环控制
(3) Open APIs

SCOPE 提供了一组 Python API, 允许用户与协议栈和数据模块进行实时交互.
- 功能控制: 支持开启/关闭网络切片, 设置切片资源和调度策略, 以及调整物理层参数 (如 MCS 和功率).
- 数据交互与闭环控制: 用户可以通过 API (
read_metrics) 查询实时性能数据, 并根据这些反馈动态调整网络配置 (例如, 当缓冲区超过阈值时更改切片资源分配), 从而实现自动化的控制逻辑. - 灵活性: 除了使用 API, 开发人员仍可直接修改底层的开源代码以访问更多参数.
Scope Emulation Environment 核心内容
这一部分详细介绍了在 Colosseum + SCOPE 蜂窝仿真环境, 以及如何创建和分析蜂窝场景:
(1) Emulation Environment
系统分为两个主要域: 用户域 (User Domain) 和 Colosseum 域 (Colosseum Domain).

- User Domain:
- 运行在用户本地机器上
- 用户在此下载 SCOPE 容器, 利用 API 实现自定义算法 (如 ML/AI), 并通过 Web GUI 选择场景, 上传容器以及最终可视化结果
- Colosseum Domain: 负责实验的配置和执行
- 硬件: 使用标准无线电节点 (SRNs), 每个节点包含一个 GPU 服务器连接到一个 USRP X310.
- 执行:
- 实验开始后, 容器自动部署
- MCHEM (大规模信道仿真器) 负责 RF 仿真, TGEN (流量生成器) 负责流量生成
- 反馈闭环: 运行时产生的数据集 (如吞吐量, CQI, PRB 分配) 可作为反馈回路, 用于评估控制决策的影响
(2) Creating Cellular Scenarios
场景由 RF 场景 和 流量场景 两部分组成.

- RF 场景 (RF Scenario):
- 原理:
- 定义了每个节点经历的信道脉冲响应 (路径损耗, 衰落等)
- MCHEM 使用 FPGA 和 FIR 滤波器将信号与信道系数进行卷积
- 干扰模拟: 信号会被转发给多个 SRN 而不仅仅是目标接收器, 从而模拟真实的干扰环境
- 位置与移动性: 支持基于 GPS 的静态或动态节点位置 (可来自 OpenCelliD 或统计模型), 以及用户移动模型
- 原理:
- 流量场景 (Traffic Scenario):
- 基于 MGEN (Multi-Generator) 工具
- 支持多种 QoS 需求和业务类型, 如 URLLC (超可靠低延迟), eMBB (增强型移动宽带) 和 mMTC (海量机器类通信), 并可映射到不同的网络切片
(3) Sample Scenarios
论文基于真实地理位置, 设计了三种不同密度的城市场景:

- Rome (罗马): 高密度场景 (0.5 \(km^2\)), 包含 10 个基站和 40 个用户
- Boston (波士顿): 城市中心场景 (0.95 \(km^2\)), 10 个基站和 40 个用户
- POWDER (盐湖城): 稀疏场景 (3.6 \(km^2\)), 模拟屋顶基站部署, 8 个基站和 32 个用户
- 配置变量: 用户分布距离 (Close/Medium/Far) + 移动速度 (Static/Moderate/Fast)
(4) Scenario Analysis
作者通过大量重复实验 (>60次) 分析了 SCOPE 的性能表现:
- 距离影响: 随着用户与基站距离增加, 下行/上行吞吐量和频谱效率均下降
- 移动性影响: 移动速度越快 (UE 越容易远离基站), 性能下降越明显
- 可重复性: 实验结果显示数据分布紧密围绕中值, 置信区间窄 (Black boxes in violin plots), 证明了 SCOPE 实验具有高度的 统计稳定性 和 可重复性
Scope Use Cases 核心内容
这一部分里, 实验数据之类的就不看了, 重点关注 ML 和 Opt 对应的架构设计图, 过一遍 workflow.
(1) ML Training Workflow:

阶段一: 初始上传 (从左到右)
[1] 设计 (User Domain): user 在本地设计了一个 AI 模型
[2] 上传 (Untrained NN): user 把这个 Untrained Neural Network 传给 Colosseum
[3] 分发训练: 这个未训练的模型被复制并分发到多个不同的训练场景 (Scenario A, B, C, D) 中同时运行
阶段二: 训练与聚合 (从右到左, 再到右)
[4] 收集数据: 在场景 A-D 运行过程中, SCOPE 会收集性能数据 (Output/Dataset)
[5] 联邦学习 (User Domain):
- 注意图左侧的 Federated Combiner (联邦聚合器). 这些数据 (或局部更新的权重) 会传回用户域
- 聚合器把各个场景里学到的经验"合并"起来, 更新 user 的模型
[6] 生成成品: 经过训练和聚合后, user 的本地模型就变成了 Trained Neural Network
阶段三: 最终验证 (中间到右)
[7] 再次上传 (Trained NN): user 把这个 Trained Neural Network 再次传给 Colosseum
[8] 考试 (Testing Scenarios): 这次它被放到测试场景 (Scenario X, Y) 中运行
[9] 评估:
- 如果在这些新场景里表现好 (Satisfactory?), 就可以通过+正式部署
- 如不好, 就回炉重造 (Fine-tune)
(2) Optimizing Control Workflow:

-
User Domain
- 用户将基于优化或启发式的控制逻辑集成到 SCOPE 中, 定义目标函数和约束条件
- 该逻辑利用 SCOPE 接口在运行时控制基站配置
-
Colosseum Domain
- 将定制容器上传至 Colosseum 并运行不同的场景 (Scenario A, B)
-
Feedback Loop
- 监控: 算法在运行时利用 SCOPE 的指标和性能数据集 (Run-time metrics) 获取网络行为反馈
- 决策: 根据反馈对网络策略 (如调度和切片) 做出决策
- 执行: 随后对基站进行实时重配置
-
验证部署:
- 当策略达到满意的行为后, 即可部署到商业蜂窝网络中
(3) SCOPE Portability:
SCOPE 的设计核心之一是"一次设计, 到处运行", 支持从仿真环境无缝迁移到异构的真实测试床.
支持的测试环境:
- Colosseum: 无线网络仿真器, 用于大规模原型设计.
- Arena: 室内办公室测试床, 天线悬挂于天花板, 距离较近 (平均 4.5m).
- POWDER: PAWR 项目的大型室外平台, 基站位于 30米高楼顶, 服务地面用户, 距离较远 (平均 345m).
移植机制 (Porting Mechanism):
- 容器化技术: 由于 SCOPE 使用虚拟化的 LXC 容器, 移植过程主要是将容器传输到目标测试床.
- 网络配置: 配置 LXC 以桥接宿主机的接口到容器.
- 硬件适配: 由于实际的无线通信由 srsLTE 处理, 只需安装特定 SDR (如 USRP X310 或 B210) 所需的驱动程序即可适配不同的硬件无线电.
Related Work 核心内容
- 现有切片方案的局限性
- 主流测试平台的对比
- SCOPE 的定位与行业对齐
(1) 现有网络切片实现方案的对比与局限性
| 研究工作/方案 | 主要内容/侧重点 | 存在的局限性/不足 |
|---|---|---|
| srsLTE 相关早期工作 (Garcia-Aviles et al., Ayala-Romero et al.) |
提出了多切片服务编排框架或基于深度学习的资源联合分配方法. | 通常局限于小规模原型验证, 未能提供大规模通用的解决方案. |
| 5G-EmPOWER (Coronado et al.) |
提供了 RAN 切片的概念验证. | 实现规模极小, 仅考虑了单个基站和两个用户设备 (UEs). |
| Koutlia et al. | 描述了支持切片的实验测试床, 侧重于策略执行和准入控制. | 切片是静态分配的, 不支持在运行时重新配置. |
| 云原生切片框架 (Marinova et al.) |
基于 NFV 的集中式云切片框架, 支持参数重配置. | 重配置需要重启基站和重新连接用户, 导致数十秒的网络停机时间, 无法满足 NextG 低延迟需求; 且缺乏供用户使用的开放 API. |
(2) 主流 NextG 实验测试平台 (Testbeds) 对比
| 平台类别 | 代表平台 | 主要能力 (Capabilities) | 部署与限制 |
|---|---|---|---|
| 室内/园区级平台 | Arena, CORNET, Drexel Grid | 专注于 Sub-6 GHz RAN 和核心网应用. | 大规模室内环境. 除 Drexel Grid 有虚拟节点外, 实验受限于物理部署. |
| 大规模/城市级平台 | Colosseum, COSMOS, POWDER, FIT, NITOS, IRIS | 支持 NFV 和编排框架 (如 O-RAN, OSM); 部分支持毫米波 (COSMOS) 和 Cloud-RAN (IRIS). |
目标是室内或城市规模的室外场景. 主要限制: 实验通常受限于 SDR 的物理部署位置 (Site Specificity). |
| 特殊平台 (仿真) | Colosseum | 世界上最大的网络仿真器, 支持 Hardware-in-the-loop. | 例外: 能够仿真不同的无线环境, 不受物理位置限制. |
文章中给出的:

(3) SCOPE 的定位优势与行业标准对齐
| 维度 | 说明 |
|---|---|
| 平台定位 | SCOPE 是上述测试平台的补充 (Complement), 而非替代品. 它作为 sub-6 GHz NextG 解决方案的原型平台存在. |
| 核心优势 | 1. 开放 API: 支持跨层 RAN 功能的实时重配置, 无需重启网络. 2. 可移植性: 采用容器化实现, 平台无关. 可无缝移植到 Arena (室内) 或 POWDER (室外) 等不同物理基础设施上运行. |
| O-RAN 对齐 | O-RAN Ready: SCOPE 的 API 设计与 O-RAN xApps 的定义高度一致. 兼容性: 使用类似的例程和结构来控制网络元素, 便于研究人员开发符合 O-RAN 标准的第三方应用 (xApps). |