Methodology

2.1 Drive Tests

We conducted two major measurement campaigns, driving 1400+ km in the non-contiguous US: Alaska (June 20-26, 2024) and Maui, HI (August 16-19, 2024), covering the major cities and vast rural areas. Additionally, we conducted a third driving trip (2800+ km) in the mainland US, from Los Angeles, CA to Omaha, NE (November 1-4, 2024), to use it as a baseline against the cellular and Starlink performance in the non-contiguous US. We note that it is inherently difficult to identify mainland regions with topography/terrain similar to those of Alaska and Hawaii. Instead, our goal was to compare the performance in the contiguous vs. non-contiguous US in two distinct area types: urban centers and large, sparsely populated, rural areas. Our selected mainland route satisfies this goal, including extensive rural segments and diverse terrains (across desert basins and mountainous regions), as well as a few major urban hubs with state-of-the-art 5G deployments (e.g., Los Angeles, Las Vegas, and Denver). We believe this combination provides a balanced and practical baseline for cross-region comparison under realistic deployment conditions. The routes of the measurement campaigns are shown in Fig. 1a.

路测活动 (Drive Tests)

• 非本土地区测量：进行了两次主要的测量活动，驾驶超过 1400 公里，覆盖阿拉斯加（2024年6月）和夏威夷茂宜岛（2024年8月），范围涵盖主要城市和广阔的农村地区 。
• 本土基准测量：在美国本土进行了第三次驾驶之旅（超过 2800 公里），路线从洛杉矶到奥马哈（2024年11月），作为对比基准 。该路线包含了具有先进 5G 部署的城市中心（如洛杉矶、拉斯维加斯、丹佛）和地广人稀的农村地区，以便在现实部署条件下进行跨区域的性能对比 。

2.2 Testbed

Our testbed is shown in Fig. 1b. We used Samsung Galaxy S24 Ultra, a state-of-the-art smartphone at the time of our measurement campaigns, as the user equipment (UE) for data collection over both cellular networks and Starlink. All our experiments were conducted with 4 UEs, each connected to a different operator (Verizon, T-Mobile, and AT&T, and Starlink), to concurrently measure the performance over all four networks. For our server-side infrastructure, we used an AWS EC2 server in Oregon for all three trips. Additionally, to evaluate the benefits of edge computing, we deployed AWS EC2 Wavelength edge servers in Los Angeles, Las Vegas, and Denver for tests done with Verizon in those cities. Note that Amazon does not offer a Wavelength server in AK or HI.

For the cellular measurements, we obtained multiple unlimited data plans from Verizon, T-Mobile, and AT&T. Note that T-Mobile in AK does not have its own infrastructure, but instead provides services by roaming partners. Additionally, while performing tests with the roaming-enabled T-Mobile service in AK, we were often rate-limited to data rates less than 1 Mbps. Therefore, we do not discuss T-Mobile’s coverage and performance in AK.

For the LEO satellite network measurements, we used a Gen 3 standard Starlink terminal with a dish router and the "Roam Unlimited" plan. The UE connects to the Starlink router via an 802.11ax 6e link. The Starlink terminal is tightly mounted flat on top of the vehicle sunroof, facing directly upward to the sky to ensure an unobstructed field of view while in motion (see Fig. 1b). This mounting approach avoids the partial blockage issues in motion observed with the older Gen 2 Standard terminal (e.g., Fig. 2 in [34]), where the unit was installed at a fixed tilted angle that could reduce visibility to satellites located behind the terminal. The terminal employs a two-dimensional phased-array antenna with the Software-Assisted Orienting technique [63], which electronically steers its beam to maintain satellite connectivity without requiring manual or mechanical adjustment. We note that we intentionally used the standard Starlink terminal combined with the Roam Unlimited personal plan, similar to another recent study [28], instead of the specialized Flat High Performance terminal and/or the unlimited mobile priority business plan. The standard terminal paired with the Roam Unlimited service plan already supports mobility at a much lower cost ($514 vs. $2,249-$4,149 with different data caps) and provides a realistic view of the performance accessible to general consumers, aligning with the purpose of our study.

实验平台 (Testbed)

• 终端设备：使用三星 Galaxy S24 Ultra 智能手机作为用户设备 (UE)，同时连接并测量四个网络（Verizon、T-Mobile、AT&T 和 Starlink）的性能 。
• 服务器设置：所有测试均使用位于俄勒冈州的 AWS EC2 服务器 。对于 Verizon 在本土城市的测试，还额外使用了部署在洛杉矶、拉斯维加斯和丹佛的 AWS Wavelength 边缘服务器（注：亚马逊在阿拉斯加或夏威夷不提供 Wavelength 服务器） 。
• Starlink 设置：使用第三代标准终端（Gen 3 Standard）和“Roam Unlimited”计划 。终端紧密平放在车顶天窗上直接朝上，以确保移动中视野无遮挡，避免了旧款终端因倾斜安装而导致的移动中部分信号受阻问题 。
• 例外情况：由于 T-Mobile 在阿拉斯加没有基础设施，仅通过漫游伙伴提供服务且速率常被限制在 1 Mbps 以下，因此本研究未讨论其在阿拉斯加的覆盖和性能 。

2.3 Experimental Methodology

All our measurements were conducted while driving within legal US highway and city speed limits, representing realistic mobility scenarios for users on the road. Throughout each driving route, we conducted a suite of tests in a round-robin fashion, including backlogged TCP DL/UL throughput tests using nuttcp, ICMP-based Ping RTT measurements, and ICMP traceroute tests. Each TCP test ran for 2 min and application layer throughput was logged every 500 ms. Each RTT test ran for 30 s and sent one ICMP packet every 200 ms.

We found that tweaking the TCP congestion control algorithm and network buffers impacts end-user performance. Fig. 2 compares the cellular and Starlink downlink throughput with the default TCP configuration (Cubic with a max network buffer of 4 MB) vs. BBR with a large network buffer of 450 MB. While the impact of the congestion control algorithm (CC) and network buffer size on the cellular network performance is minimal, we observe very poor performance of Starlink with the default configuration. Hence, we used the combination of BBR and 450 MB network buffer for all our TCP downlink tests (over both cellular and Starlink). However, since we used unrooted commercial off-the-shelf smartphones, we could not change the CC or network buffers on the UE side; as a result, for uplink tests, we used the default configuration.

Since COTS smartphones do not grant access to lower layer cellular KPIs, such as handover details or LTE/5G bands, we used Accuver XCAL Solo [5] devices, which access the Qualcomm diagnostic interface on the smartphones, allowing us to capture signaling messages between the UE and the base station and to gather lower layer KPIs essential for a comprehensive analysis of network coverage and performance. XCAL also records GPS coordinates with meter precision.

For Starlink-specific data collection, grpcurl [24] was utilized to fetch and save terminal information from gRPC APIs exposed on the router’s local network. In addition, by performing reverse DNS lookups on Starlink’s user IPs, we discovered that Starlink embeds Point-of-Presence (PoP) information in the DNS Pointer (PTR) records of the public IPs assigned to its users. For example, one such PTR record resolves to the hostname ’customer.sttlwax1.pop.starlinkisp.net’ for a user IP in Alaska. The segment ’sttlwax1’ follows the CLLI (Common Language Location Identifier) standard, which indicates that the associated PoP is located in Seattle. Leveraging this naming convention, we were able to extract the PoP locations used by Starlink over time by collecting the user IPs recorded in the TCP uplink test logs and issuing reverse DNS queries on them. We then augmented the time-series records of Starlink PoP locations with the UE’s GPS coordinates by aligning timestamps with the XCAL logs, which are used for visualization of the PoPs along each driving route in § 4.1.

实验方法 (Experimental Methodology)

• 测试流程：在法定限速驾驶过程中，以轮询方式循环进行积压的 TCP 下行/上行吞吐量测试（使用 nuttcp）、ICMP Ping RTT 测量和 Traceroute 测试
• TCP 配置：
  • 研究发现默认 TCP 配置（Cubic 拥塞控制和 4 MB 缓冲区）导致 Starlink 性能极差 (看上图. 基本上全部10 Mbps以内. 性能差的离谱)
  • 因此，下行测试统一使用 BBR 拥塞控制算法配合 450 MB 的大网络缓冲区 。由于手机未获取 Root 权限，上行测试仍使用默认配置

数据采集工具 (Data Collection Tools)

• 蜂窝网络：使用 Accuver XCAL Solo 设备访问智能手机上的高通诊断接口，捕获信令消息和底层 KPI（如 LTE/5G 频段、切换详情） 。
• Starlink：使用 grpcurl 从路由器本地网络的 gRPC API 获取终端信息 。此外，通过对记录的用户 IP 进行反向 DNS 查询来提取接入点（PoP）的位置信息（Starlink 在 DNS PTR 记录中嵌入了 PoP 位置标识，如西雅图的 'sttlwax1'）