Experiment

A. Experimental Setup

Satellite Constellation: We simulate the orbital trajectories of LEO satellites using public information from three different constellations. The Starlink constellation consists of 1,584 satellites in 72 orbitals [20], while the Kuiper constellation consists of 1296 satellites in 36 orbitals [21] and the OneWeb constellation consists of 636 satellites in 12 orbitals [22]. Based on these constellations, we have built a platform for simulating real-trace dynamics of LEO satellite constellations using skyfield [23].

System Prototype: Driven by the above platform, we have built a prototype using Open5GS [9] and UERANSIM [10] for SkyOctopus. Open5GS is a widely utilized simulator for core network implementation in 5G, while UERANSIM is employed for implementing users and base stations. Following the 5G standard protocols and signaling procedures, we have made modifications to Open5GS to realize the S-UPF and the proposed PDU session establishment process. The built prototype operates on a commercial laptop with a 2.7 GHz CPU core and 24 GB RAM.

Ground Station and User Traffic: We use 40 servers from AWS’s 29 available zones [24] as ground stations. Among these, 20 ground stations will be selected as anchor points, which means h = 20. For user traffic, we randomly generate 100 users navigating through different locations in the Atlantic Ocean. Additionally, we select 25 target servers randomly from the top 50 most visited websites globally [25].

卫星星座: 我们分别使用三种不同星座的公开信息来模拟LEO卫星的轨道轨迹。Starlink星座包含位于72个轨道的1584颗卫星[20]，Kuiper星座包含位于36个轨道的1296颗卫星[21]，而OneWeb星座则包含位于12个轨道的636颗卫星[22]。基于这些星座，我们利用skyfield [23]构建了一个用于模拟LEO卫星星座真实轨迹动态的平台。

系统原型: 由上述平台驱动，我们使用Open5GS [9]和UERANSIM [10]为SkyOctopus构建了一个原型系统。Open5GS是一个被广泛用于5G核心网实现的模拟器，而UERANSIM则用于实现用户和基站。我们遵循5G标准协议和信令流程，对Open5GS进行了修改，以实现S-UPF功能以及我们所提出的PDU会话建立流程。该原型系统运行在一台拥有2.7 GHz CPU核心和24 GB内存的商用笔记本电脑上。

地面站与用户流量: 我们使用来自AWS 29个可用区的40台服务器[24]作为地面站。在这些地面站中，将选出20个作为锚点，即 h=20。对于用户流量，我们随机生成了100个在北大西洋不同位置航行的用户。此外，我们从全球访问量前50的网站中[25]随机选择了25个作为目标服务器。

Mobile Satellite Network Schemes: We compare SkyOctopus with the following three mobile satellite network schemes to demonstrate its effectiveness in reducing latency.

• Standard refers to the standard 5G NTN architecture, which is described in II-B. In this architecture, base stations are deployed on satellites and ISLs are available. The core network assigns a unique anchor point to the user based on their registered area and maintains this assignment for the duration of the PDU session.

• Standard-GS refers to a scheme that selects the nearest ground station, meaning the core network assigns the closest anchor point to the user. User traffic is quickly transmitted to the corresponding ground station after passing through the base station on the satellite and then reaches the target server via the public network.

• Standard-SAT refers to a scheme in which anchor points are deployed in different clusters on satellites, and the user is assigned an anchor point belonging to the cluster of the satellite access point, inspired by [26]. This scheme reduces latency by deploying anchor points on satellites and shortening the distance between the base station and the anchor point.

移动卫星网络方案对比: 为了证明SkyOctopus在降低时延方面的有效性，我们将其与以下三种移动卫星网络方案进行比较

• Standard: 指标准的5G NTN架构，如II-B节所述。在此架构中，基站部署在卫星上，且星间链路（ISL）可用。核心网根据用户的注册区域为用户 分配一个唯一的锚点，并在整个PDU会话期间保持该分配不变
• Standard-GS: 指选择最近地面站的方案，即 核心网为用户分配距离其最近的锚点 。用户流量在经过卫星上的基站后，被迅速传输至相应的地面站，然后通过公共网络到达目标服务器
• Standard-SAT: 受文献[26]启发，该方案 将锚点部署在卫星上的不同簇中 ，并为用户分配一个隶属于其接入卫星所在簇的锚点。此方案通过在卫星上部署锚点并缩短基站与锚点间的距离来降低时延

Anchor Point Distribution: We compare the proposed greedy algorithm with the following two algorithms to demonstrate its effectiveness in selecting anchor point distribution.

• K-means refers to the anchor distribution algorithm based on K-means. The algorithm clusters all available ground stations using K-means and further selects the center of each cluster as the deployment location for anchor points.

• Random refers to the algorithm that selects the anchor points randomly from all available ground stations.

锚点分布算法对比: 为了证明我们所提出的贪心算法在选择锚点分布方面的有效性，我们将其与以下两种算法进行比较

• K-means: 指基于K-means的锚点分布算法。该算法使用K-means对所有可用地面站进行聚类，并进一步选择每个簇的中心作为锚点的部署位置
• Random: 指从所有可用地面站中随机选择锚点的算法

B. Experimental Results

End-to-end Latency: We compare the end-to-end latency of different schemes using different constellations, which is shown in Fig. 6. It can be observed that SkyOctopus shows superior performance in terms of end-to-end latency compared to the three other schemes in different constellations.

Specifically, Fig. 6a shows the latency in the Starlink constellation. The end-to-end latency based on SkyOctopus is 70.5ms on average, which is much shorter than the latency of 187.7ms based on the Standard scheme. Meanwhile, it is much shorter than the latency based on the two other schemes (i.e., Standard-GS and Standard-SAT), which are 120.8ms and 104.5ms, respectively. This performance can be attributed to the fact that SkyOctopus can select the optimal anchor point from multiple paths, while the other three schemes always use the path corresponding to the fixed anchor point.

Furthermore, SkyOctopus’s maximum end-to-end latency is 163.8ms, which saves 59% and 50% compared to 396.6ms of the Standard schemes and 327.9ms of the Standard-GS, respectively. This indicates that SkyOctopus can significantly reduce end-to-end latency for users in scenarios with severely circuitous routing.

We also evaluate the performance of SkyOctopus in other satellite constellations such as Kuiper and OneWeb, as demonstrated in Fig. 6b and Fig. 6c. SkyOctopus outperforms the other three schemes regardless of the type of satellite constellation. SkyOctopus primarily reduces latency by increasing the number of available anchor points, making it independent of the specific constellation. Besides, the latency exhibits a little difference in different constellations (6% on average). This can be attributed to differences in constellation configurations, such as inter-orbit and intra-orbit distances and satellite altitudes. Although OneWeb has the highest satellite altitude, it benefits from a regular constellation topology, resulting in a lower average transmission latency in the satellite network. Therefore, it performs better than the other two constellations with the same ground station distribution.

Overall, SkyOctopus reduces end-to-end latency by an average of 53% compared to the other three schemes in different satellite constellations.

端到端时延: 我们比较了不同方案在不同星座下的端到端时延，如图6所示。可以观察到，在不同星座中，与其余三种方案相比，SkyOctopus在端到端时延方面均表现出优越的性能。

具体而言，图6a展示了在Starlink星座下的时延。基于SkyOctopus的端到端时延平均为70.5毫秒，远低于基于Standard方案的187.7毫秒。同时，它也远低于另外两种方案（即Standard-GS和Standard-SAT），后者的时延分别为120.8毫秒和104.5毫秒。这一性能优势可归因于SkyOctopus能够从多条路径中选择最优的锚点，而其他三种方案总是使用对应于固定锚点的路径。

此外，SkyOctopus的最大端到端时延为163.8毫秒，与Standard方案的396.6毫秒和Standard-GS方案的327.9毫秒相比，分别节省了59%和50%。这表明，在存在严重路由迂回的场景中，SkyOctopus能够为用户显著降低端到端时延。

我们同样评估了SkyOctopus在其他卫星星座（如Kuiper和OneWeb）中的性能，如图6b和图6c所示。无论卫星星座类型如何，SkyOctopus的性能均优于其他三种方案。SkyOctopus主要通过增加可用锚点的数量来降低时延，这使其不依赖于特定的星座。此外，不同星座下的时延表现出微小差异（平均为6%）。这可归因于星座配置的不同，例如轨道间和轨道内距离以及卫星高度。尽管OneWeb的卫星高度最高，但它得益于规整的星座拓扑，使得其在卫星网络中的平均传输时延更低。因此，在相同的地面站分布下，其性能优于另外两种星座。

总体而言，在不同卫星星座中，与其他三种方案相比，SkyOctopus平均将端到端时延降低了53%

Anchor Point Selection: We recorded the latency experienced by one of the users when accessing these servers through SkyOctopus in the Starlink constellation to demonstrate the effectiveness of our anchor point selection strategy.

As shown in Fig. 7, we can see that the initially chosen anchor point based on location-based anchor selection has a 68% concordance rate, meaning that the chosen anchor point after the first path update matches the initially chosen anchor point. In the remaining 32% of non-concordance cases, the S-UPF promptly reselects anchor points for the user through the path update mechanism. In this situation, the user’s latency decreases by a maximum of 42% and an average of 21%.

The reasons for these non-concordance cases primarily include three factors. The first reason is that, although the S-UPF forwards user traffic to the anchor point closest to the target server, the shortest distance between the anchor point and the target server does not always mean the lowest end-to-end latency. On the one hand, distance is only one of the factors affecting latency. On the other hand, in some cases, the intra-network latency may be significantly higher than inter-network latency. In such scenarios, the inter-network latency represents a small proportion of the end-to-end latency. Therefore, forwarding user traffic to the anchor point closest to the target server does not always result in the lowest endto-end latency.

The second reason is the inaccurate correspondence between IP addresses and locations. This inaccuracy is influenced by the used database and its update frequency, as the accuracy of the database is challenged by various factors, such as dynamic IP address allocation and the use of proxy servers.

The third reason is the changes in network conditions along the path. Factors such as the movement of satellites, link congestion, and equipment failures can increase end-to-end latency. Some of these factors are difficult to predict, thus we introduce the path update mechanism to adjust PDRs timely.

In summary, SkyOctopus can effectively select anchor points for user traffic and make timely adjustments to mitigate increases in end-to-end latency due to various factors.

锚点选择: 我们记录了在Starlink星座中，某一个用户通过SkyOctopus访问这些服务器时所经历的时延，以证明我们锚点选择策略的有效性。

如图7所示，我们可以看到，基于位置初始选择的锚点其一致率（concordance rate）为68%，意味着在首次路径更新后选择的锚点与初始选择的锚点相匹配。在其余32%不一致的情况下，S-UPF通过路径更新机制迅速为用户重新选择了锚点。在这种情况下，用户的时延最大降幅为42%，平均降幅为21%

导致这些不一致情况的原因主要包括三个因素:

第一个原因是， 尽管S-UPF将用户流量转发至距离目标服务器最近的锚点，但锚点与目标服务器之间的最短距离并不总是意味着最低的端到端时延。

一方面，距离只是影响时延的因素之一。另一方面，在某些情况下，网内时延（intra-network latency）可能远高于网间时延（inter-network latency）。在此类场景中，网间时延在端到端时延中占比较小。因此，将用户流量转发至离目标服务器最近的锚点并不总能带来最低的端到端时延。

第二个原因是 IP地址与地理位置之间对应关系的不准确性 。这种不准确性受到所用数据库及其更新频率的影响，因为数据库的准确性受到动态IP地址分配和代理服务器使用等多种因素的挑战。

第三个原因是路径上网络状况的变化。卫星的移动、链路拥塞和设备故障等因素都可能增加端到端时延。其中一些因素难以预测，因此我们引入了路径更新机制来及时调整PDR。

综上所述，SkyOctopus能够为用户流量有效地选择锚点，并进行及时调整，以缓解各种因素导致的端到端时延增加。

PDU Session Establishment Time: Fig. 8 shows the average time of users using different PDU session establishment schemes with different numbers of anchor points and constellations. The proposed scheme saves 86% of the average time with 20 anchor points compared to the standard 3GPP NTN scheme in all constellations. Additionally, the number of anchor points has little impact on the proposed scheme (with a maximum time variation of about 13%), while the average time required by the standard scheme almost increases linearly as the number of anchor points grows.

Taking Starlink as an example (Fig. 8a), since the standard scheme always performs the insertion of each anchor point based on an already established PDU session, the interaction time of each anchor point with the core network is included in the total time, leading to an average time of 4.5s to establish a PDU session using the standard scheme with 20 anchor points. The proposed scheme achieves simultaneous interactions between the core network and multiple anchor points, meaning the time required to establish a session is mainly influenced by the longest time of all interactions, rather than all of them. Therefore, with the same number of anchor points, it only requires 713ms to establish the PDU session.

Meanwhile, the additional communication process between the S-UPF and the SMF in the proposed scheme runs in parallel with the communication process between the SMF and the base station. In most cases, the base station always establishes a connection with the S-UPF on the same satellite, and thus the time to the core network is nearly the same for both, which is another significant reason why the proposed scheme surpasses the standard scheme.

PDU会话建立时间: 图8展示了用户在不同锚点数量和星座下，使用不同PDU会话建立方案的平均时间。在所有星座中，与标准的3GPP NTN方案相比，我们提出的方案在20个锚点的情况下平均节省了86%的时间。此外，锚点的数量对我们提出的方案影响甚微（最大时间变化约13%），而标准方案所需的时间几乎随着锚点数量的增长而线性增加。

以Starlink为例（图8a），由于标准方案总是在一个已建立的PDU会话基础上逐个插入锚点，每个锚点与核心网的交互时间都被计入总时间，导致在使用标准方案和20个锚点时，建立PDU会话的平均时间为4.5秒。我们提出的方案实现了核心网与多个锚点之间的同步交互，这意味着建立会话所需的时间主要受所有交互中最长一次的时间影响，而非全部时间之和。因此，在相同锚点数量下，建立PDU会话仅需713毫秒。

同时，在我们提出的方案中，S-UPF与SMF之间额外的通信过程与SMF和基站之间的通信过程是并行运行的。在大多数情况下，基站总是与同一卫星上的S-UPF建立连接，因此两者到核心网的时间几乎相同，这是我们提出的方案超越标准方案的另一个重要原因。

Anchor Point Distribution: Furthermore, we compare the impact of different algorithms on anchor point distribution in terms of average network latency. As shown in Fig. 9, the proposed algorithm consistently achieves anchor point locations with lower average latency in various constellations. In the Starlink constellation, the proposed algorithm achieves an average latency of 67ms, while the K-means and random algorithms result in latencies of 73ms and 79ms, respectively. In the Kuiper and OneWeb constellations, there are slight differences in latencies. For the Kuiper constellation, the latencies for the proposed, K-means and random algorithms are 64ms, 70ms, and 80ms, respectively. For the OneWeb constellation, the corresponding latencies are 62ms, 67ms, and 75ms. On average, our algorithm reduces latency by 8.3% compared to the K-means algorithm and by 17.2% compared to the random algorithm.

We attribute this improvement to the fact that our proposed algorithm directly targets the optimization objective to find the optimal distribution. In contrast, the K-means algorithm attempts to find an anchor distribution that is as uniformly distributed as possible on the Earth’s surface. However, a uniform distribution does not necessarily lead to lower latency due to the uneven distribution of target services and the nonlinear relationship between geographical distance and latency.

锚点分布: 此外，我们比较了不同算法在锚点分布方面对平均网络时延的影响。如图9所示，我们提出的算法在各种星座中总能获得具有更低平均时延的锚点位置。在Starlink星座中，我们提出的算法实现了67毫秒的平均时延，而K-means和随机算法则分别导致了73毫秒和79毫秒的时延。在Kuiper和OneWeb星座中，时延存在轻微差异。对于Kuiper星座，我们提出的、K-means和随机算法的时延分别为64毫半、70毫秒和80毫秒。对于OneWeb星座，相应的时延分别为62毫秒、67毫秒和75毫秒。平均而言，与K-means算法相比，我们的算法降低了8.3%的时延，与随机算法相比则降低了17.2%

我们将这一改进归因于我们提出的算法直接针对优化目标来寻找最优分布。相比之下，K-means算法试图找到一个在地球表面尽可能均匀分布的锚点位置。然而，由于目标服务分布的不均匀以及地理距离与时延之间的非线性关系，均匀分布并不一定能带来更低的时延。