[Starlink] Starlink "beam spread"

Wed Aug 31 09:41:07 EDT 2022

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/

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/
****************************************************************