Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] [LibreQoS] Starlink cell capacity (was; tarana strikes back)
Date: Wed, 27 Sep 2023 10:16:56 +1300	[thread overview]
Message-ID: <e2606e85-9832-4754-93ec-7e976f224ced@auckland.ac.nz> (raw)
In-Reply-To: <9q304pqs-778s-2s16-455s-604qnn43082q@ynat.uz>

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


On 27/09/2023 8:00 am, David Lang via Starlink wrote:
> On Tue, 26 Sep 2023, Jim Forster wrote:
>
> > This is all true (as much as I understand), Worth noting as well, is 
> that with
> > LEOs if one satellite is maxed out serving a cell, then getting a 
> second
> > satellite to help with that cell mean adding *lots* more satellites. If
> > adjacent cells had very different loads then I guess nearby unloaeded
> > satellites could help out their busy neighbors. But areas with busy 
> cells
> > close together would mean doubling the number of satellites and 
> therefore
> > platform Capex. Whereas terrestrial towers can be densified in busy 
> areas.
>
> In 2021 when SpaceX had launched 1800 satellites they said that once 
> all of them
> reached operational altitude they would be able to provide global 
> coverage.
>
> They now have >4k satellites in operation and (if fully approved) are 
> aiming at
> ~10x that number eventually. That leaves a lot of additional 
> satellites to
> provide additional coverage for busy cells or smaller cells.

There's a minor issue that I'm not convinced people take into account. 
Simply putting more satellites in orbit doesn't necessarily create more 
system capacity - it also takes spectrum to accommodate the up- and 
downlink capacity.

And therein lies a bit of a challenge. In terrestrial cellularised 
communication, one can leverage proximity between base station and UE to 
reduce power emission to a point where neither can be heard too far 
away. This allows re-use of the same part of the spectrum a bit further 
down the road. But that only works because we can build base stations 
within a few hundred metres of where the users are. The moment we need 
to project capacity from kilometres away, we're no longer economical 
with our spectrum resource. At that point, we're leveraging low user 
density.

When cellular networks start out, the base stations tend to be on top of 
high vantage points: towers, high buildings, hills. As a network gains 
customers, the base stations migrate down the slopes - the hills now 
serve as welcome obstacles to isolate the base stations in the valleys 
from each other spectrum-wise. Your cells shrink in size and your 
transmissions drop in power.

The problem with a LEO system such as Starlink is that migrating down 
from orbit is not an option. You have to project your capacity from many 
hundreds of km away. You can to an extent use beamforming etc. to direct 
your transmissions at targets on the ground, but the side lobes from 
your phased arrays pretty much render your transmit frequency unusable 
for any other satellite for hundreds of miles around.

Going to E band - fine, but even that is a limited resource, and it has 
its other issues, too.

>
> I agree terrestrial towers can be densified more easily in a specific 
> area.
>
> I'm saying that the crossover point where the density favors 
> terrestrial towers
> is significantly denser than the original author was stating. (and as 
> more sats
> are launched, will move further)
>
> There's also the fact that satellite densification covers all areas, 
> where
> terrestrial tower densification only covers that area. So around the 
> already
> dense areas, you will have tower densification happening, pushing out,
> leveraging the nearby wired infrastructure. But you may see a different
> situation in areas where small communities are growing and you have to 
> setup the
> tower and wired infrastructure from scratch.
>
> scenario:
>
> a village that is a 30 min drive from the next community and doesn't
> have much fiber run to it. As it grows, you can't just put in towers 
> without
> also running tens of miles of fiber to the area, so densification of 
> towers in
> the area is significantly harder than seeing the suburbs of a large 
> city grow
> where fiber is just a couple miles away.
>
> David Lang
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



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

  reply	other threads:[~2023-09-26 21:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-24  2:34 [Starlink] tarana strikes back Dave Taht
2023-09-24 20:19 ` Luis A. Cornejo
2023-09-24 20:37   ` Dave Taht
2023-09-25  8:11     ` David Lang
2023-09-26 18:37       ` [Starlink] [LibreQoS] Starlink cell capacity (was; tarana strikes back) Jim Forster
2023-09-26 19:00         ` David Lang
2023-09-26 21:16           ` Ulrich Speidel [this message]
2023-09-26 21:32             ` David Lang
2023-09-27  9:01             ` Alexandre Petrescu
2023-09-26 23:05           ` dan
2023-09-26 19:14 ` [Starlink] tarana strikes back Jeremy Austin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e2606e85-9832-4754-93ec-7e976f224ced@auckland.ac.nz \
    --to=u.speidel@auckland.ac.nz \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox