[Starlink] Starlink "beam spread"

Wed Aug 31 19:44:37 EDT 2022

Hi, Ulrich,

I agree with you even I don't know if StarLink satellite will process IP packet. IETF may work on this area soon. IP is the mandatory if some IP based features are moved to satellite, such as DNS, CDN, etc. Also, from 3GPP perspective, future LEO satellite network should be IP based. Then, the NTN integration with 5G and Internet can be done.
check out my slide: https://datatracker.ietf.org/doc/slides-114-hotrfc-sessa-the-leo-satellite-networking-lin-han/. We will have side meeting to discuss this in the next IETF 115 (London).

BRs.

Lin

From: Starlink <starlink-bounces at lists.bufferbloat.net> On Behalf Of Ulrich Speidel via Starlink
Sent: Wednesday, August 31, 2022 2:46 PM
To: starlink at lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"

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><mailto:u.speidel at auckland.ac.nz>
> To: David Lang <david at lang.hm><mailto:david at lang.hm>
> Cc: Sebastian Moeller <moeller0 at gmx.de><mailto:moeller0 at gmx.de>, Ulrich Speidel via Starlink
> <starlink at lists.bufferbloat.net><mailto:starlink at lists.bufferbloat.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404 at auckland.ac.nz><mailto: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fpulse%2Fquick-analysis-starlink-link-budget-potential-emf-david-witkowski&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2F%2BC4lM8fTdy9ZwX9%2FvGWPsoDKgDo3JWWxldoKyF%2FePw%3D&reserved=0>
>
> 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<mailto:u.speidel at auckland.ac.nz>
> http://www.cs.auckland.ac.nz/~ulrich/<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cs.auckland.ac.nz%2F~ulrich&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VmZuZendHQ4aco0nywbdmA%2FRg1j77iaO67KQstBQNks%3D&reserved=0>
> ****************************************************************
>
_______________________________________________
Starlink mailing list
Starlink at lists.bufferbloat.net<mailto:Starlink at lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.bufferbloat.net%2Flistinfo%2Fstarlink&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OI%2B4gUpL6bRmDK383Nf%2BCL%2FyOI6mZADjvWnDtcDfa5k%3D&reserved=0>

--

****************************************************************

Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland

u.speidel at auckland.ac.nz<mailto:u.speidel at auckland.ac.nz>

http://www.cs.auckland.ac.nz/~ulrich/<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cs.auckland.ac.nz%2F~ulrich%2F&data=05%7C01%7Clin.han%40futurewei.com%7Ca42f8a5df7de45f239e708da8b9a4324%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637975791971369095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A09JGBKfdxaK3IhoiegLHxlI1ph7TfKa1X%2FxsuVeboM%3D&reserved=0>

****************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220831/507402d2/attachment-0001.html>