CrowdLink: Unlocking Idle LEO Network Capacity with User Terminals

A natural approach to alleviate GSL bottlenecks is to increase the number of ground stations and deploy them more widely. A denser GS deployment provides more landing opportunities for satellites, activating more GSLs, thereby increasing the utilization of idle satellite capacity. However, this approach encounters three challenges:

1. 1.

   Geographic and policy constraints: GS deployment is primarily limited to land, which accounts for less than 30% of Earth’s surface. Even on land, many regions like rainforests, deserts, and mountainous areas can not easily support GS deployment [61]. Furthermore, geopolitical restrictions make it difficult to obtain the necessary permissions for GS installation, particularly in foreign or sensitive territories [57].

2. 2.

   High deployment cost: Large-scale GS expansion incurs substantial economic overhead. The number of GSs must scale with the number of subscribers, leading to escalating costs, including site acquisition, construction, operational, and maintenance cost. For example, the Starlink community gateway incurs a recurring cost of $75,000 per Gbps per month, with a one-time setup fee of $1.25 million [67]. Similarly, deploying a single OneWeb ground station costs an estimated $15 million, excluding operational and maintenance expenses [5]. As illustrated in Figure 6(a), achieving just 11.23% satellite utilization improvement would require building an additional 795 GSs at a cost of 993.75–11,925 million USD, which would result in a low return on investment. Although it is possible to build cheaper ground stations [63], it is usually at the cost of limited bandwidth and hence falls short to eliminating the last-mile bottleneck.

3. 3.

   Inflexible: Fixed GSs are inherently inflexible and cannot adapt to dynamic changes in user density and traffic demand. In practice, to meet peak demand, operators may oversupply GS capacity, which can reduce cost-efficiency during off-peak periods. [40, 13, 20, 17] suggest dynamically leasing GS capacity from third-party providers based on traffic demand, aiming to improve flexibility and reduce upfront deployment costs. However, this approach still faces two major limitations. First, the global GS pool remains small compared to the number of active satellites, and hundreds of thousands of satellites still compete for connections to only a few hundred GSs, leaving the fundamental bottleneck unresolved. Second, most GS providers [13, 20, 17] require satellite operators to reserve usage windows several hours in advance, which limits the system’s responsiveness to short-term demand shifts.

Alternatively, recent efforts seek to leverage ISLs to use idle satellites. These efforts typically involve designing inter-satellite topologies and load-balancing strategies to distribute user traffic more evenly across satellites and ground stations. As shown in Figure 5, ground station load is often imbalanced. Some GSs are heavily congested while others remain underutilized. By spreading traffic across multiple GSs, load balancing can improve per-UT bandwidth. Meanwhile, routing traffic through underutilized satellites helps increase satellite utilization.

While helpful, ISLs alone cannot eliminate last-mile GSL bottlenecks. When the dominant bottleneck is the aggregate GSL capacity, ISLs merely reshuffle where traffic lands and cannot increase the total throughput. Take Starlink as an example: with 227 GSs, each equipped with eight 20 Gbps Ka-band antennas, the system offers a total downlink capacity of 36.3 Tbps. When shared by 4.6 million users, the average per-user capacity remains just 7.9 Mbps. Figure 6(b) illustrates the effect of ISL activation ratio on utilization. Assuming each satellite has no more than two intra-orbit ISLs and no more than one inter-orbit ISL, we simulate different ISL activation ratios. While utilization improves with more active ISLs, the overall gain is limited. Even at full ISL activation, the improvement is only 5.9%, which is far from sufficient.

In addition, ISLs remain operationally constrained in today’s LEO networks. Establishing a laser ISL involves scanning, acquisition, tracking, and pointing, which can take hundreds of milliseconds [27, 66, 29]. Once connected, satellites must continuously adjust their orientation to maintain the connection. As shown in Table 1, ISL maintenance requires extremely tight angular alignment. Even small orbital jitter or line-of-sight disruptions can break the link. Hence, in operational LEO networks like Starlink, multi-hop ISL routing is mostly used for users outside the GS coverage [6].

Since neither of the above workarounds can eliminate bottlenecks from skewed ground stations, it is interesting to consider whether one can totally redesign the LEO constellation to avoid satellite waste. In this direction, [45, 30] design non-uniform LEO constellations to match the satellite supplies with the uneven terrestrial demands. [53, 54, 48] advocate multi-operator LEO constellations to increase their satellite utilization. While inspiring for future LEO networks, these clean-slate constellation designs are difficult to retrofit into operational LEO networks today to utilize their massive idle satellites.

We target a readily deployable design for today’s operational LEO networks. This constrains the solution space. Since satellites are harder to upgrade, the design should require no changes to satellites. Moreover, since current satellites assume ground stations as the only egress points, a key challenge is to integrate UT-based egress and relaying into the current framework while keeping the satellite side transparent. At the same time, given the scale of existing deployments, casting UTs as relays or local access points should not require hardware replacement.

The scale of the LEO network will considerably inflate after incorporating numerous UT-based gateways and relays. Different from the state-of-the-art LEO networks, now the UTs are no longer end hosts only; they become part of the forwarding infrastructure and must be considered in routing and data forwarding at the scale of millions. More seriously, all these incorporated UTs’ links are intermittent due to LEO mobility. At the speed of 27,000 km/h, each LEO satellite can cover each UT for 3–10 minutes, after which the UT must hand over to another satellite to maintain connectivity. This results in tons of USL changes per second over this large-scale LEO network topology, thereby significantly challenging the scalability, efficiency, and reliability of routing and data forwarding.

Unlike ground stations that are fully provisioned and managed by the network operators, UTs are privately owned and operated. While C1 and C2 highlight the feasibility and scalability challenges of enabling UTs as relay or breakout nodes, a further challenge lies in their willingness to participate. Providing such services is not free: a local breakout UT must contribute its own backhaul capacity and pay for Internet access and electricity, while a relay UT consumes additional device power and reduces its own usable capacity. Without incentives, participation may be insufficient. If incentives are misaligned or absent, the system risks either insufficient participation or opportunistic misuse. A practical design must incorporate an incentive mechanism that sustains continuous participation and adapts to spatial and temporal demand variations.

CrowdLink upgrades UT software to support two optional roles:

• $\mathrm{■}$

  Local access point: As shown in Table 2, commodity UTs are equipped with Ethernet ports or WiFi. They can use these interfaces to connect to the Internet and act as a local access point.

• $\mathrm{■}$

  Inter-satellite relay: [2, 10] show that many commodity UTs have backup beams to connect more than one satellite synchronously or asynchronously. CrowdLink leverages this capability, when present, to provide an additional satellite-to-satellite forwarding option through UTs. As shown in Figure 7, each relay UT can inspect incoming packets and tunnel them over the secondary beam. The UT acts as a transparent inter-satellite relay, without requiring any changes to satellite forwarding or routing logic.

Once the UTs can act as local access points and relay nodes, the operator-side connectivity controller should be capable of utilizing them. In real LEO networks today, the controller is already responsible for computing all UTs’ satellite schedules for its beams, i.e., the list of LEO satellites this UT’s primary beam should connect to over time (every 15s in Starlink [52, 51]). CrowdLink reuses this feature and applies to the secondary beam as well to generate its satellite schedules for relay UTs, ensuring that the second beam consistently connects to satellites required for relaying. This extension allows the controller to orchestrate dual-beam relays while preserving backward compatibility.

To request for a side path for more bandwidth and/or lower latencies, a UT can contact the controller to activate a secondary gateway. This procedure has been available in today’s LEO network, except that this secondary gateway referred to a dedicated ground station (PoP). CrowdLink reuses the same request workflow, but allows the controller to add a local access point UT as an additional egress option. For each request, the controller can select one or more UT-based gateways based on their location, bandwidth, and other factors. These UT gateways can co-exist with existing operator-managed PoPs: the requesting UT continue to rely on them as the baseline, while UT-operated gateways serve as supplementary performance boosters.

For backward compatibility, CrowdLink implements the data tunneling across UTs without changing satellites. After selecting local access point UTs, the controller computes paths from normal UTs to its local access point UT via relay UTs (see details in §4.2). These paths are distributed to participating UTs. Each UT maintains a local path table keyed by $(\text{normal UT},\text{local access point UT})$, which stores the ordered list of UTs along the path. Packets are then tunneled hop by hop according to these tables. Since all tunneling states are installed at the UT-side, satellites can be unaware of inter-UT relaying and forward traffic as usual.

Next, we walk through CrowdLink’s uplink and downlink data tunneling using this UT overlay:

• $\mathrm{■}$

  Uplink tunneling: Figure 8(a) shows how to tunnel traffic from the normal UT to its local access point. Packets originate at the normal UT, where CrowdLink intercepts outgoing traffic and decides whether to tunnel via a local access point UT. If so, the packet is encapsulated with a new routing header specifying the next-hop UT⁴⁴4There are various options to implement this feature, such as IPv6’s hop-by-hop header, SRv6, IP-in-IP encapsulation, or MPLS.. If multiple local access point UTs are assigned, packets can be distributed to leverage all paths. Relay UTs inspect the packet, update the header using their path tables, and tunnel it via secondary satellite to the next hop. Finally, the local access point UT verifies itself as the target, decapsulates the payload, and tunnels the original packet to the terrestrial Internet through its Ethernet port, maintaining NAT state for return flows.

• $\mathrm{■}$

  Downlink tunneling: Figure 8(b) shows the downlink process. Packets arriving from the terrestrial Internet are intercepted by the local access point UT, which consults its NAT table to identify the target normal UT. It then encapsulates the packet and tunnels it along the precomputed path distributed by the controller. Relay UTs update the routing header and tunnel accordingly. Upon receipt, the normal UT decapsulates the packet and delivers it to its local devices.

Since CrowdLink relies on user-operated, potentially untrusted UTs, it is understandable for users to be concerned about their security and privacy. The UT-based gateways and relays may eavesdrop on other UTs’ data packets to leak privacy, manipulate them to violate integrity, or drop them to induce DoS attacks.

CrowdLink counteracts these threats with three measures. First, when a normal UT requests the controller for a side path, the controller will allocate an operator-controller PoP, instruct the allocated UT-based gateway to redirect traffic to this PoP, and establish an end-to-end secure tunnel between the normal UT and this PoP (which is already available in Starlink [28] and hence reusable)⁵⁵5Note that these PoPs can still be decentralized across the Internet and not necessarily co-located with UT-based gateways to prevent bottlenecks.. This tunnel’s end-to-end encryption and integrity protection can prevent intermediate relay/gateway UTs’ eavesdropping and tampering. Second, to combat user behavior leakage from packet header metadata, CrowdLink can optionally use encrypted hop-by-hop packet encapsulation across multi-party UT relays and gateways, similar to the onion routing (Tor [33]). Third, CrowdLink penalizes misbehaving gateways and relays based on user feedback. After assigned a side path comprising UT gateways and relays, each normal UT routinely measures its performance (e.g., throughput, delay, and data loss) and reports these metrics to the controller. Based on these metrics from all these normal UTs, the controller can reliably detect underperforming or malicious UT relays/gateways, stop using them in future side-path assignments, and hence cut their rewards in §4.3 and block their misbehaviors.

For legacy UTs, CrowdLink’s gateway or next-hop relay UT is indistinguishable from another ground station/PoP. It can use them in the same way as using a secondary PoP. For ground stations, CrowdLink still keep them as the UTs’ default gateway and complement them with relay/gateway UTs as side paths. For satellites, CrowdLink’s UT gateways/relays are no different from a ground station. Its inter-UT tunneling is also transparent to satellites to facilitate their co-existence.

CrowdLink organizes UTs into a forest of trees, each rooted at a local access point UT and composed of relay UTs and normal UTs as child nodes. For each newly added UT (relay UT or normal UT), the controller incrementally attaches it to an existing tree by performing the steps illustrated in Figure 9.

• $\mathrm{■}$

  Step 1: Discover the upstream parent. For a new UT, the controller searches for potential parents (local access point UTs or relay UTs already in a tree) within a radius of $L$, corresponding to the diameter of a satellite coverage area. For each candidate parent, the controller retrieves its satellite access schedule.

• $\mathrm{■}$

  Step 2: Cross-check of satellite schedules. For each candidate parent, the controller evaluates two metrics: (i) schedule consistency, defined as the duration over which the parent’s access schedule remains available for the new UT (i.e., the time window during which both UTs can concurrently access the same satellite), and (ii) load level, measured as the number of existing downstream UTs already attached to the parent. Only candidates whose schedule consistency exceeds a threshold are retained. They are then ranked using a combined score that prioritizes local access point UTs over relay UTs, longer schedule alignment, and lower load levels. This heuristic balances stability and load distribution while avoiding unnecessary relay hops.

• $\mathrm{■}$

  Step 3: Schedule replication. The top-ranked candidate is selected as the parent. If the parent is a relay UT, its primary schedule is copied to the child (secondary beam for relay UT). If the parent is a local access point UT, its schedule is directly replicated to the child. This replication aligns the satellite access of the parent and child UTs, increasing the likelihood that their logical link remains available despite satellite mobility.

By repeating this process, the controller incrementally expands each tree outward from its local access point root. Once a normal UT joins a tree, it is implicitly associated with the local access point UT at the root. This hierarchical organization masks satellite dynamics, improves the utilization of underloaded UTs, and reduces the need for frequent path recomputation, thereby enhancing scalability and service continuity.

Because each local access point UT offers limited bandwidth and the distribution of downstream UTs may be uneven, CrowdLink further interconnects local access point-rooted trees to form a stable UT-level graph (Figure 10). This interconnection allows the controller to expose each normal UT to multiple reachable local access point UTs and to balance the load across them.

• $\mathrm{■}$

  Step 1: Candidate discovery. For each relay or normal UT, the controller searches within a radius $L$ for local access point UTs or relay UTs in other trees and compares their schedules. Candidates whose schedule consistency exceeds a threshold are retained and ranked by the local access point UT of their tree, node type, and duration of alignment.

• $\mathrm{■}$

  Step 2: Cross-tree interconnection. The controller establishes cross-tree links among the selected candidates, prioritizing direct connections to local access point UTs from different trees to avoid unnecessary multi-hop relaying. Unlike intra-tree attachment, this process does not replicate schedules. Instead, the controller records these aligned links as additional forwarding options.

Through these steps, the controller constructs a stable UT-level graph in which local access point-rooted trees are interconnected by cross-tree links. This structure enables load-aware assignment of multiple local access point UTs to each normal UT, improving per-UT performance and increasing the utilization of otherwise wasted satellite capacity.

Given the stable UT-level graph, computing a path from a normal UT to a local access point UT reduces to a hierarchical tree traversal. Starting from the normal UT, the controller traverses upward along the intra-tree links until reaching the root local access point UT of the corresponding tree.

Figure 11 illustrates the process of relaying computation. When a normal UT (Source UT) initiates a service request, the controller attaches it to the tree rooted at local access point $U{T}_1$ and assigns $U{T}_1$ as its local access point. If the source UT requests additional bandwidth, the controller may allocate another local access point, such as $U{T}_4$. Using aligned inter-tree links, the source UT is then treated as a leaf in the $U{T}_4$-rooted tree. In each tree, the controller performs a bottom-up traversal from the source UT by repeatedly following stabilized parent links, yielding the corresponding relaying paths ($SourceUT\to \mathrm{\cdots }\to U{T}_1$ and $SourceUT\to \mathrm{\cdots }\to U{T}_4$).

Once the paths are determined, the controller distributes them to all involved UTs, including the source, intermediate relays, and local access points. Each UT installs the received path into its local path table for packet forwarding. Because UT-level links are stabilized through schedule alignment and replication (§4.2), these paths remain available for extended periods. As a result, CrowdLink avoids frequent path recomputation and reduces update signaling overhead, enabling scalable and highly available routing under LEO mobility.

In CrowdLink, the connectivity controller assigns a per-unit reward price to each relay UT or local access point UT based on the local supply-demand condition. Both supply and demand are time-varying. Relay and gateway UTs may join or leave, and normal UTs’ side-path requests can fluctuate (e.g., due to diurnal usage patterns). CrowdLink dynamically adapts prices to reflect these changes, so that relays and gateways in scarce or highly loaded areas tend to receive higher per-unit rewards, while rewards decrease when supply exceeds demand. This takes three steps:

• $\mathrm{■}$

  UT-level load estimation. The controller first estimates the load ratio ${\rho }_i$ for each relay or local access point UT $i$: ${\rho }_i=\frac{{\mathrm{𝑙𝑜𝑎𝑑}}_i^{actual}}{{\mathrm{𝑙𝑜𝑎𝑑}}_i^{rec}}$, where ${\mathrm{𝑙𝑜𝑎𝑑}}_i^{rec}=\frac{b_i^{\text{avail}}}{b_{\text{unit}}}$ is the recommended load for $i$, $b_i^{\text{avail}}$ is UT $i$’s contributed bandwidth, and $b_{\text{unit}}$ is the estimated bandwidth required based on normal UTs’ requests to the controller. ${\mathrm{𝑙𝑜𝑎𝑑}}_i^{actual}$ is the number of downstream normal UTs in the subtree rooted at UT $i$, capturing the amount of traffic that traverse it. ${\rho }_i>1$ indicates UT $i$ is overloaded and suggests that stronger incentive is needed.

• $\mathrm{■}$

  Region-level load estimation. To scale to millions of UTs, CrowdLink groups UTs’ pricing by geographic regions. It partitions the Earth’s surface into disjoint regions, each no larger than a satellite footprint. For each region $R_k$, the controller computes the average load ratio:

  $${\overline{\rho }}_k=\frac{1}{|R_k|}\sum _{i\in R_k}{\rho }_i$$

  The base unit price for region $R_k$ is then:

  $$p_k^{\text{base}}(r)=p_0^{(r)}\cdot \left(1+\alpha \cdot \max (0,{\overline{\rho }}_k-1)\right)$$

  where $r\in \{\text{relay},\text{local access point}\}$ specifies the UT’s role, and $p_0^{(r)}$ is the baseline cost for that role (with $p_0^{\text{local access point}}>p_0^{\text{relay}}$ to reflect higher costs such as Internet access). Using $max(0,{\overline{\rho }}_k-1)$ ensures that price inflation only occurs when regional demand exceeds sustainable capacity, avoiding over-incentivizing underutilized areas.

• $\mathrm{■}$

  Contribution to topological connectivity. Beyond traffic load, CrowdLink also adjusts rewards based on a UT’s contribution to connectivity. The goal is to reward UTs in positions that connect many normal UTs, especially in areas where relays or gateways are relatively scarce. Specifically, let $d_i$ denote the path depth of UT $i$ (the maximum hop count from a normal UT to $i$), and let $s_i$ denote a normalized scarcity score derived from the fraction of normal UT paths traversing $i$ and the number of equivalent UTs within the same tree. The final per-unit reward price for UT $i$ is:

  $$p_i=p_k^{\text{base}}(r_i)\cdot (1+\beta \cdot d_i)\cdot (1+\gamma \cdot s_i)$$

  where $\beta ,\gamma$ are tunable coefficients. This formulation is intended to bias rewards toward UTs in high-demand regions and critical topological positions, so that incentives better reflect their contribution to connectivity. Based on this unit price, the connectivity controller pays each local access point UT (relay UT) for the traffic volume it offloads (relays).

An efficient incentive mechanism requires reliable and trustworthy measurement of forwarded traffic. CrowdLink deploys lightweight traffic accounting modules on all participating UTs. Each source, relay, and local access point UT locally records forwarded traffic and signs its report with verifiable credentials. At the end of each charging cycle, these signed records are submitted to the controller for consistency checks and settlement (e.g., using trust-free two-sided measurements [26], game-theoretical charging negotiation [46], or reputation-based charging [49]). The controller multiplies the settled traffic volume by the dynamic unit price $p_i$ to compute (i) the bill charged to each normal UT and (ii) the rewards allocated to each relay and local access point UT. By combining geographic demand-aware pricing with verifiable accounting, CrowdLink aligns the incentives of normal UTs, serving UTs, and the LEO network operator, resulting in a triple win.

We evaluate CrowdLink using a trace-driven emulation based on Starlink, the largest operational LEO satellite network to date. Our emulation incorporates all active Starlink satellites and 227 ground stations. We model the user demand based on Starlink’s officially reported subscriber count (4.6 million) and the distribution of active users released in October 2024 [8]. We partition the Earth’s surface into disjoint 1°$\times$1° latitude-longitude cells and assign users to cells accordingly. For each cell, we estimate the available satellite capacity based on satellite coverage, user distribution [8], and Starlink’s officially published regional per-UT data rates [21], assuming each satellite provides 96 Gbps radio link capacity [9]. The estimated unused GSL/USL capacity above each cell constrains the maximum bandwidth that relay UTs and local access point UTs within the cell can collectively contribute. To evaluate CrowdLink at scale, we proportionally sample 150,000 users according to the reported UT distribution. Among these sampled users, 50% are configured as local access points and 30% as relays. We compute per-UT bandwidth and satellite capacity utilization under varying activation ratios. We model the state-of-the-art LEO network architecture shown in Figure 3 as the baseline, where user traffic is uplinked to satellites and must be downlinked through ground stations before entering the terrestrial Internet.

Figure 14(a) shows the per-UT bandwidth improvement of CrowdLink over the baseline. In the baseline, all UTs compete for limited GSL capacity, so GSLs become the bottleneck and limit per-UT bandwidth, especially in hotspot areas. CrowdLink improves per-UT bandwidth by leveraging unused USL capacity to construct additional UT-based landing paths. A source UT can simultaneously use the default GS-based path and a controller-orchestrated side path that lands traffic through a local access point UT, thus increasing the total available bandwidth. When 10% of global UTs are active as sources, CrowdLink improves each UT’s bandwidth by 3.52$\times$ (up to 21.88$\times$). As more source UTs request side paths, multiple sources compete for the limited unused capacity that each local access point UT can contribute, so the average improvement gradually decreases. Even when all source UTs are active, CrowdLink still improves per-UT bandwidth by 3.22$\times$ on average, with much larger gains (65.27$\times$) in hotspot areas where baseline throughput is severely constrained.

Figure 14(b) shows how CrowdLink improves the utilization of idle satellite capacity in Starlink. In the baseline, user traffic must be downlinked through ground stations. Due to the uneven distribution and limited capacity of satellite-ground links, a significant fraction of satellite capacity remains idle. We calculate the baseline utilization by measuring the aggregate bandwidth consumed by UTs in each region and comparing it to the aggregate satellite-ground link capacity, based on Starlink’s per-satellite satellite-ground capacity (96 Gbps [9]) and regional user distribution [8]. CrowdLink enables user traffic to land through local access point UTs through underutilized USLs, unlocking satellite capacity that would otherwise remain unused. When all UTs request side paths, CrowdLink nearly doubles the overall LEO network capacity utilization compared to the baseline. As more UTs participate in CrowdLink, a larger portion of idle satellite capacity is activated, leading to higher utilization.

Figure 15 shows logs captured on the hosts behind each Starlink Dishy. The source UT encrypts the original payload, encapsulates it, and updates the destination address to the next relay UT. Upon receiving the packet, the relay UT rewrites the destination address to the controller-assigned local access point UT. Finally, the local access point UT decapsulates and decrypts the payload and forwards the original packet to the Internet. We adopt tcpdump tools at all UTs, confirming that the source UT successfully receives response packets from Internet servers, routed through the relay and gateway UTs. These results evaluate CrowdLink’s feasibility in practice.

We compare the end-to-end throughput under UDP and TCP with/without CrowdLink. Figure 16 presents the results and reveals two key observations. First, UDP achieves relatively stable throughput, while TCP exhibits more fluctuations due to its sensitivity to packet loss and latency variation. Second, compared to baseline, CrowdLink significantly improves the data rate, reaching 24.91 Mbps in the uplink and 49.95 Mbps in the downlink. To understand the performance limits, we further examine the throughput bottleneck. As shown in Figure 16(a), the uplink is the bottleneck in both baseline and CrowdLink, which limits the end-to-end throughput. This aligns with Starlink’s public measurements [21], which report an average global uplink rate of 24.95 Mbps. Since it is largely independent of user or ground-station distribution, we attribute this to operator-imposed rate limiting. If such limits are relaxed in the future, CrowdLink can further increase throughput.

We measure the packet processing latency introduced by CrowdLink to assess whether UT-side processing could become a performance bottleneck. Across all roles, the additional latency introduced by CrowdLink is on the order of tens to a few hundred microseconds. Specifically, the source UT adds 44.89 $\mu$s in the uplink and 40.60 $\mu$s in the downlink. A relay UT introduces an average processing latency of 246.74 $\mu$s, while the local access point adds 189.29 $\mu$s in the uplink and 171.39 $\mu$s in the downlink. Compared to the end-to-end latency of LEO satellite networks, which is on the order of tens of milliseconds, this processing overhead is negligible and does not limit performance.

We first evaluate the stability of relaying paths and the associated signaling overhead. In the baseline, each relay UT independently schedules its secondary beam, so frequent satellite handovers directly translate into frequent logical path changes. In contrast, CrowdLink organizes relay and local access point UTs as a tree rooted at local access point UT and stabilizes logical connectivity by replicating the parent UT’s beam schedule to its children. Figure 17(a) shows the frequency of path updates from source UTs to their assigned local access point UTs under varying local access point ratios. Compared to the baseline, CrowdLink reduces the path update frequency by 2.63–3.12$\times$. With more local access points, source UTs are more likely to establish direct connections, further reducing path dynamics. Since each path update requires the controller to push the updated routes to all UTs along the path, improved stability directly reduces signaling overhead. As shown in Figure 17(b), CrowdLink reduces control messages by 5.9–9.0$\times$.

We next examine how the number of relay UTs affects performance. Figure 18(a) shows the results when 10% of UTs act as local access points. Adding relay UTs increases the fraction of source UTs that can reach a local access point. However, since all traffic must ultimately exit through local access points, additional relays also intensify competition for limited egress capacity. As a result, the additional per-UT bandwidth improvement drops from 0.77$\times$ to 0.64$\times$, and the utilization of satellite capacity slightly drops from 24.91% to 24.03%. Figure 18(b) shows the case where 50% of UTs serve as local access points. Here, most source UTs already connect directly to local access points, thus relay UTs play a less critical role. Thus, increasing the number of relay UTs leads to only mild performance changes: the bandwidth improvement drops from 2.11$\times$ to 2.06$\times$, and utilization declines from 29.24% to 29.00%. These results indicate that relay UTs primarily extend connectivity, while network performance is ultimately constrained by the number of available local access points.

We now evaluate how scaling the number of local access point UTs influences system performance. We tune the number of relay UTs to ensure that as many source UTs as possible can connect to at least one local access point, either directly or via relays. As shown in Figure 19, increasing the number of local access point UTs significantly improves both per-UT bandwidth and satellite capacity utilization. When all source UTs are active, the bandwidth improvement of CrowdLink over the baseline rises from 0.81$\times$ to 4.21$\times$, while the utilization of total contributed bandwidth increases from 23.47% to 31.65%. Unlike relay scaling, which shares a fixed set of exit UTs, each additional local access point UT contributes new uplink and downlink capacity and directly serves nearby users. This reduces contention and shortens paths, leading to higher per-UT throughput and better utilization of satellite resources.

We finally compare the end-to-end latency from source UTs to their gateways. In the baseline, traffic is uplinked to satellites and downlinked through operator-managed ground stations. In CrowdLink, traffic is instead forwarded to user-controlled local access point UTs. Figure 20 shows the latency distribution. In our simulation, most source UTs offload traffic after a single satellite hop. This is because Starlink users are predominantly located near deployed ground stations, as reflected in the reported user distribution [8]. Since local access points are often geographically closer than fixed ground stations, CrowdLink achieves comparable to or lower latency than the baseline, reducing path delays by 6.8% (up to 22.97%). As the number of local access point UTs increases, more source UTs can establish direct connections, further shortening paths. These results indicate that CrowdLink preserves competitive end-to-end latency while providing more stable paths and higher capacity utilization.