[Starlink] Starlink "beam spread"

Thu Sep 1 11:19:22 EDT 2022

If Starlink satellites are processing IP packets, shouldn't them be
shown in traceroutes? They are not shown now, AFAIK.

A transparent geographical based routing could be possible, with
signal-pass-through approach to the next satellite on a path
connecting to a GW, via ISL, if the satellite receiving traffic from a
dishy does not have any GW at direct sight.

> Date: Thu, 1 Sep 2022 09:46:20 +1200
> From: Ulrich Speidel <u.speidel at auckland.ac.nz>
> To: starlink at lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c at auckland.ac.nz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> I work on the assumption that Starlink satellites are, or at least will
> eventually be, processing IP packets. For inter-satellite routing it's
> more or less a must-have unless you have some other packet switching
> protocol layered in between.
>
> On 1/09/2022 2:51 am, David Fernández via Starlink wrote:
>> "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>> maybe already in operation?"
>>
>> Are the satellites processing IP packets? Are the ISLs even in
>> operation? I have been told Starlink satellites are transparent.
>>
>>
>> > Date: Thu, 1 Sep 2022 01:41:07 +1200
>> > From: Ulrich Speidel <u.speidel at auckland.ac.nz>
>> > To: David Lang <david at lang.hm>
>> > Cc: Sebastian Moeller <moeller0 at gmx.de>, Ulrich Speidel via Starlink
>> > <starlink at lists.bufferbloat.net>
>> > Subject: Re: [Starlink] Starlink "beam spread"
>> > Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404 at auckland.ac.nz>
>> > Content-Type: text/plain; charset=UTF-8; format=flowed
>> >
>> > Um, yes, but I think we're mixing a few things up here (trying to bundle
>> > responses here, so that's not just to you, David).
>> >
>> > In lieu of a reliable Starlink link budget, I'm going by this one:
>> >
>> >
>> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski/
>>
>> <https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potential-emf-david-witkowski>
>> >
>> > Parameters here are a little outdated but the critical one is the EIRP
>> > at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka
>> > band signal over a 600 km path, which is more reflective of the current
>> > constellation. Then Friis propagation gives us a path loss of about 178
>> > dB, and if we pretend for a moment that Dishy is actually a 60 cm
>> > diameter parabolic dish, we're looking at around 45 dBi receive antenna
>> > gain. Probably a little less as Dishy isn't actually a dish.
>> >
>> > Then that gives us 97 dBm - 178 dB + 45 dB = -36 dBm at the ground
>> > receiver. Now I'm assuming here that this is for ALL user downlink beams
>> > from the satellite combined. What we don't really know is how many
>> > parallel signals a satellite multiplexes into these, but assuming at the
>> > moment a receive frontend bandwidth of about 100 MHz, noise power at the
>> > receiver should be around 38 pW or -74 dBm. That leaves Starlink around
>> > 38 dB of SNR to play with. Shannon lets us send up to just over 1.25
>> > Gb/s in that kind of channel, but then again that's just the Shannon
>> > limit, and in practice, we'll be looking a a wee bit less.
>> >
>> > That SNR also gives us an indication as to the signal separation Dishy
>> > needs to achieve from the beams from another satellite in order for that
>> > other satellite to re-use the same frequency. Note that this is
>> > significantly more than just the 3 dB that the 3 dB width of a beam
>> > gives us. The 3 dB width is what is commonly quoted as "beam width", and
>> > that's where you get those nice narrow angles. But that's just the width
>> > at which the beam drops to half its EIRP, not the width at which it can
>> > no longer interfere. For that, you need the 38 dB width - or thereabouts
>> > - if you can get it, and this will be significantly more than the 1.2
>> > degrees or so of 3dB beam width.
>> >
>> > But even if you worked with 1.2 degrees at a distance of 600 km and you
>> > assumed that sort of beam width at the satellite, it still gives you an
>> > >12 km radius on the ground within which you cannot reuse the downlink
>> > frequency from the same satellite. That's orders of magnitude more than
>> > the re-use spatial separation you can achieve in ground-based cellular
>> > networks. Note that the 0.1 deg beam "precision" is irrelevant here -
>> > that just tells me the increments in which they can point the beam, but
>> > not how wide it is and how intensity falls off with angle, or how bad
>> > the side lobes are.
>> >
>> > Whether you can re-use the same frequency from another satellite to the
>> > same ground area is a good question. We really don't know the beam
>> > patterns that we get from the birds and from the Dishys, and without
>> > these it's difficult to say how much angular separation a ground station
>> > needs between two satellites using the same frequency in order to
>> > receive one but not be interfered with by the other. Basically, there
>> > are just too many variables in this for me to be overly optimistic that
>> > re-use by two different sources within a Starlink cell is possible. And
>> > I haven't even looked at the numbers for Ku band here.
>> >
>> > CDNs & Co - are NOT just dumb economic optimisations to lower bit miles.
>> > They actually improve performance, and significantly so. A lower RTT
>> > between you and a server that you grab data from via TCP allows a much
>> > faster opening of the congestion window. With initial TCP cwnd's being
>> > typically 10 packets or around 15 kB of data, having a server within 10
>> > ms of your client means that you've transferred 15 kB after 5 ms, 45 kB
>> > after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25
>> > ms. Make your RTT 100 ms, and it takes half a second to get to your 465
>> > kB. Having a CDN server in close topological proximity also generally
>> > reduces the number of queues between you and the server at which packets
>> > can die an untimely early death, and generally, by taking load off such
>> > links, reduces the probability of this happening at a lot of queues.
>> > Bottom line: Having a CDN keeps your users happier. Also, live streaming
>> > and video conferencing aside, most video is not multicast or broadcast,
>> > but unicast.
>> >
>> > DNS on Starlink satellites: Good idea, lightweight, and I'd suspect
>> > maybe already in operation? It's low hanging fruit. CDNs on satellites:
>> > In the day and age of SSDs, having capacity on the satellite shouldn't
>> > really be an issue, although robustness may be. But heat in this sort of
>> > storage gets generated mostly when data is written, so it's a function
>> > of what percentage of your data that reaches the bird is going to end up
>> > in cache. Generally, on a LEO satellite that'll have to cache baseball
>> > videos while over the US, videos in a dozen different languages while
>> > over Europe, Bollywood clips while over India, cooking shows while over
>> > Australia and always the same old ads while over New Zealand, all the
>> > while not getting a lot of cache hits for stuff it put into cache 15
>> > minutes ago, would probably have to write a lot. Moreover, as you'd be
>> > reliant on the content you want being on the satellite that you are
>> > currently talking to, pretty much all satellites in the constellation
>> > would need to cache all content. In other words: If I watch a cat video
>> > now and thereby put it into the cache of the bird overhead, and then
>> > send you an e-mail and you're in my neighbourhood and you watch it half
>> > an hour later, my satellite would be on the other side of the world, and
>> > you'd have to have it re-uploaded to the CDN on the bird that's flying
>> > overhead our neighbourhood then. Not as efficient as a ground-based CDN
>> > on our ground-based network that's fed via a satellite link.
>> >
>> > As long as Starlink is going to have in the order of hundreds of
>> > thousands of direct users, that problem won't go away.
>> >
>> > On 31/08/2022 7:33 pm, David Lang wrote:
>> >
>> >> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>> >>
>> >>> This combines with the uncomfortable truth that an RF "beam" from a
>> >>> satellite isn't as selective as a laser beam, so the options for
>> >>> frequency re-use from orbit aren't anywhere near as good as from a
>> >>> mobile base station across the road: Any beam pointed at you can be
>> >>> heard for many miles around and therefore no other user can re-use
>> >>> that frequency (with the same burst slot etc.).
>> >>
>> >> not quite, you are forgetting that the antennas on the ground are also
>> >> steerable arrays and so they can focus their 'receiving beam' at
>> >> different satellites. This is less efficient than a transmitting beam
>> >> as the satellites you aren't 'pointed' at will increase your noise
>> >> floor, but it does allow the same frequency to be used for multiple
>> >> satellites into the same area at the same time.
>> >>
>> >> David Lang
>> >>
>> > --
>> > ****************************************************************
>> > Dr. Ulrich Speidel
>> >
>> > School of Computer Science
>> >
>> > Room 303S.594 (City Campus)
>> >
>> > The University of Auckland
>> > u.speidel at auckland.ac.nz
>> > http://www.cs.auckland.ac.nz/~ulrich/
>> <http://www.cs.auckland.ac.nz/~ulrich>
>> > ****************************************************************
>> >
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>