From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Why ISLs are difficult...
Date: Fri, 2 Sep 2022 00:19:14 +1200 [thread overview]
Message-ID: <cf9ab778-d2a2-bb94-d87f-c49180643ff9@auckland.ac.nz> (raw)
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@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
next reply other threads:[~2022-09-01 12:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 12:19 Ulrich Speidel [this message]
2022-09-01 14:37 ` Dave Taht
2022-09-01 17:24 ` Mike Puchol
2022-09-01 22:00 ` Michael Richardson
2022-09-01 22:12 ` Dave Taht
2022-09-05 10:54 ` Ulrich Speidel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf9ab778-d2a2-bb94-d87f-c49180643ff9@auckland.ac.nz \
--to=u.speidel@auckland.ac.nz \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox