STARRYNET Design

TL;DR for Chapter 4

这一章是系统核心组件的介绍，非常重要，但是过于细节与冗长。笔者在这里进行总结概括:

4.1 系统核心组件

• Constellation Observer
  • "博百家之长"，收集数据（相当于智慧化的“数据库”）
• Constellation Synchronizer
  • 计算目标的时空特性，进而配置参数
• Constellation Orchestrator
  • 资源的协同调度与分配
  • 与外部互联网流量交互
• Unified Abstraction: API
  • 研究员调用API使用StarryNet系统

4.2 Observer

简单的数据库维护与集成罢了

4.3 Synchronizer

1. 星座模型

采用双粒度描述机制：

1. 星座级：使用Walker星座构型描述法（N/P/p格式），其中N为单轨道面卫星数，P为轨道面总数，p为轨道面相位偏移因子；
2. 轨道级：通过轨道根数精细刻画卫星运行特征，包括：（1）轨道倾角；（2）运行高度；（3）相邻轨道面相位偏移系数（取值范围[0,1]）。

2. 地面站模型

通过三要素(LLH)表征地面站特征：（1）地理位置坐标；（2）可用通信天线数量；（3）最低通信仰角（决定空间-地面链路的可视时间窗口）。

3. 网络模型

定义星间/星地连接的动态规则：

影响因子	建模方法
可视性	基于LLH坐标与仰角约束实时计算
链路资源	配置卫星ISL接口与地面站天线容量
连接策略	提供+Grid（固定四邻连接， starlink里的1234）与Motif（可见性驱动）两种星间组网模式

4. 计算模型

支持差异化计算能力配置：

• 传统星载处理器（如BAE-RAD系列）建模：核频110-466MHz范围可调
• 商业货架产品（COTS）模拟：通过CPU频率缩放与时间配额限制实现多核仿真

5. 星座一致性保障机制

空间一致性，通过三阶段实现：

1. 容器资源规划：基于星座规模确定虚拟节点数量；
2. 星位解算：依据轨道根数实时计算各卫星的经纬度与高度（LLH信息）；
3. 可视性分析：结合LLH与仰角约束生成动态连接矩阵。

时间一致性，采用时间分片机制：

• 将实验周期划分为离散时隙（典型粒度1秒）
• 每个时隙内更新所有节点的空间状态与网络条件（连通性、传播时延等）
• 动态状态参数驱动协调器进行实时仿真环境重构

该机制确保实验环境与真实ISTN保持时间维度的高度同步，支持秒级精度的时变网络行为仿真。

4.4 Orchestrator

1. 多机器协同工作:
   • 选定一台机器作为manager
   • 其余是worker
2. 卫星拓扑之间的连接采用VLAN隔离方案:
   • 直接物理链路会“广播”，原因是machine-level
   • VLAN方案会实现Satellite Node级别的流量隔离，遂采用
3. 更新事件的方式 (保障时间一致性):
   • "集中式通信管理器"负载太大，且不具备扩展性，遂不考虑
   • 我们采用: 基于预测的多线程事件记忆化方法

4.5 APIs

1. 环境API: 人与系统的交互
2. Self API: 模拟系统中的“卫星”之间的交互

4.1 System Overview

Key idea. The design of STARRY NET is inspired by an important insight obtained from the satellite Internet ecosystem: many organizations (e.g., regulators and satellite operators) and end users have shared a collection of public data for the community, including constellation regulatory information [2,73], orbital data observed from realistic satellites [16, 38], ground station distributions [3, 26, 39], and performance results measured from terrestrial user terminals [32,33], etc. Based on this important fact, STARRY NET creates ISTN experimental environments on demand by judiciously combining: (1) crowd-sourced real data trace; (2) model-based orbit and network analysis; and (3) large-scale network system emulation, to construct a real-data-driven digital twin, i.e., a virtual presentation synchronized to a real physical ISTN in terrestrial environments. In particular, the key idea behind our STARRY NET design can be summarized as follows: (1) leveraging a crowd-sourcing approach to collect, combine and explore realistic constellation-relevant information to calculate the spatial and temporal characteristics consistent to real mega-constellations; then (2) driven by such realistic information, exploiting a large number of networked virtual nodes and links to flexibly emulate a customized experimental environment, which characterizes system-level effects and network behaviors consistent to a real ISTN.

System architecture. Figure 1 depicts STARRY NET’s architecture, including four core components as described below.

• A Constellation Observer (§4.2) that leverages a crowdsourcing approach to collect public constellation information, network performance, ground station distributions etc., from the satellite ecosystem. It maintains several databases to support, guide and drive the construction of ISTN experimental environments for various research requirements.

• A Constellation Synchronizer (§4.3) which exploits a collection of hybrid models to calculate the spatial and temporal characteristics of a specific mega-constellation, based on collected data as well as user-defined configurations. Specifically, such characteristics include constellation scale, visibility, connectivity, time-varying propagation delay, etc., which are further used to configure the network emulation.

• A Constellation Orchestrator (§4.4) for automating the management, coordination and allocation for resources used to build the experimental environment upon multiple physical machines. The orchestrator can also interact with realworld facilities (e.g., real satellite hardware) to support network experiments with interactive Internet traffic.

• A Unified Abstraction (§4.5) offering flexible and easyto-use APIs for researchers to create and manipulate the configurations of the ISTN experimental environment.

核心设计思想

STARRY NET的设计灵感源自卫星互联网生态系统的关键发现：监管机构、卫星运营商及终端用户已共享大量公开数据，包括星座监管信息[2,73]、真实卫星轨道观测数据[16,38]、地面站分布[3,26,39]以及地面终端性能实测结果[32,33]等。基于此，STARRY NET通过三重技术融合构建按需定制的ISTN实验环境：

1. 众包真实数据溯源：聚合多源异构数据流；
2. 模型驱动分析：实现轨道动力学与网络状态联合计算；
3. 超大规模系统仿真：构建与真实物理ISTN同步的数据驱动型数字孪生体。

具体而言，其设计理念可归纳为：

• 通过众包方式汇聚真实星座特征信息，计算与巨型星座时空特性一致的网络参数；
• 基于参数化驱动，利用海量网络化虚拟节点与链路，弹性仿真定制化实验环境，精准刻画真实ISTN的系统级效应与网络行为。

系统架构组成

如图1所示，STARRY NET架构包含四大核心模块：

• 星座观测器（§4.2）：采用众包技术从卫星生态系统采集星座监管信息、网络性能数据及地面站分布等，维护多维度数据库以支持、引导并驱动ISTN实验环境构建。
• 星座同步器（§4.3）：基于混合建模方法，结合采集数据与用户自定义配置，计算目标巨型星座的时空特性（包括星座规模、可见性、连通性、时变传播时延等），进而配置网络仿真参数。
• 星座协调器（§4.4）：自动化管理多物理机资源，实现实验环境资源的协同调度与分配。该模块可与真实卫星硬件等设施交互，支持承载交互式互联网流量的网络实验。
• 统一抽象层（§4.5）：提供灵活易用的API接口，供研究者创建与操控ISTN实验环境配置。

系统设计

• Constellation Observer
  • "博百家之长"，收集数据（相当于智慧化的“数据库”）
• Constellation Synchronizer
  • 计算目标的时空特性，进而配置参数
• Constellation Orchestrator
  • 资源的协同调度与分配
  • 与外部互联网流量交互
• Unified Abstraction: API
  • 研究员调用API使用StarryNet系统

4.2 Constellation Observer

The constellation observer is designed as a collector for constellation-relevant information, and it maintains three databases related to satellite, ground station and user terminal information respectively. Specifically, the observer searches and collects the latest:

(1) regulatory information (e.g., from [2,10,73]) which describes frequency and orbital coordination of mega-constellations;

(2) operating satellites information (e.g., from [16,38,71]);

(3) ground station distributions (e.g., from [3,26,39]);

(4) Internet user statistics (e.g., from [59]) which can be used to generate the distribution of terrestrial users;

and (5) network measurements from end users (e.g., from [32,33]).

The constellation observer classifies the above information, and saves them in the databases, which then can be used to drive other components and build ENEs to flexibly support various research experiments.

星座观测器旨在汇聚与卫星星座相关的多源异构信息，其核心功能体现为三个专项数据库的构建与维护：

（1）卫星数据库

• 监管信息层：集成来自国际电联（ITU）[2]、美国联邦通信委员会（FCC）[10]等机构的频率分配方案与轨道协调数据[73]
• 动态运行层：实时收录NORAD编号[71]、轨道参数（TLE数据）[38]及星间链路状态[16]等卫星运行特征

（2）地面设施数据库

• 全球站网拓扑：整合国际空间站网络[3]、澳大利亚深空测控站[26]与南极洲Troll地面站[39]等关键节点的地理分布
• 技术参数库：存储天线增益、频段支持、传输时延等地面站核心性能指标

（3）用户终端数据库

• 用户行为画像：基于全球互联网统计[59]生成用户密度热力图与业务需求模型
• 网络性能基线：融合星链时延测量[32]、静止轨道卫星吞吐量测试[33]等端到端实测数据

该模块通过自动化爬虫系统与API接口对接，实现多源数据的实时采集与结构化存储。数据库采用时空关联建模技术，支持按轨道面、覆盖区域、时间窗口等维度进行动态检索，为实验性网络环境（ENE）的拓扑仿真、流量注入与协议验证提供数据驱动型支撑。

4.3 Constellation Synchronizer

STARRY NET’s synchronizer leverages a collection of models to calculate various constellation characteristics and network behaviors, and accordingly generate a virtual network presentation synchronized to a real ISTN. At runtime, values in these models are assigned primarily based on real ISTN information collected by the constellation observer. In addition, to improve the flexibility, STARRY NET also allows researchers to manually configure model values based on his or her customized experimental requirements.

STARRY NET的同步器利用一系列模型计算不同的星座特性和网络行为，并据此生成与真实ISTN同步的虚拟网络表现。在运行时，这些模型中的值主要基于星座观察器收集的真实ISTN信息进行分配。此外，为了提高灵活性，STARRY NET还允许研究人员根据其定制的实验需求手动配置模型值。

4.3.1 Hybrid models

Constellation model. STARRY NET’s synchronizer characterizes a satellite system in both constellation-granularity and orbit-granularity descriptions. First, STARRY NET uses the Walker notation [82] to describe a constellation: N/P/p, where N is the number of satellites per plane, P is the number of planes, and p is the number of distinct phases of planes to control spacing offsets in planes. Second, the orbit-granularity description enables a fine-grain notation for orbits in a certain constellation via specifying several primary orbital elements, including: (1) inclination, which is the angle between an orbit and the Equator as satellites move; (2) altitude, which is the height above sea level and determines the orbital velocity; (3) phase offset [56], which is a factor between [0,1], describing the relative position between two satellites in adjacent orbits.

星座模型。STARRY NET的同步器在星座粒度和轨道粒度的描述上对卫星系统进行刻画。

首先，STARRY NET使用Walker符号法 [82] 来描述星座：N/P/p，其中N是每平面上的卫星数，P是平面数，p是控制平面间距偏移的平面相位数。

其次，轨道粒度的描述提供了对某一星座轨道的细粒度表示，通过指定多个主要轨道元素，包括：

（1）倾角，即卫星运动时轨道与赤道之间的夹角；

（2）高度，即海平面以上的高度，决定了轨道速度；

（3）相位偏移 [56]，其值在[0,1]之间，描述了两个卫星在相邻轨道中的相对位置。

Ground station model. STARRY NET leverages (利用) the following parameters to describe a ground station:

(1) geographic location; (2) the number of available antennas (天线) for ground communication; (3) the elevation angle, which determines the light-of-insight (LoS) of the ground station and can affect the available duration of space-ground communication.

地面站模型。STARRY NET利用以下参数描述地面站：

（1）地理位置；

（2）可用于地面通信的天线数量；

（3）仰角，决定了地面站的视距（LoS），并能影响 空间-地面 通信的可用时长。

Network model. The inter-satellite or ground-satellite network connectivity is mainly affected by following factors: (1) the visibility between two communication ends; (2) the amount of available ISLs or antennas in satellites or ground stations; and (3) the connectivity policy, which decides how to establish a connection between two communication ends. STARRY NET enables two prefabs of connectivity policies for inter-satellite connection: (1) +Grid [58], where each satellite connects to two adjacent satellites in the same orbit and to two in adjacent orbits; (2) Motif [40], which is a repetitive pattern where each satellite connects to multiple visible satellites and each satellite’s local view is the same as that of any other. For ground-satellite connectivity, STARRY NET offers multiple optional schemes that control a ground station to connect to a visible satellite, e.g., selecting the one with the shortest distance or the longest remaining visible time. Since the delay is typically determined by the network topology and speed of the light, STARRY NET calculates the propagation delay of each link based on the physical distance between two ends. As network capacity might be too speculative in practice, link capacity is set by user-specific configurations.

网络模型。星间或地面-卫星网络连接主要受以下因素的影响：

（1）两个通信端之间的可视性；

（2）卫星或地面站中可用的星间链路（ISLs）或天线数量；

（3）连接策略，决定如何在两个通信端之间建立连接。

STARRY NET为 星间连接 提供了两种预设的连接策略：

（1）+Grid [58]，每颗卫星与同轨道中的两颗邻近卫星和相邻轨道中的两颗卫星连接；

（2）Motif [40]，一种重复模式，每颗卫星与多个可视卫星连接，每颗卫星的局部视图与任何其他卫星相同。

对于 地面-卫星连接，STARRY NET提供多种可选方案，控制地面站与可见卫星连接，例如选择距离最短的卫星或剩余可视时间最长的卫星。

由于延迟通常由网络拓扑结构和光速决定，STARRY NET根据两个端点之间的物理距离计算每个链路的传播延迟。由于实际中链路容量可能存在较大的不确定性，链路容量由用户根据具体需求进行配置。

Computation model. The computation capability of satellites varies greatly in different real-world deployments. Generally, conventional space-grade processors have limited capability [53,65] as compared with that used in terrestrial computer systems. For example, the operating frequency of space-borne processors (空间处理器) (e.g., BAE-RAD series [21,22]) ranges from 110 to 466MHz per core. Recently, satellite operators and researchers start to use commercial off-the-shelf (COTS) processors in space stations [14] or in LEO small satellites [23,44] to reduce the manufacturing cost. To support various experimental requirements, STARRY NET allows researchers to manually configure the CPU capability of each satellite node through approximating the frequency and number of available cores of each emulated node, by scaling download CPU frequency and enforcing a maximum time quota for each node.

计算模型。不同实际部署中的卫星计算能力差异较大。

通常，传统的空间级处理器与地面计算机系统使用的处理器相比，能力有限 [53,65]。例如，空间处理器（如BAE-RAD系列处理器 [21,22]）的操作频率范围为每个核心110MHz至466MHz。

近年来，卫星运营商和研究人员开始在空间站 [14] 或低地轨道（LEO）小卫星 [23,44] 中使用商用现货（COTS）处理器，以降低制造成本。

为了支持不同的实验需求，STARRY NET允许研究人员通过调整每个模拟节点的频率和可用核心数来手动配置每颗卫星节点的CPU能力，具体方法是通过缩放下载CPU频率并为每个节点强制设置最大时间配额。

4.3.2 Constellation consistency

Spatial consistency. Based on constellation-wide information, STARRY NET first determines the amount of required containers. Each container runs realistic system environments and networking stack to emulate a satellite in the constellation, a ground station or a terrestrial user terminal. Second, using orbit-granularity information, STARRY NET calculates the latitude, longitude and height (i.e., LLH information) of each satellite at any given time slot. Finally, exploiting the above LLH information and minimum elevation angles, S TAR RY N ET calculates the visibility between arbitrary two satellites, or between satellites and ground facilities.

Temporal consistency. Since emerging LEO satellites are inherently moving at a high velocity, the locations, intervisibility, and network conditions (e.g., connectivity and propagation delay between two nodes) of an ISTN are changing over time. To achieve realism, these states should be temporally consistent to real scenarios. STARRY NET splits time into slots, calculates LLH information in each slot, and follows the hybrid models to determine time-varying network conditions in different slots. Such dynamic states will further be used for driving the dynamic emulation operated by the orchestrator.

空间一致性。基于全星座信息，STARRY NET首先确定所需容器的数量。每个容器运行真实的系统环境和网络栈，用以模拟星座中的卫星、地面站或地面用户终端。其次，使用轨道粒度信息，STARRY NET计算每颗卫星在任何给定时间段的纬度、经度和高度（即LLH信息）。最后，利用上述LLH信息和最小仰角，STARRY NET计算任意两颗卫星之间或卫星与地面设施之间的可视性。

时间一致性。由于新兴的低地轨道卫星本身以高速度运动，ISTN的卫星位置、可视性和网络条件（例如两节点之间的连接性和传播延迟）随时间变化。为了实现真实感，这些状态应与真实场景在时间上保持一致。STARRY NET将时间划分为多个时隙，计算每个时隙中的LLH信息，并按照混合模型确定不同时隙中的时变网络条件。这些动态状态将进一步用于驱动由编排器操作的动态仿真。

TL;DR

4.3这一部分直接对着看太累了，我这里来个总结版 🚀

星座模型

采用双粒度描述机制：

1. 星座级：使用Walker星座构型描述法（N/P/p格式），其中N为单轨道面卫星数，P为轨道面总数，p为轨道面相位偏移因子；
2. 轨道级：通过轨道根数精细刻画卫星运行特征，包括：（1）轨道倾角；（2）运行高度；（3）相邻轨道面相位偏移系数（取值范围[0,1]）。

地面站模型

通过三要素(LLH)表征地面站特征：（1）地理位置坐标；（2）可用通信天线数量；（3）最低通信仰角（决定空间-地面链路的可视时间窗口）。

网络模型

定义星间/星地连接的动态规则：

影响因子	建模方法
可视性	基于LLH坐标与仰角约束实时计算
链路资源	配置卫星ISL接口与地面站天线容量
连接策略	提供+Grid（固定四邻连接， starlink里的1234）与Motif（可见性驱动）两种星间组网模式

计算模型

支持差异化计算能力配置：

• 传统星载处理器（如BAE-RAD系列）建模：核频110-466MHz范围可调
• 商业货架产品（COTS）模拟：通过CPU频率缩放与时间配额限制实现多核仿真

星座一致性保障机制

空间一致性，通过三阶段实现：

1. 容器资源规划：基于星座规模确定虚拟节点数量；
2. 星位解算：依据轨道根数实时计算各卫星的经纬度与高度（LLH信息）；
3. 可视性分析：结合LLH与仰角约束生成动态连接矩阵。

时间一致性，采用时间分片机制：

• 将实验周期划分为离散时隙（典型粒度1秒）
• 每个时隙内更新所有节点的空间状态与网络条件（连通性、传播时延等）
• 动态状态参数驱动协调器进行实时仿真环境重构

该机制确保实验环境与真实ISTN保持时间维度的高度同步，支持秒级精度的时变网络行为仿真。

4.4 Constellation Orchestrator

The orchestrator is designed for four goals. First, the orchestrator exploits container-based emulation to construct an emulated ISTN environment upon one or many physical machines (depending on the constellation size). Second, the orchestrator configures the computation and network capability of each emulated node, according to users’ configurations and the spatial and temporal results calculated by the constellation synchronizer. For example, a space-ground connectivity should be dynamically updated based on the time-varying visibility between its two ends. Third, the orchestrator can connect the emulated ISTN to real-world network facilities (if any, e.g., real satellite prototypes or terminals) and support interactive Internet traffic. Finally, at runtime the orchestrator leverages a measurement agent to monitor and report the runtime resource usage (e.g., CPU/memory/bandwidth usage) to the user as a feedback of the experiment for further analysis.

星座协调器承担四大核心功能，通过容器化仿真技术构建ISTN实验环境：

（1）异构资源整合

• 基于物理机集群动态分配容器资源，支持单机至超大规模星座仿真（规模自适应）
• 采用轻量化容器（如Docker实例）模拟卫星节点，每个容器部署全栈网络协议

（2）动态参数配置

根据同步器输出的时空状态参数实时调整节点属性：

• 计算能力：通过CPU Cgroup限制容器算力配额
• 网络特性：基于TC工具动态设置链路带宽与时延
• 拓扑更新：依据星间可视性变化触发虚拟链路重构

（3）虚实系统互联

• 提供网关接口实现仿真环境与真实设施（卫星原型机、地面终端）的协议级交互
• 支持注入真实互联网流量，承载端到端业务流验证（如视频传输、TCP拥塞控制）

（4）实验监测反馈

• 部署分布式测量代理（Measurement Agent），实时采集：
  • 节点级资源消耗（CPU/内存/磁盘IO）
  • 网络级性能指标（吞吐量、丢包率、时延抖动）
• 生成多维实验报告，支持研究者进行迭代优化

该模块通过声明式API接收实验配置，采用事件驱动架构实现秒级动态响应，确保超大规模仿真环境的时间同步精度控制在毫秒级别。

4.4.1 Multi-machine support for constellation emulation

Since each emulated satellite consumes computation, network and storage resources in practice, it is challenging to support the emulation of large-scale constellations on a single machine, especially when additional user-defined payloads (e.g., a new satellite routing protocol) need to be loaded for experimentation. STARRY NET addresses this limitation by integrating resources on multiple machines to support largescale, time-varying constellation emulations. When deployed on multiple machines, STARRY NET’s orchestrator divides these machines into two parts. First, one machine, selected as the resource manager, manages, schedules and allocates resources upon all machines to jointly create and maintain the ENE. Second, other machines, working as worker clusters, receive and follow commands from the resource manager. For each node in the ISTN (e.g., a satellite or ground station), the orchestrator creates a container to emulate it, and creates a virtual bridge connecting two nodes to emulate a link.

Topology creation on multiple machines. One big challenge made by extending an emulated mega-constellation to multiple machines is to ensure that the emulated constellation is topologically consistent to the real constellation. Figure 2 shows an example of emulating an LEO satellite constellation including two adjacent orbits on two physical machines. Specifically, Figure 2a plots two Starlink inclined orbits, each of them having 22 satellites evenly spaced with available ISLs. Assume that we use two machines for this emulation, and each machine creates 22 containers to emulate 22 satellites. In a real constellation, each satellite connects its two neighbors in the same orbit, and to another satellite in the adjacent orbit. Ideally, an emulated topology for the constellation in Figure 2a can be easily created if each machine has more than 22 physical network interfaces. However, in practice the number of available interfaces of a machine is likely to be limited. As shown in Figure 2b, if we directly bridge the emulated network interface of each satellite to the physical interface, due to the lack of traffic isolation, emulated satellites in two machines will establish an “all-to-all” topology which is inconsistent to the grid-like topology in Figure 2a .

STARRY NET addresses this inconsistency on multiple machines by creating multiple VLANs to emulate independent ISLs, interconnect satellites in two machines and isolate intersatellite traffic as that in a real constellation. As plotted in Figure 2c, we build a VLAN for each ISL crossing different machines (e.g., vlink A1-B1 interconnects emulated satellite A1 and B1), and thus STARRY NET obtains the correct virtual network topology consistent to the real constellation topology as illustrated in Figure 2a upon multiple machines.

Topology update on multiple machines. Due to the high dynamics of ISTN, the network topology fluctuates over time. If a connectivity change occurs on a single machine, i.e., all affected nodes are located on the same machine, STARRY NET deletes the old virtual link, and creates a new link connecting corresponding nodes. Otherwise, if a connectivity change involves nodes on multiple machines, STARRY NET exploits a VLAN-based approach to limit the link update operation to a single machine. Figure 3 plots an example of the emulation of space-ground handovers upon multiple machines. Assume there are three satellites, two ground stations in two sequential time slots. In the first slot, satellite S2/S3 connects to ground station GS1/GS2 respectively. As satellites move, the space-ground connectivity changes, and S1/S2 connects to GS1/GS2 respectively in the second slot. STARRY NET emulates the ground-satellite links (GSLs) by two VLANbased virtual links, and performs the correct handover by properly adjusting the connectivity change between S1/S2/S3 and vlink-GS1/GS2, in different slots on machine A.

鉴于单颗仿真卫星需消耗计算、网络与存储资源，单机环境下难以支撑超大规模星座仿真（尤其需加载用户自定义协议栈时）。STARRY NET通过多机资源协同机制突破此限制，具体实现架构如下：

资源协同架构

• 资源管理器：选定单机作为控制中枢，负责跨机资源调度与实验环境全生命周期管理
• 工作集群：多台物理机组成执行单元，按资源管理器指令完成虚拟节点部署与链路配置
• 节点-容器映射：每个卫星/地面站节点对应独立容器实例，通过虚拟网桥实现星间链路（ISL）仿真

拓扑构建机制

图2案例展示了双机协同仿真含44颗卫星的星链星座时面临的挑战与解决方案：

1. 理想拓扑需求（图2a）：每颗卫星需与同轨相邻节点及邻轨指定节点建立四向连接
2. 物理接口限制（图2b）：直接桥接物理接口将导致产生全连接，从而拓扑失真
3. VLAN隔离方案（图2c）：
   • 为跨机ISL创建独立VLAN通道（如vlink A1-B1）
   • 通过VLAN标签实现流量隔离与拓扑精确还原
   • 构建与真实星座一致的网格化虚拟拓扑

explanation for fig-2

问题1：为什么直接桥接物理接口会导致全连接拓扑失真？

在图2(b)中，假设我们直接将每台机器上的仿真卫星容器（如S-A1、S-B1）通过物理接口（plink-A/B）连接起来，而不做任何隔离或限制。这样会发生以下问题：

1. 物理接口的广播特性：

   • 物理网络接口本质上是共享的，所有通过同一个接口发送的数据包都会被其他连接到该接口的节点接收
   • 注意看上面的fig-2，它的物理链路接口本质上是 machine-level 的
   • 例如，Machine A 上的 S-A1 发送数据时，Machine B 上的所有仿真卫星（如 S-B1、S-B2、S-B3）都能收到这个数据包

2. 结果：形成“全连接”拓扑：

   • 在真实的星座网络中，每颗卫星只与固定的邻居建立连接（如图2(a)所示，网格化拓扑）
   • 然而，在这种直接桥接的情况下，每颗卫星会与另一台机器上的所有卫星建立连接，导致“全连接”现象
   • 这种“全连接”完全偏离了真实星座的网格化结构，无法准确模拟真实网络行为

问题2：为什么要采用VLAN隔离方案？这样做的好处是什么？

为了避免上述问题，STARRY NET 使用了 VLAN（虚拟局域网）隔离方案，如图2(c)所示。以下是具体原因和好处：

• VLAN 是一种通过逻辑分组隔离网络流量的技术。每个 VLAN 都有唯一的标识符（VLAN ID），只有属于同一 VLAN 的设备才能互相通信。
• STARRY NET 为每一条跨机器的星间链路（ISL）分配一个独立的 VLAN。例如：
  • vlink A1-B1 对应 VLAN 100
  • vlink A2-B2 对应 VLAN 101
  • vlink A3-B3 对应 VLAN 102

拓扑动态更新

针对ISTN高动态特性，设计分级更新策略：

更新类型	处理机制
单机内链路变更	本地删除旧链路并创建新连接
跨机链路变更	采用VLAN锚定技术，将更新操作限制在单机完成

以图3星地切换场景为例：

• 时隙1：卫星 S2/S3 分别连接地面站 GS1/GS2
• 时隙2：卫星 S1/S2 接管 GS1/GS2 连接
• 实现方式：
  1. 基于VLAN建立GS1/GS2虚拟链路
  2. 通过 VLAN端口重映射完成跨机切换 操作
  3. 确保拓扑更新 仅需在机器A完成配置同步

该机制通过VLAN虚拟化技术，在保证拓扑时空一致性的同时，将大规模星座仿真扩展性提升至千节点量级，支持研究者开展协议栈深度验证与系统级性能评估。

4.4.2 Efficient time synchronization and state update

Another challenge made by multi-machine extension is the time synchronization and link update overhead. Specifically, to achieve temporal consistency, STARRY NET’s constellation synchronizer assigns a sequence of update events to the orchestrator to inform each emulated satellite when an update (e.g., a location/connectivity change) should happen. To trigger such events, a baseline approach is to let the centralized manager send commands to all emulated satellites in every slot, and trigger corresponding update events. However, such a real-time approach has limited scalability as the amount of emulated satellites increases, since each event requires to update the state of a certain virtual interface/container, and continuously and simultaneously performing a large number of updates can overload the manager, result in delayed update, and invalidate the temporal consistency of the emulation.

To reduce the state update overhead caused by mimicking temporal dynamics in mega-constellations, STARRY NET leverages a prediction-based multi-thread event memorization approach. We define the synodic period as the amount of time that it takes for the constellation to reappear at the same projection upon the earth surface. In the emulated environment, at the beginning of each synodic period, the orchestrator pre-generates an event list for each satellite that includes all its update events during the current synodic period. At runtime, each emulated satellite adopts an independent event update thread to read the local event list in each slot, and triggers the corresponding event scheduled in the current slot. Time clocks upon all machines are synchronized by the NTP [17].

在多机环境中，为了实现时间一致性，STARRY NET的星座同步器需要向协调器分配一系列更新事件，用于通知每颗仿真卫星何时需要进行状态更新（例如位置或连通性变化）。

基线方法的局限性

一种直接的方法是由集中式管理器在 每个时间隙 向所有仿真卫星发送命令，触发对应的更新事件。然而，这种实时方法随着仿真卫星数量的增加面临以下问题：

1. 可扩展性受限：每个事件都需要更新特定虚拟接口或容器的状态，随着事件数量的增加，集中式管理器可能因过载而出现延迟。
2. 时间一致性失效：如果更新延迟，可能导致仿真环境无法准确反映真实星座的动态行为。

解决方案：基于预测的多线程事件记忆化方法

为了减少模拟超大规模星座时因时间动态变化引起的状态更新开销，STARRY NET采用了一种基于预测的多线程事件记忆化方法。具体实现如下：

1. 定义会合周期（Synodic Period）
   • 会合周期 指的是 星座在地球表面投影重新回到相同位置所需的时间。
   • 在仿真环境中，会合周期为一个循环周期，用于预生成所有更新事件。
2. 预生成事件列表
   • 在每个会合周期开始时，协调器为每颗仿真卫星预先生成一个事件列表，包含当前会合周期内所有需要触发的更新事件。
   • 这些事件包括位置变化、连通性变化等。
3. 独立线程处理本地事件
   • 每颗仿真卫星运行一个独立的 “事件更新线程”，在每个时间隙读取本地事件列表，并触发当前时间隙中计划的对应事件。
   • 这种分布式处理方式减少了集中式管理器的负担。
4. 时间同步机制
   • 所有物理机通过网络时间协议（NTP）进行时钟同步，确保各机器间的时间一致性。

Note

方法优势: 基于预测 + 多线程

• 高效性：通过提前生成事件列表并分布式处理，大幅降低了实时计算与通信开销。
• 可扩展性：支持超大规模星座仿真，因为每颗卫星独立处理自身事件，不受其他节点影响。
• 时间一致性保障：通过NTP同步和本地线程执行，确保仿真环境与真实场景在时间维度上的高度一致。

4.5 Open APIs for ISTN Experiments

Environment APIs. STARRY NET provides the environment APIs for a researcher to load trace from the database, and create/control/run an ENE upon one or multiple machines with user-defined ISTN configurations. Once constellation and GS information are completely loaded, these configurations are delivered to the synchronizer to calculate spatial and temporal characteristics, which are further used by the orchestrator to construct the ENE. The environment APIs also allow users to configure the interval of discrete time slot to adjust the dynamicity. Note that the ENE not only maintains the runtime of emulated constellations, but also needs to run the test workload deployed by the researcher. We design a resource threshold ∆ to control the percentage of CPU/memory used by the framework. In other words, at least (100%-∆) of the total CPU/memory should be left for the researcher’s test cases.

环境API设计

STARRY NET通过环境API为研究者提供实验性网络环境（ENE）的全生命周期管理能力，具体涵盖：

• 数据加载：支持从数据库加载星座监管信息、地面站分布等真实轨迹数据
• 环境构建：基于用户自定义配置，在单机/多机集群上动态创建并控制ISTN仿真环境
• 动态调控：允许设置离散时隙间隔参数，调节仿真环境的时间粒度与动态性强度

核心机制

1. 配置传递流程
   • 用户通过API提交星座规模、连接策略等配置参数
   • 同步器接收配置，计算时空特性（如卫星轨道参数、星间可见性矩阵）
   • 协调器依据计算结果构建虚拟节点与动态链路
2. 资源阈值控制
   • 定义资源阈值 Δ（如Δ=20%），确保框架自身 CPU或内存占用 ≤ Δ
   • 剩余 ≥ (100%-Δ) 资源预留给用户测试用例（如路由算法、流量工程）

Self-node APIs. STARRY NET’s self-node APIs are designed to be called by the researcher’s programs on each emulated satellite. These APIs expose underlying satellite-related information to user programs. Specifically, in each emulated satellite, user program can obtain the index of current satellite/orbit, sunlight state, time-varying geo-location information, current satellite velocity and the index of adjacent reachable satellites, etc. Such satellite-specific information can be used for developing new on-board capabilities in ISTNs.

自节点API设计

自节点API为仿真卫星节点上的用户程序提供底层状态感知能力，包括：

• 拓扑信息：当前卫星/轨道索引、可达邻星索引
• 时空状态：实时地理位置、运行速度、光照状态
• 环境参数：离散时隙间隔、链路传播时延

该API体系通过资源隔离与状态透传，实现仿真环境的高保真度与用户测试的灵活性兼得。