An experimental evaluation of satellite constellation emulators

Abstract: Satellite emulation software is essential for research due to the lack of access to physical testbeds. To be useful, emulators must generate observations that are well-aligned with real-world ones, and they must have acceptable resource overheads for setting up and running experiments. This study provides an in-depth evaluation of three open-source emulators: StarryNet, OpenSN, and Celestial. Running them side-by-side and comparing them with real-world measurements from the WetLinks study identifies shortcomings of current satellite emulation techniques as well as promising avenues for research and development.

• The paper presents a systematic evaluation of three open-source emulators, revealing key differences in scalability, real-time updates, and fidelity compared to empirical measurements.
• It analyzes diverse methodologies including Docker, microVMs, and eBPF-based techniques to simulate satellite positions and network behaviors for trace-driven experiments.
• The study identifies major limitations in fidelity and resource management, advocating for modular, distributed architectures for robust LEO satellite network research.

Experimental Evaluation of Satellite Constellation Emulators

Introduction

This paper presents an exhaustive technical evaluation of three prominent open-source satellite constellation emulators—StarryNet, OpenSN, and Celestial—focusing on their fidelity to real-world measurements and their performance at scale. Given the lack of accessible hardware testbeds in non-terrestrial network (NTN) research, emulation is essential. The analysis extends beyond system-level realism, emphasizing emulator limitations and providing actionable insights for future development directions.

Emulator Architectures and Features

The three evaluated emulators each embody distinct architectural choices and implementation detail:

• StarryNet leverages Docker containers organized via the CLI, employing the tc netem framework to enforce link characteristics. Satellite positions and network states are precomputed using SGP4 and the Skyfield API, enabling trace-driven emulation and reducing online computational overhead. The mainline version suffers from limited scalability and prolonged bring-up times, while the development branch adopts the Linux Netlink API and a custom container runtime for improved performance but at the expense of portability.

Figure 1: StarryNet's architectural model utilizes Docker-based containerization, preprocessing satellite orbital states for trace-driven emulation.

• OpenSN uses Docker and Netlink APIs for nodes and links, respectively, delivering reduced bring-up latency. Unlike StarryNet, OpenSN computes satellite positions and link characteristics at runtime, resulting in significant dynamic delays as constellation size grows. Its architecture decouples constellation management and emulation daemons via a distributed key-value store (etcd), enabling flexible resource allocation at the cost of increased runtime contention.
• Celestial diverges by using Firecracker microVMs, assigning each satellite and ground station a dedicated VM. It implements bounding boxes to suspend VMs outside the region of interest, mitigating resource cost. Celestial enforces network connectivity with eBPF filters, but its star topology offers only approximate ISL emulation and sacrifices fidelity for efficiency. Visualisation for scenario setup is performed offline, improving user experience.

These architectural divergences drive tangible differences in scalability, fidelity, and operational overhead.

Fidelity Analysis

The study benchmarks emulator outputs against WetLinks dataset measurements, which characterize Starlink networks under varied atmospheric conditions. The emulators replicated specific scenarios, including satellite handovers and ground station coverage, but with simplified channel and scheduling models.

Figure 2: Side-by-side comparison of emulator and WetLinks bent-pipe round-trip times highlights persistent fidelity gaps.

Evaluation revealed major fidelity constraints:

• None of the emulators approach real-world RTT distributions; they neglect atmospheric variability, client scheduling, and complex satellite selection policies.
• Packet loss and latency modeling are overly simplistic (fixed averages, free-space propagation).
• ISL support is inconsistent: OpenSN enables multi-hop routing, StarryNet produces unstable paths, and Celestial's topology reduces long-haul ISLs to two-hop communication.
• Throughput emulation exhibits minimal variance; Celestial achieves greater downlink variance, while OpenSN's configuration errors limit acceptable downlink performance.

These observations underscore the inadequacy of current emulation strategies for high-fidelity research, suggesting the necessity for richer channel and scheduling models, modular architectures, and plugin interfaces for extensibility.

Resource Consumption and Scalability

The paper presents detailed resource scaling analysis:

• Node bring-up time is dominated by container or VM initialization and link configuration. StarryNet's mainline version demonstrates ∼10× longer startup times due to CLI/Docker interaction overheads.
• OpenSN, using API-based orchestration, achieves faster initialization but suffers from CPU contention and near-maximal utilization (>90%) at constellation-scale deployments—impacted by daemon resource requirements.
• Celestial demonstrates lowest average CPU utilization, benefiting from the VM suspension mechanism, though its lack of routing engines and grid topology emulation skews this metric.
• The StarryNet development branch outperforms all others in bring-up efficiency, but lacks root filesystem mounting, which diminishes reproducibility and hinders complex experiment scenarios.

Figure 3: Node and network bring-up times for StarryNet, OpenSN, StarryNet-dev, and Celestial, broken down by number of orbital planes.

• Link management overhead is minimized in Celestial due to lower link count (star topology), while StarryNet-dev scales better than OpenSN in configuring links, likely due to lower kernel contention.

Constellation Update Delays

Accurate real-time constellation updates are vital for experiment fidelity. The evaluation demonstrates:

• OpenSN's runtime update mechanism leads to unsustainable constellation step intervals (up to 55s for 20 orbital planes), resulting in misaligned simulation time and real-time measurements.
• StarryNet (mainline) and Celestial rely on precomputed offline constellation states; StarryNet suffers high update delays due to CLI-based link management.
• Celestial's usage of eBPF results in fast link updates, but this is only viable for scenarios with limited link complexity.

  Figure 4: Delays (log-scale) incurred by constellation state and link updates, emphasizing scalability challenges for real-time emulators.

Despite attempts to optimize, all emulators exhibit scaling limitations. Ideal architectures should parallelize and distribute both state computation and update processes, ensuring bounded delays and synchronization with real-world experiment timelines.

Practical and Theoretical Implications

The work exposes fundamental challenges: existing emulators are insufficient for accurate systems research in LEO satellite networks. Realistic modeling of channel characteristics, packet scheduling, and user heterogeneity is necessary. Additionally, operational scalability—bring-up and update times bound by network size—must be realized through parallel/distributed architecture and daemon-less or custom container runtimes augmented with root filesystems.

Theoretical implications encourage plugin-based modularity for emulator internals, enabling rapid integration of updated channel and scheduling models derived from empirical studies and reverse engineered insights.

Practically, improvements in visualisation interfaces, bounding box-based resource pruning, and support for heterogeneous constellation configuration would facilitate broader, rigorous experimental campaigns.

Future Directions

Future emulator architectures should:

• Leverage custom, lightweight container runtimes enabling user-generated root filesystems.
• Adopt eBPF for efficient and scalable network emulation.
• Employ parallelized precomputation and update strategies for constellation state, distributed across multiple machines to ensure scalability.
• Provide decoupled visualisation infrastructure for scenario design, bounding box mechanisms for resource reduction, and support for heterogeneous satellite node configurations.

These advances would enable rigorous systems-level emulation for NTNs, underpinning both theoretical frameworks and practical deployment optimizations in satellite network research.

Conclusion

A systematic comparison of StarryNet, OpenSN, and Celestial demonstrates that open-source satellite constellation emulators, while indispensable, are currently limited by fidelity deficits and operational scalability constraints. Addressing these will require significant architectural innovation: custom runtime environments, modular channel and scheduling modeling, distributed real-time updates, and standardized plugin interfaces. These improvements are imperative to support robust future research in LEO satellite networking.

(2604.04498)