Evaluating Futuristic ISTN Research with STARRY NET: Case Studies

Next we conduct several case studies to show how STARRY NET can be used to advance futuristic ISTN research.

接下来，我们进行几个案例研究，展示如何使用 STARRY NET 推进未来 ISTN 研究。

7.1 Exploring the Design Space of Integrating LEO Satellites and Terrestrial Facilities

To realize the promise of low-latency and pervasive accessibility of ISTN, the first step should be interconnecting LEO satellites and terrestrial facilities (e.g., ground stations and user terminals). While many existing studies have proposed different space-ground topology designs, it still lacks a systematically analysis and comparison on these integration paradigms, in terms of their network performance and corresponding cost. We leverage STARRY NET to explore how different design choices of space-ground integration (as illustrated in Figure 10) could affect the performance and cost of an ISTN.

(1) Satellite relays for last-mile accessibility (SRLA). Satellites and ground facilities can be integrated based on the classic “bent-pipe” architecture to provide last-mile network accessibility as illustrated in Figure 10a, which is the status-quo of many today’s satellite constellations like OneWeb. Data from the ground are first transmitted to the satellite, which then sends it right back down again like a bent pipe. The only processing performed by satellites is to retransmit the signals.

(2) Satellite relays for ground station networks (SRGS). Figure 10b depicts another “bent-pipe”-based integration paradigm originally introduced in [57], where geo-distributed ground stations work as routers to construct a network. Each satellite switches packets between two ground stations connected to the satellite. Packets from the sender are routed to the receiver by paths built upon satellites and ground stations.

(3) Ground station gateway for satellite networks (GSSN). Figure 10c shows an ISL-based internetworking approach proposed by [52]. ISL-enabled satellites can build space routes for long-haul communication, without the need of a large number of ground station relays, as well as user-side satellite dishes. Satellites and ground stations build a Layer-3 network. During an end-to-end transmission, packets from the sender are first routed to a ground station via terrestrial Internet, then to the receiver side ground station over ISL-enabled satellites, and finally to the receiver over the terrestrial Internet.

(4) Directly accessed satellite networks (DASN). Figure 10d plots a paradigm where users’ satellite dishes directly connect to ISL-enabled satellite networks, and two users can establish long-haul communication without the assistance of geo-distributed ground stations [51,56]. Satellites work not only as routers, but also as access points/gateways allocating addresses for different terrestrial users.

星地融合组网范式对比分析:

为探究不同星地融合组网范式的性能与成本特征，本研究基于STARRY NET平台对四类典型拓扑（如图10）展开系统化对比：

(1) 星基末端接入(SRLA)

• 采用传统"弯管式"架构（图10a）
• 卫星仅承担信号中继功能（如OneWeb现网方案）
• 数据流：地面->卫星->地面

(2) 星基地面站组网(SRGS)

• 基于文献的分布式地面站路由架构（图10b）
• 卫星作为地面站间数据交换节点
• 依赖密集地面站部署
• 数据流：用户->地面站->卫星->地面站->卫星->......->地面站->卫星->用户

(3) 地面站网关组网(GSSN)

• ISL使能的星间路由方案（图10c）
• 卫星构建空间骨干网，地面站作网关
• 数据流：用户->地面站->星间网络->地面站->用户

(4) 卫星直连组网(DASN)

• 用户直连星间网络架构（图10d）
• 卫星兼具路由与接入网关功能
• 免除地面站中转
• 数据流：用户->星间网络->用户

Experiment setup. We leverage STARRY NET to build an ENE for each paradigm, analyze their cost, and evaluate their network performance. Specifically, we establish an ENE based on Starlink’s first constellation shell and its ground station distribution. We randomly pick geo-distributed user-pairs and establish communication sessions between these pairs over the satellite network. On each emulated satellite, we load BIRD [37] routing software and run OSPF as the routing protocol to achieve the shortest path for data transmission.

Observations. Table 3 summarizes the average end-to-end latency and the latency breakdown of different space-ground topology designs. We observe an obvious latency reduction accomplished by laser ISLs, and DASN obtains the lowest end-to-end latency on average. Since ground stations typically can not be deployed upon oceans (70% earth surface), SRGS suffers from the highest latency as compared with other schemes due to the insufficient deployment of ground stations.

As satellites move, two main factors affect the end-to-end network reachability. First, users in certain regions may lose available satellite access due to the LEO dynamics. For example, users in high latitude areas may suffer from intermittent satellite access. Second, frequent connectivity changes can trigger routing re-convergence. As plotted in Table 3, SRGS suffers from the lowest reachability due to the combination of LEO dynamics and limited coverage of insufficient ground stations. GSSN obtains low reachability because frequent satellite-ground handovers result in continuous reconvergence, during which routes are fluctuating and unstable.

For SRLA, SRGS and GSSN, the IP address of user’s satellite dish is allocated by the fixed user-side ground station, and the addresses of senders or receivers do not change during the communication. However, for DASN, each satellite works not only as a router, but also as an access point/a gateway which allocates IP addresses for terrestrial dishes connect to it. Due to the LEO dynamics, terrestrial dishes have to frequently change access satellite as well as their subnet. Consequently, addresses are frequently updated, which may further disrupt high layer transport connections and application sessions.

The above four topologies have different deployment and operating costs in addition to LEO satellites. SRLA and SRGS require a large number of available ground stations near users to guarantee continuous satellite coverage. For SRGS, it also requires sufficient geo-distributed ground stations to ensure stable and low-latency routes over satellites and ground stations. GSSN and DASN require the extra deployment of ISLs. Users in SRLA, SRGS and DASN have to purchase a dedicated dish to access satellites. In GSSN, users connect to the ground station gateway via terrestrial networks, and do not need to install additional satellite dishes.

Implications. As summarized in Table 3, there is no clear winner for all four integration methodologies. “Bent-pipe”-based approaches achieve simplicity without ISL requirements, but they fail to fully unleash the low-latency potential of ISTNs. Approaches relying on ISLs can form near-optimal spaces routes to attain wide-area low-latency communication, but they involve extra ISL cost, and suffer from higher route instability and connection disruptions, due to the route re-convergence and address update caused by LEO dynamics. All integration approaches have their limitations, and satellite operators are suggested to choose a proper topology based on their specific performance requirements and cost budgets.

基于星链首层星座与地面站分布构建实验环境，关键配置包括：

• 采用BIRD路由软件与OSPF协议
• 随机选取全球用户对建立通信会话
• 时延测量覆盖端到端全路径

性能对比（表3）

时延特性

• DASN平均时延最低（激光ISL优势显著）
• SRGS时延最高（受限于地面站覆盖不足）
• GSSN因频繁星地切换产生路由震荡

网络可达性

• SRGS可达性最低（LEO动态+地面站覆盖不足）
• GSSN受星地切换影响可达性次低
• DASN地址频繁更新导致传输层中断

部署成本

• SRLA/SRGS：依赖密集地面站部署
• GSSN/DASN：需额外ISL建设成本
• 用户端成本：SRLA/SRGS/DASN需专用终端，GSSN仅需地面网络接入

范式选择建议

• 弯管式方案：部署简单但时延优化有限
• ISL方案：时延优势显著但路由稳定性差
• 运营商需权衡时延需求、覆盖要求与成本预算，现阶段尚无普适最优解

Note

上述模式小结

1. Bent-Pipe Based: 优点是简单，便于部署；缺点是本质上还是走大型陆地网络，卫星只是起到最后中转的作用罢了
2. ISL Based: 优点是真正体现了ISTN的本质，走ISL真空介质传播速度更快；缺点是LEO高速移动，不稳定，易出错，丢包/路由混乱...

7.2 Evaluating ISTN Resilience

Satellites are operated in complex outer space environments. Small satellites deployed in emerging mega-constellations typically have a short lifetime (e.g., 3-5 years [30]) due to their low manufacturing cost. Many space factors or events, such as space debris [15], geomagnetic storms [12], and single event upset [28], etc., can cause immediate satellite failures. For example, in February 8, 2022, about 40 Starlink satellites are doomed by a geomagnetic storm [1]. Therefore, given the harsh and error-prone space environment, it should be important for satellite operators and researchers to evaluate and analyze how resilient an ISTN is, and what kind of system/network factors affect the resilience.

Experiment setup. We thus conduct an experiment with STARRY NET to evaluate the network resilience with different routing configurations. Specifically, we mimic the impact of a space failure (e.g., due to a geomagnetic storm) which makes a fraction of satellites in the constellation inactive and can not forward network traffic. We load BIRD [37] in our ENE and run OSPF as the routing protocol in this experiment.

Observations. Figure 11 plots the routing recovery time for a set of representative city-pairs under various failure ratios. An on-path satellite failure can cause a network disruption, and the routing recovery time increases as the constellation size and failure rate increase. Figure 12 plots the comparison for the end-to-end latency before the constellation failure and after the routing re-convergence. We observe that the latency increases slightly under low failure rate, and the latency dramatically increases when the failure rate reaches 30%.

Implications. We summarize three key implications from this experiment. First, we find the mesh-like network based on a large number of satellites can maintain low latency in case of low failure rate. This is because the mesh-like satellite network has high path diversity, offering backup routes for communication pairs in case of network failures. Second, the inherent high dynamicity of LEO satellites is a double-edge sword for the service restoration in an ISTN. On one hand, for terrestrial users whose access satellite above them fails, the dynamicity helps because faulty satellites will soon move out of their line-of-sight. On the other hand, the dynamicity hurts, as it spreads the failure globally, and could affect the network accessibility of other users. Finally, while improving redundancy in physical connectivity and applying robust mechanisms in protocol design are two critical directions to improve the ISTN resilience, it is challenging to attain a “winwin” integration of them in practical systems. Increasing the satellite density indeed improves the resilience of satellite accessibility in case of sudden failures, but it also involves much more nodes and links in the network, and thus imposes new challenges and requirements on the protocol scalability and recovery efficiency under various failure scenarios.

空间失效场景下的网络韧性分析:

实验背景

卫星在复杂太空环境中面临多重失效风险（空间碎片、地磁暴、单粒子翻转等）。例如 2022年2月地磁暴事件 导致约40颗星链卫星失效。本研究通过STARRY NET评估不同路由配置下的网络韧性，实验设置包括：

• 模拟空间失效导致部分卫星停止转发流量
• 采用BIRD路由软件与OSPF协议
• 测量典型城市对的路径恢复时间与时延变化

关键发现（图11-12）

路由恢复时间：

• 失效卫星位于通信路径时引发网络中断
• 恢复时间随星座规模与失效比例增加 呈非线性增长
• 大型星座在 30%失效率下恢复时间达分钟级

时延特征：

• 低失效率（<10%）时端到端时延增幅<15%
• 失效率达30%时平均时延激增2-3倍
• 网状拓扑的高路径冗余有效缓解低失效场景影响

韧性设计启示:

1. 冗余与动态性双刃剑效应：
   • 卫星动态性加速本地故障脱离视场
   • 同时导致故障影响全局扩散
2. 协议可扩展性挑战：
   • 增加卫星密度提升物理冗余
   • 但节点/链路激增考验路由协议收敛效率
3. 韧性优化方向：
   • 物理层：构建分级冗余星座架构
   • 网络层：开发快速重路由机制
   • 系统层：实现故障预测与主动防护

实验表明， 现有ISTN在应对大规模突发失效时仍存在显著性能退化 ，需通过跨层协同设计提升系统韧性。

7.3 Hardware-in-the-loop Testing

In real satellite deployments, it is very important to accurately estimate how much energy a new system or network function will consume before the launch. STARRY NET enables researchers to conduct hardware-in-the-loop testing to accurately evaluate the low-level system effects under various workloads. As a case study to demonstrate STARRY NET’s ability, we connect a 3U CubeSat prototype, equipped with a low-power processor [23,24] running real routing protocols to the virtual satellite network emulated by STARRY NET, as illustrated in Figure 13. Collectively, the 3U CubeSat prototype together with the emulation creates a virtual constellation network with 1584 Starlink satellites. We follow the satellite traffic model proposed in [51] to inject traffic and use a power monitor to measure the satellite prototype. Table 4 summarizes the power consumption in different states (e.g., calculating route convergence and forwarding traffic in various data rates). Our hardware-in-the-loop test demonstrates STARRY NET’s ability to create a hybrid ENE and evaluate real system effects for user-defined functionalities.

硬件在环系统效能验证:

为验证STARRY NET在真实硬件环境下的评估能力，本研究构建混合仿真环境（如图13所示）：

• 硬件配置：集成3U立方星原型机，搭载低功耗处理器（Raspberry Pi/Jetson TX2）运行真实路由协议
• 虚拟网络：仿真1584颗星链卫星构成星座网络
• 流量模型：采用文献提出的卫星流量特征注入数据
• 监测手段：使用功率监测设备实时记录原型机能耗

功耗分析（表4）

该案例为卫星网络功能部署前的能耗预估提供了可靠实验范式，可有效降低在轨运行风险。