LEOScope: Building a Global Testbed for Low-Earth Orbit Satellite Networks¶

本文介绍了一个名为 LEOScope 的全球性测试平台, 旨在对 LEONET 进行大规模的性能测量和瓶颈分析.

目标是: 建立一个类似于 "PlanetLab" 的 LEO 版本, 提供广泛的地理覆盖, 支持自定义实验, 并适应 LEO 网络的高动态特性.

alt text

Introduction 核心内容

(1) 现有研究的局限性:

类别1: 在特定区域的单点测量
- 代表:
  - A Starlink-Based Measurement from End Users (INFOCOM'23)
  - A First Look at Starlink Performance (IMC'22)
  - Connecting the Dots in the Sky (NDSS'24)
  - Better Fill Up Your Pipe (LEO-NET'25)
- 问题: 难以复现 + 特定区域的数据结论难以泛化
类别2: 基于公共平台的非受控数据收集
- 代表:
  - A Multifaceted Look at Starlink Performance (WWW'24)
  - Dissecting the Performance of Satellite Network Operators (CoNEXT'23)
- 问题: 公共平台的隐私保护导致参数缺失
类别3: 开源仿真模拟
- 代表: Hypatia, StarryNet, xeoverse
- 问题: 可以建模, 但不能完整捕获真实互联网的所有特征

(2) LEOScope 的提出:

为了解决上述问题, 作者推出了 LEOScope, 这是一个可扩展的全球 LEO 卫星网络测试平台. 它旨在补充现有的地面互联网测试平台, 帮助研究人员理解 LEO 网络的细微差别并在全球范围内进行大规模创新.

(3) LEOScope 特点:

广泛的地理覆盖:
- 为了对全球 Starlink 网络进行测试, LEOScope 具有广泛的地理足迹, 涵盖了欧洲, 非洲和北美 7 个国家的大学和志愿者家庭节点.
- 其中, 志愿者节点对于覆盖无法部署大学节点的偏远地区至关重要.
高度灵活性(Docker 容器化):
- 与限制实验类型的传统测试平台不同, LEOScope 允许用户以 Docker 容器的形式运行自定义实验.
- 这意味着几乎任何可以封装在容器中的功能(如 Ping, CDN 测试等)都可以在平台上运行.
- 这对于处于早期探索阶段的 LEO 网络测量至关重要.
适应动态变化的调度机制(Trigger Mode):
- 为了捕捉 LEO 网络的动态特性(如卫星切换, 延迟波动), LEOScope 开发了 trigger mode, 支持基于特定条件(如延迟峰值, 恶劣天气, 太阳风暴等)自动调度实验.
- 同时也支持类似 cron job 的定期调度.
完善的保障措施(Scavenger Mode 与伦理规范):
- 技术保障: 引入了 scavenger mode, 系统会持续感知志愿者是否正在使用网络, 并自动推迟实验以避免干扰志愿者的正常网络使用.
- 非技术保障: 要求实验者上传 IRB(机构审查委员会)批准证明或完成安全检查清单, 并签署最终用户许可协议(EULA), 以防止滥用和确保负责任的研究.

核心功能

trigger mode: 支持基于特定条件的实验自动调度
cron job: 定时调度
scavenger mode: 自动感知志愿者是否正在使用网络, 并推迟实验以避免干扰他的正常网络使用

(4) 社区号召:

论文旨在通过展示 Starlink 的性能测量案例来证明 LEOScope 的实用性, 并呼吁广大研究社区贡献节点和使用该平台, 共同推动 LEO 测量研究的发展.

Related Work 核心内容

对比对象	现有平台的特点/局限	LEOScope 的优势/区别
PlanetLab / EdgeNet	拥有全球规模, 支持运行任意实验(Docker 容器).	目标是成为 "LEO 宽带版的 PlanetLab"; 保留了运行任意实验(Docker)的灵活性, 但针对 LEO 的独特性进行了专门设计.
RIPE Atlas	虽然探针也被用于 Starlink 测量, 但通常仅能运行一组受限的标准实验(如 Ping, DNS, NTP 等).	更加灵活, 允许在协议框架内运行新的, 创新性的用户自定义实验.
M-Lab	运行一套Google固定的, 经过仔细审查的实验(主要是服务器端); 实验仅在用户主动发起时进行.	提供 "触发器模式"(Trigger Mode), 可指定丰富的触发条件来自动驱动网络性能测试.
BISmark / SamKnows	通过向家庭发送特制路由器进行宽带测量.	与它们不同, LEOScope 主动设计为支持包含任意功能的实验.
无线/蜂窝测试平台 (FABRIC/PhoneLab/Orbit-Rutgers)	运行成功但未针对 LEO 的动态特性进行调整.	集成了卫星特定遥测数据, 基于事件的触发机制(用于精确测量切换等现象)以及资源感知操作(拾荒者模式).
核心总结	缺乏针对 LEO 卫星网络特性的专门设计(如轨道动态, 卫星遥测结合).	首个专门为 LEO 卫星网络研究设计的测量平台, 结合了网络性能测量与卫星定位数据, 并具备硬件灵活性.

看看论文里整理的核心"对比对象+对比指标"表格, 非常值得借鉴学习:

alt text

Design Considerations 核心内容

设计目标与驱动因素:

LEOScope 旨在支持多样化的网络研究用例, 从测量视频流等应用在 LEO 上的表现, 到设计适应 LEO 网络需求的新协议.
设计主要由两大需求驱动:
- 地理覆盖的多样性 (因为 LEO 性能随纬度变化)
- LEO 星座的动态性 (卫星切换, 天气影响, SNR 变化 ...)

亮点1: 多样化节点部署

为了支持地理多样性并覆盖偏远地区, LEOScope 不仅支持传统的大学节点, 还支持志愿者家庭节点.

亮点2: 拾荒者模式 (Scavenger Mode) - 保护志愿者

(1) 目的:

确保高带宽消耗的实验(如 iperf)不会干扰志愿者(主用户)的正常网络使用(如视频会议或看 Netflix).

(2) 机制:

利用 Starlink 遥测数据监控总流量 (\(t_{all}\)) 和 Docker API 监控实验流量 (\(t_{expt}\))
系统计算志愿者自身流量 (\(t_{all} - t_{expt}\))
如果超过阈值 \(\Delta\), 则判定志愿者正在使用网络, 并按占用带宽降序停止实验

(3) 特性:

允许不影响志愿者的 "轻量级" 实验(如 ping)继续运行
被停止的实验会被重新调度
志愿者可以设置每月的流量上限

亮点3: 触发器模式 (Trigger Mode) - 应对动态性

针对 LEO 连接质量的动态变化, 设计了类似 IFTTT (If This Then That) 的触发模式
允许基于外生因素(如雨雪天气)或内生因素(如高延迟, 低吞吐量)自动触发特定的实验

亮点4: Cron 模式 (Cron Mode) - 定时任务

支持使用 crontab 语法在预定时间点或以固定间隔调度实验
适用于需要统计有效性的重复测量或特定时间段(如: 晚高峰)的测试

亮点5: 互斥调度 - 避免实验干扰

由于所有容器共享同一 Starlink 连接, 某些实验可能会相互干扰
允许将实验标记为带宽敏感型 (bandwidth sensitive), 系统会确保此类实验互斥运行, 避免同时执行

如何理解: 互斥调度

这里每个 Starlink 终端(Dish)都是 Single-node level 的

LEOScope 由分布在世界各地的多个独立节点组成
每个地理位置的节点都有自己独立的 Starlink 终端(Dish)和独立的网络连接

现在我们想说的是: 单个节点上, 如果有一堆containers, 会干扰自身的网络测量实验

比如, 如果 user-a 的实验目的是为了测速(例如: 想看看卫星切换时网速最快能到多少), 他就需要独占整个带宽

如果此时另一个 user-b 的实验也在后台下载数据, user-a 测出来的 "最大网速" 就会变低, 这会导致 user-a 的实验数据不仅不准确, 甚至是错误的

所以, 问题的本质是: 尽管 Docker 保证了实验环境的独立, 但无法解决共享带宽带来的干扰!

为了解决这个问题, LEOScope 允许实验申请 "独占时段", 在此期间系统会禁止其他实验运行, 以确保该实验能独享整个 Starlink 连接

Architecture Details 核心内容

这一部分按照 workflow / dataflow 的顺序整理

alt text

整个过程可以分为三个阶段: 调度阶段, 执行阶段, 数据收集与展示阶段

阶段一: 调度与分发 (Scheduling & Distribution)

(1) 用户提交

研究人员通过 Web UI 提交实验请求, 定义实验内容(Docker 容器), 调度方式(Cron/触发器), 选择目标节点

(2) 编排与决策

Cloud Orchestrator 接收请求, 检查节点健康状况, 并评估新请求是否与现有时间表冲突.

如果需要服务器配合, Orchestrator 会先通知 Measurement Server 下载 experiment artifacts, 并启动监听环境.

(3) 指令下发

Measurement Client 会定期向 Orchestrator 发送 "心跳包" (Heartbeat).

由于 Client 在 NAT 后面, Orchestrator 无法直接发号施令, 而是将实验调度指令 "搭载" (piggyback) 在心跳包的响应中传回给 Client.

piggyback 的实现方式

(1) RESTful API [json over http]

RESTful 是一种软件架构风格, 可以查阅 RESTful - Wikipedia

NAT 网关通常允许内网设备主动发起的出站连接(Outbound), 并会暂时保留端口映射以允许响应数据包(Inbound)回传

JSON
// Client 发送请求: POST /api/heartbeat
{
    "node_id": "london-01",
    "status": "healthy",
    "current_load": "low"
}
// Orchestrator 返回响应 (搭载指令): 200 OK
{
    "ack": true,
    "next_heartbeat": 30,
    "commands": [  // "Piggyback" Commands
        {
        "type": "start_experiment",
        "image": "docker.io/leoscope/iperf-test",
        "args": "-c server.ip -t 10"
        }
    ]
}

(2) gRPC [基于 Protocol Buffers]

gRPC 的神奇之处在于, 它让 Measurement Client (本地) 觉得 "我只是调用了一个本地的函数".

但实际上这个函数是在 Cloud Orchestrator (远程) 上运行的, 并且返回值(包含了搭载的指令)是从 Orchestrator 传回来的.

定义 .proto 文件: Server 和 Client 必须遵守同一份协议(Protocol Buffers), 规定好数据长什么样
Client Node 角度(位于 NAT 后, 发起者)
- 不知道服务器什么时候有任务给它, 它只管按时打卡
- 动作: 客户端代码像调用本地函数一样调用 SendHeartbeat()
- 因为是 Client 主动发起的 TCP/HTTP2 连接, 家里的路由器(NAT)会允许数据出去, 并建立映射等待数据回来
Server 角度(位于公网, 被动者)
- 不能主动连接客户端, 它只能被动等待客户端来 "打卡". 一旦客户端来了, 它就抓住这个机会, 把积压的任务 "塞" 进返回包里
- 动作: 实现 SendHeartbeat() 函数的逻辑

在这个场景下, gRPC (google Remote Procedure Call) 的 "远程调用" 体现在: local client 远程调用 remote server 的函数, 返回值是从 remote server 返回的.

Server 从未主动建立连接(connect), 它只是在 Client 建立的连接上 return 数据. NAT 路由器允许这种 "有去有回" 的流量

阶段二: 实验执行 (Execution)

(4) 环境准备

Client 收到指令后, 下载必要的 experiment artifacts, 并设置本地环境.

(5) 实际运行

Client 的执行器 (Executor) 启动 Docker 容器运行实验:

如果是单端实验(如: ping 8.8.8.8), Client 独自完成.
如果是双端实验(如: iperf), Client 会向已经在云端准备好的 Server 发起网络连接进行测试.

(6) 本地监控

在实验运行期间, Client 的 "终端数据消费者" 服务会持续从 Starlink 终端读取遥测数据(用于拾荒者模式判断或数据关联).

阶段三: 数据回传与展示 (Data Collection & Visualization)

(7) 数据上传

Client 和 Server 生成的实验结果数据, 不会传回 Orchestrator 的数据库, 而是直接推送到 Cloud Storage.

数据存储结构是分层级的目录, 便于按节点或实验实例查找.

(8) 数据后处理

Orchestrator 使用后处理库从 Cloud Storage 拉取原始数据.

(9) 结果展示

处理后的数据生成图表和见解, 最终显示在用户的 Web Dashboard 上.

alt text

Measurement Clients 和 Measurement Servers 内部运行着四个核心服务, 概括如下:

MClient 就是用户本地的机器, MServer 是云端服务器. 这两个在整个系统里的角色就是"worker".

调度服务 (Scheduler Service)
- 负责处理来自云编排器(Cloud Orchestrator)的实验时间表
- 并相应地更新本地系统的 cron 守护进程, 以安排任务执行
实验执行器 (Experiment Executor)
- 这是一个容器, 负责根据编排器批准的时间表, 实际执行网络实验
终端数据消费者 (Terminal Data Consumer)
- 持续收集用户终端(如: Starlink Dish)公开的遥测数据
- 这些数据不仅有助于后续分析, 还可能作为条件触发额外的调度任务(即: trigger-mode)
心跳服务 (Heartbeat Service)
- 负责定期向编排器发送信号, 告知该节点处于存活和正常运行状态

Appendix 操作说明书

(1) 平台目标与社区参与

LEOScope 旨在实现 LEO 卫星网络测量的大众化, 并大规模推动网络创新
论文呼吁研究社区通过注册账号或贡献节点的方式加入该平台
社区可以通过邮件或 Slack 频道参与讨论

(2) 如何运行实验

研究人员需要在 LEOScope官方网站 上创建账户
实验被封装为 Docker 容器运行
实验执行依赖于一个 YAML 配置文件, 其中详细说明了云端结果的存储位置和实验运行器的具体信息
平台提供了操作文档以及一个 Ping 测试的示例作为模板. 未来计划建立一个常用实验的 Docker 镜像库供社区重用.

(3) 如何贡献节点

贡献节点相对简单, 只需在 Starlink 终端后配置一台小型计算机(如 Intel NUC)
在网站注册节点, 然后克隆并运行测试平台的代码库, 操作指南
志愿者可随时退出或暂时关闭节点, 可通过用户界面设定特定时间段将节点接入 LEOScope

(4) 资源管理与计费

实施了计费功能来跟踪和监控资源使用情况, 通过键值(KV)结构记录指标
节点管理员可以定义每月的流量使用上限, 以确保公平和可持续的资源分配
计数器会在月底重置

(5) 确保负责任的使用与安全

保护志愿者网络: 实施 "拾荒者模式"(Scavenger mode), 确保实验不干扰志愿者的主要网络使用
技术安全措施:
- 网络隔离: 节点应用程序在连接 Starlink 的 Linux 机器上通过单独的 VLAN 或子网隔离
- Docker 加固: 禁用 host 网络模式, 配置自定义网桥, 防止访问本地局域网
- 最小权限: 容器以最小权限运行(丢弃所有不必要的能力, 使用只读文件系统)
- 审计: 限制对 Docker socket 的访问(仅限 root), 并审计容器部署以防止端口暴露
法律与流程保障:
- EULA: 要求签署最终用户许可协议, 规定不损害测试床资源的法律责任
- 入职培训: 要求研究人员尊重志愿者的隐私, 严禁访问志愿者家庭私有网络或去匿名化节点
- 伦理审批: 每个新实验需上传 IRB(机构审查委员会)批准文件, 或通过一份轻量级的安全检查清单

(6) 与现有平台的对比优势

LEOScope 填补了现有平台(如 RIPE Atlas, M-Lab, PlanetLab)在 LEO 特定功能上的空白, 具有以下独特能力:

遥测集成: 结合了网络性能测量与卫星定位数据
事件触发: 支持基于卫星事件(如切换)触发测量
资源感知: 通过拾荒者模式确保不干扰志愿者
硬件灵活性: 支持多种硬件配置,降低志愿者参与门槛