What Obstructed Skies Teach Us About Satellite Internet

We calculate packet loss percentage defined as the fraction of lost packets during a specific time interval using lost packets from RTT measurements over 1-hour intervals for 10 days (Figure 3(b)). The positive y-axis shows control dish loss and negative y-axis shows test dish loss. Both dishes perform similarly with occasional high loss spikes between 12AM-4AM (most frequently at 3AM), likely due to Starlink infrastructure maintenance rather than user traffic.

We use the Starlink-gRPC API to obtain a 2D obstruction map (123px $\times$ 123px grid) capturing satellite movement. While the Starlink mobile application provides 3D visualization, only the 2D version is programmatically accessible. Figure 4(b) shows an obstruction map from the API where white pixel-based lines represent satellite trajectories, continuously updated as satellites move with each pixel representing satellite position relative to the dish.

Over time, overlapping satellite trajectories crowd the obstruction map, making satellite identification challenging. We address this by clearing the map every minute using the Starlink-gRPC API, choosing a one-minute window to avoid frequent resets while allowing time to start trajectory repopulation. Since satellite handovers occur at 12, 27, 42, and 57 seconds, we reset at 56th second to maximize captured trajectory data with 1 second for processing.

During each reset cycle, we capture snapshots every 15s at 11, 26, 41, and 56 seconds, timed one second before expected handover events for processing delays. While related work reboots dishes every 10 minutes, the Starlink-gRPC reset API enables map clearing without rebooting, capturing trajectory data with reduced overlapping trajectories [44].

Since the trajectory is continuously populated on the same map, isolating the most recent trajectory (i.e.,the trajectory populated during the last 15 seconds between $N^{th}$ and ${(N-1)}^{th}$ snapshot) from $N^{th}$ snapshot of the obstruction map requires additional processing. Following the approach of [44] for isolating the trajectory, we compute an XOR between the $N^{th}$ and the ${(N-1)}^{th}$ snapshot captured for the previous 15 second window.

XOR alone can leave residual trajectories from previous resets. We address this by applying an additional AND operation between the $N^{th}$ snapshot and XOR result, filtering outdated points to retain only the most recent trajectory from the ${(N-1)}^{th}$ snapshot. Figures 4(b)-4(e) show the snapshots and operations where XOR retains trajectories from both snapshots while AND isolates the most recent trajectory.

To map the trajectory to a satellite, we first convert the trajectory data to a format compatible with public satellite information. Satellite positions in Celestrak are represented using azimuth and angle of elevation (AOE) [23], as shown in Figure 2. For each trajectory, we compute the AOE and azimuth per pixel. Since the obstruction map uses a polar coordinate system, AOE is estimated based on the radial distance from the center of the map, while azimuth is determined by measuring the clockwise angle from the top (North) of the map [44, 6].

We compare extracted trajectories to Celestrak satellite data [1] for identification. Since Celestrak updates only every six hours, we use SGP4 [47] to compute real-time satellite positions. We find the best match between the obstruction map and public satellite data we use Dynamic Time Warping (DTW) distance [42], and classify the satellite with smallest DTW distance as the serving satellite. For computing DTW distance, both trajectories are converted from polar to Cartesian coordinates using $x=r\cdot \cos (\theta )$ and $y=r\cdot \sin (\theta )$, where $r$ is radial distance or azimuth and $\theta$ is AOE.

To address misclassification, we consider the k closest satellites based on DTW distance, rather than relying solely on the single closest match. By analyzing the top k candidates, we can account for minor variations in trajectory data. With k=2, we find that both dishes connect to the same satellite over 99.9% of the time, confirming that the observed mismatches resulted from minor trajectory variations. We compare the trajectories directly next to further validate the results.

Rather than mapping trajectories to a satellite and then comparing the matched satellites, we directly compare the trajectories from both dishes using difference in DTW values. We convert the polar coordinates to Cartesian coordinates for comparison.

AOE or r can vary from 25 to 90, on the other hand azimuth can vary from 0 to 360 degrees but converting to Cartesian coordinates involves taking $\sin$ or $\cos$ of azimuth which limits its values between 0 and 1. This causes the DTW distance to vary widely with changes in r but not with $\theta$. To account for this, we normalize r using multiple methods to bound the value between 0 and 1 and compare the results. We normalize r by the following methods: 1. dividing by maximum value of r (90), 2. normalizing over the range of 25 to 90, 3. taking $\cos (r)$ , and 4. taking $\sin (r)$. The equations for these normalization methods are shown below.

Using the normalized values of r, we compute the difference in DTW distance between the two trajectories. Figure 6 shows the DTW distance for the default non-normalized value of r has a knee around 0.97. In contrast, all other normalization methods show the knee around 0.99. This suggests that even without normalization, the DTW distance between the control and test trajectories is very low, indicating strong similarity. After normalization, the DTW distance decreases even further, reinforcing that the trajectories are highly similar and the dishes are connected to the same satellite.

Using obstruction height and distance from the dish as shown in Figure 4(a), we estimated the blocked AOE, which closely matched the obstruction map. We validated results by testing different distances.

Using obstruction width and distance, we estimated blocked azimuth. Initial results showed a 1.5x offset, which we adjusted for in further calculations. We validated the adjusted model by testing different distances and directions and found alignment with the obstruction map.

We estimated the obstructed direction using easily available devices, including a mobile phone compass, an orienteering compass, and a smartwatch compass. However, these devices yielded inconsistent results. To align with the obstruction map, we adjust the direction by referencing the Starlink obstruction map.

After validating our estimates and accurately profiling the blocked region, we examine the directional impact of the obstruction placement, leveraging the observation that the dish predominantly connects in specific directions.

The obstructed area appeared clearly, indicating that the dish experienced obstruction in its LOS, as shown in Figure 8(a). This aligns with our expectations, as the dish primarily connects to satellites in the eastern region. Despite the obstruction in the connection area, we did not observe a significant RTT or loss degradation.

The obstructed area appeared clearly as shown in Figure 8(c). This aligns with our expectations based on the connection region. In this case, the obstruction led to 4% increase in RTT on average for the test dish compared to the control dish. We also observed an average increase from 0.1% to 0.4% in packet loss.

The obstruction did not appear in the obstruction map as shown in Figure 8(b), and no performance degradation was observed. This is consistent with our expectations, as the dish primarily connects to satellites towards the eastern side, as discussed in Section 4.4.

The obstruction did not appear in the obstruction map and no performance degradation was observed, as it was located behind the dish where satellites are not typically accessed.

Hence, we can say that the obstruction’s impact depends on the direction it is placed in. Obstructions in SE degraded performance the most, followed by the obstruction in NE. On the other side, obstructions in the NW and SW directions had minimal impact on the dish’s performance. Given that the obstruction in the SE direction had the most impact on performance, we further investigated this direction to better understand the causes of performance degradation.

To understand the performance impact of obstructing the south east region, we measured RTT and packet loss following the methodology outlined in §4. Figure 9(a) shows the hourly median RTT over a 10-day period to assess aggregate performance along with the tail latencies ($5^{th}$ and ${95}^{th}$ percentiles) of both dishes. We observe that the obstructed (test) terminal observes a persistent RTT increase of approximately 4% on average compared to the control dish. Similarly, we calculate the percentage of packet loss over 1-hour intervals and tail latencies for the same 10-day period. Figure 9(b) shows consistently higher loss with an absolute increase of 0.3% in presence of the obstruction.

Using the satellite identification method described in §4, we calculate the percentage of instances where the test terminal connected to a different satellite than the control terminal.

We observed that the test terminal connected to a different satellite in 15% of the cases on average for SE. The daily percentage of such connections are shown in Figure 10. This indicates that the obstruction in affected the satellite connection area and led to a different satellite being selected.

We observed changes in the connection area of the test dish as shown in Figure 11 using cumulative distribution function (CDF) rather than using a scatter plot as in Figure 7, as the scatter plot makes it difficult to present these changes. The CDF reveals that the test terminal’s azimuth shifted north to avoid the obstructed area (marked with gray lines), while the control terminal also unexpectedly changed its connection area.

As shown in Figure 11, in the unobstructed scenario, the azimuth CDF of both the terminals overlapped as expected. In the obstructed scenario, we anticipated the control terminal’s CDF to remain unchanged and aligned with the unobstructed case. However, we observed a slight shift in the control terminal’s azimuth distribution toward the north, despite no visible obstruction in its obstruction map. To verify whether this shift was caused by the obstruction placed for the test terminal, we removed the obstruction and found that both the terminal’s azimuth distribution returned to its original pattern. This suggests two possible scenarios: (1) the obstruction may have partially interfered with the control terminal’s line of sight despite not being registered in the obstruction map, or (2) the obstructed test terminal indirectly influenced Starlink’s satellite selection algorithm, causing the control terminal to change its connection area. If the latter is true, it indicates a vulnerability in the connection algorithm of Starlink which can be exploited to affect the connectivity of other terminals.

These results confirm that obstructions in critical connection regions directly impact connectivity and performance.

When the obstruction was placed in the east direction, we observed performance similar to the southeast direction. Since the dish connects in this general direction, the results were expected. Interestingly, the connection area shifted towards south, unlike southeast direction, where it shifted towards the north. This points that the dish often connects between east and south east directions.

We initially placed the obstruction at a distance of 44 inches from the dish. To assess the impact of distance, we moved the obstruction closer which resulted in an increase in the blocked azimuth range and reduction in blocked AOE range due to the elevation of the obstruction as shown in Table 1. As the distance decreased, we observed improvements in both RTT and loss. At 42 inches the performance was comparable to the control dish, suggesting that the dish handles blocked azimuth better than blocked AOE.

In practice, when the LOS between the dish and its serving satellite is near the boundary of the blocked region, the dish can often remain connected, but performance begins to degrade. As the LOS moves further into the blocked region, RTT and packet loss tend to degrade, until the dish eventually loses connectivity as shown in Figure 12.

We studied the on-terminal obstruction scenario by placing a thin aluminum sheet on top of the dish to simulate the accumulation of debris as shown in Figure 1(b). When the dish was fully covered, it was unable to connect to any satellite. However, when half of the dish was covered, it successfully established a connection and showed no performance degradation in terms of loss and latency. This shows that the dish can tolerate partial on-terminal obstructions.

In some time windows when the test dish connects to a different satellite compared to the control dish, we observe partial trajectories in the obstruction map of the test dish as shown in Figure 13(a). We observe two distinct trajectories, trajectory 1 in color blue for the obstructed region and trajectory 2 in green for the clear region. We call the trajectory that is not the longest trajectory in such cases, as an extra partial trajectory.

As per this observation, there are cases when the test dish switches the satellite connection during the slot, contrary to the popular belief that handovers happen only at the end of a 15 second slot [44]. Note that even when the satellite changes mid-slot, the usual handover still occurs at the end of the 15-second slot. These mid-slot switches are accompanied by high packet loss, suggesting that the dish changes satellites in response to the obstructions. Figure 12 shows an example of this behavior where the obstructed dish connects to a satellite at $T=12\text{s}$, experiences high loss and latency, and switches to a different satellite around $T=16\text{s}$ within the same 15-second slot. Figure 13(a) shows the corresponding obstruction map, with Trajectory 1 and Trajectory 2 representing the initial and subsequent connections. In contrast, the control dish remains connected to the same satellite as shown in Trajectory 1 in Figure 13(b), while Trajectory 2 shows the underflow behavior described in Section §6.2. We observe partial trajectories like Trajectory 2 in the obstruction maps of the test dish approximately 6% of the time compared to just 0.3% for control dish. We discuss this difference later in the section.

The partial trajectory can be as short as a single pixel in the obstruction map, which would occur when the connection is very brief, resulting in fewer pixels being populated in the obstruction map. When the connection is too short, the trajectory may not be visible on the obstruction map, unfortunately preventing us from identifying such cases as instances of responsive routing.

To understand pixel overflow and underflow we name connection windows. The currently examined 15s connection window for pixel identification and classification is the current window. The 15s window right before the current window is previous window and the window right after the current window is next window. Figure 14 shows the underflowed pixel in the current window 14(a) since it matches the trajectory from the next window 14(b). This occurs when the trajectory data is captured right after the handover. Similarly, we can have a pixel overflow where the pixel in the current window is populated from the next window’s trajectory data which can happen when the trajectory data is captured right before the handover.

The pixel overflow or underflow can occur due to the data capturing process. Since the trajectory data is captured just 1 second before the handover, processing delays may cause some pixels in the obstruction map to overflow or underflow the 15s connection window. For such a disjoint pixel in the obstruction map of the current window, we identify the following scenarios:

• $\mathrm{■}$

  Underflow. If the disjoint pixel in the current window is populated from the next window, we identify it by checking the trajectory in the next window. If it matches the trajectory, within a threshold defined as the maximum allowable pixel distance between two trajectory points for overflow or underflow, we classify it as an underflow.

• $\mathrm{■}$

  Overflow. If a pixel in the current window is from the trajectory in previous window, we can identify it by checking the trajectory in the previous window.

• $\mathrm{■}$

  Neither. If the pixel is neither overflowed nor underflowed (i.e.,populated in the current window) then we classify the pixel as a distinct trajectory and therefore as evidence of responsive routing.

For identifying evidence of disjoint routing, we do not consider cases where a pixel in the current window could have overflowed or underflowed into the previous or subsequent window. Instead, we specifically address and exclude scenarios where pixels in the current window have originated (overflowed or underflowed) from neighboring windows. This approach is necessary because it is uncertain whether pixels originating from adjacent windows correspond to a different satellite connection during the current observation window. If a pixel has overflowed or underflowed into adjacent windows and aligns with the trajectory in the current window, we conclude it is from the same satellite connection. If it does not match, we cannot determine if it overflowed or underflowed.

Table 2 summarizes the pixel populating scenarios for the test and control dishes. It splits connection windows into four categories: (1) no extra trajectory, when only one trajectory is seen; (2) extra trajectory, when multiple trajectories are present but neither overflow nor underflow occurs; (3) underflow, when the pixel in the current window originated from the next window; and (4) overflow, when the pixel in current window originated from previous window.

Table 2 illustrates these pixel populating scenarios across three different threshold values (0, 1, and 2). The threshold value influences trajectory classification into overflow and underflow. At threshold 0, the trajectory must precisely overlap with adjacent window trajectories, an unlikely condition due to satellite motion dynamics. Increasing the threshold to 1 reduces extra trajectory occurrences from 19.64% to 0.37% for the control dish and from 22.66% to 6.38% for the test dish. We attribute this reduction to increases in underflow and overflow. These results indicate that the test dish frequently connects to multiple satellites within the 15-second connection interval due to obstructions. Increasing the threshold further to 2 does not significantly alter the results, confirming that a threshold value of 1 is adequate.

Table 2 and Table 3 present the pixel populating scenarios. Table 3 specifically focuses on instances when the satellite identification algorithm determined the dishes connected to different satellites. In these cases, the extra trajectory scenario accounts for 21.28% for the test dish but only 0.66% for the control dish, reinforcing that the test dish has a higher chance of connecting to multiple satellites in obstructed connection windows.