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
<[email protected]> 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
> [email protected]
> https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
