跳转至

Communication As a Space Microdatacenter Bottleneck

The above analysis did not consider communication of EO data from the satellites to an SµDC. Fig. 10 shows a small constellation supported by two SµDCs in ‘ring’ topology [87]. Data from distant EO satellites is relayed to the SµDC by more proximal EO satellites. Thus, the number of connected EO satellites is potentially limited by the capacity of the ISL between the SµDC and the closest EO satellites.

A ring topology in which the SµDCs are part of the same orbit as the EO satellites has clear benefits. By flying the SµDCs in formation with the EO satellites and using a fixed ring topology, ISLs are also fixed. This is important when ISLs are optical, since optical ISLs can take seconds or even minutes to orient [32, 75]. Small satellites which contain optical ISLs often orient the ISL by rotating the entire satellite [75]. This means that the satellite cannot perform simultaneous communication and imaging. However, by using a ring topology with fixed distance and angle between satellites, satellite designers can design the ISL and camera such that they are usable simultaneously.

If one SµDC can support the computation of \(n\) satellites, but the capacity limitation of the ISL between the SµDC and the closest EO satellites dictates that the SµDC can only receive data from \(m < n\) satellites, then the number of clusters (and thus SµDCs) needed is \(\\frac{64}{m} > \\frac{64}{n}\). In this case, the constellation is ISL-bottlenecked. If \(m \\ge n\), the constellation is ISL-unconstrained.

For lightweight applications, the minimal number of SµDCs that are needed in a ring topology may not be set by the total amount of computation required, but rather by the number required to mitigate the ISL bottleneck. Table 8 shows how many EO satellites an SµDC can support before becoming ISL-bottlenecked at various

data rates and for several ISL capacities based on RF [101, 137] and optical [41, 89] LEO to LEO ISLs. This table assumes that a base (at 3 m) 4K RGB image is generated every 1.5 s on each EO, and transmitted via ISL to the SµDC. As resolution improves, so does the number of pixels in the image (i.e., the imaged area remains constant). In a ring topology, the limiting links are the ones between the SµDC and its adjacent EO satellites. Thus, for example, at 3 m resolution and \(1 \\text{ Gbit } s^{-1}\) ISL capacity, each ISL can support transmitting over four images every 1.5 s. Since the SµDC has two ISL receivers, it can support up to nine EO satellites.

The results show that \(< 100 \\text{ Gbit } s^{-1}\) ISLs are often insufficient to support even a single EO satellite for high data rates. Even \(100 \\text{ Gbit } s^{-1}\) ISLs fail at 10 cm resolutions. On the other hand, a single SµDC can support a large number of EO satellites at low data generation rates (i.e., coarse resolution and high early discard rates) — more than what would realistically be placed into a single orbital plane. This table data, combined with Fig. 9 indicates when ISL-bottlenecks or computational requirements dictate the number of SµDCs needed. Fig. 11 shows that the number of clusters, and thus SµDCs, is set by the ISL-bottlenecks for many applications — especially for high-power SµDCs. As ISL capacity increases, the bottleneck goes away, and the number of clusters required matches the number of SµDCs needed to support the computation, as in Fig. 9.

In general, it is preferable for a constellation to be ISL-unconstrained as an ISL-bottlenecked constellation means more SµDCs are launched than are strictly required based on computational power requirements. This increases constellation equipment, launch, and management costs.

Our results also show that ISLs considerations can have important influence on SµDC design for lightweight applications — high power SµDCs are more likely to be ISL-bottlenecked than a low power SµDCs. They also suggest that ISL network topology may play an important role in enabling high SµDC utilization. Thus ISL considerations will impact EO/SµDC satellite constellation design.

AI 概括:

卫星间链路 ISL 是部署 \(S \mu DC\) 的主要瓶颈

核心内容分点概括如下:

1. 识别瓶颈

  • 在考虑计算能力分析时，之前的研究并未考虑 EO 卫星将数据传输到 \(S \mu DC\) 的通信环节
  • 分析发现，EO 观测卫星与 \(S \mu DC\) 之间的 通信成为了一个瓶颈

2. 瓶颈机制与拓扑结构

  • EO 卫星通常使用卫星间链路 (ISL) 将数据卸载到 \(S \mu DC\)
  • 章节展示了 \(S \mu DC\) 在 LEO 轨道上与 EO 卫星采用“环形”拓扑结构 (ring topology) 的场景
    • 在这种拓扑中，来自较远 EO 卫星的数据通过较近的 EO 卫星中继到 \(S \mu DC\)
    • alt text
  • 如果 \(S \mu DC\) 的计算能力可以支持 \(n\) 颗卫星，但由于 ISL 容量限制，它只能接收来自 \(m < n\) 颗卫星的数据，那么该星座就处于ISL 瓶颈型 (ISL-bottlenecked) 状态
    • 在这种情况下，所需的 \(S \mu DC\) 数量由 ISL 瓶颈决定，而不是由总计算需求决定

3. 量化限制与后果

  • 定量分析表明，ISL 容量成为支持高分辨率 EO 任务的限制因素
  • 对于高数据生成速率，容量低于 100 \(\mathrm{Gbit \ s}^{-1}\) 的 ISL 通常不足以支持哪怕一颗 EO 卫星的数据传输
    • 例如，即使是 100 \(\mathrm{Gbit \ s}^{-1}\) 的 ISL，在 10 厘米分辨率下也会失效
  • 对于许多应用而言，ISL 瓶颈决定了所需的 \(S \mu DC\) 数量，尤其对于高功率的 4 kW \(S \mu DC\)。
  • 处于 ISL 瓶颈状态的星座是不可取的，因为这意味着发射的 \(S \mu DC\) 数量会超过计算能力严格要求的数量，从而增加星座的设备、发射和管理成本

4. 引出解决方案

  • 鉴于 ISL 瓶颈会严重影响 \(S \mu DC\) 的有效利用，下一章节提出了三种 \(S \mu DC\)-通信协同设计策略来缓解这一瓶颈，包括 \(k\)-list 网络拓扑、微数据中心拆分以及将 \(S \mu DC\) 转移到地球静止轨道