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.
Mike Puchol <mike@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@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________ Starlink mailing list Starlink@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@cs.auckland.ac.nz http://www.cs.auckland.ac.nz/~ulrich/ ****************************************************************