Network topology design at 27,000 km/hr | Hacker News Reader

Network topology design at 27,000 km/hr

blog.apnic.net

83 pointsolivernyc13 comments

The first generations of Starlink satellites will serve as bent pipes. They're not doing intersatellite links. This will require dozens of small trunk-link earth stations around the USA, in the same general region for rural services.

For example an earth station near the fiber in Boise, ID would have visibility for bent-pipe type relay to the same satellites presently overhead of many very hard to reach, rural, remote Idaho locations. The remote parts of ID which are presently only serviced by small geostationary VSAT terminals (viasat/wildblue/hughesnet etc).

About a year and a half ago Elon Musk fired the part of the starlink team, based on Redmond WA who wanted to go directly to intersatellite links in the first generation, most of whom have now ended up at Kuiper.

https://www.reuters.com/article/us-spacex-starlink-insight/m...

This also means that in order to establish service in a particular area it will require putting in place starlink earth stations in the general region. Meaning that there might be full satellite coverage over the same latitudes in Canada, and Russia on the same calendar date, but Canada will receive live service much earlier.

That’s really disappointing to learn. It was the inter-satellite linking part that make it really interesting (to me) and which promised to provide big latency improvements over fiber (over longer distances). I wonder if it proved too hard in practice?

Elon Musk has stated that until they have inter-satellite laser links deployed, they can get wide area low latency communications by relaying via ground stations at a high slant angle. I built a simulator and ran an analysis of this, and actually it works pretty well. My video analysing all this is here: https://youtu.be/m05abdGSOxY

There's a variety of software packages you can use to simulate the ground footprint of a starlink satellite, from the TLEs (two line elements). Or Iridium or anything else.

It's a circle many hundreds of km wide. Assuming that an earth station will have a minimum look angle of about 18 degrees above the horizon, one can calculate the serviceable area for customer and trunk link spot beams within the satellite's moving footprint.

The scenario shown in your youtube video has uses for HFT and similar very latency sensitive applications. But because it's RF, there's no way that a chain of starlink satellites relaying through multiple ground stations will compete in raw throughput and capacity with fiber. Remember that a single IT standard 100GHz grid DWDM channel is a few terahertz wide, and 80 channels can easily fit in the conventional bands of a long haul DWDM system in just two strands of fiber.

Yes, that's correct, but the interesting part is not the footprint, but the latency and variability of the dynamically routed paths you can obtain. That's what I simulated. I also made some modifications to how you'd normally route such a network, because the conventional approach wasn't fast enough if you have a wide choice of groundstations and the topology is continuously changing. The animations in the video are doing the route calculations in realtime once per frame of video; I was pretty pleased with those optimizations. One surprise, for me at least, was that there are paths where you sometimes want to relay via ground stations, even when the satellites have inter-satellite laser links. That's in the video towards the end.

Edit: in response to the point you added about bandwidth: that's correct - there's no way the ground relay path competes with fibre on bandwidth. There are, however, many potential uses that require low latency and are not high bandwidth.

It's definitely on the design road map, and the starlink satellites are designed to have relatively low orbits and short service lives. But it was too ambitious to jump directly to in the first generation. The ground footprint of visibility of a starlink satellite looking down, with its various spot beams, is a circle many hundreds of km in diameter. It's not like they'll need to put earth stations in a vast number of areas, just concentrated in small to mid sized cities with decent fiber connectivity that happen to be within a 300-400km radius of the remote areas to be served.

If you enjoyed this, Eccentric Orbits: The Iridium Story by John Bloom is a good book on the similar topic from few decades back. Spiced with a healthy bunch of politics, entrepreneurship and action.

Have to second this comment. The Audible version of it had me riveted. A great story well-told, with a raft of good quotes, such as "People didn’t like game changers in the 90s anymore than the owners of of the Erie Canal liked the transcontinental railroad. New technology always leaves a battlefield littered with bodies."

While general purpose satellite internet is nice, I'm wondering (in brainstorm mode) about whether there are alternative situations for which an architecture based on such fast moving satellites would be desirable rather than a challenge.

Below are some unfiltered thoughts on this -

1. Treat satellites like postboxes. If ground to satellite link is fast, use it to upload TB of data to these satellites and let them transport it across oceans and dump them at destinations (article notes it takes 6mins to cross the Atlantic).

2. Serve applications off satellites - sort of like CDN edge servers. Thinking Cloudflare Workers. No idea what their capacities are though.

3. Distribute updates to devices or end points. Tesla updates?

4. Make the satellites pick up and drop data between specific ground stations.

Any intelligent ways to abuse this system?

Yoo, I met the author when I toured ETH Zurich for visit days. If you're reading this, super excited for you :D

Are there any companies that are doing something similar in the bay area?

oneweb, kuiper, starlink, telesat, and SES (o3b) are all hiring. Not necessarily in the bay area.

OneWeb has an office in Mountain View apparently: https://www.oneweb.world/contact-us

Reply on news.ycombinator.com