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

Alexandre Petrescu alexandre.petrescu at gmail.com
Wed Oct 18 11:04:40 EDT 2023 

Le 16/10/2023 à 15:26, David Fernández via Starlink a écrit :
> Regarding this: "The SDA standard (:
> https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf)

This document looks like a standard of a communication system. For 
example it has a packet format (figure 11 "FSO Payload Frame Format").

One could think about further specifying how to transmit IP packets on it.


> requires beaconless PAT without a side channel to sync the two OCTs,
> which makes things much harder. Acquisition times are longer, and
> initial pointing requires extremely accurate knowledege of the
> position of the other side, which greatly increases cost."
>
> Following the example of the SDA (Space Development Agency), ESA has
> also now an optical link specification for 2.5 Gbps, 10 Gbps and 100 /
> 200 /400 Gbps per channel consolidated with the help of 18 European
> industries.
Has it?  Or is it in project phase?
>
> See the link to ESTOL (ESA Specification for Terabit/sec Optical
> Links) here: https://www.esa.int/Applications/Connectivity_and_Secure_Communications/European_space_firms_set_specifications_for_optical_links

At that URL there is a "ESA Specifications for Terabit/second Optical 
Links" https://esamultimedia.esa.int/docs/CSC/ESTOL.pdf

It refers some times to "Open ROADM", but not sure what is this "Open 
ROADM".  The URL http://www.openroadm.org/ is insecure.  Its https 
counterpart URL tells "SSL_ERROR_NO_CYPHER_OVERLAP".

The ESTOL and OCT frame formats seem to be different (Figure 4 "2.5G OOK 
frame structure" vs Figure 11 "FSO Payload Frame Format")


At the same time, there is now this Horizon Europe call for projects 
ongoing in the Space destination of Cluster 4 
"HORIZON-CL4-2024-SPACE-01-73".  Sorry for the acronym speech.

It calls for a few things, among which "High data rate (12.5 to 28 Gbps 
or higher 56 Gbps), low consumption, short range links [Target TRL 7]" 
among other things.

Maybe ESTOL is the same thing as it is called for by this call, or maybe 
ESTOL is for space-to-ground and this call is for ISL. It is not clear 
to me.

>
> The ESTOL follows the PAT process of SDA due to compatibility with
> existing European terminal suppliers.
>
> The ‘beaconless’ PAT is not necessarily performing worse than having a
> side channel; it simply means that the communications wavelength is
> used also for initial acquisition and then for tracking.
> This is also the approach in EDRS
> (https://connectivity.esa.int/european-data-relay-satellite-system-edrs-overview)
> and actually SDA has formalized the EDRS approach.
>
> The separate wavelength (or beacon) may provide some advantages in
> space to ground links rather than space-space ISLs.

You seem to be understanding the ESTOL specs. I dont.

I might dare saying the following: if one would like interop between 
ESTOL and SDA OCT, maybe one wants to make a gateway with an ESTOL and 
an SDA OCT interface on it.

And have IP running and on SDA OCT, and on ESTOL.

For that to work, one would need an IP-over-SDA-OCT spec, and an 
IP-over-ESTOL spec.  These could come in the form of Internet Drafts 
proposed at IETF.

It  might be also possible that ESTOL does not yet fully exist as a 
spec; as such it could  be further adapted to be more compatible with 
SDA OCT.  At that point, a single Internet Draft 
"IP-over-OCT-kind-of-ESTOL" would be sufficient to gain interop.

>
> Starlink optical ISL at 100G is most likely reusing the terrestrial
> fibre optics COTS transceivers in space, as planned to do by Hydron
> (https://connectivity.esa.int/developing-future-optical-highcapacity-satellite-networks-hydron-high-throughput-optical-network)
> and ESTOL.

For Hydron: I did not know it, thanks.

For Starlink optical ISL: I think it could be several other things, and 
not necessarily ESTOL or Hydron.

Also some ESA calls point to these other laser devices for satcom:

- "TOSIRIS - Direct-to-Earth Laser Communication Terminal" ==> CCSDS.  
(is ESTOL the same as CCSDS?)

- TESAT Pixl - maybe the same as TOSIRIS(?)

- "SmallCAT laser communication system" ==> maybe also uses CCSDS.

- "OPTEL-μ: Optical Terminal for Small Satellite LEO Applications" ==> 
uses  MCS (Modulation and Coding Scheme, but I dont know what is it).

These seem to be small and affordable devices.

All in all, to me, the question is that of interoperability, because 
there are so many link layers up there.

Maybe SDA OCT, ESTOL and CCSDS are all the same thing, or maybe not.

The great thing would be to run IP on them.

Alex



>
> Regards,
>
> David
>
>> Date: Sat, 2 Sep 2023 20:44:06 -0700
>> From: Mike Puchol <mike at starlink.sx>
>> To: starlink at lists.bufferbloat.net
>> Subject: Re: [Starlink] Main hurdles against the Integration of
>> 	Satellites and Terrestial Networks
>> Message-ID: <8070d746-1aa0-45a6-8b0f-9bc4f01d1c8d at Spark>
>> Content-Type: text/plain; charset="utf-8"
>>
>> The ETSI standard you reference is a generic framework for testing &
>> measuring earth stations connecting to NGSO systems, so they may be using
>> it, but it’s not mandatory. In any case, the standard doesn’t have any
>> effect on the RF characteristics, the interoperability, etc.
>>
>> Regarding ISL, I would doubt they use the SDA OCT standard, except maybe for
>> Starshield payloads. The SDA standard requires beaconless PAT without a side
>> channel to sync the two OCTs, which makes things much harder. Acquisition
>> times are longer, and initial pointing requires extremely accurate
>> knowledege of the position of the other side, which greatly increases cost.
>>
>> Best,
>>
>> Mike
>> On Sep 2, 2023 at 18:03 -0700, David Fernández via Starlink
>> <starlink at lists.bufferbloat.net>, wrote:
>>> It seems that Starlink follows this norm, although it does not reflect
>>> the entire Starlink system specification:
>>> https://www.etsi.org/deliver/etsi_en/303900_303999/303981/01.02.00_30/en_303981v010200v.pdf
>>>
>>> Then, for the ISL, I suppose they are following this:
>>> https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf
>>>
>>>> Date: Fri, 1 Sep 2023 17:27:30 +0100
>>>> From: Inemesit Affia <inemesitaffia at gmail.com>
>>>> To: David Lang <david at lang.hm>
>>>> Cc: Alexandre Petrescu <alexandre.petrescu at gmail.com>,
>>>> starlink at lists.bufferbloat.net
>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>>>> Satellites and Terrestial Networks
>>>> Message-ID:
>>>> <CAJEhh70CMSk_WAmd9sgXfMDoWZhhz5uPAU=d5UG3rW5XFkw1KQ at mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> 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 at 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 at 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 at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230902/9209f929/attachment-0001.html>
>>
>> ------------------------------
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

More information about the Starlink mailing list