【NTN 卫星通信】Starlink基于终端用户的测量以及测试概述

1 概述

收集了一些starlink的资料,是基于终端侧部署在野外的一些测试以及测量结果。

2 低地球轨道卫星网络概述

低地球轨道卫星网络(lsn)被认为是即将到来的6G中真正实现全球覆盖的关键基础设施。本文介绍了我们对Starlink端到端网络特征的初步测量结果和观测结果,Starlink可以说是迄今为止最大的LSN星座。我们的研究结果证实,lsn是实现地球上无处不在的互联网覆盖的一个有希望的解决方案;然而,我们也发现星链的用户体验到更多的低吞吐量和延迟超过地面网络用户,甚至频繁中断。它的用户体验受到环境因素的严重影响,比如地形、太阳风暴、雨、云、还有温度,功耗也是如此。我们进一步分析了星链目前的弯管中继策略及其局限性,特别是跨洋航线。我们还探索了它的移动性和便携性潜力,并扩展了我们的实验从城市到偏远的荒野地区,都面临着独特的现实和文化挑战。

低地球轨道(LEO)卫星运行在距离地球表面约180公里至2000公里的地方,与传统的地球同步轨道(GEO)卫星运行在距离地球表面约35,780公里的地方相比,低地球轨道(LEO)卫星能够实现更短的延迟和更高的空间-地面通信吞吐量,尽管覆盖范围较小大量这样的近地轨道卫星,还是可以形成一个LEO卫星网络(LSN) constel,共同为地面用户提供真正覆盖全球的高质量网络服务。它被认为是即将到来的6G网络的关键基础设施。在过去的十年中,我们已经看到了LSN星座的商业部署,并迅速引起了公众的关注。OneWeb的行业领导者之一,

正在建设一个由648颗宽带卫星组成的星座,最终将扩大到7000颗。

它的竞争对手SpaceX的Starlink已经向近地轨道发射了2000多颗卫星,并已获得联邦通信委员会 (FCC)的批准,将这一数字提高到1.2万颗。FCC进一步授权Starlink在不久的将来发射7500颗第二代卫星。下一代星链星座最终可能容纳多达30,000颗卫星。

图1 图1 starlink测量场景以及工具

然而,LSN仍处于早期阶段,用户基础和用户体验有限。地球同步轨道和近地轨道卫星通信有了新的理论和仿真研究。然而,除了在论坛上的零散讨论或模拟之外,很少有深入了解大规模LSN实际性能的综合性研究。复杂和动态的拓扑结构,以及增量部署过程中产生的异构和黑盒体系结构,使出色的lsn的性能进一步复杂化。为了加速对于lsn的设计、部署和优化,系统的测量是必不可少的,尽管具有挑战性。

在本文中,我们提出了我们的初步结果和观察系统的LSN测量研究。我们关注的是Starlink网络,就卫星数量和用户数量而言,它可以说是迄今为止最大的LSN星座基地。我们对不同配置和应用程序的端到端网络特性和性能特别感兴趣。这些也是大多数互联网普通用户关注的焦点,而这正是星链所瞄准的大众消费市场。事实上,Starlink网络运营商SpaceX公司为普通终端用户提供即插即用的黑匣子服务,用户只需通过WiFi或以太网连接到Starlink路由器,而无需了解卫星通信细节和星座运行情况。因此,我们

对以下关键问题感兴趣:

•今天的星链能否达到与典型的现代地面网络为最终用户所做的相当的性能?

•终端用户感知到的星链网络服务的主要影响因素是什么?

•星链是否通过其星座实现了全球覆盖?如果没有,挑战是什么?

我们的星链测量,涉及四个部分,从2022年初开始持续了半年多。我们使用脚本自动启动各种工具和应用程序,以便与分布在全球不同地区的服务器进行通信。我们在城市和偏远的野外地区进行了实地测试,每个地区收集的样本超过300万份总记录。我们的研究结果证实,LSN是实现地球上无处不在的互联网覆盖的一种有希望的解决方案;然而,我们也发现了当前Starlink网络服务的一系列重大问题;特别是以下几点观察:

1)与地面网络相比,Starlink用户所经历的吞吐量和延迟更加动态;也有频繁的掉线。

  1. Starlink的用户体验会受到地形、太阳风暴、降雨、云层、温度等环境的严重影响,其功耗也会受到影响。

我们也对星座拓扑结构的影响感兴趣。Starlink目前采用弯管策略,而不是在卫星之间建立卫星间链路(ISLs),其中LEO卫星必须将流量中继到地面站(GS)以进行进一步路由,如图1所示。我们已经验证了弯管通常是一跳,并且在切换到地面网络之前只涉及最近的GS,而不是多个。我们分析了这一策略及其潜在的局限性,特别是跨洋航线。

我们还研究了Starlink的移动性和可携带性支持。即使吞吐量在移动过程中没有太大变化,我们的实验表明,使用Starlink的移动仍然需要更多的工作,因为中断经常发生在高延迟下。我们进一步扩展我们的实验从城市向野生偏远地区的转变,揭示了一系列关于全球覆盖的问题,包括独特的现实和文化挑战。

3 相关网络

从理论分析,到系统设计,再到实际部署,卫星通信通信已经有了许多开创性的工作。对现实世界实际系统或模拟的早期测量主要集中在地球同步轨道卫星组网。由于地面到卫星的距离,因此信号延迟是一个物理障碍,只能通过移动到近地轨道来缓解。在过去的十年中,LEO星座重新作为5G以外无处不在的互联网连接的手段受到了广泛关注。人们对低轨道卫星与地面站之间的相互作用进行了广泛的研究,星座拓扑管理,寻址和路由,以及潜在的影响环境因素,如降雨和太阳风暴。

近年来,在现实世界中出现了这样的部署,SpaceX的Starlink、OneWeb和Telesat。新闻媒体和用户论坛上有很多关于这些LSN的文章和帖子,尤其是Starlink,其中大多数都是简单的评论。

对LEO星座网络的研究在很大程度上依赖于模拟器,如Hypatia和StarPerf。它们适用于模型和设计验证,但对于如此大规模的像星链这样的复杂系统实际测量是不可替代的。我们已经看到了早期的测量,这些测量的设置相对简单,影响因素的动态有限,并且通常侧重于物理层行为。在那里最近使用Ookla的速度测试和浏览器扩展进行了测量工作。他们用Starlink测试了QUIC性能和浏览器延迟。我们的工作与他们的工作同时进行,试图从普通终端用户的角度对星链的性能进行系统的衡量。我们的测量具有更广泛的全球覆盖范围,并且考虑了视频流,偏远蛮荒的北方地区,能量消耗。

4 测量系统建立方式以及方法

4.1 Starlink网络概述

图2 starlink 网络结构

SpaceX的Starlink是最先进的近地轨道卫星网络的杰出代表,截至目前,该网络在全球范围内为40多万用户提供服务。它的系统由三个主要部分组成:低轨道卫星星座、地面站网络和用户终端。该星座目前有超过2000颗卫星在不同的LEO组,被称为壳(层)。大多数部署的卫星位于第一层,其中包含72个轨道,倾角为53°,高度为550 m,每个轨道最多可容纳22颗卫星(见图2(a))。

卫星在Ku和ka波段采用相控阵波束形成和数字处理进行数据通信。在地面上,不是直接从手机连接到卫星,而是需要一个碟子(昵称Dishy McFlatface)通过用户链接(UL)与当前可见和可访问的近地轨道卫星进行通信。然后,该碟子为本地用户设备提供服务。有两代碟子可供消费者选择:圆形的Gen 1和矩形的Gen 2。Gen 1的直径为23.2英寸,重量为7.3公斤,而Gen 2则略小(19英寸× 12英寸),重量更轻(4.2公斤),带宽更大,路由器(3x3 MU-MIMO与Gen 1中的2x2)。后者具有更好的便携性,但仍然笨重。不仅天空需要无遮挡,设置位置需要足够宽,以适应碟子的大小和任何运动所需的自我调整倾斜。由星链应用程序提供的可见性地图,可以帮助放置(如图3所示),它在调试模式下也给出了数值阻塞比。我们在测量中使用了这两个碟子,发现最终用户体验到的网络服务在很大程度上是相似的,虽然第二代似乎对TCP更友好。

它为最终用户提供了一个即插即用的Internet访问接口,该接口隐藏了上述卫星通信的技术细节。

用户套件包括三个主要的组件:碟形天线,一个以太网供电适配器,一个带WiFi和以太网端口(Gen 1)或本地设备仅WiFi (Gen 2)的路由器。每次连接到碟形天线的特定卫星将充当中继器,通过ka波段将信号中继到地面站(GS),通过GS到卫星链路(GSL)进一步连接到全球互联网,反之亦然(见图2(b))。目前,至少有65家gse位于北美,23家gse位于欧洲,其他gse分布在世界各地为了成功建立这个弯管的流量中继,GS,而且天线必须同时处于卫星的视野范围内。因此,它们的距离不应超过1000公里左右。还需要注意的是,低轨卫星在地面上的一个地点上空停留时间仅为10分钟左右;当它移出时,服务需要移交给进入该地区的新卫星(如果有的话)。Starlink已经开始了基于激光的ISL(卫星间链路)实验;然而,大规模实施要到2022年底才能实现。

4.2 测量拓扑与环境

我们在不同地点部署了4个器件,用于数据生成、通信和收集。其中三个是Gen 1(分别称为A、B、C)。一种是Gen2(简称F),它更容易携带到偏远地区。我们的实验跨越了广泛的地形,包括加拿大不列颠哥伦比亚省(BC)的主要城市,即温哥华(特别是大温哥华地区的本拿比和高贵林),有开阔的天空空间,偏远地区有陡峭的山谷或在遥远的北方(BC省的Koeye Point,靠近Starlink目前的服务边界),有沉重障碍的温带雨林等。碟子A和碟子B驻扎在本拿比,碟子C驻扎在Coqutilam,碟子F驻扎在Koeye Point。为了以最小的信号,工作负载干扰和功耗需求收集测量数据,树莓派4B(树莓派,一款基于ARM的微型电脑主板)通过以太网电缆直接连接到每个Starlink路由器,除了碟F只有WiFi接口。我们对使用亚马逊网络服务(AWS)部署的9个目标服务器进行了测量,这些服务器分布在全球各地:圣保罗、新加坡、悉尼、北加州、巴林、东京、伦敦、开普敦和孟买。整个设置如图1所示。

对于国内(加拿大)地面互联网接入可用的实验,我们使用了一台具有i7-10700KF CPU的PC和相同的AWS服务器作为com模型的基线。本文中提出的基准是在地面电缆服务上运行,最大下载速度为800 Mb/s。我们在不同的陆地上做过实验,具有类似最大速度的宽带互联网服务,并且观察到类似的基线性能。我们还使用了Emporia智能插头监控器件的即时和历史功耗。为了了解天气条件的影响,我们从温哥华港的气候站提取每小时的数据,该气象站距离碟子A大约10公里。

4.3 目标应用和测量工具

我们的测量涵盖了不同的协议和应用,从标准的Web浏览和文件传输到高需求的视频流。我们使用iperf3来测量传输层的TCP和UDP吞吐量。我们使用立方TCP作为默认值,但需要进行进一步的研究与其他比较。对于每个目标服务器,在不同的端口分别启动两个iperf3用于下载和上传,从而允许同时测量两者。我们还使用安全复制协议(SCP)将具有不同数据大小的文件双向复制到AWS。fallocate用于创建数据大小从1到300 mb不等的文件。ping和traceroute用于跟踪和分析网络路径特征和路由策略。我们使用Starlink移动应用程序和YouTube内置的工具Stats来收集相关的网络,用户和应用程序信息。我们设计了基于python的脚本来自动启动测试并收集输出数据,这些数据将公开提供。


5 城市测量:starlink与地面网络

我们从温哥华开始测量,温哥华是太平洋西海岸的一个主要城市,拥有最先进的地面互联网网络基础设施和星链覆盖。我们将天线部署在城市居民区的不同位置,周围有足够的开放空间,因此应该可以展示Starlink的最佳性能。

5.1.端到端延迟

我们测量了9个AWS区域的延迟,并研究了星链和地面网络延迟的区别。总之,我们发现星链的延迟比地面网络的平均延迟略高(10%),并且更加不稳定(见图4、5).障碍物、卫星运动和ISP路由决策是影响Starlink延迟的潜在因素。

跨区域延迟:我们可以在图4中看到Starlink和地面网络的延迟之间存在明显的差距,平均差距如表1所示。差距通常在距离地面网络1.8到22.8毫秒之间,悉尼是一个异常值(差距大3.4到43.6倍)。延迟时间明显增加,但由于地面网络也观察到这样的增长,所以碟子很可能不是罪魁祸首。这可能是由于与用户盘上的AWS服务器的连接问题(从St0到位置St1,其中上标t0和t1表示不同时间的卫星S),延迟将不断增加,直到切换到新卫星发生。仔细观察数据包级别的到达时间也证实了这一点------Starlink的抖动为0.255 ms(下载)和2.715 ms(上传),两者都比地面网络高5倍以上(分别为0.041 ms下载和0.546 ms上传)。

5.2 端到端吞吐量

如图8所示,Starlink实现了良好的吞吐量(平均约80 Mb/s),但仍然缺乏稳定性。Starlink和地面网络的吞吐量标准差分别为50.71%和34.44%。这种变化很可能是由于卫星运动和不断变化的网络路径,以及从Starlink网络经过后潜在的低成本地面网络路由。对于UDP测量,我们逐渐增加iperf3传输流量,直到路径饱和。Starlink实现的吞吐量在所有地区都是相似的(见表2)。这表明要么是天线的跳是物理瓶颈,要么是UL或GSL的流量工程应用于该跳。后者可能是根本原因,因为IV-D3中的结果表明,吞吐量可能会受到限制功耗控制。我们还观察到突发数据包的丢失比地面网络高得多。这种损失不一定是由拥塞引起的,因为我们在低UDP吞吐量实验中也观察到它们。对于当前吞吐量的20%,这是很低的,足以缓解数据包丢失的拥塞因素,我们仍然看到下载和上传的平均突发损失分别为0.24%和1.24%。这与早期的卫星通信模拟研究结果一致。有趣的是,12小时左右也有一个周期。每个周期的平均值和峰值不同,但每个周期各区域的平均值和峰值相似,损耗最有可能发生在弯管上,特别是UL,这将在我们在第IV-C节中对路由策略的分析中进一步研究。


对于TCP通信,Starlink在拥塞控制方面比地面网络遇到了更多的问题。我们的研究结果表明,Starlink的带宽利用率为39.0%,明显低于地面网络的46.8%,这表明TCP的拥塞控制对卫星跳中的动态非常敏感。与城市中的第一代天线相比,较新的第二代天线可以优化TCP上传,吞吐量提高1.76倍。不幸的是,UDP上传没有看到类似的增长,就吞吐量而言,它是第一代碟的0.73倍。这表明TCP上传的改进可能是由于更新后的碟子中更优化的访问方法或修改后的路由器设计。

我们也研究了通过SCP传输大量数据。如图9所示,与地面网络相比,随着数据量的增长,Starlink传输时间的上升趋势更强,方差也更大。虽然有由于SCP开销,1mb数据大小几乎没有差异,与地面网络相比,Starlink上的SCP传输时间几乎是200mb数据大小的两倍。这表明卫星跳的网络动态随着时间的推移而积累,因此放大了与SCP中较大的数据量。

5.3 路由策略

我们的traceroute测量结果表明,Starlink网络只沿路线进行一次弯管通信(例如,第一次UL和GSL),然后进入地面网络到达目的地,反之亦然。在我们的实验中,无论目的地在哪里,星链网络都将始终连接到离天线地理位置最近的GS。在路由切换到地面ISP之前,我们只看到一个位于离天线最近的GS的SpaceX服务ISP入口。尽我们最大的努力,到目前为止我们还没有找到Starlink使用L2路由的参考。如图6所示,这些地区,尤其是悉尼、圣保罗和伦敦,具有类似的Starlink网络延迟模式。我们使用所有区域之间的Pearson相关性来进一步分析这一点图10中的相关矩阵显示,天线通信的所有区域都具有中等相关性,进一步表明它们具有中等相关性类似的延迟模式。尽管与不同地区通信,但两项观测都表明使用了类似的卫星、GSes和路线。换句话说,这种单弯管道体系结构不参与路由策略,只是作为桥接到Internet(或Internet)的第一跳,最后一跳(如果星链用户是目的地)。否则,考虑到伦敦离美国东部更近,我们的测量位置(太平洋西海岸)的流量在切换到地面网络之前,应该通过Starlink使用多个弯曲管道传输路由到美国东部的GSes,这应该降低了与其他的相关性

与伦敦方向不同的地区,如加州北部、悉尼和东京。不幸的是,目前情况并非如此,因为图10所示的相关性是中等的。

到目前为止,我们的讨论仅限于一端是星链用户的情况。当星链成为一项无处不在的互联网服务时,通常情况下,两个网络端点都将是碟子用户。理想情况下,人们会期望,当两个附近的碟子都在卫星的服务区域内时,它们可以使用卫星来点对点交换数据,中继各自的ul,而无需通过gsl或其他地面互联网节点。为了验证这一点,我们将碟子A和B放在一起,试图将它们直接连接起来。不幸的是,我们发现在这个设置中,Starlink只允许ssh连接。事实上,Starlink阻止用户在典型路由器中编辑更高级的功能,如端口转发。最后,必须使用外部代理,例如通过remote.it。为Starlink定制,设置外部AWS服务器作为公共代理。吞吐量平均为2-3 Mb/s。峰值达到9- 12mb /s;然而,27%的吞吐量读取值完全为零。显然,基于隧道的解决方案还不能很好地工作,需要改进成对的天线通信。

5.4 环境影响因素

1)障碍物,Starlink应用程序提供了天线当前位置的天空可见度图(图3),以及障碍物状态。后者只能在应用程序的调试模式中通过受阻状态→当前受阻和分数受阻看到。本文将该分数称为障碍物比,它并不总是与能见度图相关。制作初始地图大约需要12-24小时,但障碍物比率更频繁地更新,以捕捉实时动态,例如,覆盖在蝶子上的落叶。我们发现,即使一个位置有很好的能见度地图,由于外来物体造成的短暂阻塞也会导致延迟峰值甚至网络中断,这意味着天线对表面obstructions.12简而言之,星链的终端用户既需要晴朗的天空,也需要干净的天线,才能实现最佳性能。

2)太阳和地磁风暴,Starlink的吞吐量会受到太阳和地磁风暴的严重影响。太阳风暴,或日冕物质抛射(CME),是指来自太阳的大量磁化粒子向特定方向抛射,例如向地球抛射,这可能与地球磁场相互作用,我们发现,在2022年2月3日和4日期间,该天线的吞吐量从100 Mb/s急剧下降到5 Mb/s。与此同时发生了两件事:2月3日,SpaceX向太空发射了49颗卫星;2月4日,一场地球/电磁风暴迫使40颗卫星重新进入地球大气层。风暴可能强烈干扰了UL/GSL,类似于GPS无线电波受到先前地磁风暴引起的大气变化的影响。另一个原因可能是卫星星座可能处于较不可靠的维护模式,导致通信能力差。有趣的是,上传似乎没有受到影响,因为吞吐量保持相对稳定。这意味着当面对这样的风暴时,两个方向是不对称的,这可能是一个重要的因素,在整合星链和地面网络基础设施时需要考虑的问题。

3)降水、温度和天线功率:我们观察到,Starlink的吞吐量会受到天气的显著影响。结果表明,与降水和温度相比,吞吐量呈负相关。

在任何降水期间,吞吐量平均下降27%(详见图11)。我们还发现,吞吐量受到大雨(> 4毫米每小时)的限制下载比上传受到的影响更大,UDP下载的最大负相关为0.34。例如,UDP下载在没有沉淀的情况下平均为215mb /s,在4.1到5.2 mm沉淀的情况下几乎减半到120mb /s左右。降雨衰减可能是吞吐量下降的罪魁祸首,因为Ka和ku波段无线电波在降雨中会受到严重影响。此外,云的形成在天空中也可能中断与卫星的数据通信。众所周知,即使是轻云也会对卫星信号强度产生10%左右的影响。厚厚的云层通常伴随着强降雨,进一步阻塞了ULs和GSLs的网络路径。


Starlink碟子没有主动冷却机制,只能通过铝背板被动冷却,16在夏季或热带地区使用时,这可能是一个重大挑战。使用Emporia智能插头,我们发现当前洗碗机的平均功耗约为56.3瓦,但最高可达144.5瓦。这比先前报道的平均105瓦和最大190瓦的测量值要低得多。这种节能很可能是通过固件优化来实现的,因为碟子的形状因素保持不变同样,它当然有助于热量控制。作为2022年12月19日至20日夜间本那比暴风雪期间的额外实验,Starlink进入融雪模式10小时,使其平均功耗增加到146.3瓦,最大功耗为188.6瓦。如果星链

在寒冷和多雪的气候中使用时,用户必须小心,因为这个碟子需要更多的能量来融化可能积聚的雪。但是,如果用户有其他方法可以使星链远离雪,则可以在星链应用程序中关闭此功能。

由于碟子套件是一个黑盒子,我们不能直接测量单个模块的功耗。但是,我们比较了功耗和吞吐量,发现它们之间没有明显的相关性,这与更高的吞吐量需要更多的功率的直觉形成对比。事实上,在某些情况下,我们已经看到它们在上传和下载方面呈负相关。这些

建议天线不必进一步放大信号以获得更高的吞吐量,并且天线可以节流最大可实现吞吐量以控制功耗。考虑表2中的总结,它是最高的。在我们的实验中,TCP的平均吞吐量大约是下载108mb /s,上传6mb /s;然而,之前在奥地利进行的一项实验观察到两个方向的吞吐量都要高得多:下载175 Mb/s。这可能是由于障碍物和覆盖范围的差异;然而,星链软件更新以降低功耗可能也影响了吞吐量为了验证这一猜想,需要在相同的环境中进行更新的未来测量。

另一方面,如图12所示,天线的功耗与降水相关。在没有下雨的情况下,功耗通常较低,偶尔会由于其他因素(如调整天线方向或与更远的卫星建立UL)而出现峰值。当有雨或多云时,耗电量会持续增加更高,可能是为了应对雨水或云层的干扰。

6 星链在野外

服务偏远地区一直是卫星通信系统的重点目标,特别是星链。我们在这些具有挑战性的环境中进行了一系列测量,这些环境没有地面互联网覆盖,甚至没有蜂窝或电力服务。我们现在给出两种情况的结果代表:一个河口在遥远的北方,一个深谷被陡峭的山脉包围。

A.北海岸线

从温哥华到河口(Koeye Point),如图13(b)所示,需要2小时的飞行到北部的贝拉贝拉,然后沿着太平洋海岸线乘坐2小时的摩托艇。

我们此行是为了一个与生物学家和Heiltsuk当地人合作的项目,目的是保护鲑鱼和森林。构建通信服务在项目中起着重要的作用。我们的测试是基于图13(a)中所示的碟F,这是一种更容易在飞机上携带的Gen 2。

我们住在Koeye Point的简易小屋是由Heiltsuk人建造的。在太平洋海岸线附近,天空晴朗,没有障碍物。光污染很低,可以清晰地看到卫星(100%)和在上面轨道运行的空间站。不幸的是,尽管这个位置最近被Starlink覆盖,Dish F可以用于简单的日常应用,但它的下载吞吐量比城市中的低68%左右,延迟时间比城市中的长11%到30%,并且不时出现中断。这可能是由于较少的卫星和gse能够覆盖北部地区(如图7所示)以及第一层壳的倾角限制。因此,寻找下一颗卫星进行交接并建立GSL和UL需要更多的努力。

B.高海拔深谷

我们的第二个测试在不列颠哥伦比亚省曼宁公园中心,如图14所示,海拔1000米左右的地形崎岖,周围环绕着海拔2000多米的山脉。距离温哥华3小时车程,基本上没有蜂窝网络覆盖,更不用说互联网接入了。我们开着车把碟子C带到了现场,并打开了便携选项,这样碟子就可以在它原来注册的位置之外使用。

尽管这个山谷直到2023年底才正式由Starlink提供服务,如图15,18所示,我们能够在没有拒绝的情况下连接到卫星,尽管服务很差。不同区域的平均延迟从90-350毫秒不等,波动幅度在1,000毫秒以上。吞吐量是下载和上传的平均速度分别为13 Mb/s和4 Mb/s,偶尔会达到100 Mb/s和20 Mb/s。每1-3分钟就会发生一次频繁的中断,尽管该应用报告的阻塞率只有2%。考虑到地形,我们认为任何低轨道卫星,如果不是在正上方,都会被山脉阻挡。山谷内清晰的短距离能见度会误导App的算法计算障碍物。事实上,C碟曾经被放置在城市的阳台上,但它的最终用户,遭受了24.9%的阻碍率。这表明位置(尤其是地形)扮演着重要的角色,并不是所有的障碍物都等同于最终用户的体验。随着更多卫星的部署和山谷的正式服务,服务质量将得到改善,即使不能达到平坦开阔地区的水平。值得注意的是,这两个偏远地区还没有接入电网,在不久的将来也不会接入电网。因此,我们必须依靠河口的太阳能-柴油混合动力系统和山谷的电池组。考虑到目前Starlink套件的功耗,一个典型的1500 Ah电源组只能持续大约1小时。

7 进一步讨论

A.弯管的稳定性

我们早期的实验表明,尽管弯管在吞吐量方面相当好,但在通信中往往不稳定。为了仔细检查其稳定性,我们在超高分辨率8K (7,680 x 4,320像素)YouTube视频的连续流下进行了压力测试我们将两个天线(A和B)放置在同一颗卫星的覆盖范围平均值内的附近位置。换句话说,它们共享相同的GSL,但具有各自的UL。然后我们在YouTube上表演流媒体同步传输给它们,每个都连接到PC上播放视频。通过循环播放视频,同步流媒体会话可以持续24小时以上。

每次播放后都会清理浏览器缓冲区,以确保连续下载数据。我们使用一个脚本自动抓取YouTube的内置工具Stats,以获取实时数据统计,包括连接速度、网络活动和缓冲区健康。这里的缓冲区运行状况表示预加载视频内容的长度(以秒为单位)对网络中断很敏感,与观看者的感知质量直接相关。

从图16可以看出,在这次同步测试中,两个天线都经历了一系列的缓冲中断,其中一些是重叠的。例如,两对缓冲中断同时发生在01:18和03:26,以及他们的星链应用程序都同时报告了网络中断。重叠的故障表明可能有一个共同的因素,弯曲的管道,导致它们在两个盘子之间。表格。III总结了停机事件,从中我们可以确认,不可忽略的停机事件数量是由它们的弯曲管道引起的(a超过37.5%,B超过15.79%)。数据还显示,Dish A在流媒体中比B更稳定,这可能是因为它有更清晰的可见性。B碟周围有更多的树,因此Starlink应用程序报告的a碟和B碟的阻塞率分别为2.7%和4.7%。因此,即使在同一业务区域,不同的星联用户体验到的UL质量也可能不同,从而影响网络服务质量。

B.移动潜力

美国联邦通信委员会(FCC)最近授权Starlink互联网在行驶中的车辆上使用,尽管它尚未得到Starlink的全面支持。因此,我们在这个阶段进行了一个简短的测试,以评估让Starlink为完全的动态连接做好准备所需的工作利用碟子的便携性,我们将碟子C用两个横梁固定在一辆小型货车的车顶行李架上(见图17)

选项正在打开。在我们30分钟的测试中,这辆车以40至70公里/小时的速度在三条不同的行驶路线上行驶,其间有曲折,然后在接近终点时完全停止。大多数时候,天线都是平对天空的,有一些小小的自我调整。注意,盘子在固定设置是大部分都向一个方向倾斜。因此,天线可能会感应到运动,并相应地调整平面位置,这对全方位接收效果最好。

目前的星链天线可以在运动中工作,但要与目前的固定装置相匹配,还有很长的路要走。我们观察到每16.5秒中断一次,有些每162秒中断一次,持续时间长达36秒(第95个百分位数)。如图18所示,延迟平均为100 ms,最高为2,800 ms,在20:42。超过200 ms的延迟峰值平均每分钟至少出现两次,最高可达8次。这经常会中断需要低于200毫秒才能获得满意体验的应用程序。考虑到我们之前讨论过的固定天线平均在50毫秒左右,移动时的延迟很高波动。这些延迟的增加可能是由于汽车转弯时突然改变方向或树木经过时的间歇性障碍物。例如,右转发生在20:40左右,这与大约同一时间的延迟急剧上升相吻合。下载吞吐量达到了与静态测试相似的平均值,大约在80到100 Mb/s之间,但在接近结束时立即下降,如图19所示。有趣的是,上传吞吐量能够保持在5到10mb /s左右,与固定设置相当。两者都在20:58左右观察到明显的下降,可能是由于与卫星断开连接。在过去的6分钟里,大部分时间都是在山谷里直线行驶,这表明天线可能被迫比预期更快地切换卫星。

请注意,Starlink套件通常需要3-7分钟才能启动并准备好上网,但我们观察到的情况超过20分钟。如此长的时间将成为手机使用的障碍。

8 全球覆盖、技术及文化影响

为了实现真正的全球覆盖,需要更多的星链卫星,包括覆盖北极和南极的其他外壳。我们的偏远地区实验是在北极圈以南14°(北纬66°34)进行的,这几乎已经超出了北美目前的服务区域。为了实现有效的跨大陆通信和灾害发生在地球表面附近时的可靠运行,还必须启用卫星间的连接。即使这些技术问题最终会被克服,在我们深入河口上游大熊温带雨林的实地考察中,我们也意识到许多挑战,我们计划在海尔图克原住民重建的堰附近安装一个Starlink天线,用于捕鱼器及其监测系统(如图20(b)所示)。

实际的挑战包括清理、野生动物和电力。如图20(a)所示,这些古老的树木有30米高,唯一晴朗的天空是在河边的堰边,那里容易被洪水淹没。熊、狼和鸟类等野生动物很容易越过狭窄的堰,破坏盘子。事实上,一百种截然不同在科伊流域发现了个体灰熊。此外,在这样一个偏远的森林深处地区,太阳能是唯一可用的电力来源(柴油发电机是不允许的,也不实用)。因此,间歇性运行是不可避免的,因为如果它不进入融雪模式,则需要最大145瓦的功率。

文化挑战更为复杂,这是我们在实地考察之前没有考虑到的。Koeye河及其周围的温带雨林是Heiltsuk原住民的圣地,他们的传统大房子就在这里。那里的人们带来了他们与传统价值观的冲突。信号污染包含了更多关于priis 时间荒野的哲学思想,随着世界上越来越多的地方被连接起来,越来越少的地方将成为逃避持续连接的地方。如今光污染是众所周知的,低轨道卫星星座带来的全球覆盖会带来另一种不可见电磁波的污染,WiFi污染。这不是在技术方面,而是在社会方面。这是和我们一起工作的生物学家最关心的问题。事实上,在真实中野生的个体必须时刻保持警惕,并且大多要照顾好自己;因此,使用移动应用程序的分心会掩盖保持联系的好处。因此,对于即将到来的全球互联网在地球和空间的覆盖,迫切需要跨不同学科和文化的政策、专业准则和道德规范。

9 结论以及未来的工作

本文从终端用户的角度介绍了我们对今天星链网络特性的初步测量。从我们的研究中发现的许多问题不仅局限于星链,而且在lsn中很常见。因此,我们的观察将有助于优化LSN的部署和运营,也将帮助开发人员和用户定制他们的网络和应用。

LSN服务正在迅速发展,因此我们将继续监控Starlink互联网服务的性能发展。例如,在未来的实验中,天气或云对Starlink的影响可以进一步扩展为降雨概率和云衰减模式。

它们可以包括考虑到天气衰减概率并采取相应行动以提供不间断服务的优化方法。对于弯管的稳定性,未来可以通过在每个房屋的屋顶上安装碟形天线来进行重复实验,以减轻阻力比的变化。

我们也对即将到来的新功能的有效性感兴趣,例如,卫星到卫星链接,多个弯管和移动支持,仅举几例。我们还对LSN与地面互联网和5G蜂窝网络的无缝集成,以实现真正的全球覆盖率和相关的跨学科问题感兴趣。

10 参考文献

1、Network Characteristics of LEO Satellite Constellations:

A Starlink-Based Measurement from End Users

相关推荐
孤蓬&听雨1 天前
Kafka自动生产消息软件(自动化测试Kafka)
分布式·kafka·自动化·测试·生产者
帅得不敢出门5 天前
Python+Appium+Pytest+Allure自动化测试框架-安装篇
python·appium·自动化·pytest·测试·allure
陈明勇6 天前
自动化测试在 Go 开源库中的应用与实践
后端·go·测试
帅得不敢出门6 天前
Python+Appium+Pytest+Allure自动化测试框架-代码篇
python·appium·自动化·pytest·测试·allure
Dylanioucn7 天前
《解锁 TDD 魔法:高效软件开发的利器》
后端·功能测试·测试·测试驱动开发·tdd
北京_宏哥8 天前
《最新出炉》系列入门篇-Python+Playwright自动化测试-41-录制视频
前端·python·测试
努力的小雨9 天前
新手入门Java自动化测试的利器:Selenium WebDriver
后端·测试
周珂呀11 天前
Linux 命令行学习:数据流控制、文本处理、文件管理与自动化脚本 (第二天)
linux·前端·chrome·操作系统·终端·基础知识
画江湖Test14 天前
pytest 单元框架里,前置条件
python·自动化·pytest·测试·1024程序员节
城下秋草19 天前
AI测试之 TestGPT
测试工具·单元测试·ai编程·测试