Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] [LibreQoS] Starlink cell capacity (was; tarana strikes back)
Date: Wed, 27 Sep 2023 11:01:50 +0200	[thread overview]
Message-ID: <d72ed214-e854-48cb-9ae0-d36cca959a91@gmail.com> (raw)
In-Reply-To: <e2606e85-9832-4754-93ec-7e976f224ced@auckland.ac.nz>


Le 26/09/2023 à 23:16, Ulrich Speidel via Starlink a écrit :
>
>
> 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.
>
I agree, spectrum management is an important aspect in wireless 
deployments.  But both on sat and ground wireless.

Ground wireless deployments like cellular have the potential of finer 
coverage management - it's not simply heaxagonal cells, but more 
arbitrary shapes, planned according to visibility and 3D models.  (when 
done right, because there are also numerous ground cellular deployments, 
including new ones, done very wrong with respect to coverage).

The ground wireless and wired deployments have other drawbacks such as 
simply too many cables managed by too many people, who simply lost track 
of what is where.  That situation is only growing alarmly.  It leads to 
service interruption and bad quality of Internet to subscribers.   With 
sat LEO Internet such situation (not known cables) does not really 
happen - the sat trajectories and orbits are much more planned.

What happens badly with LEO Internet deployments is the new debris added 
to the existing large debris.  The debris situation is so bad that the 
risks of fall out of the sky and injure people or damage property is 
considered seriously.  There are sites continuously watching and 
forecasting the next debris fall.  If this situation amplifies, it might 
become a factor of societal acceptance.

Alex


> 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
> -- 
> ****************************************************************
> 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/
> ****************************************************************
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

  parent reply	other threads:[~2023-09-27  9:01 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
2023-09-26 21:32             ` David Lang
2023-09-27  9:01             ` Alexandre Petrescu [this message]
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=d72ed214-e854-48cb-9ae0-d36cca959a91@gmail.com \
    --to=alexandre.petrescu@gmail.com \
    --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