Research problems in satellite-based broadband, à la SpaceX Starlink

I’ll first give brief context on the recent industry developments and why they matter. Then I’ll outline several research directions that I believe will lead to both top-tier publications and long-term industry impact. Lastly, to help you get started, I’ll point you to more in-depth readings and tools for research.

Thousands of satellites providing low-latency broadband Internet

Five of Starlink’s planned orbital shells coded into different colors. Some shells, e.g., the dense red and green ones, do not cover the Earth’s poles.

As of December 2021, Starlink comprises 1,732 working satellites, making it the largest constellation that has ever been deployed by far. Altogether between Starlink, OneWeb, Amazon’s Kuiper, Telesat, and many others, more than 10,000 satellites may be deployed by 2030. These constellations will all operate in low Earth orbit (LEO), a few hundred to at most 2,000 km above the surface, and provide low-latency broadband across the globe. Note that with LEO satellites (unlike for satellites in Geostationary orbit, GEO), ground-to-satellite-to-ground latencies can, in theory, be well under 10 ms. For communication between endpoints separated by a few thousand kilometers or more, LEO networks (with inter-satellite laser links deployed) can provide lower latency than even terrestrial fiber.

Why is LEO broadband a big deal?

Even in the most pessimistic scenario, LEO networks will soon serve millions of consumers. This is just the low-hanging fruit, because satellite-based services that are clearly inferior (much higher latency using GEO) are already serving around 2 million customers in the Americas alone. A more optimistic outlook may suggest hundreds of millions of users globally within a decade, with many served indirectly, such as by LEO satellites providing backhaul connectivity for terrestrial cellular towers in rural/remote areas. Further, LEO connectivity has myriad applications beyond consumer broadband, including disaster management, inflight connectivity, and shipping, offshore, and other remote-site industries. Even cloud operators like Google and Microsoft, with state-of-the-art terrestrial networks, have inked partnerships with Starlink to benefit from its global low-latency reach.

The below graphic summarizes the satellite network design space, capturing (coarsely) the relationship between some of the design options and their outcomes along the axes of latency and capacity/market-size. (I’m conflating the latter two, which are aligned, but not the same thing.)

Massive-scale LEO can provide both low-latency and high throughput for a large user population, depending on how many satellites are used in the system and the per-satellite bandwidth.

Open research challenges and opportunities

At my opening talk for LEOCONN 2021, the first workshop on satellite mega-constellations, I outlined 20 research challenges in this area, most of which I believe can and will be developed into top-tier research publications, and will inform and influence future industry activity. I will only touch on three broad sets of questions in this writeup, pointing interested readers to the talk’s recording (https://youtu.be/-kxgBI1osl0) for the rest.

Opportunity 1: Mixed-orbital constellation design

The easiest-to-explain research opportunity uses the context I set up just above in describing some of the design options for satellite networks. The idea is simple: combine the strengths of LEO-only and MEO-only networks. (MEO networks operate in medium Earth orbit.)

LEO networks can provide low-latency, but being closer to the ground means that each satellite’s coverage cone is small, and you need many hundreds if not thousands of satellites to provide coverage (at great expense). MEO networks (at certain orbital heights) can provide global coverage with a few tens of satellites while still providing sub-50 ms latencies. Thus, one could imagine building a system with (say) a hundred LEO satellites and a few tens of beefier MEO satellites, such that low-latency traffic (typically also low in volume) uses LEO connectivity, while throughput-focused traffic uses MEO. This would likely result in a substantially cheaper network, albeit requiring careful partitioning of traffic across the mixed orbital design. I’ve positioned this proposal in the design space schematic below. The challenges include, for instance, figuring out how best to combine different types of orbits for specific targeted traffic mixes, how to partition traffic in a reasonably transparent way (hiding complexity without violating neutrality expectations), and how the optimal design might evolve as satellite launch costs shift and externalities like space-congestion and night-sky-pollution are priced.

A system combining a few hundred LEO satellites and a few tens of MEO satellites could be less expensive than mega-constellations and provide both low-latency and high throughput for different traffic classes.

Opportunity 2: Congestion control and traffic engineering

Our measurement and analysis work showed that as LEO satellites zoom around in Space at 27,000 km/h, the structure of paths and end-end latencies evolve over time. These changes cause packet reordering (as paths sometimes shorten, and earlier-in-sequence packets arrive after later-in-sequence packets), which congestion control can misinterpret as loss. Loss is also an undesirable primary signal of congestion for an entirely separate reason: operating with full or substantially occupied buffers would negate the low-latency promise of these networks. However, the other potential congestion signal — increasing delay — is also noisy in this case, as paths naturally elongate and shorten independent of congestion.

It is an open problem how to design congestion control for such conditions where both loss and delay are noisier and more unreliable than in typical terrestrial conditions. Of course, if one were to “subtract” the delay changes caused by (predictable) satellite motion, the problem seems easy, but the issue is that this requires a break in abstraction: now the endpoints have to be network aware to be able to perform this “subtraction”. In general, an end-end path may traverse both LEO segments and ground segments, and one should not expect endpoints to care about the network-layer path in making their transport-layer decisions.

Another potential solution involves transport proxies that terminate endpoint connections and can, by virtue of sitting at the LEO network edge as middleboxes, appropriately account for satellite motion in making congestion control decisions. This would be a break from the end-end principle, and comes with costs: if the proxy dies, connection state would be lost, or worse, could be corrupted (e.g., the proxy ACKs some data to the sender and then dies, without the receiver seeing the data). Equally worrisome, this model would also not work with end-end encrypted QUIC transport.

Finally, the utilization of certain network links can change dramatically as they end up on a route between traffic hotspots, or move off of such routes. (A small visualization of this is in the example below; details are in our paper.) Such changes imply that congestion control needs to converge fast in the presence of shifting bottlenecks and the extent of congestion on them. Some of this could potentially be tackled at the network layer, with careful traffic engineering to smoothen out the impact of upcoming path structure changes by gradual shifts in traffic across multiple routes.

The utilization of different links on an end-end path in an LEO network is color coded here, with thin/green being low utilization, and warmer colors or thicker lines indicating higher link utilization. Notice the link on the far left and the links in the center-right part of the image — their utilization changes across the snapshots.

Thus, I expect there to be interesting followup work on rigorously evaluating numerous current congestion control proposals in challenging LEO settings, as well as in designing new congestion control and traffic engineering schemes that address the issues outlined above.

Opportunity 3: Integration with cloud and content networks

I noted above the Google and Microsoft partnerships with Starlink. If you’ve made it this far into the writeup, you are likely familiar with the bespoke WAN designs of these operators, B4 and SWAN respectively. These networks use software-defined networking techniques to manage global inter-datacenter connectivity. The Starlink partnerships open up a new and interesting set of research questions:

• What customizations do the B4/SWAN networks need to incorporate the dramatically different connectivity LEO networks provide? Are the existing solutions already capable of taking advantage of LEO links with link characteristics that are very different from terrestrial fiber links in terms of packet reordering, latency variation, bit error rates, and random loss?
• Where both terrestrial and LEO connectivity are available, and the LEO link offers lower latency (for long distances, as noted above), how to best use limited LEO capacity?
• Is there value in sophisticated operators like Google and Microsoft getting the raw channel, minus forward error correction, from the LEO operator? One could, for instance, imagine the cloud operators wanting to customize the degree of FEC to arrive at the best operational tradeoff with latency. (Analogously, some customers of terrestrial microwave networking, such as high-frequency traders, typically get an FEC-free channel, as they place a premium on latency.)
• If the cloud operator wanted to resell LEO connectivity as a premium enhanced turbo nitro networking service to their customers, how would they define SLOs for such time-variable connectivity?

Lastly, beyond the announced partnerships by Google and Microsoft, can content distribution networks also benefit from the low-latency connectivity offered by LEO networks? If so, how should a CDN architecture incorporate LEO connectivity and potentially, on-satellite storage and compute?

Resources to help you get started with LEO research

• For a more fleshed out read on the potential and challenges of LEO networks, I recommend our HotNets 2018 work. (2 hours)
• For learning about the nuts and bolts of an LEO network — what parameters describes such a network’s structure, how connectivity works — I suggest section 2.1 in our CoNEXT 2019 paper. (1 hour)
• If you are searching for interesting research problems to explore, check out my opening talk at LEOCONN 2021, where I touch upon 20 open research challenges in satellite networking. (30 min)
• We spent substantial effort in building simulation tools that bake in many of the abstractions that would be new to networking researchers, such that the bar for entry into this new research area is as low as possible, with different frameworks for different types of work at the graph/topology level, for routing, and for full-fledged packet-level simulations.

I am grateful to all my co-authors and collaborators on the above listed papers and other work in this area for shaping my thoughts on this exciting space. Debopam Bhattacherjee deserves a special thanks — as is often the case with excellent PhD advisees, I learnt as much or more by working with him as he did by working with me :-)

Closing notes

In my view, mega-scale LEO networks are “one giant leap” in Internet infrastructure, and could very well improve a billion lives (or more!) in the long run. There is a huge amount of opportunity for innovation at every layer of the network stack, and for every stakeholder in the networking ecosystem. I only sketched out a few research ideas here, and many more are presented in my LEOCONN talk. I’m also certain that there are entire sub-areas that my writeup is missing, e.g., there must be many challenges just in the ground-to-satellite radio segment. I thus hope to see an explosion of activity on this front at top-tier networking research venues.