OpenSN: An Open Source Library for Emulating LEO Satellite Networks

TPDS'25 version. Extension of APNet'24 OpenSN

与APNet24版本的具体扩展差异

(1) 技术层面的核心新增：eBPF Links

这是TPDS版本最大的技术贡献增量。APNet版本完全没有eBPF相关内容。

基本思路： 用XDP（eXpress Data Path）上的eBPF程序替代传统的Linux Bridge虚拟设备来实现帧转发，分为机内和跨机两种场景。

机内eBPF链路：

• 传统方式：每条点对点链路需要创建Linux Bridge设备，涉及sub-device mount，Bridge内部还有广播、端口重定向等冗余功能
• eBPF方式：用内核空间的eBPF程序+eBPF map实现帧重定向，跳过Bridge设备创建
• 切换（handover）效率提升显著：传统方式需要删除并重建虚拟设备（会改变容器内的网络接口），eBPF方式只需修改redirect map，容器接口保持不变

跨机eBPF链路：

• 传统VXLAN方式：Ethernet帧→UDP封装→发送→目标机器解封→转发到目标容器
• eBPF方式：无需帧-数据报转换，直接修改目标MAC地址进行转发。论文给出了Algorithm 2（Point-to-Point Link eBPF Forwarder），利用卫星网络点对点链路的特性（源MAC唯一对应目标MAC）
• eBPF跨机链路的额外好处：不依赖Linux内核的网络层协议（UDP/IP），因此研究者可以基于OpenSN开发和评估全新的网络层架构和协议

(2) 任务调度优化的细化

APNet版本只简单说了Container Runtime Manager用协程池并行、Virtual Link Manager用协程快速响应。TPDS版本新增了：

• Fig. 2 任务调度对比图：明确对比了三种调度模式——Serial（Mininet，CPU利用不充分）、Burst Parallel（StarryNet，频繁进程切换导致阻塞）、Parallel with limitation on queue size（OpenSN，限制同时执行任务数，避免过度切换）
• Node与Link创建的交互优化：APNet只说了分别优化node和link。TPDS新增了"Interaction between Node & Link Creation"部分——Virtual Link Manager有一个waiting pool，记录所有收到的link创建任务；当一个container创建完成后，Container Runtime Manager会signal waiting pool，然后立即开始创建该容器相关的link。这比StarryNet和Mininet等待所有容器创建完才开始创建link更高效

(3) Key-Value Database的详细说明

APNet版本只概述了KV数据库的角色。TPDS版本新增了Table III，详细列出了数据库中记录的信息类型：

• Machine：最大容器数、机器地址等required配置
• Node：卫星/GS的几何参数等required配置，以及TU发送请求时间戳等user-defined配置
• Link：连接关系、延迟等
• Application：容器镜像、环境变量等

区分了required configurations（仿真必需）和user-defined configurations（可选定制）。

(4) OpenSN Usage 全新章节

APNet版本完全没有使用说明。TPDS新增了完整的使用教程：

• 系统要求：最低1 vCPU + 2GB内存可跑Iridium + OSPF；支持Linux内核5.4到6.8
• 容器镜像配置：区分静态节点（Router、CP，可完全预配置）和动态节点（卫星、TU，需运行时动态配置）；给出了Dockerfile示例和JSON配置文件示例（Fig. 9）
• 拓扑配置：展示了Python SDK的User-Defined Configurator用法（Fig. 10）
• 网络仿真启动：三步流程
  • 启动依赖（etcd、InfluxDB、CodeServer）
  • 更新内核设置（ARP缓存阈值、bridge转发）
  • 启动Container Network Manager。区分leader和follower机器
• 功能扩展示例：
  • 更换路由协议/软件：默认用FRRouting，支持换协议、开发新协议、换其他路由软件
  • IPv4切换到IPv6：只需改地址生成规则和路由协议（OSPFv2 → OSPFv3）

Introduction

A. Background & Motivation

In recent years, we have witnessed the rapid development of low-earth-orbit (LEO) constellations. Different from the geostationary satellites orbiting at the altitude of 35768 km, the orbital altitude of LEO satellites is around 300-2000 km. The lower orbital altitude leads to a smaller latency for the ground-satellite links (GSLs), but also reduces the coverage area of a single satellite. Consequently, it is indispensable to deploy hundreds or thousands of LEO satellites to achieve global coverage. Many commercial enterprises have launched their mega-constellation plans. For example, Starlink Shell-I consists of a total of 1584 satellites on 72 orbital planes. At the early stages, LEO satellites are only used as repeaters between two ground stations (GSes), which is also known as the bent-pipe architecture. Recently, many LEO constellations have beenequippedwith(oraredeploying)inter-satellitelinks(ISLs). For example, Iridium Next has been using ISLs in L-band [2]. Starlink launched satellites equipped with laser-based ISLs way back in 2021 [3]. The adoption of ISLs creates the satellite network (SN) in space.

Although SN provides opportunities for extending Internet services to where the terrestrial networks cannot reach, it also leads to new challenges in satellite networking. Due to the mobile nature and the time-varying communication links, the topology characteristics of LEO satellite networks are quite different from those of the terrestrial Internet. There have been increasing studies on LEO satellite networking, focusing on the low-latency advantages (e.g., [4], [5], [6], [7]), the constellation topology (e.g., [8], [9], [10]), the shortest-path problem (e.g., [11]), the intra-domain routing (e.g., host-centric [12], [13], [14], contentcentric [15], [16], [17], and link-identified [18], [19], [20]), the inter-domain routing (e.g., BGP-S [21], PCR [22], DB-R [23]), and the security authentication (e.g., [24]).

Despite the wide investigation, how to evaluate these new architectures, protocols, and algorithms in a systematic and reproducible manner has been an open problem. Different from terrestrial Internet, it is costly to carry out experiments in a real-world SN. Even for those commercial giants like SpaceX and Amazon, it also takes a few years to deploy their LEO constellations. Therefore, most existing studies on SN still rely on network simulation or network emulation to evaluate the performance of their proposals. There are significant differences between emulating LEO satellite networks and terrestrial networks. First of all, LEO constellations often consist of hundreds or thousands of satellites. It is necessary to construct a large-scale topology for simulation/emulation. Second, unlike terrestrial networks with fixed nodes, LEO satellites are in constant motion, leading to dynamic changes in visibility, connectivity, and propagation delays. This also increases the overhead of simulation/emulation. In general, the simulation/emulation platforms for SN could be classified into three categories:

1) Orbit Analysis: The initial step of simulating SN is to obtain the trajectory data of LEO satellites. STK [25] is an orbit analysis tool, but it does not support network protocol simulation. Hence STK is often used as the orbit analyzer in this research area.

2) Discrete-Event Simulation: The discrete-event simulators of SN construct the constellation topology based on the trajectory data obtained from STK, and then simulate the networking events at different levels. Specifically, the flow-level SN simulators (e.g., StarPerf [26]) cannot capture the fine-grained packet forwarding behaviors, thus are not able to simulate networking protocols. Packet-level SN simulators (e.g., [27], [28], [29]) usually rely on a third-party discrete-event simulation platform (e.g., ns3 [30] and OMNeT++ [31]). Typical networking protocols could be simulated based on packet-level SN simulators.

3) Virtual-Network Emulation: The virtual-network emulators of SN run real protocol stack in Linux kernel and support unmodified applications on host OS. Existing virtual-network SN emulators either rely on Mininet [32] or Docker container [33]. For example, LeoEM [34] is developed upon Mininet. StarryNet [35] and the emulator in [36] adopt the container-based virtualization.

Among these solutions, virtual-network emulation provides the most realistic and meaningful results. However, existing virtual-network SN emulators have some shortcomings. For example, existing virtual-network SN emulators are not efficient enough to emulate frequent state changes (e.g., ISL failure/recovery and GSL handover), which slows down the experimental progress and prolongs the research period. Moreover, existing virtual-network SN emulators often have scalability issues, making it difficult to emulate large-scale LEO constellations (e.g., Starlink). Furthermore, most SN emulators are not fully open source, thus cannot provide a systematic evaluation platform that contributes to reproducibility. In this paper, we would like to present OpenSN, i.e., an open source library for emulating large-scale satellite networks. OpenSN is a virtual-network SN emulator that exhibits advantages in emulation efficiency, system stability, and function extensibility. We believe that OpenSN could empower the research on LEO satellite networking in the future. OpenSN has been available at https://opensn-library.github.io.

近年来, 我们见证了低地球轨道(LEO)星座的快速发展.与运行在35768公里高度的地球静止轨道卫星不同, LEO卫星的轨道高度约为300-2000公里.较低的轨道高度降低了星地链路(GSL)的延迟, 但也减小了单颗卫星的覆盖区域.因此, 必须部署成百上千颗LEO卫星以实现全球覆盖.许多商业企业已经启动了其巨型星座计划, 例如, Starlink Shell-I由分布在72个轨道面上的总共1584颗卫星组成.在早期阶段, LEO卫星仅作为两个地面站(GS)之间的中继器, 这也被称为"弯管"(bent-pipe)架构.近来, 许多LEO星座已经配备(或正在部署)星间链路(ISL).例如, Iridium Next一直在使用L波段的ISL.Starlink早在2021年就发射了配备激光ISL的卫星.ISL的采用在太空中构建了卫星网络(SN).

尽管SN为将互联网服务扩展到地面网络无法覆盖的区域提供了机会, 但也给卫星组网带来了新的挑战.由于移动特性和时变通信链路, LEO卫星网络的拓扑特征与地面互联网截然不同.关于LEO卫星组网的研究日益增多, 主要集中在低延迟优势(如 [4], [5], [6], [7]), 星座拓扑(如 [8], [9], [10]), 最短路径问题(如 [11]), 域内路由(如以主机为中心 [12], [13], [14], 以内容为中心 [15], [16], [17] 和链路标识 [18], [19], [20]), 域间路由(如 BGP-S [21], PCR [22], DB-R [23])以及安全认证(如 [24])等方面.

尽管已有广泛的研究, 但如何以系统且可复现的方式评估这些新架构, 协议和算法仍是一个悬而未决的问题.与地面互联网不同, 在真实世界的SN中进行实验成本高昂.即使对于SpaceX和Amazon这样的商业巨头, 部署其LEO星座也需要数年时间.因此, 大多数现有的SN研究仍然依赖网络模拟或网络仿真来评估其方案的性能.仿真LEO卫星网络与仿真地面网络之间存在显著差异.首先, LEO星座通常由成百上千颗卫星组成, 因此有必要构建大规模拓扑用于模拟/仿真.其次, 与拥有固定节点的地面网络不同, LEO卫星处于持续运动中, 导致可见性, 连接性和传播延迟发生动态变化.这也增加了模拟/仿真的开销.总体而言, SN的模拟/仿真平台可归为三类:

1) 轨道分析(Orbit Analysis): 模拟SN的第一步是获取LEO卫星的轨迹数据.STK [25] 是一个轨道分析工具, 但它不支持网络协议模拟.因此, STK在该研究领域通常被用作轨道分析器.

2) 离散事件模拟(Discrete-Event Simulation): SN的离散事件模拟器基于从STK获取的轨迹数据构建星座拓扑, 然后模拟不同层级的网络事件.具体而言, 流级SN模拟器(如StarPerf [26])无法捕捉细粒度的数据包转发行为, 因此无法模拟网络协议.包级SN模拟器(如 [27], [28], [29])通常依赖于第三方离散事件模拟平台(如 ns3 [30] 和 OMNET++ [31]).基于包级SN模拟器可以模拟典型的网络协议.

3) 虚拟网络仿真(Virtual-Network Emulation): SN的虚拟网络仿真器在Linux内核中运行真实的协议栈, 并支持宿主操作系统上未修改的应用程序.现有的虚拟网络SN仿真器主要依赖Mininet [32]或Docker容器 [33].例如, LeoEM [34] 是基于Mininet开发的.StarryNet [35] 和 [36] 中的仿真器采用了基于容器的虚拟化技术.

在这些解决方案中, 虚拟网络仿真提供了最真实和最有意义的结果.然而, 现有的虚拟网络SN仿真器存在一些缺陷.例如, 现有的虚拟网络SN仿真器在仿真频繁的状态变化(如ISL故障/恢复和GSL切换)方面效率不够高, 这减缓了实验进度并延长了研究周期.

此外, 现有的虚拟网络SN仿真器通常存在可扩展性问题, 使得仿真大规模LEO星座(如Starlink)变得困难.更有甚者, 大多数SN仿真器并非完全开源, 因此无法提供有助于复现性的系统化评估平台.

在本文中, 我们将介绍OpenSN, 即一个用于仿真大规模卫星网络的开源库.OpenSN是一个虚拟网络SN仿真器, 在仿真效率, 系统稳定性和功能扩展性方面表现出优势.我们相信OpenSN能够为未来的LEO卫星组网研究提供支持.OpenSN已在 https://opensn-library.github.io 上发布.

Note

积累一下这里 Discrete-Event Simulation 和 Virtual-Network Emulation 的写作语言, 以及依次对应的实例

B. Main Results and Key Contributions

This paper presents OpenSN, i.e., an open source library for emulating LEO satellite networks. Specifically, OpenSN is a virtual-network emulator, that runs real kernel and real applications. Compared to other SN emulators (e.g., LeoEM [34] and StarryNet [35]), OpenSN achieves better emulation efficiency, system scalability, and function extensibility. Next we introduce the key contributions and leave the detailed comparison (with previous works) in Table II.

• Container-based Emulation: OpenSN adopts container-based virtualization for emulating SN with two considerations. First, the container-based emulation achieves good horizontal scalability via flexible multi-machine extension. Second, the container-based emulation allows for running distributed software (e.g., routing software and observation applications) in large-scale constellations without manual configuration. The two aspects above enable OpenSN to outperform LeoEM (adopting lightweight virtualization via Mininet) in terms of horizontal scalability and function extensibility, respectively.

• Separation Architecture: OpenSN mainly consists of User-Defined Configurator, Container Network Manager, and Key-Value Database. The Key-Value Database records the necessary information for SN emulation, and acts as a data forwarder between User-Defined Configurator and ContainerNetworkManager.Comparedtoothercontainerbased SN emulators (e.g., StarryNet), such a separation architecture enhances the function extensibility of OpenSN. For example, OpenSN allows users to flexibly change the emulation parameters and customize the emulation rules (e.g., GSL handover policy and ISL failure model) without complicated configuration.

• Efficiency Improvement: By investigating and comparing existing container-based SN emulators, we find that the emulation efficiency of the container network is mainly limited by the interaction with the Docker command line interface (CLI). To this end, OpenSN streamlines the interaction process with Docker. First, OpenSN’s Container Runtime Manager replaces the CLI interaction with the official SDK, and also adopts a distributed architecture to achieve better parallelism. Second, OpenSN’s Virtual Link Manager skips Docker Network Manager, and directly controls Linux virtual devices, which can significantly reduce the overhead of unnecessary operations. This way, OpenSN (installed distributed routing software) is still capable of achieving almost the same emulation efficiency as the specialized network emulator Mininet (without routing software).

The remainder of this paper is organized as follows. We review related works on SN simulation/emulation in Section II. We present the OpenSN architecture in Section III. We introduce the usage of OpenSN in Section IV. We evaluate the performance of OpenSN in Section V. Finally, we conclude this paper in Section VI.

本文提出了OpenSN, 即一个用于仿真LEO卫星网络的开源库.具体而言, OpenSN是一个虚拟网络仿真器, 运行真实的内核和真实的应用程序.与其他SN仿真器(如LeoEM [34]和StarryNet [35])相比, OpenSN实现了更好的仿真效率, 系统可扩展性和功能扩展性.接下来我们介绍主要贡献, 并将详细的对比(与先前工作)留待表II中展示.

• 基于容器的仿真: 出于两方面的考虑, OpenSN采用基于容器的虚拟化来仿真SN

  • 首先, 基于容器的仿真通过灵活的多机扩展实现了良好的水平可扩展性
  • 其次, 基于容器的仿真允许在大规模星座中运行分布式软件(如路由软件和观测应用程序), 而无需手动配置
  • 上述两个方面使得OpenSN分别在水平可扩展性和功能扩展性方面优于LeoEM(采用Mininet的轻量级虚拟化)

• 分离式架构: OpenSN主要由用户定义配置器, 容器网络管理器和 K-V DB 组成

  • 键值数据库记录了SN仿真所需的信息, 并充当用户定义配置器与容器网络管理器之间的数据转发器
  • 与其他基于容器的SN仿真器(如StarryNet)相比, 这种分离式架构增强了OpenSN的功能扩展性
  • 例如, OpenSN允许用户灵活地更改仿真参数并自定义仿真规则(如GSL切换策略和ISL故障模型), 而无需复杂的配置

• 效率提升: 通过调查和比较现有的基于容器的SN仿真器, 我们发现容器网络的仿真效率主要受限于与Docker命令行接口(CLI)的交互.为此, OpenSN简化了与Docker的交互过程

  • 首先, OpenSN的容器运行时管理器(Container Runtime Manager)使用官方SDK替代了CLI交互, 并采用了分布式架构以实现更好的并行性
  • 其次, OpenSN的虚拟链路管理器(Virtual Link Manager)跳过了Docker网络管理器, 直接控制Linux虚拟设备, 这可以显著减少不必要操作的开销
  • 通过这种方式, OpenSN(安装了分布式路由软件)仍然能够实现与专用网络仿真器Mininet(无路由软件)几乎相同的仿真效率

本文的其余部分组织如下.我们在第二部分回顾了关于SN模拟/仿真的相关工作, 在第三部分介绍了OpenSN的架构, 在第四部分介绍了OpenSN的使用方法.我们在第五部分评估了OpenSN的性能.最后, 我们在第六部分总结了全文.

Literature Review

The existing platforms for evaluating satellite networking protocols could be classified into two categories. We will compare their advantages and disadvantages in the following. Table I provides a guideline.

A. Discrete-Event Simulation for SN

The discrete-event simulation for SN captures the networking events at different levels:

Flow-level: The flow-level SN simulators could calculate some performance metrics (e.g., end-to-end propagation delay) given the constellation topology. However, they are not able to capture the fine-grained behaviors of packets under different networking protocols. Lai et al. in [26] present StarPerf, i.e., a flow-level SN simulator based on Python. It allows for trajectory simulation, topology generation, and shortest-path calculation. They leverage StarPerf to gain insights on optimizing the constellation architecture.

Packet-Level: Existing packet-level SN simulators rely on the third-party discrete-event simulation platforms, e.g., ns3 [30] and OMNeT++ [31]. Kassing et al. in [27] propose Hypatia, i.e., a packet-level SN simulator based on ns3. The authors use Hypatia to investigate the impact of latency and link utilization on congestion control and routing. Cheng et al. in [29] present a packet-level simulator for space-air-ground integrated network based on ns3, which supports various mobility traces of space and aerial networks. Both the two SN simulators above focus on the classic TCP/IP architecture. Yan et al. in [28] build a packet-level SN simulator on OMNET++, and compare the performance between IP architecture and Named Date Network(NDN) architecture in the LEO satellite network scenario. The authors further conduct a comparative study of host-centric routingandinformation-centricroutinginlarge-scaleLEOsatellite constellations.

The aforementioned packet-level SN simulators have two drawbacks. First, it usually takes a long time to complete a simulation run due to the complexity of scheduling discrete events. For example, when the LEO constellation is large, OSPF protocol generates a great number of message exchanges and link-stateannouncements, aswellastheroutingtablecalculation events. These discrete events are not able to be scheduled in a parallel manner. Second, they are not able to run real protocol stacks of OS. This means that the packet-level simulation results still exhibit differences compared to the real-world system. Therefore, some studies have been exploring the virtual-network emulation for SN.

卫星网络(SN)的离散事件模拟(Discrete-Event Simulation)捕获不同层级的网络事件:

流级(Flow-level): 给定星座拓扑, 流级SN模拟器可以计算某些性能指标(例如, 端到端传播延迟).然而, 它们无法捕捉不同网络协议下数据包的细粒度行为.Lai等人在文献 [26] 中提出了StarPerf, 即一种基于Python的流级SN模拟器.它支持轨迹模拟, 拓扑生成和最短路径计算.他们利用StarPerf来获取优化星座架构的见解.

包级(Packet-Level): 现有的包级SN模拟器通常依赖于第三方离散事件模拟平台, 例如ns3 [30] 和 OMNeT++ [31].Kassing等人在文献 [27] 中提出了Hypatia, 即一种基于ns3的包级SN模拟器.作者使用Hypatia研究了延迟和链路利用率对拥塞控制和路由的影响.Cheng等人在文献 [29] 中提出了一种基于ns3的天地一体化网络包级模拟器, 该模拟器支持空间和空中网络的各种移动轨迹.上述两个SN模拟器都侧重于经典的TCP/IP架构.Yan等人在文献 [28] 中基于OMNeT++构建了一个包级SN模拟器, 并在LEO卫星网络场景中比较了IP架构与命名数据网络(NDN)架构的性能.作者进一步在大型LEO卫星星座中对以主机为中心的路由和以信息为中心的路由进行了比较研究.

上述包级SN模拟器存在两个缺点.首先, 由于调度离散事件的复杂性, 完成一次模拟运行通常需要很长时间.例如, 当LEO星座规模较大时, OSPF协议会产生大量的消息交换和链路状态通告, 以及路由表计算事件.这些离散事件无法以并行方式调度.其次, 它们无法运行操作系统的真实协议栈.这意味着包级模拟结果与真实世界系统相比仍存在差异.因此, 一些研究已经开始探索SN的虚拟网络仿真.

B. Virtual-Network Emulation for SN

The virtual-network emulators for SN mainly depend on three types of virtualization technologies: (i) Mininet (trimmed process virtualization); (ii) Container technology; (iii) Virtual machine technology. One could run real applications over SN with real-time response.

Mininet-based: Mininet [32] enables users to create a realistic virtual network, running a real kernel stack. However, Mininet does not provide specific support for SN emulation. Moreover, Mininet adopts lightweight virtualization (i.e., processbased) [32], thus is not suitable to emulate large-scale SN running distributed software (e.g., routing software). Cao et al. in [34] develop LeoEM (available at [43]), which emulates LEO constellations via Mininet. Moreover, LeoEM adopts StarPerf’s solution for constellation construction and the shortest-path calculation. The authors in [34] leverage LeoEM to evaluate their proposed congestion control mechanisms (i.e., SatTCP), aiming to address the challenge caused by frequent GSL handovers.

Container-based: The container-based network emulation has also been adopted in different scenarios other than SN. For example, Mukerjee et al. in [37] present the design of Etalon (available at [44]), i.e., an open source reconfigurable datacenter network emulator developed upon Docker container. The authors establish a testbed on four servers to emulate a datacenter network. However, Etalon does not support for SN emulation. Lai et al. in [35] develop StarryNet, i.e., a container-based emulator for SN. It is also implemented upon Docker, and emulates the distributed routing process by loading BIRD [45] on each container node. Particularly, StarryNet also incorporates some realorbitaldata(whichisnotthescopeofourstudyinthispaper). StarryNet is now partially available at [46]. Furthermore, Pan et al. in [36] introduce a similar container-based SN emulator, using another routing software Quagga [47]. However, they do not open source this work. Hence we are not able to provide performance comparison with it.

VM-based: Virtual machine (VM) technology enables users to create and connect multiple isolated virtual network nodes on a single physical machine, forming a virtual network. There are also several VM-based SN network emulators. For example, LORSAT [42] creates an emulation-based testbed integrating emulated satellite components with real LoRaWAN devices but only supports the bent-pipe architecture without routing calculation. NEaaS [40] is a cloud-based network emulation platform offering Network Emulation as a Service. It uses VM-Container hybrid architecture to build the virtual network. However, virtual machine nodes still hold a dominant position in their virtual networks. The high overhead of virtual machines prevents large-scale (thousands of nodes) network emulation. Celestial [38] is a micro-VM-based [39] virtual testbed for the LEO edge, primarily designed for edge computing scenarios. It create VMs only for involved satellites and lacks support for distributed routing emulation. Although VMs offer better isolation and the capacity to customize the kernel for each network node, the excessive overhead makes these emulation tools unable to meet the emulation requirements of large-scale LEO satellite networks.

OpenSN is a container-based emulator for SN. Compared to LeoEM and StarryNet, OpenSN exhibits advantages in emulation efficiency, system scalability, and function extensibility. We briefly summarize the comparison in Table II, and will introduce the detailed design in Section III.

SN的虚拟网络仿真器(Virtual-Network Emulation)主要依赖三种类型的虚拟化技术:(i) Mininet(精简的进程虚拟化);(ii) 容器技术;(iii) 虚拟机技术.用户可以在SN上运行具有实时响应能力的真实应用程序.

基于Mininet(Mininet-based): Mininet [32] 使用户能够创建运行真实内核栈的逼真虚拟网络.然而, Mininet并未提供针对SN仿真的特定支持.此外, Mininet采用轻量级虚拟化(即基于进程)[32], 因此不适合仿真运行分布式软件(如路由软件)的大规模SN.Cao等人在文献 [34] 中开发了LeoEM(可在 [43] 获取), 该工具通过Mininet仿真LEO星座.此外, LeoEM采用了StarPerf的星座构建和最短路径计算方案.文献 [34] 的作者利用LeoEM评估了他们提出的拥塞控制机制(即SatTCP), 旨在解决频繁GSL切换带来的挑战.

基于容器(Container-based): 基于容器的网络仿真也已被应用于SN以外的不同场景.例如, Mukerjee等人在文献 [37] 中介绍了Etalon的设计(可在 [44] 获取), 即一种基于Docker容器开发的开源可重构数据中心网络仿真器.作者在四台服务器上建立了一个测试床来仿真数据中心网络.然而, Etalon不支持SN仿真.Lai等人在文献 [35] 中开发了StarryNet, 即一种基于容器的SN仿真器.它也是基于Docker实现的, 并通过在每个容器节点上加载BIRD [45] 来仿真分布式路由过程.值得注意的是, StarryNet还结合了一些真实的轨道数据(这不在本文的研究范围内).StarryNet目前在 [46] 部分可用.此外, Pan等人在文献 [36] 中介绍了一种类似的基于容器的SN仿真器, 使用了另一种路由软件Quagga [47].然而, 他们没有开源这项工作, 因此我们无法提供与其的性能比较.

基于虚拟机(VM-based): 虚拟机(VM)技术使用户能够在单台物理机上创建并连接多个隔离的虚拟网络节点, 从而形成虚拟网络.也有一些基于虚拟机的SN网络仿真器.例如, LORSAT [42] 创建了一个基于仿真的测试床, 将仿真的卫星组件与真实的LoRaWAN设备集成, 但仅支持弯管(bent-pipe)架构, 不包含路由计算.NEaaS [40] 是一个基于云的网络仿真平台, 提供网络仿真即服务(Network Emulation as a Service).它使用虚拟机-容器混合架构来构建虚拟网络.然而, 虚拟机节点在其虚拟网络中仍占据主导地位.虚拟机的高开销阻碍了大规模(数千个节点)的网络仿真.Celestial [38] 是一个基于微虚拟机(micro-VM)[39] 的LEO边缘虚拟测试床, 主要为边缘计算场景设计.它仅为涉及的卫星创建虚拟机, 并且缺乏对分布式路由仿真的支持.尽管虚拟机提供了更好的隔离性, 并且能够为每个网络节点定制内核, 但过高的开销使得这些仿真工具无法满足大规模LEO卫星网络的仿真需求.

OpenSN是一个基于容器的SN仿真器.与LeoEM和StarryNet相比, OpenSN在仿真效率, 系统可扩展性和功能扩展性方面表现出优势.我们在表 II 中简要总结了对比情况, 并将在第三部分详细介绍其设计.

积累一下相关工作的分类

1. Orbit Analysis
   • 例如: STK
2. Discrete-Event Simulation
   • 按照 "转发level" 来分
   • flow level: StarPerf
   • packet level: Hypatia
3. Virtual-Network Emulation
   • 按照 "仿真方法" 来分
   • Mininet-based: Mininet
   • Container-based: StarryNet, OpenSN
   • VM-based: LORSAT(Testbed), NEaaS(Cloud), Celestial(Micro-VM)

OpenSN Framework

This section presents the design of OpenSN. We first provide an overview in Section III-A. We then introduce the improvements on emulation efficiency and system scalability in Section III-B and Section III-C, respectively. We introduce the enhancement via eBPF links in Section III-D. Finally, we present the function extensibility of OpenSN in Section III-E.

A. Overview and Architecture

OpenSN is a virtual-network emulator for LEO satellite networks, which leverages containers and virtual links to emulate SN.Fig.1showsthearchitectureofOpenSN, includingthreekey components: User-Defined Configurator, Container Network Manager, and Key-Value Database.

User-Defined Configurator allows users to specify the emulation parameters (e.g., constellation, connectivity, nodes, etc) and the emulation rules (e.g., ISL failure model, GSL handover policy, trajectory udpate, etc) in OpenSN. To enhance extensibility, the corresponding configuration data will not be directly passed to Container Network Manager, but will be recorded in Key-Value Database.

Key-Value Database records the necessary information of SN emulation. Some are user-specified emulation parameters and rules from User-Defined Configurator. Some are status data of SN emulation obtained from Container Network Manager in each machine. Table III summarizes the information recorded in OpenSN’s Key-Value Database, which includes the configuration for machines, nodes, links, and applications. Specifically, each configuration may include required ones and user-defined ones.

• Required configurations cover the necessary parameters or rules required by SN emulation. For example, a machine’s maximum number of containers specifies how many containers can run on each machine. Geometric parameters of satellites and ground stations (GS) are used to calculate the trajectories of satellites and control the ground-satellite link (GSL) handover and inter-satellite link (ISL) failure.

• User-defined configurations are the optional configurations that could be customized by OpenSN users. These configurations will take effect in OpenSN User-Defined Configurator and container applications. In Table III, we list some examples used in Section IV. For example, we specify the timestamps for terminal user (TU) node to send requests to the content provider (CP). Furthermore, OpenSN leaves more possibilities to users to achieve a better extensibility.

Container Network Manager controls the major functionality of SN emulation, which is conducted on multiple machines connected by VXLAN. According to the information from Key-ValueDatabase, ContainerRuntimeManagerisresponsible for container creation/deconstruction and single-node resource management. Virtual Link Manager constructs the virtual links for each ISL and GSL in SN. Moreover, Message Forwarder is used to transfer necessary information (e.g., real-time topology, IP address of each interface, and user’s command) between KeyValue Database and Multi-Machine Emulation Environment.

OpenSN 采用分离式架构, 主要包含三个关键组件:

1. 用户定义配置器 (User-Defined Configurator):
   • 用于指定仿真参数(如星座, 拓扑)和规则(如 ISL 故障, GSL 切换)
2. 键值数据库 (Key-Value Database):
   • 记录仿真所需信息, 作为配置器与底层网络管理器之间的数据中转站, 增强了系统的扩展性
3. 容器网络管理器 (Container Network Manager):
   • 负责在通过 VXLAN 连接的多台机器上控制容器生命周期和虚拟链路构建

Fig. 1 展示了这三个组件如何协同工作以及与多机仿真环境的交互:

B. Efficient Network Emulation

One of the major challenges and performance bottlenecks of emulating SN lies in the network emulation. On the one hand, the number of involved nodes, ISLs and GSLs is huge for LEO mega-constellations. On the other hand, the link state changes (e.g., ISL failure/recovery and GSL handover) are quite frequent due to the mobile nature of LEO satellites. These two aspects above require an efficient network manager. Existing containerbased SN emulators are not efficient enough due to the following two drawbacks.

• The Docker network controller is not developed for emulating large-scale networks with frequent state changes. Specifically, the Docker network manager exhibits unnecessary processes in container management and link management (e.g., repeatedly interacting with data stores). Moreover, concurrent network state changes (e.g., creation/deconstruction of containers and links) may be blocked by the Docker Daemon in the same task queue, which reduces the response speed of network emulation. This becomes an even more significant overhead when the constellation scales up.

• The existing SN emulators do not optimize the scheduling of network construction tasks. Roughly speaking, the creation of a container network includes two steps: node creation (heavy computation) and link creation (light computation). As shown in Fig. 2, serial execution (e.g., Mininet) will lead to insufficient utilization of CPU resources for light-computation tasks, thus eventually slowing down the network construction. Parallel execution (e.g., StarryNet) will cause frequent process switching and blocking for computation-intensive tasks, thus eventually slowing down the network construction.

Based on the above observations, Container Network Manager tends to improve the emulation efficiency from the perspectives of nodes and links. We first introduce how OpenSN streamlines the procedure of node management and link management via Container Runtime Manager and Virtual Link Manager, respectively. We then introduce their interactions.

Container Runtime Manager of OpenSN is implemented in a distributed manner and should be deployed on each machine. To improve the efficiency, we make the following improvements. First, Container Runtime Managers of OpenSN in each machine rely on a coroutine pool to schedule the node creation/deconstruction tasks in a parallel manner. The capacity of such a coroutine pool is determined by the CPU specification of the machine, which can limit the number of simultaneous tasks and avoid excessive process switching. Second, Container Runtime Manager of OpenSN leverages the official Docker SDK to connect with Docker daemon, instead of relying on Docker Command Line Interface (CLI) like StarryNet. This enables OpenSN to skip many unnecessary processes (e.g., launch shell and Docker-client) when creating containers or executing commands inside containers, thus significantly reducing the operation overhead.

Virtual Link Manager of OpenSN is developed to directly manage the Linux virtual network devices and the network namespace. This manager has the highest priority. It will immediately create a coroutine to implement rapid response once the command of link-state change is detected. Furthermore, OpenSN’s Virtual Link Manager streamlines the process of creating a virtual link. Fig. 3 shows the event sequence of creating a virtual link under Docker Network Manager and OpenSN’s Virtual Link Manager. Specifically, Docker Network Manager creates a link in three major actions:

• Create network,

• Connect to the first container,

• Connect to the second container.

Moreover, each action actually consists of several steps, e.g., parsing/fetching information and other necessary configurations. Such a process will reduce efficiency of link operations. For example, the interaction with a data store will trigger concurrent synchronization throttling, reducing the parallelism of task execution. In contrast, Virtual Link Manager of OpenSN could establish a virtual link within a single call, which improves the parallelization efficiency of link operations.

Interaction between Node & Link Creation: The interaction between node creation and link creation also affects the emulation efficiency. Roughly speaking, link creation tasks cannot be executed until the corresponding two containers have been created.StarryNetandMininetstarttoexecutelinkcreationtasks after all the containers in the emulation environment have been created. Obviously, such a scheduling pattern is not efficient in terms of time. OpenSN tends to optimize the interaction between node creation and link creation, aiming to speed up the network construction progress. To this end, OpenSN implements a fine-grained orchestrator for dependent tasks, and aims to create correlated containers and links together. Specifically, Virtual Link Manager of OpenSN has a waiting pool, which records all the received link creation tasks. Upon a container being created, Container Runtime Manager of OpenSN would signal the waiting pool. Virtual Link Manager then starts to create links of this container.

Although OpenSN has improved the efficiency of link creation, it is still a significant overhead to configure a great number of link handovers at one time. 1 However, GSL handover is a crucial aspect in SN emulation. To address this issue, OpenSN tends to improve the efficiency of emulating GSL handover via eBPF. In the following, we first present multi-machine extension in Section III-C. We then introduce how to improve the handover efficiency for intra-machine links and inter-machine links in Section III-D.

高效的网络仿真机制

为了解决大规模节点和频繁链路变更带来的效率瓶颈, OpenSN 进行了以下优化:

1. 任务调度优化:

   • 如 Fig. 2 所示
   • OpenSN 采用 带限制的并行执行策略(协程池), 避免了 Mininet 的串行低效和 StarryNet 的"爆发式并行"导致的进程切换阻塞

2. 链路创建简化:

   • 如 Fig. 3 所示
   • OpenSN 的虚拟链路管理器(Virtual Link Manager)跳过了 Docker 网络管理器的冗余步骤(如反复连接容器, 解析信息), 通过 直接调用 Linux 虚拟设备接口, 实现了单次调用即可建立链路, 显著提升了效率

C. Multi-Machine Extension

The virtual-network emulation for LEO mega-constellation requires a lot of computing resources. Although OpenSN has made significant improvements in emulation efficiency in Section III-B, the pattern of single-machine deployment still cannot afford to emulate thousands of satellites running resource-hungry applications. Hence OpenSN provides the capability of multi-machine extension. Next we introduce how the control plane and data plane work.

1) Control Plane: To achieve flexible multi-machine extension, OpenSN’s control plane consists of centralized control and distributed execution (in multiple machines). Fig. 4 plots the control plane framework for multi-machine extension.

Centralized Control is achieved by User-Defined Configurator shown in Fig. 1. The OpenSN SDK for Python for User-Defined Configurator generates the detailed information (i.e., machine index, nodes, links, interfaces, etc) for each machine. This process is transparent to OpenSN users. This enables OpenSN users to control the configuration on a single machine without considering the entire emulation environment.

Distributed Execution refers to container network creation and operation on different machines. Each machine is responsible for emulating part of the LEO satellites and the corresponding links. Such a parallel execution paradigm helps reduce the runtime resource consumption on a single machine, thus improving the execution efficiency. For load-balancing, we use a weighted round-robin procedure to assign containers and links to the machines. Algorithm 1 summarizes the procedure. Algorithm 1 mainly consists of two phases.

• Lines 2-6 initialize the WeightList and the WeightLeftList according to the weight of machines. The WeightLeftList is used to assign instances to each machine, and the WeightList is used to refresh the WeightLeftList in each round. This phase also initializes the variable i, which is the index of the current machine that the scheduler assigns instances to.

• Lines 7-14 assign the instances and links to the machines.

When an instance and its links have been assigned to the Set machine [i], the WeightLeftList[i] decreases. When the WeightLeftList[i] reaches zero, the WeightLeftList[i] will be refreshed. This loop will continue until all instances have been assigned.

At the end, the instances and links will be divided into several subsets and assigned to each machine according to the resource capacity of each machine.

Instruction Delivery is achieved by a KV database based on Etcd [48]. Specifically, Etcd records the status of different entities (e.g., containers and links). For example, the status of a link entity could be connected or disconnected. The instructions generated based on user configuration will be dispatched to the corresponding machines. With the server-pushing ability, Etcd is able to immediately notify the Container Network Manager of the corresponding machine (once the status change is detected). Accordingly, Container Network Manager will update the emulation environment. This enables Container Network Manager of each machine to immediately respond to the frequent status changes (e.g., link delay and link connection) at a low cost in LEO constellations.

2) Data Plane: To achieve multi-machine extension, the data plane of OpenSN should be able to emulate the ISLs and GSLs when the corresponding containers are deployed on different emulation machines. OpenSN leverages VXLAN technology [49] to achieve inter-machine data transfer. This is because most links of SN are point-to-point, and VXLAN naturally supports such a network structure and can flexibly connect containers across machines. As we will see in Section III-D, OpenSN can further improve the emulation efficiency of intermachine links via eBPF technique [50].

多机扩展能力

为了支持资源需求巨大的巨型星座仿真, OpenSN 支持多机部署:

• 控制平面: 如 Fig. 4 所示, 采用"集中控制, 分布式执行"的模式.配置器生成指令并通过 Etcd 数据库分发到各台机器的管理器上
• 负载均衡: 使用加权轮询算法(Algorithm 1)将容器和链路分配到不同机器上

D. Enhancement Via eBPF Links

We have introduced how OpenSN improves the emulation efficiency and scalability in Section III-B and Section III-C, respectively. To further enhance the two aspects above, OpenSN incorporates a novel virtual link structure based on XDP (eXpress Data Path) [50]. This is especially beneficial to emulate frequent GSL handover and speed up the inter-machine data stream. Next we first introduce eBPF links. We then present intra-machine eBPF links and inter-machine eBPF links.

1) eBPF Links: The eBPF link is a virtual link structure, which uses eBPF program (attached to the XDP hook point of the virtual network device) to realize the function of redirecting frames. Specifically, the eBPF program provides the ability to revise the kernel space data path. With this capability, the eBPF link could outperform the traditional virtual links in the followingtwoaspects. Forintra-machinelinks, eBPFlinkscould replace all the Linux bridge devices with a redirect controller. For inter-machine links, eBPF links could transmit the Ethernet frames by directly modifying destination MAC address instead of repacking the packets. The two aspects above significantly reduce the number of Linux virtual devices, and streamline the operation of link handover.

Next we introduce the detailed implementation of eBPF links for inner-machine and inter-machine cases, respectively.

2) Inner-Machine eBPF Links: We demonstrate the difference between eBPF link structure and legacy link structure based on Fig. 5. Specifically, the legacy link structure relies on Linux bridge devices. In contrast, eBPF link structure uses the kernel-space eBPF program and eBPF map to implement frame redirection for virtual links. Overall, eBPF link structure exhibits the following two-fold advantages:

Efficient Network Construction: As mentioned above, the process of creating an eBPF link skips the bridge device creation compared to the legacy link. This reduces the burden of Virtual Link Manager, and facilitates efficient network construction and deconstruction.

Better Runtime Efficiency: The eBPF technique also improves the runtime efficiency in terms of configuring link handover. As shown in Fig. 6, the handover of legacy links involves deleting and recreating virtual devices (i.e., Linux bridges). Such a process will inevitably change the interface inside the container, causing extra overhead. Moreover, some switch functions (e.g., broadcast and port redirect map) in Linux bridges are redundant for point-to-point links, which consume more computation resources than eBPF redirect program. In contrast, the handover of eBPF links can be achieved by directly modifying the redirect map, which is much faster than virtual device configuration. Moreover, the container can keep the same interface after handover. Therefore, eBPF technique enables OpenSN to efficiently change the connections of network nodes.

3) Inter-Machine eBPF Links: Given the capability of multimachine extension, the inter-machine links are used to transmit Ethernet frames to the correct container in the correct machine. This type of link could be implemented via VXLAN or eBPFbased XDP. OpenSN supports both methods. We illustrate the difference based on Fig. 7.

VXLAN: Ethernet frames will be transformed into UDP datagrams in the source container, and then sent to the destination machine. After the UDP datagrams reach the destination machine, it will be transformed into Ethernet frames in VXLAN devices with specified VXLAN Network Identifier (VNI), which is then forwarded to the destination container.

eBPF: For eBPF links, there is no need to conduct the transformation between Ethernet frames and datagrams. Algorithm 2 shows procedure of the eBPF program attached to the virtual NIC. Algorithm 2 consists of two phases.

• Lines 1-2 update the destination MAC address of the packet. If the field Pkt.SrcMac is in the key set of the Map dst , then the forwarder will update the Pkt.DstMac to the corresponding value in the Map dst .

• Lines 3-9 forward the packet based on three different scenarios. If the field Pkt.SrcMac is in the key set of the Map fwd , then this packet should be forwarded to a container inside the current machine. Otherwise, the forwarder should check the direction of the packet. If it is an Egress packet, then it should be sent out from the current machine. Otherwise, it is a packet for this machine, thus should be delivered to upper-layer protocols.

When a packet is sent from a container instance, the eBPF program attached to the egress direction of a specified NIC in the source machine will modify the destination MAC address of the Ethernet frame. Consequently, the frame will be forwarded to the NIC of the destination machine. Accordingly, when a packet arrives at a machine’s gateway NIC, the eBPF program attached to the ingress direction of the specified NIC in the destination machine will restore the received frame and redirect it to the destination container.

Note that the above procedure takes advantage of the point-to-point links in satellite networks, i.e., each source MAC address corresponds to a unique destination MAC address.

The eBPF-based implementation for inter-machine links provides the better function extensibility, since it does not rely on network-layer protocols in Linux kernel. However, the VXLAN-based implementation relies on the UDP protocol and IP network. Therefore, the eBPF-based implementation enables researchers to develop and evaluate novel network-layer architectures and protocols based on OpenSN.

基于 eBPF 的链路增强

OpenSN 引入了基于 XDP 的 eBPF 链路结构以进一步提升性能:

1. 结构优势:

   • 如 Fig. 5 所示
   • eBPF 链路使用 XDP 重定向路径替代了传统的 Linux 网桥(Bridge), 减少了虚拟设备的创建开销
   • 

2. 快速切换:

   • 如 Fig. 6 所示
   • 在进行链路切换(Handover)时, 传统方式需要删除并重建设备(慢), 而 eBPF 链路只需修改重定向映射表(快), 且能保持容器接口不变
   • 

3. 跨机通信优化:

   • 如 Fig. 7 所示
   • 相比于 VXLAN 需要将帧封装为 UDP 数据报, eBPF 链路可以通过直接修改目的 MAC 地址来转发数据帧, 提供了更好的效率和协议扩展性
   • 

详细展开此处 XDP + eBPF 的设计

(1) eBPF (extended Berkeley Packet Filter)

通俗理解:

它是一种让用户能在操作系统内核(Kernel)中运行自定义代码的技术, 而不需要修改内核源码

论文中的定义:

eBPF 是一种在内核空间运行的程序, 它提供了修改内核空间数据路径(Data Path)的能力

在 OpenSN 中的作用:

• 它被用来替代传统的 Linux 网桥(Bridge)设备, 充当一个"重定向控制器"
• 它使用 eBPF Map(一种键值对存储结构)来记录数据包应该转发到哪里

核心优势:

• 当卫星移动导致链路切换(Handover)时, 传统方法需要"删除旧设备, 创建新设备", 这很慢
• 而 eBPF 只需要修改 Map 中的记录(比如把"发给卫星A"改成"发给卫星B"), 这非常快

(2) XDP (eXpress Data Path)

通俗理解:

它是网络数据包进入系统后的第一个"关卡"或"挂载点", 数据包刚到网卡还没深入系统时, 就可以在这里被处理

论文中的定义:

XDP 是虚拟网络设备上的一个 Hook Point(挂载点)

在 OpenSN 中的作用:

• 它允许 eBPF 程序直接挂载在这个点上
• 它的主要功能是实现帧重定向(Redirecting Frames), 即在数据包刚到达时, 就直接根据规则把它"踢"到目标容器去, 而不必经过复杂的操作系统协议栈处理

(3) 它们是如何配合工作的?

在 OpenSN 中, 这两者结合形成了一种高效的虚拟链路结构(eBPF Link Structure):

1. 位置 (XDP): OpenSN 在虚拟网卡的入口(XDP 挂载点)安插了哨兵
2. 指令 (eBPF): 这个哨兵执行的是 eBPF 程序
3. 操作:
   • 同机转发: 如果数据包是发给同一台机器上的另一个容器, eBPF 程序直接通过 Redirect Map 把它转过去, 跳过了创建 Linux 网桥的繁琐步骤
   • 跨机转发: 如果数据包是发给另一台机器的, eBPF 程序直接修改以太网帧的目的 MAC 地址, 把它转发到目标机器的网卡, 而不需要像 VXLAN 那样把数据包重新封装一遍(减少开销. 不过笔者认为有点牵强, 在多机不同子网的环境下, 还是需要 VXLAN 的; 光 MAC Redirect 仅限同一子网的多机实验环境)

E. Enhanced Extensibility

Besides the above efficiency improvement, OpenSN also enhances the extensibility from the perspectives of architecture and container image.

1) Architecture: To facilitate the performance evaluation of new studies, SN emulators should exhibit good extensibility in terms of the emulation functionality. The existing network simulation/emulation libraries usually enhance function extensibility by separating the business code (for simulation/emulation) from the operation code (of the simulation/emulation environment). With the simulator/emulator SDKs, users can customize the simulation/emulation rules without understanding the underlying environment in detail. OpenSN also follows such a design philosophy to achieve a better function extensibility. As we mentioned in Fig. 1, OpenSN users can flexibly specify the emulation parameters and emulation rules via the User-Defined Configurator.

2) Container Images: OpenSN also allows users to change the functionality of each node. In general, SN emulation may involve many different types of nodes, e.g., satellites, GSs, terrestrial routers, switches, HTTP servers, and servers of different content providers. Container technique provides the applicationlevel isolation and the portability of virtual environment [51]. With the help of Open Container Initiative (OCI) [52], various applications can be deployed into the containers. However, existing container-based emulators (e.g., StarryNet) usually support only a few images, and are hard to cover all possible configuration actions. This is because they use direct function calls to configure the environment inside the container. For example, the configurator of StarryNet generates the configuration file for BIRD routing software and launches the BIRD directly by itself. Consequently, StarryNet can only use the image running BIRD routing software. If one wants to use other images, then it is necessary to modify StarryNet and rewrite all that couples with this image.

To overcome the above drawback, OpenSN leaves the image configuration actions to the initialization program inside the container. This way, OpenSN users can configure the environment inside the container by specifying necessary information in the initialization program. This approach provides users with better flexibility. For example, if one would like to change the routing configuration, it only requires replacing the image and the initialization program inside the container, instead of modifying the entire emulator. However, the aforementioned initialization program involves a technical problem, i.e., the initialization program cannot get information (e.g., addresses of other containers) outside the container. To address this issue, OpenSN implements the message forwarder to create an informationpathfromUser-DefinedConfiguratortotheenvironment inside the container. Based on User-Defined Configurator, OpenSN users can generate configuration data for each container and upload them to the Key-Value Database. Upon detecting changes, the message forwarder will be noticed and forward them into the containers. To sum up, OpenSN enables users to load any container image to the network node without changing the emulation library.

3) Case Study: We will demonstrate the function extensibility of OpenSN, and introduce how to build a video streaming scenario in satellite-terrestrial integrated network (STIN). As shown in Fig. 8, this scenario consists of three autonomous systems (ASes). AS 1 corresponds to Starlink Shell-I constellation (i.e., 72 orbits and 22 satellites per orbit). AS 2 consists of a terrestrial user (TU), a router, and a ground station (GS). AS 3 consists of a content provider (CP), a router, and a GS. The video stream is delivered from CP to TU via the satellite network. OpenSN can build container images for different types of nodes in this scenario. The detailed steps will be introduced in Section IV.

功能扩展性与案例

OpenSN 允许用户自定义容器镜像和初始化程序, 从而支持不同的路由协议或应用:

案例研究: 如 Fig. 8 所示, 论文展示了一个天地一体化网络视频流传输的仿真场景, 包含三个自治系统(Starlink 星座, 地面用户, 内容提供商), 验证了 OpenSN 构建复杂异构网络的能力

Conclusion and Future Work

This paper presents OpenSN, i.e., an open source library for emulating large-scale LEO satellite networks. OpenSN adopts container-based virtualization, thus allowing for running distributed software (e.g., routing) on each node, and achieves a better horizontal scalability than Mininet-based SN emulator LeoEM. Compared to other container-based SN emulators (e.g., StarryNet), OpenSN streamlines the interaction with the Docker CLI and significantly reduces unnecessary operation during virtual link creation. These modifications improve emulation efficiency and vertical scalability on a single machine. Furthermore, OpenSN separates user-defined configuration from container network management via a Key-Value Database that records the necessary information for SN emulation. Such a separation architecture enhances the function extensibility. Experimental results validate the performance of OpenSN.

The development of OpenSN is still in its early stage. In the future, we would like to make the following improvements.

• Routing Protocols: The convergence time is a critical metric for routing protocols. It is especially important for LEO satellite networks with topology dynamics. In the future, we would like to develop more state-of-the-art routing protocols (e.g., OPSPF [12] and LoFi [13]) on OpenSN, and then investigate the convergence time in LEO mega-constellations.

• Networking Architectures: OpenSN is now built on host-centric IP networking architecture, which was initially designed for wired networks. The topology characteristics of LEO constellations are quite different from those of wired networks. To facilitate LEO satellite networking innovation, it is necessary to enrich the protocol stacks of OpenSN and make it support the emulation of alternative protocol stacks (e.g., content-centric NDN [55] and linkcentric LIPSIN [56]) and even newly developed protocols.

• Efficient Prototyping: The primary goal of network emulation is protocol prototypes. Researchers and engineers face significant challenges on developing new network protocols, since they need to understand the kernel stack code and then develop the new protocols on top of it. We will isolate the protocol logic from the kernel implementation for OpenSN, aiming to help expedite the development process and allow researchers to focus more on the protocol itself.

本文介绍了 OpenSN, 即一个用于仿真大规模 LEO 卫星网络的开源库.OpenSN 采用基于容器的虚拟化技术, 从而允许在每个节点上运行分布式软件(例如, 路由软件), 并且实现了比基于 Mininet 的 SN 仿真器 LeoEM 更好的水平可扩展性.与其他基于容器的 SN 仿真器(例如, StarryNet)相比, OpenSN 简化了与 Docker CLI 的交互, 并显著减少了虚拟链路创建过程中不必要的操作.这些修改提高了单机的仿真效率和垂直可扩展性.此外, OpenSN 通过一个记录 SN 仿真必要信息的键值数据库, 将用户定义的配置与容器网络管理分离开来.这种分离式架构增强了功能的可扩展性.实验结果验证了 OpenSN 的性能.

OpenSN 的开发仍处于早期阶段.未来, 我们计划进行以下改进:

• 路由协议(Routing Protocols):
  • 收敛时间是路由协议的一个关键指标.对于具有拓扑动态性的 LEO 卫星网络而言, 这一点尤为重要
  • 未来, 我们计划在 OpenSN 上开发更多最先进的路由协议(例如, OPSPF [12] 和 LoFi [13]), 进而研究 LEO 巨型星座中的收敛时间
• 网络架构(Networking Architectures):
  • OpenSN 目前建立在以主机为中心的 IP 网络架构之上, 该架构最初是为有线网络设计的.LEO 星座的拓扑特征与有线网络截然不同
  • 为了促进 LEO 卫星组网的创新, 有必要丰富 OpenSN 的协议栈, 使其支持替代协议栈(例如, 以内容为中心的 NDN [55] 和以链路为中心的 LIPSIN [56])甚至新开发协议的仿真
• 高效原型设计(Efficient Prototyping):
  • 网络仿真的首要目标是协议原型设计.研究人员和工程师在开发新的网络协议时面临重大挑战, 因为他们需要理解内核栈代码, 然后在此基础上开发新协议
  • 我们将把协议逻辑与 OpenSN 的内核实现隔离开来, 旨在帮助加快开发过程, 并允许研究人员将更多精力集中在协议本身上