基于星链网络的实时多媒体服务：现实检测 | NOSSDAV 2023

最近，低地球轨道卫星网络（LSN）被认为是未来6G通信基础设施中高带宽和低延迟全球覆盖的关键和有前途的组成部分。SpaceX 的 Starlink 可以说是迄今为止最大、最可操作的 LSN 。Starlink 已经有了包括苛刻的多媒体应用在内的各种网络应用的实际使用。由于终端用户的反馈混合不一，目前的 LSN ，特别是 Starlink，是否已经准备好了实时多媒体仍不清楚。在本文中，我们对实时多媒体服务在 Starlink 上进行了系统的测量研究，探索它们在这种新一代网络中的运营和性能的见解。我们的研究结果表明，Starlink 可以有效地处理大多数点播和直播服务，只要配置了适当的缓冲区，但在交互式视频会议中会出现视频暂停或音频中断的问题，特别是在极端天气条件下。我们还研究了卫星切换和卫星路由策略的影响，为多媒体服务和LSN 的未来增强提供了提示。

作者： Haoyuan Zhao, Hao Fang, Feng Wang, Jiangchuan Liu
来源： NOSSDAV ’23: Proceedings of the 33rd Workshop on Network and Operating System Support for Digital Audio and VideoJune 2023Pages 43–49
论文链接： https://doi.org/10.1145/3592473.3592562
内容整理： 李冰奇

介绍

在最近几年中，低地球轨道（LEO）卫星引起了学术界和工业界的广泛关注。与高地球轨道卫星相比，特别是距离地球表面约35780公里的地球同步轨道（GEO）卫星不同，LEO卫星距离地球表面的距离约为180至2000公里，这可以大大减少空地通信延迟和增加吞吐量。由于短的轨道距离也减少了LEO卫星的覆盖范围，因此LEO卫星网络（LSN）星座被设想为提供任何地方任何时间地面用户的网络连接。全球领先的LSN服务提供商SpaceX的Starlink已经拥有3754颗运营中的LEO卫星，并雄心勃勃地计划将下一代Starlink星座最终扩展到最多30000颗卫星。这样的快速增长也使LSN成为集成到通信基础设施中走向6G及以上的关键组成部分。

已经有人在不同层面上评估和优化LSN 。LSN 大大改善带宽和延迟潜在地使更广泛的服务和应用成为可能，而这在传统的空间网络中是不可能的。最近的研究评估了不同应用程序在 Starlink 上的端到端性能，例如文件共享和Web浏览，表明 Starlink 是这些简单应用程序的可行选项。然而，高级应用程序仍需要检查。特别是，众所周知，多媒体流量主导了当前的互联网（>60%），因此了解它们在 Starlink 上的性能对于未来 LSN 的服务和网络增强至关重要。

在本文中，我们对代表性的实时多媒体服务在 Starlink 上的性能进行了系统的测量和分析，包括视频点播（VoD）、直播流和视频会议服务。我们确认当前的 Starlink 网络可以通过适当配置缓冲区支持这些典型的多媒体服务，但在交互式视频会议中会出现视频暂停或音频中断，特别是在极端天气下。我们还研究了卫星切换的影响以及卫星路由策略的演变，为多媒体服务和LSN的未来增强提供了线索。

测量概述

我们的测量从2022年12月开始，持续了4个月。我们考察了广泛的实时多媒体服务，包括视频点播、直播和视频会议（见表1）。

我们使用YouTube、Twitch和Zoom作为代表，从应用程序和网络层面分析了它们的数据。图1展示了我们的测量设置。我们在不同的位置部署了两个Starlink 天线以收集实验数据：天线 A 位于太平洋西海岸的城市地区，而天线 B 位于美国中南部的农村地区。两个天线都被精心放置以确保对天空的无遮挡视野，根据 Starlink 门户网站的报告，A 的遮挡比为0.734％，B的遮挡比为 0.029％。

由于多媒体应用程序需要大量的带宽和计算资源，我们准备了两台装有i7-12700 CPU的台式电脑，运行应用程序，并通过以太网（称为Starlink以太网）或 WiFi（称为Starlink WiFi）连接到每个天线的路由器。然后，我们通过 A 天线的路由器的300 Mbps以太网端口连接了一个 Raspberry Pi 3B+，以记录长期的 traceroute 和 ping 结果，但不会干扰运行多媒体应用程序的台式电脑。为了比较，我们使用了通过以太网连接的典型地面网络服务作为基准线（称为地面网络），其下载和上传速度高达1 Gbps。该网络的稳定性已经多次验证，以确保我们获得可靠的基准。

为了捕获应用程序级别的数据，YouTube 和 Twitch 提供了内置的视频统计监控工具（Stats for nerds和Video Stats），而Zoom则有自己的Zoom Meeting API 来检索会议的视频和网络统计信息。我们使用了一个基于Web的网络流量监视器 Ntopng ，同时跟踪了实验期间的网络层数据。ping 和 traceroute 也用于测量和分析所考虑的 LSN 的延迟模式和路由策略。Starlink 移动应用程序已被用于跟踪 Starlink 网络故障的历史记录。

测量结果分析

视频点播服务（YouTube）

为了评估视频点播服务的端到端性能，我们选择了一个典型的 4K 分辨率视频，帧率为 24 帧每秒，平均比特率为 36 Mbps。我们总共收集了约 32 个小时的测量数据，采样率为每秒一次。使用内置的监控工具 Stat for nerds 收集视频分辨率、帧丢失数量、连接速度、网络活动和缓冲状态。连接速度是实际下载速度，仅在客户端当前下载视频段时变化。网络活动表示每个样本中下载的数据量，仅在下载段时才会非零。缓冲状态以本地缓存的视频长度（以秒为单位）来衡量，这对用户的体验最为相关。为确保一致性，每个视频循环后都清除了浏览器缓存，强制客户端从服务器重新下载每个视频段。

在视频点播服务的测量过程中，我们观察到 Starlink 以太网、Starlink WiFi和地面网络的平均连接速度分别为67 Mbps、62 Mbps和381 Mbps。总体网络活动的累积分布函数（CDF）如图2所示，其中地面网络、Starlink以太网和WiFi的空闲时间分别为88％、73％和65％（即，网络活动为0）。这表明，Starlink网络需要更多时间来下载后续的视频段，并且与地面网络相比，经常出现更频繁的网络活动。然而，这些影响在缓冲区足够大的情况下可能会被很好地隐藏起来，而这通常是视频点播服务的情况。

在整个测量过程中，我们还注意到Starlink WiFi的性能与Starlink以太网非常接近。因此，在本小节的剩余部分中，我们将重点分析Starlink以太网的性能，因为它作为Starlink网络的性能上限。

图3显示了一个典型实验中缓冲区大小随时间的变化情况，其中红点表示从Starlink移动应用程序报告的网络中断，大小与中断时间成比例。显然，Starlink以太网的总体缓冲区大小约为 15 秒，而地面网络约为 25 秒，这是因为地面网络有更丰富的带宽来预取更多的段以进行每个缓冲事件。对于Starlink以太网，我们观察到中断时间的平均值约为 6.46 秒，最长的中断时间为 18 秒。这样的中断可能会对缓冲状态造成一些影响，例如在图3中可以看到两个典型的重大缓冲区下降，分别发生在00:15和01:50。然而，在视频点播服务中通常使用的大缓冲区通常足以弥补这些 Starlink 中断，并提供无缝的观看体验。

总之，我们的研究结果表明，Starlink 网络上的视频点播服务的端到端性能与传统的地面网络相当，这与先前的研究一致。然而，对于高带宽内容（例如超高清360度视频），其性能可能会显著降低，其中网络活动可能会一直发生，连接带宽大量占用。

直播流服务（Twitch）

由于直播内容和直播时间由主播控制，因此我们选择一个始终处于开启状态并且每天的直播内容也相对固定的频道11作为我们的测量目标。该直播频道具有1,920 x 1,080分辨率，帧率为35帧每秒，平均比特率约为 6 Mbps。我们以每秒一次的速率收集了约77小时的数据。内置的 Video Stats 工具提供视频分辨率、帧率、跳帧数量、缓冲区大小、到广播器的延迟（LtB）和播放比特率等信息。LtB 是指从视频内容被广播者捕获到在观看者的显示器上显示之间的时间间隔。在 Twitch 中，可以使用 Low-on-Latency（LoL）方法动态调整LtB以更好地匹配观众的网络条件，其中服务器会为那些网络条件较差的观众分配更大的 LtB，以便他们仍然可以拥有流畅的观看体验，但可能会遭受与主播通过文本聊天进行通信时更高的延迟。Twitch的整体性能如表2所示。

与Starlink以太网/ WiFi相比，地面网络具有明显的优势，除了播放比特率，这表明吞吐量不是此流源的瓶颈。图4 显示了Twitch中缓冲区大小和LtB 在一个典型的测量周期（大约2.5小时）内的变化情况。很明显，通过Starlink 以太网提供的服务比通过地面网络提供的服务遇到更多的缓冲区断流，有些断流甚至会导致流媒体暂停。幸运的是，LoL机制已经起到缓解用户体验的作用，LtB增加后，每个断流的影响都会减轻。例如，有三个严重的缓冲区断流分别在00:06、00:45和02:22消耗了所有预加载的视频内容。在每次断流之后，LtB首先初始化约为10秒，然后逐渐下降，直至稳定在比以前更高的延迟水平。值得注意的是，LtB的减少是通过以1.025倍的速度加快视频播放而实现的，据报道，这对人类来说通常是不可察觉的。更高的LtB还允许客户端预取更多的缓冲内容，并且对于未来可能的中断是可承受的。例如，在02:23，另一个长时间的中断发生在缓冲区断流之后，但是由于更大的缓冲区大小有助于减少导致空缓冲区的可能性，因此流媒体不会暂停。在直播流服务中，可用缓冲视频的长度相对于 VoD 服务来说要短得多。因此，Starlink网络中的中断更有可能清空当前缓冲区，导致流媒体冻结并直接影响用户的体验。

从图4中可以看到，一些缓冲区断流与 Starlink 手机应用程序报告的中断不符。进一步的调查发现，这些断流是由于卫星切换导致的网络抖动引起的，这将在第4节中进一步讨论。基本上，卫星切换故障或两个卫星之间的大延迟差异可能会导致短时间内的显著网络抖动，这对直播流服务非常不利。

总之，与 VoD 服务相比，Starlink 网络上的直播流服务更容易遭受严重的缓冲区断流和冻结播放。

视频会议服务（ Zoom ）

COVID-19 疫情催生了许多有关视频会议应用程序的网络性能研究。报道称，Zoom 是最受欢迎的视频会议应用程序之一，自2020年以来的流量增加了四倍。因此，我们的团队对 Starlink 网络上的 Zoom 性能进行了测量。

为了测量 Zoom 的网络性能，我们使用了 Zoom 的Zoom Meeting API，该API允许我们检索每分钟的网络指标统计数据，例如音视频的平均延迟、抖动和平均丢包率。为了确保测量的一致性，我们使用了 Zoom 的屏幕共享功能，而不是视频摄像头。这使我们能够在每个Zoom会议期间显示相同的内容，便于更好地分析性能统计数据。共享的内容是一段预先录制的分辨率为2K、帧率为 60 FPS、视频比特率为9001 kbps、音频比特率为126 kbps的视频。由于视频会议应用程序对网络连接稳定性有很高的要求，因此我们确保所有参与者在Zoom会议期间通过以太网电缆连接到网络。

在测量过程中，我们收集了超过60小时的Zoom会议数据。平均而言，当地面网络托管屏幕共享时，帧率和比特率分别为24 FPS和3649 kbps，而Starlink以太网的相应值为13 FPS和1512 kbps。以Starlink以太网为主机的屏幕共享导致帧率和比特率下降至12 FPS和1522 kbps，分别适用于Starlink以太网和地面网络。这些结果表明，在屏幕共享期间，Starlink以太网是瓶颈。比特率和帧率在时间上没有显示出明显的波动模式，因此我们的分析将集中于屏幕共享的延迟/抖动和平均音频丢失率。此外，我们对两个和三个参与者的情况进行的测量表明，网络性能没有显著差异。这是因为，根据Zoom的文档，Zoom会议中的所有参与者都将在会议期间与Zoom服务器通信，因此假设他们不在同一局域网上，每个用户的网络统计数据应独立于会议中的用户数量。

我们首先进行了一个只有一个参与者进行屏幕共享的实验。图5显示了一个典型的Zoom会议的测量结果，该会议有两个参与者，其中一个参与者使用Starlink以太网（dish A）进行视频共享，另一个参与者通过地面网络观看。从图中可以看出，地面网络的音视频延迟/抖动都非常稳定和低。相比之下，Starlink网络表现出明显的波动，特别是在持续超过1秒的网络中断期间。然而，短于0.5秒的Starlink网络中断对Zoom会议性能的影响较小。此外，我们发现与屏幕共享延迟不同，音频丢失率与 Starlink 网络中断高度相关。图5右上角显示的平均音频丢失率大部分时间保持一致，但每当发生Starlink 网络中断时，平均音频丢失率会增加，较长的网络中断会产生更高的平均音频丢失率。除了上述测量外，我们还进行了另一个实验，其中一个使用地面网络的参与者共享屏幕，而一个使用Starlink以太网的参与者观看屏幕共享。我们观察到，性能的总体模式与我们之前的发现保持一致，表明在两种情况下，参与者对 Starlink 的中断非常敏感。此外，我们发现，Starlink 以太网上行的平均延迟为61毫秒，下行的平均延迟为45毫秒。

我们还进行了一个实验，测试Zoom的多屏幕共享功能，该功能允许用户在共享屏幕的同时观看另一个用户的屏幕共享内容。我们进行了这个实验，因为我们认为它可以提供关于 Starlink 网络在同时利用上行和下行时的性能表现以及这将如何影响用户的实时视频会议体验的见解。在实验过程中，我们让两个Starlink 用户共享屏幕，并同时查看彼此的屏幕共享内容。我们的结果显示，Starlink 网络仍然可以在 Zoom 会议期间同时利用下行和上行时提供良好的网络质量。但是，如图6所示，双屏共享会话中的用户的网络延迟增加。我们猜测这是由于Starlink天线/路由器的通信能力受限，它只能同时发送或接收有限数量的数据所致。

在视频会议服务中，由于涉及到许多实时用户交互，我们还进行了一项实验，以调查 Starlink 网络对这些交互的影响。然而，这里的一个挑战是如何自动化用户交互，并使它们可重复且尽可能客观。为此，我们精心设计了一种方法，每个参与者使用两个显示器，这样他们可以在分享屏幕的同时查看彼此的屏幕共享内容。然后在每个参与者处运行一个 Python 脚本，在一个显示器上显示纯黑或纯白图像，同时检测另一个显示器上显示的颜色。一开始，两个参与者都显示白屏。然后，参与者 A 首先改变显示的颜色（例如从白色变为黑色）。如果参与者 B 检测到参与者 A 的屏幕共享上的颜色变化，参与者 B 将改变其显示颜色，然后参与者 A 会在检测到参与者 B 的颜色变化时做同样的事情。每当参与者检测到颜色变化时，脚本都会记录一个时间戳。在每个实验之前，我们使用 Windows 的官方同步时间功能，确保两个系统的时钟同步到同一个服务器。图7 比较了在地面网络和 Starlink 以太网上进行用户交互实验的结果，持续时间为 10 分钟，其中 RTT 定义为参与者 A 的屏幕更改时刻和参与者 A 检测到参与者B的屏幕更改时刻之间的持续时间。显然，与 Starlink 网络相比，地面网络具有更稳定的交互。值得注意的是，图中地面网络有两个异常值。我们进行了多次测量，每次测量都包含一个或两个异常值。

然而，表3中显示的总体统计数据表明，与 Starlink 以太网相比，地面网络更加稳定。地面网络的交互次数比Starlink网络多约 23.5％，延迟和方差更低，这表明使用 Starlink 网络的 Zoom 用户可能会遇到更少的流畅交互体验。总之，与地面网络相比，虽然 Starlink 网络上的视频会议服务可以实现相当不错的性能，但仍可能经历更高的平均延迟和抖动以及更大的网络方差。此外，与 VoD 和直播流服务相比，在这些服务中，相应的平台可以利用缓冲区来减轻 Starlink 网络不稳定性的影响，而视频会议服务通常对网络变化更加敏感。因此，使用 Starlink 进行视频会议服务的用户可能会遇到更多的帧丢失和音频中断等中断。

影响因素的观察

卫星切换

与其他网络系统相比，LSN 的一个独特特点是 LEO 卫星不与地球同步，这导致LEO卫星的相对位置随时间而变化，即使在相对短的时间内，如图1所示。然而，由于 SpaceX 几乎将天线和地面站之间的一切都隐藏起来，使其成为黑盒（例如，traceroute几乎无法获得任何有意义的路由信息），这使得研究卫星切换对多媒体服务的影响变得更加具有挑战性。为此，我们利用 ping 命令以一秒的间隔收集到地面站（GS）的 RTT 时间，并最终从天线A和天线B收集了887,628个数据点。我们的观察结果显示，RTT经常从一个稳态变为另一个稳态，只有小幅度的波动。以图8为例，从时间00:09开始，RTT保持稳定，只有小幅波动，约持续10秒，然后切换到另一个稳态，如此往复。我们还注意到，有时每个稳态的平均RTT几乎相同，这可能表明连接在两个卫星之间振荡。切换频率与 Starlink 卫星模拟器中观察到的一致，其中主要链接将大约每15秒切换到下一个最近的卫星。此外，图8中每个稳态之间的RTT差约为30ms，如果切换失败或切换到离用户天线很远的卫星，则可能更大。这种大的抖动会对多媒体服务产生严重影响，导致性能严重下降。

图9显示了三个Twitch缓冲器健康状况示例及其相应的同步 ping RTT，当 RTT 切换到下一个状态时，缓冲器掉帧可以轻松观察到。例如，在样本A中， RTT 在 01:00增加到 180ms，导致5秒的缓冲器掉帧。类似的后果也可以从样本B和C中观察到。有趣的是，在这些时间段内，Starlink 移动应用程序没有报告任何网络问题或中断，这也表明这可能是图4中非中断引起的缓冲器掉帧的原因之一。

Starlink路由策略

去年初，我们还对 Starlink网络进行了一些初步的测量，发现Starlink网络将连接到距离天线最近的地面站（GS）。然而，我们注意到本文的测量结果显示了不同的路由行为，所有数据包均被定向到一个可能与我们的天线地理上很远的GS。这可能表明自2022年末以来SpaceX已经改变了其路由策略或开始使用卫星间链路（ISLs），特别是考虑到一些Starlink用户报告他们在2022年底收到了ISL服务启用通知。

为了评估这种新的路由策略的性能，我们将当前的 traceroute 数据与2022年5月在天线A上收集的先前的 traceroute 数据进行了比较，并在图10中绘制了到不同大陆的RTT，去除了25%百分位数。显然，与去年初观察到的 RTT 相比，当前到每个目标的RTT都更大。此外，我们可以看到所有目标地的 RTT 增量相似，这表明 Starlink 可能使用了与去年初不同的路由策略。目前，新的路由策略在到GS的路径上增加了更多的延迟，这可能是由于 ISL 引起的，因为存在多个卫星上的处理延迟和排队延迟等额外开销。

天气对Starlink的影响

在我们的测量中，我们遇到了雷暴天气，对于天线 B 的区域，这对 Starlink 的网络性能产生了显著影响，导致网络中断更加频繁且持续时间更长。如图11所示，比较了雷暴天和晴天的12小时中断历史记录。它清楚地显示在雷暴天5点到6点之间有显著的网络中断，这与当天报告的极高的雷暴活动观察相符。图12进一步比较了不同长度的中断次数在雷暴天和晴天之间的差异。这种严重的中断可能会对各种多媒体服务产生重大影响，例如，Zoom 用户可能会发现他们的会议连接被中断，而在这种天气条件下，YouTube/Twitch视频可能会暂停甚至无法使用。我们还注意到，在天线 A 附近出现了多次雪天气。但是，性能变化与降雪天气之间的相关性并不是非常强，这可能是因为Starlink天线带有自动检测和融化雪的功能。此外，在我们的测量中，我们没有观察到在雨天条件下Starlink性能的显着差异。

结论

本文以 Starlink 网络为案例研究，对 LEO 卫星网络上多媒体服务的性能进行了系统的测量和分析。我们对 VoD 、直播和视频会议服务进行了为期四个月的测量，通过位于完全不同地理区域的两个 Starlink 天线收集了数据。我们的发现表明， Starlink 网络通常可以提供合理的支持多媒体服务的服务质量，尽管性能可能会因极端天气、卫星切换和路由路径变化等因素而降低。此外，这种性能下降可能会因多媒体服务类型不同而产生不同的影响，VoD 影响最小，其次是直播，视频会议最受影响，因为它具有实时用户交互。我们相信这些发现可以为未来的多媒体服务和LEO卫星网络的改进提供有用的信息。

我们将继续监测Starlink网络的性能，并探索克服 LSN 当前限制的方法。我们认为 Starlink 网络中存在可辨识模式的中断，通过利用天气和 Starlink 中断数据，我们可以训练一个模型来预测 Starlink 的中断，进一步提高网络性能。例如，通过预测网络中断，应用程序设计者可以为视频流应用程序预加载更多的视频数据缓冲，以避免视频流中断。