[Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Hesham ElBakoury]

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

Here is a report which summarizes the outcome of the last Satellites
conference  [
https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
]

The report highlights the two main hurdles against the integration of
satellites and terrestrial networks: standardization and business model.

"*Most of the pushback against closer integration of terrestrial wireless
and satellite networks revolved around standardization. This may just be
growing pains and it likely reflects the relative positions of wireless and
satellite along the maturity curve, but some of the speakers were arguing
against standardization. The basis of this argument was that the mobile
industry only understands standards, but the satellite industry is
currently differentiating based on custom systems and capabilities. The
feeling was that the satellite industry had focused on technology and not
regulations or standards and changing that course would not be helpful to
the industry in the short term. Timing is important in this analysis
because almost everyone agreed that at some point, standardization would be
a good thing, but the concern was the best way to get to the point in the
future. The other interesting argument against closer integration between
wireless and satellite had to do with the business model. Several speakers
questioned where the customers would go as terrestrial and non-terrestrial
networks become more integrated. The underlying issues seemed to include
who is responsible for solving network issues and perhaps more importantly,
who recognizes the revenue. These issues seem, perhaps a bit
simplistically, to be similar to early wireless roaming issues. While these
issues created turbulence in the wireless market, they were solved and that
is probably a template to address these challenges for the wireless and
satellite operators."*

Comments?

Hesham

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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
> Here is a report which summarizes the outcome of the last Satellites 
> conference  
> [https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up]
>
> The report highlights the two main hurdles against the integration of 
> satellites and terrestrial networks: standardization and business model.
>
> "/Most of the pushback against closer integration of terrestrial 
> wireless and satellite networks revolved around standardization. This 
> may just be growing pains and it likely reflects the relative 
> positions of wireless and satellite along the maturity curve, but some 
> of the speakers were arguing against standardization. The basis of 
> this argument was that the mobile industry only understands standards, 
> but the satellite industry is currently differentiating based on 
> custom systems and capabilities. The feeling was that the satellite 
> industry had focused on technology and not regulations or standards 
> and changing that course would not be helpful to the industry in the 
> short term. Timing is important in this analysis because almost 
> everyone agreed that at some point, standardization would be a good 
> thing, but the concern was the best way to get to the point in the 
> future. The other interesting argument against closer integration 
> between wireless and satellite had to do with the business model. 
> Several speakers questioned where the customers would go as 
> terrestrial and non-terrestrial networks become more integrated. The 
> underlying issues seemed to include who is responsible for solving 
> network issues and perhaps more importantly, who recognizes the 
> revenue. These issues seem, perhaps a bit simplistically, to be 
> similar to early wireless roaming issues. While these issues created 
> turbulence in the wireless market, they were solved and that is 
> probably a template to address these challenges for the wireless and 
> satellite operators."/
> /
> /
> Comments?


It is an interesting report.

For standardisation standpoint, it seems SDOs do push towards 
integration of 5G/6G and satcom; there are strong initiatives at least 
at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But 
these are SDOs traditionally oriented to land communications, rather 
than space satcom.

I wonder whether space satcom traditional SDOs (which ones?) have 
initiated work towards integration with 5G/6G and other land-based Internet?

Alex

>
> Hesham
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Inemesit Affia]

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

With the existence of solutions like OpenMTCProuter, SDWAN, policy based
routing or any solution in general that allows combination in a sense of
any number of IP links, I really don't see a point for specific solutions.
Can anyone enlighten me?

For home users an issue may be IP blocks for certain services like Netflix
when the egress is out of a VPN or cloud provider richer than a residential
provider

On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
> > Here is a report which summarizes the outcome of the last Satellites
> > conference
> > [
> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
> ]
> >
> > The report highlights the two main hurdles against the integration of
> > satellites and terrestrial networks: standardization and business model.
> >
> > "/Most of the pushback against closer integration of terrestrial
> > wireless and satellite networks revolved around standardization. This
> > may just be growing pains and it likely reflects the relative
> > positions of wireless and satellite along the maturity curve, but some
> > of the speakers were arguing against standardization. The basis of
> > this argument was that the mobile industry only understands standards,
> > but the satellite industry is currently differentiating based on
> > custom systems and capabilities. The feeling was that the satellite
> > industry had focused on technology and not regulations or standards
> > and changing that course would not be helpful to the industry in the
> > short term. Timing is important in this analysis because almost
> > everyone agreed that at some point, standardization would be a good
> > thing, but the concern was the best way to get to the point in the
> > future. The other interesting argument against closer integration
> > between wireless and satellite had to do with the business model.
> > Several speakers questioned where the customers would go as
> > terrestrial and non-terrestrial networks become more integrated. The
> > underlying issues seemed to include who is responsible for solving
> > network issues and perhaps more importantly, who recognizes the
> > revenue. These issues seem, perhaps a bit simplistically, to be
> > similar to early wireless roaming issues. While these issues created
> > turbulence in the wireless market, they were solved and that is
> > probably a template to address these challenges for the wireless and
> > satellite operators."/
> > /
> > /
> > Comments?
>
>
> It is an interesting report.
>
> For standardisation standpoint, it seems SDOs do push towards
> integration of 5G/6G and satcom; there are strong initiatives at least
> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
> these are SDOs traditionally oriented to land communications, rather
> than space satcom.
>
> I wonder whether space satcom traditional SDOs (which ones?) have
> initiated work towards integration with 5G/6G and other land-based
> Internet?
>
> Alex
>
> >
> > Hesham
> >
> > _______________________________________________
> > 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
>

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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

Exactly my thoughts (I haven't downloaded and read the full report yet). What 
are they looking to do with this 'integration'? I can integrate my starlink just 
like any other ISP.

or are they looking at the 'cell phones to orbit' functionality thats due to 
roll out very suddently

or are they looking for "intergration" as another way to say "force SpaceX to 
open the specs for Starlink and allow other user terminals to interact with the 
Starlink satellites?

The cynic in me says it's the latter.

long term it may make sense to do this to some degree, but we are WAY too early 
to define "Interoperability Standards" and block people from coming up with 
better ways to do things.

the Apple vs SpaceX cellphone-to-satellite have completely different ways of 
operating, and who wants to tell all the Apple people that their way isn't going 
to be the standard (or worse, that it is and they have to give everyone else the 
ability to use their currently proprietary protocol)

David Lang

On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:

> With the existence of solutions like OpenMTCProuter, SDWAN, policy based
> routing or any solution in general that allows combination in a sense of
> any number of IP links, I really don't see a point for specific solutions.
> Can anyone enlighten me?
>
> For home users an issue may be IP blocks for certain services like Netflix
> when the egress is out of a VPN or cloud provider richer than a residential
> provider
>
> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>>
>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>> Here is a report which summarizes the outcome of the last Satellites
>>> conference
>>> [
>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>> ]
>>>
>>> The report highlights the two main hurdles against the integration of
>>> satellites and terrestrial networks: standardization and business model.
>>>
>>> "/Most of the pushback against closer integration of terrestrial
>>> wireless and satellite networks revolved around standardization. This
>>> may just be growing pains and it likely reflects the relative
>>> positions of wireless and satellite along the maturity curve, but some
>>> of the speakers were arguing against standardization. The basis of
>>> this argument was that the mobile industry only understands standards,
>>> but the satellite industry is currently differentiating based on
>>> custom systems and capabilities. The feeling was that the satellite
>>> industry had focused on technology and not regulations or standards
>>> and changing that course would not be helpful to the industry in the
>>> short term. Timing is important in this analysis because almost
>>> everyone agreed that at some point, standardization would be a good
>>> thing, but the concern was the best way to get to the point in the
>>> future. The other interesting argument against closer integration
>>> between wireless and satellite had to do with the business model.
>>> Several speakers questioned where the customers would go as
>>> terrestrial and non-terrestrial networks become more integrated. The
>>> underlying issues seemed to include who is responsible for solving
>>> network issues and perhaps more importantly, who recognizes the
>>> revenue. These issues seem, perhaps a bit simplistically, to be
>>> similar to early wireless roaming issues. While these issues created
>>> turbulence in the wireless market, they were solved and that is
>>> probably a template to address these challenges for the wireless and
>>> satellite operators."/
>>> /
>>> /
>>> Comments?
>>
>>
>> It is an interesting report.
>>
>> For standardisation standpoint, it seems SDOs do push towards
>> integration of 5G/6G and satcom; there are strong initiatives at least
>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>> these are SDOs traditionally oriented to land communications, rather
>> than space satcom.
>>
>> I wonder whether space satcom traditional SDOs (which ones?) have
>> initiated work towards integration with 5G/6G and other land-based
>> Internet?
>>
>> Alex
>>
>>>
>>> Hesham
>>>
>>> _______________________________________________
>>> 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
>>
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Inemesit Affia]

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

For the US military, starlink has already allowed two antenna/terminal
manufacturers to connect to the network.

Ball aerospace for aircraft.

DUJUD(hope I got that right) for regular user terminals.

Any antenna that connects with OneWeb should theoretically work apart from
the DRM

On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:

> Exactly my thoughts (I haven't downloaded and read the full report yet).
> What
> are they looking to do with this 'integration'? I can integrate my
> starlink just
> like any other ISP.
>
> or are they looking at the 'cell phones to orbit' functionality thats due
> to
> roll out very suddently
>
> or are they looking for "intergration" as another way to say "force SpaceX
> to
> open the specs for Starlink and allow other user terminals to interact
> with the
> Starlink satellites?
>
> The cynic in me says it's the latter.
>
> long term it may make sense to do this to some degree, but we are WAY too
> early
> to define "Interoperability Standards" and block people from coming up
> with
> better ways to do things.
>
> the Apple vs SpaceX cellphone-to-satellite have completely different ways
> of
> operating, and who wants to tell all the Apple people that their way isn't
> going
> to be the standard (or worse, that it is and they have to give everyone
> else the
> ability to use their currently proprietary protocol)
>
> David Lang
>
> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>
> > With the existence of solutions like OpenMTCProuter, SDWAN, policy based
> > routing or any solution in general that allows combination in a sense of
> > any number of IP links, I really don't see a point for specific
> solutions.
> > Can anyone enlighten me?
> >
> > For home users an issue may be IP blocks for certain services like
> Netflix
> > when the egress is out of a VPN or cloud provider richer than a
> residential
> > provider
> >
> > On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
> > starlink@lists.bufferbloat.net> wrote:
> >
> >>
> >> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
> >>> Here is a report which summarizes the outcome of the last Satellites
> >>> conference
> >>> [
> >>
> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
> >> ]
> >>>
> >>> The report highlights the two main hurdles against the integration of
> >>> satellites and terrestrial networks: standardization and business
> model.
> >>>
> >>> "/Most of the pushback against closer integration of terrestrial
> >>> wireless and satellite networks revolved around standardization. This
> >>> may just be growing pains and it likely reflects the relative
> >>> positions of wireless and satellite along the maturity curve, but some
> >>> of the speakers were arguing against standardization. The basis of
> >>> this argument was that the mobile industry only understands standards,
> >>> but the satellite industry is currently differentiating based on
> >>> custom systems and capabilities. The feeling was that the satellite
> >>> industry had focused on technology and not regulations or standards
> >>> and changing that course would not be helpful to the industry in the
> >>> short term. Timing is important in this analysis because almost
> >>> everyone agreed that at some point, standardization would be a good
> >>> thing, but the concern was the best way to get to the point in the
> >>> future. The other interesting argument against closer integration
> >>> between wireless and satellite had to do with the business model.
> >>> Several speakers questioned where the customers would go as
> >>> terrestrial and non-terrestrial networks become more integrated. The
> >>> underlying issues seemed to include who is responsible for solving
> >>> network issues and perhaps more importantly, who recognizes the
> >>> revenue. These issues seem, perhaps a bit simplistically, to be
> >>> similar to early wireless roaming issues. While these issues created
> >>> turbulence in the wireless market, they were solved and that is
> >>> probably a template to address these challenges for the wireless and
> >>> satellite operators."/
> >>> /
> >>> /
> >>> Comments?
> >>
> >>
> >> It is an interesting report.
> >>
> >> For standardisation standpoint, it seems SDOs do push towards
> >> integration of 5G/6G and satcom; there are strong initiatives at least
> >> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
> >> these are SDOs traditionally oriented to land communications, rather
> >> than space satcom.
> >>
> >> I wonder whether space satcom traditional SDOs (which ones?) have
> >> initiated work towards integration with 5G/6G and other land-based
> >> Internet?
> >>
> >> Alex
> >>
> >>>
> >>> Hesham
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >_______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 01/09/2023 à 18:27, Inemesit Affia a écrit :
> For the US military, starlink has already allowed two
> antenna/terminal manufacturers to connect to the network.
> 
> Ball aerospace for aircraft.
> 
> DUJUD(hope I got that right) for regular user terminals.

Thanks, I did not know that.

It is not clear from the announcements I read whether Ball aerospace and
DUJUD are simply antennas (albeit complex) plugged into starlink boxes
with a 50 ohm RF cable, or are they more computing than that.

I must say that I dont know whether the original 'DISHY' is simply a
dish antenna with an analog amplifier and maybe some mechanical motor
steering, or whether DISHY includes a computer to execute some protocol,
some algorithm.

If DUJUD and Ball aerospace make more than just the antennas, maybe
program some computers, then indeed there can be a sharing of protocol
documents from SpaceX (starlink) to DUJUD and Ball aerospace.  At that
point we'd be talking maybe of licensing.  These might be the premisses
of a need of interoperability.

Alex

> 
> Any antenna that connects with OneWeb should theoretically work apart
>  from the DRM
> 
> On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm 
> <mailto:david@lang.hm>> wrote:
> 
> Exactly my thoughts (I haven't downloaded and read the full report 
> yet). What are they looking to do with this 'integration'? I can
> integrate my starlink just like any other ISP.
> 
> or are they looking at the 'cell phones to orbit' functionality thats
> due to roll out very suddently
> 
> or are they looking for "intergration" as another way to say "force 
> SpaceX to open the specs for Starlink and allow other user terminals
> to interact with the Starlink satellites?
> 
> The cynic in me says it's the latter.
> 
> long term it may make sense to do this to some degree, but we are WAY
> too early to define "Interoperability Standards" and block people
> from coming up with better ways to do things.
> 
> the Apple vs SpaceX cellphone-to-satellite have completely different 
> ways of operating, and who wants to tell all the Apple people that
> their way isn't going to be the standard (or worse, that it is and
> they have to give everyone else the ability to use their currently
> proprietary protocol)
> 
> David Lang
> 
> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
> 
>> With the existence of solutions like OpenMTCProuter, SDWAN,
> policy based
>> routing or any solution in general that allows combination in a
> sense of
>> any number of IP links, I really don't see a point for specific
> solutions.
>> Can anyone enlighten me?
>> 
>> For home users an issue may be IP blocks for certain services
> like Netflix
>> when the egress is out of a VPN or cloud provider richer than a
> residential
>> provider
>> 
>> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink < 
>> starlink@lists.bufferbloat.net
> <mailto:starlink@lists.bufferbloat.net>> wrote:
>> 
>>> 
>>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>>> Here is a report which summarizes the outcome of the last
> Satellites
>>>> conference [
>>> 
> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
> <https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up>
>
> 
>> ]
>>>> 
>>>> The report highlights the two main hurdles against the
> integration of
>>>> satellites and terrestrial networks: standardization and
> business model.
>>>> 
>>>> "/Most of the pushback against closer integration of
>>>> terrestrial wireless and satellite networks revolved around
> standardization. This
>>>> may just be growing pains and it likely reflects the relative 
>>>> positions of wireless and satellite along the maturity curve,
> but some
>>>> of the speakers were arguing against standardization. The basis
>>>> of this argument was that the mobile industry only understands
> standards,
>>>> but the satellite industry is currently differentiating based
>>>> on custom systems and capabilities. The feeling was that the
>>>> satellite industry had focused on technology and not
>>>> regulations or standards and changing that course would not be
>>>> helpful to the industry
> in the
>>>> short term. Timing is important in this analysis because
>>>> almost everyone agreed that at some point, standardization
>>>> would be a good thing, but the concern was the best way to get
>>>> to the point in the future. The other interesting argument
>>>> against closer integration between wireless and satellite had
>>>> to do with the business model. Several speakers questioned
>>>> where the customers would go as terrestrial and non-terrestrial
>>>> networks become more
> integrated. The
>>>> underlying issues seemed to include who is responsible for
>>>> solving network issues and perhaps more importantly, who
>>>> recognizes the revenue. These issues seem, perhaps a bit
>>>> simplistically, to be similar to early wireless roaming issues.
>>>> While these issues
> created
>>>> turbulence in the wireless market, they were solved and that
>>>> is probably a template to address these challenges for the
> wireless and
>>>> satellite operators."/ / / Comments?
>>> 
>>> 
>>> It is an interesting report.
>>> 
>>> For standardisation standpoint, it seems SDOs do push towards 
>>> integration of 5G/6G and satcom; there are strong initiatives at
> least
>>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.
>>> But these are SDOs traditionally oriented to land communications,
>>> rather than space satcom.
>>> 
>>> I wonder whether space satcom traditional SDOs (which ones?)
>>> have initiated work towards integration with 5G/6G and other
>>> land-based Internet?
>>> 
>>> Alex
>>> 
>>>> 
>>>> Hesham
>>>> 
>>>> _______________________________________________ Starlink
>>>> mailing list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>> _______________________________________________ Starlink mailing
>>> list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>> 
>> _______________________________________________
> Starlink mailing list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net> 
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>
> 

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Ulrich Speidel]

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


On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>
> I must say that I dont know whether the original 'DISHY' is simply a
> dish antenna with an analog amplifier and maybe some mechanical motor
> steering, or whether DISHY includes a computer to execute some protocol,
> some algorithm.

It's a phased array, not a dish, even if it looks like one. It consists 
of 100's of fingernail-sized antenna elements that:

  * during transmissions, have an individual phase delay added to the
    signal transmitted from that element, in order to permit
    transmission of the combined signal from all elements into a
    particular direction.
  * during reception, have an individual phase delay added to the signal
    collected by that element, before the signals are added to obtain
    the combined received signal. This allows reception from a
    particular direction.

Dishy's main direction of transmission / reception is therefore not its 
surface normal - this simply points to the area of the sky where Dishy 
expects to see most satellites (a function of geographical latitude and 
constellation design - essentially straight up in the tropics, and 
elsewhere in the direction of the 53rd parallel, which corresponds to 
the predominant orbital inclination in the Starlink fleet). The actual 
tracking is then done with the phased array without mechanical movement 
by Dishy.

 From what I've seen, Dishy seems to consume more power on receive than 
on transmit - that's if you actually download stuff. This is somewhat 
counter-intuitive if you're used to putting link budgets together. But 
I'd attribute that to a higher degree of digital signal processing 
required on the receive and demodulation path.

-- 

****************************************************************
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: 2845 bytes --]

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

On Sat, 16 Sep 2023, Ulrich Speidel via Starlink wrote:

> On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>> 
>> I must say that I dont know whether the original 'DISHY' is simply a
>> dish antenna with an analog amplifier and maybe some mechanical motor
>> steering, or whether DISHY includes a computer to execute some protocol,
>> some algorithm.

In addition to that Ulrich says, the dishy is a full computer, it's output is 
ethernet/IP and with some adapters or cable changes, you can plug it directly 
into a router.

There are numberous teardown videos on youtube now, for both the original and 
the 1st of the rectangular dishys, they will show you how complex the system is.

David Lang

  >
> It's a phased array, not a dish, even if it looks like one. It consists of 
> 100's of fingernail-sized antenna elements that:
>
> * during transmissions, have an individual phase delay added to the
>   signal transmitted from that element, in order to permit
>   transmission of the combined signal from all elements into a
>   particular direction.
> * during reception, have an individual phase delay added to the signal
>   collected by that element, before the signals are added to obtain
>   the combined received signal. This allows reception from a
>   particular direction.
>
> Dishy's main direction of transmission / reception is therefore not its 
> surface normal - this simply points to the area of the sky where Dishy 
> expects to see most satellites (a function of geographical latitude and 
> constellation design - essentially straight up in the tropics, and elsewhere 
> in the direction of the 53rd parallel, which corresponds to the predominant 
> orbital inclination in the Starlink fleet). The actual tracking is then done 
> with the phased array without mechanical movement by Dishy.
>
> From what I've seen, Dishy seems to consume more power on receive than on 
> transmit - that's if you actually download stuff. This is somewhat 
> counter-intuitive if you're used to putting link budgets together. But I'd 
> attribute that to a higher degree of digital signal processing required on 
> the receive and demodulation path.
>
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Ulrich Speidel]

On 16/09/2023 5:52 am, David Lang wrote:
>
> In addition to that Ulrich says, the dishy is a full computer, it's 
> output is ethernet/IP and with some adapters or cable changes, you can 
> plug it directly into a router.

We've done that with the Yaosheng PoE Dishy adapter - actually plugged a 
DHCP client straight in - and it "works" but with a noticeably higher 
rate of disconnects.

-- 

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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
> On 16/09/2023 5:52 am, David Lang wrote:
>>
>> In addition to that Ulrich says, the dishy is a full computer, it's 
>> output is ethernet/IP and with some adapters or cable changes, you 
>> can plug it directly into a router.
>
> We've done that with the Yaosheng PoE Dishy adapter - actually plugged 
> a DHCP client straight in - and it "works" but with a noticeably 
> higher rate of disconnects.

It is good to know one can plug a DHCP client into the Ethernet of the 
DISHY and receive DHCP replies.

But that would be only a lead into what kind of DHCPv4 is supported, or not.

I would ask to know whether the DHCP server runs on the DISHY, or 
whether it is on the ground network of starlink, i.e. the reply to DHCP 
request comes after 50ms, or after 500microseconds (timestamp difference 
can be seen in the wireshark run on that Ethernet).

This (DHCP server daemon on dishy or on ground segment) has an impact of 
how IPv6  can be, or is, made to work.

This kind of behaviour of DHCP - basically asking who allocates an 
address - has seen a continous evolution in 3GPP cellular networks since 
they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP 
network; even in a typical smartphone there are intricacies about where 
and how the DHCP client and server works. With it comes the problem of 
/64 in cellular networks (which some dont call a problem, but I do).

So, it would be interesting to see whether starlink has the same /64 
problem as 3GPP has, or is free of it (simply put: can I connect several 
Ethernet subnets in my home to starlink, in native IPv6 that is, or not?).

Alex

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

it's very clear that there is a computer in the dishy that you are talking to. 
You get the network connection while the dishy is not connected to the 
satellites (there's even a status page and controls, stowing and unstowing for 
example)

I think we've seen that the dishy is running linux (I know the routers run an 
old openwrt), but I don't remember the details of the dishy software.

David Lang

  On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:

> Date: Sun, 17 Sep 2023 19:21:50 +0200
> From: Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Main hurdles against the Integration of Satellites and
>      Terrestial Networks
> 
>
> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>> On 16/09/2023 5:52 am, David Lang wrote:
>>>
>>> In addition to that Ulrich says, the dishy is a full computer, it's 
>>> output is ethernet/IP and with some adapters or cable changes, you 
>>> can plug it directly into a router.
>>
>> We've done that with the Yaosheng PoE Dishy adapter - actually plugged 
>> a DHCP client straight in - and it "works" but with a noticeably 
>> higher rate of disconnects.
>
> It is good to know one can plug a DHCP client into the Ethernet of the 
> DISHY and receive DHCP replies.
>
> But that would be only a lead into what kind of DHCPv4 is supported, or not.
>
> I would ask to know whether the DHCP server runs on the DISHY, or 
> whether it is on the ground network of starlink, i.e. the reply to DHCP 
> request comes after 50ms, or after 500microseconds (timestamp difference 
> can be seen in the wireshark run on that Ethernet).
>
> This (DHCP server daemon on dishy or on ground segment) has an impact of 
> how IPv6  can be, or is, made to work.
>
> This kind of behaviour of DHCP - basically asking who allocates an 
> address - has seen a continous evolution in 3GPP cellular networks since 
> they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP 
> network; even in a typical smartphone there are intricacies about where 
> and how the DHCP client and server works. With it comes the problem of 
> /64 in cellular networks (which some dont call a problem, but I do).
>
> So, it would be interesting to see whether starlink has the same /64 
> problem as 3GPP has, or is free of it (simply put: can I connect several 
> Ethernet subnets in my home to starlink, in native IPv6 that is, or not?).
>
> Alex
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Hesham ElBakoury]

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

Given the discussions in this email thread, what IETF should standardize in
priority order  for the integrated NTN terrestrial networks?

Thanks,
Hesham

On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> it's very clear that there is a computer in the dishy that you are talking
> to.
> You get the network connection while the dishy is not connected to the
> satellites (there's even a status page and controls, stowing and unstowing
> for
> example)
>
> I think we've seen that the dishy is running linux (I know the routers run
> an
> old openwrt), but I don't remember the details of the dishy software.
>
> David Lang
>
>   On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>
> > Date: Sun, 17 Sep 2023 19:21:50 +0200
> > From: Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net>
> > Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> > To: starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] Main hurdles against the Integration of
> Satellites and
> >      Terrestial Networks
> >
> >
> > Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
> >> On 16/09/2023 5:52 am, David Lang wrote:
> >>>
> >>> In addition to that Ulrich says, the dishy is a full computer, it's
> >>> output is ethernet/IP and with some adapters or cable changes, you
> >>> can plug it directly into a router.
> >>
> >> We've done that with the Yaosheng PoE Dishy adapter - actually plugged
> >> a DHCP client straight in - and it "works" but with a noticeably
> >> higher rate of disconnects.
> >
> > It is good to know one can plug a DHCP client into the Ethernet of the
> > DISHY and receive DHCP replies.
> >
> > But that would be only a lead into what kind of DHCPv4 is supported, or
> not.
> >
> > I would ask to know whether the DHCP server runs on the DISHY, or
> > whether it is on the ground network of starlink, i.e. the reply to DHCP
> > request comes after 50ms, or after 500microseconds (timestamp difference
> > can be seen in the wireshark run on that Ethernet).
> >
> > This (DHCP server daemon on dishy or on ground segment) has an impact of
> > how IPv6  can be, or is, made to work.
> >
> > This kind of behaviour of DHCP - basically asking who allocates an
> > address - has seen a continous evolution in 3GPP cellular networks since
> > they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP
> > network; even in a typical smartphone there are intricacies about where
> > and how the DHCP client and server works. With it comes the problem of
> > /64 in cellular networks (which some dont call a problem, but I do).
> >
> > So, it would be interesting to see whether starlink has the same /64
> > problem as 3GPP has, or is free of it (simply put: can I connect several
> > Ethernet subnets in my home to starlink, in native IPv6 that is, or
> not?).
> >
> > Alex
> >
> > _______________________________________________
> > 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
>

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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

On Mon, 18 Sep 2023, Hesham ElBakoury wrote:

> Given the discussions in this email thread, what IETF should standardize in
> priority order  for the integrated NTN terrestrial networks?

I don't see why you need to do any particular standardization to integrate 
things like starlink into terrestrial networks.

Just like IETF didn't need to standardize ethernet/token ring/arcnet/modems to 
make them compatible with each other. They all talk IP, and a computer with a 
link to each of them can serve as a gateway (and this included proprietary 
modems that were not compatible with anything else, the network didn't care)

Starlink is just another IP path, all the tools that you use with any other ISP 
work on that path (or are restricted like many other consumer ISPs with dynamic 
addressing, no inbound connections, no BGP peering, etc. No reason that the 
those couldn't work, SpaceX just opts not to support them on consumer dishes)

I'll turn the question back to you, what is the problem that you think is there 
that needs to be solved?

David Lang

> Thanks,
> Hesham
>
> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> it's very clear that there is a computer in the dishy that you are talking
>> to.
>> You get the network connection while the dishy is not connected to the
>> satellites (there's even a status page and controls, stowing and unstowing
>> for
>> example)
>>
>> I think we've seen that the dishy is running linux (I know the routers run
>> an
>> old openwrt), but I don't remember the details of the dishy software.
>>
>> David Lang
>>
>>   On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>
>>> Date: Sun, 17 Sep 2023 19:21:50 +0200
>>> From: Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net>
>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>> Satellites and
>>>      Terrestial Networks
>>>
>>>
>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>
>>>>> In addition to that Ulrich says, the dishy is a full computer, it's
>>>>> output is ethernet/IP and with some adapters or cable changes, you
>>>>> can plug it directly into a router.
>>>>
>>>> We've done that with the Yaosheng PoE Dishy adapter - actually plugged
>>>> a DHCP client straight in - and it "works" but with a noticeably
>>>> higher rate of disconnects.
>>>
>>> It is good to know one can plug a DHCP client into the Ethernet of the
>>> DISHY and receive DHCP replies.
>>>
>>> But that would be only a lead into what kind of DHCPv4 is supported, or
>> not.
>>>
>>> I would ask to know whether the DHCP server runs on the DISHY, or
>>> whether it is on the ground network of starlink, i.e. the reply to DHCP
>>> request comes after 50ms, or after 500microseconds (timestamp difference
>>> can be seen in the wireshark run on that Ethernet).
>>>
>>> This (DHCP server daemon on dishy or on ground segment) has an impact of
>>> how IPv6  can be, or is, made to work.
>>>
>>> This kind of behaviour of DHCP - basically asking who allocates an
>>> address - has seen a continous evolution in 3GPP cellular networks since
>>> they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP
>>> network; even in a typical smartphone there are intricacies about where
>>> and how the DHCP client and server works. With it comes the problem of
>>> /64 in cellular networks (which some dont call a problem, but I do).
>>>
>>> So, it would be interesting to see whether starlink has the same /64
>>> problem as 3GPP has, or is free of it (simply put: can I connect several
>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
>> not?).
>>>
>>> Alex
>>>
>>> _______________________________________________
>>> 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
>>
>

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Hesham ElBakoury]

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

My understanding is that for integrated NTN and Terrestrial network we may
need new or enhanced routing protocols. There are many publications in this
area.

I suggest that you discuss your view in int-sat email list (copied)

Thanks
Hesham

On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm> wrote:

> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>
> > Given the discussions in this email thread, what IETF should standardize
> in
> > priority order  for the integrated NTN terrestrial networks?
>
> I don't see why you need to do any particular standardization to integrate
> things like starlink into terrestrial networks.
>
> Just like IETF didn't need to standardize ethernet/token
> ring/arcnet/modems to
> make them compatible with each other. They all talk IP, and a computer
> with a
> link to each of them can serve as a gateway (and this included proprietary
> modems that were not compatible with anything else, the network didn't
> care)
>
> Starlink is just another IP path, all the tools that you use with any
> other ISP
> work on that path (or are restricted like many other consumer ISPs with
> dynamic
> addressing, no inbound connections, no BGP peering, etc. No reason that
> the
> those couldn't work, SpaceX just opts not to support them on consumer
> dishes)
>
> I'll turn the question back to you, what is the problem that you think is
> there
> that needs to be solved?
>
> David Lang
>
> > Thanks,
> > Hesham
> >
> > On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
> > starlink@lists.bufferbloat.net> wrote:
> >
> >> it's very clear that there is a computer in the dishy that you are
> talking
> >> to.
> >> You get the network connection while the dishy is not connected to the
> >> satellites (there's even a status page and controls, stowing and
> unstowing
> >> for
> >> example)
> >>
> >> I think we've seen that the dishy is running linux (I know the routers
> run
> >> an
> >> old openwrt), but I don't remember the details of the dishy software.
> >>
> >> David Lang
> >>
> >>   On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
> >>
> >>> Date: Sun, 17 Sep 2023 19:21:50 +0200
> >>> From: Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net>
> >>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> >>> To: starlink@lists.bufferbloat.net
> >>> Subject: Re: [Starlink] Main hurdles against the Integration of
> >> Satellites and
> >>>      Terrestial Networks
> >>>
> >>>
> >>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
> >>>> On 16/09/2023 5:52 am, David Lang wrote:
> >>>>>
> >>>>> In addition to that Ulrich says, the dishy is a full computer, it's
> >>>>> output is ethernet/IP and with some adapters or cable changes, you
> >>>>> can plug it directly into a router.
> >>>>
> >>>> We've done that with the Yaosheng PoE Dishy adapter - actually plugged
> >>>> a DHCP client straight in - and it "works" but with a noticeably
> >>>> higher rate of disconnects.
> >>>
> >>> It is good to know one can plug a DHCP client into the Ethernet of the
> >>> DISHY and receive DHCP replies.
> >>>
> >>> But that would be only a lead into what kind of DHCPv4 is supported, or
> >> not.
> >>>
> >>> I would ask to know whether the DHCP server runs on the DISHY, or
> >>> whether it is on the ground network of starlink, i.e. the reply to DHCP
> >>> request comes after 50ms, or after 500microseconds (timestamp
> difference
> >>> can be seen in the wireshark run on that Ethernet).
> >>>
> >>> This (DHCP server daemon on dishy or on ground segment) has an impact
> of
> >>> how IPv6  can be, or is, made to work.
> >>>
> >>> This kind of behaviour of DHCP - basically asking who allocates an
> >>> address - has seen a continous evolution in 3GPP cellular networks
> since
> >>> they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP
> >>> network; even in a typical smartphone there are intricacies about where
> >>> and how the DHCP client and server works. With it comes the problem of
> >>> /64 in cellular networks (which some dont call a problem, but I do).
> >>>
> >>> So, it would be interesting to see whether starlink has the same /64
> >>> problem as 3GPP has, or is free of it (simply put: can I connect
> several
> >>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
> >> not?).
> >>>
> >>> Alex
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >

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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

On Mon, 18 Sep 2023, Hesham ElBakoury wrote:

> My understanding is that for integrated NTN and Terrestrial network we may
> need new or enhanced routing protocols. There are many publications in this
> area.

I don't see how starlink hops have to be treated any differently than 
terrestrial tunnels (think frame relay networks that overlay a virtual network 
on top of the physical network, encrypted or not). There probably are new 
routing protocols that will handle these better than current ones, but I see 
that a matter of such links being more common, rather than being fundementally 
different.

I do see that in the future, if/as information about the in-space routing 
becomes more open (and I strongly suspect, stabilizes more) that there will be 
more that can be done, and at some point it may even make sense to allow for 
'peering' between satellites from different providers (which would require 
standardization of the in-space signals and protocols)

I may be missing something at this point (I don't claim to be a networking 
expert, but I'm seeing buzzwords here, but not an explination of why normal IP 
routing isn't sufficient.

David Lang

> I suggest that you discuss your view in int-sat email list (copied)
>
> Thanks
> Hesham
>
> On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm> wrote:
>
>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>>
>>> Given the discussions in this email thread, what IETF should standardize
>> in
>>> priority order  for the integrated NTN terrestrial networks?
>>
>> I don't see why you need to do any particular standardization to integrate
>> things like starlink into terrestrial networks.
>>
>> Just like IETF didn't need to standardize ethernet/token
>> ring/arcnet/modems to
>> make them compatible with each other. They all talk IP, and a computer
>> with a
>> link to each of them can serve as a gateway (and this included proprietary
>> modems that were not compatible with anything else, the network didn't
>> care)
>>
>> Starlink is just another IP path, all the tools that you use with any
>> other ISP
>> work on that path (or are restricted like many other consumer ISPs with
>> dynamic
>> addressing, no inbound connections, no BGP peering, etc. No reason that
>> the
>> those couldn't work, SpaceX just opts not to support them on consumer
>> dishes)
>>
>> I'll turn the question back to you, what is the problem that you think is
>> there
>> that needs to be solved?
>>
>> David Lang
>>
>>> Thanks,
>>> Hesham
>>>
>>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>> it's very clear that there is a computer in the dishy that you are
>> talking
>>>> to.
>>>> You get the network connection while the dishy is not connected to the
>>>> satellites (there's even a status page and controls, stowing and
>> unstowing
>>>> for
>>>> example)
>>>>
>>>> I think we've seen that the dishy is running linux (I know the routers
>> run
>>>> an
>>>> old openwrt), but I don't remember the details of the dishy software.
>>>>
>>>> David Lang
>>>>
>>>>   On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>>>
>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200
>>>>> From: Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net>
>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>> To: starlink@lists.bufferbloat.net
>>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>>>> Satellites and
>>>>>      Terrestial Networks
>>>>>
>>>>>
>>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>>>
>>>>>>> In addition to that Ulrich says, the dishy is a full computer, it's
>>>>>>> output is ethernet/IP and with some adapters or cable changes, you
>>>>>>> can plug it directly into a router.
>>>>>>
>>>>>> We've done that with the Yaosheng PoE Dishy adapter - actually plugged
>>>>>> a DHCP client straight in - and it "works" but with a noticeably
>>>>>> higher rate of disconnects.
>>>>>
>>>>> It is good to know one can plug a DHCP client into the Ethernet of the
>>>>> DISHY and receive DHCP replies.
>>>>>
>>>>> But that would be only a lead into what kind of DHCPv4 is supported, or
>>>> not.
>>>>>
>>>>> I would ask to know whether the DHCP server runs on the DISHY, or
>>>>> whether it is on the ground network of starlink, i.e. the reply to DHCP
>>>>> request comes after 50ms, or after 500microseconds (timestamp
>> difference
>>>>> can be seen in the wireshark run on that Ethernet).
>>>>>
>>>>> This (DHCP server daemon on dishy or on ground segment) has an impact
>> of
>>>>> how IPv6  can be, or is, made to work.
>>>>>
>>>>> This kind of behaviour of DHCP - basically asking who allocates an
>>>>> address - has seen a continous evolution in 3GPP cellular networks
>> since
>>>>> they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP
>>>>> network; even in a typical smartphone there are intricacies about where
>>>>> and how the DHCP client and server works. With it comes the problem of
>>>>> /64 in cellular networks (which some dont call a problem, but I do).
>>>>>
>>>>> So, it would be interesting to see whether starlink has the same /64
>>>>> problem as 3GPP has, or is free of it (simply put: can I connect
>> several
>>>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
>>>> not?).
>>>>>
>>>>> Alex
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>

Re: [Starlink] [Sat-int] Main hurdles against the Integration of Satellites and Terrestial Networks

[Jorge Amodio]

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

I believe that a better definition and characterization of "NTN" would be
appropriate.

NTN can represent a yuuuuuuuuge space... networking to Proxima Centauri
could be considered NTN, but I bet you will have a completely different set
of challenges than LEO, MEO, GEO, etc.

My .02
Jorge


On Mon, Sep 18, 2023 at 8:01 PM David Lang <david@lang.hm> wrote:

> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>
> > My understanding is that for integrated NTN and Terrestrial network we
> may
> > need new or enhanced routing protocols. There are many publications in
> this
> > area.
>
> I don't see how starlink hops have to be treated any differently than
> terrestrial tunnels (think frame relay networks that overlay a virtual
> network
> on top of the physical network, encrypted or not). There probably are new
> routing protocols that will handle these better than current ones, but I
> see
> that a matter of such links being more common, rather than being
> fundementally
> different.
>
> I do see that in the future, if/as information about the in-space routing
> becomes more open (and I strongly suspect, stabilizes more) that there
> will be
> more that can be done, and at some point it may even make sense to allow
> for
> 'peering' between satellites from different providers (which would require
> standardization of the in-space signals and protocols)
>
> I may be missing something at this point (I don't claim to be a networking
> expert, but I'm seeing buzzwords here, but not an explination of why
> normal IP
> routing isn't sufficient.
>
> David Lang
>
> > I suggest that you discuss your view in int-sat email list (copied)
> >
> > Thanks
> > Hesham
> >
> > On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm> wrote:
> >
> >> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
> >>
> >>> Given the discussions in this email thread, what IETF should
> standardize
> >> in
> >>> priority order  for the integrated NTN terrestrial networks?
> >>
> >> I don't see why you need to do any particular standardization to
> integrate
> >> things like starlink into terrestrial networks.
> >>
> >> Just like IETF didn't need to standardize ethernet/token
> >> ring/arcnet/modems to
> >> make them compatible with each other. They all talk IP, and a computer
> >> with a
> >> link to each of them can serve as a gateway (and this included
> proprietary
> >> modems that were not compatible with anything else, the network didn't
> >> care)
> >>
> >> Starlink is just another IP path, all the tools that you use with any
> >> other ISP
> >> work on that path (or are restricted like many other consumer ISPs with
> >> dynamic
> >> addressing, no inbound connections, no BGP peering, etc. No reason that
> >> the
> >> those couldn't work, SpaceX just opts not to support them on consumer
> >> dishes)
> >>
> >> I'll turn the question back to you, what is the problem that you think
> is
> >> there
> >> that needs to be solved?
> >>
> >> David Lang
> >>
> >>> Thanks,
> >>> Hesham
> >>>
> >>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
> >>> starlink@lists.bufferbloat.net> wrote:
> >>>
> >>>> it's very clear that there is a computer in the dishy that you are
> >> talking
> >>>> to.
> >>>> You get the network connection while the dishy is not connected to the
> >>>> satellites (there's even a status page and controls, stowing and
> >> unstowing
> >>>> for
> >>>> example)
> >>>>
> >>>> I think we've seen that the dishy is running linux (I know the routers
> >> run
> >>>> an
> >>>> old openwrt), but I don't remember the details of the dishy software.
> >>>>
> >>>> David Lang
> >>>>
> >>>>   On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
> >>>>
> >>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200
> >>>>> From: Alexandre Petrescu via Starlink <
> starlink@lists.bufferbloat.net>
> >>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> >>>>> To: starlink@lists.bufferbloat.net
> >>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
> >>>> Satellites and
> >>>>>      Terrestial Networks
> >>>>>
> >>>>>
> >>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
> >>>>>> On 16/09/2023 5:52 am, David Lang wrote:
> >>>>>>>
> >>>>>>> In addition to that Ulrich says, the dishy is a full computer, it's
> >>>>>>> output is ethernet/IP and with some adapters or cable changes, you
> >>>>>>> can plug it directly into a router.
> >>>>>>
> >>>>>> We've done that with the Yaosheng PoE Dishy adapter - actually
> plugged
> >>>>>> a DHCP client straight in - and it "works" but with a noticeably
> >>>>>> higher rate of disconnects.
> >>>>>
> >>>>> It is good to know one can plug a DHCP client into the Ethernet of
> the
> >>>>> DISHY and receive DHCP replies.
> >>>>>
> >>>>> But that would be only a lead into what kind of DHCPv4 is supported,
> or
> >>>> not.
> >>>>>
> >>>>> I would ask to know whether the DHCP server runs on the DISHY, or
> >>>>> whether it is on the ground network of starlink, i.e. the reply to
> DHCP
> >>>>> request comes after 50ms, or after 500microseconds (timestamp
> >> difference
> >>>>> can be seen in the wireshark run on that Ethernet).
> >>>>>
> >>>>> This (DHCP server daemon on dishy or on ground segment) has an impact
> >> of
> >>>>> how IPv6  can be, or is, made to work.
> >>>>>
> >>>>> This kind of behaviour of DHCP - basically asking who allocates an
> >>>>> address - has seen a continous evolution in 3GPP cellular networks
> >> since
> >>>>> they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP
> >>>>> network; even in a typical smartphone there are intricacies about
> where
> >>>>> and how the DHCP client and server works. With it comes the problem
> of
> >>>>> /64 in cellular networks (which some dont call a problem, but I do).
> >>>>>
> >>>>> So, it would be interesting to see whether starlink has the same /64
> >>>>> problem as 3GPP has, or is free of it (simply put: can I connect
> >> several
> >>>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
> >>>> not?).
> >>>>>
> >>>>> Alex
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>
> >--
> Sat-int mailing list
> Sat-int@ietf.org
> https://www.ietf.org/mailman/listinfo/sat-int
>

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

Re: [Starlink] [Sat-int] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

Very much so. If we are talking about integrating Starlink (and similar furture 
networks) with ground based networks, that's not hard (and is the scenario I was 
referring to)

but when we start talking about mars (and possibly even the moon) the existing 
networking protocols are going to time out. I expect that for a long time it's 
going to be some sort of batch protocol, possibly pulling UUCP back out and 
using it (with some forward error correction at the link layer) rather than the 
interactive protocols that we see in use today.

David Lang

On Mon, 18 Sep 2023, Jorge Amodio wrote:

> I believe that a better definition and characterization of "NTN" would be
> appropriate.
>
> NTN can represent a yuuuuuuuuge space... networking to Proxima Centauri
> could be considered NTN, but I bet you will have a completely different set
> of challenges than LEO, MEO, GEO, etc.
>
> My .02
> Jorge
>
>
> On Mon, Sep 18, 2023 at 8:01 PM David Lang <david@lang.hm> wrote:
>
>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>>
>>> My understanding is that for integrated NTN and Terrestrial network we
>> may
>>> need new or enhanced routing protocols. There are many publications in
>> this
>>> area.
>>
>> I don't see how starlink hops have to be treated any differently than
>> terrestrial tunnels (think frame relay networks that overlay a virtual
>> network
>> on top of the physical network, encrypted or not). There probably are new
>> routing protocols that will handle these better than current ones, but I
>> see
>> that a matter of such links being more common, rather than being
>> fundementally
>> different.
>>
>> I do see that in the future, if/as information about the in-space routing
>> becomes more open (and I strongly suspect, stabilizes more) that there
>> will be
>> more that can be done, and at some point it may even make sense to allow
>> for
>> 'peering' between satellites from different providers (which would require
>> standardization of the in-space signals and protocols)
>>
>> I may be missing something at this point (I don't claim to be a networking
>> expert, but I'm seeing buzzwords here, but not an explination of why
>> normal IP
>> routing isn't sufficient.
>>
>> David Lang
>>
>>> I suggest that you discuss your view in int-sat email list (copied)
>>>
>>> Thanks
>>> Hesham
>>>
>>> On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm> wrote:
>>>
>>>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>>>>
>>>>> Given the discussions in this email thread, what IETF should
>> standardize
>>>> in
>>>>> priority order  for the integrated NTN terrestrial networks?
>>>>
>>>> I don't see why you need to do any particular standardization to
>> integrate
>>>> things like starlink into terrestrial networks.
>>>>
>>>> Just like IETF didn't need to standardize ethernet/token
>>>> ring/arcnet/modems to
>>>> make them compatible with each other. They all talk IP, and a computer
>>>> with a
>>>> link to each of them can serve as a gateway (and this included
>> proprietary
>>>> modems that were not compatible with anything else, the network didn't
>>>> care)
>>>>
>>>> Starlink is just another IP path, all the tools that you use with any
>>>> other ISP
>>>> work on that path (or are restricted like many other consumer ISPs with
>>>> dynamic
>>>> addressing, no inbound connections, no BGP peering, etc. No reason that
>>>> the
>>>> those couldn't work, SpaceX just opts not to support them on consumer
>>>> dishes)
>>>>
>>>> I'll turn the question back to you, what is the problem that you think
>> is
>>>> there
>>>> that needs to be solved?
>>>>
>>>> David Lang
>>>>
>>>>> Thanks,
>>>>> Hesham
>>>>>
>>>>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
>>>>> starlink@lists.bufferbloat.net> wrote:
>>>>>
>>>>>> it's very clear that there is a computer in the dishy that you are
>>>> talking
>>>>>> to.
>>>>>> You get the network connection while the dishy is not connected to the
>>>>>> satellites (there's even a status page and controls, stowing and
>>>> unstowing
>>>>>> for
>>>>>> example)
>>>>>>
>>>>>> I think we've seen that the dishy is running linux (I know the routers
>>>> run
>>>>>> an
>>>>>> old openwrt), but I don't remember the details of the dishy software.
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>>>   On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>>>>>
>>>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200
>>>>>>> From: Alexandre Petrescu via Starlink <
>> starlink@lists.bufferbloat.net>
>>>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>>>> To: starlink@lists.bufferbloat.net
>>>>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>>>>>> Satellites and
>>>>>>>      Terrestial Networks
>>>>>>>
>>>>>>>
>>>>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>>>>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>>>>>
>>>>>>>>> In addition to that Ulrich says, the dishy is a full computer, it's
>>>>>>>>> output is ethernet/IP and with some adapters or cable changes, you
>>>>>>>>> can plug it directly into a router.
>>>>>>>>
>>>>>>>> We've done that with the Yaosheng PoE Dishy adapter - actually
>> plugged
>>>>>>>> a DHCP client straight in - and it "works" but with a noticeably
>>>>>>>> higher rate of disconnects.
>>>>>>>
>>>>>>> It is good to know one can plug a DHCP client into the Ethernet of
>> the
>>>>>>> DISHY and receive DHCP replies.
>>>>>>>
>>>>>>> But that would be only a lead into what kind of DHCPv4 is supported,
>> or
>>>>>> not.
>>>>>>>
>>>>>>> I would ask to know whether the DHCP server runs on the DISHY, or
>>>>>>> whether it is on the ground network of starlink, i.e. the reply to
>> DHCP
>>>>>>> request comes after 50ms, or after 500microseconds (timestamp
>>>> difference
>>>>>>> can be seen in the wireshark run on that Ethernet).
>>>>>>>
>>>>>>> This (DHCP server daemon on dishy or on ground segment) has an impact
>>>> of
>>>>>>> how IPv6  can be, or is, made to work.
>>>>>>>
>>>>>>> This kind of behaviour of DHCP - basically asking who allocates an
>>>>>>> address - has seen a continous evolution in 3GPP cellular networks
>>>> since
>>>>>>> they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP
>>>>>>> network; even in a typical smartphone there are intricacies about
>> where
>>>>>>> and how the DHCP client and server works. With it comes the problem
>> of
>>>>>>> /64 in cellular networks (which some dont call a problem, but I do).
>>>>>>>
>>>>>>> So, it would be interesting to see whether starlink has the same /64
>>>>>>> problem as 3GPP has, or is free of it (simply put: can I connect
>>>> several
>>>>>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
>>>>>> not?).
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>
>>> --
>> Sat-int mailing list
>> Sat-int@ietf.org
>> https://www.ietf.org/mailman/listinfo/sat-int
>>
>

Re: [Starlink] [Sat-int] Main hurdles against the Integration of Satellites and Terrestial Networks

[emile.stephan]

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

+1, in fine these ones are a bit more terrestrial

De : Sat-int <sat-int-bounces@ietf.org> De la part de Jorge Amodio
Envoyé : mardi 19 septembre 2023 03:08
À : David Lang <david@lang.hm>
Cc : Hesham ElBakoury <helbakoury@gmail.com>; Alexandre Petrescu <alexandre.petrescu@gmail.com>; Dave Taht via Starlink <starlink@lists.bufferbloat.net>; sat-int@ietf.org
Objet : Re: [Sat-int] [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks


I believe that a better definition and characterization of "NTN" would be appropriate.

NTN can represent a yuuuuuuuuge space... networking to Proxima Centauri could be considered NTN, but I bet you will have a completely different set of challenges than LEO, MEO, GEO, etc.

My .02
Jorge


On Mon, Sep 18, 2023 at 8:01 PM David Lang <david@lang.hm<mailto:david@lang.hm>> wrote:
On Mon, 18 Sep 2023, Hesham ElBakoury wrote:

> My understanding is that for integrated NTN and Terrestrial network we may
> need new or enhanced routing protocols. There are many publications in this
> area.

I don't see how starlink hops have to be treated any differently than
terrestrial tunnels (think frame relay networks that overlay a virtual network
on top of the physical network, encrypted or not). There probably are new
routing protocols that will handle these better than current ones, but I see
that a matter of such links being more common, rather than being fundementally
different.

I do see that in the future, if/as information about the in-space routing
becomes more open (and I strongly suspect, stabilizes more) that there will be
more that can be done, and at some point it may even make sense to allow for
'peering' between satellites from different providers (which would require
standardization of the in-space signals and protocols)

I may be missing something at this point (I don't claim to be a networking
expert, but I'm seeing buzzwords here, but not an explination of why normal IP
routing isn't sufficient.

David Lang

> I suggest that you discuss your view in int-sat email list (copied)
>
> Thanks
> Hesham
>
> On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm<mailto:david@lang.hm>> wrote:
>
>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>>
>>> Given the discussions in this email thread, what IETF should standardize
>> in
>>> priority order  for the integrated NTN terrestrial networks?
>>
>> I don't see why you need to do any particular standardization to integrate
>> things like starlink into terrestrial networks.
>>
>> Just like IETF didn't need to standardize ethernet/token
>> ring/arcnet/modems to
>> make them compatible with each other. They all talk IP, and a computer
>> with a
>> link to each of them can serve as a gateway (and this included proprietary
>> modems that were not compatible with anything else, the network didn't
>> care)
>>
>> Starlink is just another IP path, all the tools that you use with any
>> other ISP
>> work on that path (or are restricted like many other consumer ISPs with
>> dynamic
>> addressing, no inbound connections, no BGP peering, etc. No reason that
>> the
>> those couldn't work, SpaceX just opts not to support them on consumer
>> dishes)
>>
>> I'll turn the question back to you, what is the problem that you think is
>> there
>> that needs to be solved?
>>
>> David Lang
>>
>>> Thanks,
>>> Hesham
>>>
>>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink <
>>> starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>> wrote:
>>>
>>>> it's very clear that there is a computer in the dishy that you are
>> talking
>>>> to.
>>>> You get the network connection while the dishy is not connected to the
>>>> satellites (there's even a status page and controls, stowing and
>> unstowing
>>>> for
>>>> example)
>>>>
>>>> I think we've seen that the dishy is running linux (I know the routers
>> run
>>>> an
>>>> old openwrt), but I don't remember the details of the dishy software.
>>>>
>>>> David Lang
>>>>
>>>>   On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>>>
>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200
>>>>> From: Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>
>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>
>>>>> To: starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>
>>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>>>> Satellites and
>>>>>      Terrestial Networks
>>>>>
>>>>>
>>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>>>
>>>>>>> In addition to that Ulrich says, the dishy is a full computer, it's
>>>>>>> output is ethernet/IP and with some adapters or cable changes, you
>>>>>>> can plug it directly into a router.
>>>>>>
>>>>>> We've done that with the Yaosheng PoE Dishy adapter - actually plugged
>>>>>> a DHCP client straight in - and it "works" but with a noticeably
>>>>>> higher rate of disconnects.
>>>>>
>>>>> It is good to know one can plug a DHCP client into the Ethernet of the
>>>>> DISHY and receive DHCP replies.
>>>>>
>>>>> But that would be only a lead into what kind of DHCPv4 is supported, or
>>>> not.
>>>>>
>>>>> I would ask to know whether the DHCP server runs on the DISHY, or
>>>>> whether it is on the ground network of starlink, i.e. the reply to DHCP
>>>>> request comes after 50ms, or after 500microseconds (timestamp
>> difference
>>>>> can be seen in the wireshark run on that Ethernet).
>>>>>
>>>>> This (DHCP server daemon on dishy or on ground segment) has an impact
>> of
>>>>> how IPv6  can be, or is, made to work.
>>>>>
>>>>> This kind of behaviour of DHCP - basically asking who allocates an
>>>>> address - has seen a continous evolution in 3GPP cellular networks
>> since
>>>>> they appeared.  Nowadays the DHCP behaviour is very complex in a 3GPP
>>>>> network; even in a typical smartphone there are intricacies about where
>>>>> and how the DHCP client and server works. With it comes the problem of
>>>>> /64 in cellular networks (which some dont call a problem, but I do).
>>>>>
>>>>> So, it would be interesting to see whether starlink has the same /64
>>>>> problem as 3GPP has, or is free of it (simply put: can I connect
>> several
>>>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
>>>> not?).
>>>>>
>>>>> Alex
>>>>>
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>
>--
Sat-int mailing list
Sat-int@ietf.org<mailto:Sat-int@ietf.org>
https://www.ietf.org/mailman/listinfo/sat-int


Orange Restricted
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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

Re: [Starlink] [Sat-int] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 19/09/2023 à 03:08, Jorge Amodio a écrit :
> 
> I believe that a better definition and characterization of "NTN"
> would be appropriate.

True.

> NTN can represent a yuuuuuuuuge space... networking to Proxima
> Centauri could be considered NTN, but I bet you will have a
> completely different set of challenges than LEO, MEO, GEO, etc.

I'd look at where and how 'NTN' term originated.  I believe it was at
ITU several years ago that it was coined, even though I might be wrong.
But in recent years it is used extensively at 3GPP.

The way in which 3GPP uses this term 'NTN' makes think very much of a
HAP (high-alti platform), or maybe one or two satellites,  maybe at MEO
or GEO orbits, but LEO is also in the picture.  The examples that could
approach that 'NTN', without being 'NTN', are the recent smartphones
huawei mate60 pro on a GEO sat in a set of 3, but the iphone 14 and 15
is via LEO sats globalstar; none of the two are 'NTN'-labelled even
though they are certainly 3GPP devices.

Proxima Centauri: before that, I suppose they'll put 3GPP bases stations
and user equipment on the Moon and on Mars, if not on a comet.  For the
moment it's not called 'NTN' but NTN does make sense indeed, because 
it's non-terrestrial.

Alex

> 
> My .02 Jorge
> 
> 
> On Mon, Sep 18, 2023 at 8:01 PM David Lang <david@lang.hm 
> <mailto:david@lang.hm>> wrote:
> 
> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
> 
>> My understanding is that for integrated NTN and Terrestrial
> network we may
>> need new or enhanced routing protocols. There are many
> publications in this
>> area.
> 
> I don't see how starlink hops have to be treated any differently
> than terrestrial tunnels (think frame relay networks that overlay a 
> virtual network on top of the physical network, encrypted or not).
> There probably are new routing protocols that will handle these
> better than current ones, but I see that a matter of such links being
> more common, rather than being fundementally different.
> 
> I do see that in the future, if/as information about the in-space 
> routing becomes more open (and I strongly suspect, stabilizes more)
> that there will be more that can be done, and at some point it may
> even make sense to allow for 'peering' between satellites from
> different providers (which would require standardization of the
> in-space signals and protocols)
> 
> I may be missing something at this point (I don't claim to be a 
> networking expert, but I'm seeing buzzwords here, but not an
> explination of why normal IP routing isn't sufficient.
> 
> David Lang
> 
>> I suggest that you discuss your view in int-sat email list
>> (copied)
>> 
>> Thanks Hesham
>> 
>> On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm
> <mailto:david@lang.hm>> wrote:
>> 
>>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>>> 
>>>> Given the discussions in this email thread, what IETF should
> standardize
>>> in
>>>> priority order  for the integrated NTN terrestrial networks?
>>> 
>>> I don't see why you need to do any particular standardization to
> integrate
>>> things like starlink into terrestrial networks.
>>> 
>>> Just like IETF didn't need to standardize ethernet/token 
>>> ring/arcnet/modems to make them compatible with each other. They
>>> all talk IP, and a
> computer
>>> with a link to each of them can serve as a gateway (and this
>>> included
> proprietary
>>> modems that were not compatible with anything else, the network
> didn't
>>> care)
>>> 
>>> Starlink is just another IP path, all the tools that you use
> with any
>>> other ISP work on that path (or are restricted like many other
>>> consumer
> ISPs with
>>> dynamic addressing, no inbound connections, no BGP peering, etc.
>>> No
> reason that
>>> the those couldn't work, SpaceX just opts not to support them on
> consumer
>>> dishes)
>>> 
>>> I'll turn the question back to you, what is the problem that you
> think is
>>> there that needs to be solved?
>>> 
>>> David Lang
>>> 
>>>> Thanks, Hesham
>>>> 
>>>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink < 
>>>> starlink@lists.bufferbloat.net
> <mailto:starlink@lists.bufferbloat.net>> wrote:
>>>> 
>>>>> it's very clear that there is a computer in the dishy that
>>>>> you are
>>> talking
>>>>> to. You get the network connection while the dishy is not
> connected to the
>>>>> satellites (there's even a status page and controls, stowing
>>>>> and
>>> unstowing
>>>>> for example)
>>>>> 
>>>>> I think we've seen that the dishy is running linux (I know
>>>>> the
> routers
>>> run
>>>>> an old openwrt), but I don't remember the details of the
>>>>> dishy
> software.
>>>>> 
>>>>> David Lang
>>>>> 
>>>>> On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>>>> 
>>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200 From: Alexandre
>>>>>> Petrescu via Starlink
> <starlink@lists.bufferbloat.net
> <mailto:starlink@lists.bufferbloat.net>>
>>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>
>>>>>> To: starlink@lists.bufferbloat.net
> <mailto:starlink@lists.bufferbloat.net>
>>>>>> Subject: Re: [Starlink] Main hurdles against the
>>>>>> Integration of
>>>>> Satellites and
>>>>>> Terrestial Networks
>>>>>> 
>>>>>> 
>>>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit
>>>>>> :
>>>>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>>>> 
>>>>>>>> In addition to that Ulrich says, the dishy is a full
> computer, it's
>>>>>>>> output is ethernet/IP and with some adapters or cable
> changes, you
>>>>>>>> can plug it directly into a router.
>>>>>>> 
>>>>>>> We've done that with the Yaosheng PoE Dishy adapter -
> actually plugged
>>>>>>> a DHCP client straight in - and it "works" but with a
>>>>>>> noticeably higher rate of disconnects.
>>>>>> 
>>>>>> It is good to know one can plug a DHCP client into the
> Ethernet of the
>>>>>> DISHY and receive DHCP replies.
>>>>>> 
>>>>>> But that would be only a lead into what kind of DHCPv4 is
> supported, or
>>>>> not.
>>>>>> 
>>>>>> I would ask to know whether the DHCP server runs on the
>>>>>> DISHY, or whether it is on the ground network of starlink,
>>>>>> i.e. the
> reply to DHCP
>>>>>> request comes after 50ms, or after 500microseconds
>>>>>> (timestamp
>>> difference
>>>>>> can be seen in the wireshark run on that Ethernet).
>>>>>> 
>>>>>> This (DHCP server daemon on dishy or on ground segment)
>>>>>> has
> an impact
>>> of
>>>>>> how IPv6  can be, or is, made to work.
>>>>>> 
>>>>>> This kind of behaviour of DHCP - basically asking who
> allocates an
>>>>>> address - has seen a continous evolution in 3GPP cellular
> networks
>>> since
>>>>>> they appeared.  Nowadays the DHCP behaviour is very
>>>>>> complex
> in a 3GPP
>>>>>> network; even in a typical smartphone there are
>>>>>> intricacies
> about where
>>>>>> and how the DHCP client and server works. With it comes
>>>>>> the
> problem of
>>>>>> /64 in cellular networks (which some dont call a problem,
>>>>>> but
> I do).
>>>>>> 
>>>>>> So, it would be interesting to see whether starlink has
>>>>>> the
> same /64
>>>>>> problem as 3GPP has, or is free of it (simply put: can I
>>>>>> connect
>>> several
>>>>>> Ethernet subnets in my home to starlink, in native IPv6
>>>>>> that
> is, or
>>>>> not?).
>>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>> _______________________________________________ Starlink
>>>>>> mailing list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net>
>>>>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>>>>> _______________________________________________
>>>>> Starlink mailing list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net>
>>>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>>>> 
>>>> 
>> --
> Sat-int mailing list Sat-int@ietf.org <mailto:Sat-int@ietf.org> 
> https://www.ietf.org/mailman/listinfo/sat-int 
> <https://www.ietf.org/mailman/listinfo/sat-int>
> 

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 19/09/2023 à 02:36, Hesham ElBakoury a écrit :
[...]

> On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm
[...]

> Starlink is just another IP path,

Yes.

For IPv6 it might not be that simple.  There can be things suggested to
starlink to implement, such as to make it better from an IPv6
standpoint.  That includes, and is not limited to, this /64 aspect.

For IP in general (be it IPv4 or IPv6), as long as starlink stays
closed, there might be no interest to suggest anything about IP that
they have not already thought of.

IF on the other hand, starlink feels a need to interoperate, then we can
discuss.

It is possible that starlink does not feel any need to interoperate now.
  At that point, the need to interoperate might come as a mandate from
some outside factors.  Such factors could be the public-private
cooperations.  Other factors could be partnerships that appear when some
organisations feel the need to cooperate.  I will not speculate when,
but it happens.

Assuming that such openness appears, with a need to interoperate, then
there certainly will be perspective developped where Starlink is not
just another IP path.

> all the tools that you use with any other ISP work on that path (or
> are restricted like many other consumer ISPs with dynamic addressing,
> no inbound connections, no BGP peering, etc. No reason that the those
> couldn't work, SpaceX just opts not to support them on consumer
> dishes)

But, these other ISPs (not Starlink) are all standardized.

> I'll turn the question back to you, what is the problem that you 
> think is there that needs to be solved?

Here is one, but there are potentially more.  I would not close the door 
to searching them.

I dont have DISHY, so no first hand experience.

But I suspect the IPv6 it supports it is an IPv6 encapsulated in IPv4. 
That adds to latency, not to say bufferbloat.  It brings in a single 
point of failure too (if it fails, then all fails).

Then, when they'll want to remove that they'd hit into the /64 issue.

Alex
> 
> David Lang
> 
>> Thanks, Hesham
>> 
>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink < 
>> starlink@lists.bufferbloat.net
> <mailto:starlink@lists.bufferbloat.net>> wrote:
>> 
>>> it's very clear that there is a computer in the dishy that you
> are talking
>>> to. You get the network connection while the dishy is not 
>>> connected
> to the
>>> satellites (there's even a status page and controls, stowing and
> unstowing
>>> for example)
>>> 
>>> I think we've seen that the dishy is running linux (I know the
> routers run
>>> an old openwrt), but I don't remember the details of the dishy
> software.
>>> 
>>> David Lang
>>> 
>>> On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>> 
>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200 From: Alexandre Petrescu 
>>>> via Starlink
> <starlink@lists.bufferbloat.net 
> <mailto:starlink@lists.bufferbloat.net>>
>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>
>>>> To: starlink@lists.bufferbloat.net
> <mailto:starlink@lists.bufferbloat.net>
>>>> Subject: Re: [Starlink] Main hurdles against the Integration 
>>>> of
>>> Satellites and
>>>> Terrestial Networks
>>>> 
>>>> 
>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>> 
>>>>>> In addition to that Ulrich says, the dishy is a full
> computer, it's
>>>>>> output is ethernet/IP and with some adapters or cable
> changes, you
>>>>>> can plug it directly into a router.
>>>>> 
>>>>> We've done that with the Yaosheng PoE Dishy adapter - 
>>>>> actually
> plugged
>>>>> a DHCP client straight in - and it "works" but with a 
>>>>> noticeably higher rate of disconnects.
>>>> 
>>>> It is good to know one can plug a DHCP client into the 
>>>> Ethernet
> of the
>>>> DISHY and receive DHCP replies.
>>>> 
>>>> But that would be only a lead into what kind of DHCPv4 is
> supported, or
>>> not.
>>>> 
>>>> I would ask to know whether the DHCP server runs on the DISHY, 
>>>> or whether it is on the ground network of starlink, i.e. the 
>>>> reply
> to DHCP
>>>> request comes after 50ms, or after 500microseconds (timestamp
> difference
>>>> can be seen in the wireshark run on that Ethernet).
>>>> 
>>>> This (DHCP server daemon on dishy or on ground segment) has an
> impact of
>>>> how IPv6  can be, or is, made to work.
>>>> 
>>>> This kind of behaviour of DHCP - basically asking who
>>>> allocates an address - has seen a continous evolution in 3GPP
>>>> cellular
> networks since
>>>> they appeared.  Nowadays the DHCP behaviour is very complex in
> a 3GPP
>>>> network; even in a typical smartphone there are intricacies
> about where
>>>> and how the DHCP client and server works. With it comes the
> problem of
>>>> /64 in cellular networks (which some dont call a problem, but 
>>>> I
> do).
>>>> 
>>>> So, it would be interesting to see whether starlink has the
> same /64
>>>> problem as 3GPP has, or is free of it (simply put: can I
> connect several
>>>> Ethernet subnets in my home to starlink, in native IPv6 that 
>>>> is, or
>>> not?).
>>>> 
>>>> Alex
>>>> 
>>>> _______________________________________________ Starlink 
>>>> mailing list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>>> _______________________________________________
>>> Starlink mailing list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>> 
>> 
> 

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

On Tue, 19 Sep 2023, Alexandre Petrescu wrote:

> Le 19/09/2023 à 02:36, Hesham ElBakoury a écrit :
> [...]
>
>> On Mon, Sep 18, 2023, 5:31 PM David Lang <david@lang.hm
> [...]
>
>> Starlink is just another IP path,
>
> Yes.
>
> For IPv6 it might not be that simple.  There can be things suggested to
> starlink to implement, such as to make it better from an IPv6
> standpoint.  That includes, and is not limited to, this /64 aspect.
>
> For IP in general (be it IPv4 or IPv6), as long as starlink stays
> closed, there might be no interest to suggest anything about IP that
> they have not already thought of.

Personally, I think that it's more a situation that they are doing something 
that nobody else has done (at least on anything close to this scale) so they are 
scrambling to make it work and finding things that the rest of us are just 
speculating about.

> IF on the other hand, starlink feels a need to interoperate, then we can
> discuss.

interoperate with what is the question.

Interoperate with other ground stations?

include other companies satellites in their space based routing?

Right now there isn't a lot in the way of other space based routing for them to 
possibly be interoperable with, and other systems have been actively hostile to 
Starlink (I don't know if it's mutual or not, I don't see everything, but the 
news I've heard has been primarily other companies trying to use regulations to 
block Starlink, not a basis for cooperation)

I also think that it's a bit early to push for standardization of the links. We 
don't have enough experience to know what really works on this sort of scale and 
dynamic connection environment.

> It is possible that starlink does not feel any need to interoperate now.
> At that point, the need to interoperate might come as a mandate from
> some outside factors.  Such factors could be the public-private
> cooperations.  Other factors could be partnerships that appear when some
> organisations feel the need to cooperate.  I will not speculate when,
> but it happens.
>
> Assuming that such openness appears, with a need to interoperate, then
> there certainly will be perspective developped where Starlink is not
> just another IP path.
>
>> all the tools that you use with any other ISP work on that path (or
>> are restricted like many other consumer ISPs with dynamic addressing,
>> no inbound connections, no BGP peering, etc. No reason that the those
>> couldn't work, SpaceX just opts not to support them on consumer
>> dishes)
>
> But, these other ISPs (not Starlink) are all standardized.

they are now, but they have not been in the past, and nothing prevents a 
networking vendor from introducing new proprietary things that only work on 
their equipment and are (hopefully) transparent to users. We actually see this 
with caching, 'wan accelerators', captive portals, etc

>> I'll turn the question back to you, what is the problem that you think is 
>> there that needs to be solved?
>
> Here is one, but there are potentially more.  I would not close the door to 
> searching them.
>
> I dont have DISHY, so no first hand experience.
>
> But I suspect the IPv6 it supports it is an IPv6 encapsulated in IPv4. That 
> adds to latency, not to say bufferbloat.  It brings in a single point of 
> failure too (if it fails, then all fails).

is there some testing that I can do to help you with this?

personally, I suspect that even IPv4 is encapsulated in some way.

> Then, when they'll want to remove that they'd hit into the /64 issue.

I'm not sure exactly what you are referring to here, sorry.

David Lang

> Alex
>> 
>> David Lang
>> 
>>> Thanks, Hesham
>>> 
>>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink < 
>>> starlink@lists.bufferbloat.net
>> <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> 
>>>> it's very clear that there is a computer in the dishy that you
>> are talking
>>>> to. You get the network connection while the dishy is not connected
>> to the
>>>> satellites (there's even a status page and controls, stowing and
>> unstowing
>>>> for example)
>>>> 
>>>> I think we've seen that the dishy is running linux (I know the
>> routers run
>>>> an old openwrt), but I don't remember the details of the dishy
>> software.
>>>> 
>>>> David Lang
>>>> 
>>>> On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>>> 
>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200 From: Alexandre Petrescu via 
>>>>> Starlink
>> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com
>> <mailto:alexandre.petrescu@gmail.com>>
>>>>> To: starlink@lists.bufferbloat.net
>> <mailto:starlink@lists.bufferbloat.net>
>>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>>>> Satellites and
>>>>> Terrestial Networks
>>>>> 
>>>>> 
>>>>> Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>>>>> On 16/09/2023 5:52 am, David Lang wrote:
>>>>>>> 
>>>>>>> In addition to that Ulrich says, the dishy is a full
>> computer, it's
>>>>>>> output is ethernet/IP and with some adapters or cable
>> changes, you
>>>>>>> can plug it directly into a router.
>>>>>> 
>>>>>> We've done that with the Yaosheng PoE Dishy adapter - actually
>> plugged
>>>>>> a DHCP client straight in - and it "works" but with a noticeably higher 
>>>>>> rate of disconnects.
>>>>> 
>>>>> It is good to know one can plug a DHCP client into the Ethernet
>> of the
>>>>> DISHY and receive DHCP replies.
>>>>> 
>>>>> But that would be only a lead into what kind of DHCPv4 is
>> supported, or
>>>> not.
>>>>> 
>>>>> I would ask to know whether the DHCP server runs on the DISHY, or 
>>>>> whether it is on the ground network of starlink, i.e. the reply
>> to DHCP
>>>>> request comes after 50ms, or after 500microseconds (timestamp
>> difference
>>>>> can be seen in the wireshark run on that Ethernet).
>>>>> 
>>>>> This (DHCP server daemon on dishy or on ground segment) has an
>> impact of
>>>>> how IPv6  can be, or is, made to work.
>>>>> 
>>>>> This kind of behaviour of DHCP - basically asking who
>>>>> allocates an address - has seen a continous evolution in 3GPP
>>>>> cellular
>> networks since
>>>>> they appeared.  Nowadays the DHCP behaviour is very complex in
>> a 3GPP
>>>>> network; even in a typical smartphone there are intricacies
>> about where
>>>>> and how the DHCP client and server works. With it comes the
>> problem of
>>>>> /64 in cellular networks (which some dont call a problem, but I
>> do).
>>>>> 
>>>>> So, it would be interesting to see whether starlink has the
>> same /64
>>>>> problem as 3GPP has, or is free of it (simply put: can I
>> connect several
>>>>> Ethernet subnets in my home to starlink, in native IPv6 that is, or
>>>> not?).
>>>>> 
>>>>> Alex
>>>>> 
>>>>> _______________________________________________ Starlink mailing list 
>>>>> Starlink@lists.bufferbloat.net
>> <mailto:Starlink@lists.bufferbloat.net>
>>>>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>
>>>>> _______________________________________________
>>>> Starlink mailing list Starlink@lists.bufferbloat.net
>> <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>
>>>> 
>>> 
>> 
>

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 19/09/2023 à 01:32, Hesham ElBakoury a écrit :
> Given the discussions in this email thread, what IETF should standardize 
> in priority order  for the integrated NTN terrestrial networks?

Maybe make the NTN networks run IP, and preferably IPv6.  It would be a 
good step towards integrating with the IP flat networks on the ground.

(yes, I know, many will say that starlink does support IP and even IPv6, 
but I believe there is no IP in the sats; or maybe I have to read more).

Alex

> 
> Thanks,
> Hesham
> 
> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink 
> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> 
> wrote:
> 
>     it's very clear that there is a computer in the dishy that you are
>     talking to.
>     You get the network connection while the dishy is not connected to the
>     satellites (there's even a status page and controls, stowing and
>     unstowing for
>     example)
> 
>     I think we've seen that the dishy is running linux (I know the
>     routers run an
>     old openwrt), but I don't remember the details of the dishy software.
> 
>     David Lang
> 
>        On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
> 
>      > Date: Sun, 17 Sep 2023 19:21:50 +0200
>      > From: Alexandre Petrescu via Starlink
>     <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>      > Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com
>     <mailto:alexandre.petrescu@gmail.com>>
>      > To: starlink@lists.bufferbloat.net
>     <mailto:starlink@lists.bufferbloat.net>
>      > Subject: Re: [Starlink] Main hurdles against the Integration of
>     Satellites and
>      >      Terrestial Networks
>      >
>      >
>      > Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>      >> On 16/09/2023 5:52 am, David Lang wrote:
>      >>>
>      >>> In addition to that Ulrich says, the dishy is a full computer,
>     it's
>      >>> output is ethernet/IP and with some adapters or cable changes, you
>      >>> can plug it directly into a router.
>      >>
>      >> We've done that with the Yaosheng PoE Dishy adapter - actually
>     plugged
>      >> a DHCP client straight in - and it "works" but with a noticeably
>      >> higher rate of disconnects.
>      >
>      > It is good to know one can plug a DHCP client into the Ethernet
>     of the
>      > DISHY and receive DHCP replies.
>      >
>      > But that would be only a lead into what kind of DHCPv4 is
>     supported, or not.
>      >
>      > I would ask to know whether the DHCP server runs on the DISHY, or
>      > whether it is on the ground network of starlink, i.e. the reply
>     to DHCP
>      > request comes after 50ms, or after 500microseconds (timestamp
>     difference
>      > can be seen in the wireshark run on that Ethernet).
>      >
>      > This (DHCP server daemon on dishy or on ground segment) has an
>     impact of
>      > how IPv6  can be, or is, made to work.
>      >
>      > This kind of behaviour of DHCP - basically asking who allocates an
>      > address - has seen a continous evolution in 3GPP cellular
>     networks since
>      > they appeared.  Nowadays the DHCP behaviour is very complex in a
>     3GPP
>      > network; even in a typical smartphone there are intricacies about
>     where
>      > and how the DHCP client and server works. With it comes the
>     problem of
>      > /64 in cellular networks (which some dont call a problem, but I do).
>      >
>      > So, it would be interesting to see whether starlink has the same /64
>      > problem as 3GPP has, or is free of it (simply put: can I connect
>     several
>      > Ethernet subnets in my home to starlink, in native IPv6 that is,
>     or not?).
>      >
>      > Alex
>      >
>      > _______________________________________________
>      > Starlink mailing list
>      > Starlink@lists.bufferbloat.net
>     <mailto:Starlink@lists.bufferbloat.net>
>      > https://lists.bufferbloat.net/listinfo/starlink
>     <https://lists.bufferbloat.net/listinfo/starlink>
>      >_______________________________________________
>     Starlink mailing list
>     Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/starlink
>     <https://lists.bufferbloat.net/listinfo/starlink>
> 

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

On Tue, 19 Sep 2023, Alexandre Petrescu wrote:

> Le 19/09/2023 à 01:32, Hesham ElBakoury a écrit :
>> Given the discussions in this email thread, what IETF should standardize in 
>> priority order  for the integrated NTN terrestrial networks?
>
> Maybe make the NTN networks run IP, and preferably IPv6.  It would be a good 
> step towards integrating with the IP flat networks on the ground.

if you want Starlink to run IPv6, then I think that someone needs to show how it 
would work in such a dynamic environment, with the links/paths changing every 
few minutes, and the ground stations moving as well. I've seen papers on mobile 
IP addresses in the past, but those have all involved so much tunneling that it 
really hasn't mattered if the underlying network is IP or not,

> (yes, I know, many will say that starlink does support IP and even IPv6, but 
> I believe there is no IP in the sats; or maybe I have to read more).

I don't think anyone knows what the in-space protocols are. We know there is not 
in-space routing, so it's no longer a matter of simple bent-pipe relaying, but I 
haven't heard of any leaks/papers on the topic (if there are any, I'm 
interested, but haven't gone digging, counting on others to find them and bring 
it up here :-) )

David Lang

> Alex
>
>> 
>> Thanks,
>> Hesham
>> 
>> On Sun, Sep 17, 2023, 12:59 PM David Lang via Starlink 
>> <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> 
>> wrote:
>>
>>     it's very clear that there is a computer in the dishy that you are
>>     talking to.
>>     You get the network connection while the dishy is not connected to the
>>     satellites (there's even a status page and controls, stowing and
>>     unstowing for
>>     example)
>>
>>     I think we've seen that the dishy is running linux (I know the
>>     routers run an
>>     old openwrt), but I don't remember the details of the dishy software.
>>
>>     David Lang
>>
>>        On Sun, 17 Sep 2023, Alexandre Petrescu via Starlink wrote:
>>
>>      > Date: Sun, 17 Sep 2023 19:21:50 +0200
>>      > From: Alexandre Petrescu via Starlink
>>     <starlink@lists.bufferbloat.net 
>> <mailto:starlink@lists.bufferbloat.net>>
>>      > Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com
>>     <mailto:alexandre.petrescu@gmail.com>>
>>      > To: starlink@lists.bufferbloat.net
>>     <mailto:starlink@lists.bufferbloat.net>
>>      > Subject: Re: [Starlink] Main hurdles against the Integration of
>>     Satellites and
>>      >      Terrestial Networks
>>      >
>>      >
>>      > Le 16/09/2023 à 01:32, Ulrich Speidel via Starlink a écrit :
>>      >> On 16/09/2023 5:52 am, David Lang wrote:
>>      >>>
>>      >>> In addition to that Ulrich says, the dishy is a full computer,
>>     it's
>>      >>> output is ethernet/IP and with some adapters or cable changes, you
>>      >>> can plug it directly into a router.
>>      >>
>>      >> We've done that with the Yaosheng PoE Dishy adapter - actually
>>     plugged
>>      >> a DHCP client straight in - and it "works" but with a noticeably
>>      >> higher rate of disconnects.
>>      >
>>      > It is good to know one can plug a DHCP client into the Ethernet
>>     of the
>>      > DISHY and receive DHCP replies.
>>      >
>>      > But that would be only a lead into what kind of DHCPv4 is
>>     supported, or not.
>>      >
>>      > I would ask to know whether the DHCP server runs on the DISHY, or
>>      > whether it is on the ground network of starlink, i.e. the reply
>>     to DHCP
>>      > request comes after 50ms, or after 500microseconds (timestamp
>>     difference
>>      > can be seen in the wireshark run on that Ethernet).
>>      >
>>      > This (DHCP server daemon on dishy or on ground segment) has an
>>     impact of
>>      > how IPv6  can be, or is, made to work.
>>      >
>>      > This kind of behaviour of DHCP - basically asking who allocates an
>>      > address - has seen a continous evolution in 3GPP cellular
>>     networks since
>>      > they appeared.  Nowadays the DHCP behaviour is very complex in a
>>     3GPP
>>      > network; even in a typical smartphone there are intricacies about
>>     where
>>      > and how the DHCP client and server works. With it comes the
>>     problem of
>>      > /64 in cellular networks (which some dont call a problem, but I do).
>>      >
>>      > So, it would be interesting to see whether starlink has the same /64
>>      > problem as 3GPP has, or is free of it (simply put: can I connect
>>     several
>>      > Ethernet subnets in my home to starlink, in native IPv6 that is,
>>     or not?).
>>      >
>>      > Alex
>>      >
>>      > _______________________________________________
>>      > Starlink mailing list
>>      > Starlink@lists.bufferbloat.net
>>     <mailto:Starlink@lists.bufferbloat.net>
>>      > https://lists.bufferbloat.net/listinfo/starlink
>>     <https://lists.bufferbloat.net/listinfo/starlink>
>>      >_______________________________________________
>>     Starlink mailing list
>>     Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>     https://lists.bufferbloat.net/listinfo/starlink
>>     <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 15/09/2023 à 19:52, David Lang via Starlink a écrit :
> On Sat, 16 Sep 2023, Ulrich Speidel via Starlink wrote:
>
>> On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>>>
>>> I must say that I dont know whether the original 'DISHY' is simply a
>>> dish antenna with an analog amplifier and maybe some mechanical motor
>>> steering, or whether DISHY includes a computer to execute some 
>>> protocol,
>>> some algorithm.
>
> In addition to that Ulrich says, the dishy is a full computer, it's 
> output is ethernet/IP and with some adapters or cable changes, you can 
> plug it directly into a router.
>
> There are numberous teardown videos on youtube now, for both the 
> original and the 1st of the rectangular dishys, they will show you how 
> complex the system is.

Thanks for the note.  It's always interesting to look at teardowns.

The Ethernet/IP capability in the antenna box is very promising.

If I had one, the first think I'd do is to use wireshark to listen on 
that Ethernet port to see whether it sends Router Advertisements (IPv6).

People say IPv6 is supported but there are many ways in which IPv6 can 
be 'supported', and some are better than others, not the least being 
NAT66, IPv6-in-IPv4 and the prefix length (64 or not).  And DHCPv6 of 
course.  Native vs non native IPv6, in short.

Alex

>
> David Lang
>
>  >
>> It's a phased array, not a dish, even if it looks like one. It 
>> consists of 100's of fingernail-sized antenna elements that:
>>
>> * during transmissions, have an individual phase delay added to the
>>   signal transmitted from that element, in order to permit
>>   transmission of the combined signal from all elements into a
>>   particular direction.
>> * during reception, have an individual phase delay added to the signal
>>   collected by that element, before the signals are added to obtain
>>   the combined received signal. This allows reception from a
>>   particular direction.
>>
>> Dishy's main direction of transmission / reception is therefore not 
>> its surface normal - this simply points to the area of the sky where 
>> Dishy expects to see most satellites (a function of geographical 
>> latitude and constellation design - essentially straight up in the 
>> tropics, and elsewhere in the direction of the 53rd parallel, which 
>> corresponds to the predominant orbital inclination in the Starlink 
>> fleet). The actual tracking is then done with the phased array 
>> without mechanical movement by Dishy.
>>
>> From what I've seen, Dishy seems to consume more power on receive 
>> than on transmit - that's if you actually download stuff. This is 
>> somewhat counter-intuitive if you're used to putting link budgets 
>> together. But I'd attribute that to a higher degree of digital signal 
>> processing required on the receive and demodulation path.
>>
>>
>
> _______________________________________________
> 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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 15/09/2023 à 17:18, Ulrich Speidel via Starlink a écrit :
>
>
> On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>>
>> I must say that I dont know whether the original 'DISHY' is simply a
>> dish antenna with an analog amplifier and maybe some mechanical motor
>> steering, or whether DISHY includes a computer to execute some protocol,
>> some algorithm.
>
> It's a phased array, not a dish, even if it looks like one. It 
> consists of 100's of fingernail-sized antenna elements that:
>
>   * during transmissions, have an individual phase delay added to the
>     signal transmitted from that element, in order to permit
>     transmission of the combined signal from all elements into a
>     particular direction.
>   * during reception, have an individual phase delay added to the
>     signal collected by that element, before the signals are added to
>     obtain the combined received signal. This allows reception from a
>     particular direction.
>
> Dishy's main direction of transmission / reception is therefore not 
> its surface normal - this simply points to the area of the sky where 
> Dishy expects to see most satellites (a function of geographical 
> latitude and constellation design - essentially straight up in the 
> tropics, and elsewhere in the direction of the 53rd parallel, which 
> corresponds to the predominant orbital inclination in the Starlink 
> fleet). The actual tracking is then done with the phased array without 
> mechanical movement by Dishy.
>
Thanks for the description.  It is an advanced and interesting antenna 
behaviour for a consumer product.  It is good the mechanical motor is 
replaced with phasing.

More advanced phasing is probably used in their antenna version for 
automobiles, but might be the same principles.

Then, for ships, where more 3D-imensional like movements exist, 
replacing big motors with phasing can represent significant gains in 
terms of space occupied.

> From what I've seen, Dishy seems to consume more power on receive than 
> on transmit - that's if you actually download stuff. This is somewhat 
> counter-intuitive if you're used to putting link budgets together. But 
> I'd attribute that to a higher degree of digital signal processing 
> required on the receive and demodulation path.
>
It is interesting it consumes more on receive than on transmit. Thanks.

There was a pointer here pointing to an ETSI document about what might 
be a sort of certification (access to medium to not disturb the 
others).  In it, it seems a different freq is used for transmit than for 
receive. (12 vs 14GHz, or so, or vice-versa). The difference in frquency 
might also be a factor (in addition to the dsp calculus you mention) in 
differentiating the consumption up vs download.  I'd expect working with 
higher freuencies to require more energy.  But I am not sure an ETSI 
document can be for US starlink end user device.

Alex

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

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Steve Stroh]

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

Correction - Dishy has a motor AND a phased array antenna.

Dishy figures out the best direction and azimuth to orient the antenna and
uses the motor to do so. The phased array then tracks the orbital
progression of each satellite it chooses to use for maximum SNR.

I’ve read that the motor can also be used in creative ways like tipping
itself to as close to vertical as possible to remove accumulated snow.

You can choose to lock (disable) the motor - I’ve seen this done for fixed
installations like RVs and boats and if there are no obstacles such as
trees and there’s a sufficient density of sats in your location, “motor
off” mode can work reasonably well.

Steve Stroh

On Sun, Sep 17, 2023 at 10:09 Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
> Thanks for the description.  It is an advanced and interesting antenna
> behaviour for a consumer product.  It is good the mechanical motor is
> replaced with phasing.
>
> More advanced phasing is probably used in their antenna version for
> automobiles, but might be the same principles.
>
> Then, for ships, where more 3D-imensional like movements exist,
> replacing big motors with phasing can represent significant gains in
> terms of space occupied.
>
> It is interesting it consumes more on receive than on transmit. Thanks.
>
> There was a pointer here pointing to an ETSI document about what might
> be a sort of certification (access to medium to not disturb the
> others).  In it, it seems a different freq is used for transmit than for
> receive. (12 vs 14GHz, or so, or vice-versa). The difference in frquency
> might also be a factor (in addition to the dsp calculus you mention) in
> differentiating the consumption up vs download.  I'd expect working with
> higher freuencies to require more energy.  But I am not sure an ETSI
> document can be for US starlink end user device.
>
> Alex
>
> > --
> > ****************************************************************
> > 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: 3117 bytes --]

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[Alexandre Petrescu]

Le 30/08/2023 à 18:51, Inemesit Affia a écrit :
> With the existence of solutions like OpenMTCProuter, SDWAN, policy 
> based routing or any solution in general that allows combination in a 
> sense of any number of IP links, I really don't see a point for 
> specific solutions. Can anyone enlighten me?

I would be interested to see how MTCP, QUIC, SDWAN and policy based 
routing can help an end-user smartphone take advantage simultaneously of 
a low latency offered by a drone-airplane and of a high bandwidth 
offered by a MEO-GEO sat.  This would be an ideal solution for UE; it 
would compete directly with the latency and bandwidths offered by most 
advanced fiber or 6G ground links, but less cable kludge or antenna towers.

I think even Starlink goes somehow in that direction when it puts sats 
at 70km high altitudes: it lowers the altitude and thus reduces latency, 
even though not as low as what a drone/airplane can do at 500m high; 
that lower altitude is combined with their high bandwidth, but in a same 
sat.  And, not sure what kind of protocols Starlink uses (not known 
whether starlink sats have IP addresses,  neither whether they are IPv6 
addresses; not known about what kind of MPTCP or QUIC is there, or is it 
only a complete L2 network).

It is said somewhere that kepler (a competitor somehow to starlink) sats 
might carry BGP routers, so that would make kepler sats to have IP 
addresses inside, if so.  But even that is not sure: it is not really 
sure that kepler runs BGP on sat, or alternatively kepler sats is also 
an entire L2 network that transports BGP (and thus IP) packets through.


> For home users an issue may be IP blocks for certain services like 
> Netflix when the egress is out of a VPN or cloud provider richer than 
> a residential provider


Not sure what it means?

Alex


>
> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink 
> <starlink@lists.bufferbloat.net> wrote:
>
>
>     Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>     > Here is a report which summarizes the outcome of the last
>     Satellites
>     > conference
>     >
>     [https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up]
>     >
>     > The report highlights the two main hurdles against the
>     integration of
>     > satellites and terrestrial networks: standardization and
>     business model.
>     >
>     > "/Most of the pushback against closer integration of terrestrial
>     > wireless and satellite networks revolved around standardization.
>     This
>     > may just be growing pains and it likely reflects the relative
>     > positions of wireless and satellite along the maturity curve,
>     but some
>     > of the speakers were arguing against standardization. The basis of
>     > this argument was that the mobile industry only understands
>     standards,
>     > but the satellite industry is currently differentiating based on
>     > custom systems and capabilities. The feeling was that the satellite
>     > industry had focused on technology and not regulations or standards
>     > and changing that course would not be helpful to the industry in
>     the
>     > short term. Timing is important in this analysis because almost
>     > everyone agreed that at some point, standardization would be a good
>     > thing, but the concern was the best way to get to the point in the
>     > future. The other interesting argument against closer integration
>     > between wireless and satellite had to do with the business model.
>     > Several speakers questioned where the customers would go as
>     > terrestrial and non-terrestrial networks become more integrated.
>     The
>     > underlying issues seemed to include who is responsible for solving
>     > network issues and perhaps more importantly, who recognizes the
>     > revenue. These issues seem, perhaps a bit simplistically, to be
>     > similar to early wireless roaming issues. While these issues
>     created
>     > turbulence in the wireless market, they were solved and that is
>     > probably a template to address these challenges for the wireless
>     and
>     > satellite operators."/
>     > /
>     > /
>     > Comments?
>
>
>     It is an interesting report.
>
>     For standardisation standpoint, it seems SDOs do push towards
>     integration of 5G/6G and satcom; there are strong initiatives at
>     least
>     at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>     these are SDOs traditionally oriented to land communications, rather
>     than space satcom.
>
>     I wonder whether space satcom traditional SDOs (which ones?) have
>     initiated work towards integration with 5G/6G and other land-based
>     Internet?
>
>     Alex
>
>     >
>     > Hesham
>     >
>     > _______________________________________________
>     > 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
>

Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks

[David Lang]

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

On Thu, 31 Aug 2023, Alexandre Petrescu via Starlink wrote:

>> With the existence of solutions like OpenMTCProuter, SDWAN, policy 
>> based routing or any solution in general that allows combination in a 
>> sense of any number of IP links, I really don't see a point for 
>> specific solutions. Can anyone enlighten me?
>
> I would be interested to see how MTCP, QUIC, SDWAN and policy based 
> routing can help an end-user smartphone take advantage simultaneously of 
> a low latency offered by a drone-airplane and of a high bandwidth 
> offered by a MEO-GEO sat.  This would be an ideal solution for UE; it 
> would compete directly with the latency and bandwidths offered by most 
> advanced fiber or 6G ground links, but less cable kludge or antenna towers.

This isn't done on the phone, it's done on your wifi router.

the phone-to-satellite systems are very low bandwidth, and are probably always 
going to be due to the large footprint of each satellite (each 'cell' is very 
large, and you can only have one tansmitter on a given frequency in a given 
'cell'. It's good for low-bandwidth needs as a result

Cell service in urban areas gets it's high bandwidth by having lots of tiny 
cells (5g gets them down to a block or so) so that a given frequency can be 
re-used in a shorter distance.

When I do wifi for the Scale conference (3k+ geeks showing up to the Pasadena 
Convention Center), I run over 100 APs on low power at ground level for the same 
reason.

Even massive satellite antennas (IIRC 25 meter dishes) cannot focus the signal 
down to a area less than 10s of miles wide from orbit, and such large antennas 
cause significant drag at lower altitudes.


once you are taking IP locally from the dish, it's just another ISP (and like 
many residential ISPs, it has limits on incoming traffic). The biggest problem 
is that since the data rate changes frequently, existing rate adaptation 
struggles. It would be really nice to be able to query the dish (or better yet 
subscribe to a feed) to get expected bandwidth as it changes

David Lang


> I think even Starlink goes somehow in that direction when it puts sats 
> at 70km high altitudes: it lowers the altitude and thus reduces latency, 
> even though not as low as what a drone/airplane can do at 500m high; 
> that lower altitude is combined with their high bandwidth, but in a same 
> sat.  And, not sure what kind of protocols Starlink uses (not known 
> whether starlink sats have IP addresses,  neither whether they are IPv6 
> addresses; not known about what kind of MPTCP or QUIC is there, or is it 
> only a complete L2 network).
>
> It is said somewhere that kepler (a competitor somehow to starlink) sats 
> might carry BGP routers, so that would make kepler sats to have IP 
> addresses inside, if so.  But even that is not sure: it is not really 
> sure that kepler runs BGP on sat, or alternatively kepler sats is also 
> an entire L2 network that transports BGP (and thus IP) packets through.
>
>
>> For home users an issue may be IP blocks for certain services like 
>> Netflix when the egress is out of a VPN or cloud provider richer than 
>> a residential provider
>
>
> Not sure what it means?
>
> Alex
>
>
>>
>> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>>
>>     Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>     > Here is a report which summarizes the outcome of the last
>>     Satellites
>>     > conference
>>     >
>> 
> [https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up]
>>     >
>>     > The report highlights the two main hurdles against the
>>     integration of
>>     > satellites and terrestrial networks: standardization and
>>     business model.
>>     >
>>     > "/Most of the pushback against closer integration of terrestrial
>>     > wireless and satellite networks revolved around standardization.
>>     This
>>     > may just be growing pains and it likely reflects the relative
>>     > positions of wireless and satellite along the maturity curve,
>>     but some
>>     > of the speakers were arguing against standardization. The basis of
>>     > this argument was that the mobile industry only understands
>>     standards,
>>     > but the satellite industry is currently differentiating based on
>>     > custom systems and capabilities. The feeling was that the satellite
>>     > industry had focused on technology and not regulations or standards
>>     > and changing that course would not be helpful to the industry in
>>     the
>>     > short term. Timing is important in this analysis because almost
>>     > everyone agreed that at some point, standardization would be a good
>>     > thing, but the concern was the best way to get to the point in the
>>     > future. The other interesting argument against closer integration
>>     > between wireless and satellite had to do with the business model.
>>     > Several speakers questioned where the customers would go as
>>     > terrestrial and non-terrestrial networks become more integrated.
>>     The
>>     > underlying issues seemed to include who is responsible for solving
>>     > network issues and perhaps more importantly, who recognizes the
>>     > revenue. These issues seem, perhaps a bit simplistically, to be
>>     > similar to early wireless roaming issues. While these issues
>>     created
>>     > turbulence in the wireless market, they were solved and that is
>>     > probably a template to address these challenges for the wireless
>>     and
>>     > satellite operators."/
>>     > /
>>     > /
>>     > Comments?
>>
>>
>>     It is an interesting report.
>>
>>     For standardisation standpoint, it seems SDOs do push towards
>>     integration of 5G/6G and satcom; there are strong initiatives at
>>     least
>>     at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>>     these are SDOs traditionally oriented to land communications, rather
>>     than space satcom.
>>
>>     I wonder whether space satcom traditional SDOs (which ones?) have
>>     initiated work towards integration with 5G/6G and other land-based
>>     Internet?
>>
>>     Alex
>>
>>     >
>>     > Hesham
>>     >
>>     > _______________________________________________
>>     > 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
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>