From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E510E3B29D for ; Mon, 16 Oct 2023 09:26:13 -0400 (EDT) Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-1e9d0fc55beso1566435fac.3 for ; Mon, 16 Oct 2023 06:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697462773; x=1698067573; darn=lists.bufferbloat.net; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zGUDr2mI3ShR0pDMkzoxbzi4fagFmbyXDsCl/e+oldg=; b=G2h5+M2HXcbYwSgzM5z8PCzIy6Eq1+Z1TAcrOV1x3qur/KycQNuyPqQgD/zOI0SXor JC3tEPXkrQMAufTn0Qlc2DsGdP92e3pff1+qofeEBJu1KIU5Jd3n+SR9+7S/e1tuoQy2 c3dHBYh2SzMG6B9gP/U43vPymRvkLWZDiVYtlYy9fsdionDd9OQJfGqvUQsNiPlDcclG CLNaOIQ7W+3vd/JZV5g0qpRzJLZ7IgAJzY3ubWBNXpJEuQOtTtYiDy4zbvpktkdC6U9r M0UxjXTUrUIIfprw2ZzJ+uAXiKq7tJOZ05ZaMDFA7u2hY8LO3G9dUZVGjgmCK9vdtREy eflA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697462773; x=1698067573; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zGUDr2mI3ShR0pDMkzoxbzi4fagFmbyXDsCl/e+oldg=; b=Hdw1SLlrFXmnBPKxKdPLQSbYEOFESGt/QLUXjJCgV9n0apiY0KNav7D7Auy8SjpQ6x M3GV21lwPLDWXAxpnnzxqeXTPpfkYu0KeMKz/CPpDnQ05lIvkmnHYXal0LfzQRk6nCA8 ea654aLdmBejcRKmRdOq4VFosZjNtqmYJbaKIiZ8LEyOOjKVi0/RJ0Mh9ZIhjb2SbT1r Hz2Zfu6V5lspmEDqeBNzKZry22sHp+CUJdELq13sgb8RTPd7l4byp22v7AXBoIPPyqI0 Ugky8y4BEJ+ALCxTNd5pd1oHqia0Bk1NwC+5fOFUKrIzMsdnk+G2p1eV3pqegbEHlUcw nNQw== X-Gm-Message-State: AOJu0Yw78x0sBy6Z8MRZHpjyTm1/1DBuk0QAvRpfTcBLATFF1rSYkDwd Kht3lzEC5rfb/u/6h2vKc0FvxNqrWVXwezPa+yfB6XObYAxZrw== X-Google-Smtp-Source: AGHT+IHVFMXSQMvaMtPiRbXt+3oLwT+x2nymJeNYwLEjqVLZgi5a1SVEwsY0wFNE1s5+vKftxwos/2I0cI8u7JEPR/k= X-Received: by 2002:a05:6871:8483:b0:1e9:d830:160b with SMTP id sv3-20020a056871848300b001e9d830160bmr10380650oab.10.1697462772563; Mon, 16 Oct 2023 06:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6358:5306:b0:143:54ad:58e5 with HTTP; Mon, 16 Oct 2023 06:26:12 -0700 (PDT) From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Mon, 16 Oct 2023 15:26:12 +0200 Message-ID: To: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2023 13:26:14 -0000 Regarding this: "The SDA standard (: https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf) 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. See the link to ESTOL (ESA Specification for Terabit/sec Optical Links) here: https://www.esa.int/Applications/Connectivity_and_Secure_Commu= nications/European_space_firms_set_specifications_for_optical_links The ESTOL follows the PAT process of SDA due to compatibility with existing European terminal suppliers. The =E2=80=98beaconless=E2=80=99 PAT is not necessarily performing worse th= an 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-ove= rview) 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. 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-satell= ite-networks-hydron-high-throughput-optical-network) and ESTOL. Regards, David > Date: Sat, 2 Sep 2023 20:44:06 -0700 > From: Mike Puchol > To: starlink@lists.bufferbloat.net > Subject: Re: [Starlink] Main hurdles against the Integration of > Satellites and Terrestial Networks > Message-ID: <8070d746-1aa0-45a6-8b0f-9bc4f01d1c8d@Spark> > Content-Type: text/plain; charset=3D"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=E2=80=99s not mandatory. In any case, the standard doesn=E2=80= =99t 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 s= ide > 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 cos= t. > > Best, > > Mike > On Sep 2, 2023 at 18:03 -0700, David Fern=C3=A1ndez via Starlink > , 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 >> > To: David Lang >> > Cc: Alexandre Petrescu , >> > starlink@lists.bufferbloat.net >> > Subject: Re: [Starlink] Main hurdles against the Integration of >> > Satellites and Terrestial Networks >> > Message-ID: >> > >> > Content-Type: text/plain; charset=3D"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 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 that= s >> > > 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 intera= ct >> > > 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 WA= Y >> > > 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 =C3=A0 14:10, Hesham ElBakoury via Starlink a =C3= =A9crit : >> > > > > > Here is a report which summarizes the outcome of the last >> > > > > > Satellites >> > > > > > conference >> > > > > > [ >> > > > > >> > > https://www.microwavejournal.com/articles/39841-satellite-2023-summa= ry-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 terrestri= al >> > > > > > wireless and satellite networks revolved around standardizatio= n. >> > > > > > 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 basi= s >> > > > > > 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 almos= t >> > > > > > 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 integrate= d. >> > > > > > The >> > > > > > underlying issues seemed to include who is responsible for >> > > > > > solving >> > > > > > network issues and perhaps more importantly, who recognizes th= e >> > > > > > revenue. These issues seem, perhaps a bit simplistically, to b= e >> > > > > > similar to early wireless roaming issues. While these issues >> > > > > > created >> > > > > > turbulence in the wireless market, they were solved and that i= s >> > > > > > probably a template to address these challenges for the wirele= ss >> > > > > > 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?) hav= e >> > > > > initiated work towards integration with 5G/6G and other land-bas= ed >> > > > > Internet? >> > > > > >> > > > > Alex >> > > > > >> > > > > > >> > > > > > Hesham >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------