xeoverse: A Real-time Simulation Platform for Large LEO Satellite Mega-Constellations

TL;DR

xeoverse introduces a real-time, high-fidelity simulator for LEO mega-constellations that pre-computes topology and routing, updates only the links that change, and focuses on scenario-relevant connections to achieve real-time execution on commodity hardware. Built on a two-stage workflow with Back Stage pre-computation and Main Stage Mininet emulation, the platform supports static routing via networkx and a weather-aware RF model for GSLs and ISLs. Compared to Hypatia and StarryNet, xeoverse delivers substantial speedups, scales to 1584 satellites on a single machine, and demonstrates fidelity to real-world conditions, including weather effects and ISL dynamics. This enables end-to-end protocol testing and research on large satellite networks with an accessible, low-footprint toolchain that can inform transport, routing, and application-layer decisions in mega-constellations.

Abstract

In the evolving landscape of satellite communications, the deployment of Low-Earth Orbit (LEO) satellite constellations promises to revolutionize global Internet access by providing low-latency, high-bandwidth connectivity to underserved regions. However, the dynamic nature of LEO satellite networks, characterized by rapid orbital movement and frequent changes in Inter-Satellite Links (ISLs), challenges the suitability of existing Internet protocols designed for static terrestrial infrastructures. Testing and developing new solutions and protocols on actual satellite mega-constellations are either too expensive or impractical because some of these constellations are not fully deployed yet. This creates the need for a realistic simulation platform that can accurately simulate this large scale of satellites, and allow end-to-end control over all aspects of LEO constellations. This paper introduces xeoverse, a scalable and realistic network simulator designed to support comprehensive LEO satellite network research and experimentation. By modeling user terminals, satellites, and ground stations as lightweight Linux virtual machines within Mininet and implementing three key strategies -- pre-computing topology and routing changes, updating only changing ISL links, and focusing on ISL links relevant to the simulation scenario -- xeoverse achieves real-time simulation, where 1 simulated second equals 1 wall-clock second. Our evaluations show that xeoverse outperforms state-of-the-art simulators Hypatia and StarryNet in terms of total simulation time by being 2.9 and 40 times faster, respectively.

Figures (7)

• Figure 1: Workflow of xeoverse Simulator. The process is divided into two stages. The xeoverse Back Stage builds the constellation topology, calculate the link characteristics in terms of latency and capacity, and finally compute the routing tables for each satellite. The xeoverse Main Stage configures a Mininet topology based on the inputs from xeoverse Back Stage, and run applications on top of Mininet.
• Figure 2: LEO Networks topology changes. Number of ISLs changes (left y-axis) per minute using colored dots: red for three occurrences, orange for two, and green for a single occurrence within each minute, visually representing the frequency and distribution of ISL changes.
• Figure 3: The total simulation time (including pre-compute and simulation updates times) for the 3 simulators when varying the number of satellites from $25$ to $1584$. xeoverse's simulation update time is $2.3$x and $40$x times less than Hypatia and StarryNet, respectively.
• Figure 4: Focusing only on the pre-compute time due to its computational demanding nature, and varying the number of ground segments from $20$ to $100$. We also focus only on Hypatia and xeoverse as we simulate a full constellation of $1584$ satellites in this experiment which cannot be achieved by StarryNet. xeoverse's pre-computation time is $2.9$x times less than Hypatia.
• Figure 5: xeoverse shows high-fidelity when compared to Hypatia. (a) shows how the changes in the ISL path between two terminals one in London and another in San Francisco impacts the observed data rate at these terminal (the shaded red area); yet that is not reflected in a replicated scenario in Hyptia. (b) shows the latency spike for the same scenario when the ISL path changes. (c) shows a rapid fluctuation of throughput for multiple path changes between two terminals in Paris and Sydney. (d) shows the latency spike between Paris and Sydney when the ISL path changes.