From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: David Lang <david@lang.hm>
Cc: Mike Puchol <mike@starlink.sx>,
starlink@lists.bufferbloat.net,
Michael Richardson <mcr@sandelman.ca>
Subject: [Starlink] Re: Starlink and Iran
Date: Thu, 29 Jan 2026 09:43:32 +1300 [thread overview]
Message-ID: <4bde9877-a034-4897-b2dd-89d6d3d43e49@auckland.ac.nz> (raw)
In-Reply-To: <89q404n0-7205-86o5-p825-o6o140619o6n@ynat.uz>
Again, not that straightforward.
These beams have to come from somewhere, and there has to be - from the
ground perspective - some angular separation between them, lest adjacent
beams both end up in the main lobe of the same receiver on the ground.
So there's only so much potential here - and 8 beams might already be
pushing it in a dynamic environment like LEO. Remember: You have to
maintain that angular separation until at least the next handover (and
you don't want to have these too often as they mean packets being sent
pre-handover into queues heading for the pre-handover satellite ->
packet loss if these queues don't clear before the handover).
Phased arrays (unlike real dishes) also have non-insignificant side
lobes, and an unwanted beam getting into one of those raises the noise
floor.
User density isn't just a matter of population density but also of fibre
and mobile penetration on the ground. In places like NZ, where fibre
penetration in cities and towns is high, user density is highest in
their outer periphery (where lifestyle block meets IT manager just
outside fibre coverage). In other places, where there hasn't ever been a
concerted push to fibre up cities, you find it's the townsfolk who buy
Starlink's shelves bare. The US are probably more in that category.
Going over the limits in the US would be a nice experiment I think. If
it works there, I'm sure the likes of Brazil and the Philippines would
be watching closely.
On 28/01/2026 10:53 pm, David Lang wrote:
> rather than looking at it as 'every 3db lets you add 1 bit/s/Hz', look
> at it as 'every 3db lets you double the number of beams covering the
> area.
>
> With enough satellites, it's easy to have multiple satellites in view
> at sufficiently different angles. They have 10k satellites up now and
> were providing coverage with something around 1k satellites.
>
> it would be interesting to learn the density of users in different
> countries. I would not be surprised to learn that the US has far more
> users/area than other countries, so if Starlink limits itself to the
> article 21 emissions outside the US but goes over the limits in the
> US, why would it be a problem?
>
> David Lang
>
> On Wed, 28 Jan 2026, Ulrich Speidel wrote:
>
>> Date: Wed, 28 Jan 2026 22:05:24 +1300
>> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
>> To: Mike Puchol <mike@starlink.sx>, starlink@lists.bufferbloat.net
>> Cc: Michael Richardson <mcr@sandelman.ca>, David Lang <david@lang.hm>
>> Subject: Re: [Starlink] Re: Starlink and Iran
>>
>> It's not that straightforward.
>>
>> The EPFD limits under Article 21 apply as an aggregate limit, not on
>> a per-beam basis. With Nco=1, a single beam can utilise this limit.
>> This lets that beam project (for v2) 64QAM, and for v1 (16QAM) as the
>> underlying modulation scheme of the OFDM. But only just - the fade
>> margin there is ~1 dB. That gives the beam a theoretical capacity of
>> 6 bit/s / Hz for v2 and 4 bit/s / Hz for v1.
>>
>> If you use both polarisations, each beam needs to be lowered in power
>> by half (3 dB), which costs 1 bit/s / Hz. So in v2, using two
>> co-frequency beams with opposing polarisation gives you 2 * (6 - 1) =
>> 10 bit/s / Hz in total for v2, or 2 * (4 - 1) = 6 bit/s / Hz. That's
>> what's been possible so far.
>>
>> If you read 4. a. as "on the same frequency" rather than "in the same
>> frequency band" and thus go to Nco=8, then that EPFD budget needs to
>> be shared between the 8 beams. If that's done equally, this knocks
>> back the received power per beam by 9 dB. Now, each 3 dB in power
>> loss costs the beam 1 bit/s / Hz in capacity. So if these are v2
>> beams, you're now down to 3 bit/s / Hz and for v1 you're at 1 bit/s /
>> Hz. So using just one polarisation gives you up to 8 * 3 = 24 bit/s
>> Hz for v2. That's a factor of 2.4 in terms of capacity for v2 or 4/3
>> for v1. The latter is a bit academic since the grant is for v2 only.
>>
>> So it's not nothing, but it's not a factor of 8. The main benefit
>> here could be easier compliance with the requirements of Article 22
>> though, so the factor of 2.4 could translate into something a bit
>> higher in some practical situations where Article 22 currently bites
>> first.
>>
>> Now we can't use the opposite polarisation of each beam here because
>> that would remain a co-frequency beam and thus we'd exceed the limit
>> of 8. If Starlink were to use 4 co-frequency beams of each
>> polarisation, we'd need to lop off another 3 dB or 1 bit/s / Hz per
>> beam. That would give us 16 bit/s / Hz across the 2 * 4 beams.
>>
>> Note that the satellite's beam shaping (different from beam steering)
>> ensures that the footprint on the ground is more or less circular and
>> covers the H3 hexagon pretty much exactly, with the beam contour
>> leaking into the adjacent cells, thereby ensuring that if all 8
>> co-frequency beams point at a cell, then neither this frequency (nor
>> beams with the opposite polarisation on the same frequency) can be
>> used for the cells next door.
>>
>> Also note that deploying that number of beams assumes that you have a
>> sufficient number of spacecraft (very easy) in the right positions
>> (much harder) to allow 8 beams to downlink without interfering with
>> each other - you'll need significant angular separation here from the
>> Dishy perspective.
>>
>> David was asking what would happen if the EPFD limits were raised. In
>> terms of Article 21, my answer would by "by how much?" Every 3 dB
>> increase would translate into 1 bit/s / Hz extra per beam. But quite
>> how many such steps are realistic before you get to power values that
>> are difficult to provide in space is another question.
>>
>> Sure, with Starship you could launch larger satellites. But larger
>> satellites with larger panels also have a larger cross-section, and
>> that has an impact on collision probabilities and so on.
>>
>> Another notable point is the addition of multiple frequency bands for
>> uplink and for what is clearly only suitable for downlink to gateway.
>> This indicates that SpaceX are feeling the need for more uplink
>> capacity as gateways now don't just supply bent pipes through a
>> single satellite but are actually feed points for a much larger mesh.
>>
>> On 28/01/2026 5:02 pm, Mike Puchol wrote:
>>> One clarification, nco = 8 means 8 co-frequency beams overlapping.
>>> If you have 8 different channels in Ku band, that’s a total of 64
>>> possible beams per cell. This is a huge upgrade from the original
>>> nco = 1 for user/service beams (e.g. max 8 beams per cell).
>>>
>>> Best,
>>>
>>> Mike
>>> On Jan 27, 2026 at 19:30 -0800, David Lang via Starlink
>>> <starlink@lists.bufferbloat.net>, wrote:
>>>> Ulrich Speidel wrote:
>>>>
>>>>> Either way, it's worth noting here that while the relationship
>>>>> between
>>>>> transmit power and and received power is linear, the relationship
>>>>> between
>>>>> received power and achievable bit rate is logarithmic in nature.
>>>>> For those
>>>>> not so mathematically inclined: Starlink is starting off with
>>>>> 64QAM (6 bits
>>>>> per symbol) at current EPFD limits, and each extra bit beyond that
>>>>> requires a
>>>>> doubling of the received power. Turning up the volume is not a
>>>>> game you can
>>>>> stay ahead in for long, regardless of regulatory constraints.
>>>>
>>>> I think that the value in allowing higher radiated power at the
>>>> receive end
>>>> isn't to increase the bit rate from a single satellite, but to
>>>> allow multiple
>>>> satellites to cover the same area with the beam steering on the
>>>> receiver
>>>> differentiating between the satellites.
>>>>
>>>> allowing two satellites with significantly different angles to
>>>> cover the same
>>>> area allows for (close to) 2x the aggregate bandwidth to spread
>>>> between all
>>>> receivers in that area.
>>>>
>>>>> Some interesting tidbits from the grant document though:
>>>>>
>>>>> * 4. a. No more than 8 satellite beams "in the same frequency" (I
>>>>> presume there's the word "band" missing here) into the same or
>>>>> overlapping areas at a time. That means at most 8 beams per cell.
>>>>
>>>> if that's a step up from a single beam, that will allow for close
>>>> to 8x the
>>>> aggregate bandwidth.
>>>>
>>>> And if they can show (over time) that this doesn't cause problems,
>>>> it will be
>>>> reasonable to expect raising this limit over time
>>>>
>>>> it may be band, or it may be frequency/channel (like wifi has 3
>>>> bands, 2.4G, 5G,
>>>> 6G), but 5G has many non-overlapping channels, and operating on
>>>> multiple
>>>> channels at the same time is quite reasonable for high-end APs
>>>>
>>>>> * 4. b. "SpaceX must maintain a minimum GSO arc exclusion zone of at
>>>>> least four (4) degrees with respect to operational GSO satellites".
>>>>> Finally a clear word?
>>>>
>>>> that geo exclusion has been in place for a while, but I thought it
>>>> was a lot
>>>> wider than 8 degrees (4 degrees to each side) I seem to remember
>>>> hearing 25
>>>> degrees being thrown around in discussions (I may very well be
>>>> misremembering)
>>>>
>>>> David Lang
>>>> _______________________________________________
>>>> 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/
****************************************************************
next prev parent reply other threads:[~2026-01-28 20:43 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
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 [this message]
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=4bde9877-a034-4897-b2dd-89d6d3d43e49@auckland.ac.nz \
--to=u.speidel@auckland.ac.nz \
--cc=david@lang.hm \
--cc=mcr@sandelman.ca \
--cc=mike@starlink.sx \
--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