Re: [Starlink] Starlink Roaming

[Mike Puchol <mike@starlink.sx>]

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

I did over-simplify so the point was better understood. On the optical gateways, these exist already: https://mynaric.com/products/ground-capabilities/

Once you have an optical mesh in orbit, the only practical way to provide it with massive capacity is optical links - there isn’t enough radio spectrum that would do it (without a massive ground gateway network with enough physical separation). You can create a network of optical gateways that guarantees a number of them will not be impared by cloud cover at any given time. Optical has the advantage of being license-free, too.

Best,

Mike
On Feb 22, 2022, 10:20 +0300, Dick Roy <dickroy@alum.mit.edu>, wrote:
>
>
> From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of Mike Puchol
> Sent: Monday, February 21, 2022 9:35 PM
> To: Daniel AJ Sokolov; David Lang
> Cc: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink Roaming
>
> Actually, laser links would make gateway connectivity *worse*. If we take the scenario attached, one gateway is suddenly having to serve traffic from all UTs that were not previously under coverage.
>
> A satellite under full load can saturate two gateway links by itself. If you load, say, 20 satellites in an orbital plane, onto a single gateway, over ISL, you effectively have 5% of each satellite’s capacity available (given an equal distribution of demand, of course there will be satellites with no UTs to cover etc.).
> [RR] I think to do this analysis correctly; one needs to consider the larger system and the time-varying loads on the components thereof. What you say is true; just a bit over-simplified to be maximally useful. Routing through complex congested networks is well-studied problem and hnts at possible solutions can probably be found thereJ)
>
>
> Eventually they will go for optical gateways, it’s the only way to get enough capacity to the constellation, specially the 30k satellite version.
> [RR] What do you mean by “”optical gateway”? An optical link from the satellite to the ground station? That would be real expensive at least power-wise and unreliable.
>
> Best,
>
> Mike
> On Feb 22, 2022, 05:17 +0300, David Lang <david@lang.hm>, wrote:
>
> On Mon, 21 Feb 2022, Daniel AJ Sokolov wrote:
>
> On 2022-02-21 at 13:52, David Lang wrote:
>
>
> They told me that I could try it, and it may work, may be degraded a
> bit, or may not work at all. They do plan to add roaming capabilities in
> the future (my guess is that the laser satellites will enable a lot more
> flexibility)
>
> Isn't that a very optimistic assessment? :-)
>
> Laser links are great for remote locations with very few users, but how
> could they relieve overbooking of Starlink in areas with too many users?
>
> The laser links can reduce the required density of ground stations, but
> they don't add capacity to the network. Any ground station not built
> thanks to laser links adds load to other ground stations - and, maybe
> more importantly, adds load to the satellite that does eventually
> connect to a ground station.
>
> Can laser links really help on a large scale, or are they just a small
> help here and there?
>
> My thinking is that the laser links will make it possible to route the traffic
> from wherever I am to the appropriate ground station that I'm registered with as
> opposed to the current bent-pipe approach where, if I move to far from my
> registered location, I need to talk to a different ground station.
>
> Currently there are two limits in any area for coverage:
>
> 1. satellite bandwidth
> 2. ground station bandwidth
>
> laser links will significantly reduce the effect of the second one.
>
> We know that they can do mobile dishes (they are testing it currently on Elon's
> gulfstream, FAR more mobile that I will ever be :-) )
>
> David Lang
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 8106 bytes --]