Performance Evaluation

We build a container-based ISTN simulator based on [16] as described in §III-A. We conduct experiments based on data-driven simulations to explore the following aspects about SKYCASTLE: (i) can SKYCASTLE accomplish high connection uninterrupted ratio and low latency under both user movement and high LEO dynamics? (ii) how much network- and systemlevel cost does SKYCASTLE involve at satellite anchors?

我们基于 [16] 构建了一个基于容器的 ISTN 模拟器，如 §III-A 中所述。我们基于数据驱动的模拟进行实验，以探索有关 SKYCASTLE 的以下方面：

（i）SKYCASTLE 能否在用户移动和高 LEO 动态下实现高连接不间断率和低延迟？

（ii）SKYCASTLE 在卫星锚点涉及多少网络和系统级成本？

Experiment Setup

SKYCASTLE prototype. Each satellite router builds one TCP connection with its corresponding anchor for reliable location updates. Anchors use DHCPv6 [32] to allocate addresses for users. SKYCASTLE leverages Segment Routing (SR) [33] to realize the tunnel-based and convergence-free route mechanism mentioned in §V-C. We implement SKYCASTLE’s deployment and assignment algorithms in Python. The anchor manager collects satellites’ two-line element sets (TLEs) [34] from [35] to obtain constellation deployment and satellite trajectory data.

SKYCASTLE原型。每颗卫星路由器与其对应的锚点建立一个TCP连接，用于可靠的位置更新。锚点使用DHCPv6 [32]为用户分配地址。SKYCASTLE利用分段路由（Segment Routing，SR）[33]实现了§V-C中提到的基于隧道和无汇聚的路由机制。我们在Python中实现了SKYCASTLE的部署和分配算法。锚点管理器从[35]获取卫星的两行元素集（TLE）[34]，以获取星座部署和卫星轨迹数据。

Constellation information. Our simulation is based on the public information of two different constellations. The first is a complete shell of Starlink, including 1584 satellites in 72 orbits at an altitude of 540km [26]. The second is a shell in the Kuiper constellation which plans to deploy 1296 satellites in 36 orbits at 610km altitude [36]. We also simulate scenarios with Inmarsat satellites which work at geostationary orbit and have provided commercial Internet services for airplanes [37].

星座信息。我们的模拟基于两种不同星座的公开信息。第一种是Starlink的完整外壳，包括在72个轨道上的1584颗卫星，轨道高度为540公里[26]。第二种是Kuiper星座的外壳，计划部署1296颗卫星，轨道高度为610公里[36]。我们还模拟了使用地球静止轨道的Inmarsat卫星，这些卫星为飞机提供商业互联网服务[37]。

Model-based traffic generation. For Starlink, we use geographic distribution of GSs published by [30]. Since Amazon provides complete satellite services with their global infrastructure, we consider their 12 Amazon Web Services (AWS) ground stations [38] and 105 available zones (AZs) [39] as distributed GSs for Kuiper. For users, we follow the methodology proposed in [40] which assumes 0.1% of the population in each cell (1 latitude × 1 longitude) of the Starlink availability map [41] are ISTN users. We also collect flight traces of two different airlines to mimic user mobility, one across the North Pacific and the other across the North Atlantic [42], [43]. Users in the evaluation access the Akamai content delivery network server [44] closet to each GS.

基于模型的流量生成。对于Starlink，我们使用[30]发布的地面站（GS）的地理分布。由于Amazon提供了完整的卫星服务和全球基础设施，因此我们将其12个Amazon Web Services（AWS）地面站[38]和105个可用区（AZs）[39]视为Kuiper的分布式地面站。对于用户，我们遵循[40]提出的方法，假设Starlink可用性地图[41]中每个单元格（1度纬度 × 1度经度）内的0.1%人口是ISTN用户。我们还收集了两家不同航空公司的飞行轨迹，以模拟用户的移动性，一家是横跨北太平洋，另一家是横跨北大西洋[42][43]。评估中的用户访问离各自地面站最近的Akamai内容分发网络服务器[44]。

Comparison. We compare SKYCASTLE with Reliable Extreme Mobility Management (REM) [45], ATOM [46] and Networkbased Distributed Mobility Management (NDMM) [22]. REM is designed for cellular networks based on ground anchors for user mobility. We extend REM in ISTNs by choosing a nearby GS as the anchor for mobile users. ATOM aims to select a better interface between cellular and WiFi networks for improve the quality of experience (QoE). In the evaluation of applying ATOM in ISTNs, anchors in ground stations will determine whether to forward traffic to the satellite or terrestrial networks to reduce latency. NDMM offloads the anchor functionalities to the network edge, which is considered as all satellites in the constellation. For SKYCASTLE, we limit H (i.e., the maximum extra hop as defined in §VI-A) to X+Y , where X and Y is 2 the number of orbits and satellites in per orbit, respectively.

对比。我们将SKYCASTLE与Reliable Extreme Mobility Management（REM）[45]、ATOM [46]和基于网络的分布式移动管理（NDMM）[22]进行比较。REM是为基于地面锚点的用户移动性设计的蜂窝网络方案。我们通过选择一个附近的地面站（GS）作为移动用户的锚点，将REM扩展到ISTN中。ATOM旨在选择一个更好的接口，在蜂窝和WiFi网络之间切换，以提高用户体验（QoE）。在评估ATOM应用于ISTN时，地面站中的锚点将决定是否将流量转发到卫星或地面网络，以减少延迟。NDMM将锚点功能卸载到网络边缘，所有卫星均视为星座中的锚点。对于SKYCASTLE，我们将H（即§VI-A中定义的最大额外跳数）限制为X+Y，其中X和Y分别是每个轨道上的卫星数和轨道数的2倍。

对比的产品

• SkyCastle: 本论文主角
• REM: 锚点在地面基站 (GS)
• ATOM: 地面站中的锚点将决定是否将流量转发到卫星或地面网络 (决策中心在GS)
• NDMM: 将锚点功能卸载到网络边缘 (fixed)，所有卫星均视为星座中的锚点
• Inmarsat: GEO，地球同步卫星

Connection Uninterrupted Ratio (CUR)

Figure 8a plots the CUR in different constellations. The CUR only varies from 43.2% to 79.3% for both server-to-user and user-to-server traffic in REM and ATOM, because both data packets and location update messages suffer from the frequent and long-time routing instability due to handovers happening in GSs. NDMM can significantly improve the CUR in server-to-user traffic but only reaches about 60% CUR in the user-to-server traffic. The main reason is that anchors on satellites in NDMM only manage the mobility of users and do not take into account the network location changes of GSs, thus making the user-to-server connection is also interrupted by route instability. SKYCASTLE reaches 98.7% and 99.1% of CUR in both directions of traffic. On the one hand, the location notification can be correctly and rapidly updated to the corresponding satellite anchor(s) due to stable ISL connections. On the other hand, anchors in SKYCASTLE provide convergence-free route mechanism by managing the location of network infrastructures (i.e., GSs).

图8a绘制了不同星座下的CUR。

无论是服务器到用户流量还是用户到服务器流量，在REM和ATOM中，CUR的变化仅在43.2%到79.3%之间，因为数据包和位置更新消息由于地面站（GS）发生的频繁且长期的路由不稳定而遭受影响。

NDMM可以显著提高 服务器到用户 流量的CUR，但在 用户到服务器 流量中，CUR仅达到大约60%。 主要原因是NDMM中的卫星锚点仅管理用户的移动性，而未考虑地面站网络位置的变化，因此用户到服务器的连接也受到路由不稳定的影响。

SKYCASTLE在两个方向的流量中分别达到98.7%和99.1%的CUR。一方面，由于 稳定的卫星间链路（ISL），位置通知可以正确并迅速地更新到相应的卫星锚点 。另一方面， SKYCASTLE中的锚点通过管理网络基础设施（即地面站）的位置信息提供了无汇聚路由机制 。

Figure 8b plots the CUR when users move in two different airlines. Firstly, the user-to-server CUR does not decrease significantly for all mechanisms although users are moving, because this is mainly dependent on the space-ground routing instability, which does not change because the ground stations are still fixed. Secondly, the server-to-user CUR deceases by 4.3% and 4.7% on average for REM and ATOM. The main reason is that users’ movement leads to an increase in the frequency of switching ingress satellites and ground stations (anchors), so the number of location update failures and the number of IP address changes also increase, which reduces the CUR. However, SKYCASTLE can still achieve more than 97.4% CUR because users can still connect to satellites in the same cluster during their movements, which can keep the IP address unchanged. Finally, despite the use of geostationary satellites (Inmarsat), which is stationary relative to the ground, the CUR is only 1.9% to 2.4% higher than SKYCASTLE, because the high speed of user movement still causes the change of anchor points in flight trajectories.

图8b绘制了用户在两家不同航空公司飞行时的CUR。

首先，尽管用户在移动，但所有机制中的 用户到服务器CUR 并未显著下降，因为这主要取决于空间地面路由的不稳定性，而这并未发生变化，因为地面站仍然是固定的。

其次，服务器到用户 的CUR在REM和ATOM中平均下降了4.3%和4.7%。主要原因是用户的移动导致了进入卫星和地面站（锚点）的切换频率增加，因此位置更新失败和IP地址变化的次数增加，从而降低了CUR。

然而，SKYCASTLE仍然能够实现超过97.4%的CUR，因为用户 在移动过程中仍然可以连接到同一集群中的卫星，从而保持IP地址不变 。

最后，尽管使用了地球静止卫星（Inmarsat），其相对于地面是静止的，但由于用户的高速移动，飞行轨迹的锚点变化仍会导致CUR只比SKYCASTLE高出1.9%到2.4%。

User-perceived Latency

Figure 9a plots the RTT between global users and servers in different constellations using different MM mechanisms. REM, ATOM, and NDMM all suffer from high latency due to the long distance between users and their anchors. Users in REM and ATOM naively registers with the nearest GS as the anchor, while the anchor in NDMM and SKYCASTLE is usually near the user’s path to access the server. Therefore, unwise anchor selection can lead to serious detour and increase the latency. However, NDMM suffers from a high latency tail (up to 414.56ms in Starlink and 622.72ms in Kuiper) because the distances between anchor points on satellites and users increase rapidly over time. Although anchors are also deployed on satellites, SKYCASTLE reduces the latency by up to 47.8% through changing anchors for users with a latency constraint.

图9a绘制了不同星座下使用不同移动管理机制的全球用户与服务器之间的RTT。REM、ATOM和NDMM都 由于用户与其锚点之间的长距离 而遭受了较高的延迟。

REM和ATOM中的用户天真地选择最近的地面站作为锚点，而在NDMM和SKYCASTLE中，锚点通常接近用户通往服务器的路径。

不明智的锚点选择 (REM and ATOM) 可能导致严重的绕路并增加延迟。

然而，NDMM由于 卫星上锚点与用户之间的距离随着时间的推移迅速增加，导致延迟出现严重的尾部情况 （Starlink中最高延迟为414.56ms，Kuiper中为622.72ms）。 尽管锚点也部署在卫星上，SKYCASTLE通过为具有延迟约束的用户更换锚点，将延迟降低 了最多47.8%。

Figure 9b plots the RTT while users are moving in two different airplanes using different research mechanisms and an actual commercial technique. First, compared with Inmarsat, which consists of satellites working at the geostationary orbit, Starlink and Kuiper can reduce latency significantly by using LEO satellites.

However, as the distance between the satellite anchor and the aircraft increases in NDMM, the highest latency has reaches 86.3% of the latency of using Inmarsat. SKYCASTLE can achieve the lowest latency in the airline of United 857 than other mechanisms. The maximum latency in SKYCASTLE is slightly higher than that in REM and ATOM when users are moving at the airline of Virgin Atlantic 138. The primary reason for this is the proximity of GSs to the flight trajectory, which results in a shorter distance between

图9b绘制了用户在两家不同航空公司飞行时使用不同机制的RTT。首先，与使用地球静止轨道卫星（Inmarsat）相比，Starlink和Kuiper能够显著降低延迟，因为它们使用LEO卫星。

然而，由于在NDMM中卫星锚点与飞机之间的距离逐渐增大，最大延迟达到了Inmarsat的86.3%。SKYCASTLE可以在United 857航班中实现比其他机制更低的延迟。 在Virgin Atlantic 138航班中，SKYCASTLE的最大延迟略高于REM和ATOM。主要原因是地面站靠近飞行轨迹，导致卫星锚点与飞机之间的距离较短 (REM and ATOM 的锚点都在GS，离得更近，有增益)。

Frequency of IP Address Update

Table I shows the average number of IP address changes and handovers times per hour. Firstly, SKYCASTLE can reduce IP address change frequency by up to 69.1% and 83.1% in Starlink and Kuiper compared with REM and ATOM. The reason is that the high-speed movement of users is negligible for satellites, but travels for a long distance on the ground, thus connecting to many nearby GSs and reacquiring new IP address frequently. Besides, SKYCASTLE reduces handover times by about 23.5% because users prefer connecting either to their current satellite or to new satellites within the same cluster. Users do not change IP addresses in NDMM because they always consider the initial ingress satellite as anchors, which causes latency to increase by 46.6% compared to SKYCASTLE.

表I显示了每小时的平均IP地址变化次数和切换次数。首先，与REM和ATOM相比，SKYCASTLE可以分别减少Starlink和Kuiper中IP地址变化的频率最多69.1%和83.1%。

原因是 用户的高速移动对于卫星来说影响较小，而在地面上移动则需要连接多个地面站，频繁地重新获取新IP地址 。

此外，SKYCASTLE通过减少大约23.5%的切换次数，减少了IP地址更新频率，因为用户更倾向于连接当前卫星或同一集群中的新卫星。由于 NDMM中的用户始终将初始进入的卫星视为锚点 (fixed)，因此用户不会改变IP地址，但这导致了与SKYCASTLE相比延迟增加了46.6%。

Note

SkyCastle IP切换频率降低，这是极大的优势

原因:

1. 用户的高速移动对于卫星集群内部来说影响较小 (相对静止)
2. 集群托管，用户更倾向于连接当前卫星或同一集群中的新卫星，维护IP的不变性

Cost Analysis

For evaluating more realistic system-level overhead, we also deploy various mechanisms on a Raspberry Pi 4 computer and replace a container in the simulator, which has been tested in a real space environment, to demonstrate the advantages of SKYCASTLE. Figure 10 plots the network-level and systemlevel overhead while running different mechanisms.

为了评估更现实的系统级开销，我们还将不同机制部署在一台 Raspberry Pi 4 计算机上，并替换模拟器中的容器，这在实际的空间环境中进行了测试，以展示SKYCASTLE的优势。图10绘制了运行不同机制时的网络级和系统级开销。

Figure 10a plots the control overhead required by different mobility management mechanisms, which is defined as the number of transmission hops taken by all control messages per second. We divide the control overhead into location and route management overhead. Firstly, the location management overhead of SKYCASTLE is lower than other mechanisms because of the reduction of handover times and the transmission of most update messages are limited within a cluster. Secondly, the high route management overhead of REM, ATOM, and NDMM comes from the route update messages caused by the handovers between GSs and satellites. However, in SKYCASTLE the route recovery after handovers in GSs can also be solved by the location management and route mechanism of satellite anchors without route convergence. Therefore, there is no additional route overhead in the same simulated scenario.

图10a 绘制了不同移动管理机制所需的控制开销，定义为 每秒所有控制消息的传输跳数 。我们将 控制开销分为位置和路由管理开销。

首先，SKYCASTLE的位置信息管理开销低于其他机制，因为减少了切换次数，大部分更新消息仅限于集群内部传输。

其次，REM、ATOM和NDMM的 高路由管理开销来源于地面站和卫星之间切换时路由更新消息 的产生。然而，在SKYCASTLE中，地面站切换后的路由恢复可以通过 卫星锚点 的位置信息管理和路由机制解决 ，从而避免了额外的路由开销。

Figure 10b plots the CPU usage of the Raspberry Pi 4 while running different mechanisms. In REM, ATOM, and NDMM, satellites suffer from higher CPU usage because they are required to handle route calculation and update users’ location simultaneously. Specially, in NDMM, the satellite may also act as an anchor to perform MM functions. In SKYCASTLE, as similar to NDMM, the satellite anchor needs to handle location update messages and maintain a location database. However, there is no need for frequent route calculation triggered by handovers, which significantly reduces the CPU usage.

图10b 绘制了 Raspberry Pi 4 在运行不同机制时的CPU使用率。在REM、ATOM和NDMM中，由于卫星需要同时处理路由计算和更新用户位置，因此CPU使用率较高。特别是在NDMM中，卫星可能还充当锚点来执行移动管理功能。在SKYCASTLE中，与NDMM类似，卫星锚点需要处理位置更新消息并维护位置数据库。然而，由于没有因切换而频繁进行路由计算，CPU使用率显著降低。

Note

SkyCastle优势: CPU 利用率较低 + Ctrl Msg 较少

原因:

• For CPU:
  1. 位置信息管理开销低, 因为减少了切换次数，大部分更新消息仅限于集群内部传输
  2. 地面站切换后的路由恢复可以通过 卫星锚点 的位置信息管理和路由机制解决
• For Ctrl Msg:
  • 不必因切换而频繁进行路由计算