<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 2/09/2022 5:24 am, Mike Puchol via
Starlink wrote:<br>
</div>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<title></title>
<div name="messageBodySection">
<div dir="auto">I can talk with a tiny bit of knowledge, having
worked with FSOC technology for ~3 years now (and being a
curious nerd!).<br>
</div>
<blockquote style="border-left-color: rgb(26, 188, 156); margin:
5px; padding-left: 10px; border-left-width: thin;
border-left-style: solid;">- Linking two satellites that
follow each other on the same orbit is the<br>
easiest exercise. I gather that Starlink have ticked that one
off. It's<br>
probably not too useful on its own for most real scenarios
though:<br>
ground stations move through orbital planes. Also, two
arbitrary ground<br>
stations between one would want to forward will probably not
be<br>
connectable by a chain of satellites all in the same orbital
plane.<br>
- Linking two satellites that are in different but adjacent
orbital<br>
planes is one notch up but probably not a lot harder if you
master<br>
gimbal / mirror control. You have some relative movement, but
most of<br>
the time it's slow. Low hanging fruit if it's not already been
picked.<br>
- Linking two satellites in range of each other that satisfy
some<br>
arbitrary criterion (minimum distance, desired direction): A
bit harder.</blockquote>
<div dir="auto">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 <a href="https://www.starlink.com/assets/images/prd-default/satellites/Module_1_Carousel/4_SpaceLaser.jpg" target="_blank" moz-do-not-send="true">https://www.starlink.com/assets/images/prd-default/satellites/Module_1_Carousel/4_SpaceLaser.jpg</a><br>
<br>
</div>
</div>
</blockquote>
That's what I'd call gimbals, but I'm happy to adapt to whatever
terminology you choose ;-)<br>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<div name="messageBodySection">
<div dir="auto">
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):<br>
<br>
<img style="max-width:100%;height:auto" src="cid:part1.X5GyMXm3.kzX9q4Jb@auckland.ac.nz" class=""><br>
<br>
</div>
</div>
</blockquote>
<p>All understood - and a somewhat obvious way of doing things.
Now... not so obvious, actually. <br>
</p>
<p>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.</p>
<p>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. <br>
</p>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<div name="messageBodySection">
<div dir="auto">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. <br>
<br>
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:<br>
<br>
<img style="max-width:100%;height:auto" src="cid:part2.uhpDqycZ.7mMDJr1c@auckland.ac.nz" class=""><br>
<br>
Zooming in, this particular plane’s ISL chain is served by the
Ibi, Spain gateway:<br>
<br>
<img style="max-width:100%;height:auto" src="cid:part3.LBgxqa0D.FyL0pb05@auckland.ac.nz" class=""><br>
</div>
<blockquote style="border-left-color: rgb(26, 188, 156); margin:
5px; padding-left: 10px; border-left-width: thin;
border-left-style: solid;">Turning this into a global network
in the shell: Even harder.</blockquote>
<div dir="auto"><br>
Agreed! If you equate this to an OSPF network with 4400 nodes,
which are reconfiguring themselves every few minutes, the task
is not trivial.<br>
</div>
</div>
</blockquote>
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. <br>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<div name="messageBodySection">
<blockquote style="border-left-color: rgb(26, 188, 156); margin:
5px; padding-left: 10px; border-left-width: thin;
border-left-style: solid;">Let's assume we have one or more
gimbals that allow us to point our<br>
space laser(s) at other satellites in range. Or a mirror
arrangement -<br>
doesn't matter.<br>
<br>
One unknown that we have is what the receiver side of these
links will<br>
look like. As we'll see in a moment, this is actually quite
important.<br>
<br>
There are in principle two options for the receiver:<br>
<br>
1) A receiver with a wide angle lens that can receive laser
signals from<br>
multiple other satellites at once. This is a pretty simple
arrangement<br>
and may not even need moving parts.<br>
<br>
2) A receiver that gets pointed back at the transmitting
satellite,<br>
perhaps with a telescopic zoom lens. This adds a little weight
and could<br>
be on the same gimbal as a laser, so we could communicate both
ways<br>
between the satellites. Moreover, the zoom lens would be like
antenna<br>
gain in a link budget, so would allow a higher data rate
between the<br>
satellites and / or less power.<br>
<br>
Now 2) seem clearly superior, right, if we can handle a few
extra grams?<br>
Then we could give each satellite n TX/RX gimbals and could,
say, get<br>
each of our satellites to connect to its n nearest neighbours.
And<br>
bingo, we'd have a network that spans the globe, right?</blockquote>
<div dir="auto">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.<br>
</div>
</div>
</blockquote>
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? <br>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<div name="messageBodySection">
<div dir="auto">
<br>
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.<br>
</div>
</div>
</blockquote>
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. <br>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<div name="messageBodySection">
<div dir="auto">
<br>
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.<br>
</div>
</div>
</blockquote>
Well do we? And if we do, is this the way it should be?<br>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<div name="messageBodySection">
<blockquote style="border-left-color: rgb(26, 188, 156); margin:
5px; padding-left: 10px; border-left-width: thin;
border-left-style: solid;">A) What happens if one of our n
nearest neighbours doesn't have us among<br>
its n nearest neighbours? Then they won't point their gimbal
back at us.<br>
How do we resolve this?<br>
B) If n=3 and I have Dave, Mike, and Brandon as my nearest
neigbours,<br>
Dave's 3 nearest neighbours are Mike, Brandon and me, Mike's
nearest<br>
neighbours are Dave, Brandon and me, and Brandon has Dave,
Mike and me<br>
as his nearest neighbours, then David, Dick and Sebastian who
may be<br>
orbiting a bit further away from us don't get to link to our
elitist<br>
cluster and our dream of a global network turns to dust.<br>
<br>
Now, Problem B (which also occurs for outward links from
clusters with<br>
receiver type 1) can be mitigated by requiring a minimum
distance to a<br>
neighbour, but in combination with a), we seem to have a nasty
little<br>
overlay graph problem to solve. Oh, and we'd want to do that
in a<br>
distributed fashion if possible, and every few seconds from
scratch, please.</blockquote>
<div dir="auto"><br>
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. <br>
</div>
</div>
</blockquote>
But is that truly the best way of going about?<br>
<blockquote type="cite" cite="mid:8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark">
<div name="messageBodySection">
</div>
<div name="messageSignatureSection"><br>
<div class="matchFont">Best,<br>
<br>
Mike</div>
</div>
<div name="messageReplySection">On Sep 1, 2022, 14:19 +0200,
Ulrich Speidel via Starlink
<a class="moz-txt-link-rfc2396E" href="mailto:starlink@lists.bufferbloat.net"><starlink@lists.bufferbloat.net></a>, wrote:<br>
<blockquote type="cite" style="border-left-color: grey;
border-left-width: thin; border-left-style: solid; margin: 5px
5px;padding-left: 10px;">As this seems to have branched out...
There are a whole bag of issues<br>
with ISL's and routing, really, and again we know diddly squat
about<br>
what Starlink actually intend to do.<br>
<br>
My 5 cents worth:<br>
<br>
- Linking two satellites that follow each other on the same
orbit is the<br>
easiest exercise. I gather that Starlink have ticked that one
off. It's<br>
probably not too useful on its own for most real scenarios
though:<br>
ground stations move through orbital planes. Also, two
arbitrary ground<br>
stations between one would want to forward will probably not
be<br>
connectable by a chain of satellites all in the same orbital
plane.<br>
- Linking two satellites that are in different but adjacent
orbital<br>
planes is one notch up but probably not a lot harder if you
master<br>
gimbal / mirror control. You have some relative movement, but
most of<br>
the time it's slow. Low hanging fruit if it's not already been
picked.<br>
- Linking two satellites in range of each other that satisfy
some<br>
arbitrary criterion (minimum distance, desired direction): A
bit harder.<br>
- Turning this into a global network in the shell: Even
harder.<br>
<br>
Let me elaborate a bit on this.<br>
<br>
Let's assume we have one or more gimbals that allow us to
point our<br>
space laser(s) at other satellites in range. Or a mirror
arrangement -<br>
doesn't matter.<br>
<br>
One unknown that we have is what the receiver side of these
links will<br>
look like. As we'll see in a moment, this is actually quite
important.<br>
<br>
There are in principle two options for the receiver:<br>
<br>
1) A receiver with a wide angle lens that can receive laser
signals from<br>
multiple other satellites at once. This is a pretty simple
arrangement<br>
and may not even need moving parts.<br>
<br>
2) A receiver that gets pointed back at the transmitting
satellite,<br>
perhaps with a telescopic zoom lens. This adds a little weight
and could<br>
be on the same gimbal as a laser, so we could communicate both
ways<br>
between the satellites. Moreover, the zoom lens would be like
antenna<br>
gain in a link budget, so would allow a higher data rate
between the<br>
satellites and / or less power.<br>
<br>
Now 2) seem clearly superior, right, if we can handle a few
extra grams?<br>
Then we could give each satellite n TX/RX gimbals and could,
say, get<br>
each of our satellites to connect to its n nearest neighbours.
And<br>
bingo, we'd have a network that spans the globe, right?<br>
<br>
Not so simple. Two problems, and they're serious ones as it
turns out:<br>
<br>
A) What happens if one of our n nearest neighbours doesn't
have us among<br>
its n nearest neighbours? Then they won't point their gimbal
back at us.<br>
How do we resolve this?<br>
B) If n=3 and I have Dave, Mike, and Brandon as my nearest
neigbours,<br>
Dave's 3 nearest neighbours are Mike, Brandon and me, Mike's
nearest<br>
neighbours are Dave, Brandon and me, and Brandon has Dave,
Mike and me<br>
as his nearest neighbours, then David, Dick and Sebastian who
may be<br>
orbiting a bit further away from us don't get to link to our
elitist<br>
cluster and our dream of a global network turns to dust.<br>
<br>
Now, Problem B (which also occurs for outward links from
clusters with<br>
receiver type 1) can be mitigated by requiring a minimum
distance to a<br>
neighbour, but in combination with a), we seem to have a nasty
little<br>
overlay graph problem to solve. Oh, and we'd want to do that
in a<br>
distributed fashion if possible, and every few seconds from
scratch, please.<br>
<br>
--<br>
****************************************************************<br>
Dr. Ulrich Speidel<br>
<br>
School of Computer Science<br>
<br>
Room 303S.594 (City Campus)<br>
<br>
The University of Auckland<br>
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a><br>
<a href="http://www.cs.auckland.ac.nz/~ulrich/" moz-do-not-send="true">http://www.cs.auckland.ac.nz/~ulrich/</a><br>
****************************************************************<br>
<br>
<br>
<br>
_______________________________________________<br>
Starlink mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/starlink" moz-do-not-send="true">https://lists.bufferbloat.net/listinfo/starlink</a><br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Starlink mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/starlink">https://lists.bufferbloat.net/listinfo/starlink</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</body>
</html>