[Starlink] Why ISLs are difficult...
Ulrich Speidel
u.speidel at auckland.ac.nz
Mon Sep 5 06:54:54 EDT 2022
On 2/09/2022 5:24 am, Mike Puchol via Starlink wrote:
> 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
> <https://www.starlink.com/assets/images/prd-default/satellites/Module_1_Carousel/4_SpaceLaser.jpg>
>
That's what I'd call gimbals, but I'm happy to adapt to whatever
terminology you choose ;-)
> 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):
>
>
>
All understood - and a somewhat obvious way of doing things. Now... not
so obvious, actually.
The in-plane links are easy, as discussed. As far as the cross-plane
links go, it's a little harder as you say. One problem is best explained
if you just look at two adjacent planes. Consider two satellites flying
alongside each other in the 0-180 deg part of the orbit, such that say
bird A sees bird B on its starboard side, and packets from A to B travel
in a SW direction (depending on where you put 0 degrees - up north? -
and whether you assume clockwise motion). Then in the 180-360 part of
the arc, A will see B on its port side and packets will travel in a NW
direction. This requires a side change for the ISL as the orbits cross
over. So that needs to be managed, and probably - my guess - means
momentary loss of connectivity. Unfortunately, these crossovers mostly
happen in just the busiest parts of the network - around 53 deg of
latitude, except for the polar orbits, where they happen around 83 deg N
and S.
But there's another issue here. What you suggest involves forwarding to
what are in effect the nearest neighbours only. This maximises number of
hops for a given distance, and maximises load on the satellites. If the
gateway that happens to see your plane happens to be on the other side
of the world, you have half the orbital plane involved in handling your
packet. Not great for power budgets, or for latency. It's also prone to
breakage if you have satellites with mechanical problems on the optical
heads or dysfunctional optical heads. But I guess you could skip those.
> 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.
I think the only sensible way to do this is to let the satellites
themselves decide where to forward packets. You really don't want to
have ground stations have to worry about prescribing a path through a
constellation like this with something like IPv6 source routing and the
associated overhead, or about having to keep complete topology information.
>
> 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.
I can understand why you would do this for terrestrial links. But with
zero atmospheric backscatter in space, you could, presumably, have a
non-diffraction mirror and a laser / zoom lens pointing in parallel, on
the same wavelength, right?
>
> 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.
Put in other words: A wide angle lens is a low gain antenna, which
decreases your SNR at the receiver, and therefore your data rate. Indeed.
>
> 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.
Well do we? And if we do, is this the way it should be?
>
> 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.
But is that truly the best way of going about?
>
> 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/
>> <http://www.cs.auckland.ac.nz/~ulrich/>
>> ****************************************************************
>>
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
--
****************************************************************
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/
****************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220905/0e82408e/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/pipermail/starlink/attachments/20220905/0e82408e/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/pipermail/starlink/attachments/20220905/0e82408e/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/pipermail/starlink/attachments/20220905/0e82408e/attachment-0005.png>
More information about the Starlink
mailing list