[Starlink] thinking about the laser links again
Ulrich Speidel
ulrich at cs.auckland.ac.nz
Wed Oct 27 02:20:20 EDT 2021
Interesting discussion and one I hoped would pop up! Here's my 5 cents
worth:
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 micro-/nanometer scale). On a spacecraft,
this is further compounded by not being able to fly with RF antenna
structures whose size is many orders of magnitude greater than the
wavelength involved. In RF terms, this means transmit power flux going
off into directions where the power isn't needed and in most cases also
not wanted. Not only is this a drain on your bird's power budget, but
also a recipe for interference elsewhere. Plus you have the issue of RF
spectrum being a vastly more constrained resource.
In terms of laser ISLs, space is a pretty benign environment: If you're
linking to another sat at the same orbital altitude or higher, any light
that doesn't hit the satellite goes to places where it's not going to
interfere with anyone else. There's no attenuation or dispersion due to
atmospheric effects, either, and while both vehicles move, the only
significant "noise" that the movement injects would probably come from
the gimbal mechanics I'd guess.
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. This is an issue
even for GEO sats which face foreseeable "outages" twice a year as the
satellite comes to sit in front of the sun for a few minutes. LEOs also
suffer from this problem, e.g., intra-plane links are affected when the
twilight zone is perpendicular to the orbital plane: Any bird flying
into the sunrise will lose signal from the bird in front, and any bird
flying away from sunset will lose signal from the bird behind. Note that
in the high inclination orbits that Starlink currently uses, this is
only an issue for birds near the northern and southern turning points of
the orbit.
Beyond that, laser beams can be optically widened to make pointing
easier. At the end of the day it's a trade off between the amount of
laser power that arrives at the receiver, which determines the feasible
modulation schemes and hence the link's achievable bit rate, and the
ease and robustness of pointing.
Given that satellites are on limited power budgets, any satellite that
needs to carry transit traffic that could be carried on a ground segment
provides premium service. It constrains the satellite's available
bandwidth for traffic that does not have a terrestrial path option, as
well as its capacity for communication with ground stations (in
principle, since it could dedicate the power used to convey the transit
traffic towards a stronger signal in ground direction). This makes
in-plane forwarding a bit of a strange game: the first satellite from
uplink carries all traffic, the second all traffic minus whatever the
first satellite was able to downlink, and so on. Obviously, the
definition of "first satellite" changes over time as the satellite
proceeds in its orbit and as the uplinking ground station on Earth
rotates away from the orbital plane. So you'd have to hand over orbital
planes between different ground stations.
Presuming next-gen Starlink can communicate cross-plane in the same
shell, what are the options? Starlink currently uses cells, which I read
as: "A cell is a geographical area. A satellite assigned to a cell at a
given time can downlink to any Dishy in the cell." So it's probably
reasonable to assume that they'll try to route between cells first and
foremost. So they could:
- 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. How do we ensure the almanach is always complete and correct?
How do we know what the receiver's view of the sky is? One sub-option
here is to treat the space segment merely as an access network. For each
cell, work out a ground station that will always service that cell and,
for any given point in time a combination of satellites needed to
service that route. Have the ground station set up a VC to the satellite
serving the cell. For most areas of the planet, that wouldn't require
more than a couple of satellites to be involved (if Starlink had ground
stations around the globe where there is fibre).
- 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. But it's still a lot of number crunching on
a bird. Another option would be for each satellite to compute a great
circle direction to the target cell and then forward to whichever
neighbour satellite comes closest to being along that route.
So yeah, will be interesting to see what they'll actually do, whether
that'll change over time, and whether they'll ever tell anyone.
On 27/10/2021 6:51 am, Michael Richardson wrote:
> Mike Puchol<mike at starlink.sx> wrote:
> > I could bore you to death but here’s a quick test you can do: grab a
> > laser pointer and try to keep it on a target the size of the laser dot
> > on a wall 10-15 meters away. You’ll quickly see why doing that at
>
> I fail, because the cat attacks me :-)
> (our cats somehow know when we get the laser pointers out, even if the
> batteries are dead...)
>
> > The logical thing to start with would be to keep every shell
> > interconnected, but not to try to cross-link shells. For this,
> > ground-to-satellite links come into play.
>
> Or they could interconnect using microwaves, couldn't they?
> It's all just different parts of the EM spectrum after all :-)
>
> > How do you make capacities in the petabits per second around your space
> > segment useful? You need to deliver to the ground eventually. IMHO the
> > only way this will hapen is ground-to-satellite links, with the ground
> > stations either in a few, as cloudless as possible locations, or many
> > stations in as geographically diverse configuration as possible, so
> > that at least some will not have cloud cover.
>
> > Once you have the ground links to each shell, they can be used to
> > offload to internet backbones, or you can relay data between shells,
> > without complicating your pointing & tracking on the satellites.
>
> What about going the other way? Interconnect via GEO?
> Or something resonant to the earth that is not quite so far?
>
> > Mark Handley makes a very good job at explaining in this video (and
> > others he has posted):https://www.youtube.com/watch?v=QEIUdMiColU
>
> Thnk you for the link.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ]mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
>
>
> _______________________________________________
> 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)
Ph: (+64-9)-373-7599 ext. 85282
The University of Auckland
ulrich at cs.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/20211027/f852f248/attachment.html>
More information about the Starlink
mailing list