On Mon, Jan 20, 2025 at 11:36 PM Mike Puchol via Starlink
<starlink@lists.bufferbloat.net> wrote:

Thank you Dave!

It has been a while since I wrote that piece, and so much has changed. I have been really busy with work, and haven’t been able to implement a lot of these changes into the starlink.sx tracker - I’m trying to put aside some time to update it.

Perhaps someone here could help you out?

There are a number of issues that were not addressed in Mike's original paper:

• Beam shaping
• ITU EPFD limits. These cap what can go to all dishys in a cell to <=12 Gb/s combined if the cell is served exclusively from the Gen 1 generation and <=20 Gb/s if only Gen 2 is used, inclusive of any overhead (FEC, access/handover management). So the real cell capacity per dishy is usually somewhere between these numbers. That's provided SpaceX stick to what they applied for in terms of the licenses they were seeking. In that sense, it doesn't matter whether sats are brought down further. As long as these limits are in place (and removing them completely might just jeopardise people's satellite TV), about the only way to add capacity is to have more cells per surface area (=fewer users per cell), i.e., make the cells and beam footprints smaller, and that becomes increasingly non-trivial as cell size shrinks.
  
• v2 didn't apply for division of Ku band into sub-channels, so there's a bit of extra capacity there in terms of straddled guard bands - potentially.
  
• E and Ka aren't used for end user downlink (and wouldn't be suitable for such on a continuous basis due to fading in rain etc.)
• Ka-band community gateways

We're about to submit a couple of papers to address some of this. Quite which cell gets how much of the cake based on local quirks - which is what Mike mostly looked into - we're not addressing, however, at least not for any particular cell.

It would generally help if people understood that when someone talks about speeds or capacity in relation to Starlink, then it's usually meaningless unless they say exactly what capacity they mean:

• Capacity / speed to / from individual user?
• Capacity / speed to / from individual cell? Cell where? Cell in which neighbourhood context (any dishys in the neighbourhood)?
  
• Capacity of satellite to all dishy users in FOV combined?
• Capacity of all beams (including sat to / from gateways) on a satellite?
  
• Capacity in sky seen by a dishy (only part of which may be deployable to the cell that the dishy is in, but which acts as an indicator of whether the cell is likely to get as much as spectrum permits)
  
• Capacity of optical links.
  
• Total system capacity worldwide.

These are all totally different, dependent on generation of satellite and latitude, and in a lot of cases on more than just your dishy and the one satellite it's talking to at the moment. Yet our influencer friends seem to be only too happy to post numbers without context, and then they cause a flurry when they get re-posted here.

It's also important to remember that the maximum achievable physical layer data rates aren't the only factor in how well a connectivity solution works and how scalable it is. Bufferbloat's been discussed here extensively, but the thing that I'm almost more concerned about is the absence of an obvious way of running a CDN on/via/for a LEO network. This means that a big chunk of the collective physical capacity of Starlink gets spent on transmitting the same content to large numbers of users one user at a time: Each user needs their own copy communicated to them, and it takes up capacity every single time. This is fundamentally different from what happens on international fibre cables now.

Did those of you in the Seattle to Portland (OR) corridor, those around Sacramento (CA) and San Diego (CA), those around Edmonton (Canada), Rio de Janeiro and Sao Paolo, London (UK), Manila, Jakarta, Brisbane, Perth, Harare, Abuja, Accra, Port Harcourt and a whole bunch of other places notice that you can no longer get a fixed address Starlink connection there? Sold out, and not for lack of dishys, I guess.

The following I can think of:

v2mini satellites are not modeled, and are now a great portion of the constellation.
Gateways now have Ka and E band capability, increasing backhaul capacity considerably (5 GHz available on E band).

I am under the impression that much of the rocky mountains - eastern
USA can only be served by E and Ka and not Ku?

Several megasites have been constructed (32 gateway antennas per site).
Additional Ku beams are available on v2mini satellites.
ISL is a complete mesh now, with very few gaps.

I keep wondering what tokoyo to london latency is via ISL.

DTC onboard newer v2mini satellites.
Reduced operational altitude on some shells, enabling more frequency re-use, and 3-4 dB better link margin.
New versions of the UT, with Mini being the equivalent of 802.11b Wi-Fi clients ruining the party for G/N clients by dragging down resources.

I thought this would really hurt the constellation initially, but if
you consider most of the time
a dish is idle, not so much.

Best,

Mike
On Jan 14, 2025 at 14:24 -0800, Dave Taht via Starlink <starlink@lists.bufferbloat.net>, wrote:

https://mikepuchol.com/modeling-starlink-capacity-843b2387f501

It has a few challengeable assumptions now.

--
Dave Täht CSO, LibreQos
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

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