In-orbit Computing as a Service

The premise of our thought experiment is simple: what if instead of restricting themselves to offering network connectivity, the planned LEO constellations also offer computing as a service? Thus instead of being only ISPs, what if these operators also become “in-orbit computing providers” much like cloud computing providers, but above the clouds?

We first attempt to make a positive case for the above proposition by examining which applications may benefit from the unique characteristics of in-orbit computing.

我们思想实验的前提很简单：如果规划中的LEO星座不仅仅局限于提供网络连接，还提供计算即服务，那会怎样？也就是说，如果这些运营商不仅是互联网服务提供商（ISP），还成为“在轨计算提供商”——类似于云计算提供商，但位于真正的“云层之上”呢？

我们首先通过审视哪些应用能从在轨计算的独特性中受益，来为上述命题提供一个积极的论证。

CDN and edge computing

Content distribution networks invest heavily in building points of presence close to users to minimize latency as much as possible. Nevertheless, the reach of CDNs is limited by several factors: in some geographies, there is no suitable support and power infrastructure for edge sites, or operations are made difficult by political or jurisdictional issues. As a result, in large parts of the world, CDN edge latencies still exceed 100 ms [18, 19, 24, 45]. As prior work has shown, even tens of milliseconds of additional round-trip latency deteriorate Web browsing page load times substantially [11].

Further, for new, upcoming applications like augmented reality, latencies beyond small tens of milliseconds are prohibitive. AR is considered a key component of our future interactions with computing, with a diverse set of envisioned applications, e.g., in education [56], in e-commerce [46], assisting workers by augmenting their environment with helpful information [16], assisting drivers [51], etc. More broadly, many such networked applications that depend on low latency for rich interactivity are being referred to as “Tactile Internet” applications [1, 20, 57]. Many of these applications depend on data fetched or processed from nearby edge computing infrastructure, with tight latency requirements.

In-orbit computing could serve these needs by providing lowlatency compute access everywhere on Earth. Fig. 1 shows the round-trip times from ground locations at different latitudes to two planned LEO constellations, Kuiper and Starlink. For Starlink, we only use the Phase I configuration, comprising 4,409 satellites, as details for the rest of the constellation are sparse. For each constellation, we compute the RTT from a ground location every minute over two hours, and use the maximum value across these measurements. We do so for the nearest reachable satellite, as well as the farthest (directly) reachable satellite. The nearest reachable satellite is within ∼4 ms at most latitudes for both constellations. Kuiper’s design does not provide service beyond 60°latitude. Starlink’s nearest satellite is within 11 ms RTT across all possible ground locations at all times. Even the farthest directly reachable satellite is within 16 ms RTT. Of course, these numbers are computed accounting for only propagation delays, so true latencies will be somewhat higher.

One satellite may not offer a large amount of available compute, so we quantify how many satellites are reachable from a ground location at any time. As Fig. 2 shows, for Kuiper, 10+ satellite-servers would be reachable from any location for most latitudes Kuiper services. For Starlink, 30+ satellites are reachable from almost all locations at all times; typically more than 40 satellites are reachable. These numbers are similar to what is being envisioned for “cloudlets” or edge computing sites [10, 48]. Note that given the result in Fig. 1 on the latency to the farthest directly reachable satellite, all of these satellites are reachable within a small RTT.

Somewhat surprisingly, if just one server were added to each of its satellites, Starlink, with 40,000 planned satellites at its full scale, would be only 7× smaller than the largest present-day CDN, Akamai [3]. Also given that today’s CDN infrastructure is skewed, with larger clusters near metro areas, in-orbit compute could very well suffice to meet the needs of sparsely populated areas not covered by CDNs.

Thus, in-orbit computing over large LEO constellations could bring substantial edge computing capabilities to any location on the planet, allowing low-latency access to these resources. This can help truly bridge the digital divide: to ensure that remote or under-served areas are not left out of the next computing revolution, access to proximal compute is as essential as access to networking.

内容分发网络（CDN）投入巨资建设靠近用户的存在点（points of presence），以尽可能地降低延迟。然而，CDN的覆盖范围受到多种因素的限制：在某些地区，缺乏适合边缘站点的支持和电力基础设施，或者政治及司法管辖问题使得运营变得困难。因此，在全球大部分地区，CDN的边缘延迟仍然超过 100 ms [18, 19, 24, 45]。正如先前的研究所示，即使是几十毫秒的额外往返延迟，也会显著恶化网页浏览的页面加载时间 [11]。

此外，对于像增强现实（AR）这样新兴的应用，超过几十毫秒的延迟是无法接受的。AR被视为我们未来与计算交互的关键组成部分，其应用场景设想丰富多样，例如，在教育领域[56]、电子商务[46]、通过在环境中增强有用信息来辅助工人[16]、辅助驾驶员[51]等。更广泛地说，许多这类依赖低延迟以实现丰富交互性的网络应用，被称为“触觉互联网”应用[1, 20, 57]。这些应用大多依赖于从附近的边缘计算基础设施获取或处理数据，并有严格的延迟要求。

在轨计算可以通过在地球上任何地方提供低延迟的计算访问来满足这些需求。图1显示了地面不同纬度位置到两个规划中的LEO星座——Kuiper和Starlink——的往返时间（RTT）。对于Starlink，我们仅使用其第一阶段（Phase I）的配置，该阶段包含4,409颗卫星，因为星座其余部分的细节很少。对于每个星座，我们在两小时内每分钟计算一次从地面位置出发的RTT，并取这些测量值的最大值。我们分别对最近和最远的可（直接）达卫星进行了计算。结果显示，对于两个星座，在大多数纬度地区，最近的可达卫星延迟都在 ∼4 ms以内。Kuiper的设计不为纬度 60° 以上的地区提供服务。而Starlink的最近卫星在所有时间和所有地面位置的RTT都在 11 ms以内。即使是最远的可直接到达卫星，RTT也在 16 ms以内。当然，这些数字仅考虑了传播延迟，因此真实延迟会略高一些。

一颗卫星可能无法提供大量的可用计算资源，因此我们量化了在任何时间点，一个地面位置可以访问多少颗卫星。如图2所示，对于Kuiper星座，在其服务的大多数纬度地区，任何位置都可以访问 10 颗以上的卫星服务器。对于Starlink，几乎所有位置在任何时候都可以访问 30 颗以上的卫星；通常可达卫星数量超过 40 颗。这些数字与“云微粒（cloudlets）”或边缘计算站点的设想规模相似[10, 48]。值得注意的是，鉴于图1中到最远可直接到达卫星的延迟结果，所有这些卫星都可以在很小的RTT内被访问。

有些出人意料的是，如果Starlink的每颗卫星都增加一台服务器，那么在其全规模规划的 40,000 颗卫星下，其规模将仅比当今最大的CDN服务商Akamai小7倍[3]。同时，考虑到当今CDN基础设施的分布不均，大型集群多集中在都市区附近，在轨计算很可能足以满足CDN未覆盖的人口稀少地区的需求。

因此，基于大型LEO星座的在轨计算可以为地球上任何地点带来强大的边缘计算能力，允许对这些资源的低延迟访问。这有助于真正地弥合数字鸿沟：要确保偏远或服务不足的地区不被下一代计算革命所抛下，获得近端计算的途径与获得网络连接同样至关重要。

Multi-user interaction

A variety of applications involve multiple users participating in an interactive activity, such as online gaming, collaboratively playing music, learning in a shared online classroom, or more broadly, immersion in the same virtual environment. In these applications, often the multi-user group’s experience is contingent on every participant receiving low latency connectivity to the server hosting the application, which we shall refer to as the “meetup server”. For some applications, like gaming, it is also important that latency differences across users are small, so that each user’s experience is somewhat consistent, and in competitive settings, no user has a significant disadvantage compared to others.

许多应用涉及 多个用户参与一个交互式活动 ，例如在线游戏、协同演奏音乐、在共享在线课堂中学习，或更广泛地沉浸在同一个虚拟环境中。在这些应用中，多用户群体的体验往往取决于 每个参与者到托管应用的服务器（我们称之为“汇合点服务器”）是否都有低延迟连接。对于某些应用（如游戏）， 用户之间的延迟差异小也很重要，这样每个用户的体验才能相对一致，并且在竞争环境中，没有用户会比其他人处于明显劣势。

Today, these problems are side-stepped by restrictions on which users can participate together, e.g., by matchmaking in online games, which typically accounts for player latencies to the game server. This is, of course, limiting, as it prevents certain sets of users from participating with their friends. With in-orbit computing, this limitation can be overcome: for a large LEO constellation, there is always a satellite that provides nearly the minimum-possible latency for the user group as a whole, instead of being limited by the location of the terrestrial game servers.

Consider the example shown in Fig. 3. Microsoft Azure, which claims to have “more global regions than any other cloud provider” [5] has two data center regions in Africa. Three users in West Africa need a meetup server for an interactive application. The nearest Azure data center that could host the meetup server is 9,200 km round-trip from the farthest of these three users, and her latency to this server will determine their experience. Even using the Starlink LEO constellation to connect the users to this terrestrial meetup server, we find that the RTT would be as high as 46 ms. On the other hand, the RTT to a meetup server hosted using in-orbit compute on the same constellation would be 16 ms, an almost 3× reduction. For applications like augmented and virtual reality, much smaller differences would suffice to make the terrestrial server entirely unworkable, while the in-orbit server would provide high quality of experience. Note that in line with Starlink’s model [47], we assume that user terminals can communicate directly via satellites without any gateway intervention.

This use case is most relevant to two types of user-groups: ones where most of the users in the group are relatively far from a data center (like in the above example, but broadly in Africa, South America, and large parts of Asia), and ones where each user themselves may be near a data center, but there is no one data center location that provides low latency for all users, such as for a user group partitioned across the Americas and Eurasia. A particularly illustrative example of the latter type is seen on the Kuiper constellation’s first phase planned deployment, where for users in 3 locations that each have an Azure data center — South Central US, Brazil South, and Australia East — the best terrestrial meetup server incurs 97 ms, while an in-orbit server can achieve 66 ms latency. This lower latency can improve quality of experience for gamers [7, 42]. For other applications, e.g., ones needing real-time haptic feedback [1, 57], the upper bound on acceptable latency may be smaller still; this will limit the physical separation of users of such applications for any deployment, but a lower latency architecture allows greater separation between users, and thus expands the communities served by such applications.

Processing space-native data

In-orbit computing resources would necessarily be much more limited in quantity and more expensive than terrestrial cloud resources (§4). Moving data from terrestrial sources to satellites for computing would also be costly. Thus, for most cloud applications, in-orbit compute would be unattractive.

However, many applications generate their data in space, e.g., Earth imagery, weather observations, and remote sensing. Data analytics on “Big Earth Observation Data” [12, 13, 35, 55] is seen as a lucrative and expanding market [41], so much so, that Amazon recently launched its “AWS Ground Station” service targeting this segment. At least one of the LEO networks planned, Starlink, has hinted that its satellites may additionally produce such sensing data [40]. Would processing this data at satellite-servers, in line with the “near-data processing” paradigm [6], be fruitful?

Satellites performing imagery and sensing are capable of multiGbps data production, but their sensing time is limited by data transmission capacity to ground stations [21, 22]. 1 Thus, pre-processing this data using in-orbit compute could increase sensing time, and decrease the bandwidth cost of downloading this data and further processing it terrestrially.

A constellation with several thousand satellites could potentially perform such data processing in-orbit. The inter-satellite bandwidth is likely to be less constrained [2, 36, 37], and would allow satellites to process data cooperatively. Unlike terrestrial data centers, where latencies between servers are a few microseconds, satellite-satellite communication will incur milliseconds, but this should still be sufficient for bulk processing on the large volumes of data involved.

Another benefit of using satellites for such compute is that it allows better use of LEO infrastructure. At any time, a large fraction of a network-only constellation’s resources are above areas where they do not provide useful connectivity. Opportunistic in-orbit data processing can help the operator extract useful work from this infrastructure continuously.

To illustrate the issue of low-connectivity-utility satellites, we computed the number of satellites in LEO networks that are not within reach of population centers. For this purpose, we use a snapshot of each of the Kuiper and Starlink constellations, and count the satellites that are not directly within reach from any of the largest 𝑛 cities by population. Fig. 4 shows the results for 𝑛 ∈ {100, 200, . . . , 1000}. Even with ground stations at 1000 cities, more than a third of Starlink’s and more than a half of Kuiper’s satellites are “invisible” in this manner at any time. Fig. 5 shows these invisible satellites for Starlink — while some of these satellites will provide valuable connectivity using inter-satellite links, such as for transatlantic routes, the vast majority of invisible satellites are the ones South of most of the World’s population, and won’t have much utility for networking. (Of course, minutes later, these satellites do provide useful connectivity.)

在轨计算资源在数量上必然比地面云资源有限得多，也更昂贵（§4）。将数据从地面源移动到卫星进行计算的成本也会很高。因此，对于大多数云应用来说，在轨计算将缺乏吸引力。

然而， 许多应用的数据是在太空中生成的，例如地球影像、气象观测和遥感。“地球观测大数据”[12, 13, 35, 55]的数据分析被视为一个利润丰厚且不断扩大的市场[41] ，以至于亚马逊最近推出了其针对这一细分市场的“AWS Ground Station”服务。至少有一个规划中的LEO网络——Starlink——已经暗示其卫星可能额外产生此类传感数据[40]。那么，遵循“近数据处理”范式[6]，在卫星服务器上处理这些数据会富有成效吗？

执行成像和传感的卫星能够以数Gbps的速率产生数据，但它们的传感时间受到向地面站传输数据能力的限制[21, 22]。因此，使用在轨计算对这些数据进行预处理，可以增加传感时间，并降低下载这些数据并在地面进行进一步处理的带宽成本。

一个拥有数千颗卫星的星座可能具备在轨执行此类数据处理的能力。星间带宽的限制可能较小[2, 36, 37]，这将允许卫星协同处理数据。与地面数据中心服务器间延迟为几微秒不同，星间通信的延迟将是毫秒级别，但这对于处理所涉及的大量数据的批量处理来说，应该仍然是足够的。

使用卫星进行此类计算的另一个好处是，它能更好地利用LEO基础设施。 在任何时候，一个纯网络星座的大部分资源都位于无法提供有效连接的区域上空。 机会性的在轨数据处理可以帮助运营商从这些基础设施中持续地提取有效工作。

为了说明 “连接效用低的卫星” 问题，我们计算了LEO网络中不在人口中心可达范围内的卫星数量。为此，我们使用了Kuiper和Starlink星座的快照，并统计了无法从人口最多的前 n 个城市中的任何一个直接到达的卫星数量。图4显示了当 n∈{100,200,...,1000} 时的结果。即使在1000个城市设有地面站，Starlink超过三分之一和Kuiper超过一半的卫星在任何时候都是以这种方式“不可见”的。图5展示了Starlink的这些“不可见”卫星——虽然其中一些卫星会通过星间链路提供宝贵的连接（例如跨大西洋航线），但绝大多数“不可见”卫星是那些位于世界大部分人口南侧的卫星，它们对于网络的效用不大。（当然，几分钟后，这些卫星确实会提供有用的连接。）