[Starlink] Why ISLs are difficult...

[Mike Puchol]

I can talk with a tiny bit of knowledge, having worked with FSOC technology for ~3 years now (and being a curious nerd!).
> - Linking two satellites that follow each other on the same orbit is the
> easiest exercise. I gather that Starlink have ticked that one off. It's
> probably not too useful on its own for most real scenarios though:
> ground stations move through orbital planes. Also, two arbitrary ground
> stations between one would want to forward will probably not be
> connectable by a chain of satellites all in the same orbital plane.
> - Linking two satellites that are in different but adjacent orbital
> planes is one notch up but probably not a lot harder if you master
> gimbal / mirror control. You have some relative movement, but most of
> the time it's slow. Low hanging fruit if it's not already been picked.
> - Linking two satellites in range of each other that satisfy some
> arbitrary criterion (minimum distance, desired direction): A bit harder.
Each satellite has three optical heads, which from SpaceX renderings, have two mechanical rings each, allowing the pointing of the beam anywhere, except through the satellite. See https://www.starlink.com/assets/images/prd-default/satellites/Module_1_Carousel/4_SpaceLaser.jpg

With three heads, you link to the satellite in front and behind (in-plane), and with the third, to the next plane (cross-plane), or cross-shell to above/below. The first two are “easy” as the satellites barely move with respect to each other, while the third needs tracking between satellites moving in different directions and speeds, so it’s “hard” (but not impossible, optical links to high-speed craft have been demonstrated already). To give an idea of how the links work, I'll use this constellation status chart (real orbital positions extracted from TLEs, so not made up):



The Y axis shows how far along the plane a satellite is (north/south axis, so-to-speak), the X axis shows how far along the equator the plane is (east/west axis). The green arrow shows the direction of the satellite’s rotation, the red arrow the direction of their precession. On three planes around 60º on the X axis, I have drawn green lines representing in-plane ISL, and red lines representing cross-plane ISL. All satellites that are blue dots are in their right orbital slot and at the same altitude, which means they all move together - they do not shift in position relative to each other. If you redraw this chart an hour later, the planes will have moved left, and the satellites up, but they will still be in the exact same position relative to each other.

In terms of ground station coverage, once the entire ISL “mesh” is complete, you could find a satellite with gateway coverage somewhere, all the time. The path will change every few minutes, as the satellite linking to the gateway changes, but it’s in the order of minutes, not seconds. You can see all of this in my tracker already, by the way. Click on one of the ISL paths, and see all the satellites in it, and which ones (if any) have a gateway link. Today, the shell is still far from complete, so there will be gaps and times when a plane does not have a viable gateway:



Zooming in, this particular plane’s ISL chain is served by the Ibi, Spain gateway:


> Turning this into a global network in the shell: Even harder.

Agreed! If you equate this to an OSPF network with 4400 nodes, which are reconfiguring themselves every few minutes, the task is not trivial.
> Let's assume we have one or more gimbals that allow us to point our
> space laser(s) at other satellites in range. Or a mirror arrangement -
> doesn't matter.
>
> One unknown that we have is what the receiver side of these links will
> look like. As we'll see in a moment, this is actually quite important.
>
> There are in principle two options for the receiver:
>
> 1) A receiver with a wide angle lens that can receive laser signals from
> multiple other satellites at once. This is a pretty simple arrangement
> and may not even need moving parts.
>
> 2) A receiver that gets pointed back at the transmitting satellite,
> perhaps with a telescopic zoom lens. This adds a little weight and could
> be on the same gimbal as a laser, so we could communicate both ways
> between the satellites. Moreover, the zoom lens would be like antenna
> gain in a link budget, so would allow a higher data rate between the
> satellites and / or less power.
>
> Now 2) seem clearly superior, right, if we can handle a few extra grams?
> Then we could give each satellite n TX/RX gimbals and could, say, get
> each of our satellites to connect to its n nearest neighbours. And
> bingo, we'd have a network that spans the globe, right?
This is not how FSOC works at all. Both sides have an identical optical train (telescope, mirrors, gimbals, rotating heads, etc.), and a diffraction mirror that allows combination of transmit and receive beams, at shifted frequencies. One side shifts towards the red side of the spectrum, the other towards the blue, thus, we have a full duplex link with simmetrical capacity. What you cannot have is two “red” terminals talking to each other.

What is not (yet IMHO) practical is a wide-angle lens that receives several beams from different directions, primarily, because you would need the corresponding beam going back to be precisely oriented - if you “blast” photons by diffraction, optical power drops dramatically with distance, and destructive interference and other effects start to take place.

We know exactly what the receiver side looks like - as it is also the transmit side, one single optical head is full duplex, and there are three per satellite.
> A) What happens if one of our n nearest neighbours doesn't have us among
> its n nearest neighbours? Then they won't point their gimbal back at us.
> How do we resolve this?
> B) If n=3 and I have Dave, Mike, and Brandon as my nearest neigbours,
> Dave's 3 nearest neighbours are Mike, Brandon and me, Mike's nearest
> neighbours are Dave, Brandon and me, and Brandon has Dave, Mike and me
> as his nearest neighbours, then David, Dick and Sebastian who may be
> orbiting a bit further away from us don't get to link to our elitist
> cluster and our dream of a global network turns to dust.
>
> Now, Problem B (which also occurs for outward links from clusters with
> receiver type 1) can be mitigated by requiring a minimum distance to a
> neighbour, but in combination with a), we seem to have a nasty little
> overlay graph problem to solve. Oh, and we'd want to do that in a
> distributed fashion if possible, and every few seconds from scratch, please.

I believe these become moot once we remove the previous issues you pointed out. We will always have a neighbor we can see that can point their optical head back at us, in-plane and cross-plane. The “mesh” is static, only needs adjustments when satellites perform collision avoidance maneuvres, and those are known, so the links can automatically adjust. Any calculation as to what links are established, are active, etc. can be done on the ground and sent to the satellites for execution, much in the same way that RF resource scheduling is done centrally in 15 second blocks.

Best,

Mike
On Sep 1, 2022, 14:19 +0200, Ulrich Speidel via Starlink <starlink at lists.bufferbloat.net>, wrote:
> As this seems to have branched out... There are a whole bag of issues
> with ISL's and routing, really, and again we know diddly squat about
> what Starlink actually intend to do.
>
> My 5 cents worth:
>
> - Linking two satellites that follow each other on the same orbit is the
> easiest exercise. I gather that Starlink have ticked that one off. It's
> probably not too useful on its own for most real scenarios though:
> ground stations move through orbital planes. Also, two arbitrary ground
> stations between one would want to forward will probably not be
> connectable by a chain of satellites all in the same orbital plane.
> - Linking two satellites that are in different but adjacent orbital
> planes is one notch up but probably not a lot harder if you master
> gimbal / mirror control. You have some relative movement, but most of
> the time it's slow. Low hanging fruit if it's not already been picked.
> - Linking two satellites in range of each other that satisfy some
> arbitrary criterion (minimum distance, desired direction): A bit harder.
> - Turning this into a global network in the shell: Even harder.
>
> Let me elaborate a bit on this.
>
> Let's assume we have one or more gimbals that allow us to point our
> space laser(s) at other satellites in range. Or a mirror arrangement -
> doesn't matter.
>
> One unknown that we have is what the receiver side of these links will
> look like. As we'll see in a moment, this is actually quite important.
>
> There are in principle two options for the receiver:
>
> 1) A receiver with a wide angle lens that can receive laser signals from
> multiple other satellites at once. This is a pretty simple arrangement
> and may not even need moving parts.
>
> 2) A receiver that gets pointed back at the transmitting satellite,
> perhaps with a telescopic zoom lens. This adds a little weight and could
> be on the same gimbal as a laser, so we could communicate both ways
> between the satellites. Moreover, the zoom lens would be like antenna
> gain in a link budget, so would allow a higher data rate between the
> satellites and / or less power.
>
> Now 2) seem clearly superior, right, if we can handle a few extra grams?
> Then we could give each satellite n TX/RX gimbals and could, say, get
> each of our satellites to connect to its n nearest neighbours. And
> bingo, we'd have a network that spans the globe, right?
>
> Not so simple. Two problems, and they're serious ones as it turns out:
>
> A) What happens if one of our n nearest neighbours doesn't have us among
> its n nearest neighbours? Then they won't point their gimbal back at us.
> How do we resolve this?
> B) If n=3 and I have Dave, Mike, and Brandon as my nearest neigbours,
> Dave's 3 nearest neighbours are Mike, Brandon and me, Mike's nearest
> neighbours are Dave, Brandon and me, and Brandon has Dave, Mike and me
> as his nearest neighbours, then David, Dick and Sebastian who may be
> orbiting a bit further away from us don't get to link to our elitist
> cluster and our dream of a global network turns to dust.
>
> Now, Problem B (which also occurs for outward links from clusters with
> receiver type 1) can be mitigated by requiring a minimum distance to a
> neighbour, but in combination with a), we seem to have a nasty little
> overlay graph problem to solve. Oh, and we'd want to do that in a
> distributed fashion if possible, and every few seconds from scratch, please.
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel at auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220901/113b9d3b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orbital_status.png
Type: image/png
Size: 140049 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220901/113b9d3b/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attachment.png
Type: image/png
Size: 501412 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220901/113b9d3b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attachment-1.png
Type: image/png
Size: 65890 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220901/113b9d3b/attachment-0005.png>