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 --]
next prev parent 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