[Starlink] System and method of providing a medium access control scheduler

[Starlink] System and method of providing a medium access control scheduler

[Dave Taht]

For those of you that don't look at patents, don't look at:

https://patents.justia.com/patent/11540301

But I would welcome comment from those that do.

H/T virtuallynathan.

-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC

Re: [Starlink] System and method of providing a medium access control scheduler

[Oleg Kutkov]

Oh, that's interesting.

 >> the satellite broadcasts the downlink radio frame to all the user 
terminals in a group and they each retrieve their respective data from 
the downlink radio frame

I thought the satellite beamformer only sends data frames to the 
appropriate UT. It looks like the given satellite covers the whole cell 
at one TX channel.
Otherwise, it would be too complex, I guess.

On 2/23/23 23:53, Dave Taht via Starlink wrote:
> For those of you that don't look at patents, don't look at:
>
> https://patents.justia.com/patent/11540301
>
> But I would welcome comment from those that do.
>
> H/T virtuallynathan.
>
-- 
Best regards,
Oleg Kutkov

Re: [Starlink] System and method of providing a medium access control scheduler

[David Lang]

they can only narrow the radio beam so much (probably whatever their cell size 
is). They can't change the footprint without changing the antenna, so unless 
they have the beam move around in the cell, the footprint should be slightly 
larger than the cell size

sometimes there is a lot of data going to one station, but sometims it's only 
going to be a trival amount (think ack packets for a lot of uploads), so they 
can save airtime by using one timeslot to transmit to many stations at once.

David Lang

On Fri, 24 Feb 2023, Oleg Kutkov via Starlink wrote:

> Date: Fri, 24 Feb 2023 01:47:05 +0200
> From: Oleg Kutkov via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: Oleg Kutkov <contact@olegkutkov.me>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] System and method of providing a medium access control
>      scheduler
> 
> Oh, that's interesting.
>
> >> the satellite broadcasts the downlink radio frame to all the user 
> terminals in a group and they each retrieve their respective data from 
> the downlink radio frame
>
> I thought the satellite beamformer only sends data frames to the 
> appropriate UT. It looks like the given satellite covers the whole cell 
> at one TX channel.
> Otherwise, it would be too complex, I guess.
>
> On 2/23/23 23:53, Dave Taht via Starlink wrote:
>> For those of you that don't look at patents, don't look at:
>>
>> https://patents.justia.com/patent/11540301
>>
>> But I would welcome comment from those that do.
>>
>> H/T virtuallynathan.
>>
>

Re: [Starlink] System and method of providing a medium access control scheduler

[Oleg Kutkov]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

Yes. The cell size is ~20 km

On 2/24/23 02:08, David Lang wrote:
> they can only narrow the radio beam so much (probably whatever their 
> cell size is). They can't change the footprint without changing the 
> antenna, so unless they have the beam move around in the cell, the 
> footprint should be slightly larger than the cell size
>
> sometimes there is a lot of data going to one station, but sometims 
> it's only going to be a trival amount (think ack packets for a lot of 
> uploads), so they can save airtime by using one timeslot to transmit 
> to many stations at once.
>
> David Lang
>
> On Fri, 24 Feb 2023, Oleg Kutkov via Starlink wrote:
>
>> Date: Fri, 24 Feb 2023 01:47:05 +0200
>> From: Oleg Kutkov via Starlink <starlink@lists.bufferbloat.net>
>> Reply-To: Oleg Kutkov <contact@olegkutkov.me>
>> To: starlink@lists.bufferbloat.net
>> Subject: Re: [Starlink] System and method of providing a medium 
>> access control
>>      scheduler
>>
>> Oh, that's interesting.
>>
>> >> the satellite broadcasts the downlink radio frame to all the user 
>> terminals in a group and they each retrieve their respective data 
>> from the downlink radio frame
>>
>> I thought the satellite beamformer only sends data frames to the 
>> appropriate UT. It looks like the given satellite covers the whole 
>> cell at one TX channel.
>> Otherwise, it would be too complex, I guess.
>>
>> On 2/23/23 23:53, Dave Taht via Starlink wrote:
>>> For those of you that don't look at patents, don't look at:
>>>
>>> https://patents.justia.com/patent/11540301
>>>
>>> But I would welcome comment from those that do.
>>>
>>> H/T virtuallynathan.
>>>
>>
-- 
Best regards,
Oleg Kutkov

[-- Attachment #2.1: Type: text/html, Size: 3078 bytes --]

[-- Attachment #2.2: dUsO08OKzqrAgrTa.png --]
[-- Type: image/png, Size: 35251 bytes --]

Re: [Starlink] System and method of providing a medium access control scheduler

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]

Did you mean to say 20 km diameter or 20 km^2 area?

For those not familiar with RF engineering terms: A 3 dB contour as Oleg 
shows it below in blue is the line where the power flux density from the 
satellite drops to half of the value at the centre of the beam. That's 
important as in RF engineering of cellular or beam division networks, 
the minimum power you need to receive a signal successfully can be 
several orders of magnitude larger than the amount of power you need to 
cause interference to off-beam unintended receivers. So in terms of 
their interference contour, beams are actually much wider than just a 
cell or so, and a power flux density half as high as at beam centre 
doesn't mean that it's the perimeter of the beam as such - the beam will 
happily interfere with anyone up to a few cells down the road at least.

Incidentally, I'm seeing Dishy use more power when it's receiving at 
higher rates, which is what you'd expect if its DSP is busy digging out 
intended signals from unintended ones.

On 24/02/2023 1:18 pm, Oleg Kutkov via Starlink wrote:
>
> Yes. The cell size is ~20 km
>
> On 2/24/23 02:08, David Lang wrote:
>> they can only narrow the radio beam so much (probably whatever their 
>> cell size is). They can't change the footprint without changing the 
>> antenna, so unless they have the beam move around in the cell, the 
>> footprint should be slightly larger than the cell size
>>
>> sometimes there is a lot of data going to one station, but sometims 
>> it's only going to be a trival amount (think ack packets for a lot of 
>> uploads), so they can save airtime by using one timeslot to transmit 
>> to many stations at once.
>>
>> David Lang
>>
>> On Fri, 24 Feb 2023, Oleg Kutkov via Starlink wrote:
>>
>>> Date: Fri, 24 Feb 2023 01:47:05 +0200
>>> From: Oleg Kutkov via Starlink <starlink@lists.bufferbloat.net>
>>> Reply-To: Oleg Kutkov <contact@olegkutkov.me>
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Re: [Starlink] System and method of providing a medium 
>>> access control
>>>      scheduler
>>>
>>> Oh, that's interesting.
>>>
>>> >> the satellite broadcasts the downlink radio frame to all the user 
>>> terminals in a group and they each retrieve their respective data 
>>> from the downlink radio frame
>>>
>>> I thought the satellite beamformer only sends data frames to the 
>>> appropriate UT. It looks like the given satellite covers the whole 
>>> cell at one TX channel.
>>> Otherwise, it would be too complex, I guess.
>>>
>>> On 2/23/23 23:53, Dave Taht via Starlink wrote:
>>>> For those of you that don't look at patents, don't look at:
>>>>
>>>> https://patents.justia.com/patent/11540301
>>>>
>>>> But I would welcome comment from those that do.
>>>>
>>>> H/T virtuallynathan.
>>>>
>>>
> -- 
> Best regards,
> Oleg Kutkov
>
> _______________________________________________
> 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/
****************************************************************



[-- Attachment #2.1: Type: text/html, Size: 5632 bytes --]

[-- Attachment #2.2: dUsO08OKzqrAgrTa.png --]
[-- Type: image/png, Size: 35251 bytes --]

Re: [Starlink] System and method of providing a medium access control scheduler

[Oleg Kutkov]

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

It's 20 km in diameter, roughly.

On 2/24/23 02:51, Ulrich Speidel via Starlink wrote:
>
> Did you mean to say 20 km diameter or 20 km^2 area?
>
> For those not familiar with RF engineering terms: A 3 dB contour as 
> Oleg shows it below in blue is the line where the power flux density 
> from the satellite drops to half of the value at the centre of the 
> beam. That's important as in RF engineering of cellular or beam 
> division networks, the minimum power you need to receive a signal 
> successfully can be several orders of magnitude larger than the amount 
> of power you need to cause interference to off-beam unintended 
> receivers. So in terms of their interference contour, beams are 
> actually much wider than just a cell or so, and a power flux density 
> half as high as at beam centre doesn't mean that it's the perimeter of 
> the beam as such - the beam will happily interfere with anyone up to a 
> few cells down the road at least.
>
> Incidentally, I'm seeing Dishy use more power when it's receiving at 
> higher rates, which is what you'd expect if its DSP is busy digging 
> out intended signals from unintended ones.
>
> On 24/02/2023 1:18 pm, Oleg Kutkov via Starlink wrote:
>>
>> Yes. The cell size is ~20 km
>>
>> On 2/24/23 02:08, David Lang wrote:
>>> they can only narrow the radio beam so much (probably whatever their 
>>> cell size is). They can't change the footprint without changing the 
>>> antenna, so unless they have the beam move around in the cell, the 
>>> footprint should be slightly larger than the cell size
>>>
>>> sometimes there is a lot of data going to one station, but sometims 
>>> it's only going to be a trival amount (think ack packets for a lot 
>>> of uploads), so they can save airtime by using one timeslot to 
>>> transmit to many stations at once.
>>>
>>> David Lang
>>>
>>> On Fri, 24 Feb 2023, Oleg Kutkov via Starlink wrote:
>>>
>>>> Date: Fri, 24 Feb 2023 01:47:05 +0200
>>>> From: Oleg Kutkov via Starlink <starlink@lists.bufferbloat.net>
>>>> Reply-To: Oleg Kutkov <contact@olegkutkov.me>
>>>> To: starlink@lists.bufferbloat.net
>>>> Subject: Re: [Starlink] System and method of providing a medium 
>>>> access control
>>>>      scheduler
>>>>
>>>> Oh, that's interesting.
>>>>
>>>> >> the satellite broadcasts the downlink radio frame to all the 
>>>> user terminals in a group and they each retrieve their respective 
>>>> data from the downlink radio frame
>>>>
>>>> I thought the satellite beamformer only sends data frames to the 
>>>> appropriate UT. It looks like the given satellite covers the whole 
>>>> cell at one TX channel.
>>>> Otherwise, it would be too complex, I guess.
>>>>
>>>> On 2/23/23 23:53, Dave Taht via Starlink wrote:
>>>>> For those of you that don't look at patents, don't look at:
>>>>>
>>>>> https://patents.justia.com/patent/11540301
>>>>>
>>>>> But I would welcome comment from those that do.
>>>>>
>>>>> H/T virtuallynathan.
>>>>>
>>>>
>> -- 
>> Best regards,
>> Oleg Kutkov
>>
>> _______________________________________________
>> 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

-- 
Best regards,
Oleg Kutkov

[-- Attachment #2.1: Type: text/html, Size: 6878 bytes --]

[-- Attachment #2.2: dUsO08OKzqrAgrTa.png --]
[-- Type: image/png, Size: 35251 bytes --]

Re: [Starlink] System and method of providing a medium access control scheduler

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

I do hope more patents appear. There is apparently no support for retries
at this layer (yay!), no documentation on what error correction is used
besides OFDMA, or how packets are encrypted.

Some of the patents cited are pretty interesting, notably the oldest one.
Good to have some baseline numbers for the intervals!

[-- Attachment #2: Type: text/html, Size: 383 bytes --]