Small-scale LEO Satellite Networking for Global-scale Demands

Do we really need 10,000s of Low Earth Orbit (LEO) satellites to meet huge global Internet demands? While proven feasible and valuable, such LEO mega-constellation networks have raised concerns about their prohibitive capital expenditures, market monopoly, and unsustainable use of space. Instead, our analysis reveals that most of their satellites can be wasted due to their mismatch with physically uneven demands. We thus propose TinyLEO, a software-defined solution to shrink LEO network size for enormous global demands via dynamic spatiotemporal supply-demand matching. TinyLEO sparsifies satellite supplies on demand by combining diverse yet sparse orbits, hides complexities of this sparse LEO network via orbital model predictive control, and shifts the responsibility for handling these complexities to its geographic segment anycast for higher network usability, lower resource wastes, faster failovers, simpler satellites, and more flexible network orchestration. We have prototyped TinyLEO as a community toolkit for open research. Our evaluation using this toolkit shows that TinyLEO can compress the existing LEO mega-constellation network size by 2.0–7.9×, cut control plane costs by 1–3 orders of magnitude, and maintain the same demands and comparable data plane performance.

我们是否真的需要数万颗低地球轨道（LEO）卫星来满足庞大的全球互联网需求？尽管此类LEO巨型星座网络已被证明其可行性与价值，但其高昂的资本支出、市场垄断以及对空间的不可持续利用也引发了广泛担忧。与此相反，我们的分析揭示，由于卫星供应与物理上不均衡的需求之间存在错配，大部分卫星资源可能被浪费。

因此，我们提出了TinyLEO，一个软件定义的解决方案，旨在通过动态时空供需匹配，为巨大的全球需求缩减LEO网络规模。TinyLEO通过结合多样化但稀疏的轨道来按需稀疏化卫星供应，利用轨道模型预测控制来隐藏稀疏LEO网络的复杂性，并将其地理分段任播（anycast）作为处理这些复杂性的责任主体，从而实现更高的网络可用性、更低的资源浪费、更快的故障切换、更简化的卫星设计以及更灵活的网络编排。

我们已将TinyLEO原型化为一个面向开放研究的社区工具包。使用该工具包的评估表明，TinyLEO能够将现有LEO巨型星座的网络规模压缩2.0至7.9倍，将控制平面成本降低1至3个数量级，同时满足同等需求并保持相当的数据平面性能。

核心机制

Software-Defined LEO Network

控制平面: 将高层的拓扑和路由意图编译为供数据平面执行的底层指令

数据平面:

1. 将大部分复杂动态的责任转移到每颗卫星的数据平面
2. 地理分段任播: 发往某个地理单元的数据包可以被转发至覆盖该单元的任何卫星

Introduction

The Low Earth Orbit (LEO) satellite mega-constellations are revolutionizing the “Internet from space.” Thanks to a vast number of satellites with ultrahigh-capacity links, they promise high-speed Internet access to the numerous “offline” users everywhere on Earth. To date, SpaceX Starlink, the leading LEO mega-constellation, has offered 350 Tbps total capacity with around 7,000 satellites and 13,000 inter-satellite links (ISLs) for more than 4.6 million active users from 118 countries, enabling about 100 Mbps download speeds per user [1]. More LEO mega-constellation networks, such as OneWeb [2], GW [3], and Kuiper [4], are also under planning or deployment to catch up with Starlink.

Despite this great success, LEO satellite mega-constellation networks are not without concerns. Even with technological advances in rocket reusability and satellite miniaturization, their manufacturing, launching, and operation costs are still prohibitive for most Internet service providers (ISPs) and countries [5, 6]. This barrier to entry leads to a monopolistic global LEO network market by very few tech giants, which concerns regulators [7] and developing countries [8, 9]. More importantly, numerous satellites in LEO mega-constellations severely congest Earth’s orbits to threaten the sustainable and safe use of space for all humanity [10–13].

To resolve these concerns, we explore alternatives to LEO megaconstellation networks. Our goal is to shrink the LEO network scale for fewer satellites and retain comparable usability, performance, and resiliency to mega-constellations for large or global-scale users. This can help more small ISPs and countries own affordable satellite networks, democratize this global market with more players, and relieve orbital congestion for sustainability and safety.

低地球轨道（LEO）卫星巨型星座正在彻底改变“天基互联网”的格局。凭借其拥有超高容量链路的大量卫星，它们承诺为地球上任何地方众多“离线”用户提供高速互联网接入。迄今为止，作为领先的LEO巨型星座，SpaceX的星链（Starlink）已通过约7,000颗卫星和13,000条星间链路（ISL）提供了350 Tbps的总容量，为来自118个国家的超过460万活跃用户提供服务，实现了每用户约100 Mbps的下载速度[1]。其他更多的LEO巨型星座网络，如OneWeb [2]、国网（GW）[3]和Kuiper [4]，也正在规划或部署中，以追赶星链的步伐。

尽管取得了巨大成功，LEO卫星巨型星座网络并非没有隐忧。即使火箭可复用性和卫星小型化技术取得了进步，其制造、发射和运营成本对于大多数互联网服务提供商（ISP）和国家而言仍然高得令人望而却步[5, 6]。这一进入壁垒导致了全球LEO网络市场被极少数科技巨头垄断，这引起了监管机构[7]和发展中国家[8, 9]的关切。更重要的是，LEO巨型星座中的大量卫星严重拥堵了地球轨道，对全人类可持续和安全地利用空间构成了威胁[10–13]。

为解决这些问题，我们探索了LEO巨型星座网络的替代方案。我们的目标是缩减LEO网络规模以减少卫星数量，同时为大规模或全球范围的用户保持与巨型星座相当的可用性、性能和弹性。这有助于更多的小型ISP和国家拥有负担得起的卫星网络，通过引入更多参与者来使这个全球市场民主化，并为可持续性和安全性缓解轨道拥堵。

Our work starts with a simple insight: Most satellites in LEO mega-constellation networks are underutilized. For ease of networking and management, most mega-constellations in use distribute their satellites almost uniformly in space, leading to a homogeneous global network supply. But as shown in Figure 1a, the global network demands are uneven, with over 70% of users concentrated in 5% of the land and very few users in oceans covering 70.8% of the Earth. This physical mismatch wastes most satellites in lowdemand areas, which cannot be fully eliminated by higher-layer load balancing like local beam steering or global traffic engineering.

我们的工作始于一个简单的洞察：LEO巨型星座网络中的大多数卫星未被充分利用

为便于组网和管理，目前使用的大多数巨型星座几乎将卫星均匀地分布在空间中，导致了同质化的全球网络供应。但如图1a所示，全球网络需求是不均衡的，超过70%的用户集中在5%的陆地面积上，而在覆盖地球70.8%的海洋上用户极少。这种物理上的错配浪费了低需求区域的大多数卫星，而这种浪费无法通过上层的负载均衡技术（如局部波束调整或全局流量工程）完全消除。

To this end, we seek to shrink LEO networks by cutting these underutilized satellites. Clearly, the most fundamental method is to rearrange their layouts to match the uneven demands with fewer satellites, calling for non-uniform LEO networks. At first glance, this task seems simple since state-of-the-art geostationary (GEO) satellites have achieved this. However, it becomes extremely challenging for dynamic LEO satellite networks for two reasons:

• Unstable supply-demand match in mobility: Unlike GEO satellites, LEO satellites suffer from inevitable fast, asynchronous movement relative to the rotating Earth, leading to a rapidly changing coverage area on the ground. This extreme mobility makes it hard for LEO constellations to maintain their persistent match with uneven demands.

• Hard-to-use complex networking: A non-uniform LEO network should unevenly place satellites across latitudes, longitudes, and time to match imbalanced demands, incurring complex motions among heterogeneous satellites. This intensifies satellite link switches, topology updates, and routing path changes, all being risks for LEO network availability, efficiency, resiliency, and usability [14–18].

为此，我们寻求通过削减这些未被充分利用的卫星来缩减LEO网络。显然， 最根本的方法是重新安排其布局，以更少的卫星匹配不均衡的需求，这就要求构建非均匀的LEO网络

乍一看，这个任务似乎很简单，因为先进的地球静止轨道（GEO）卫星已经实现了这一点。然而，对于动态的LEO卫星网络而言，这变得极具挑战性，原因有二:

1. 移动性下不稳定的供需匹配：与GEO卫星不同，LEO卫星不可避免地相对于自转的地球进行高速、异步的运动，导致其地面覆盖区域快速变化
   • 这种极端的移动性使得LEO星座难以与不均衡的需求保持持续的匹配
2. 难以使用的复杂网络：一个非均匀的LEO网络应在纬度、经度和时间上不均匀地放置卫星以匹配不均衡的需求，这将导致异构卫星之间产生复杂的运动
   • 这加剧了卫星链路的切换、拓扑的更新和路由路径的变更，所有这些都对LEO网络的可用性、效率、弹性和易用性构成了风险[14–18]

We address both challenges with TinyLEO, a software-defined small-scale LEO networking for global-scale demands via spatiotemporal supply-demand matching. TinyLEO utilizes orbital diversity to enable stable on-demand network supply despite extreme satellite mobility. It decouples high-level network intents (stable demands) from their low-level enforcements (dynamic supplies) for high usability. Specifically,

(1) On-demand LEO network sparsification. TinyLEO combines diverse yet sparse orbits to complement each other for cutting satellite redundancy over space and time (akin to video compression). This can be efficiently achieved via compressed sensing [19–22], an advanced sparse signal reconstructor from very few Earth-repeat ground tracks of satellites (“textures”).

(2) Control plane: stable intent + orbital MPC. To retain high network usability, TinyLEO hides most complexities of the sparse LEO network’s complex physical dynamics from high-level networking demands. It decomposes its control plane into geographic traffic engineering intents (for topology and routing optimization on a stable basis) and an orbital model predictive control (MPC [23]) shim layer (for runtime compilation into dynamic network supplies) for simple and flexible orchestration and low signaling overhead under extreme LEO dynamics.

(3) Data plane: geographic segment anycast. TinyLEO shifts the responsibility for handling most LEO dynamics to each satellite’s local data plane, which is closer to these dynamics for more timely and efficient adaptations than the remote control plane. It enhances its data plane with geographic segment anycast for policy-compliant, flexible local (re)routing, load balancing, and fast recovery from outages (e.g., solar storms and ISL disruption). We have prototyped TinyLEO as a community toolkit for open research. Our evaluation using this toolkit validates that TinyLEO can compress the existing LEO mega-constellation network size by 2.0–7.9× (hence alleviating space congestion/pollution and saving ISPs’ capital expenditures of satellites) and cut control plane costs by 1–3 orders of magnitude while meeting broadband network demands at comparable data plane performance.

我们通过TinyLEO来应对这两个挑战。TinyLEO是一个 软件定义的、通过时空供需匹配来满足全球规模需求的小型LEO网络方案。 TinyLEO利用轨道多样性，在极端卫星移动性的情况下实现稳定的按需网络供应。 它将高层网络意图（稳定的需求）与其底层执行（动态的供应）解耦，以实现高可用性。 具体而言：

(1) 按需的LEO网络稀疏化。 TinyLEO结合多样化但稀疏的轨道，使其在空间和时间上互为补充，从而削减卫星冗余（类似于视频压缩）。这可以通过压缩感知[19–22]——一种先进的稀疏信号重构技术——从极少数的卫星对地重复轨迹（“纹理”）中高效实现。

(2) 控制平面：稳定的意图 + 轨道模型预测控制（MPC）。 为保持高的网络可用性，TinyLEO向高层网络需求隐藏了稀疏LEO网络复杂的物理动力学。它将其控制平面分解为地理流量工程意图（用于在稳定基础上进行拓扑和路由优化）和一个轨道模型预测控制（MPC [23]）适配层（用于将意图实时编译为动态的网络供应），从而在极端的LEO动态下实现简单灵活的编排和低信令开销。

(3) 数据平面：地理分段任播（anycast）。 TinyLEO将处理大多数LEO动态的责任转移到每个卫星的本地数据平面，该平面更接近这些动态，从而能比远程控制平面进行更及时、更高效的自适应。 它通过地理分段任播来增强其数据平面，以实现策略合规、灵活的本地（重）路由、负载均衡以及从中断（如太阳风暴和星间链路中断）中快速恢复。

We have prototyped TinyLEO as a community toolkit for open research. Our evaluation using this toolkit validates that TinyLEO can compress the existing LEO mega-constellation network size by 2.0–7.9× (hence alleviating space congestion/pollution and saving ISPs’ capital expenditures of satellites) and cut control plane costs by 1–3 orders of magnitude while meeting broadband network demands at comparable data plane performance.

Toolkit release and video: Our TinyLEO community toolkit and demo video are publicly available at [24].

Ethics: This paper raises no ethical concerns.

我们已将TinyLEO原型化为一个面向开放研究的社区工具包。使用该工具包的评估验证了TinyLEO可以将现有LEO巨型星座的网络规模压缩2.0至7.9倍（从而缓解空间拥堵/污染并节省ISP的卫星资本支出），并将控制平面成本降低1至3个数量级，同时满足宽带网络需求并保持相当的数据平面性能。

工具包发布与视频： 我们的TinyLEO社区工具包和演示视频已在[24]公开发布。

伦理声明： 本文不涉及伦理问题。

LEO Network Supply-Demand Gap

This section motivates our design of TinyLEO with analysis and empirical validations of the networking supply, demand, and their mismatch in LEO satellite mega-constellations.

本节通过对LEO卫星巨型星座中的网络供应、需求及其错配情况进行分析和实证验证，阐述我们设计TinyLEO的动机。

2.1 Large-scale LEO Network Supply

LEO satellite networks aim to connect the vast number of “unconnected” users without terrestrial network access. Each LEO satellite operates at 340–2,000 km altitudes, 20–100× closer to users than traditional GEO satellites at the 35,786 km altitude for lower latency and stronger radio signals. It equips ultrahigh-capacity radio links (e.g., 96 Gbps in Starlink v2 mini [1]) for end users and optionally laser links among satellites (e.g., 3 ISLs per Starlink satellite, up to 200 Gbps for each [1]) for global routing. As shown in Figure 2, each LEO satellite only has a finite coverage, so a constellation of satellites is necessary to cover the Earth everywhere.

For a basic global coverage, a small constellation with tens of LEO satellites usually suffices. However, such a small LEO constellation does not have sufficient network capacity to meet numerous users’ demands for high-speed Internet. For example, each Starlink v2 mini satellite with a 96 Gbps radio link can only serve up to 960 users with concurrent 100 Mbps downlink speed. To this end, operational LEO networks have been actively expanding their capacity with more satellites, aiming for mega-constellations with 1,000s–10,000s of satellites [1]. Meanwhile, they are also increasing each satellite’s radio link capacity to serve more users (e.g., from 15 Gbps in Starlink v1.5 to 96 Gbps in v2 mini [1, 25]).

Early LEO communications satellites, such as Starlink v1, simply act as access networks by relaying signals between terminals and ground stations (gateways to Internet). This “bent pipe” mode suffers from low service coverage due to its reliance on ground stations within each LEO satellite’s small visibility. To this end, recent LEO satellites have equipped ISLs to form backbone networks for global routing. By 2024, Starlink has activated 13,000 ISLs [1] with over 99% uptime and 42 petabytes of daily traffic delivery [17]. These data are typically forwarded across ISLs via tunneling [26].

LEO卫星网络旨在连接广大无法接入地面网络的“未连接”用户。每颗LEO卫星运行在340–2,000公里的高度，比传统GEO卫星35,786公里的高度近20–100倍，从而实现更低的时延和更强的无线电信号。它装备了面向终端用户的超高容量无线电链路（例如，星链v2 mini版为96 Gbps [1]）以及可选的用于全球路由的卫星间激光链路（例如，每颗星链卫星配备3条星间链路，每条速率高达200 Gbps [1]）。如图2所示，单颗LEO卫星的覆盖范围有限，因此需要一个卫星星座才能实现对地球的处处覆盖。

要实现基本的全球覆盖，一个拥有数十颗LEO卫星的小型星座通常就足够了。然而，这样的小型LEO星座不具备足够的网络容量来满足海量用户对高速互联网的需求。例如，一颗配备96 Gbps无线电链路的星链v2 mini卫星，在用户并发100 Mbps下行速率的情况下，最多只能服务960名用户。为此，在运行的LEO网络一直在通过增加更多卫星来积极扩展其容量，目标是建成拥有数千至数万颗卫星的巨型星座[1]。与此同时，它们也在提升单颗卫星的无线电链路容量以服务更多用户（例如，从星链v1.5的15 Gbps提升至v2 mini版的96 Gbps [1, 25]）。

早期的LEO通信卫星（如星链v1）仅作为接入网络，通过在中继终端和地面站（互联网网关）之间转发信号来工作。这种“弯管”（bent pipe）模式由于依赖于每颗LEO卫星狭小可见范围内的地面站，导致服务覆盖范围有限。为此，近期的LEO卫星已装备星间链路（ISL）以组成用于全球路由的骨干网络。到2024年，星链已激活了13,000条星间链路[1]，其正常运行时间超过99%，每日承载的数据流量高达42 PB [17]。这些数据通常通过隧道技术（tunneling）在星间链路上传输[26]。

2.2 Imbalanced Global Network Demand

Although LEO networks can cover everywhere on Earth, their demands are physically uneven for at least 3 reasons:

• Uneven global populations: As shown in Figure 1, more than 70% of the world’s population is concentrated in 5% of the land, while oceans with very few users cover 70.8% of the Earth’s surface. This spatial population bias inevitably leads to an uneven LEO network user distribution.

• Differentiated needs for satellite networks: Urban residents are usually surrounded by terrestrial broadband cables, WiFi, and cellular networks, thus less needing LEO networks than rural, maritime, and aviation users.

• Policy constraints: Due to complicated commercial and international policies, certain areas may be restricted from accessing LEO networks even if they are physically visible.

As a result, the real global distribution of LEO network users is uneven. Figure 3 presents the distribution of Starlink’s worldwide traffic based on Cloudflare’s DNS-based user activity measurements over 2 days at 15-minute intervals [27], which is in concert with Starlink’s official reports in [1] (see Figure 13a). It shows that Starlink users are more concentrated around a few regions than others, resulting in a long-tail distribution. Figure 3b also reveals periodic diurnal fluctuations of user activity across global time zones. It proves that LEO network users vary spatially and temporally.

尽管LEO网络可以覆盖地球上的任何地方，但其需求在物理上是不均衡的，至少有3个原因：

• 全球人口分布不均： 如图1所示，全球超过70%的人口集中在5%的陆地面积上，而用户极少的海洋覆盖了地球表面的70.8%。这种空间上的人口偏差不可避免地导致了LEO网络用户分布的不均衡。
• 对卫星网络的差异化需求： 城市居民通常被地面宽带光缆、WiFi和蜂窝网络所环绕，因此比农村、海事和航空用户更少需要LEO网络。
• 政策限制： 由于复杂的商业和国际政策，某些地区即使在物理上可见，也可能被限制接入LEO网络。

因此，LEO网络用户的真实全球分布是不均衡的。图3展示了基于Cloudflare在2天内以15分钟为间隔的DNS用户活动测量得出的星链全球流量分布[27]，这与[1]中星链的官方报告（见图13a）相吻合。它显示星链用户更集中于少数区域，呈现出长尾分布的特征。图3b还揭示了用户活动在全球各时区存在周期性的昼夜波动。这证明了LEO网络用户在空间和时间上都是变化的。

2.3 Network Supply-Demand Mismatch

Unfortunately, existing LEO mega-constellation network supplies are not well aligned with the uneven demands. For ease of networking and management, most operational LEO networks uniformly distribute their satellites in space based on homogeneous layouts (e.g., Walker constellation [28]). This uniform LEO network severely wastes its satellite link capacity and limits its serviceable users in two aspects:

◦ Underutilization in idle areas: As shown in Figure 4, LEO satellites move across the Earth at about 7 km/s. Most of them are unavoidably exposed in areas with few users and left idle most of the time. This makes each satellite’s added capacity in §2.1 less useful to serve more users and even worsens its capacity waste in low-demand areas.

◦ Underutilization propagation from hotspots: Due to their fast mobility, LEO satellites that cover hotspots for now will soon leave. To meet excessive demand in these hotspots, LEO networks must ensure that there are always enough satellites covering these areas, which, however, leads to more satellite capacity waste elsewhere as they will move from hotspots to low-demand areas.

然而，现有的LEO巨型星座网络供应与不均衡的需求并未很好地匹配。为便于组网和管理，大多数在运行的LEO网络都基于同质化布局（如沃克星座[28]）将卫星均匀地分布在空间中。这种均匀的LEO网络在两个方面严重浪费了其卫星链路容量，并限制了其可服务的用户数量：

• 在空闲区域的利用率不足: 如图4所示，LEO卫星以大约7公里/秒的速度划过地球。它们中的大多数不可避免地会经过用户稀少的区域，并在大部分时间内处于空闲状态。这使得§2.1中提到的单星容量增加对于服务更多用户的效用降低，甚至恶化了其在低需求区域的容量浪费

• 利用率不足从热点区域传播: 由于其高速移动性，当前覆盖热点地区的LEO卫星很快就会离开。为了满足这些热点地区的超额需求，LEO网络必须确保总有足够的卫星覆盖这些区域，但这反过来又会导致更多的卫星容量在别处被浪费，因为这些卫星将从热点区域移动到低需求区域

Can load balancing help?

A standard solution to this mismatch in traditional networking is load balancing. Although partially applicable to LEO networks, it encounters physical constraints to fulfill its potential:

• Local radio access beam steering: A common practice for satellite load balancing is to steer its radio access link beams to highdemand areas, which has been extensively used in Starlink [29]. However, as shown in Figure 5a, a satellite beam’s maximum steering angle has an upper bound due to physical visibility constraints (e.g., 56.7°in Starlink [30]). Even if it is idle over broad oceanic areas, it cannot always redirect its beams to the nearest terrestrial high-demand areas for load balancing. In addition, to avoid co-channel interferences, nearby satellites’ beams using the same RF bands cannot be steered to the same area [29, 30], further limiting their flexibility for load balancing.

• Global traffic engineering: Another method to balance the global LEO network load is to shift traffic flows from hotspots to lowdemand satellites via ISLs, such as trans-oceanic routes [31] or backhaul traffic aggregation [32]. While helpful for inter-satellite backbone networks, it cannot fully shift the last-mile user traffic between hotspots and idle areas as explained above. In reality, most LEO networks’ utilizations are bottlenecked by their lasthop radio access links to users rather than ISLs (e.g., 96 Gbps in Starlink versus its 200-Gbps ISLs [1]). Traffic engineering cannot eliminate this bottleneck in uniform LEO networks.

负载均衡能解决问题吗？ 在传统网络中，应对这种错配的标准方案是负载均衡。尽管该方案部分适用于LEO网络，但它受到物理限制，难以充分发挥其潜力：

• 局部无线电接入波束调整：卫星负载均衡的一个常见做法是将其无线电接入链路的波束导向高需求区域，这在星链中已被广泛使用[29]。然而，如图5a所示，卫星波束的最大偏转角受物理可见性限制（例如，星链为56.7°[30]），存在一个上限。即使卫星在广阔的海洋区域上空处于空闲状态，它也无法总是将其波束重定向到最近的陆地高需求区域进行负载均衡。此外，为避免同信道干扰，使用相同射频频段的邻近卫星的波束不能被导向同一区域[29, 30]，这进一步限制了它们进行负载均衡的灵活性。

• 全局流量工程：平衡全球LEO网络负载的另一种方法是通过星间链路将流量从热点区域转移到低需求区域的卫星上，例如通过跨洋路由[31]或回程流量汇聚[32]。 虽然这对于星间骨干网络有帮助，但如上所述，它无法完全转移热点区域与空闲区域之间的“最后一英里”用户流量。实际上，大多数LEO网络的利用率瓶颈在于其到用户的最后一跳无线电接入链路，而非星间链路（例如，星链的接入链路为96 Gbps，而其星间链路速率为200 Gbps [1]）。 流量工程无法消除均匀LEO网络中的这一瓶颈。

How about a multi-shell LEO network?

In fact, Starlink is aware of this supply-demand gap and seeks to mitigate it using multi-shell LEO networks. As exemplified in Figure 2, most Starlink satellites are in orbits with 53–53.2°inclinations to serve most users in low latitudes, while others use 97.6°inclinations to cover few users in the Arctic and Antarctica.

Unfortunately, this simple fix is not enough to eliminate the supply-demand gap. LEO network demands are uneven in not only latitudes but also longitudes (Figure 1). Since each shell’s satellites remain uniform, they cannot match uneven longitudinal demands for high utilization (Figure 4). The Earth’s rotation also complicates this matching due to its asynchronous longitudinal mobility to LEO satellites. As a result, even with this multi-shell design, Starlink’s satellite utilization remains unsatisfactory, as shown in Figure 4.

多层壳（Multi-shell）LEO网络方案如何？事实上，星链已经意识到了这种供需差距，并试图通过使用多层壳LEO网络来缓解它。如图2所示，大多数星链卫星位于轨道倾角为53–53.2°的轨道上，以服务低纬度地区的大多数用户，而其他卫星则使用97.6°的倾角来覆盖北极和南极的少数用户。

不幸的是，这种简单的修补不足以消除供需差距。LEO网络的需求不仅在纬度上不均衡，在经度上也是如此（图1）。由于每一层壳的卫星分布仍然是均匀的，它们无法匹配不均衡的经度需求以实现高利用率（图4）。地球的自转也使这种匹配变得复杂，因为它与LEO卫星存在经度上的异步移动。因此，即使采用了这种多层壳设计，星链的卫星利用率仍然不理想，如图4所示。

What if a non-uniform LEO network?

The fundamental solution to this satellite underutilization is to rearrange the physical LEO network layout to match the uneven global user demand, calling for non-uniform satellite distributions. While conceptually simple and already feasible for GEO satellites, it is hard to realize in LEO networks for two reasons:

• Hard to maintain physical match in mobility: Unlike GEO satellites, LEO satellites suffer from inevitable fast, asynchronous movement relative to the Earth at about 7 km/s, leading to a rapidly changing coverage area on the ground (Figure 4). For instance, each Starlink satellite’s coverage to each area can only last up to 3 minutes. This space-terrestrial dynamics makes it difficult for the constellation to keep matching the uneven demands.

• Dynamic heterogeneous networking: A non-uniform LEO constellation should unevenly distribute satellites in different orbits to match imbalanced demands. As we will see in §4.2, this complicates satellites’ relative motions and intensifies their network topology and routing changes. These dynamics can degrade network availability, efficiency, and resiliency [14–18], eventually challenging the usability of non-uniform LEO networks.

如果采用非均匀LEO网络呢？ 解决这种卫星利用率不足问题的根本方案是重新安排LEO网络的物理布局以匹配不均衡的全球用户需求，这要求采用非均匀的卫星分布。虽然这个概念很简单，且对GEO卫星来说已经可行，但在LEO网络中却难以实现，原因有二：

• 在移动中难以维持物理匹配： 与GEO卫星不同，LEO卫星不可避免地以大约7公里/秒的速度相对于地球进行高速、异步的运动，导致其地面覆盖区域快速变化（图4）。例如，每颗星链卫星对任一区域的覆盖最多只能持续3分钟。这种星地动态特性使得星座难以持续匹配不均衡的需求。
• 动态的异构组网： 一个非均匀的LEO星座应将卫星不均匀地分布在不同轨道上以匹配不均衡的需求。正如我们将在§4.2中看到的，这会使卫星间的相对运动复杂化，并加剧其网络拓扑和路由的变化。这些动态性可能会降低网络的可用性、效率和弹性[14–18]，最终对非均匀LEO网络的易用性构成挑战。

Problem statement: This work explores an alternative to LEO mega-constellation networks by addressing these challenges for the non-uniform LEO network. We seek usable small-scale non-uniform LEO networking for global-scale high-speed Internet demands. It can compress the LEO network size for affordability and space sustainability, while retaining comparable network availability, performance, robustness, and flexibility to LEO mega-constellations.

问题陈述： 本文通过应对非均匀LEO网络的这些挑战，探索了LEO巨型星座网络的一种替代方案。我们寻求一种可用的、小规模的非均匀LEO组网方案，以满足全球规模的高速互联网需求。该方案可以压缩LEO网络规模以实现可负担性和空间可持续性，同时保持与LEO巨型星座相当的网络可用性、性能、鲁棒性和灵活性。

Solution Overview

We propose TinyLEO, a software-defined small-scale LEO networking that achieves all the above goals. At its core, TinyLEO enables spatiotemporal supply-demand matching in LEO networks to cut unnecessary satellites. It decouples high-level inter-networking intents (stable demands) from their low-level enforcements (dynamic supplies) for high network usability. This paradigm is achieved by exploiting three unique opportunities in LEO satellite networks:

(1) Predictive orbital motions: While the geo-asynchronous extreme mobility of LEO satellites forces a dynamic network supply-demand match, it remains predictable by orbital laws to facilitate a semi-stable match;

(2) Combine diverse yet sparse orbits: Each individual LEO cannot perfectly match its homogeneous satellites with uneven global demands. However, a combination of heterogeneous LEOs (each having sparse satellites) with different orbital periods, inclination angles, and right ascensions can complement each other for near-optimal matching;

(3) Geographic invariants for usable networking: Despite frequent changes of visible satellites, each geographic area retains a constant number of available satellites after the supplydemand match, offering stable guidance to enforce usable satellite topology and routing.

我们提出了TinyLEO，一个旨在实现上述所有目标的软件定义小型LEO组网方案。其核心在于，TinyLEO通过在LEO网络中实现时空供需匹配来削减不必要的卫星。它将高层的网络意图（稳定的需求）与其底层的执行（动态的供应）相解耦，以实现高的网络可用性。这一范式是通过利用LEO卫星网络的三个独特机遇实现的：

(1) 可预测的轨道运动：尽管LEO卫星与地理位置异步的极端移动性迫使网络供需匹配必须是动态的，但这种移动性遵循轨道定律，是可预测的，这为实现半稳定的匹配提供了便利。

(2) 结合多样化但稀疏的轨道：单个LEO星座无法用其同质化的卫星完美匹配不均衡的全球需求。然而，将多个具有不同轨道周期、轨道倾角和升交点赤经的异构LEO星座（每个星座都只有稀疏的卫星）相结合，可以相互补充，从而达到近乎最优的匹配。

(3) 用于实现可用网络的地理不变量：尽管可见卫星频繁变化，但在供需匹配后，每个地理区域可用的卫星数量保持恒定，这为执行可用的卫星拓扑和路由提供了稳定的指导。

Figure 6 overviews the workflow of TinyLEO based on these insights. It comprises an offline sparse network synthesizer and online network control/data-plane functions:

• On-demand LEO network sparsification (§4.1). The synthesizer plans a sparse LEO network layout to match spatiotemporally uneven demands. TinyLEO achieves this by combining diverse yet sparse LEOs to cut satellite waste via compressed sensing (akin to video compression).

• Control plane: stable intent + orbital MPC (§4.2). On top of the sparse LEO network, TinyLEO’s control plane compiles high-level topology and routing intents to low-level instructions for the data plane. For high network usability, we split it into a stable geographic networking intent abstraction and orbital model predictive controller (MPC). This separation of concerns hides complexities of complex LEO physical dynamics from network demands for flexible orchestration and low signaling costs.

• Data plane: geographic segment anycast (§4.3). TinyLEO moves the responsibility for tackling most sparse LEO networks’ complex dynamics to each satellite’s data plane. It achieves this via geographic segment anycast (i.e., packets destined to a geographic cell can be forwarded to any satellite covering this cell) for policy-compliant, efficient local (re)routing, load balancing, and failovers.

图6概述了基于这些洞察的TinyLEO工作流程。它包含一个离线稀疏网络合成器和在线的网络控制/数据平面功能：

• 按需的LEO网络稀疏化 (§4.1)
  • 合成器规划一个稀疏的LEO网络布局，以匹配时空不均衡的需求
  • TinyLEO通过压缩感知技术（类似于视频压缩），将多样化但稀疏的LEO星座组合起来削减卫星浪费，从而实现这一目标
• 控制平面：稳定意图 + 轨道MPC (§4.2)
  • 在稀疏LEO网络之上， TinyLEO的控制平面将高层的拓扑和路由意图编译为供数据平面执行的底层指令
  • 为实现高的网络可用性，我们将其拆分为一个稳定的地理网络意图抽象层和一个轨道模型预测控制器（MPC）
  • 这种“关注点分离”的设计，将复杂的LEO物理动力学从网络需求中隐藏起来，以实现灵活的编排和低信令开销
• 数据平面：地理分段任播 (§4.3)
  • TinyLEO将处理稀疏LEO网络 大部分复杂动态的责任转移到每颗卫星的数据平面
  • 它通过地理分段任播（geographic segment anycast，即 发往某个地理单元的数据包可以被转发至覆盖该单元的任何卫星 ）来实现策略合规、高效的本地（重）路由、负载均衡和故障切换

Design of TinyLEO

This section addresses three critical issues to realize TinyLEO:

(I) How to sparsify the LEO network supply while still meeting uneven global broadband demands (§4.1)?

(II) How to streamline this sparse LEO network’s control plane for diverse high-level networking intents (§4.2)?

(III) How to enhance the data plane to enforce these intents in the sparse LEO network’s dramatic dynamics (§4.3)?

tips for ch4

感觉这一节，只需要看4.3即可，了解一下dataflow即可

4.1 On-demand LEO Network Sparsification

TinyLEO’s core idea is to accurately match the sparse LEO network supply with uneven global demands to cut satellites. As explained in §2.3, this calls for a non-uniform LEO network layout across latitudes, longitudes, and time. It departs from existing LEO mega-constellations that can only differentiate their supply across latitudes via multiple orbital shells at most (§2.3). To realize this, we should answer three questions:

(1) How to enable uneven satellite distributions across latitudes, longitudes, and time for on-demand matching?

(2) How to stabilize this uneven network supply under fast, geo-asynchronous LEO satellite mobility?

(3) How to use as few LEO satellites as possible to match uneven global broadband demands?

Diverse orbits for on-demand matching: TinyLEO does not place dense satellites in homogeneous orbits as mega-constellations. Instead, it combines diverse orbits (each with sparse satellites) to match uneven network demands across latitudes, longitudes, and time. Figure 7 depicts diverse orbital parameters’ spatiotemporal impacts on matching:

• Inclination for latitudinal diversity: An orbit’s inclination angle 𝛽 determines its maximal latitudes on Earth to cover. As explained in §2.3 and shown in Figure 2, existing LEO mega-constellations deploy multiple orbital shells with various inclinations to match demands across latitudes;

• Right ascentation for longitudinal diversity: The longitude of each orbit’s ascending angle bounds its horizontal areas to cover. Shifting the right ascension of the ascending node can match a satellite supply to different longitudinal areas;

• Orbit period for temporal diversity: It decides how frequently each satellite revisits geographic areas. LEO satellites with diverse orbital periods can complement each other’s coverage at different times to match temporal demand changes.

Intuitively, more orbits with these diverse parameters can better match LEO network supplies with uneven demands.

Earth-repeat ground tracks for stable matching: While the above orbital parameters can seemingly generate diverse satellites to match uneven demands in different areas, this matching can be unstable due to LEO mobility. Different from terrestrial or GEO satellite networks, it is hard to fix a geo-asynchronous LEO satellite to serve a single area, making it hard for the non-uniform LEO network to fix its supply-demand match anywhere for continuous high-speed services.

TinyLEO makes a case to solve this issue by exploiting ubiquitous Earth-repeat ground tracks [33, 34]. Intuitively, the LEO satellite in an Earth-repeat orbit always periodically revisits the same geographic area despite its mobility and Earth rotation. To achieve this, its orbital period \(T\) satisfies

\(T/T_E = p/q, \quad p, q \in \mathbb{N}^+\) (1)

where \(T_E\) is the Earth's rotation period (24h) and \(p < q\) can be any positive integers. A salient feature of Earth-repeat orbit is its fixed satellite ground track: As visualized in Figure 7, each satellite in this orbit always revisits the same geographic area after \(q\) rounds (or equivalently \(p\) days of Earth's rotations), forming a stable basis of matching these areas' demands. Moreover, Earth-repeat LEO orbits are abundant and diverse: They can be easily generated on demand by varying \((p, q)\) and diverse orbital parameters in Figure 7, which form an over-complete set of stable LEO satellite network supplies with diverse geographic coverages and satellite densities.

Basic network sparsification setup: Based on the above primitives, TinyLEO models LEO network sparsification as a spatiotemporal supply-demand matching problem (akin to video compression), as illustrated in Figure 8:

• Uneven network demands: We divide the Earth's surface into \(m\) geographic cells to let network designers/operators plan each cell \(i\)'s maximal serviceable demand at time \(t\) (\(y_t^i\), in the unit of the number of satellites) as TinyLEO's input. This maximal serviceable demand \(y_t^i\) can be customized to account for various real-world factors, including but not limited to local radio access link capacity, ISL capacity for backbone (§4.2), over-provisioning for remote areas or unpredictable traffic spikes, backup satellites for fault tolerance (e.g., by solar storms and cosmic radiations), and periodic diurnal dynamics (§2.2). How to balance them is out of this paper's scope and has been well-discussed in prior network planning works. This separation of concerns ensures TinyLEO's efficiency despite demand diversity and changes. We denote all geographic cells' demands as a vector \(y_t = [y_t^1, y_t^2, ..., y_t^m]^T\). The uneven demands imply that y is a sparse vector, i.e., \(y_t^i \approx 0\) for most \(i\) and \(t\).
• Diverse yet sparse network supply: TinyLEO maintains a LEO Earth-repeat ground track ("texture") library as an over-complete set of candidates for network supply. These candidates are identified by enumerating \((p, q)\) pairs in Equation 1 whose orbits are not occupied or allocated by space regulators (e.g., ITU and FCC). The \(j\)-th ground track in this library is uniquely characterized by its orbit's right ascension \(\alpha_j\), inclination \(\beta_j\), and period \(T_j\) (or \(p_j\) and \(q_j\)) in Figure 7. TinyLEO does not pose any constraints for these orbital parameters; any Earth-repeat orbit is allowed. It will optimize the number of satellites \(x_j \ge 0\) (\(x_j \in \mathbb{N}\)) to place in this orbit and their distributions. We represent all orbits' number of satellites as a vector \(x = [x_1, x_2, ..., x_n]^T\), where \(n\) is the number of candidates in this library and should be large (\(m \ll n\)) for over-completeness. Due to TinyLEO's nature, most candidates' satellites will be eventually empty (i.e., \(x_j \approx 0\) for most \(j\)), making \(x\) a sparse vector as well.
• Spatiotemporal supply-demand matching: Given the global network demand \(y_t\) and all available Earth-repeat orbital ground tracks covering these areas, we arrange each Earth-repeat orbit's satellites \(x\) and combine them to satisfy \(y_t\) everywhere, anytime. In this process, we minimize the total number of satellites. This can be formulated as

\(min \quad ||x||_1\) (2)

\(s.t. \quad A_t x \ge y_t \quad \forall t = 1, 2, ..., T_{max}\) (3)

\(x_i \in \mathbb{N}\) (4)

where \(||x||_1 = \Sigma_{i=1}^n x_i\) is the total number of satellites, \(T_{max} = LCM(T_1, T_2, ..., T_n)\) is the maximal time slot to consider (i.e., the least common multiple of all orbital periods, after which all satellites repeat their ground tracks), \(A_t \in \mathbb{R}^{m \times n}\) is the coverage matrix at time \(t\) with \(A_t(i, j) \in [0, 1]\) being the fraction of satellite \(j\)'s radio link coverage over cell \(i\), and hence \(A_t x\) is the runtime LEO network capacity supply at time \(t\). Due to predictable LEO mobility, each coverage matrix \(A_t\) can be pre-computed based on orbital laws, the Earth's rotation period \(T_E\), and orbital parameters \(\alpha_i\), \(\beta_i\), and \(T_i\).

Sparse matching via compressed sensing: Equation 2–4 is a standard integer linear programming problem, which is NP-hard in general [35]. Fortunately, in our context, the LEO network supply \(x\), the network demand \(y_t\), and satellite coverage matrix \(A_t\) are all sparse. This domain-specific property can cast our optimization as a sparse signal recovery problem, which can be more efficiently solved with compressed sensing techniques [19–22]¹.

Algorithm 1 presents TinyLEO's sparse approximation of the solution for Equation 2–4, which is a variant of the matching pursuit (MP) algorithm from compressed sensing [19, 22]. As visualized in Figure 8, to unify the spatial and temporal matching, this algorithm first unfolds the time-evolving LEO network demands and coverage matrix as a concatenation of a single vector/matrix (line 1–2). Then it iteratively searches the ground track \(i\) whose satellites can cover the maximum amount of the unsatisfied residual demands (line 6–7), determines the number of satellites \(x_i\) this ground track should add (line 8), and updates the residual demands by subtracting this ground track's satisfied demands (line 9). The algorithm stops when the residual demands are less than a predefined network availability threshold \(\epsilon\) (e.g., \(\epsilon \ge 99\%\) across space and time [17]). Since the LEO network demand \(y_t\) and coverage matrix \(A_t\) are sparse, Algorithm 1 can quickly meet this criterion to complete its spatiotemporal matching. Its greedy nature also ensures that its output LEO network supply \(x\) is sparse enough to save satellites.

Incremental LEO network expansion: Algorithm 1 also eases incremental deployment. Its greedy search for satellites that best match residual demands forms a natural step-by-step satellite launching plan. Suppose the ISP wants to serve more users than initially planned. To satisfy it, TinyLEO can simply set the residual demand \(z^k\) as this additional demand and continue Algorithm 1 to determine new satellites to launch without affecting its existing satellites.

Long-term stability: In reality, satellites may deviate from Earth-repeat ground tracks due to orbital decays or collision avoidance maneuvers. To retain network demand-supply match, each satellite can routinely calibrate its location in its daily orbit maintenance (already done by Starlink for stable networking [13, 36]) to stay in its Earth-repeat ground track.

TinyLEO的核心思想是精确匹配稀疏的低轨网络供应与不均衡的全球需求，以削减卫星数量。如§2.3所述，这要求在纬度、经度和时间上实现非均匀的低轨网络布局。这与现有的低轨巨型星座不同，这些星座最多只能通过多个轨道壳层来实现纬度上的供应差异化（§2.3）。为实现这一目标，我们需要回答三个问题：

(1) 如何在纬度、经度和时间上实现不均衡的卫星分布，以进行按需匹配？

(2) 在快速、地球非同步的低轨卫星移动性下，如何稳定这种不均衡的网络供应？

(3) 如何使用尽可能少的低轨卫星来匹配不均衡的全球宽带需求？

用于按需匹配的多样化轨道

TinyLEO不像巨型星座那样将密集的卫星放置在同质化的轨道中。相反，它结合了多样化的轨道（每条轨道上只有稀疏的卫星），以匹配跨越纬度、经度和时间的非均衡网络需求。图7描述了不同轨道参数在时空上对匹配的影响：

• 轨道倾角实现纬度多样性：一条轨道的倾角 \(β\) 决定了其在地球上能覆盖的最大纬度。如§2.3和图2所示，现有的低轨巨型星座通过部署具有不同倾角的多个轨道壳层来匹配不同纬度的需求。

• 升交点赤经实现经度多样性：每条轨道的升交点经度限定了其覆盖的水平区域。通过改变升交点赤经，可以将卫星供应匹配到不同的经度区域。

• 轨道周期实现时间多样性：它决定了每颗卫星重访特定地理区域的频率。具有不同轨道周期的低轨卫星可以在不同时间互补彼此的覆盖范围，以匹配需求的时间变化。

直观上，拥有这些多样化参数的轨道越多，就越能更好地将低轨网络供应与不均衡的需求相匹配。

利用地球重复地面轨迹实现稳定匹配

尽管上述轨道参数看似可以生成多样化的卫星来匹配不同区域的不均衡需求，但由于低轨卫星的移动性，这种匹配可能不稳定。与地面网络或地球静止轨道（GEO）卫星网络不同，很难固定一颗地球非同步的低轨卫星来服务于单个区域，这使得非均匀的低轨网络难以在任何地方固定其供需匹配，从而提供持续的高速服务。

TinyLEO提出通过利用普遍存在的地球重复地面轨迹 [33, 34] 来解决此问题。直观地说，处于地球重复轨道上的低轨卫星，尽管自身在移动且地球在自转，但总会周期性地重访相同的地理区域。为实现这一点，其轨道周期 \(T\) 需满足：

\[T/T_E = p/q, \quad p, q \in \mathbb{N}^+ \quad (1)\]

其中，\(T_E\) 是地球的自转周期（24小时），\(p < q\) 可以是任意正整数。地球重复轨道的一个显著特征是其固定的卫星地面轨迹：如图7所示，该轨道上的每颗卫星在绕行 \(q\) 圈（或相当于地球自转 \(p\) 天）后，总会重访相同的地理区域，这为匹配这些区域的需求提供了稳定的基础。此外，地球重复的低轨轨道数量丰富且种类多样：通过改变 \((p, q)\) 对和图7中多样化的轨道参数，可以按需轻松生成这些轨道，它们构成了一个过完备的稳定低轨卫星网络供应集，具有多样化的地理覆盖和卫星密度。

基本网络稀疏化设置

基于上述基本要素，TinyLEO将低轨网络稀疏化建模为一个时空供需匹配问题（类似于视频压缩），如图8所示：

• 不均衡的网络需求：我们将地球表面划分为 \(m\) 个地理单元，网络设计者/运营商可以规划每个单元 \(i\) 在时间 \(t\) 的最大可服务需求（\(y_t^i\)，单位为卫星数量），并将其作为TinyLEO的输入。这个最大可服务需求 \(y_t^i\) 可以根据各种现实因素进行定制，包括但不限于本地无线接入链路容量、用于骨干网的星间链路（ISL）容量（§4.2）、为偏远地区或不可预测的流量高峰提供的超额配置、为应对故障（如太阳风暴和宇宙辐射）的备用卫星，以及周期性的昼夜动态（§2.2）。如何平衡这些因素超出了本文的范围，并且在先前的网络规划工作中已有充分讨论。这种关注点分离确保了TinyLEO在需求多样化和变化的情况下仍能保持高效。我们将所有地理单元的需求表示为向量 \(y_t = [y_t^1, y_t^2, ..., y_t^m]^T\)。不均衡的需求意味着 \(y_t\) 是一个稀疏向量，即对于大多数 \(i\) 和 \(t\)，\(y_t^i \approx 0\)。

• 多样化但稀疏的网络供应：TinyLEO维护一个低轨地球重复地面轨迹（“纹理”）库，作为网络供应的过完备候选集。这些候选轨道通过枚举公式(1)中的 \((p, q)\) 对来确定，且这些轨道未被空间监管机构（如ITU和FCC）占用或分配。库中的第 \(j\) 条地面轨迹由其轨道的升交点赤经 \(\alpha_j\)、轨道倾角 \(\beta_j\) 和周期 \(T_j\)（或 \(p_j\) 和 \(q_j\)）唯一表征（见图7）。TinyLEO对这些轨道参数不施加任何约束；任何地球重复轨道都是允许的。它将优化放置在该轨道上的卫星数量 \(x_j \ge 0\) (\(x_j \in \mathbb{N}\)) 及其分布。我们将所有轨道的卫星数量表示为向量 \(x = [x_1, x_2, ..., x_n]^T\)，其中 \(n\) 是库中候选轨道的数量，且为了实现过完备性，\(n\) 应远大于 \(m\)（\(m \ll n\)）。由于TinyLEO的特性，大多数候选轨道的卫星数量最终将为零（即对于大多数 \(j\)，\(x_j \approx 0\)），使得 \(x\) 也是一个稀疏向量。

• 时空供需匹配：给定全球网络需求 \(y_t\) 和所有可用的覆盖这些区域的地球重复轨道地面轨迹，我们安排每条地球重复轨道上的卫星数量 \(x\) 并将它们组合起来，以随时随地满足 \(y_t\)。在此过程中，我们最小化卫星的总数。这可以公式化为：

\[\min \quad ||x||_1 \quad (2)\]

\[s.t. \quad A_t x \ge y_t \quad \forall t = 1, 2, ..., T_{max} \quad (3)\]

\[x_i \in \mathbb{N} \quad (4)\]

其中 \(||x||_1 = \Sigma_{i=1}^n x_i\) 是卫星总数，\(T_{max} = LCM(T_1, T_2, ..., T_n)\) 是需要考虑的最大时间槽（即所有轨道周期的最小公倍数，此后所有卫星将重复其地面轨迹），\(A_t \in \mathbb{R}^{m \times n}\) 是在时间 \(t\) 的覆盖矩阵，其中 \(A_t(i, j) \in [0, 1]\) 是卫星 \(j\) 的无线链路覆盖范围对单元 \(i\) 的覆盖比例，因此 \(A_t x\) 是在时间 \(t\) 的实时低轨网络容量供应。由于低轨卫星的移动是可预测的，每个覆盖矩阵 \(A_t\) 都可以基于轨道定律、地球自转周期 \(T_E\) 以及轨道参数 \(\alpha_i\)、\(\beta_i\) 和 \(T_i\) 预先计算出来。

通过压缩感知实现稀疏匹配

公式2-4是一个标准的整数线性规划问题，通常是NP难的 [35]。幸运的是，在我们的情境中，低轨网络供应 \(x\)、网络需求 \(y_t\) 和卫星覆盖矩阵 \(A_t\) 都是稀疏的。这一领域特定的属性使我们可以将此优化问题视为一个稀疏信号恢复问题，并可以利用压缩感知技术 [19–22] 更高效地求解。

算法1展示了TinyLEO对公式2-4解的稀疏近似方法，该算法是压缩感知领域中匹配追踪（MP）算法的一个变体 [19, 22]。如图8所示，为了统一空间和时间上的匹配，该算法首先将随时间演变的网络需求和覆盖矩阵展开并拼接成一个单一的向量/矩阵（第1-2行）。然后，它迭代地搜索其卫星能最大程度满足未满足的剩余需求的地面轨迹 \(i\)（第6-7行），确定这条地面轨迹应增加的卫星数量 \(x_i\)（第8行），并通过减去该地面轨迹已满足的需求来更新剩余需求（第9行）。当剩余需求低于预定义的网络可用性阈值 \(\epsilon\)（例如，全时空范围内 \(\epsilon \ge 99\%\) [17]）时，算法停止。由于低轨网络需求 \(y_t\) 和覆盖矩阵 \(A_t\) 是稀疏的，算法1可以迅速达到此标准以完成其时空匹配。其贪心性质也确保了其输出的低轨网络供应 \(x\) 足够稀疏，从而节省卫星。

低轨网络的增量式扩展

算法1也便于进行增量式部署。其贪婪搜索最能匹配剩余需求的卫星的过程，自然地形成了一个分步的卫星发射计划。假设互联网服务提供商（ISP）希望服务比原计划更多的用户。为满足此需求，TinyLEO可以简单地将剩余需求 \(z^k\) 设置为这个新增的需求，并继续执行算法1来确定需要发射的新卫星，而不会影响其现有卫星。

长期稳定性

在现实中，卫星可能因轨道衰减或碰撞规避机动而偏离地球重复地面轨迹。为了保持网络供需匹配，每颗卫星可以在日常的轨道维持中（Starlink已为保证网络稳定而执行此类操作 [13, 36]）例行校准其位置，以保持在其地球重复地面轨迹上。

4.2 Control Plane: Stable Intent + Orbital MPC

After shrinking the LEO network size, TinyLEO's next task is to make this non-uniform LEO network easily usable. If these LEO satellites simply act as access networks in §2.1, this mission is already completed in §4.1 since TinyLEO ensures sufficient radio access link capacity everywhere, anytime. If these satellites also need to act as backbone networks to deliver data traffic through their ISLs, TinyLEO should also manage additional complexities of their topology and routing in this extremely dynamic, non-uniform LEO network.

To understand the impacts of the non-uniform LEO physical dynamics on topology and routing, Figure 9 projects the update frequency of all potential ISLs and shortest paths among satellites in TinyLEO and uniform LEO networks of the same size. Due to heterogeneous satellite motions by diverse orbital parameters, the sparse LEO network will inevitably encounter more ISL and route changes than the uniform one. If not properly tackled, both can harm network availability, efficiency, and resiliency [14–18]. This complexity is unavoidable for sparse LEO networks.

In operational LEO networks, the contemporary solution to manage this complexity is to utilize regular orbital motions for predictive temporospatial software-defined networking (TS-SDN). For instance, Starlink [17, 26] and Aalyria [14–16] adopt TS-SDN to forecast satellite motions, search for potential ISLs and paths over space and time, and optimize the evolving satellite network topology and routing accordingly. While effective and affordable in uniform LEO networks, they may be unstable and expensive in the extremely dynamic non-uniform LEO networks for two reasons:

• High control costs: Existing TS-SDN exposes almost all low-level LEO physical dynamics, logical network topology, and hop-by-hop satellite routing to the upper layer for control [14–16, 37]. As evidenced in Figure 9, with frequent ISL and path changes, this fine-grained control becomes overwhelming and triggers signaling storms to satellites for exhaustive inter-satellite routing reconfigurations.
• Slow response to unpredictable dynamics: Random satellite failures and intermittent ISLs are a norm rather than an exception. They may be exacerbated in non-uniform LEO networks due to the complexity of ISL acquisition, tracking, and pointing under satellite mobility [17, 38]. TS-SDN relies on the control plane to react to these failures, which can be slow (multi-seconds to minutes [14, 16]) due to the disparity in timescales between intermittent failure occurrence (seconds or shorter) TS-SDN's remote control.

To address both challenges, TinyLEO streamlines state-of-the-art TS-SDNs by stabilizing high-level networking intents (demands) by satellite-independent geography and decoupling them from their low-level dynamic enforcements (supplies). It splits its control plane into geographic traffic engineering intents and an orbital model predictive controller to move the responsibility of handling most LEO dynamics to the data plane in §4.3.

Geographic traffic engineering intent: In practice, most operators care more about what network policy to adopt rather than which satellite(s) to enforce it. No matter how satellites move and interconnect, the geographic locations of users remain stable. Moreover, with TinyLEO's supply-demand matching in §4.1, the minimal number of available satellites over each geographic cell is also stable. Based on both invariants, TinyLEO offers stable high-level APIs for operators to customize their traffic engineering intents by geography without worrying about low-level LEO dynamics.

Figure 10 shows TinyLEO's geographic networking intent abstraction. It reuses each geographic cell \(u\) in §4.1 as a basic unit and assigns it two attributes: its geographic location \(L_u\) and minimal number of available satellites \(n_u\) (i.e., radio access link and ISL capacity) given by Algorithm 1. The operator can define the geographic topology \(G(V, E, N)\) on top of these cells, where each node \(u \in V\) is a geographic cell, an edge \((u,v) \in E\) exists if cell \(u\) and \(v\) needs to be connected via ISLs, and its weight \(N_{u,v} \in \mathbb{N}\) (\(n_{u,v} \le min\{n_u, n_v\}\)) represents the required number of ISLs between \(u\) and \(v\). To support versatile policies, TinyLEO lets the operator define any geographic topology under only two physical constraints: the maximal per-cell satellite count (\(n_u \ge \Sigma_{(u,v) \in V} n_{u,v}, \forall u \in E\)) and inter-cell distance for visible ISL setup. On top of this geographic topology, the operator can customize versatile traffic engineering policies, such as the shortest-path routing, multipath load balancing [39], trans-oceanic traffic offloading [31], and detour away from undesirable areas [40, 41], to name a few. These routes can be modified over time, e.g., to optimize for diurnal user activities in §2.2. Each route is encoded as a list of hop-by-hop geographic cells \(u \to w_1 \to w_2 \to \dots \to v\) and passed to data plane in §4.3 for runtime enforcement.

Orbital model predictive controller (MPC): To decouple the above stable traffic engineering policy from its runtime dynamic enforcement, TinyLEO inserts a MPC shim layer [23] between the high-level control intent and the data plane. As a classic sequential decision-making framework, MPC lets us iteratively collect the runtime LEO network status, forecast its short-term evolutions based on these feedbacks and orbital laws, and decide near-term control actions with these predictions. Different from existing TS-SDN, this MPC is only responsible for geographic topology enforcement and does not adapt routing to all LEO physical dynamics. Instead, TinyLEO moves the latter task to its data plane for higher efficiency and lower signaling costs, as we will detail in §4.3.

Figure 10 presents how TinyLEO's MPC compiles the high-level geographic topology intent \(G(V, E, N)\) to a low-level equivalent satellite network topology at runtime. It seeks to stabilize the LEO network topology as long as possible since frequent ISL reconfigurations are not desirable [17, 38]. To this end, TinyLEO adopts a three-stage stable matching. At each time slot \(t\), for each geographic cell \(u\), it first predicts which satellites cover it based on orbital laws. For each \(u\)'s connected neighbor \(v\) with \(n_{u,v} > 0\), \(u\) should allocate \(n_{u,v}\) out of its \(n_u\) satellites as "gateways" toward \(v\) via ISLs to meet the demand. TinyLEO models it as a classic many-to-one stable matching [42]: It constructs a weighted bipartite graph with left nodes as each of \(u\)'s satellites \(s\), right nodes as \(u\)'s connected neighboring cells (\(\{v|n_{u,v} > 0\}\)), and the edge weight \(\tau_{s,v} \ge 0\) as each satellite \(s\)'s preference to be the gateway toward \(v\). To stabilize the LEO network topology, we set \(\tau_{s,v}\) as the expected ISL lifetime (larger \(\tau_{s,v}\) preferred):

\(\tau_{s,v} = \frac{1}{n_v} \sum_{s' \in v} \tau_{s,s'}\)

where \(\tau_{s,s'}\) is the ISL lifetime if satellite \(s\) and \(s'\) are connected and can be predicted based on their visibility and orbital laws. To stabilize this topology, TinyLEO runs the Gale-Shapley algorithm [42] to generate a stable many-to-one matching for each neighboring cell \(v\) demanding \(n_{u,v}\) satellites from \(u\). Afterward, each connected cell pair \((u, v)\) has allocated \(n_{u,v}\) satellites to each other. Then, TinyLEO runs another one-to-one stable matching [42] between these satellites in \(u\) and \(v\) using the ISL lifetime \(\{\tau_{s,s'}\}_{s \in u, s' \in v}\) as satellite \(s \in u\)'s preference to \(s' \in v\). Last, inside each cell \(u\), TinyLEO connects all above matched satellites \(s \in u\) as a ring to ensure their connectivity. This ends up with a LEO network topology that enforces the geographic topology intent \(G(V, E, N)\) and maximizes its average ISL lifetime for topological stability.

Repairing unpredictable failures: Once TinyLEO's MPC receives runtime ISL/satellite failure reports from the data plane, it will repair them to keep satisfying geographic topology intents. It checks the unsatisfied residual demands of the geographic intent after failures, incrementally runs the above three-stage matching for residual demands, and finds new ISLs/satellites to replace failed ones.

在缩减低轨网络规模后，TinyLEO的下一个任务是使这个非均匀的低轨网络易于使用。如果这些低轨卫星仅作为§2.1中的接入网络，那么这个任务在§4.1中已经完成，因为TinyLEO确保了随时随地都有足够的无线接入链路容量。如果这些卫星还需要作为骨干网络，通过其星间链路（ISL）传输数据流量，那么TinyLEO还必须管理这个极度动态、非均匀的低轨网络中额外的拓扑和路由复杂性。

为了理解非均匀低轨物理动态对拓扑和路由的影响，图9展示了在同等规模的TinyLEO和均匀低轨网络中，所有潜在星间链路和卫星间最短路径的更新频率。由于多样化轨道参数导致了异构的卫星运动，稀疏的低轨网络将不可避免地比均匀网络遇到更多的星间链路和路由变化。如果处理不当，这两者都可能损害网络的可用性、效率和弹性 [14–18]。这种复杂性对于稀疏低轨网络是无法避免的。

在现行的低轨网络中，当前的主流解决方案是利用规律的轨道运动来实现预测性时空软件定义网络（TS-SDN）。例如，Starlink [17, 26] 和 Aalyria [14–16] 采用TS-SDN来预测卫星运动，在时空维度上搜索潜在的星间链路和路径，并相应地优化演进中的卫星网络拓扑和路由。虽然这种方法在均匀低轨网络中有效且成本可控，但在极度动态的非均匀低轨网络中，它可能变得不稳定且成本高昂，原因有二：

• 高昂的控制成本：现有的TS-SDN几乎将所有底层的低轨物理动态、逻辑网络拓扑和逐跳卫星路由都暴露给上层进行控制 [14–16, 37]
  • 如图9所示，随着星间链路和路径的频繁变化，这种细粒度的控制会变得难以承受，并会向卫星触发信令风暴，以进行详尽的星间路由重构
• 对不可预测动态的响应缓慢：随机的卫星故障和间歇性的星间链路是常态而非例外
  • 在非均匀低轨网络中，由于卫星移动性下星间链路捕获、跟踪和指向的复杂性，这些问题可能加剧 [17, 38]
  • TS-SDN依赖控制平面来应对这些故障，但由于间歇性故障发生的时间尺度（秒级或更短）与TS-SDN的远程控制之间存在差异，其响应可能很慢（数秒到数分钟 [14, 16]）

为应对这两个挑战，TinyLEO通过稳定独立于卫星的地理高级网络意图（需求），并将其与底层的动态执行（供应）解耦，从而简化了最先进的TS-SDN。它将其控制平面拆分为地理流量工程意图和一个轨道模型预测控制器，从而将处理大部分低轨动态的责任转移到§4.3的数据平面。

地理流量工程意图

在实践中，大多数运营商更关心采纳什么网络策略，而非由哪颗卫星来执行。无论卫星如何移动和互联，用户的地理位置保持稳定。此外，通过§4.1中TinyLEO的供需匹配，每个地理单元上空的最小可用卫星数量也是稳定的。基于这两项不变量，TinyLEO为运营商提供了稳定的高级API，使其可以按地理位置定制其流量工程意图，而无需担心底层的低轨动态。

图10展示了TinyLEO的地理网络意图抽象。它复用了§4.1中的每个地理单元 \(u\) 作为基本单位，并为其分配两个属性：其地理位置 \(L_u\) 和由算法1给出的最小可用卫星数量 \(n_u\)（即无线接入链路和星间链路容量）。运营商可以在这些单元之上定义地理拓扑 \(G(V, E, N)\)，其中每个节点 \(u \in V\) 是一个地理单元，如果单元 \(u\) 和 \(v\) 需要通过星间链路连接，则存在一条边 \((u,v) \in E\)，其权重 \(N_{u,v} \in \mathbb{N}\) (\(n_{u,v} \le \min\{n_u, n_v\}\)) 代表了 \(u\) 和 \(v\) 之间所需的星间链路数量。为了支持多样的策略，TinyLEO允许运营商在仅有的两个物理约束下定义任何地理拓扑：每个单元的最大卫星数量（\(n_u \ge \Sigma_{(u,v) \in V} n_{u,v}, \forall u \in E\)）和为建立可见星间链路的单元间距离。在此地理拓扑之上，运营商可以定制多样的流量工程策略，例如最短路径路由、多路径负载均衡 [39]、跨洋流量卸载 [31] 以及绕行不受欢迎的区域 [40, 41] 等。这些路由可以随时间修改，例如为优化§2.2中用户的昼夜活动。每条路由被编码为一个逐跳的地理单元列表 \(u \to w_1 \to w_2 \to \dots \to v\)，并传递给§4.3中的数据平面进行实时执行。

轨道模型预测控制器（MPC）

为了将上述稳定的流量工程策略与其运行时的动态执行解耦，TinyLEO在高级控制意图和数据平面之间插入了一个MPC适配层 [23]。作为一种经典的序贯决策框架，MPC允许我们迭代地收集实时低轨网络状态，基于这些反馈和轨道定律预测其短期演变，并利用这些预测来决定近期的控制动作。与现有的TS-SDN不同，此MPC仅负责执行地理拓扑意图，而不会为了适应所有低轨物理动态而调整路由。相反，TinyLEO将后一项任务转移到其数据平面，以实现更高的效率和更低的信令成本，我们将在§4.3中详述。

图10展示了TinyLEO的MPC如何在运行时将高级的地理拓扑意图 \(G(V, E, N)\) 编译为等效的底层卫星网络拓扑:

它力求尽可能长时间地稳定低轨网络拓扑，因为频繁的星间链路重构是不可取的 [17, 38]。为此，TinyLEO采用了一个三阶段的稳定匹配。在每个时间槽 \(t\)，对于每个地理单元 \(u\)，它首先基于轨道定律预测哪些卫星正在覆盖它。对于 \(u\) 的每个已连接邻居 \(v\)（\(n_{u,v} > 0\)），\(u\) 需要从其 \(n_u\) 颗卫星中分配 \(n_{u,v}\) 颗作为朝向 \(v\) 的“网关”，通过星间链路来满足需求。TinyLEO将其建模为一个经典的多对一稳定匹配问题 [42]：它构建一个加权二分图，左侧节点为 \(u\) 的每颗卫星 \(s\)，右侧节点为 \(u\) 的已连接邻居单元（\(\{v|n_{u,v} > 0\}\)），边权重 \(\tau_{s,v} \ge 0\) 代表卫星 \(s\) 成为朝向 \(v\) 的网关的偏好度。为了稳定低轨网络拓扑，我们将 \(\tau_{s,v}\) 设置为预期的星间链路持续时间（\(\tau_{s,v}\) 越大越好）：

\[\tau_{s,v} = \frac{1}{n_v} \sum_{s' \in v} \tau_{s,s'}\]

其中 \(\tau_{s,s'}\) 是在卫星 \(s\) 和 \(s'\) 连接情况下的星间链路持续时间，可以根据它们的可见性和轨道定律进行预测。为稳定此拓扑，TinyLEO运行盖尔-沙普利算法 [42]，为每个从 \(u\) 请求 \(n_{u,v}\) 颗卫星的邻居单元 \(v\) 生成一个稳定的多对一匹配。之后，每个连接的单元对 \((u, v)\) 都已相互分配了 \(n_{u,v}\) 颗卫星。接着，TinyLEO在 \(u\) 和 \(v\) 的这些卫星之间，使用星间链路持续时间 \(\{\tau_{s,s'}\}_{s \in u, s' \in v}\) 作为卫星 \(s \in u\) 对 \(s' \in v\) 的偏好度，运行另一个一对一稳定匹配 [42]。最后，在每个单元 \(u\) 内部，TinyLEO将所有上述已匹配的卫星 \(s \in u\) 连接成一个环，以确保它们的连通性。最终形成一个既能执行地理拓扑意图 \(G(V, E, N)\)，又能为实现拓扑稳定而最大化其平均星间链路持续时间的低轨网络拓扑。

修复不可预测的故障

一旦TinyLEO的MPC从数据平面接收到实时的星间链路/卫星故障报告，它将进行修复以继续满足地理拓扑意图。它会检查故障后地理意图中未被满足的剩余需求，为剩余需求增量式地运行上述的三阶段匹配，并找到新的星间链路/卫星来替换故障的部分。

4.3 Data Plane: Geographic Segment Anycast

As explained in §4.2, TinyLEO decouples geographic routing policy intents from their runtime enforcement by satellites. To achieve this, it enhances its data plane for efficient, policy-compliant routing under the sparse LEO network's dramatic dynamics. Since each satellite's local data plane is closer to LEO dynamics than remote control planes, this separation of concern can increase the network availability and utilization, speed up failure recoveries, and lower the control overhead.

如§4.2所述，TinyLEO将地理路由策略意图与其由卫星执行的运行时实施进行解耦。为实现此目的，它增强了其数据平面，以便在稀疏低轨网络的剧烈动态下实现高效、策略合规的路由。由于每颗卫星的本地数据平面比远程控制平面更接近低轨动态，这种关注点分离可以提升网络可用性和利用率，加速故障恢复，并降低控制开销。

To achieve these objectives, TinyLEO builds its data plane with geographic segment routing. Segment routing (SR) [43–46] is an IETF-standardized source routing scheme over IPv6 or MPLS (both used in Starlink [47, 48]). In §4.2, TinyLEO encodes each network operator-defined route intent as a list of geographic cells \(u \to w_1 \to w_2 \to \dots \to v\) for hop-by-hop forwarding, which is a natural use case of SR. As shown in Figure 11 (cross-oceanic traffic offloading as an example), each segment in this route represents a geographic cell. It is stable and decoupled from the rapidly changing satellites. Any satellite covering this cell can receive a packet destined for this segment, extract the next-hop cell from the segment list, and locally forward it to any satellite in the next cell via in-packet location-based geographic routing [49–53]. Unlike logical IP/MPLS routing over satellite topologies, this geographic anycast defeats LEO dynamics for various benefits:

• Near-stateless: Unlike link-state [54], distance-vector [14], tunneling [26], and ad hoc on-demand routing [55, 56] that require every LEO satellite to exchange, update, and maintain local stateful routes, geographic segment anycast eliminates these states and their frequent updates caused by heterogeneous satellite mobility. This saves remarkable signaling overheads for resource-constrained satellites;
• High network availability/utilization: Any satellite and its ISLs in each cell can deliver traffic for fault-tolerant, geographically load-balanced services;
• Fast failure recovery: Upon unpredictable link/satellite outages (e.g., by solar storms and radiations), each satellite can locally reroute through any alternative ISLs/satellites in the cell without waiting for the remote control plane;
• Low control overhead: Geographic routing eliminates the need for frequent computations and updates of satellite routes over the dynamic LEO network topology;

为达成这些目标，TinyLEO采用地理分段路由构建其数据平面。

分段路由（Segment Routing, SR）[43–46] 是一种IETF标准化的源路由方案，可运行于IPv6或MPLS之上（两者均在Starlink中使用 [47, 48]）。

在§4.2中，TinyLEO将网络运营商定义的每条路由意图编码为一个地理单元列表 \(u \to w_1 \to w_2 \to \dots \to v\) 以进行逐跳转发，这正是SR的一个自然用例。如图11所示（以跨洋流量卸载为例）， 该路由中的每个段（segment）代表一个地理单元。 它是稳定的，并与快速变化的卫星解耦。覆盖该单元的任何卫星都可以接收发往此段的数据包，从段列表中提取下一跳单元，并通过包内基于位置的地理路由，在本地将其转发到下一单元内的任意一颗卫星 [49–53]。与基于卫星拓扑的逻辑IP/MPLS路由不同，这种地理任播（anycast）克服了低轨动态性，带来了多种好处：

• 近乎无状态：与链路状态 [54]、距离矢量 [14]、隧道 [26] 和自组织按需路由 [55, 56] 等需要在每颗低轨卫星上交换、更新和维护有状态本地路由的协议不同，地理分段任播消除了这些状态及其因异构卫星移动性导致的频繁更新。这为资源受限的卫星节省了显著的信令开销。
• 高网络可用性/利用率：每个单元内的任何卫星及其星间链路都可以传输流量，从而实现容错和地理上的负载均衡服务。
• 快速故障恢复：当发生不可预测的链路/卫星中断时（例如由太阳风暴和辐射引起），每颗卫星都可以在本地通过单元内的任何备用星间链路/卫星重新路由，而无需等待远程控制平面的指令。
• 低控制开销：地理路由无需在动态的低轨网络拓扑上频繁计算和更新卫星路由。

Despite appealing, geographic routing is prone to forwarding failures due to its local greedy nature. Without global routes, it can get stuck in a "local minimum" where a node is closer to the destination than all its neighbors but is obstructed from reaching it. While this problem can be solved via face routing in 2D planar networks [49, 50], it becomes complicated [51] or even impossible [52] to solve in 3D spaces, such as non-uniform LEO networks in our case. Recent LEO-specific geographic routing schemes [18, 53] resolve this issue with domain knowledge. However, they only work for uniform LEO networks like Walker constellations [28] or multi-shell networks [18]. Unfortunately, neither assumption holds for TinyLEO's non-uniform, heterogeneous network topology.

尽管地理路由很有吸引力，但由于其本地贪心性质，它容易出现转发失败。在没有全局路由信息的情况下，它可能会陷入“局部最小值”问题，即一个节点比其所有邻居都更接近目的地，但却无法到达。虽然该问题在二维平面网络中可通过面路由（face routing）解决 [49, 50]，但在三维空间中则变得复杂 [51] 甚至无法解决 [52]，而我们的非均匀低轨网络正属于此种情况。近期的针对低轨网络的地理路由方案 [18, 53] 利用领域知识解决了此问题。然而，它们仅适用于均匀的低轨网络，如沃克星座（Walker constellations）[28] 或多壳层网络 [18]。不幸的是，这两个假设都不适用于TinyLEO的非均匀、异构网络拓扑。

Instead, TinyLEO's data plane ensures traffic delivery with a simple observation: Its segment-by-segment geographic anycast is navigated by its higher-layer route intents in §4.2, which is based on global topological information. Once this high-level route intent is loop-free and reachable to the destination (easily verifiable at the control plane), TinyLEO's data-plane enforcement also ensures traffic delivery as long as each hop is reachable. This condition is easily satisfied in TinyLEO's topology in §4.2: As shown in Figure 10, any two connected geographic cells in the topology intent have corresponding 1-hop ISLs in the runtime satellite topology.

Figure 11 shows TinyLEO's data-plane workflow based on these observations. Upon receiving a packet, each satellite extracts its next-hop geographic cell (segment) to forward to. If it has a direct ISL to a gateway satellite covering this next-hop cell, it immediately forwards this packet through this ISL. Otherwise, it uses the "intra-domain" ring in §4.2 to clockwise pass this packet to its next neighboring satellite inside the same cell. Since this ring connects all gateway satellites of each cell, the packet is guaranteed to eventually reach a gateway destined to the next-hop cell for successful delivery. In the worst case that this ring is disconnected by random failures, this packet will be buffered until TinyLEO's MPC in §4.2 repairs this ring to continue its delivery.

TinyLEO的数据平面转而通过一个简单的观察来确保流量交付：其逐段的地理任播是由§4.2中基于全局拓扑信息的高层路由意图来引导的。一旦这个高层路由意图被验证为无环路且可达目的地（这在控制平面上很容易验证），只要每一跳都可达，TinyLEO的数据平面执行也能保证流量的交付。这个条件在§4.2的TinyLEO拓扑中很容易满足：如图10所示，拓扑意图中任何两个相连的地理单元，在运行时的卫星拓扑中都有对应的单跳星间链路。

图11展示了基于这些观察的TinyLEO数据平面工作流程:

1. 在收到一个数据包后，每颗卫星提取其要转发的下一跳地理单元（段）
2. 如果它有一条直连到覆盖下一跳单元的网关卫星的星间链路，它会立即通过该链路转发数据包
3. 否则，它利用§4.2中的“域内”环路，将数据包顺时针传递给同一单元内的下一个相邻卫星

由于该环路连接了每个单元的所有网关卫星，数据包保证最终能够到达一个目的地为下一跳单元的网关，从而成功交付。在最坏的情况下，如果该环路因随机故障而断开，数据包将被缓存，直到§4.2中的TinyLEO MPC修复该环路以继续其交付。

TinyLEO Community Toolkit

In essence, TinyLEO is designed as an affordable, sustainable satellite network solution for small ISPs and countries. To achieve this goal and foster more community efforts in this direction, we have implemented all features in TinyLEO as a complete community toolkit for open research and experiments. Our community toolkit distinguishes itself from recent LEO network simulators [57–60] since it not only supports packet-level data-plane tests, but also offers upstream LEO network planning and control-plane features. It also departs from current commercial TS-SDN controllers [14–16] by offering geographic networking intent APIs and open-source orbital MPC-based control logic. This toolkit can be used to synthesize sparse LEO networks on demand, specify high-level networking intents by geography, enforce these intents at runtime with orbital MPC, and conduct per-packet emulations with hardware in the loop (see [24] for details). As shown in Figure 12, it consists of two core components:

本质上，TinyLEO被设计为一个面向小型互联网服务提供商（ISP）和国家的经济、可持续的卫星网络解决方案。为实现这一目标并鼓励社区在这一方向上做出更多努力，我们将TinyLEO的所有功能实现为一个完整的社区工具包，用于开放研究和实验。我们的社区工具包与近期的低轨网络模拟器[57–60]不同，因为它不仅支持数据包级的数据平面测试，还提供了上游的低轨网络规划和控制平面功能。它也不同于当前的商业化TS-SDN控制器[14–16]，因为它提供了地理网络意图API和开源的、基于轨道MPC的控制逻辑。该工具包可用于按需合成稀疏低轨网络，按地理位置指定高级网络意图，在运行时通过轨道MPC执行这些意图，并进行带硬件在环的逐包仿真（详见[24]）。如图12所示，它由两个核心组件构成：

Offline LEO network synthesizer: This tool implements TinyLEO’s demand-driven LEO network sparsification in §4.1. On the network supply side, it routinely tracks the public space-track satellite orbital traces [61] and ITU orbit allocation databases [62] to learn existing satellites and space objects in orbit, extracts all unoccupied/unallocated Earth-repeat orbits accordingly, and stores their ground tracks into the texture library as TinyLEO’s candidates for its network supply-demand matching. On the network demand side, this tool offers APIs to specify serviceable demands for each geographic cell in the unit of the number of satellites. Given both inputs, this synthesizer runs Algorithm 1 to output a sparse LEO network layout to meet the demands. To optimize its runtime efficiency, our implementation encodes the LEO network supplies x, demands y t , and coverage matrix A t using compressed sparse row (CSR) matrices [63] to speed up matrix additions/multiplications and save storage costs. We have also parallelized Algorithm 1’s demand matching of all orbit candidates (line 6–7) for acceleration.

离线低轨网络合成器： 该工具实现了§4.1中TinyLEO的需求驱动的低轨网络稀疏化。在网络供应端，它定期跟踪公开的space-track卫星轨道轨迹[61]和ITU轨道分配数据库[62]，以了解在轨的现有卫星和空间物体，据此提取所有未占用/未分配的地球重复轨道，并将其地面轨迹存入纹理库，作为TinyLEO进行供需匹配的候选供应。在网络需求端，该工具提供API，用于以卫星数量为单位指定每个地理单元的可服务需求。给定这两项输入，该合成器运行算法1，输出一个稀疏的低轨网络布局以满足需求。为优化其运行时效率，我们的实现使用压缩稀疏行（CSR）矩阵[63]来编码低轨网络供应 \(x\)、需求 \(y_t\) 和覆盖矩阵 \(A_t\)，以加速矩阵的加法/乘法运算并节省存储成本。我们还对算法1中所有候选轨道的匹配过程（第6-7行）进行了并行化以加速计算。

---

Online LEO network orchestrator: It comprises a series of control-plane and data-plane tools, including:

(1) Geographic northbound API: It implements TinyLEO’s geographic traffic engineering intent abstractions in §4.2 and a network verifier to pre-check the geographic topology connectivity and routing path reachability and loop-freedom (§4.3). It allows researchers, developers, and operators to specify and test versatile topology, routing, and traffic engineering policies in LEO satellite networks.

(2) Orbital model predictive controller: This shim layer realizes TinyLEO’s orbital MPC in §4.2 to compile the above geographic topology intents to runtime satellite topology and adapt to random satellite/ISL failures.

(3) Geo-segment anycast: This module realizes TinyLEO’s dataplane geographic segment anycast in §4.3. It is built atop StarryNet [58] with three key enhancements. First, we use Linux 5.4.0 kernel’s native in-kernel support for segment routing over IPv6 (SRv6 [44, 45]) to implement geographic segment anycast. Second, we add a gRPC-based southbound API agent per satellite to exchange control commands and runtime ISL/satellite status with TinyLEO’s MPC (§4.2). Third, we optimize StarryNet’s satellite virtualizations by customizing lightweight Linux namespace-based containers and supporting uneven LEO topologies. This allows for a larger-scale, more flexible packet-level LEO network emulation in the next section.

在线低轨网络编排器： 它包含一系列控制平面和数据平面的工具，包括：

(1) 地理北向API： 它实现了§4.2中TinyLEO的地理流量工程意图抽象，以及一个网络验证器，用于预先检查地理拓扑的连通性以及路由路径的可达性和无环路性（§4.3）。它允许研究人员、开发者和运营商在低轨卫星网络中指定和测试多样的拓扑、路由和流量工程策略。

(2) 轨道模型预测控制器： 该适配层实现了§4.2中TinyLEO的轨道MPC，用于将上述地理拓扑意图编译为运行时的卫星拓扑，并适应随机的卫星/星间链路故障。

(3) 地理分段任播： 该模块实现了§4.3中TinyLEO的数据平面地理分段任播。它构建于StarryNet[58]之上，并进行了三项关键增强。

首先，我们使用Linux 5.4.0内核对基于IPv6的分段路由（SRv6 [44, 45]）的原生内核内支持来实现地理分段任播

其次，我们为每颗卫星添加了一个基于gRPC的南向API代理，用于与TinyLEO的MPC（§4.2）交换控制命令和运行时的星间链路/卫星状态

第三，我们通过定制基于Linux命名空间的轻量级容器并支持非均匀的低轨拓扑，优化了StarryNet的卫星虚拟化。这使得在下一节中进行更大规模、更灵活的数据包级低轨网络仿真成为可能

Evaluation

tldr

Discussion

Radio link optimizations with TinyLEO: While primarily designed for sparse LEO satellite networking, TinyLEO can also help with their last-hop radio access links’ spectrum management, interference mitigation, resource scheduling, and more tasks. It can sparsify satellite radio links covering each area to alleviate their overlapping, interference, and resource competition. Its stable geographic intents in §4.2 can also mask complex LEO mobility to simplify these tasks as less dynamic optimizations like terrestrial mesh networks.

Deployment incentives: TinyLEO may be more attractive to small ISPs and countries since it lowers their barriers to entering the market. Regulators (e.g., ITU) may also welcome it since it can stimulate the LEO network market with more players, unleash orbit resources, and relieve space congestion. While LEO megaconstellation operators (e.g., Starlink) may not be incentivized to shrink their network scale due to their market hold, they can still adopt TinyLEO’s control and data planes for higher network efficiency. Their satellites can also be safer if others adopt TinyLEO with low orbital congestion.

LEO network decentralization: Besides TinyLEO, another emerging vision of alleviating monopoly, capital costs, and satellite wastes is to build a decentralized multi-party LEO network [71, 72] for multi-tenant access [73], backhaul rental [32], and multi-tasking [74]. Fulfilling this great long-term vision is nontrivial since it calls for substantial efforts of trust establishment, heterogeneous internetworking, and protocol standardization among global players with inconsistent interests. TinyLEO is free of these issues due to its single-entity network nature. Instead, it can boost this LEO network decentralization by enabling more entrants and letting each contribute its (regional) networks at low costs (Figure 14c). Limitations and future work: As an initial attempt at small LEO networks for global-scale demands, TinyLEO has some inevitable limitations that deserve future work. First, TinyLEO shrinks the satellite network at the cost of more LEO dynamics, hence leading to more challenges for network availability, efficiency, and resiliency. While our current design has significantly mitigated these issues, it currently relies on Earth-repeat ground tracks. It would be nice to unlock ground tracks beyond Earth-repeat ones for more stable and sparser LEO networks. Second, TinyLEO’s control plane can be decentralized to facilitate the above multi-party LEO network (akin to BGP). Last but not least, TinyLEO’s data plane should be enhanced for future deterministic networking (DetNet).

TinyLEO对无线链路的优化： 尽管TinyLEO主要为稀疏低轨卫星网络设计，但它也有助于其最后一跳无线接入链路的频谱管理、干扰抑制、资源调度等任务。它可以通过稀疏化覆盖每个区域的卫星无线链路，来缓解它们的重叠、干扰和资源竞争。其在§4.2中稳定的地理意图也可以屏蔽复杂的低轨移动性，将这些任务简化为类似地面网状网络的低动态优化问题。

部署激励： TinyLEO对小型ISP和国家可能更具吸引力，因为它降低了它们进入市场的门槛。监管机构（如ITU）也可能欢迎它，因为它可以通过引入更多参与者来激发低轨网络市场，释放轨道资源，并缓解空间拥堵。虽然低轨巨型星座运营商（如Starlink）可能因其市场主导地位而没有动力去缩减其网络规模，但他们仍然可以采用TinyLEO的控制和数据平面来提升网络效率。如果其他方采用TinyLEO从而降低轨道拥堵，它们的卫星也会更安全。

低轨网络去中心化： 除了TinyLEO，缓解垄断、资本成本和卫星资源浪费的另一个新兴愿景是构建一个去中心化的多方低轨网络[71, 72]，以实现多租户接入[73]、回程租赁[32]和多任务处理[74]。实现这一宏大的长期愿景并非易事，因为它需要在利益不一致的全球参与者之间付出巨大的努力来进行信任建立、异构网络互联和协议标准化。由于其单一实体网络的性质，TinyLEO没有这些问题。相反，它可以通过赋能更多新进入者，并让各方以低成本贡献其（区域性）网络，来促进低轨网络的去中心化（图14c）。

局限性与未来工作： 作为针对全球规模需求的小型低轨网络的初步尝试，TinyLEO存在一些不可避免的局限性，值得未来进一步研究。首先，TinyLEO以增加低轨动态性为代价来缩减卫星网络，因此给网络的可用性、效率和弹性带来了更多挑战。虽然我们当前的设计已显著缓解了这些问题，但它目前依赖于地球重复地面轨迹。未来若能解锁除地球重复轨道之外的地面轨迹，将有望实现更稳定、更稀疏的低轨网络。其次，TinyLEO的控制平面可以去中心化，以促进上述的多方低轨网络（类似于BGP）。最后但同样重要的是，TinyLEO的数据平面应为未来的确定性网络（DetNet）进行增强。

Related Work

The recent surge of LEO mega-constellations has excited academia and industry for satellite networking R&D. Most of these works have centered around LEO mega-constellations, including but not limited to space topology designs [13, 70, 75], long-range radio optimizations [76–79], global collision and interference-free medium access [57, 80, 81], large-scale routing [18, 31, 39, 39, 53, 82], dynamic transport control [83–85], and security [86–89]. It was not until recently that the networking community started to rethink the concerns of LEO mega-constellations and explore decentralized LEO networks [32, 71–74] in §7 as alternatives. Instead, TinyLEO complements these efforts by directing shrinking the LEO network size while still satisfying network demands at scale.

Different from pure LEO constellation design [66] and networkonly optimizations [14–17], TinyLEO explores a co-design of offline network planning and online control/data plane operation. As shown in §4–§6, this is co-design crucial to both save more satellites and make the network usable.

近期低轨巨型星座的热潮激发了学术界和工业界对卫星网络研发的极大兴趣。这些工作大多围绕低轨巨型星座展开，包括但不限于空间拓扑设计[13, 70, 75]、远程无线优化[76–79]、全球无碰撞与无干扰的媒体接入[57, 80, 81]、大规模路由[18, 31, 39, 39, 53, 82]、动态传输控制[83–85]以及安全[86–89]。直到最近，网络社区才开始反思低轨巨型星座引发的关切，并探索§7中提及的去中心化低轨网络[32, 71–74]作为替代方案。与这些工作不同，TinyLEO通过致力于在满足大规模网络需求的同时缩减低轨网络规模，对这些努力进行了补充。

与纯粹的低轨星座设计[66]或单纯的网络优化[14–17]不同，TinyLEO探索了离线网络规划与在线控制/数据平面操作的协同设计。如§4–§6所示，这种协同设计对于节省更多卫星并使网络变得可用至关重要。

Conclusion

We propose TinyLEO, an alternative to LEO mega-constellation networks to meet global-scale demands with sparse satellites. TinyLEO is motivated by the insight that most satellites in mega-constellations are wasted due to their mismatch with uneven global network demands. Hence, it sparsifies LEO networks via spatiotemporal supply-demand matching and makes it usable via control/dataplane refinements. We hope TinyLEO can inspire more community efforts to enable affordable LEO satellite networks for small ISPs and countries, democratize this market with more players, and strive for sustainable “Internet from space” for all humanity.

我们提出了TinyLEO，一种低轨巨型星座网络的替代方案，旨在用稀疏的卫星满足全球规模的需求。TinyLEO的动机源于一个洞察：由于与不均衡的全球网络需求不匹配，巨型星座中的大多数卫星被浪费了。因此，它通过时空供需匹配来稀疏化低轨网络，并通过控制/数据平面的优化使其变得可用。我们希望TinyLEO能激励社区付出更多努力，为小型ISP和国家提供经济实惠的低轨卫星网络，通过引入更多参与者使这个市场民主化，并为全人类努力实现可持续的“太空互联网”。