ns-3-leo: Evaluation Tool for Satellite Swarm Communication Protocols

(1) 研究背景与动机

• 背景: 现代光纤和地面网络覆盖有限, LEO 卫星巨型星座 (如 SpaceX 的 Starlink, Telesat) 被视为提供全球宽带互联网接入的解决方案
• 问题:
  • 与地球静止轨道 (GEO) 卫星不同, LEO 卫星具有高动态性, 网络拓扑不断变化
  • 现有的路由协议 (来自 MANET 或 WSN 领域) 在这种环境下的表现尚不明确
• 目标: 开发一个仿真工具 (ns-3-leo), 用于在离散事件模拟器中模拟 LEO 网络的移动性和链路特性, 以便评估路由协议

(2) 系统模型

论文详细描述了 ns-3-leo 模块的三个核心模型组件:

• 坐标参考系 (Coordinate Reference Frame):

  • 使用 ITRF (国际地球参考框架) 作为统一的坐标系, 便于处理地面站 (固定) 和卫星 (移动) 的位置

• 移动性模型 (Mobility Model):

  • 支持基于倾角, 方位角和高度的 圆形轨道 简化模型.
  • 允许动态计算卫星位置, 速度和航向, 支持模拟尚未发射的星座 (通过公开参数设定)

• 信道模型 (Channel Model):

  • 星间链路 (ISL): 基于视距 (Line-of-Sight, LOS) 判断两颗卫星是否可以通信 (需不被地球遮挡)
  • 星地链路 (Satellite-Ground): 基于卫星波束覆盖角度和视距判断连接, 并结合路径损耗模型计算接收功率

(3) Implementation

• 平台: 基于 ns-3 (v3.30) 开发的模块
• 功能:
  • 提供了处理卫星和地面站移动性的 Helper 类
  • 实现了支持 ISL 和星地通信的 NetDevice 和 Channel
  • 支持从外部文件导入轨道参数或 TLE 数据

Introduction

Modern terrestrial and fiber-optics networks provide fast broadband internet connectivity, but in 2019 they served only around 54% of the global population [1]. For people living in remote areas or in countries with insufficient infrastructure, access is limited.

Low Earth Orbit (LEO) satellite constellations such as Iridium [2] and Globalstar [3] provide telephony and internet coverage in remote areas. While providing reliable coverage to most of the world, these older types of networks do not support the data rates needed by modern internet applications and their network capacity is quite limited. Another way of providing broadband internet connections is via GeoStationary Earth Orbit (GEO) satellites [4]. The position in GEO has the advantage of needing considerably fewer satellites to achieve global coverage. While the data rates of these satellites support modern internet applications, the considerable distance from earth has the disadvantage of long end-to-end delays and the bandwidth that is offered to end-users can not compete with fiber-optics or terrestrial networks where those are available.

In recent years, the idea of using many LEO satellites for this purpose has been promoted by a number of companies, among which SpaceX [5], Amazon [6], Telesat [7], OneWeb [8] are some of the more notable competitors. An example of such a mega-constellation can be seen in figure 1.

Based on theoretical calculations, the network capacity would be sufficient to provide a high-bandwidth internet connectivity [9] comparable to that of fiber-optics networks. While the low altitude of LEO satellites results in very low latency [10], because of the small signal propagation delay compared to GEO satellites, a significantly larger number of stations are required to relay data over the same distance, as Barrios et al. [9] point out. To overcome part of this challenge, Inter-Satellite Link (ISL) have successfully been used in the past to extend the connectivity of individual satellites beyond the horizon [11]. ISLs allow for the direct transmission of data between satellites either using directed radio links or laser terminals. This removes the need for additional ground relays, where such links are possible. Figure 1 shows an example of a multi-hop path between a user terminal and a gateway that contains multiple ISL.

ISLs also have the potential to increase the overall throughput [9], reduce operational costs and allow satellite operators to scale their networks by adding additional orbits and satellites without the need for additional ground stations. The downside of this is, that with such ISL-based multi-hop networks there may exist various alternate paths. Hence, the network operator has to introduce appropriate routing algorithms to optimize the available network capacity. Routing is a classical problem in many networking contexts. The solution always depends on various parameters of the network such as nature of interconnects of the individual nodes, data and error rates, as well as mobility (if relevant).

For LEO satellite mega-constellations, the orbits of individual satellites are deterministic, but the topology of the network is constantly changing, interconnects (e.g., via ISL) change and individual satellites may disappear from or be added to the network at any time, due to equipment failure or traffic volume. As of today, there is only little published information about the routing protocols satellite operators might use to support these types of networks. At the same time, LEO networks share characteristics with other network types such as from MANET and WSN as they have to deal with mobility, a large volume of traffic, limited resources and certain requirements for the quality of service. There is a wide variety of candidate protocols that each solve some of these challenges [12], but a more specific evaluation has yet to be done.

现代地面网络与光纤网络虽提供了高速宽带互联网连接, 但在2019年, 其服务范围仅覆盖了全球约54%的人口[1]. 对于居住在偏远地区或基础设施匮乏国家的人群而言, 网络接入依然受限.

低地球轨道 (LEO) 卫星星座, 如铱星 (Iridium) [2]和全球星 (Globalstar) [3], 为偏远地区提供了电话与互联网覆盖. 尽管这些早期类型的网络能够为全球大部分地区提供可靠的覆盖, 但其不支持现代互联网应用所需的数据传输速率, 且网络容量相当有限. 另一种提供宽带互联网连接的途径是利用地球静止轨道 (GEO) 卫星[4]. GEO轨道的优势在于仅需极少量的卫星即可实现全球覆盖. 虽然此类卫星的数据速率能够支持现代互联网应用, 但其与地球的巨大距离导致了较长的端到端延迟, 且在已部署光纤或地面网络的区域, 其提供给终端用户的带宽无法与前者抗衡.

近年来, 利用大量LEO卫星来实现这一目标的理念得到了众多企业的推动, 其中SpaceX[5], 亚马逊 (Amazon) [6], Telesat[7]和OneWeb[8]是较为著名的竞争者. 图1展示了此类巨型星座的一个示例.

基于理论计算, 其网络容量足以提供与光纤网络相媲美的高带宽互联网连接[9]. 尽管由于信号传播延迟远小于GEO卫星, LEO卫星的低轨道特性带来了极低的延迟[10], 但正如Barrios等人[9]所指出, 为了在相同距离上传输数据, 需要显著更多的中继站点.

为部分克服这一挑战, 星间链路 (ISL) 在过去已被成功用于将单颗卫星的连接范围扩展至视距之外[11]. ISL允许利用定向无线电链路或激光终端在卫星之间直接传输数据. 在可行的情况下, 这消除了对额外地面中继的需求. 图1展示了用户终端与网关之间包含多条ISL的多跳路径示例:

ISL还具有提高整体吞吐量[9], 降低运营成本的潜力, 并允许卫星运营商通过增加轨道和卫星来扩展网络, 而无需增设地面站. 然而, 其不利之处在于, 在此类基于ISL的多跳网络中可能存在多种替代路径. 因此, 网络运营商必须引入适当的路由算法以优化可用网络容量. 路由是许多网络环境中的经典问题. 其解决方案始终取决于各种网络参数, 例如各个节点的互连性质, 数据速率与误码率, 以及移动性 (如果相关).

对于LEO卫星巨型星座而言, 虽然单颗卫星的轨道是确定性的, 但网络拓扑结构却在不断变化, 互连关系 (如通过ISL) 随之改变, 且由于设备故障或流量需求, 个别卫星可能随时退出或加入网络. 截至目前, 关于卫星运营商可能用于支持此类网络的路由协议的公开信息寥寥无几. 与此同时, LEO网络与移动自组网 (MANET) 及无线传感器网络 (WSN) 等其他网络类型具有共同特征, 即都需应对移动性, 大数据流量, 受限资源以及特定的服务质量 (QoS) 要求. 尽管存在多种候选协议可解决部分挑战[12], 但尚缺乏更具针对性的评估.

A. PROBLEM STATEMENT

To learn more about the performance of existing MANET and WSN protocols in the context of LEO networks, it would be of interest to see how individual protocols perform inside a discrete event network simulation environment. This simulation requires detailed models of the network topology, radio technologies and network protocols involved in LEO mega-constellations.

While all of these individual topics have been theoretically covered in previous research and are relatively well understood, some building blocks for a simulation are still missing. As a first step towards a practical assessment of possible protocol options, we created ns-3-leo, a simulation tool for the network topology and link characteristics of LEO networks. Using this tool, we were able to identify future challenges for routing protocols in LEO mega-constellations, but more important we support developers to implement and investigate new protocols.

A. 问题陈述

为了深入了解现有的MANET和WSN协议在LEO网络环境下的性能, 探究各协议在离散事件网络仿真环境中的表现具有重要意义. 此类仿真需要对LEO巨型星座所涉及的网络拓扑, 无线电技术及网络协议建立详细模型.

尽管所有这些独立主题在过往研究中已在理论层面得到涵盖且被相对透彻地理解, 但构建仿真所需的部分模块依然缺失. 作为对潜在协议选项进行实际评估的第一步, 我们开发了 ns-3-leo, 这是一种用于模拟LEO网络拓扑及链路特性的仿真工具. 利用该工具, 我们不仅能够识别LEO巨型星座中路由协议面临的未来挑战, 更重要的是, 我们能够支持开发人员实现并研究新的协议.

B. DOCUMENT STRUCTURE

First, we present an overview of previous work on the simulation LEO satellite networks. In section III, we describe our mobility model and channel models. The implementation of a ns-3-leo as a module of ns-3 is further detailed in section IV. In section V, we present the results of our analysis of the performance of ns-3-leo. We then use it to evaluate AODV for a set of scenarios involving the Starlink and Telesat networks, to showcase its capabilities. In section VI, we discuss the current limitations of our approach, identify challenges for new and emerging routing protocols in LEO satellite networks and then present our conclusion.

B. 论文结构

首先, 我们概述了关于LEO卫星网络仿真的相关工作. 在第三节中, 我们描述了移动性模型和信道模型. 作为ns-3扩展模块的ns-3-leo的实现细节将在第四节中进一步阐述. 在第五节中, 我们展示了对ns-3-leo性能的分析结果; 随后, 为了展示其功能, 我们利用该工具针对涉及Starlink和Telesat网络的一组场景对AODV协议进行了评估. 在第六节中, 我们讨论了当前方法的局限性, 指出了LEO卫星网络中新兴路由协议面临的挑战, 并最后提出了结论.

Related Work

The following section highlights some research related to LEO mega-constellations, the involved radio technology and related routing protocols. We also discuss similar simulations from the literature and compare them to our own.

A. STATISTICAL MODELS

The Federal Communications Commission (FCC) filings for the Starlink [5], OneWeb [8] and Telesat LEO [7] constellations contain detailed information on their link characteristics and orbital parameters. All of them have similar architectures with many ground stations and satellites, but with some notable differences. OneWeb’s constellation does not feature ISL in its first generation, while Starlink plans to have significantly more satellites when fully deployed. An exemplary overview of the network architecture of Telesat LEO constellation is shown in figure 1.

Barrios et al. [9] described and compared some of these planned LEO constellations in detail. They combined the models of the topology and link budgets with the Iternational Telephony Union (ITU) model for atmospheric attenuation [13] to create a statistical model of the throughput and capacity for each constellation. Using this model, they estimated the total capacity relative to the capacity of the ISLs, the number of gateway antennas and the number of ground stations. Additionally, they used global census data [14] to create a demand model of the global network traffic and designed a basic genetic algorithm to determine the optimal number and placement of the ground stations. Based on the bandwidth utilization of the satellite links, the maximum system throughput and the total network capacity, they analyzed the impact of ISLs on the number of ground stations required and found that the use of ISL reduces the required number of ground stations and increases the total throughput. Since they analyze the same constellations, but use a statistical model instead of a simulation, their findings can be used to verify the validity of our simulation.

B. INTER-SATELLITE COMMUNICATIONS

One of the more prominent examples of satellite communication networks that make use of ISL is Iridium [15] and Iridium Next [16]. In these networks, only the communication between satellites with opposing directions on neighboring polar orbits requires the use of relaying ground stations.

Modern Ka-Band ISLs are capable of very high data rates of multiple gigabits per second over long communication distances. In the future these capabilities may be even further extended using optical ISL. At the time of writing, the off-the-shelf hardware required for optical ISLs in commercial applications was still uncommon [17], so our simulation focuses on ISLs using Ka-Band transmitters.

The combined use of ground relays and ISL is further investigated by Handley [10], [18]. He finds that paths using a series of space-ground links, even without ISLs, generally have a shorter delay than paths that exclusively use terrestrial networks. If the paths use ISLs, this further reduces the propagation delay, decreases the number of required ground-relays and increases the total capacity of the network. This supports the findings of Barrios et al. [9]. Handley uses his own visualization based on Unity 3D [19] to simulate and display the shortest paths inside the Starlink LEO network. The software ignores some connectivity constraints which, according to Handley, makes some east-west paths unrealistically good [20].

The statistical model of Barrios et al. [9] does not consider the effects of the protocols involved in packet routing, frequency coordination and medium access control. All three may play a significant role in how efficiently the available network capacity can be utilized and what the resulting quality of service will be. We attempt to add to their analysis through our own simulation of the effect of ISLs on existing routing protocols.

C. SPACE COMMUNICATION PROTOCOLS

The Consultative Committee for Space Data Systems (CCSDS) compiled an overview of existing space communication protocols [21]. Protocols like CFDP [22] are less relevant to LEO networks, since they are designed for reliable file transfers in scientific missions, not broadband internet connectivity.

Iridium and Geosat provide well researched examples of frequency coordination and Medium-Access Control (MAC) protocols in satellite networks. Some technical details can be found in satellite broadcasting standards such as the specification for Digital-Video-Broadcast - Satellite 2 X (DVB-S2X) [23]. A practical implementation of the predecessor of this standard, DVB-S2X, although only for a single geostationary satellite, can be found in SNS3 [24]. Finding and implementing a suitable frequency and MAC coordination algorithm for LEO mega-constellations remains a topic for future research.

In an extensive survey of available protocols, Azúza et al. [12] identified potential candidate protocols for satellite networks. Their envisioned usage scenario is a very heterogeneous, federated architecture of multiple satellite networks that communicate across a range of different technologies. For this, they compared routing protocols from many network types, including MANETs, snapshot networks, existing LEO satellite networks, multi-layered networks, WSN and Delay Tolerant Networking (DTN). They compiled a list of properties that are critical for routing protocols in satellite networks. According to them, such a protocol should be based on distance-vector routing, be adaptive to topology changes from network mobility, and support resource aware routing.

It is important to note that the federated architecture of multiple satellite networks proposed by them is very different from the architecture that is planned for the LEO megaconstellation. This loosens some requirements for candidate protocols, such as the ability to deal with a heterogeneous architecture or the support for multiple different routing protocols, but puts more emphasis on others such as the optimal distribution of available bandwidth and resources, support for mobility and minimal latency. As some possible candidates for future investigations they suggest Load-Aware On-Demand Routing (LAOR), Zone Routing Protocol (ZRP), Ad-Hoc On-Demand Distance-Vector Routing (AOMDV), Routing Protocol For Low-Power And Lossy Networks (RPL), Energy Aware Epidemic Routing (EAEpidemic) and Probabilistic Routing Protocol For Intermittently Connected Networks (PROPHET).

Our exemplary evaluation of ns-3-leo uses AODV, since it matches most of the criteria and implementations for ns-3 are already available. Later in section V, we compare the results of our preliminary evaluation to the expectations of Azúza et al. [12].

D. DISCRETE EVENT NETWORK SIMULATION

Bedon et al. [25] investigated the performance of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) when used with ISL links. They simulated a network of Cubesat satellites along one polar orbit with different traffics flows and distances between the satellites. The simulation uses SaVi, which is a visualization tool based on the now outdated ns-2. While they also simulate a LEO network, they do not consider mobility or communication between satellites on different orbits.

ns-3 is a discrete event network simulator [26]. Discrete event network simulators process events, like the transmission of a packet, the progression of a node to a different waypoint or a route expiration of a protocol timer, in the order they are scheduled using a central simulator control loop. ns-3 provides the basic components including the simulator event loop and interface definitions for network devices, channels, mobility model and routing protocols. The simulator is easily extendable using a module system, where individual modules may provide additional components. Users may build simulations by combining them with parts of ns-3 itself and other third party modules. This provides our simulation with a large framework that already includes many protocol implementations. ns-3 includes extensible tracing facilities using various types of event sources and sinks. We may also obtain Packet Captures (PCAPs) for further analysis in network protocol analyzers such as tcpdump and Wireshark [27].

Building a more accurate mobility model, requires the positions of the ground stations and satellites at any given point in time. The simulation of orbital dynamics of satellites often involves mission-planning software like FreeFlyer [28]. This software is too complex to use and not easily integrable into existing simulation tools. ns-3-leo provides both a simple mobility model based on circular orbits that encourages fast experimentation and can optionally import mobility traces from external files.

SNS-3 [24] is a sophisticated module for ns-3 that models a geostationary Digital Video Broadcast (DVB) satellite systems, including its mobility, physical-layer and link-layer. Satellite module for ns-3 (SNS-3) is not applicable to LEO satellite constellations for multiple reasons. In LEO, the satellites do not remain stationary relative to a point on the earths surface, but have a high degree of mobility. As such, the channel model has to consider the mobility of multiple satellites, which is not the case for the single geostationary satellite included in the model of SNS-3. To support multi-hop paths inside the constellation, each node must be able to regenerate the payload and update the forwarding information inside each packet it forwards. The channel-model of SNS-3 is limited to a bent-pipe design, which tightly ties the uplink and downlink transmissions to each other and does not allow any modifications to the packet by a higher protocol layer. At the same time, the channel and link-layer models of SNS-3 use very similar transmission technologies to that of LEO satellites. This is why we initially attempted to make these models useable outside of SNS-3 through code refactoring. While this would have required too much effort to be suitable, SNS-3 influenced the design of the ns-3-leo module.

OS 3 is a satellite simulator that is available as a module for OMNET ++ , another discrete event network simulator. OS 3 models the satellite positions using Simplified General Perturbations Version 4 (SGP4) [29] and includes a detailed model of the propagation loss using current weather information. One downside of SGP4 is that is requires a description of the satellite’s orbit in the form of Two-Line Element (TLE), which usually is only available for already launched satellites [30]. ns-3-leo can additionally simulate approximate circular orbits and use externally generated waypoint files. This makes it possible to simulate the orbits of satellites in the planned mega-constellations that have not been launched yet. An advantage of OS 3 is the detailed path-loss model, which our simulation does not yet include. Instead, we rely on estimates from the literature [9]. OS 3 does not model ISLs, which is necessary for a simulation of upcoming LEO networks.

(1) 统计模型 (Statistical Models)

• LEO星座架构对比: 介绍了Starlink, OneWeb和Telesat等主要LEO星座的架构异同 (如Starlink规划卫星数量最多, OneWeb第一代无ISL)
• Barrios等人的统计模型:
  • Barrios等人结合拓扑, 链路预算和大气衰减模型, 建立了一个吞吐量和容量的统计模型
  • 他们的研究发现, 使用星间链路 (ISL) 能减少所需地面站数量并提高总吞吐量
• 作为验证基准: 由于Barrios等人分析了相同的星座但使用的是统计模型而非仿真, 其结论可用来验证本文ns-3-leo仿真结果的有效性

(2) 星间通信 (Inter-Satellite Communications)

• ISL的作用: 以Iridium为例, 说明ISL允许卫星间直接通信. ISL (特别是未来的光通信) 能提供极高数据速率
• ISL的优势: ISL能减少对地面中继的依赖, 缩短传播延迟, 并增加网络总容量 (Handley的研究也支持此点).
• 本文的补充: 现有的统计模型 (如Barrios的研究) 未考虑路由协议, 频率协调和MAC层的影响. 本文旨在通过仿真填补这一空白, 具体分析ISL对现有路由协议的影响

(3) 空间通信协议 (Space Communication Protocols)

• 现有协议的局限: CCSDS的协议 (如CFDP) 主要针对科学任务的文件传输, 不适合宽带互联网
• MAC层协议: Iridium和DVB-S2X (如SNS3仿真中实现) 提供了频率协调和MAC协议的例子, 但针对LEO巨型星座的合适算法仍需研究
• 路由协议候选: 引用Azuza等人的调查, 指出LEO网络需要适应拓扑变化和资源感知的路由协议 (如距离矢量路由)
• 选择AODV的原因: 本文选择AODV作为评估对象, 因为它符合Azuza等人提出的大部分标准, 且ns-3中已有现成实现

(4) 离散事件网络仿真 (Discrete Event Network Simulation)

• 现有仿真的不足:
  • Bedon等人的仿真 (基于SaVi/ns-2) 未考虑移动性或不同轨道间的通信
  • SNS-3 (ns-3模块) 仅模拟单颗GEO卫星的弯管 (bent-pipe) 模式, 不支持LEO的高动态性和星上处理/路由
  • OS 3 (OMNET++模块) 虽然传播损耗模型详细, 但依赖TLE数据 (仅适用于已发射卫星), 且不支持ISL
• ns-3-leo的优势:
  • 基于ns-3, 利用其强大的现有协议库和扩展性
  • 提供了简单的圆形轨道移动性模型, 无需TLE即可模拟未发射的星座
  • 填补了上述工具在模拟LEO巨型星座ISL和多跳路由方面的空白

Models

In this section, we discuss the theoretical background of our mobility model of nodes inside LEO networks, and how we modeled satellite-ground and satellite-satellite interconnects.

A. COORDINATE REFERENCE FRAME

To make our mobility model usable in practical research, it was important to find a coordinate reference frame that allows us to express the positions of both ground stations and satellites with a tolerable loss of precision. Positions for ground stations, and other points on the earth’s surface, are generally provided as pairs of longitude and latitude, whereas the position of LEO satellites is often specified as their orbit’s inclination from the equatorial plane and their mean altitude from earth’s surface, or even using TLEs.

There exist a variety of coordinate systems to choose from when doing orbital calculations, the main difference between them being their point of reference. For instance, the International Celestial Reference Frame (ICRF) [31] centers around the sun, whereas many other systems such as International Terrestrial Reference Frame (ITRF) [32] have their origin at the earth’s center of mass. The center of mass aligns mostly with that determined by Galileo Terrestrial Reference Frame (WGS84) [33] and newer versions thereof. This means that orbit propagation algorithms, such as SGP4, that rely on this version of the earth’s gravitational model will produce results that can be directly translated into the ITRF and we can specify the positions of ground stations as pairs of latitude and longitude with a reasonable loss of precision. An additional advantage of the ITRF is that points on the surface of the earth (e.g., ground relays) stay fixed over time. This means only the positions of the satellites have to be kept up to date, which reducing computational demands.

We therefore use ITRF as a universal reference frame for the positions of both ground stations and satellites within the simulation.

B. MOBILITY MODEL

For the mobility model, it is necessary to know the speed, heading and current position of the satellites with sufficient accuracy to obtain precise timings for interconnect events between the ground stations and satellites and between the satellites themselves.

Using algorithms for orbit propagations like SGP4, it is possible to create a mobility model from the current orbit parameters. Up-to-date TLE data for many satellites can be obtained from Celestrak [30]. Only providing mobility models for existing satellites is insufficient for a general simulation environment for arbitrary LEO satellite constellations in which the experimentation with arbitrary satellite orbits should be possible.

Our simplified mobility model supports circular orbits in LEO based on the inclination, azimuth, and height of the satellites. This has the downside of being less precise than the propagation of the orbits with e.g., SGP4 or even more precise models such as the Hybrid Simulation Platform for Space Systems (HPS) [34], since it excludes factors such as atmospheric drag and the unevenness of the earth’s gravitational field, but it still is precise enough to accurately describe the satellites positions within a network topology. This enables the user to specify arbitrary orbits (e.g., that of not yet launched Telesat satellites) only using the orbit parameters published in the technical specifications [7]. It also has the advantage of being able to dynamically generate the positions, speed and heading at runtime, so that arbitrary spans of time can be simulated with any starting point without the loss of precision or the deterioration of the orbit.

Figure 2 shows how the position, speed, and heading of a satellite can be obtained using the height, inclination θ and azimuth φ of its orbital plane.

The velocity v of a satellite can be obtained from its height h using the gravitational mass product GM of the earth.

The norm n of an orbital plane of the satellite, which is shown in green, can be obtained by rotating the equatorial plane by the angle θ.

The progress within the orbit can then be obtained using v, and the time since the satellite last crossed the orbital plane t.

C. CHANNEL MODEL

The channel model has the task of deciding if two nodes have an opportunity to transmit data, depending on their position within the mobility model and the characteristics of the radio channel. Nodes can be either satellites or ground stations.

1) INTER-SATELLITE LINKS

Two satellites, like Sat1 and Sat3 in figure 3, have a ISL with each other if they are sufficiently close for the signal to be strong enough at the receiver and if the Line-Of-Sight (LOS) between them is not blocked by other objects, like the earth. The satellites themselves can be assumed to be small enough at such distances as not to block the LOS. To compute the LOS, we used a method for line-sphere intersection that is often used in simple ray-tracers.

Depending on the value of the discriminant of the resulting quadratic equation and the relative positions of the satellites, and any intersection points of the ray with the earth, there may or may not be a LOS.

2) SATELLITE-GROUND LINKS

For the antenna beams, as shown in Figure 3, we specify the inclination φ based on the maximum relative angle α at which a satellite is still able to communicate with a ground station and vice-versa with φ = π/2−α. φ can be obtained alongside other radio parameters from the technical specifications contained in the FCC applications [7] [6] [8] [5]. The equation for the ray cast by Sat2 to a point p1 on the surface of the earth, depending on φ and the altitude h s is

\[ p(t) = t \begin{pmatrix} 1 \\ -\tan \phi \end{pmatrix} + \begin{pmatrix} 0 \\ h_s \end{pmatrix} \]

This can be used to determine the maximum communication distance of a satellite and any ground station, again using the same line-sphere intersection.

Whether a device can receive a packet, also depends on the received power. It is given as

\[P_{RX} = P_{TX} + G_{TX} - L_{TX} - L_{FS} - L_{M} + G_{RX} - L_{RX}\]

where P TX is the transmitter power, G TX the transmitter gain, L TX the transmitter loss, L FS the free-space loss, L M the link margin, + G RX the receiver gain and L RX the receiver loss. All of these parameters can either be directly obtained from the technical specifications or as statistical estimates from the relevant literature [9].

(1) 坐标参考系 (Coordinate Reference Frame)

• 选择 ITRF: 文章选用 ITRF (国际地球参考框架) 作为通用坐标系
• 原因与优势:
  • ITRF 以地心为原点, 与 GPS 使用的 WGS84 高度对齐, 便于处理经纬度
  • 在该坐标系下, 地面站的位置是固定的, 只有卫星位置需要更新, 从而减少了仿真时的计算需求

(2) 移动性模型 (Mobility Model)

• 简化圆形轨道模型: 为了支持任意 (包括尚未发射的) LEO 星座, 作者开发了一种基于圆形轨道的简化移动模型, 而非依赖 TLE 数据的 SGP4 模型.
• 输入参数: 仅需轨道的高度, 倾角 (Inclination) 和方位角 (Azimuth)
• 优势: 虽然忽略了大气阻力等因素导致精度略低于 SGP4, 但对于网络拓扑仿真已足够精确, 且能动态生成卫星位置, 速度和航向, 支持长时间模拟且无精度衰减

(3) 信道模型 (Channel Model)

旨在根据节点位置和无线电特性判断两点间是否可以通信

• 星间链路 (Inter-Satellite Links, ISL)

  • 判定标准: 信号足够强且存在视距 (Line-Of-Sight, LOS)
  • 算法: 使用"线-球交点" (Line-Sphere Intersection) 算法 (类似光线追踪) 来判断两颗卫星之间是否被地球遮挡

• 星地链路 (Satellite-Ground Links)

  • 几何判定: 根据卫星波束的倾角 和 最大相对角度, 利用射线投射方程来确定卫星与地面的最大通信距离和视距
  • 功率判定: 通过链路预算公式计算接收功率, 综合考虑发射功率, 天线增益, 自由空间损耗和其他损耗, 以确定设备是否能成功接收数据包

Implementation

The implementation of ns-3-leo is available for the community as download: https://gitlab.ibr.cs.tu-bs.de/tschuber/ns-3leo. Besides the source code, the repository also contains useful examples on how to configure and run simulations.

We implemented the mobility model and link layer model as a module for ns-3 version 3.30, which was the newest version at the beginning of the work on the module.

ns-3 provides models with a common way to declare their interface, which contains declarations of the name, attributes, constructors, and trace sources of the model [35]. This has the advantage that all these things can be referred to their semantic names, when the user configures the simulation. An example of such a name would be the trace source for course changes on all mobility models of all nodes in the simulation, which is written to by the leo mobility model.

/NodeList/ * /$ns3::MobilityModel/CourseChange

Each component may additionally define a log component. These are primarily meant to be used for debugging and not for tracing, since traces provide better performance and allow for different log output formats. They provide direct access to the traced object and the trace sink may choose whatever output format is available to it (e.g., a plain-text file, or PCAP), while the log component always writes to the standard error output.

ns-3-leo provides these interface and logger definitions to ns-3 and includes an assortment of classes that help with setting up more complex simulation scenarios, while sacrificing nothing of the extensibility and configurability provided by the model’s interfaces.

A. NETWORK TOPOLOGY AND MOBILITY

There are generally two forms of mobility within a satellite network, the constant positions of the user-terminals and gateway stations and the continuously moving satellites, for which we implemented two mobility models. These models provide the channel models with the current position and velocity of each node and their distances to each other, depending on the simulation time.

We provide the simulation with the polar coordinates of each ground station. These are then converted into the ITRF by a custom position allocator. A set of helper classes is available to import polar coordinates from a file and insert them as ground stations into the simulation.

The first method of creating a mobility model for the satellites is by generating the positions ahead of the simulation using SGP4 and importing the waypoints into a waypoint mobility model. We provide helper classes that import the pre-generated waypoints into the simulation.

As mentioned previously in section II, we also want to be able to simulate additional satellites for which we have no orbit parameters in the form of TLE files. For this purpose, ns-3-leo contains a mobility model that provides the current position and velocity of satellites, as if they were moving on circular orbits. The model takes the altitude and inclination of the orbits as parameters. Additionally, the time interval after which the position will be recomputed can be configured. Figure 4 shows how the simulator event loop triggers periodic updates of the position stored in the mobility model.

Each satellite starts out at some position along its orbit at the beginning of the simulation. These positions are generated by the position allocator, which can be configured for each simulation through the provided helper classes. We implemented a simple position allocator that iterates through the orbits of a certain inclination and altitude and passes the position of each satellite inside the orbit and its orbit’s location to the mobility model. ns-3-leo provides helper classes that import orbit definitions from external files. It is also possible to specify them directly in the user scripts.

B. LINK-LAYER

Since the MAC algorithms and frequency coordination functions that will be used in future LEO mega-constellations are still in the process of being specified [36], we implemented the network devices only as a thin wrapper around a send-queue with no added special behavior, except that it applies the configured error model, receive power thresholds, and maximum data-rates. Since only a few parameters of the ISL and satellite-to-ground links were published, we use the maximum possible data rates [9], representing a best-case scenario. Our network device implementations can handle both unicast and broadcast traffic, since these are necessary for AODV to work. Our network device implementation also provides support for both packet captures and tracing of packets through the simulation.

Network devices transmit packets using the channels they are attached to. Each channel represents a physical medium on which the data is transmitted (e. g. from a radio frequency or a laser-light beam). We implemented two types of channels, one for the inter-satellite links and one for the space-ground links.

We show the sequence of steps involved in the transmission of a packet using our channel implementation in figure 5 and figure 6.

The satellite-to-ground channel separates the attached network devices into two sets based on their type, one for ground stations and one for satellite-to-ground links on satellites. It is important to note, that any direct communication within these two sets must be prohibited by the channel. Such communication would only occur if one satellite or ground station would enter the beam of another. Since this is verify uncommon, we purposefully exclude such cases from the channel model. This also improves the performance of the simulation, since a smaller amount of nodes has to be iterated and fewer individual transmission events need to be simulated. This is different from the simulation of a shared medium like a wireless LAN channel.

The propagation loss model determines which nodes of the two sets are reachable for each transmission. Using the method explained in the specification III, it checks first if there is a LOS between the satellite and the ground station and then whether the ground station is inside the satellite’s beam or not. For nodes that are in the LOS, the propagation loss model is then used to estimate the received signal strength. We used the statistical estimates from Barrios et al. [9] to create an approximate model of the path loss and estimated the propagation delay using the constant speed propagation delay model of ns-3.

Our implementation of the ISL channel checks if a LOS between two satellites is possible. For this it uses the line-sphere intersection between the earth and the path between each two satellites as described in section III.

(1) 总体架构与接口

• 基于 ns-3 v3.30: ns-3-leo 模块基于 ns-3 的 3.30 版本开发, 源代码已在 GitLab 开源
• 遵循 ns-3 规范:
  • 实现了标准的 ns-3 接口 (Attributes, Trace Sources 等), 允许用户通过语义名称配置仿真
  • 提供了日志组件 (Logging) 用于调试, 以及追踪系统 (Tracing) 用于获取高性能的数据输出 (如 PCAP 文件)
• 辅助类: 包含多种 Helper 类, 用于简化复杂场景的配置, 如从文件导入参数

(2) 网络拓扑与移动性 (Network Topology and Mobility)

• 地面站: 位置固定, 使用极坐标表示, 并通过自定义的位置分配器转换为 ITRF 坐标系
• 卫星移动性的两种实现方式:
  1. 基于 SGP4: 在仿真前使用 SGP4 算法生成航点 (waypoints), 并在仿真时导入
  2. 简化圆形轨道模型: 无需 TLE 文件, 仅需轨道高度和倾角即可模拟. 模型会在运行时动态计算卫星位置和速度, 支持模拟未发射的星座
• 位置更新机制: 通过仿真器的事件循环 (Event Loop) 触发周期性的位置更新

(3) 链路层与信道 (Link-Layer)

• 网络设备 (NetDevice):
  • 由于具体的 MAC 和频率协调协议尚未标准化, 网络设备实现为一个"瘦包装器" (thin wrapper), 仅包含基本的发送队列, 错误模型和功率阈值
  • 假设为最佳情况 (使用文献中的最大数据速率), 支持单播和广播 (适配 AODV 协议)
• 信道模型 (Channel):
  • 星地信道:
    • 将节点分为"地面站"和"卫星"两组, 禁止组内通信 (如地面站之间直接通信) 以提高仿真性能
    • 仅当存在视距且地面站位于卫星波束内时才允许通信
  • 星间信道 (ISL): 基于线-球交点算法判断两颗卫星之间是否存在视距 (即不被地球遮挡)
• 传播模型:
  • 使用恒定速度传播延迟模型
  • 路径损耗基于 Barrios 等人的统计估算值