Measuring Mobile Starlink Performance: A Comprehensive Look

Received 21 January 2025; accepted 5 February 2025. Date of publication 7 February 2025; date of current version 24 February 2025. Digital Object Identifier 10.1109/OJCOMS.2025.3539836 Measuring Mobile Starlink Performance: A Comprehensive Look DOMINIC LANIEWSKI (Graduate Student Member, IEEE), ERIC LANFER , (Graduate Student Member, IEEE), AND NILS ASCHENBRUCK , (Member, IEEE) Institute of Computer Science, Osnabrück University, 49069 Osnabrück, Germany CORRESPONDING AUTHOR: D. LANIEWSKI (e-mail: [email protected]) This work was supported in part by the German Federal Ministry for Digital and Transport as part of the “Innovative Network Technologies” Funding Program under Grant FKZ: 19OI23008C. ABSTRACT With the recent success of Low Earth Orbit (LEO) satellite networks, such as SpaceX’s Starlink, measuring their performance has been of great interest to the community. While stationary Starlink performance has been extensively assessed on a globalized view, mobile - in-motion - usage is relatively new. A first look at its performance has only been taken by three studies so far. In this paper, we take a comprehensive look at mobile Starlink performance from the measurement perspective by answering the following three research questions: (1) How does mobile Starlink performance differ in different regions of the world? (2) How does the mobile performance compare to stationary performance? (3) How does obstruction impact mobile performance? To answer these questions, we conduct our own 300 km long test-drive on the German Autobahn (highway) with car velocities up to 140 km/h. We compare our results to the datasets of the other three studies and to stationary measurements. To the best of our knowledge, we are the first to deeper analyze the impact of obstructions on the performance. For this, we map bridges crossing the highway to our measurements and find that these short total obstructions cause significant burst packet loss, RTT spikes, and throughput drops. We show that mobility-induced instabilities can have a severe negative impact on the performance of higher-level applications such as HTTP bulk file transfer. INDEX TERMS Dataset, flat high performance, LEO, LEO measurement, measurement, mobility, satellite communication, Starlink, Starlink dataset, Starlink measurement, Starlink mobility. I. INTRODUCTION LOW EARTH Orbit (LEO) satellite networks are an emerging technology that promises to provide highspeed broadband Internet to remote and underserved areas world-wide. There are multiple projects to build such networks. While some projects, such as Amazon’s Kuiper and Telesat’s Lightspeed, are in early development phases and scheduled to be operational in 2025 [16] and 2027 [36], respectively, other projects, such as SpaceX’s Starlink, Iridium and Eutelsat’s OneWeb are already available to the public. With 6,218 operational satellites as of January 2025 [25],Starlink is the largest LEO-ISP to-date. Starlink was initially designed for stationary use. Users connect to the satellite via a special terminal - called the “dish” - that is typically mounted on rooftops of buildings with clear view of the sky. In late 2022, the Flat High Performance (FHP) dish was introduced, designed to be mounted on vehicles such as cars and boats and to be operated while in-motion. Over the years, the research community has assessed stationary Starlink Performance in many measurement studies in vastly different measurement scenarios and locations from all over the world [14],[21], [24],[26]. In contrast, only three measurement studies mounted the FHP dish on a car and assessed in-motion Starlink performance in the U.S. [10], in the Arctic region of northern Sweden [4], and in a city in Western Germany [20]. In this paper, we aim to take a comprehensive look at mobile Starlink performance from the measurement perspective by answering the following research questions (RQ): 1) How does mobile Starlink performance differ in different regions of the world? c 2025 The Authors. This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ 1266 VOLUME 6, 2025 2) How does the mobile performance compare to stationary performance? 3) How does obstruction impact mobile performance? To answer these questions, we conduct our own mobile Starlink measurement campaign in an approximately 300 km long test drive on the German Autobahn (highway) in the north-west of Germany close to the Dutch border. We compare our results to the publicly available datasets from the U.S. [10], the Arctic [4], and a German city [20] to answer RQ1. To answer RQ2, we conduct a second, stationary measurement campaign and compare the results to our highway measurements. The campaign spans one week and consists of two stationary “Standard Gen 2” dishes running different service plans and an FHP dish placed directly next to each other on the rooftop of a building with an unobstructed view of the sky. In this context, we also analyze the impact of different Starlink dish versions and service plans on the performance. Additionally, we map bridges crossing the highway to our measurement results to answer RQ3. We then build an emulation of our test drive that accurately reproduces the experienced link conditions and use it to analyze the impact of mobilityinduced instabilities on real-world applications. Both of our measurement campaigns contain all relevant network parameters such as downlink and uplink throughput, the RTT, and packet loss. We release our datasets and our emulation as open access data to the community [19]. The rest of this paper is structured as follows. First, we introduce relevant background knowledge about Starlink in Section II and discuss related work in Section III. Then, we describe our mobile measurement campaign in Section IV. Afterward, we answer the research questions in Sections V–VII, respectively. We then discuss the impact of the found Starlink instabilities under mobility on real-world applications in Section VIII. Finally, we discuss limitations of our work in Section IX and present interesting future research directions in Section Xbefore we conclude our paper in Section XI. II. BACKGROUND Starlink opened to the public in 2020, initially designed only for stationary use. Users mount a satellite antenna (the “dish”) to places with an unobstructed view of the sky, such as rooftops of residential buildings. The antenna connects to a satellite that is in its field of view (FOV). The satellite also connects to a ground station (GS). This connection (dish - satellite - GS) is called the one-hop bent pipe. It is the predominant architecture in most regions of the world. If no GS is in the FOV of the satellite, satellites of version 1.5 and newer can connect to other satellites forming inter-satellite links (ISL) using laser communication. This architecture is called a multi-hop bent pipe. It is primarily used to connect more remote regions of the world. The GS is connected to the terrestrial network via a hierarchical point of presence (POP) structure. As of January 2025, Starlink operates 6,218 satellites at orbits of four inclinations: 43◦,53 ◦,70 ◦, and 97.6◦. These orbits vary in satellite densities. 2,137 satellites are operational on the 43◦orbit, 3,468 on the 53◦orbit, 384 on the 70◦orbit, and 229 on the 97.6◦orbit [25]. While the 43◦ and 53◦orbits provide service for most regions of the world, the 70◦and 97.6◦orbits are primarily used to connect the poles. SpaceX offers different dishes for stationary and mobile use. Three generations (Gen 1 - Gen 3) of the Standard dish for stationary use have been released. The Gen 2 dish can align itself to the optimal angle to track satellites due to a built-in motor, it has an average power consumption of 50 - 75 W, and a FOV of 100◦[33]. The Gen 3 dish doesn’t have a motor, it has a higher average power consumption of 75 - 100 W, and a larger FOV of 110◦[34]. In contrast, the FHP dish is designed for mobile use-cases. It can be mounted, e.g., on a car or a boat. It doesn’t have a motor, it has an average power consumption of 110 - 150 W, and a FOV of 140◦[31]. A service plan needs to be booked to operate a dish. Currently (as of January 2025), Starlink offers three categories: Residential,Roam, and Mobile [32].TheResidential service plan is bound to a fixed location. It is typically used with a Standard dish to provide consumer-level Internet at home. The generated traffic has a medium prioritization in the Starlink network. The Roam service plan is primarily designed for stationary use-cases with changing locations, such as camping. However, it also supports in-motion usage. Its data has the lowest priority of all service plans. The Mobile service plan is designed for in-motion use, e.g., on cars and boats. It includes 50 GB or 1 TB monthly priority traffic. This traffic enjoys the highest prioritization of all service plans. Once the included data volume is used up, an unlimited amount of Residential traffic can be used. While all service plans can be booked on the Standard dishes, the FHP dish requires the Mobile plan. III. RELATED WORK Stationary Starlink Performance has been extensively assessed via real-world measurements in recent studies [9], [11],[14],[21],[24],[26],[27]. These range from smallscale studies consisting of a single Starlink dish [9],[26] to large-scale measurement campaigns spanning multiple months and consisting of multiple dishes distributed over different countries [11],[14],[21],[24],[27]. In contrast, measurement studies of mobile Starlink performance are limited. In a first attempt, López et al. [23] mounted a standard Gen-1 terminal, designed for stationary residential use, on a car. They measured latency in a 250 km long test drive in northern Denmark with velocities up to 15 km/h. Ma et al. [24] also mounted a standard Gen1 terminal on a van and measured uplink and downlink performance in a 30 minute test drive in south-western Canada at velocities of 40-70 km/h. In total, three studies assessed mobile Starlink Performance using an FHP dish VOLUME 6, 2025 1267 LANIEWSKI et al.: MEASURING MOBILE STARLINK PERFORMANCE: A COMPREHENSIVE LOOK FIGURE 1. The FHP dish mounted on a VW van. mounted on a car [4],[10],[20]. All of them made their datasets publicly available. A detailed comparison is given in Section Vand especially in Tab. 1.Huetal.[10] mount a stationary Gen-2 dish and an FHP dish on a car and conduct a 1,800 km test drive across the U.S. with velocities up to 100 km/h and measure TCP and UDP throughput, latency, and packet loss. They also compare the performance of the Roam and Mobile service plans. Beckman et al. [4] measure TCP downlink throughput and latency in a 970 km test drive across the arctic circle in northern Sweden. Their velocity was typically in the range of 80-100 km/h. Laniewski et al. [20] build an autonomous measurement setup that automatically starts/ends the measurements when the car is turned on/off. They deploy it on a service car of the local energy provider in the city of Osnabrück, Germany, over a span of two months and measure UDP throughput, latency, and packet loss. The measurements are mainly conducted in the city at velocities around 50 km/h, but also contain a short highway measurement at 120 km/h. All the mentioned mobile measurement studies [4],[10],[20] only take a first look at mobile Starlink performance by analyzing their own measurements. A globalized view, which is the current trend in the stationary case, is lacking. Furthermore, a detailed comparison between mobile and stationary performance is lacking. A first look is only provided by Laniewski et al. [20]. Lastly, the impact of obstruction on Starlink performance has not yet been analyzed in neither the stationary nor the mobile cases. We aim to fill these gaps by answering our research questions in this paper. IV. THE HIGHWAY MEASUREMENT CAMPAIGN In this section, we describe our highway measurement campaign. A. THE PHYSICAL MEASUREMENT SETUP We mount the FHP dish on the roof of a Volkswagen (VW) van (Fig. 1). It is powered by a Jackery Explorer 2000 Pro power station with a capacity of 2 kWh. The FIGURE 2. Our test drive route from Osnabrück, Germany, along the Dutch border up to Bunde, close to the German North Sea. The route is driven both ways. network measurements (throughput, latency, and packet loss) are conducted on a laptop (AMD Ryzen 7 PRO 4750 U, 16 GB RAM) that is connected via Gigabit Ethernet to the Starlink router, which is set into bypass mode.TheMobile service plan with 50 GB priority traffic is booked for the dish. Our measurements were conducted using only non-priority (standard) traffic. B. THE MEASUREMENT CAMPAIGN We conduct a 300 km test drive starting in the city center of Osnabrück, Germany, over the A 30 highway and then further on the A 31 highway close to the Dutch border to Bunde. Afterward, we drive the same way back. The selected route has multiple unique features, making it an ideal route for answering our research questions. First, there are no speed limitations, allowing measurements at high car velocities. Second, the generally sparse traffic allows keeping high velocities for extended time periods. Third, the terrain ensures an optimal, unobstructed view of the sky for the Starlink dish, as it is flat and there are no large objects in direct proximity to the road possibly causing obstruction, such as forests or large buildings. Obstruction is only caused by bridges crossing the highway, allowing an isolated analysis of their impact on the measured performance. Fourth, the area around the route is sparsely populated, minimizing variations in Starlink performance possibly caused by other users producing load-fluctuations within the same service cells of the satellites. Lastly, the route is in between the cities of Osnabrück and Enschede, guaranteeing spatial proximity and consequently allowing great comparability to related Starlink measurements conducted from those cities [20],[21]. 1268 VOLUME 6, 2025 TABLE 1. Comparison of the different mobile Starlink measurement campaigns. We drove the car at velocities of 80, 100, 120, and 140 km/h for approximately 10 minutes straight. We aimed to drive approximately the same velocities at the same highway sections on both ways. As the van didn’t have cruise control and as we had to consider the traffic situation, the velocities within those sections varied slightly. The route and car velocities are visualized in Fig. 2. The test drive took place on the evening of the 19 th of April 2024, approximately from 18 h to 23 h. This avoids the evening rush hour on the highway. Earlier studies [18],[21],[24] found that weather conditions can significantly impact Starlink performance. Heavy rain with precipitation levels >4mm/h and cloudiness can reduce the UDP downlink throughput by up to 30-45 % and 5 %, respectively [18],[21],[24]. Other weather conditions, such as wind speed, temperature, humidity, and solar radiation, were found to have no impact [21]. The uplink throughput, RTT, and packet loss are generally unaffected by the weather [21]. We use three weather stations of the German Meteorological Service (DWD) close to our driving route to monitor the weather: Osnabrück-Belm (station ID: 342), Lingen (station ID: 15813), and Dörpen (station ID: 6159). The approximate locations are also marked in Fig. 2. Overall, it was a rainy and cloudy day with total precipitations between 0 h and 18 h of 17.2 mm, 12.9 mm, and 10.6 mm in Osnabrück-Belm, Lingen, and Dörpen, respectively. During the test drive, there was 0.37 mm precipitation between 18:10 h and 18:40 h in OsnabrückBelm, 0.09 mm between 18:00 h and 18:50 h in Lingen, and no precipitation in Dörpen. Even though these are low precipitation levels during the test drive, the heavier precipitation earlier that day led to a wet road causing whirled water by preceding cars, potentially impacting the Starlink performance. C. MEASUREMENT DETAILS On the way to Bunde, we continuously measured UDP throughput using iperf3 (Version 3.9) against a server located in the network operating center of the local university. The server is connected to the 5 Gbit/s fiber university network. We measured downlink and uplink throughput in parallel using two separate iperf instances to avoid CPU limitations of iperf’s bidirectional mode [21]. Target data rates of 500 Mbit/s for the downlink and 100 Mbit/s for the uplink were used to saturate the links. Since iperf was running constantly, the data was collected at one-second granularity. On the way back to Osnabrück, we measured the RTT and packet loss using the ping utility with the Starlink gateway as destination and inter-packet spacings of 10 ms. Precisely, we used the following command: ping − D−i0.01 100.64.0.1. During the complete test drive, we measured the GPS locations and vehicle velocities using the app GPS Tracks (Version 4.4.9) running on an iPhone 13 with iOS 17.4.1. V. MOBILE PERFORMANCE IN DIFFERENT WORLD REGIONS In this section, we answer RQ1: How does mobile Starlink performance differ in different regions of the world? We do this by comparing the results of our highway test drive to existing datasets from the U.S. [10], the Arctic [4], and Starlink on the road from Osnabrück city, Germany [20].For this, we first give an overview of the measurement campaigns and explain relevant differences. Afterward, we analyze the throughput, packet loss, and the impact of the vehicle speed on the performance. Lastly, we summarize our findings. A. MEASUREMENT CAMPAIGN COMPARISON Tab. 1summarizes the details of the different measurement campaigns. For simplicity and better comparability, we refer to our measurement campaign as GER-Highway,tothe campaign of Laniewski et al. [20] as GER-City,tothe campaign of Hu et al. [10] as U.S., and to the campaign of Beckman et al. [4] as Arctic. Our GER-Highway campaign is highlighted. We see that the campaigns differ vastly. They were conducted over a time span of one year in different regions VOLUME 6, 2025 1269 LANIEWSKI et al.: MEASURING MOBILE STARLINK PERFORMANCE: A COMPREHENSIVE LOOK FIGURE 3. Throughput distributions of the different datasets. “n” denotes the number of samples per dataset. FIGURE 4. Burst lengths. of the world, in different terrains, and under different weather conditions. Moreover, the measurement setups and measurement processes were significantly different. For example, the measurement device was connected to the dish via different technologies (Ethernet vs. WLAN), the latency measurements were conducted against different targets (bentpipe vs. full-path latency) and at different granularities, and different transport protocols were used for the throughput measurements (TCP vs. UDP). All these factors can possibly impact the measurement results, limiting direct comparability of the datasets. Because of the vast differences in the latency measurements, we focus our analysis on the throughput and packet loss. B. THROUGHPUT The distribution of the downlink throughput is visualized in Fig. 3(a) as violin plots and box plots. The GER-City dataset has the highest median throughput, followed GER-Highway, the Arctic, and the U.S. with medians of 263, 218, 186, and 134 Mbit/s, respectively. Their 95 % confidence intervals (CIs) do not overlap, indicating statistical significance. Their standard deviations (std) are comparable with 94, 104, 77, and 90 Mbit/s, respectively. The violin plots reveal that the U.S. dataset has a large cluster of samples at 0 Mbit/s, accounting for approximately 15 % of the total samples. This behavior is unique and can have different causes such as instabilities in the measurement setup, bad satellite coverage, or frequent obstruction. The remaining samples of the U.S. dataset are nearly evenly distributed between approximately 50 Mbit/s and 250 Mbit/s with a small cluster around 160 Mbit/s. The GER-City and Arctic datasets show a comparable sample distribution. Both show a small cluster around the third quartile, which is approximately located at 310 Mbit/s and 220 Mbits, respectively. In contrast, the distribution of the samples of our GER-Highway dataset approximately follows a normal distribution between 450 Mbit/s and 0 Mbit/s. The uplink throughput distribution is depicted by Fig. 3(b).1The median throughput is 14.9 Mbit/s, 15.4 Mbit/s, and 18 Mbit/s with stds of 10.2 Mbit/s, 8.6 Mbit/s, and 14.4 Mbit/s for our GER-Highway dataset, the GER-city dataset, and the U.S. dataset, respectively. The 95 % CIs of the medians overlap for the GER-Highway and GER-City datasets. While this indicates a similar uplink performance in cities and on the highway in Central Europe, it also shows a better performance in the U.S. The violin plots reveal the reason for this observation. The samples of our GER-Highway dataset, as well as the GER-city dataset, follow approximately a normal distribution between 0 Mbit/s and 40 Mbit/s with clusters around 15-18 Mbit/s. In contrast, the samples of the U.S. dataset are clustered around 9 Mbit/s, 28 Mbit/s, and 48 Mbit/s. The dataset does not contain samples in the range of 35-40 Mbit/s and around 25 Mbit/s. Interpretation: The observed behaviors have different root causes. The Arctic is served only by the 97.6◦orbit [4], which is populated by fewer satellites. This, in combination with the different measurement setup using multiple parallel TCP connections to saturate the link, likely leads to the worst downlink throughput compared to the measurements from GER-City and our GER-Highway test drive. The U.S. and Europe are both served by the 53◦,70 ◦, and 97.6◦ orbits, resulting in a higher satellite density. The significantly worse downlink throughput in the U.S. can be caused by a higher load caused by more customers or by worse coverage of ground stations. The differences in the downlink throughput between the GER-City dataset and our GERHighway measurements are striking, since both use a similar measurement setup and similar measurement tools. This is likely caused by the rainy weather conditions. In previous, stationary measurements [21], it was found that rain causes 1The Arctic dataset is not visualized, because it does not contain uplink throughput measurements, as indicated by Tab. 1. 1270 VOLUME 6, 2025 FIGURE 5. Throughput categorized into speed buckets. Sample sizes per speed bucket (from left to right, nsamples in braces): Downlink: <70: [722;2920;18028;12733], 70 −90: [754;103;4544;13148], 90 −100: [1309;46;5441;16909], 110 −130: [1535;30;1280;136], ≥130: [541]; Uplink: <70: [722;2920;4623], 70 −90: [754;103;333], 90 −100: [1309;46;268], 110 −130: [1535;30], ≥130: [541]. the UDP downlink throughput to drop up to 50 %, depending on the precipitation level, but that the uplink throughput remains unaffected. Our results show exactly this behavior, with the median downlink throughput of our GER-Highway measurements being 17 % lower than the one of GER-City. For the uplink throughput, the clustered distribution of the samples in the U.S. dataset is likely caused by measurement setup-specific elements, leading to no valuable comparability to our GER-Highway measurements and the GER-City dataset. C. PACKET LOSS The packet loss behavior of the different datasets can be hardly compared because of different measurement methodologies. In our GER-Highway campaign, it is measured using ICMP on the bent-pipe and on the packet-level based on sequence numbers. The GER-City dataset measures the full-path loss using ICMP with a reporting interval as percentages over 250 packets. The U.S. dataset measures the full-path loss using TCP retransmissions and reports it using percentages over measurement intervals of varying lengths. Because of these differences, we only present our measurement results. Overall, our measurement results show a packet loss rate (PLR) of 2.84 % and average burst length of 11 packets. The distribution of the burst lengths is visualized by Fig. 4.We define a burst as the number of consecutively lost packets. Approximately 50 % of the packet loss events are isolated losses with a burst length of 1. A further approximately 10 % possess a length of 2 and approximately 35 % lengths between 3 and 40. In addition to the shown behavior, we observe bursts with lengths around 500, 1,100 and 2,000 packets, but omit them in our visualization for better visibility. Interpretation: With a PLR of approximately 3 %, our measurement shows significantly more packet loss than reported by the U.S. dataset (up to 1.3 % retransmissions) and by the GER-City dataset (1 % with spikes up to 10 % in city-areas with large buildings). Later, in Sections VI-C and VII, we show that the packet loss, especially the bursts, is partially caused by periodic Starlink reconfigurations and obstruction. Together, these account for approximately 32 % of the overall packet loss. Further analysis is needed as part of future work to determine the cause of the remaining 68 % of the packet loss. D. THE IMPACT OF VEHICLE VELOCITY The impact of the vehicle velocity on the throughput is visualized in Fig. 5.2Considering the downlink throughput, we see a decline from a median of 234 Mbit/s for velocities of 70-90 km/h to 180 Mbit/s for velocities ≥130 km/h. This represents a 23.1% decrease. This behavior is contrary to the ones in the U.S. and the arctic, which are largely constant for the different velocities, as well as the one from GERCity, which sees a notable increase only for high velocities of 110-130 km/h. The uplink throughput in Fig. 5(b) shows a different behavior. The U.S. data sees an increase from a median of 15.4 Mbit/s at <70 km/h velocities to 27.1 Mbit/s for velocities between 90 and 110 km/h, representing a 76 % increase. The GER-City dataset shows an increase for higher car velocities between 110 and 130 km/h. In contrast, our highway drive has median uplink throughputs of 13.2, 16.1, 16.3, 12.9, and 13.1 Mbit/s for increasing vehicle velocities. We note that our measurements at velocities <70 km/h are not representative, as they were conducted in construction areas on the highway. At those places, the highway is narrow with a single lane and typically there are more objects causing obstructions. Interpretation: Based on the difference of 3 Mbit/s between the fastest and slowest throughput, we argue that the uplink throughput can be seen as independent of the vehicle velocities and the changes are likely noise caused, e.g., by differing sample sizes. The authors of the U.S. dataset [10] argue that the vehicle velocity is negligible compared to the satellite velocities of approximately 28,000 km/h. While their downlink throughput, as well as the Arctic downlink throughput, are in line with this argumentation, their uplink throughput increases significantly with increasing velocities. Furthermore, the authors of the GER-city dataset [20] note that a decline of downlink throughput can be observed 2We note that not all datasets contain samples at higher car velocities, as indicated by Tab. 1. This leads to missing plots in the affected velocity buckets. VOLUME 6, 2025 1271 LANIEWSKI et al.: MEASURING MOBILE STARLINK PERFORMANCE: A COMPREHENSIVE LOOK between a standing vehicle and a driving vehicle, mentioning that the vehicle speed while driving has no significant impact. Their observed increase for high velocities in both, downlink and uplink throughput, is likely caused by less obstruction because the data is from one short highway drive where the Starlink dish had an unobstructed view of the sky. In addition, the speed bucket of 110-130 km/h only contains 30 samples, leading to non-representative results. In contrast, our data shows decreasing performance for the downlink throughput and constant performance for uplink throughput. To further analyze possible reasons other than the vehicle velocity for the observed degradation of the downlink throughput, we visualized the throughput measurements on a map and analyzed the surrounding terrain using satellite pictures and Google StreetView. The terrain is flat on the complete route of our measurement campaign, with no mountains or even hills in proximity, and throughput drops do not correlate with trees or other objects next to the highway. Furthermore, there is no correlation to the number of bridges crossing the highway at the different speed buckets and there was no precipitation during the measurement segments with car velocities (>110 km/h). Consequently, we believe that the car velocity is likely causing the observed behavior. However, the reason for the contrary behavior observed by the different measurement studies remains unclear and subject to future work. E. TAKEAWAY Based on the presented results, RQ1 (How does mobile Starlink performance differ in different regions of the world?) can be answered the following way. In terms of the downlink throughput, the best performance is achieved in Central Europe, followed by the Arctic and the U.S. No conclusion can be drawn about the uplink throughput because it was not measured in the Arctic and the data for the U.S. is challenging to interpret, as the observed behavior may be caused by specifics of the measurement campaign. Similarly, no conclusion can be drawn about the latency because of vastly different measurement setups. VI. MOBILE VS. STATIONARY PERFORMANCE In this section, we answer RQ2: How does the mobile performance compare to stationary performance? For this, we conduct a separate stationary measurement campaign, to which we compare our GER-Highway measurement results. First, we describe our measurement campaign. Next, we compare the results to our GER-Highway test drive. In this context, we also analyze whether hardware differences in the used dish versions and the used service plans cause performance differences. Then, we analyze the impact of Starlink’s 15 second reconfiguration interval on the mobile and stationary performance. Lastly, we summarize our findings. A. THE STATIONARY MEASUREMENT CAMPAIGN We conduct a five-day long stationary reference measurement from 19 th to 23 rd May 2024 with three Starlink dishes placed directly next to each other on the rooftop of a university building with unobstructed views of the sky. It consists of three Starlink dishes with different service plans: (1) A Standard Gen-2 dish with the Residential service plan, which we will title as Standard in this section, (2) A Standard Gen-2 dish with the Roam service plan, which we call Roam, and (3) An FHP dish with the Mobile service plan, whichwecallFHP. Since the Mobile service plan includes 50 GB priority traffic, we ensured that they were consumed before starting our measurements. Thus, all measurements were conducted using standard traffic prioritization. All three dishes are operated in bypass mode and connected via 1 Gbit/s Ethernet to the measurement computer, which is equipped with a four-port PCIe Ethernet adapter. This setup ensures equal measurement conditions for all dishes. Our measurement tools and parameterization are identical to the ones we used for our GER-Highway test drive, leading to direct comparability of both campaigns. We utilize the ping utility to measure the RTT and packet loss. We use the same configuration as for our GER-Highway test drive (cf. Section IV-C) with the Starlink gateway as target and inter packet spacings of 0.01 s. We measure UDP downlink and uplink throughput in parallel using separate iperf3 version 3.9 instances to avoid possible CPU limitations of iperf’s bidirectional mode. All three dishes measure against their own instances running on a server located in the network operating center of the local university, connected to the 5 Gbit/s fiber university network. We set target data rates of 800 Mbit/s for the downlink and 100 Mbit/s for the uplink to saturate the links. Using these setup and tools, we measure UDP downlink and uplink throughput, RTT, and packet loss in a sequential process. First, we measure the RTT and packet loss for one minute, followed by the parallel downlink and uplink throughput measurement for two minutes. We leave approximately seven minutes space between measurements in order to minimize interference with other Starlink users in the same service cell, leading to one measurement run approximately every 10 minutes. Our specific measurement setup allows starting the measurements exactly at the same time for all three dishes. During our measurements, there was a 8 hour rain period starting on 21 th May at 21 h with low precipitation of a maximum of 1.5 mm per hour. We monitored the weather with a Froggit DP2000 weather station placed directly next to our measurement setup. B. MOBILE VS. STATIONARY PERFORMANCE COMPARISON We now compare the results of our stationary measurement campaign to the ones of our GER-Highway test drive. The comparison is visualized by Fig. 6. 1272 VOLUME 6, 2025 FIGURE 6. Comparison of the mobile and stationary Starlink performance. 1) THROUGHPUT The downlink throughput distributions are shown in Fig. 6(a). Median throughputs of 292 Mbit/s, 243 Mbit/s, 307 Mbits, and 218 Mbit/s can be observed for the Standard, Roam, FHP, and GER-Highway setups, respectively. Their 95 % CIs do not overlap. This means that the mobile performance is approximately 90 Mbit/s or 29 % lower than the stationary (FHP) one. We can also see that the FHP dish has the best stationary performance, being approximately 5 % and 26 % faster than the Standard and Roam setups. The sample distributions of the Standard and FHP dish are similar with one cluster around the third quartile, another one approximately 50 Mbit/s above the first one, and a long tail for lower throughputs. The Roam dish has approximately equally distributed samples between the first and third quartile, resulting in overall worse median performance. In contrast, the samples of the GER-Highway measurements follow approximately a normal distribution centered around the median. A different behavior can be observed for the uplink throughput depicted in Fig. 6(b). The Standard, Roam, FHP, and GER-Highway setups have median throughputs of 21 Mbit/s, 17 Mbit/s, 18 Mbit/s, and 15 Mbit/s, respectively. Their 95 % CIs do not overlap. Consequently, the mobile performance is 17 % lower than the stationary one. The stationary FHP dish also outperforms the Roam setup by approximately 6 %, but gets outperformed by the Standard setup by 17 %. For all four setups, the samples are approximately normally distributed between the first and third quartile, with the Standard and FHP dish having another cluster of samples approximately 10 Mbit/s above the third quartile. Interpretation: The 29 % gap between mobile and stationary performance in the downlink throughput can be partially explained by the wet weather conditions during our GER-Highway test drive (cf. Section IV-B). Since rain and clouds do not impact uplink throughput [21], it is likely that the 17 % gap of the uplink throughput can also be roughly expected for the downlink throughput under ideal weather conditions. Future research is needed to determine the root cause of the 17 % gap. 2) LATENCY The RTT distributions are shown in Fig. 6(c). The outliers are omitted for clarity. The Standard, Roam, FHP, and GER-Highway setups possess median RTTs of 21.3 ms, 20.5 ms, 19 ms, and 27.6 ms, respectively. In result, the RTT of the mobile setup is 45 % higher than the one of the stationary FHP setup. While the 95 % CIs do not overlap, the performance of the stationary setups is roughly comparable in practice, with differences of 1 ms in the median. All stationary dishes have similarly distributed samples, with clusters around the first and third quartiles. In contrast, the samples of the GER-Highway campaign are clustered around the first quartile, with a long tail towards higher RTTs. Interpretation: In Sections VI-C and VII we will discuss that the 15 second reconfiguration interval of Starlink, and short total obstruction periods cause short RTT spikes. While these factors contribute to the significantly higher RTTs of our GER-Highway measurements compared to the stationary FHP setup, their occurring frequency is too low to make a meaningful impact. Eliminating these spikes from our data still yields a median RTT of 27.5 ms, rendering those factors negligible in the global context. The causing factors need to be found in future work. 3) PACKET LOSS For the packet loss, a similar behavior can be observed as for the Latency. The distribution of the burst lengths is visualized by Fig. 6(d). The Standard, Roam, FHP, and GER-Highway setups have PLRs of 0.36 %, 0.41 %, 0.35 %, and 2.85 % with average burst lengths of 2, 2, 2.1, and 11.3 packets, respectively. There is more than eight times more packet loss in the mobile scenario than in the stationary scenario. Furthermore, the packet loss is more than five times more bursty. The packet loss and burst loss behavior is largely similar for all stationary dishes, with more than 60 % of the loss events being isolated packet losses of just one packet. Interpretation: Two factors contribute to the high packet loss of our GER-Highway test drive: the 15 second reconfiguration interval of Starlink and objects that obstruct the communication beam. The reconfiguration interval accounts for approximately 9 %, and the obstruction induced packet loss for approximately 23 % of the total packet loss. A detailed analysis of both factors follows in Sections VI-C and VII. It is subject to future work to determine the causes of the remaining 68 % of the packet loss. VOLUME 6, 2025 1273 LANIEWSKI et al.: MEASURING MOBILE STARLINK PERFORMANCE: A COMPREHENSIVE LOOK FIGURE 7. RTT. 4) THE IMPACT OF THE DISH VERSION AND SERVICE PLAN As a side product of our analysis, we can also determine the impact of the dish version and the used service plan on the stationary Starlink performance. Our results show that the FHP setup outperforms the Standard setup in the downlink throughput by approximately 5 %, in the RTT by approximately 10 %, and by the packet loss of 2 %. At the same time, its uplink throughput is 17 % worse than the one of the Standard setup. These results are surprising since the FHP dish has a wider FOV than the Standard dish with 140◦to 100◦(cf. Section II) and a significantly higher power consumption. They indicate that the better hardware is primarily needed to keep the connection while driving, likely because of frequent changes of the surrounding environment causing obstruction and orientation changes. Furthermore, the Roam setup trails the Standard setup by 17 %, 18 %, and 19 % in terms of downlink throughput, uplink throughput, and PLR, respectively. However, it outperforms the Standard setup by 4 %. Starlink states that traffic of the Roam service plan has the lowest prioritization. Our results indicate that this does not only have a negative impact on the performance during times of network congestion, as our setup of three dishes is highly unlikely to saturate the cell capacity. C. THE IMPACT OF THE 15 S RECONFIGURATION INTERVAL Starlink operates a global network controller that reconfigures the dish-satellite-ground station path every 15 seconds at the 12 th, 27 th, 42 nd, and 57 th seconds of every minute [27],[28],[35]. At these reconfigurations, all active clients are reconnected to the satellites [11],[27],[35], satellites reconnect to the ground stations [28], and frequencies are reallocated [5]. The dish-satellite reconnection is especially interesting because the global network controller assigns satellites to dishes based on different factors such as load and geospatial conditions [35]. In consequence, a dish might connect to a new satellite (handover) or reconnect to the old serving satellite. Earlier studies found that these reconfigurations cause short, sub-second, RTT spikes and throughput drops [27]. Furthermore, it was found that burst packet loss occurs at some reconfigurations [14],[28].This FIGURE 8. Loss. problem, however, has been mitigated by Starlink in early 2024 [28]. In this section, we compare the impact of the reconfigurations on the mobile and stationary performance. We focus our analysis on the RTT and packet loss, since the measurement interval of 10 ms allows an accurate detection of the reconfiguration times. We don’t consider the throughput, because the 1 second granularity of our measurements is insufficient to analyze sub-second behavior. We detect the reconfigurations in our data by utilizing timestamp matching. Since our clocks are not precisely synchronized to Starlinks system clock, the reconfigurations likely do not occur exactly at the scheduled 12 th, 27 th, 42 nd, and 57 th seconds of every minute. For each scheduled reconfiguration, we define a ±1s interval in which the reconfiguration occurs. We utilize the finding that short RTT spikes occur at each reconfiguration [27] to define the timestamp of the packet with the maximum RTT in our ±1s interval to be the time at which the reconfiguration happens. We analyze the distribution of these spikes and the packet loss that occurs around them. For this, we categorize our GER-Highway data into velocity buckets and compare the behavior to the FHP setup of our stationary measurements. In the following analysis, reconfigurations occurring under obstruction are eliminated, since obstruction adds additional instabilities, as we will discuss in Section VII. 1) LATENCY Fig. 7visualizes the distributions of the RTT spikes occurring at the reconfigurations. All car velocity buckets of our GER-Highway dataset show comparable behaviors with median RTT spikes of approximately 100 ms, overlapping confidence intervals, and approximately normally distributed samples centered around the medians. In comparison, the RTT spikes of the stationary use-case are approximately 30 % lower, with a median of 72 ms. The CIs do not overlap, indicating statistical significance. This indicates that the RTT spike is generally stronger under motion, but the velocity of the motion has no impact. Reconfiguration-induced RTT spikes do not explain the significantly higher RTTs of the mobile scenario shown in Fig. 6(c) because their occurring frequency is negligible in comparison to the overall sample size. Eliminating all reconfiguration spikes from the data leads 1274 VOLUME 6, 2025 FIGURE 16. Excerpt of HTTP download throughput over time under the GER-Highway link conditions. Different measurement setups also affect our analysis to answer RQ2, limiting our dataset comparison to our GERHighway test drive and our own stationary measurements. Finally, the analysis of the impact of bridges on Starlink performance conducted in Section VII to answer RQ3 is limited by the measurement accuracy discussed in Section VII-A. This includes limited GPS accuracy, uncertainties caused by clock synchronization, uncertainties of the bridge locations, and unknown orientations of the beam. X. FUTURE RESEARCH DIRECTIONS Our work opens up interesting future research directions, which we outline in this section. Finding mobility-specific instability factors: In our analysis in Sections VI and VII, we found that the periodic 15 s Starlink reconfiguration interval and obstruction caused by bridges cause short RTT spikes and burst packet loss. Both factors together account for 32 % of the approximately 3 % overall packet loss, but are negligible contributing factors to the generally higher RTTs under mobility shown in Fig. 6(c). Finding the factors causing the remaining 68 % packet loss and the higher RTTs is essential to gain a deep understanding of the system. We see sudden orientation changes of the dish, caused, e.g., by sudden changes in the driving direction or simple instabilities due to uneven roads, as a likely additional factor as it possibly leads to suboptimal beamforming behavior. However, additional measurement studies are needed to validate this. Developing mitigation strategies: In Section VIII,we have demonstrated the negative impact of mobility-induced instabilities on HTTP bulk file transfer as an exemplary TCP application. This highlights the necessity to develop appropriate coping mechanisms. In the past, congestion control algorithms to handle instabilities caused by the 15 s reconfiguration interval have been developed for TCP [7] and QUIC [13]. Both approaches utilize the recurring nature of Starlink’s reconfigurations happening at globally defined points in time (12th, 27th, 42nd, and 57th second of every minute). A comparable approach might be applicable to other factors causing instabilities under mobility, such as obstruction. Especially bridges might be fitting candidates since their positions are fixed and known. However, the dynamic environment changes make such an adaptation significantly more challenging compared to coping with the static Starlink reconfigurations. A bridge prediction would depend on an accurate measurement or estimation of the position and velocity of the car, making congestion control management highly complex and situation-specific. The complexity can be further increased by taking additional obstruction factors into account, such as large buildings in cities. Hybrid approaches, consisting of a kernel-based congestion control algorithm that can be dynamically parameterized by the application layer based on the car position and velocity, might be feasible. As an alternative to a new congestion control algorithm, application-specific modifications might be used. This could be, for example, new buffering strategies for video streaming. General impact of obstruction: The route of our GERHighway test drive provided almost optimal, unobstructed conditions for the Starlink dish, as discussed in Section IV. Only bridges crossing the highway caused short periods of total obstruction. While this enabled an isolated analysis of their impact on Starlink performance, other types of obstruction causing signal degradation remain an open research question. Especially interesting would be to analyze the impact of large buildings next to the road, and trees covering the road. For the former, a test drive through a city with large skyscrapers would be helpful, and for the latter, a test drive through forests would be necessary. Such findings could, for example, help to assess Starlink’s potential to open up new economic opportunities in rural areas, such as connecting agricultural machines. Weather impact under mobility: As discussed in Section IV, the impact of basic weather conditions, such as precipitation, cloudiness, temperature, wind speed, and humidity, on Starlink performance has been analyzed for the stationary use-case [17],[18],[21]. It was shown that precipitation and cloudiness degrade the downlink throughput. It remains an open research question whether additional mobility-related factors, such as increasing particle densities at increasing velocities or whirled water by preceding cars, intensify the degradations caused by precipitation. Such an analysis ideally also includes other extreme weather conditions, especially heavy snow and fog. However, we see practical challenges measuring these under mobility due to decreasing drivers safety at increasing velocities. VOLUME 6, 2025 1281 LANIEWSKI et al.: MEASURING MOBILE STARLINK PERFORMANCE: A COMPREHENSIVE LOOK Simulation Models: Extensive real-world measurements of mobile Starlink performance, like we did in this paper, are quite cost-intensive. Contributing factors are the acquisition costs for the FHP dish and for a power station for power supply, materials for installing the dish on the roof of the car (e.g., a roof rack), the service plan, fuel, and, most importantly, the time of the driver. Consequently, it is practically infeasible to always test newly designed algorithms or applications via real-world measurements. An accurate simulation model would not only solve this issue but would also allow researchers across the world to benchmark their developments under defined conditions, ultimately leading to better comparability of different solutions. In theory, such a simulation model containing all bridges crossing German highways can be built. However, in order to make it as accurate to the real-world as possible, additional factors which are not yet sufficiently understood, such as weather and neighboring tall buildings, need to be included. Channel Models: Channel models are used to describe the signal characteristics of wireless systems. These characteristics can include factors such as general signal propagation, signal attenuation (e.g., by tropospheric effects), satellite constellation characteristics (e.g., elevation), and user equipment mobility. In release 15, the 3rd Generation Partnership Project (3GPP) has defined guidelines for building channel models for non-geostationary orbit (NGSO) satellite networks [1]. Since then, many NGSO channel models have been developed. A comprehensive overview is given by Baeza et al. [3]. However, none of these models is generally applicable as they all base on different assumptions, are built for different use-cases, or address different aspects of the signal. Currently, no channel model exists for Starlink. While such a model would be immensely helpful for the understanding of the system and the design of improvements, its development is severely hindered by the closed nature of the system. XI. CONCLUSION In this paper, we took a comprehensive view on mobile Starlink performance from the measurement perspective. In particular, we answered the following three research questions. RQ1: How does mobile Starlink performance differ in different regions of the world? We found that limitations of the considered measurement campaigns, differences in measurement setups, and different result reporting methods made a comparison of uplink throughput and RTT difficult. In terms of the downlink throughput, we found that Central Europe outperforms the Arctic by approximately 15-30 % and the U.S. by approximately 40-50 %. Interestingly, analyzing the impact of the vehicle velocity on the throughputs yielded partly contrary results between the datasets. It is subject to future work to shed light on the root cause. RQ2: How does the mobile performance compare to stationary performance? Through a comparison of our GERHighway test drive to our own stationary measurements, we found that the mobile performance is significantly worse than the stationary performance. In terms of downlink throughput, uplink throughput, RTT, PLR, and average burst lengths, the gap is 29 %, 17 %, 45 %, 814,%, and 538 %, respectively. In this context, we also found that the 15 s Starlink reconfiguration interval causes significantly more instabilities under mobility. The RTT spikes are 42 % higher, the fractions of reconfigurations causing packet loss increase by 30 percentage points, and the average burst lengths are up to 388 % larger under mobility. The reconfigurationinduced instabilities together with obstruction of the dish partially, but not entirely, explain the lower performance under mobility. Additional factors negatively impacting the mobile performance need to be found in future work. RQ3: How does obstruction impact mobile performance? We analyzed the obstruction caused by 98 bridges crossing the route of our test drive. We found that they cause burst loss, RTT spikes, and drops of the throughput. These performance degradations can occur when the car is before, under, or behind the bridge, depending on the direction of the beam. These degradations can severely degrade the performance of TCP-based applications such as HTTP bulk file transfer. In future work, mechanisms to mitigate these effects should be developed. ETHICAL STATEMENT This work does not use any sensitive data. Following community best-practices, we carefully conducted the measurements in line with the fair-use policy of the network provider. As far as we were able to ascertain, our measurements did not interfere with service for other users. ACKNOWLEDGMENT The authors like to thank the SWO Netz GmbH for letting them build their measurement setup into their van and allowing them to gather the data. REFERENCES [1] “Study on new radio (NR) to support non-terrestrial networks (release 15),” 3GPP, Sophia Antipolis, France, Rep. 38.811, 2020. [2] M. Amend. “MP-DCCP for enabling transfer of UDP or IP traffic over multiple data paths in multi-connectivity networks.” Accessed: Feb. 14, 2025. [Online]. Available: https://datatracker.ietf.org/doc/slides-104tsvwg-sessb-43-markus-amend-multipath-dccp/ [3] V. M. Baeza, E. Lagunas, H. Al-Hraishawi, and S. Chatzinotas, “An overview of channel models for NGSO satellites,” in Proc. 96th IEEE Veh. Technol. Conf., 2022, pp. 1–6. [4] C. Beckman, J. Garcia, H. Mikkelsen, and P. Persson, “Starlink and cellular connectivity under mobility: Drive testing across the arctic circle,” in Proc. Wireless Telecommun. Symp. (WTS), 2024, pp. 1–9. [5] R. Blázquez-García, D. Cristallini, M. Ummenhofer, V. Seidel, J. Heckenbach, and D. O’Hagan, “Experimental comparison of Starlink and OneWeb signals for passive radar,” in Proc. IEEE Radar Conf., 2023, pp. 1–6. [6] “Worldwide broadband speed league 2024.” 2024. [Online]. Available: https://www.cable.co.uk/broadband/speed/worldwide-speed-league/ [7] X. Cao and X. Zhang, “SaTCP: Link-layer informed TCP adaptation for highly dynamic LEO satellite networks,” in Proc. IEEE Int. Conf. Comput. Commun. (INFOCOM), 2023, pp. 1–10. [8] B. Für Straßenwesen. “Fokus: Brücken.” 2024. [Online]. Available: https://www.bast.de/DE/Ingenieurbau/Fachthemen/brueckenstatistik/ bruecken_hidden_node.html 1282 VOLUME 6, 2025 [9] J. Garcia, S. Sundberg, G. Caso, and A. Brunstrom, “Multi-timescale evaluation of Starlink throughput,” in Proc. 1st ACM Workshop LEO Netw. Commun., 2023, pp. 31–36. [10] B. Hu et al., “LEO satellite vs. cellular networks: Exploring the potential for synergistic integration,” in Proc. 19th Int. Conf. Emerg. Netw. Exp. Technol. (CoNEXT), 2023, pp. 45–51. [11] L. Izhikevich, M. Tran, K. Izhikevich, G. Akiwate, and Z. Durumeric, “Democratizing LEO satellite network measurement,” Proc. ACM Meas. Anal. Comput. Syst., vol. 8, no. 1, pp. 1–26, 2024. [12] J. Deere. “John Deere announces strategic partnership with SpaceX to expand rural connectivity to farmers through satellite communications.” 2024. [Online]. Available: https://www.deere.com/en/ourcompany/static/john-deere-partnership-with-spacex/ [13] V. Kamel, J. Zhao, D. Li, and J. Pan, “StarQUIC: Tuning congestion control algorithms for QUIC over LEO satellite networks,” in Proc. 2nd Int. Workshop LEO Netw. Commun. (LEO-NET), 2024, pp. 43–48. [14] M. M. Kassem, A. Raman, D. Perino, and N. Sastry, “A browser-side view of Starlink connectivity,” in Proc. 22nd ACM Internet Meas. Conf. (IMC), 2022, pp. 151–158. [15] D. Katabi, M. Handley, and C. Rohrs, “Congestion control for high bandwidth-delay product networks,” in Proc. ACM SIGCOMM Conf. (SIGCOMM), 2002, pp. 89–102. [16] T. Kohnstamm, “Everything you need to know about project Kuiper, Amazon’s satellite broadband network.” 2024. [Online]. Available: https://www.aboutamazon.com/news/innovation-at-amazon/ what-is-amazon-project-kuiper [17] E. Lanfer, D. Laniewski, D. Otten, and N. Aschenbruck, “Weatherbased link prediction for LEO-satellite networks using the WetLinks dataset,” in Proc. IFIP Netw. Conf., 2024, pp. 586–588. [18] E. Lanfer, D. Laniewski, M. Wehmeier, and N. Aschenbruck, “Observing the skies—Ground-based cloud detection for evaluating the impact of clouds on LEO communications,” in Proc. 2nd Int. Workshop LEO Netw. Commun. (LEO-NET), 2024, pp. 19–24. [19] D. Laniewski, E. Lanfer, and N. Aschenbruck, “Starlink-on-theautobahn dataset.” 2025. [Online]. Available: https://github.com/sysuos/Starlink-on-the-Autobahn [20] D. Laniewski, E. Lanfer, S. Beginn, J. Dunker, M. Dückers, and N. Aschenbruck, “Starlink on the road: A first look at mobile Starlink performance in central Europe,” in Proc. 8th Netw. Traff. Meas. Anal. Conf. (TMA), 2024, pp. 1–8. [21] D. Laniewski, E. Lanfer, B. Meijerink, R. van Rijswijk-Deij, and N. Aschenbruck, “WetLinks: A large-scale longitudinal Starlink dataset with contiguous weather data,” in Proc. 8th Netw. Traff. Meas. Anal. Conf. (TMA), 2024, pp. 1–9. [22] D. Laniewski et al., “Demo: The impact of LEO satellite network instabilities on the performance of networking applications,” in Proc. 49th IEEE Conf. Local Comput. Netw. (LCN), 2024, pp. 1–4. [23] M. López, S. B. Damsgaard, I. Rodríguez, and P. Mogensen, “Connecting rural areas: An empirical assessment of 5G terrestrialLEO satellite multi-connectivity,” in Proc. 97th IEEE Veh. Technol. Conf., 2023, pp. 1–5. [24] S. Ma, Y. C. Chou, H. Zhao, L. Chen, X. Ma, and J. Liu, “Network characteristics of LEO satellite constellations: A Starlinkbased measurement from end users,” in Proc. IEEE Int. Conf. Comput. Commun. (INFOCOM), 2023, pp. 1–10. [25] J. McDowell. “Enormous (‘mega’) satellite constellations.” 2024. [Online]. Available: https://planet4589.org/space/con/conlist.html [26] F. Michel, M. Trevisan, D. Giordano, and O. Bonaventure, “A first look at Starlink performance,” in Proc. 22nd ACM Internet Meas. Conf. (IMC), 2022, pp. 130–136. [27] N. Mohan et al., “A multifaceted look at Starlink performance,” in Proc. ACM Web Conf. (WWW), 2024, pp. 2723–2734. [28] J. Pan, J. Zhao, and L. Cai, “Measuring the satellite links of a LEO network,” in Proc. IEEE Int. Conf. Commun. (ICC), 2024, pp. 4439–4444. [29] “NTP FAQ.” 2022. [Online]. Available: http://www.ntp.org/ntpfaq/ NTP-s-algo/#5131-how-accurate-will-my-clock-be, [30] Guidelines for the Design of Motorways, Road Transp. Res. Assoc., Cologne, Germany, 2008. [31] “Starlink flat high performance kit specifications.” SpaceX. 2024. [Online]. Available: https://api.starlink.com/public-files/ specification_sheet_flat_high_performance.pdf [32] “Starlink service plan specifications.” SpaceX. 2024. [Online]. Available: https://www.starlink.com/legal/documents/DOC-140028829-70 [33] “Starlink standard kit specifications.” SpaceX. 2024. [Online]. Available: https://api.starlink.com/public-files/ Starli%20Produ%20Specifications_Standard.pdf [34] “Starlink standard specifications.” SpaceX. 2024. [Online]. Available: https://api.starlink.com/public-files/specification_sheet_standard.pdf [35] H. B. Tanveer, M. Puchol, R. Singh, A. Bianchi, and R. Nithyanand, “Making sense of constellations: Methodologies for understanding Starlink’s scheduling algorithms,” in Proc. 19th Int. Conf. Emerg. Netw. Exp. Technol., 2023, pp. 37–43. [36] “ThinKom and Telesat expand agreement for low earth orbit operations,” Telesat. 2024. [Online]. Available: https://www.telesat. com/press/press-releases/thinkom-and-telesat-expand-agreement-forlow-earth-orbit-operations/ [37] “The netem Developers: Netem—Network emulator.” Accessed: Feb. 14, 2025. [Online]. Available: https://www.man7.org/linux/manpages/man8/tc-netem.8.html [38] I. Tsareva, T. V. Doan, and V. Bajpai, “A decade long view of internet traffic composition in Japan,” in Proc. IFIP Netw. Conf. (IFIP Netw.), 2023, pp. 1–9. DOMINIC LANIEWSKI (Graduate Student Member, IEEE) received the B.S. degree in information systems from the University of Münster in 2017, and the M.S. degree in computer science from Osnabrück University in 2019, where he is currently pursuing the Ph.D. degree with the Distributed Systems Group. His research interests include point cloud and video streaming, Internet measurements, machine learning for networks, and robot communications. ERIC LANFER (Graduate Student Member, IEEE) received the master’s degree in computer science from Osnabrück University, Germany. He is currently pursuing the Ph.D. degree with the Distributed Systems Group, Osnabrück University, where his research primarily centers on network security, particularly in the area of network intrusion detection. His academic journey includes international experiences with Stockholm University and the University of Twente. Additionally, he contributes to teaching and research in the field of Internet measurements and works on projects, such as exploring the performance of satellite networks. NILS ASCHENBRUCK (Member, IEEE) received the Graduate Diploma and Ph.D. degrees in computer science from Bonn University, Germany, in 2003 and 2008, respectively. He was a Senior Researcher and the Head of the Research Area “Tactical Wireless Multi-Hop Networks” with the Communication Systems Group, Bonn University, where he has been holding a Tenured Professorship for Distributed Systems since 2012. His research focus is on dependable and robust networked systems including scenario modeling, traffic engineering, and network security. VOLUME 6, 2025 1283