跳转至

Experimental Setup

We implemented Umbra in a simulator using about 500 lines of Python code. We plan to release our simulator code in the public domain. In our experiments, we inject traces derived from Planet Inc.’s Dove constellation [37] into our simulator.

我们在一个模拟器中，使用约500行Python代码实现了Umbra系统。我们计划将此模拟器的代码开源。在实验中，我们将源自 Planet公司“鸽群”星座 (Dove constellation) [37] 的追踪数据注入到我们的模拟器中进行评估。

汇总一下实验配置, 后期我们实验可以借鉴规模
  1. 153颗在轨道卫星
  2. GSL bandwidth: 2Gbps
  3. Backhaul bandwidth: 100Mbps ~ X Gbps

5.1 Satellite Constellation

Our satellite dataset from Planet Inc. contains orbital data collected from 153 satellites in orbit as part of the Dove satellite constellation [37]. These satellites orbit around the Earth in one of two polar orbits, as shown in Fig. 8, and collect RGB and NIR (near infrared) imagery.

Imagery: We run each of our data transmission plans on imagery collected from these satellites for 15 days spread across three months (the first five days in June, July, and August 2021). We access the metadata of the imagery collected on these satellites using the Planet Developer API 2 . Each image is approximately 300 MB in size, and spans at least 24 km by 8 km distance on Earth depending on the satellite hardware and the variability in its altitude. In total, we collect data for nearly 6 million images. To the best of our knowledge, this is the largest evaluation involving any satellite dataset. Table 1 shows a summary of these statistics.

Ground Station: We model Planet’s ground station architecture using publicly released information. Specifically, we simulate 12 ground stations carrying a total of 48 antennas [9, 12]. Fig. 8 shows the ground station locations.

Network Properties: We follow the radio architecture reported in [13] for simulating the satellite-ground station communication, achieving a bandwidth of up to 2 Gbps. Public information on available bandwidth for ground stationcloud backhaul links is scant. We have been in communication with multiple satellite operators. We use a combination of the anecdotal information we collected via these conversations, along with public domain information [38], to derive typical ground station-cloud bandwidths. We estimate the backhaul bandwidth values to be generally around 1 Gbps, but varying from 100Mbps to a few Gbps depending on the location. In our experiments, we vary ground station-cloud bandwidths.

alt text

我们使用的卫星数据集来自Planet公司，包含了其“鸽群”星座中 153颗在轨卫星 的轨道数据 [37]。如图8所示，这些卫星在两条 极地轨道 (polar orbits) 上环绕地球运行，并采集RGB（可见光）与近红外（NIR）图像。

  • 图像数据 (Imagery): 我们的数据传输计划运行在这些卫星于三个月（2021年6月、7月和8月）中总计15天（每月的前5天）所采集的图像上。我们通过Planet开发者API获取卫星采集图像的元数据。每张图像的大小约为300MB，根据卫星硬件及其高度的变化，在地面上的覆盖范围至少为24公里×8公里。我们总共收集了近600万张图像的数据。据我们所知，这是所有涉及卫星数据集的评估中规模最大的。表1总结了这些统计数据。

  • 地面站 (Ground Station): 我们根据公开信息对Planet公司的地面站架构进行建模。具体来说，我们 模拟了12个地面站，共搭载48根天线 [9, 12]。图8显示了这些地面站的地理位置。

  • 网络属性 (Network Properties): 我们遵循文献[13]中报告的无线电架构来 模拟星地通信，实现了高达2 Gbps的带宽 。关于地面站到云端的回程链路 (backhaul links) 可用带宽的公开信息非常匮乏。通过与多家卫星运营商的沟通，我们结合了收集到的经验性信息和公开领域的信息[38]，推导出典型的地面站-云端带宽值。我们估计 回程带宽通常在1 Gbps左右 ，但根据地理位置的不同，会在100Mbps到数Gbps之间变化。在实验中，我们对地面站-云端的带宽进行了调整。

5.2 Trace-driven Simulator

We evaluate Umbra in a discrete-event simulation. The simulator keeps track of both: i) internal status of the ground station, i.e., time, image queue, upload bandwidth, etc., and ii) satellites, i.e., time, position, captured images, etc. It simulates the system at a time granularity of 1 minute periods. This simulator is decoupled from Umbra’s control plane in Section 4, allowing us to explore stale plans, failures, etc.

Simulator execution is fine-grained. During each time step, the simulator computes the bandwidth between each ground station-satellite pair, and then simulates the scheduling algorithm’s execution plan on the waiting data at each node.

Simulating Orbital Motion and Bandwidths: We use TLEs obtained from Celestrak [29] to calculate the position, and velocity of satellites in orbit using the PyOrbital library 3 . The TLEs are periodically updated for accuracy—depending on the timestamps of the image being used, we retrieve the most up to date TLE information from Celestrak for our simulation. We predict satellite radio bandwidth by using the International Telecommunication Union (ITU) model [2628] which takes as input satellite distance, elevation, azimuth, and local precipitation at the ground station. Weather information is pulled via the DarkSky weather API [10].

Hardware: We run our simulator and optimization framework on a SuperMicro SYS-4028GR-TR 4 server. To benchmark the time taken by our scheduler, we run the scheduler on a single core. It takes approximately 25 minutes to schedule satellite traffic for a 5-day run of the entire constellation. This time could be optimized further by leveraging parallelization, especially for computing the Hungarian matching (Section 3). However we do not explore this because we expect plans to be infrequently updated.

我们在一个 离散事件模拟 (discrete-event simulation) 环境中对Umbra进行评估。该模拟器同时追踪：

i) 地面站的内部状态（如时间、图像队列、上传带宽等）

ii) 卫星的状态（如时间、位置、已捕获图像等）

它以1分钟为 时间粒度 (time granularity) 来模拟系统。此模拟器与第4节中描述的Umbra 控制平面 (control plane) 相解耦，使我们能够探究过时计划、组件故障等情况的影响

模拟器的执行是 细粒度的 (fine-grained)。在每个时间步长中，模拟器会计算每对星地组合间的带宽，然后模拟调度算法的执行计划对每个节点上待处理数据的操作:

  • 模拟轨道运动与带宽:

    • 我们使用从Celestrak [29] 获取的TLE数据，并通过PyOrbital库来计算卫星在轨的位置和速度
    • 为保证精度，TLEs会周期性更新——我们根据所用图像的时间戳，从Celestrak检索最新的TLE信息用于模拟
    • 我们采用 国际电信联盟 (ITU) 的模型 [26-28] 来预测卫星无线电带宽，该模型将卫星距离、仰角、方位角以及地面站当地的降水量作为输入
    • 天气信息通过DarkSky天气API [10] 获取

  • 硬件配置 (Hardware):

    • 我们的模拟器和优化框架运行在一台SuperMicro SYS-4028GR-TR服务器上
    • 为了对调度器的耗时进行基准测试，我们在单个核心上运行调度器
    • 为整个星座安排一个为期5天的卫星流量计划，大约需要25分钟。通过利用并行化 (parallelization)，特别是计算匈牙利匹配（第3节）时，这个时间可以被进一步优化。但我们未对此进行深入探究，因为我们预期计划的更新频率不高

5.3 Baselines vs. Umbra

We compare Umbra against three baselines:

(1) Greedy: This is the status quo: fast “greedy” transfers (Section 1) that fully utilize satellite-ground links. We use the ground station-satellite matching using past work [44].

(2) Withhold – Naive: Inspired by public documentation [13] where satellites skip over-subscribed ground stations, we designed a simple withhold scheduling strategy. In this strategy, the satellite compares the current queue sizes at its current ground station contact and its next (expected) ground station contact. If the next ground station contact currently has a smaller queue than the current ground station, the satellite decides to withhold all of its data, and instead transmits it to the next ground station.

(3) Withhold – Smart: We also design a more complex heuristic-based withholding approach in which a satellite transfers an amount of data inversely proportional to its current queue size at the ground stations. Namely, denote \(q_1\) , \(q_2\) as the queue size for the current gs and the next contact gs, and denote \(V\) as the total volume of the cached data on satellite. Then, the satellite will transmit \(V_0 = \frac{q_2}{V_{q_1 + q_2}}\) volume of data during the current contact.

Our key metrics are: (a) Throughput: How much data can a scheme transmit per day? and (b) End-to-end Latency: How long does it take for an image from the time of its capture to get to the cloud?

我们将Umbra与以下三种基准方案进行比较：

  1. 贪心策略 (Greedy): 这是当前普遍采用的方案：执行快速的“贪心”传输（第1节），旨在完全利用星地链路。我们使用先前工作[44]中提出的地面站-卫星匹配方法。

  2. 暂缓策略 - 朴素版 (Withhold – Naive): 受到公开文档[13]中“卫星会跳过超负荷地面站”的启发，我们设计了一种简单的暂缓调度策略。在该策略中，卫星会比较其当前接触的地面站和下一个（预期的）地面站的队列长度。如果下一个地面站的当前队列比当前地面站的短，卫星则决定暂存其所有数据，转而传输给下一个地面站。

  3. 暂缓策略 - 智能版 (Withhold – Smart): 我们还设计了一种更复杂的、基于启发式的暂缓方法。在该方法中，卫星传输的数据量与其当前接触的地面站队列大小成反比。具体而言，记 \(q_1\) 和 \(q_2\) 分别为当前和下一个接触的地面站队列长度，记 \(V\) 为卫星上缓存的总数据量。那么，卫星在当前接触窗口将传输 \(V_0 = \frac{q_2}{V_{q_1 + q_2}}\) 的数据量。

我们的 关键指标 (key metrics) 是:

  1. 吞吐量 (Throughput): 一种方案每天能传输多少数据？
  2. 端到端延迟 (End-to-end Latency): 一张图像从被捕获到抵达云端需要多长时间？