Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran
Date: Fri, 16 Jan 2026 13:13:18 +1300	[thread overview]
Message-ID: <5ea10a2c-4549-4d7f-9563-c5dc590857b0@auckland.ac.nz> (raw)
In-Reply-To: <BN7PPF7A8514BAD6A406106C3476B563A69F18CA@BN7PPF7A8514BAD.namprd16.prod.outlook.com>

Hi Colin, great question!

The analogy between beams that come down from the satellites and a laser 
pointer / telescope combination as a replacement for the phased array 
antennas is of course conceptual only. Starlink user downlink beams are 
beam shaped and put a circular spot on the surface of Earth that 
essentially covers a hexagonal (or in rarer cases pentagonal) cell on 
the ground (H3 cell as per Uber H3 at resolution 5 o 6 - nod to Mike 
Puchol here for bringing this up some time ago). These are a few miles 
wide. Within that cell, SpaceX can use each available 
frequency-polarisation combination only once for a beam.

What does "available" mean? These are all in a 2000 MHz (2 GHz) wide 
band between 10.7 and 12.7 GHz (Ku down). For starters, SpaceX needs a 
license for whatever part of that band it wants to use in this location. 
Even if SpaceX has a license, it may not be able to use all of the 
frequency-polarisation combinations there, e.g., because there are 
Dishys in adjacent cells that also need service and  
frequency-polarisation combination in use in one cell can't be re-used 
in its neighbourhood (much like in a cellphone network). Now in a lot of 
communication situations you can make up for lack of frequency bandwidth 
by increasing power and transmitting more bits per symbol. Not so here. 
Why? Because there is a limit on the amount of power per square metre 
and MHz of bandwidth (EPFD) that systems such as Starlink may project 
onto the surface of the Earth. It's an ITU-imposed limit, so the FCC 
can't really do much about it. SpaceX are on public record for not being 
happy with it and with their v2's they're riding right up against that 
limit. This essentially limits capacity per cell in dependence of what 
the licensing environment and the cell's neighbourhood look like in 
terms of demand. It's one of the reasons why Starlink downlink rates 
differ from place to place.

Now the aforementioned Ku-band is also shared, and there aren't really 
any other usable bands. Go down in frequency and it gets crowded, you 
need bigger antennas and focussing and steering your beam becomes much 
harder. Go further up in frequency and rain fade becomes a serious issue 
- for which you'd need to compensate with bigger Dishys. So that Ku band 
is where everyone wants to be: OneWeb, SpaceX, Kuiper, and whoever else 
is currently building LEO networks. Now if Elon gets permission to put a 
beam on frequency f into your neighbourhood, then that's his patch on 
that frequency, and Jeff & Co. either need to find themselves a 
frequency that isn't taken there yet (and isn't in use by Elon in the 
neighbourhood either), or they need to persuade the FCC to take it off 
Elon.

The other issue is orbits: Starlink now occupies an increasing amount of 
space real estate in the LEO Goldilocks zone. Go higher and you pay in 
terms of latency, and it also becomes harder to direct your beams into 
small spots on the ground. Plus you need more transmitter power or 
antenna gain to get to the EPFD limit. Go lower and you'll pay in terms 
of satellite lifetime - not ideal unless you have rapid launch 
capability. Try and snuggle up with Starlink at the same altitude and 
someone will argue that this increases the risk of collisions and hence 
Kessler syndrome.

So that's why Jeff Bezos and others are worried.

On 16/01/2026 10:49 am, Colin_Higbie via Starlink wrote:
> Ulrich, thanks. That's a great description and you're right that I had not appreciated how much more directional these are today  (in fact, in the early military applications, before it was available in cell phones, the lack of directionality was important to protect our teams from being located, even as they were transmitting from close to an enemy location).
>
> However, this creates a follow-up question: working as you describe, which I accept as correct, why the big concern from Jeff Bezos and others about the sky coverage of the Starlink LEO constellation making it tough for them? If the signal is as hyperdirectional as you've described (also saw your laser pointer example in response to Hayden Simon), I would think that means very low risk of significant interference between two nearby layers of satellites. Even with thousands zipping around the Earth, I would think the probability is quite low of any two of them being on the same line to a home dish. What kind of interference are Starlink's competitors complaining about? Is it that while it's tight beam, it's still not *that* tight, so if they're within a few miles of each other, that's enough to trigger interference?
>
> Thanks,
> Colin
>
>
> -----Original Message-----
> From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
> Sent: Friday, 16 January 2026 9:27 am
> To: starlink@lists.bufferbloat.net
> Subject: [Starlink] Re: Starlink and Iran
>
> On 16/01/2026 6:42 am, Colin_Higbie via Starlink wrote:
>> Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.
>>
>> Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.
>>
>> Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago.
> The original spread spectrum work concerned much much lower frequencies (in the MHz rather than the GHz) and the physics that goes with lower frequencies (not just spread spectrum) is that at the time, jamming was mostly used against receivers with fairly omnidirectional antennas.
> Read: It doesn't really matter where you transmit your interfering signal from - the receiver will hear it. It also helps that the (free
> space) path loss of RF signals is proportional to the square of the frequency, so low frequency means you can hit a receiver over a substantial distance with relatively little power.
>
> Starlink is a different ballgame: It operates in Ku-band above 10 GHz.
> This means highly directional antennas - so you literally need to transmit into the receive beam from the beam's preferred direction to be able to jam at all. Plus having to invest more power to bridge the distance means that flooding just isn't an option here.
>
> --
> ****************************************************************
> 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
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

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




  parent reply	other threads:[~2026-01-16  0:13 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <176851123059.1249.8585659892308012167@gauss>
2026-01-15 21:49 ` [Starlink] Re: Starlink and Iran Colin_Higbie
2026-01-15 23:15   ` Frantisek Borsik
2026-01-16  0:13   ` Ulrich Speidel [this message]
2026-01-16  1:29     ` David Lang
2026-01-16 22:55       ` Frantisek Borsik
2026-01-16 23:06         ` J Pan
     [not found]     ` <13187.1768590201@obiwan.sandelman.ca>
2026-01-16 23:30       ` Ulrich Speidel
2026-01-17  0:07         ` David Lang
2026-01-17 21:56           ` Ulrich Speidel
2026-01-19 20:39             ` David Lang
2026-01-28  3:09               ` Ulrich Speidel
2026-01-28  3:30                 ` David Lang
2026-01-28  4:02                   ` Mike Puchol
2026-01-28  9:05                     ` Ulrich Speidel
2026-01-28  9:53                       ` David Lang
2026-01-28 20:43                         ` Ulrich Speidel
2026-01-28 20:55                           ` David Lang
2026-01-17 18:32         ` Michael Richardson
2026-01-17 18:38           ` Inemesit Affia
2026-01-17 19:25             ` Michael Richardson
2026-01-17 22:12           ` Ulrich Speidel
     [not found] <176849731431.1249.14387618908540773471@gauss>
2026-01-15 17:42 ` Colin_Higbie
2026-01-15 18:56   ` Jim Forster
2026-01-15 20:15     ` Ulrich Speidel
2026-01-15 20:27   ` Ulrich Speidel
2026-01-15 20:30     ` Hayden Simon
2026-01-15 21:06       ` Ulrich Speidel
2026-01-15 21:09         ` Hayden Simon
2026-01-15 21:20           ` Ulrich Speidel
2026-01-15 21:23             ` Hayden Simon
2026-01-15 14:50 David Fernández
2026-01-15 16:11 ` Oleg Kutkov
2026-01-15 17:13   ` J Pan
  -- strict thread matches above, loose matches on Subject: below --
2026-01-15  9:51 [Starlink] " Ulrich Speidel
2026-01-15 10:06 ` [Starlink] " Inemesit Affia
2026-01-15 10:30   ` Ulrich Speidel
2026-01-15 10:44     ` Inemesit Affia
2026-01-15 11:16       ` Ulrich Speidel
2026-01-15 10:32 ` Inemesit Affia
2026-01-15 10:51   ` Ulrich Speidel
2026-01-15 11:17 ` David Lang
2026-01-15 11:59   ` Sauli Kiviranta
2026-01-15 14:08     ` David Lang
2026-01-15 15:29       ` Sauli Kiviranta
     [not found]   ` <3af2ac06-e098-4c79-869d-9c389959ca07@gmail.com>
     [not found]     ` <q9304244-661o-3qsr-o6rp-9q1nqq09r419@ynat.uz>
     [not found]       ` <4ba64a41-bbbf-4fb5-adb0-c77c15e4ca0f@gmail.com>
2026-01-15 16:20         ` Inemesit Affia
2026-01-15 20:12   ` Ulrich Speidel
2026-01-15 17:10 ` J Pan
2026-01-15 20:07   ` Ulrich Speidel
2026-01-15 21:47     ` Oleg Kutkov
2026-01-16  4:18       ` Ulrich Speidel
2026-01-16  8:12         ` Frantisek Borsik
2026-01-16  8:24           ` Inemesit Affia

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=5ea10a2c-4549-4d7f-9563-c5dc590857b0@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