Quantitative Performance Analysis of Deploying Mobile Anchors in ISTNs

Given the unique characteristics of futuristic ISTNs and the basic principles of network-layer MM approaches above, we thus ask the question: how should satellite operators deploy MM solutions in their ISTNs to sustain good user experience under both LEO dynamics and user movements?

Analysis Experiment Setup

We start our quest by quantitatively analyzing the attainable performance of directly applying existing MM solutions in ISTNs. We build an ISTN simulator based on [16], an open-source simulation tool for satellite networks. The ISTN simulator can: (i) mimic the LEO dynamics as well as the corresponding network behaviors (e.g., link connection/disconnection); and (ii) run routing protocols in simulated routers (i.e., satellites and GSs) and (iii) load different MM approaches. Specifically, we simulate an ISTN based on the public information of the first shell of Starlink [26], with 1584 LEO satellites in the well-known +Grid topology [27]–[29] and about 200 distributed GSs [30]. Each satellite connects to the two front and rear satellites in the same orbit and two left and right satellites in its adjacent orbits to construct a gird-like structure.

Metrics. Ideally, an MM approach should accomplish: (i) seamless handover, which indicates that the connection interruption time should be short during handovers; and (ii) low latency, i.e., the user perceived latency after handovers is expected to be limited in an acceptable range. Accordingly, we consider two key performance metrics: (i) end-to-end connection uninterrupted ratio (CUR), which is defined as the percentage of time that the network connection between the server and user is available, and (ii) round-trip time (RTT).

我们从对现有移动性管理（MM）解决方案在ISTN中直接应用的可达性能进行定量分析开始。我们基于一个用于卫星网络的开源模拟工具，建立了一个ISTN模拟器。该ISTN模拟器可以：（i）模拟LEO动态以及相应的网络行为（例如链路连接/断开）；（ii）在模拟的路由器（即卫星和地面站GSs）中运行路由协议；以及（iii）加载不同的MM方法。具体来说，我们模拟了一个基于 Starlink Shell 1 公开信息的ISTN，采用1584颗LEO卫星，采用著名的+Grid拓扑结构，以及约200个分布式地面站。每颗卫星连接到同一轨道中的前后两颗卫星和相邻轨道中的左右两颗卫星，以构建网格状结构。

指标 理想情况下，一个MM方法应该实现：

（i）无缝切换，即在切换过程中连接中断时间应尽可能短；

（ii）低延迟，即切换后用户感知的延迟应在可接受的范围内

因此，我们考虑两个关键的性能指标：

（i）端到端连接不中断比率（CUR），定义为服务器与用户之间的网络连接可用时间的百分比；

（ii）往返时间（RTT）

Deploying Anchors at GSs Suffers from Frequent and Long Connection Interruptions

A straightforward approach of applying existing MM approaches in ISTNs is to deploy anchors at some fixed nodes in the terrestrial network (e.g., at GSs), as shown in Figure 3a. In this case, a mobile user (e.g., airplane) registers with an anchor at a nearby GS. When the user changes their location, the satellite to which the user connects (i.e., the ingress satellite) sends notifications to notify the anchor where the user is. Traffic from the server is first forwarded to the GS anchor of the user and then to the user’s ingress satellite, and finally to the user.

Observations. Figure 4a and 4b plot the end-to-end CUR and RTTs when anchors are deployed at GSs. Our experiment results reveal that deploying anchors on GSs can result in poor network continuity. As shown in Figure 4a, The server-to-user CUR is only 79% on average, indicating that the connection is unavailable for at least 20% of the entire session.

Root cause. On our in-depth analysis, we find that the low connection uninterrupted ratio is caused by the routing instability between users’ ingress satellites and corresponding anchors at GSs due to space-ground handovers. As LEO satellites move, the ISTN topology changes frequently, which results in routing fluctuations and temporal route unreachability. As shown in Figure 3a, after the handover, the route from the ingress satellite to GS needs to be recalculated. During this routing convergence period, the location update may fail and the GS does not know the latest location of the user. Consequently, the server cannot correctly send traffic to the mobile user.

在GSs部署锚点会导致频繁且长时间的连接中断

在ISTN中应用现有移动性管理（MM）方法的一种直接方法是将锚点部署在陆地网络中的某些固定节点上（例如在地面站GSs），如图3a所示。在这种情况下，移动用户（例如飞机）在附近的地面站的锚点上注册。当用户改变其位置时，用户连接的卫星（即入口卫星）发送通知以告知锚点用户的位置。来自服务器的流量首先被转发到用户的地面站锚点，然后到用户的入口卫星，最后到达用户。

观察 图4a和4b显示了当锚点部署在GSs时的端到端连接不中断比率（CUR）和往返时间（RTTs）。我们的实验结果表明，在GSs部署锚点会导致网络连续性较差。如图4a所示，服务器到用户的CUR仅为79%的平均值，表明连接在整个会话中至少有20%的时间不可用。

根本原因 在深入分析中，我们发现低连接不中断比率是由用户入口卫星与地面站锚点之间的路由不稳定性引起的，这是由于空间-地面切换所致。随着LEO卫星的移动，ISTN拓扑结构频繁变化，从而导致路由波动和临时路由不可达。如图3a所示，在切换后，从入口卫星到GS的路由需要重新计算。在此路由收敛期间，位置更新可能会失败，GS无法获得用户的最新位置。因此，服务器无法正确地将流量发送给移动用户。

如果照搬现行的陆地NetAnchor会怎样

现行：GS 作为 Anchor

问题：

GS与“连接它”的卫星之间连接不稳定，经常做切换 ->

路由不稳定、在重计算的过程中消息缺失 ->

在路由尚未恢复稳定之前，user的location等信息没法被anchor获取 ->

server cannot correctly send traffic to the mobile user

Deploying Anchors at Satellites is Latency-limited

Another viable path to tackle mobility is to deploy anchors at access points for distributed mobility management [22], i.e., deploying anchors at the ingress satellites. As shown in Figure 3b, in this case, each satellite works not only as a router to forward network traffic, but also as an anchor to manage the location and handover of users that register with it.

另一种可行的方法是通过在接入点部署锚点来实现分布式移动性管理，即 在入口卫星上部署锚点 。如图3b所示，在这种情况下，每颗卫星不仅作为路由器来转发网络流量，还作为锚点来管理注册到它的用户的位置和切换。

Observations. Figure 4a and 4b plots the end-to-end CUR and RTTs when users choose their initial ingress satellite as the anchor. We observe that deploying anchors on satellites can significantly improve the server-to-user CUR, but it still suffers from high user-perceived RTTs. Figure 4c plots the RTTs changing over time. As users roam around the world and satellites move around the earth, we observe that the RTT can increase by about 100ms over a period of 25 minutes.

Root cause. While LEO satellites move at a high velocity relative to the earth’s surface, the relative positions of the front/rear satellites in the same orbit, and those of the left/right satellites in adjacent orbits, can remain stable [27], because they operate at the same orbital altitude and move at the same velocity. Therefore, although the routes from satellites to GSs suffer from instability, the routes between satellites are relatively stable due to fixed inter-satellite topology. As a result, when anchor points are deployed at satellites, the ingress satellite can always correctly and efficiently update users’ location to the anchor. In this case, packets are sent from the GS to satellite anchor firstly, and then forwarded to the user’s latest ingress satellite according to anchor’s location information. Note that although the optimal path from the GS to the satellite anchor also needs to be recalculated, the GS can send packets to any satellite it is currently connected to. This satellite always maintains a stable and valid route to the satellite anchor, ensuring that there is an available route from the GS to the anchor. However, the latency can significantly increase as both the anchor and the user move at a high velocity, which prolongs the user-to-anchor path.

观察。图4a和4b显示了当用户选择其初始入口卫星作为锚点时的端到端连接不中断比率（CUR）和往返时间（RTTs）。

我们观察到， 在卫星上部署锚点可以显著提高服务器到用户的CUR，但仍然存在高用户感知RTTs的问题 。

图4c显示了RTTs随时间的变化。随着用户在全球范围内漫游和卫星绕地球移动，我们观察到RTT在25分钟内可能增加约100毫秒。

根本原因。虽然LEO卫星相对于地球表面以高速移动，但同一轨道中的前后卫星以及相邻轨道中的左右卫星之间的相对位置可以保持稳定，因为它们在相同的轨道高度上运行并以相同的速度移动。

因此，尽管从卫星到GSs的路由存在不稳定性，但由于固定的星间拓扑，卫星之间的路由相对稳定。因此，当在卫星上部署锚点时，入口卫星可以始终正确高效地将用户的位置更新到锚点。

在这种情况下， 数据包首先从GS发送到卫星锚点，然后根据锚点的位置信息转发到用户的最新入口卫星 。注意，尽管从GS到卫星锚点的最优路径也需要重新计算，但GS可以将数据包发送到它当前连接的任何卫星。该卫星始终保持到卫星锚点的稳定有效路由，确保从GS到锚点存在可用的路由。然而， 由于锚点和用户都以高速移动，延迟会显著增加，从而延长用户到锚点的路径 。

让卫星成为Anchor会怎样

每颗卫星的角色：

1. 信息负载，负责路由
2. 具备做“Anchor”的能力，轮到就能上

好处:

1. user -> ingress satellite -> satellite anchor
   • 这条路全部稳定，相对静止的拓扑
   • "连接不稳定，经常做切换"的问题彻底规避
2. 步骤: pkt from terrestrial network ->
   • GS (by GSL) ->
   • Satellite Anchor (relative one, by ISL) ->
   • Ingress Satellite ->
   • User ✅

固有的弊端:

user对应的ingress satellite 和 Satellite Anchor 距离可能会被拉远，导致 user2anchor 延迟会增加

(latency can significantly increase as both the anchor and the user move at a high velocity, which prolongs the user-to-anchor path.)

Takeaways

In addition to the above analysis, our observations from Figure 4a indicate that all current MM mechanisms achieve only about 50% of the user-to-server CUR. The primary reason for this is that the routing instability, as mentioned above, not only leads to the failure of location updates but also causes interruptions in the data traffic from users to servers. Therefore, our quantitative analysis exposes the problems and challenges of conducting mobility management in ISTNs as follows.

除了上述分析之外，我们从图4a的观察中发现，所有当前的移动性管理（MM）机制仅实现了用户到服务器的连接不中断比率（CUR）约为50%。其主要原因是，如前所述，路由不稳定性不仅导致位置更新失败，还会引起用户到服务器的数据流量中断。因此，我们的定量分析揭示了在ISTN中进行移动性管理的以下问题和挑战：

• Since emerging ISTNs will provide Internet services for mobile customers such as airplanes and cruise users in motion, it should be important to effectively manage mobility and keep connections active during handovers in ISTNs.

• The key of MM is to leverage an anchor point to track user’s time-varying location and forward network traffic. However, naively deploying anchors either suffers from long connection interruption time (e.g., deploying anchors at GSs), or can result in high latency (e.g., deploying anchors at satellites).

• Our in-depth analysis reveals that the root cause for the above inefficiency is that current MM approaches only consider the user-level mobility but ignore the unique infrastructure-level mobility in an ISTN environment, which results in routing instability and long latency between users and anchors.

• 新兴ISTN将为移动客户（如飞机和游轮用户）提供互联网服务，因此在ISTN中有效管理移动性并在切换过程中保持连接活跃至关重要。

• MM的关键是利用锚点来跟踪用户随时间变化的位置并转发网络流量。然而，简单地部署锚点要么会导致长时间的连接中断（例如，在GSs部署锚点），要么会导致高延迟（例如，在卫星上部署锚点）。

• 我们的深入分析揭示了上述低效的根本原因是，当前的MM方法仅考虑用户层面的移动性，而忽略了ISTN环境中的独特的基础设施层移动性，从而导致用户与锚点之间的路由不稳定性和长延迟。