跳转至

Measurement Campaign

In this section, we describe an overview of our mobile Starlink measurement setup and the data collection campaign.

Starlink Measurement 工具积累

  • https://github.com/clarkzjw/LEOViz

  • https://github.com/sparky8512/starlink-grpc-tools

  • https://github.com/fullstorydev/grpcurl

3.1 Methodology

Fig. 3a presents an overview of our measurement setup 2 . Our measurement setup consists of two main components: (i) Network performance metrics, and (ii) Starlink UT diagnostic information via the gRPC interface.

Latency: Starlink’s default IPv4 Carrier-Grade NAT (CGNAT) gateway at 100.64.0.1 or the corresponding IPv6 gateways are reachable via ICMP-based ping, and are commonly used to measure the latency of satellite links in Starlink networks [18]. The ICMP echo request interval is set to 10 ms. Even though the actual packet interval may vary due to the scheduling behavior of the Linux operating system, however, by recording the ICMP response timestamps with the -D option, we can correlate the round-trip time (RTT) of ICMP requests with the regular 15-second handover intervals and dynamic beam switching events.

Throughput: We use iPerf3 with UDP flows to measure the impact of regular handover and dynamic beam switching events on the throughput performance. Note that we are not aiming to saturate the Starlink link capacity to measure the maximum achievable throughput, but rather to observe the throughput variations during handover and beam switching events. Consequently, we set modest UDP target bitrates to 250 Mbps downlink on a Starlink flat panel high performance (FHP) UT. UDP flows allow us to observe the throughput variations without being affected by different TCP congestion control algorithms.

Obstruction Map: We utilize the starlink-grpc-tools 3 package and grpcurl 4 to access the gRPC interface programmatically. Note that the gRPC interface does not guarantee deterministic real-time behavior, and response times may vary. In our measurements, we retrieve obstruction maps every 0.5 seconds, which avoids overloading the UT while ensuring we capture the most current snapshot of the obstruction map, as the obstruction map is updated about every second. UT Alignment Status: The UT alignment status, as represented by the tilt angle and boresight azimuth, is obtained from the gRPC interface [1]. Recent firmware updates also enabled the retrieval of dish quaternions, which we record for accurately determining the dish’s orientation in §4. Outage Events: Starlink UT can experience outages due to various reasons, such as obstructions (OBSTRUCTED), failure to receive satellite ephemeris from the central controller (NO_SCHEDULE), unable to establish a downlink due to degraded signal quality (NO_DOWNLINK) or unable to conduct a ping test to the PoP (NO_PINGS), or is conducting a sky search before establishing a link (SKY_SEARCH). The response from the gRPC get_history method includes a list of outage events, each specifying the event’s start timestamp and duration in nanoseconds, and a boolean indicator of whether a dynamic beam switching event occurred. A comprehensive list of Starlink UT event reasons is summarized in Table 2.

Location Information: The gRPC get_location method returns the UT’s positioning information as latitude and longitude using its built-in GNSS module. An external GPS antenna, mounted alongside the UT and is connected to the measurement computer, enables the retrieval of detailed motion vectors from GPSD logs when the UT and the vehicle are in motion.

Timing Information: Each Starlink UT functions as a Stratum 1 NTP server at 192.168.100.1, allowing our time-synchronized measurements to align with the regular handover intervals at 12-27-42-57 seconds of every minute. However, it is important to note that the timing accuracy of asynchronous operations, including the response time of various gRPC calls on UT operations such as resetting the obstruction map, lacks strict real-time guarantees. Consequently, the accuracy of timing information and satellite identification result is provided on a best-effort basis.

测量架构:

  1. 网络性能指标采集
  2. 通过 gRPC 接口获取的 Starlink 终端(UT)诊断信息

alt text

  • 延迟测量:
    • 使用 ICMP ping 访问 Starlink 的 CGNAT 网关(100.64.0.1)或 IPv6 网关, 间隔设为 10ms
    • 通过记录响应时间戳, 可以将 RTT(往返时间)与常规的 15 秒切换间隔及动态波束切换事件相关联
  • 吞吐量测量:
    • 使用 iPerf3 的 UDP 流进行测量, 目标比特率设为 250 Mbps(下行), 旨在观察切换期间的吞吐量变化而非链路极限容量, 并避免 TCP 拥塞控制的干扰
  • 遮挡图采集:
    • 利用 starlink-grpc-tools 和 grpcurl 以 0.5 秒的间隔获取遮挡图快照, 以保证数据的实时性并避免设备过载
  • UT 对准状态:
    • 通过 gRPC 获取 UT 的倾斜角(tilt)和方位角(azimuth)
    • 最新的固件还支持获取四元数(quaternions), 用于更精确地确定设备朝向
  • 中断事件记录:
    • 记录多种中断类型(如 OBSTRUCTED, SKY_SEARCH, NO_DOWNLINK 等)
    • get_history 方法提供的响应中包含了事件的时间戳、持续时间以及是否发生了动态波束切换的标记
  • 位置与时间同步:
    • 位置信息: 结合 UT 内置的 GNSS 和外接 GPS 天线 获取经纬度及详细的运动矢量
    • 时间同步:
      • UT 作为 Stratum 1 NTP 服务器(192.168.100.1), 确保测量与 Starlink 全球同步的切换时间(每分钟的 12-27-42-57 秒)对齐
      • 但需注意 gRPC 操作缺乏严格的实时保证, 时间精度为 best-effort

3.2 Data Collection

We begin with a controlled experimental phase using a UT mounted on a tripod, which allows us to validate our mobility-aware satellite identification method in isolation from vehicle motion and environmental variability. Using this setup, we verify the correctness of our orientation compensation and dynamic beam-switch detection under known, repeatable conditions.

We collected vehicular data covering approximately 500 km of driving over 5 hours across rural, urban, suburban, and highway environments in the midwestern USA. For these measurements, the FHP UT (hp1_proto2) was mounted on the vehicle rooftop with a fixed 7.9°tilt, as illustrated in Fig. 3b. As a stationary reference, we also performed the same measurements using a residential UT deployed under real-world obstruction condition as shown in Fig. 1b. Note that the stationary UT model (rev3_proto2) has a smaller 110°FOV than FHP UT, and is used solely to validate identification accuracy under static obstructions rather than for throughput comparison. In this paper, we focus on identifying communicating satellites in mobility scenarios and under different obstruction conditions, utilizing the diagnostic information from the same UT to explain network performance variations, without making direct cross-comparisons between different dish models on network performance.

  • 受控实验阶段: 首先将 UT 安装在三脚架上进行测试, 在隔离车辆运动和环境干扰的情况下, 验证移动感知卫星识别方法及对准补偿算法的正确性
  • 车载移动数据:
    • 在美国中西部进行了约 5 小时、覆盖 500 公里的驾驶测试, 涵盖农村、城市、高速公路等多种环境
    • 测试使用的是高性能平板 UT (FHP), 固定倾角为 7.9°
  • 静止参考对照:
    • 使用部署在真实遮挡环境下的住宅版 UT 作为参考
    • 需注意该静止 UT 仅用于验证卫星识别的准确性, 因其硬件规格不同, 不用于吞吐量性能的直接对比