Re: [Starlink] thinking about the laser links again

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]


Ulrich Speidel <ulrich@cs.auckland.ac.nz> wrote:
    > Lasers vs. RF (microwave): The problem with RF is that it's comparatively
    > difficult to produce a sharp beam as you can do with lasers - mostly due to
    > the fact that the wavelength involved is so much larger (centimeter
    > scale vs

Yeah, I knew that, but I was thinking that the shaper beam is a negative due
to effort pointing it so precisely.  Maybe some layer/RF hybrid.

    > Both lasers and RF suffer from one common problem, though: If the transmitter
    > is in front of the sun from the receiver's perspective, then sun's wideband
    > signal is all the receiver will see.

I guess the real question is: have you written the Hollywood Security Theatre
script based upon this issues, and can I play the geek that explains this? :-)

    > - Tell satellites where to send packets (in something along the lines of a
    > long header, as in AX.25 for example). Then a sending ground station would
    > need a complete almanach of the constellation and an idea as to where the
    > receiving ground station is, and which satellite it would use for the
    > downlink. Pros: The sending ground station can do all the number crunching on
    > ground rather than space power. Cons:  Header size costs bandwidth.

From what I understood, Starlink shipped some kind of comodity SDN capable
chip.  So  MPLS, or SRv6 ought to be easy, costing only a few bytes
interpreted in hardware, and a path computation element on the ground should
be able to deal with the calculation.

It's a challenging situation perhaps because the network effectively gets
rewired every few minutes, but ground based computation should be able to
deal with the problem.

    > - Get the satellites to work out where stuff needs to be sent. If they were
    > to use something like Bellman-Ford here, that would require an enormous
    > amount of update traffic. Dijkstra would require complete topology
    > information, which should in principle be computable from an almanach on the
    > satellites.

I think, but I might be wrong, that there is a pattern which repeats over and
over again.  Just need to update the mapping of which satellite is in which
position in the precomputed mesh.  No need to send the entire mesh.

One might be able to use RPL(RFC6550) for this, which avoids sending update traffic
if there is no real traffic.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]