[Starlink] Time Synchronization in Satellite Networks

[Starlink] Time Synchronization in Satellite Networks

[Hesham ElBakoury]

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

Time synchronization, for satellite networks, faces several challenges:

1. Signal Propagation Delays: Unlike terrestrial networks where signals
travel through cables at the speed of light, satellite communication
involves signals traveling vast distances through space. This creates
significant delays.

2. Clock Drift: Even highly precise atomic clocks, used in satellites, are
susceptible to "drift" - gradually losing or gaining time. This drift,
caused by factors like temperature variations, radiation exposure, and
power fluctuations, can lead to inconsistencies in timekeeping across the
network.

3. Signal Degradation: As signals travel through space, they can degrade
due to factors like atmospheric interference, ionospheric disturbances, and
solar activity. This degradation can introduce noise and errors, impacting
the accuracy of time synchronization messages.

4. Limited Resources: Satellites have limited power and processing
capabilities. Implementing complex synchronization protocols can be
resource-intensive, requiring careful optimization to minimize their impact
on other functionalities.

5. Evolving Technologies: As satellite technologies and applications
continue to evolve, new challenges related to synchronization might emerge.
For example, the integration of constellations with thousands of satellites
poses unique synchronization challenges due to the sheer scale and
complexity of the network.

These challenges necessitate the development of robust and efficient time
synchronization protocols for satellite networks and an integrated
satellite and  terrestrial networks

Are you aware of such time synchronization protocols?

I would think that using Satellite simulators is the most viable way to
develop and test these protocols given that using satellites is not that
easy.

Thanks

Hesham

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

Re: [Starlink] Time Synchronization in Satellite Networks

[Sebastian Moeller]

Hi Hesham

> On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Time synchronization, for satellite networks, faces several challenges:
> 1. Signal Propagation Delays: Unlike terrestrial networks where signals travel through cables at the speed of light,

[SM] The speed of light in your typical glas fibers (and accidentally the information propagation speed in metallic conductors) comes in roughly at 2/3 of the speed of light in vacuum, while the speed of light in air at see level is a mere 90 KM/s slower than in vacuum. 

> satellite communication involves signals traveling vast distances through space. This creates significant delays.

[SM] Sure distances might be larger, but propagation speed is around 100000Km/s faster... my main point is speed of light is a) dependent on the medium b) not the things that differentiates space from the earth's surface here, but mere geometry and larger distances on larger spheres...

> 2. Clock Drift: Even highly precise atomic clocks, used in satellites, are susceptible to "drift" - gradually losing or gaining time. This drift, caused by factors like temperature variations, radiation exposure, and power fluctuations, can lead to inconsistencies in timekeeping across the network.
> 3. Signal Degradation: As signals travel through space, they can degrade due to factors like atmospheric interference, ionospheric disturbances, and solar activity. This degradation can introduce noise and errors, impacting the accuracy of time synchronization messages. 
> 4. Limited Resources: Satellites have limited power and processing capabilities. Implementing complex synchronization protocols can be resource-intensive, requiring careful optimization to minimize their impact on other functionalities.
> 5. Evolving Technologies: As satellite technologies and applications continue to evolve, new challenges related to synchronization might emerge. For example, the integration of constellations with thousands of satellites poses unique synchronization challenges due to the sheer scale and complexity of the network.
> These challenges necessitate the development of robust and efficient time synchronization protocols for satellite networks and an integrated satellite and  terrestrial networks
> Are you aware of such time synchronization protocols?
> I would think that using Satellite simulators is the most viable way to develop and test these protocols given that using satellites is not that easy.
> Thanks
> Hesham
> 
> 
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Time Synchronization in Satellite Networks

[Hesham ElBakoury]

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

Hi Sebastian,
Can we still use PTP and NTP for time synchronization in  Satellite
networks or we need new protocols? If we need new protocols, do such
protocols exist?

Thanks
Hesham

On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Hesham
>
> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> >
> > Time synchronization, for satellite networks, faces several challenges:
> > 1. Signal Propagation Delays: Unlike terrestrial networks where signals
> travel through cables at the speed of light,
>
> [SM] The speed of light in your typical glas fibers (and accidentally the
> information propagation speed in metallic conductors) comes in roughly at
> 2/3 of the speed of light in vacuum, while the speed of light in air at see
> level is a mere 90 KM/s slower than in vacuum.
>
> > satellite communication involves signals traveling vast distances
> through space. This creates significant delays.
>
> [SM] Sure distances might be larger, but propagation speed is around
> 100000Km/s faster... my main point is speed of light is a) dependent on the
> medium b) not the things that differentiates space from the earth's surface
> here, but mere geometry and larger distances on larger spheres...
>
> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
> are susceptible to "drift" - gradually losing or gaining time. This drift,
> caused by factors like temperature variations, radiation exposure, and
> power fluctuations, can lead to inconsistencies in timekeeping across the
> network.
> > 3. Signal Degradation: As signals travel through space, they can degrade
> due to factors like atmospheric interference, ionospheric disturbances, and
> solar activity. This degradation can introduce noise and errors, impacting
> the accuracy of time synchronization messages.
> > 4. Limited Resources: Satellites have limited power and processing
> capabilities. Implementing complex synchronization protocols can be
> resource-intensive, requiring careful optimization to minimize their impact
> on other functionalities.
> > 5. Evolving Technologies: As satellite technologies and applications
> continue to evolve, new challenges related to synchronization might emerge.
> For example, the integration of constellations with thousands of satellites
> poses unique synchronization challenges due to the sheer scale and
> complexity of the network.
> > These challenges necessitate the development of robust and efficient
> time synchronization protocols for satellite networks and an integrated
> satellite and  terrestrial networks
> > Are you aware of such time synchronization protocols?
> > I would think that using Satellite simulators is the most viable way to
> develop and test these protocols given that using satellites is not that
> easy.
> > Thanks
> > Hesham
> >
> >
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>

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

Re: [Starlink] Time Synchronization in Satellite Networks

[Christian von der Ropp]

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

Why not acquire the time directly from by the satellite terminal and run local NTP servers instead of syncing via the Internet? LEO satellite terminals always have onboard GNSS antennas for geolocation which is necessary to find the satellites, so integrating a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.

Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net>:
>Hi Sebastian,
>Can we still use PTP and NTP for time synchronization in  Satellite
>networks or we need new protocols? If we need new protocols, do such
>protocols exist?
>
>Thanks
>Hesham
>
>On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Hesham
>>
>> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>> >
>> > Time synchronization, for satellite networks, faces several challenges:
>> > 1. Signal Propagation Delays: Unlike terrestrial networks where signals
>> travel through cables at the speed of light,
>>
>> [SM] The speed of light in your typical glas fibers (and accidentally the
>> information propagation speed in metallic conductors) comes in roughly at
>> 2/3 of the speed of light in vacuum, while the speed of light in air at see
>> level is a mere 90 KM/s slower than in vacuum.
>>
>> > satellite communication involves signals traveling vast distances
>> through space. This creates significant delays.
>>
>> [SM] Sure distances might be larger, but propagation speed is around
>> 100000Km/s faster... my main point is speed of light is a) dependent on the
>> medium b) not the things that differentiates space from the earth's surface
>> here, but mere geometry and larger distances on larger spheres...
>>
>> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
>> are susceptible to "drift" - gradually losing or gaining time. This drift,
>> caused by factors like temperature variations, radiation exposure, and
>> power fluctuations, can lead to inconsistencies in timekeeping across the
>> network.
>> > 3. Signal Degradation: As signals travel through space, they can degrade
>> due to factors like atmospheric interference, ionospheric disturbances, and
>> solar activity. This degradation can introduce noise and errors, impacting
>> the accuracy of time synchronization messages.
>> > 4. Limited Resources: Satellites have limited power and processing
>> capabilities. Implementing complex synchronization protocols can be
>> resource-intensive, requiring careful optimization to minimize their impact
>> on other functionalities.
>> > 5. Evolving Technologies: As satellite technologies and applications
>> continue to evolve, new challenges related to synchronization might emerge.
>> For example, the integration of constellations with thousands of satellites
>> poses unique synchronization challenges due to the sheer scale and
>> complexity of the network.
>> > These challenges necessitate the development of robust and efficient
>> time synchronization protocols for satellite networks and an integrated
>> satellite and  terrestrial networks
>> > Are you aware of such time synchronization protocols?
>> > I would think that using Satellite simulators is the most viable way to
>> develop and test these protocols given that using satellites is not that
>> easy.
>> > Thanks
>> > Hesham
>> >
>> >
>> >
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/starlink
>>
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: [Starlink] Time Synchronization in Satellite Networks

[Sebastian Moeller]

Hi Hesham,

caveat, this is far from my area of expertise, but I would simply try to get GPS/Glonass/Galileo antennas into the birds and have each sync their clock individually from such a source, which would remove the necessity for time synchronisation protocols. That said, I see neither PTP not NTP as suited, as both presumably assume that server and clients do not move to fast in relation to each other, while arbitrary members of a LEO constellation might have quite large relative speds, no?

Regards
	Sebastian

> On 2. Mar 2024, at 16:25, Hesham ElBakoury <helbakoury@gmail.com> wrote:
> 
> Hi Sebastian,
> Can we still use PTP and NTP for time synchronization in  Satellite networks or we need new protocols? If we need new protocols, do such protocols exist?
> 
> Thanks
> Hesham
> 
> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Hesham
> 
> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
> > 
> > Time synchronization, for satellite networks, faces several challenges:
> > 1. Signal Propagation Delays: Unlike terrestrial networks where signals travel through cables at the speed of light,
> 
> [SM] The speed of light in your typical glas fibers (and accidentally the information propagation speed in metallic conductors) comes in roughly at 2/3 of the speed of light in vacuum, while the speed of light in air at see level is a mere 90 KM/s slower than in vacuum. 
> 
> > satellite communication involves signals traveling vast distances through space. This creates significant delays.
> 
> [SM] Sure distances might be larger, but propagation speed is around 100000Km/s faster... my main point is speed of light is a) dependent on the medium b) not the things that differentiates space from the earth's surface here, but mere geometry and larger distances on larger spheres...
> 
> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites, are susceptible to "drift" - gradually losing or gaining time. This drift, caused by factors like temperature variations, radiation exposure, and power fluctuations, can lead to inconsistencies in timekeeping across the network.
> > 3. Signal Degradation: As signals travel through space, they can degrade due to factors like atmospheric interference, ionospheric disturbances, and solar activity. This degradation can introduce noise and errors, impacting the accuracy of time synchronization messages. 
> > 4. Limited Resources: Satellites have limited power and processing capabilities. Implementing complex synchronization protocols can be resource-intensive, requiring careful optimization to minimize their impact on other functionalities.
> > 5. Evolving Technologies: As satellite technologies and applications continue to evolve, new challenges related to synchronization might emerge. For example, the integration of constellations with thousands of satellites poses unique synchronization challenges due to the sheer scale and complexity of the network.
> > These challenges necessitate the development of robust and efficient time synchronization protocols for satellite networks and an integrated satellite and  terrestrial networks
> > Are you aware of such time synchronization protocols?
> > I would think that using Satellite simulators is the most viable way to develop and test these protocols given that using satellites is not that easy.
> > Thanks
> > Hesham
> > 
> > 
> > 
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> 

Re: [Starlink] Time Synchronization in Satellite Networks

[Hesham ElBakoury]

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

Hi Sebastian,
I agree with you that NTP and PTP are not suitable. We need new protocols.

Thanks
Hesham

On Sat, Mar 2, 2024, 7:45 AM Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Hesham,
>
> caveat, this is far from my area of expertise, but I would simply try to
> get GPS/Glonass/Galileo antennas into the birds and have each sync their
> clock individually from such a source, which would remove the necessity for
> time synchronisation protocols. That said, I see neither PTP not NTP as
> suited, as both presumably assume that server and clients do not move to
> fast in relation to each other, while arbitrary members of a LEO
> constellation might have quite large relative speds, no?
>
> Regards
>         Sebastian
>
> > On 2. Mar 2024, at 16:25, Hesham ElBakoury <helbakoury@gmail.com> wrote:
> >
> > Hi Sebastian,
> > Can we still use PTP and NTP for time synchronization in  Satellite
> networks or we need new protocols? If we need new protocols, do such
> protocols exist?
> >
> > Thanks
> > Hesham
> >
> > On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> > Hi Hesham
> >
> > > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> > >
> > > Time synchronization, for satellite networks, faces several challenges:
> > > 1. Signal Propagation Delays: Unlike terrestrial networks where
> signals travel through cables at the speed of light,
> >
> > [SM] The speed of light in your typical glas fibers (and accidentally
> the information propagation speed in metallic conductors) comes in roughly
> at 2/3 of the speed of light in vacuum, while the speed of light in air at
> see level is a mere 90 KM/s slower than in vacuum.
> >
> > > satellite communication involves signals traveling vast distances
> through space. This creates significant delays.
> >
> > [SM] Sure distances might be larger, but propagation speed is around
> 100000Km/s faster... my main point is speed of light is a) dependent on the
> medium b) not the things that differentiates space from the earth's surface
> here, but mere geometry and larger distances on larger spheres...
> >
> > > 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
> are susceptible to "drift" - gradually losing or gaining time. This drift,
> caused by factors like temperature variations, radiation exposure, and
> power fluctuations, can lead to inconsistencies in timekeeping across the
> network.
> > > 3. Signal Degradation: As signals travel through space, they can
> degrade due to factors like atmospheric interference, ionospheric
> disturbances, and solar activity. This degradation can introduce noise and
> errors, impacting the accuracy of time synchronization messages.
> > > 4. Limited Resources: Satellites have limited power and processing
> capabilities. Implementing complex synchronization protocols can be
> resource-intensive, requiring careful optimization to minimize their impact
> on other functionalities.
> > > 5. Evolving Technologies: As satellite technologies and applications
> continue to evolve, new challenges related to synchronization might emerge.
> For example, the integration of constellations with thousands of satellites
> poses unique synchronization challenges due to the sheer scale and
> complexity of the network.
> > > These challenges necessitate the development of robust and efficient
> time synchronization protocols for satellite networks and an integrated
> satellite and  terrestrial networks
> > > Are you aware of such time synchronization protocols?
> > > I would think that using Satellite simulators is the most viable way
> to develop and test these protocols given that using satellites is not that
> easy.
> > > Thanks
> > > Hesham
> > >
> > >
> > >
> > > _______________________________________________
> > > Starlink mailing list
> > > Starlink@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/starlink
> >
>
>

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

Re: [Starlink] Time Synchronization in Satellite Networks

[Hesham ElBakoury]

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

Hi Christian,
How you synchronize the time of the satellites in the network? Are you
saying each satellite has a master clock?

Hesham

On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net> wrote:

> Why not acquire the time directly from by the satellite terminal and run
> local NTP servers instead of syncing via the Internet? LEO satellite
> terminals always have onboard GNSS antennas for geolocation which is
> necessary to find the satellites, so integrating a local GNSS-disciplined
> Stratum-1 NTP server seems trivial to me.
>
>
> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <
> starlink@lists.bufferbloat.net>:
>
>> Hi Sebastian,
>> Can we still use PTP and NTP for time synchronization in  Satellite
>> networks or we need new protocols? If we need new protocols, do such
>> protocols exist?
>>
>> Thanks
>> Hesham
>>
>> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>>> Hi Hesham
>>>
>>> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>> >
>>> > Time synchronization, for satellite networks, faces several challenges:
>>> > 1. Signal Propagation Delays: Unlike terrestrial networks where
>>> signals travel through cables at the speed of light,
>>>
>>> [SM] The speed of light in your typical glas fibers (and accidentally
>>> the information propagation speed in metallic conductors) comes in roughly
>>> at 2/3 of the speed of light in vacuum, while the speed of light in air at
>>> see level is a mere 90 KM/s slower than in vacuum.
>>>
>>> > satellite communication involves signals traveling vast distances
>>> through space. This creates significant delays.
>>>
>>> [SM] Sure distances might be larger, but propagation speed is around
>>> 100000Km/s faster... my main point is speed of light is a) dependent on the
>>> medium b) not the things that differentiates space from the earth's surface
>>> here, but mere geometry and larger distances on larger spheres...
>>>
>>> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
>>> are susceptible to "drift" - gradually losing or gaining time. This drift,
>>> caused by factors like temperature variations, radiation exposure, and
>>> power fluctuations, can lead to inconsistencies in timekeeping across the
>>> network.
>>> > 3. Signal Degradation: As signals travel through space, they can
>>> degrade due to factors like atmospheric interference, ionospheric
>>> disturbances, and solar activity. This degradation can introduce noise and
>>> errors, impacting the accuracy of time synchronization messages.
>>> > 4. Limited Resources: Satellites have limited power and processing
>>> capabilities. Implementing complex synchronization protocols can be
>>> resource-intensive, requiring careful optimization to minimize their impact
>>> on other functionalities.
>>> > 5. Evolving Technologies: As satellite technologies and applications
>>> continue to evolve, new challenges related to synchronization might emerge.
>>> For example, the integration of constellations with thousands of satellites
>>> poses unique synchronization challenges due to the sheer scale and
>>> complexity of the network.
>>> > These challenges necessitate the development of robust and efficient
>>> time synchronization protocols for satellite networks and an integrated
>>> satellite and  terrestrial networks
>>> > Are you aware of such time synchronization protocols?
>>> > I would think that using Satellite simulators is the most viable way
>>> to develop and test these protocols given that using satellites is not that
>>> easy.
>>> > Thanks
>>> > Hesham
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Starlink mailing list
>>> > Starlink@lists.bufferbloat.net
>>> > https://lists.bufferbloat.net/listinfo/starlink
>>>
>>> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>

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

Re: [Starlink] Time Synchronization in Satellite Networks

[Christian von der Ropp]

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

Hi Hesham,

You do not acquire the time from a LEO satellite but directly from the GPS satellites which carry an atomic clock on board.
I'd not be aware of any LEO providing a GNSS signal but Xona plan such system (although not carrying proper atomic clocks but probably chip-sized atomic clocks that require frequent syncing with proper atomic clocks):
https://twitter.com/Megaconstellati/status/1708091536439673323

There are efforts to build trapped-ion quantum clocks that are expected to become significantly smaller and cheaper than traditional atomic clocks while as accurate which would make it viable to put an atomic clock-equivalent on small LEO satellites. Once that happens you would have an independent alternative to the big GNSS birds in MEO but with stronger signals. I'm told that we are 5-10 years away from such trapped-ion quantum clocks.

But for NTP clients, the described method (running a local NTP server in the satellite terminal synced to GPS) should be good enough.

Christian


Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <helbakoury@gmail.com>:
>Hi Christian,
>How you synchronize the time of the satellites in the network? Are you
>saying each satellite has a master clock?
>
>Hesham
>
>On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net> wrote:
>
>> Why not acquire the time directly from by the satellite terminal and run
>> local NTP servers instead of syncing via the Internet? LEO satellite
>> terminals always have onboard GNSS antennas for geolocation which is
>> necessary to find the satellites, so integrating a local GNSS-disciplined
>> Stratum-1 NTP server seems trivial to me.
>>
>>
>> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <
>> starlink@lists.bufferbloat.net>:
>>
>>> Hi Sebastian,
>>> Can we still use PTP and NTP for time synchronization in  Satellite
>>> networks or we need new protocols? If we need new protocols, do such
>>> protocols exist?
>>>
>>> Thanks
>>> Hesham
>>>
>>> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>>
>>>> Hi Hesham
>>>>
>>>> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>> >
>>>> > Time synchronization, for satellite networks, faces several challenges:
>>>> > 1. Signal Propagation Delays: Unlike terrestrial networks where
>>>> signals travel through cables at the speed of light,
>>>>
>>>> [SM] The speed of light in your typical glas fibers (and accidentally
>>>> the information propagation speed in metallic conductors) comes in roughly
>>>> at 2/3 of the speed of light in vacuum, while the speed of light in air at
>>>> see level is a mere 90 KM/s slower than in vacuum.
>>>>
>>>> > satellite communication involves signals traveling vast distances
>>>> through space. This creates significant delays.
>>>>
>>>> [SM] Sure distances might be larger, but propagation speed is around
>>>> 100000Km/s faster... my main point is speed of light is a) dependent on the
>>>> medium b) not the things that differentiates space from the earth's surface
>>>> here, but mere geometry and larger distances on larger spheres...
>>>>
>>>> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
>>>> are susceptible to "drift" - gradually losing or gaining time. This drift,
>>>> caused by factors like temperature variations, radiation exposure, and
>>>> power fluctuations, can lead to inconsistencies in timekeeping across the
>>>> network.
>>>> > 3. Signal Degradation: As signals travel through space, they can
>>>> degrade due to factors like atmospheric interference, ionospheric
>>>> disturbances, and solar activity. This degradation can introduce noise and
>>>> errors, impacting the accuracy of time synchronization messages.
>>>> > 4. Limited Resources: Satellites have limited power and processing
>>>> capabilities. Implementing complex synchronization protocols can be
>>>> resource-intensive, requiring careful optimization to minimize their impact
>>>> on other functionalities.
>>>> > 5. Evolving Technologies: As satellite technologies and applications
>>>> continue to evolve, new challenges related to synchronization might emerge.
>>>> For example, the integration of constellations with thousands of satellites
>>>> poses unique synchronization challenges due to the sheer scale and
>>>> complexity of the network.
>>>> > These challenges necessitate the development of robust and efficient
>>>> time synchronization protocols for satellite networks and an integrated
>>>> satellite and  terrestrial networks
>>>> > Are you aware of such time synchronization protocols?
>>>> > I would think that using Satellite simulators is the most viable way
>>>> to develop and test these protocols given that using satellites is not that
>>>> easy.
>>>> > Thanks
>>>> > Hesham
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Starlink mailing list
>>>> > Starlink@lists.bufferbloat.net
>>>> > https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>> gesendet.
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: [Starlink] Time Synchronization in Satellite Networks

[Alexandre Petrescu]

Le 02/03/2024 à 16:38, Christian von der Ropp via Starlink a écrit :
> Why not acquire the time directly from by the satellite terminal and 
> run local NTP servers instead of syncing via the Internet?

Certainly it is possible to run ntpd servers and clients on satellites 
and maintain synchronized times.  I would be surprised if some of them 
dont already do that.

The performance characteristics of some links between some satellites 
are not very different than links here on ground where NTP is run routinely.

NTP was designed and tested at a time when ground links had inferior 
perf. characteristics than many satcom links of recent years.

Alex


> LEO satellite terminals always have onboard GNSS antennas for 
> geolocation which is necessary to find the satellites, so integrating 
> a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.
>
>
> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink 
> <starlink@lists.bufferbloat.net>:
>
>     Hi Sebastian,
>     Can we still use PTP and NTP for time synchronization in 
>     Satellite networks or we need new protocols? If we need new
>     protocols, do such protocols exist?
>
>     Thanks
>     Hesham
>
>     On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de>
>     wrote:
>
>         Hi Hesham
>
>         > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink
>         <starlink@lists.bufferbloat.net> wrote:
>         >
>         > Time synchronization, for satellite networks, faces several
>         challenges:
>         > 1. Signal Propagation Delays: Unlike terrestrial networks
>         where signals travel through cables at the speed of light,
>
>         [SM] The speed of light in your typical glas fibers (and
>         accidentally the information propagation speed in metallic
>         conductors) comes in roughly at 2/3 of the speed of light in
>         vacuum, while the speed of light in air at see level is a mere
>         90 KM/s slower than in vacuum.
>
>         > satellite communication involves signals traveling vast
>         distances through space. This creates significant delays.
>
>         [SM] Sure distances might be larger, but propagation speed is
>         around 100000Km/s faster... my main point is speed of light is
>         a) dependent on the medium b) not the things that
>         differentiates space from the earth's surface here, but mere
>         geometry and larger distances on larger spheres...
>
>         > 2. Clock Drift: Even highly precise atomic clocks, used in
>         satellites, are susceptible to "drift" - gradually losing or
>         gaining time. This drift, caused by factors like temperature
>         variations, radiation exposure, and power fluctuations, can
>         lead to inconsistencies in timekeeping across the network.
>         > 3. Signal Degradation: As signals travel through space, they
>         can degrade due to factors like atmospheric interference,
>         ionospheric disturbances, and solar activity. This degradation
>         can introduce noise and errors, impacting the accuracy of time
>         synchronization messages.
>         > 4. Limited Resources: Satellites have limited power and
>         processing capabilities. Implementing complex synchronization
>         protocols can be resource-intensive, requiring careful
>         optimization to minimize their impact on other functionalities.
>         > 5. Evolving Technologies: As satellite technologies and
>         applications continue to evolve, new challenges related to
>         synchronization might emerge. For example, the integration of
>         constellations with thousands of satellites poses unique
>         synchronization challenges due to the sheer scale and
>         complexity of the network.
>         > These challenges necessitate the development of robust and
>         efficient time synchronization protocols for satellite
>         networks and an integrated satellite and terrestrial networks
>         > Are you aware of such time synchronization protocols?
>         > I would think that using Satellite simulators is the most
>         viable way to develop and test these protocols given that
>         using satellites is not that easy.
>         > Thanks
>         > Hesham
>         >
>         >
>         >
>         > _______________________________________________
>         > Starlink mailing list
>         > Starlink@lists.bufferbloat.net
>         > https://lists.bufferbloat.net/listinfo/starlink
>
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail 
> gesendet.
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Time Synchronization in Satellite Networks

[Alexandre Petrescu]

This is a 2nd time I do this here, but let me this time put it bluntly, 
and please excuse me if I am too direct.  This is not a reproach to 
anybody or anything, and I know this is current practice.  It is just 
that for me the practice is destabilizing.  Probably I am myself a 
little bit na3ive and I should probably upgrade to up to date practice.

That said, here it is:

     I run this text on a detector called GPTZero.  There are probably 
other detectors. The detector says that the text has a probability of 
97% of being AI-generated.

For my part, I had a doubt like that, and the tool seems to confirm my 
doubt.

I think the proper way (AI netiquette?) to answer generated text is to 
generate text.  But I will not do that.  I will reply separately with my 
human-typed text.

Sorry if I disturb anyone or anything(?)

Alex

Le 02/03/2024 à 16:03, Hesham ElBakoury via Starlink a écrit :
> Time synchronization, for satellite networks, faces several challenges:
>
> 1. Signal Propagation Delays: Unlike terrestrial networks where 
> signals travel through cables at the speed of light, satellite 
> communication involves signals traveling vast distances through space. 
> This creates significant delays.
>
> 2. Clock Drift: Even highly precise atomic clocks, used in satellites, 
> are susceptible to "drift" - gradually losing or gaining time. This 
> drift, caused by factors like temperature variations, radiation 
> exposure, and power fluctuations, can lead to inconsistencies in 
> timekeeping across the network.
>
> 3. Signal Degradation: As signals travel through space, they can 
> degrade due to factors like atmospheric interference, ionospheric 
> disturbances, and solar activity. This degradation can introduce noise 
> and errors, impacting the accuracy of time synchronization messages.
>

Re: [Starlink] Time Synchronization in Satellite Networks

[Alexandre Petrescu]

Le 02/03/2024 à 16:03, Hesham ElBakoury via Starlink a écrit :
> Time synchronization, for satellite networks, faces several challenges:
>
> 1. Signal Propagation Delays: Unlike terrestrial networks where 
> signals travel through cables at the speed of light, satellite 
> communication involves signals traveling vast distances through space. 
> This creates significant delays.
>
> 2. Clock Drift: Even highly precise atomic clocks, used in satellites, 
> are susceptible to "drift" - gradually losing or gaining time. This 
> drift, caused by factors like temperature variations, radiation 
> exposure, and power fluctuations, can lead to inconsistencies in 
> timekeeping across the network.
>
But, in a probably surprising way, it is GPS satellites at MEO altitudes 
with their higher-than-LEO latencies that calculate and provide accurate 
time on Earth.

Alex

> 3. Signal Degradation: As signals travel through space, they can 
> degrade due to factors like atmospheric interference, ionospheric 
> disturbances, and solar activity. This degradation can introduce noise 
> and errors, impacting the accuracy of time synchronization messages.
>
> 4. Limited Resources: Satellites have limited power and processing 
> capabilities. Implementing complex synchronization protocols can be 
> resource-intensive, requiring careful optimization to minimize their 
> impact on other functionalities.
>
> 5. Evolving Technologies: As satellite technologies and applications 
> continue to evolve, new challenges related to synchronization might 
> emerge. For example, the integration of constellations with thousands 
> of satellites poses unique synchronization challenges due to the sheer 
> scale and complexity of the network.
>
> These challenges necessitate the development of robust and efficient 
> time synchronization protocols for satellite networks and an 
> integrated satellite and  terrestrial networks
>
> Are you aware of such time synchronization protocols?
>
> I would think that using Satellite simulators is the most viable way 
> to develop and test these protocols given that using satellites is not 
> that easy.
>
> Thanks
>
> Hesham
>
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Time Synchronization in Satellite Networks

[Alexandre Petrescu]

some of the question is to what level of precision one wants the time to 
be maintained synchronized between entities, and for what application? 
Nano-second precision?  Less?  More is acceptable?  For what kind of 
application?  (I will not give examples).

I think links with hundred ms latency range and NTP can easily maintain 
nano-second synch'ed precision, from experience with ground links.


Le 02/03/2024 à 18:01, Alexandre Petrescu via Starlink a écrit :
>
> Le 02/03/2024 à 16:38, Christian von der Ropp via Starlink a écrit :
>> Why not acquire the time directly from by the satellite terminal and 
>> run local NTP servers instead of syncing via the Internet?
>
> Certainly it is possible to run ntpd servers and clients on satellites 
> and maintain synchronized times.  I would be surprised if some of them 
> dont already do that.
>
> The performance characteristics of some links between some satellites 
> are not very different than links here on ground where NTP is run 
> routinely.
>
> NTP was designed and tested at a time when ground links had inferior 
> perf. characteristics than many satcom links of recent years.
>
> Alex
>
>
>> LEO satellite terminals always have onboard GNSS antennas for 
>> geolocation which is necessary to find the satellites, so integrating 
>> a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.
>>
>>
>> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink 
>> <starlink@lists.bufferbloat.net>:
>>
>>     Hi Sebastian,
>>     Can we still use PTP and NTP for time synchronization in
>>     Satellite networks or we need new protocols? If we need new
>>     protocols, do such protocols exist?
>>
>>     Thanks
>>     Hesham
>>
>>     On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de>
>>     wrote:
>>
>>         Hi Hesham
>>
>>         > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink
>>         <starlink@lists.bufferbloat.net> wrote:
>>         >
>>         > Time synchronization, for satellite networks, faces several
>>         challenges:
>>         > 1. Signal Propagation Delays: Unlike terrestrial networks
>>         where signals travel through cables at the speed of light,
>>
>>         [SM] The speed of light in your typical glas fibers (and
>>         accidentally the information propagation speed in metallic
>>         conductors) comes in roughly at 2/3 of the speed of light in
>>         vacuum, while the speed of light in air at see level is a mere
>>         90 KM/s slower than in vacuum.
>>
>>         > satellite communication involves signals traveling vast
>>         distances through space. This creates significant delays.
>>
>>         [SM] Sure distances might be larger, but propagation speed is
>>         around 100000Km/s faster... my main point is speed of light is
>>         a) dependent on the medium b) not the things that
>>         differentiates space from the earth's surface here, but mere
>>         geometry and larger distances on larger spheres...
>>
>>         > 2. Clock Drift: Even highly precise atomic clocks, used in
>>         satellites, are susceptible to "drift" - gradually losing or
>>         gaining time. This drift, caused by factors like temperature
>>         variations, radiation exposure, and power fluctuations, can
>>         lead to inconsistencies in timekeeping across the network.
>>         > 3. Signal Degradation: As signals travel through space, they
>>         can degrade due to factors like atmospheric interference,
>>         ionospheric disturbances, and solar activity. This degradation
>>         can introduce noise and errors, impacting the accuracy of time
>>         synchronization messages.
>>         > 4. Limited Resources: Satellites have limited power and
>>         processing capabilities. Implementing complex synchronization
>>         protocols can be resource-intensive, requiring careful
>>         optimization to minimize their impact on other functionalities.
>>         > 5. Evolving Technologies: As satellite technologies and
>>         applications continue to evolve, new challenges related to
>>         synchronization might emerge. For example, the integration of
>>         constellations with thousands of satellites poses unique
>>         synchronization challenges due to the sheer scale and
>>         complexity of the network.
>>         > These challenges necessitate the development of robust and
>>         efficient time synchronization protocols for satellite
>>         networks and an integrated satellite and terrestrial networks
>>         > Are you aware of such time synchronization protocols?
>>         > I would think that using Satellite simulators is the most
>>         viable way to develop and test these protocols given that
>>         using satellites is not that easy.
>>         > Thanks
>>         > Hesham
>>         >
>>         >
>>         >
>>         > _______________________________________________
>>         > Starlink mailing list
>>         > Starlink@lists.bufferbloat.net
>>         > https://lists.bufferbloat.net/listinfo/starlink
>>
>> -- 
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail 
>> gesendet.
>>
>> _______________________________________________
>> 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] Time Synchronization in Satellite Networks

[Hesham ElBakoury]

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

But how you address the issues I mentioned before such propagation delay,
clock drifting, and signal degradation, ...

Hesham

On Sat, Mar 2, 2024, 9:18 AM Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:

> some of the question is to what level of precision one wants the time to
> be maintained synchronized between entities, and for what application?
> Nano-second precision?  Less?  More is acceptable?  For what kind of
> application?  (I will not give examples).
>
> I think links with hundred ms latency range and NTP can easily maintain
> nano-second synch'ed precision, from experience with ground links.
>
>
> Le 02/03/2024 à 18:01, Alexandre Petrescu via Starlink a écrit :
> >
> > Le 02/03/2024 à 16:38, Christian von der Ropp via Starlink a écrit :
> >> Why not acquire the time directly from by the satellite terminal and
> >> run local NTP servers instead of syncing via the Internet?
> >
> > Certainly it is possible to run ntpd servers and clients on satellites
> > and maintain synchronized times.  I would be surprised if some of them
> > dont already do that.
> >
> > The performance characteristics of some links between some satellites
> > are not very different than links here on ground where NTP is run
> > routinely.
> >
> > NTP was designed and tested at a time when ground links had inferior
> > perf. characteristics than many satcom links of recent years.
> >
> > Alex
> >
> >
> >> LEO satellite terminals always have onboard GNSS antennas for
> >> geolocation which is necessary to find the satellites, so integrating
> >> a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.
> >>
> >>
> >> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink
> >> <starlink@lists.bufferbloat.net>:
> >>
> >>     Hi Sebastian,
> >>     Can we still use PTP and NTP for time synchronization in
> >>     Satellite networks or we need new protocols? If we need new
> >>     protocols, do such protocols exist?
> >>
> >>     Thanks
> >>     Hesham
> >>
> >>     On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de>
> >>     wrote:
> >>
> >>         Hi Hesham
> >>
> >>         > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink
> >>         <starlink@lists.bufferbloat.net> wrote:
> >>         >
> >>         > Time synchronization, for satellite networks, faces several
> >>         challenges:
> >>         > 1. Signal Propagation Delays: Unlike terrestrial networks
> >>         where signals travel through cables at the speed of light,
> >>
> >>         [SM] The speed of light in your typical glas fibers (and
> >>         accidentally the information propagation speed in metallic
> >>         conductors) comes in roughly at 2/3 of the speed of light in
> >>         vacuum, while the speed of light in air at see level is a mere
> >>         90 KM/s slower than in vacuum.
> >>
> >>         > satellite communication involves signals traveling vast
> >>         distances through space. This creates significant delays.
> >>
> >>         [SM] Sure distances might be larger, but propagation speed is
> >>         around 100000Km/s faster... my main point is speed of light is
> >>         a) dependent on the medium b) not the things that
> >>         differentiates space from the earth's surface here, but mere
> >>         geometry and larger distances on larger spheres...
> >>
> >>         > 2. Clock Drift: Even highly precise atomic clocks, used in
> >>         satellites, are susceptible to "drift" - gradually losing or
> >>         gaining time. This drift, caused by factors like temperature
> >>         variations, radiation exposure, and power fluctuations, can
> >>         lead to inconsistencies in timekeeping across the network.
> >>         > 3. Signal Degradation: As signals travel through space, they
> >>         can degrade due to factors like atmospheric interference,
> >>         ionospheric disturbances, and solar activity. This degradation
> >>         can introduce noise and errors, impacting the accuracy of time
> >>         synchronization messages.
> >>         > 4. Limited Resources: Satellites have limited power and
> >>         processing capabilities. Implementing complex synchronization
> >>         protocols can be resource-intensive, requiring careful
> >>         optimization to minimize their impact on other functionalities.
> >>         > 5. Evolving Technologies: As satellite technologies and
> >>         applications continue to evolve, new challenges related to
> >>         synchronization might emerge. For example, the integration of
> >>         constellations with thousands of satellites poses unique
> >>         synchronization challenges due to the sheer scale and
> >>         complexity of the network.
> >>         > These challenges necessitate the development of robust and
> >>         efficient time synchronization protocols for satellite
> >>         networks and an integrated satellite and terrestrial networks
> >>         > Are you aware of such time synchronization protocols?
> >>         > I would think that using Satellite simulators is the most
> >>         viable way to develop and test these protocols given that
> >>         using satellites is not that easy.
> >>         > Thanks
> >>         > Hesham
> >>         >
> >>         >
> >>         >
> >>         > _______________________________________________
> >>         > Starlink mailing list
> >>         > Starlink@lists.bufferbloat.net
> >>         > https://lists.bufferbloat.net/listinfo/starlink
> >>
> >> --
> >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> >> gesendet.
> >>
> >> _______________________________________________
> >> 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: 8990 bytes --]

Re: [Starlink] Time Synchronization in Satellite Networks

[Alexandre Petrescu]

Le 02/03/2024 à 18:26, Hesham ElBakoury a écrit :
> But how you address the issues I mentioned before such propagation 
> delay, clock drifting, and signal degradation, ...

Propagation delay is what others call 'latency'.  I believe the current 
latencies in satcom links of many kinds allow for the use of NTP very 
well.  Clocks will sync with NTP in sats, but it depends of the 
synchronisation precision needed.

Wouldnt you think so?

(clock drifting -  if your source of information is an AI tool, then I 
suggest to find a way to feed back to the AI tool.  If possible, then I 
suggest to explain to AI tool how clocks work; clocks drift often when 
they travel very fast, much faster than how current sats travel, we talk 
about aproaching speed of light, and sats dont; other times clocks drift 
because of impurities in some of their hardware and stones - the sats 
have the same hardware as on ground, so they are subject to same drift 
as computers where current NTP is run; NTP actually _addresses_ that 
clock drifting; even the fanciest non-stone but Cesium 'atomic' clocks 
drift at some point, to a certain degree, on Earth - time is relative, 
time is a concept of humans, there is no time just a 'long now' someone 
said)

(signal degradation - signals dont degrade when they travel in space; 
they might degrade with distance, but much less so as when they travel a 
same distance on ground, be it on fiber)

(one asked two AI tools whether Beethoven met Liszt and one got 
contradictory answers).

Alex

>
> Hesham
>
> On Sat, Mar 2, 2024, 9:18 AM Alexandre Petrescu via Starlink 
> <starlink@lists.bufferbloat.net> wrote:
>
>     some of the question is to what level of precision one wants the
>     time to
>     be maintained synchronized between entities, and for what
>     application?
>     Nano-second precision?  Less?  More is acceptable?  For what kind of
>     application?  (I will not give examples).
>
>     I think links with hundred ms latency range and NTP can easily
>     maintain
>     nano-second synch'ed precision, from experience with ground links.
>
>
>     Le 02/03/2024 à 18:01, Alexandre Petrescu via Starlink a écrit :
>     >
>     > Le 02/03/2024 à 16:38, Christian von der Ropp via Starlink a écrit :
>     >> Why not acquire the time directly from by the satellite
>     terminal and
>     >> run local NTP servers instead of syncing via the Internet?
>     >
>     > Certainly it is possible to run ntpd servers and clients on
>     satellites
>     > and maintain synchronized times.  I would be surprised if some
>     of them
>     > dont already do that.
>     >
>     > The performance characteristics of some links between some
>     satellites
>     > are not very different than links here on ground where NTP is run
>     > routinely.
>     >
>     > NTP was designed and tested at a time when ground links had
>     inferior
>     > perf. characteristics than many satcom links of recent years.
>     >
>     > Alex
>     >
>     >
>     >> LEO satellite terminals always have onboard GNSS antennas for
>     >> geolocation which is necessary to find the satellites, so
>     integrating
>     >> a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.
>     >>
>     >>
>     >> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink
>     >> <starlink@lists.bufferbloat.net>:
>     >>
>     >>     Hi Sebastian,
>     >>     Can we still use PTP and NTP for time synchronization in
>     >>     Satellite networks or we need new protocols? If we need new
>     >>     protocols, do such protocols exist?
>     >>
>     >>     Thanks
>     >>     Hesham
>     >>
>     >>     On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller
>     <moeller0@gmx.de>
>     >>     wrote:
>     >>
>     >>         Hi Hesham
>     >>
>     >>         > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink
>     >>         <starlink@lists.bufferbloat.net> wrote:
>     >>         >
>     >>         > Time synchronization, for satellite networks, faces
>     several
>     >>         challenges:
>     >>         > 1. Signal Propagation Delays: Unlike terrestrial networks
>     >>         where signals travel through cables at the speed of light,
>     >>
>     >>         [SM] The speed of light in your typical glas fibers (and
>     >>         accidentally the information propagation speed in metallic
>     >>         conductors) comes in roughly at 2/3 of the speed of
>     light in
>     >>         vacuum, while the speed of light in air at see level is
>     a mere
>     >>         90 KM/s slower than in vacuum.
>     >>
>     >>         > satellite communication involves signals traveling vast
>     >>         distances through space. This creates significant delays.
>     >>
>     >>         [SM] Sure distances might be larger, but propagation
>     speed is
>     >>         around 100000Km/s faster... my main point is speed of
>     light is
>     >>         a) dependent on the medium b) not the things that
>     >>         differentiates space from the earth's surface here, but
>     mere
>     >>         geometry and larger distances on larger spheres...
>     >>
>     >>         > 2. Clock Drift: Even highly precise atomic clocks,
>     used in
>     >>         satellites, are susceptible to "drift" - gradually
>     losing or
>     >>         gaining time. This drift, caused by factors like
>     temperature
>     >>         variations, radiation exposure, and power fluctuations, can
>     >>         lead to inconsistencies in timekeeping across the network.
>     >>         > 3. Signal Degradation: As signals travel through
>     space, they
>     >>         can degrade due to factors like atmospheric interference,
>     >>         ionospheric disturbances, and solar activity. This
>     degradation
>     >>         can introduce noise and errors, impacting the accuracy
>     of time
>     >>         synchronization messages.
>     >>         > 4. Limited Resources: Satellites have limited power and
>     >>         processing capabilities. Implementing complex
>     synchronization
>     >>         protocols can be resource-intensive, requiring careful
>     >>         optimization to minimize their impact on other
>     functionalities.
>     >>         > 5. Evolving Technologies: As satellite technologies and
>     >>         applications continue to evolve, new challenges related to
>     >>         synchronization might emerge. For example, the
>     integration of
>     >>         constellations with thousands of satellites poses unique
>     >>         synchronization challenges due to the sheer scale and
>     >>         complexity of the network.
>     >>         > These challenges necessitate the development of
>     robust and
>     >>         efficient time synchronization protocols for satellite
>     >>         networks and an integrated satellite and terrestrial
>     networks
>     >>         > Are you aware of such time synchronization protocols?
>     >>         > I would think that using Satellite simulators is the most
>     >>         viable way to develop and test these protocols given that
>     >>         using satellites is not that easy.
>     >>         > Thanks
>     >>         > Hesham
>     >>         >
>     >>         >
>     >>         >
>     >>         > _______________________________________________
>     >>         > Starlink mailing list
>     >>         > Starlink@lists.bufferbloat.net
>     >>         > https://lists.bufferbloat.net/listinfo/starlink
>     >>
>     >> --
>     >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>     >> gesendet.
>     >>
>     >> _______________________________________________
>     >> 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
>

Re: [Starlink] Time Synchronization in Satellite Networks

[Hesham ElBakoury]

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

Hi Christian,
The problems is that Satellites move, therefore,  the delay between the
different directions is different which violates the condition to run NTP
and PTP.

Hesham

On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net> wrote:

> Hi Hesham,
>
> You do not acquire the time from a LEO satellite but directly from the GPS
> satellites which carry an atomic clock on board.
> I'd not be aware of any LEO providing a GNSS signal but Xona plan such
> system (although not carrying proper atomic clocks but probably chip-sized
> atomic clocks that require frequent syncing with proper atomic clocks):
> https://twitter.com/Megaconstellati/status/1708091536439673323
>
> There are efforts to build trapped-ion quantum clocks that are expected to
> become significantly smaller and cheaper than traditional atomic clocks
> while as accurate which would make it viable to put an atomic
> clock-equivalent on small LEO satellites. Once that happens you would have
> an independent alternative to the big GNSS birds in MEO but with stronger
> signals. I'm told that we are 5-10 years away from such trapped-ion quantum
> clocks.
>
> But for NTP clients, the described method (running a local NTP server in
> the satellite terminal synced to GPS) should be good enough.
>
> Christian
>
>
> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <
> helbakoury@gmail.com>:
>
>> Hi Christian,
>> How you synchronize the time of the satellites in the network? Are you
>> saying each satellite has a master clock?
>>
>> Hesham
>>
>> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net> wrote:
>>
>>> Why not acquire the time directly from by the satellite terminal and run
>>> local NTP servers instead of syncing via the Internet? LEO satellite
>>> terminals always have onboard GNSS antennas for geolocation which is
>>> necessary to find the satellites, so integrating a local GNSS-disciplined
>>> Stratum-1 NTP server seems trivial to me.
>>>
>>>
>>> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <
>>> starlink@lists.bufferbloat.net>:
>>>
>>>> Hi Sebastian,
>>>> Can we still use PTP and NTP for time synchronization in  Satellite
>>>> networks or we need new protocols? If we need new protocols, do such
>>>> protocols exist?
>>>>
>>>> Thanks
>>>> Hesham
>>>>
>>>> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>>>
>>>>> Hi Hesham
>>>>>
>>>>> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
>>>>> starlink@lists.bufferbloat.net> wrote:
>>>>> >
>>>>> > Time synchronization, for satellite networks, faces several
>>>>> challenges:
>>>>> > 1. Signal Propagation Delays: Unlike terrestrial networks where
>>>>> signals travel through cables at the speed of light,
>>>>>
>>>>> [SM] The speed of light in your typical glas fibers (and accidentally
>>>>> the information propagation speed in metallic conductors) comes in roughly
>>>>> at 2/3 of the speed of light in vacuum, while the speed of light in air at
>>>>> see level is a mere 90 KM/s slower than in vacuum.
>>>>>
>>>>> > satellite communication involves signals traveling vast distances
>>>>> through space. This creates significant delays.
>>>>>
>>>>> [SM] Sure distances might be larger, but propagation speed is around
>>>>> 100000Km/s faster... my main point is speed of light is a) dependent on the
>>>>> medium b) not the things that differentiates space from the earth's surface
>>>>> here, but mere geometry and larger distances on larger spheres...
>>>>>
>>>>> > 2. Clock Drift: Even highly precise atomic clocks, used in
>>>>> satellites, are susceptible to "drift" - gradually losing or gaining time.
>>>>> This drift, caused by factors like temperature variations, radiation
>>>>> exposure, and power fluctuations, can lead to inconsistencies in
>>>>> timekeeping across the network.
>>>>> > 3. Signal Degradation: As signals travel through space, they can
>>>>> degrade due to factors like atmospheric interference, ionospheric
>>>>> disturbances, and solar activity. This degradation can introduce noise and
>>>>> errors, impacting the accuracy of time synchronization messages.
>>>>> > 4. Limited Resources: Satellites have limited power and processing
>>>>> capabilities. Implementing complex synchronization protocols can be
>>>>> resource-intensive, requiring careful optimization to minimize their impact
>>>>> on other functionalities.
>>>>> > 5. Evolving Technologies: As satellite technologies and applications
>>>>> continue to evolve, new challenges related to synchronization might emerge.
>>>>> For example, the integration of constellations with thousands of satellites
>>>>> poses unique synchronization challenges due to the sheer scale and
>>>>> complexity of the network.
>>>>> > These challenges necessitate the development of robust and efficient
>>>>> time synchronization protocols for satellite networks and an integrated
>>>>> satellite and  terrestrial networks
>>>>> > Are you aware of such time synchronization protocols?
>>>>> > I would think that using Satellite simulators is the most viable way
>>>>> to develop and test these protocols given that using satellites is not that
>>>>> easy.
>>>>> > Thanks
>>>>> > Hesham
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > Starlink mailing list
>>>>> > Starlink@lists.bufferbloat.net
>>>>> > https://lists.bufferbloat.net/listinfo/starlink
>>>>>
>>>>> --
>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>> gesendet.
>>>
>> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>

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

Re: [Starlink] Time Synchronization in Satellite Networks

[Sebastian Moeller]

Hi Hesham,


> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury@gmail.com> wrote:
> 
> Hi Christian,
> The problems is that Satellites move, therefore,  the delay between the different directions is different which violates the condition to run NTP and PTP. 

But GPS Satellites themselves are not in geostationary oprbit, and still we can get precision time from them... so I would argue that must be a solved problem, no?

Regards
	Sebastian

> 
> Hesham
> 
> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net> wrote:
> Hi Hesham,
> 
> You do not acquire the time from a LEO satellite but directly from the GPS satellites which carry an atomic clock on board.
> I'd not be aware of any LEO providing a GNSS signal but Xona plan such system (although not carrying proper atomic clocks but probably chip-sized atomic clocks that require frequent syncing with proper atomic clocks):
> https://twitter.com/Megaconstellati/status/1708091536439673323
> 
> There are efforts to build trapped-ion quantum clocks that are expected to become significantly smaller and cheaper than traditional atomic clocks while as accurate which would make it viable to put an atomic clock-equivalent on small LEO satellites. Once that happens you would have an independent alternative to the big GNSS birds in MEO but with stronger signals. I'm told that we are 5-10 years away from such trapped-ion quantum clocks.
> 
> But for NTP clients, the described method (running a local NTP server in the satellite terminal synced to GPS) should be good enough.
> 
> Christian
> 
> 
> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <helbakoury@gmail.com>:
> Hi Christian,
> How you synchronize the time of the satellites in the network? Are you saying each satellite has a master clock?
> 
> Hesham
> 
> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net> wrote:
> Why not acquire the time directly from by the satellite terminal and run local NTP servers instead of syncing via the Internet? LEO satellite terminals always have onboard GNSS antennas for geolocation which is necessary to find the satellites, so integrating a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.
> 
> 
> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net>:
> Hi Sebastian,
> Can we still use PTP and NTP for time synchronization in  Satellite networks or we need new protocols? If we need new protocols, do such protocols exist?
> 
> Thanks
> Hesham
> 
> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Hesham
> 
> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
> > 
> > Time synchronization, for satellite networks, faces several challenges:
> > 1. Signal Propagation Delays: Unlike terrestrial networks where signals travel through cables at the speed of light,
> 
> [SM] The speed of light in your typical glas fibers (and accidentally the information propagation speed in metallic conductors) comes in roughly at 2/3 of the speed of light in vacuum, while the speed of light in air at see level is a mere 90 KM/s slower than in vacuum. 
> 
> > satellite communication involves signals traveling vast distances through space. This creates significant delays.
> 
> [SM] Sure distances might be larger, but propagation speed is around 100000Km/s faster... my main point is speed of light is a) dependent on the medium b) not the things that differentiates space from the earth's surface here, but mere geometry and larger distances on larger spheres...
> 
> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites, are susceptible to "drift" - gradually losing or gaining time. This drift, caused by factors like temperature variations, radiation exposure, and power fluctuations, can lead to inconsistencies in timekeeping across the network.
> > 3. Signal Degradation: As signals travel through space, they can degrade due to factors like atmospheric interference, ionospheric disturbances, and solar activity. This degradation can introduce noise and errors, impacting the accuracy of time synchronization messages. 
> > 4. Limited Resources: Satellites have limited power and processing capabilities. Implementing complex synchronization protocols can be resource-intensive, requiring careful optimization to minimize their impact on other functionalities.
> > 5. Evolving Technologies: As satellite technologies and applications continue to evolve, new challenges related to synchronization might emerge. For example, the integration of constellations with thousands of satellites poses unique synchronization challenges due to the sheer scale and complexity of the network.
> > These challenges necessitate the development of robust and efficient time synchronization protocols for satellite networks and an integrated satellite and  terrestrial networks
> > Are you aware of such time synchronization protocols?
> > I would think that using Satellite simulators is the most viable way to develop and test these protocols given that using satellites is not that easy.
> > Thanks
> > Hesham
> > 
> > 
> > 
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> 
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: [Starlink] Time Synchronization in Satellite Networks

[David Lang]

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

GPS satellites announce their orbit as well.

But NTP works pretty well in the face of changing path delays. Saying that 
Starlink and other LEO internet systems breaks them depends on the accuracy that 
you are looking for. yes the path length changes over the 15 min that you are on 
a satellite, but how much does it change?

Now, I really wish that Starlink would have the dish act as a NTP server based 
on it's GPS receiver, that would settle the issue.

David Lang


On Tue, 2 Apr 2024, Sebastian Moeller via Starlink wrote:

> Hi Hesham,
>
>
>> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury@gmail.com> wrote:
>> 
>> Hi Christian,
>> The problems is that Satellites move, therefore,  the delay between the different directions is different which violates the condition to run NTP and PTP. 
>
> But GPS Satellites themselves are not in geostationary oprbit, and still we can get precision time from them... so I would argue that must be a solved problem, no?
>
> Regards
> 	Sebastian
>
>> 
>> Hesham
>> 
>> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net> wrote:
>> Hi Hesham,
>> 
>> You do not acquire the time from a LEO satellite but directly from the GPS satellites which carry an atomic clock on board.
>> I'd not be aware of any LEO providing a GNSS signal but Xona plan such system (although not carrying proper atomic clocks but probably chip-sized atomic clocks that require frequent syncing with proper atomic clocks):
>> https://twitter.com/Megaconstellati/status/1708091536439673323
>> 
>> There are efforts to build trapped-ion quantum clocks that are expected to become significantly smaller and cheaper than traditional atomic clocks while as accurate which would make it viable to put an atomic clock-equivalent on small LEO satellites. Once that happens you would have an independent alternative to the big GNSS birds in MEO but with stronger signals. I'm told that we are 5-10 years away from such trapped-ion quantum clocks.
>> 
>> But for NTP clients, the described method (running a local NTP server in the satellite terminal synced to GPS) should be good enough.
>> 
>> Christian
>> 
>> 
>> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <helbakoury@gmail.com>:
>> Hi Christian,
>> How you synchronize the time of the satellites in the network? Are you saying each satellite has a master clock?
>> 
>> Hesham
>> 
>> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net> wrote:
>> Why not acquire the time directly from by the satellite terminal and run local NTP servers instead of syncing via the Internet? LEO satellite terminals always have onboard GNSS antennas for geolocation which is necessary to find the satellites, so integrating a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.
>> 
>> 
>> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net>:
>> Hi Sebastian,
>> Can we still use PTP and NTP for time synchronization in  Satellite networks or we need new protocols? If we need new protocols, do such protocols exist?
>> 
>> Thanks
>> Hesham
>> 
>> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Hesham
>> 
>> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
>> > 
>> > Time synchronization, for satellite networks, faces several challenges:
>> > 1. Signal Propagation Delays: Unlike terrestrial networks where signals travel through cables at the speed of light,
>> 
>> [SM] The speed of light in your typical glas fibers (and accidentally the information propagation speed in metallic conductors) comes in roughly at 2/3 of the speed of light in vacuum, while the speed of light in air at see level is a mere 90 KM/s slower than in vacuum. 
>> 
>> > satellite communication involves signals traveling vast distances through space. This creates significant delays.
>> 
>> [SM] Sure distances might be larger, but propagation speed is around 100000Km/s faster... my main point is speed of light is a) dependent on the medium b) not the things that differentiates space from the earth's surface here, but mere geometry and larger distances on larger spheres...
>> 
>> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites, are susceptible to "drift" - gradually losing or gaining time. This drift, caused by factors like temperature variations, radiation exposure, and power fluctuations, can lead to inconsistencies in timekeeping across the network.
>> > 3. Signal Degradation: As signals travel through space, they can degrade due to factors like atmospheric interference, ionospheric disturbances, and solar activity. This degradation can introduce noise and errors, impacting the accuracy of time synchronization messages. 
>> > 4. Limited Resources: Satellites have limited power and processing capabilities. Implementing complex synchronization protocols can be resource-intensive, requiring careful optimization to minimize their impact on other functionalities.
>> > 5. Evolving Technologies: As satellite technologies and applications continue to evolve, new challenges related to synchronization might emerge. For example, the integration of constellations with thousands of satellites poses unique synchronization challenges due to the sheer scale and complexity of the network.
>> > These challenges necessitate the development of robust and efficient time synchronization protocols for satellite networks and an integrated satellite and  terrestrial networks
>> > Are you aware of such time synchronization protocols?
>> > I would think that using Satellite simulators is the most viable way to develop and test these protocols given that using satellites is not that easy.
>> > Thanks
>> > Hesham
>> > 
>> > 
>> > 
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/starlink
>> 
>> -- 
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
>> -- 
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Time Synchronization in Satellite Networks

[J Pan]

starlink dish does advertise ".SpaceX.API.Device.GetTimeRequest time =
1037" in its latest grpc interface but "PermissionDenied" now. need to
convince starlink to be more open as well
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Mon, Apr 1, 2024 at 3:49 PM David Lang via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> GPS satellites announce their orbit as well.
>
> But NTP works pretty well in the face of changing path delays. Saying that
> Starlink and other LEO internet systems breaks them depends on the accuracy that
> you are looking for. yes the path length changes over the 15 min that you are on
> a satellite, but how much does it change?
>
> Now, I really wish that Starlink would have the dish act as a NTP server based
> on it's GPS receiver, that would settle the issue.
>
> David Lang
>
>
> On Tue, 2 Apr 2024, Sebastian Moeller via Starlink wrote:
>
> > Hi Hesham,
> >
> >
> >> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury@gmail.com> wrote:
> >>
> >> Hi Christian,
> >> The problems is that Satellites move, therefore,  the delay between the different directions is different which violates the condition to run NTP and PTP.
> >
> > But GPS Satellites themselves are not in geostationary oprbit, and still we can get precision time from them... so I would argue that must be a solved problem, no?
> >
> > Regards
> >       Sebastian
> >
> >>
> >> Hesham
> >>
> >> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net> wrote:
> >> Hi Hesham,
> >>
> >> You do not acquire the time from a LEO satellite but directly from the GPS satellites which carry an atomic clock on board.
> >> I'd not be aware of any LEO providing a GNSS signal but Xona plan such system (although not carrying proper atomic clocks but probably chip-sized atomic clocks that require frequent syncing with proper atomic clocks):
> >> https://twitter.com/Megaconstellati/status/1708091536439673323
> >>
> >> There are efforts to build trapped-ion quantum clocks that are expected to become significantly smaller and cheaper than traditional atomic clocks while as accurate which would make it viable to put an atomic clock-equivalent on small LEO satellites. Once that happens you would have an independent alternative to the big GNSS birds in MEO but with stronger signals. I'm told that we are 5-10 years away from such trapped-ion quantum clocks.
> >>
> >> But for NTP clients, the described method (running a local NTP server in the satellite terminal synced to GPS) should be good enough.
> >>
> >> Christian
> >>
> >>
> >> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <helbakoury@gmail.com>:
> >> Hi Christian,
> >> How you synchronize the time of the satellites in the network? Are you saying each satellite has a master clock?
> >>
> >> Hesham
> >>
> >> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net> wrote:
> >> Why not acquire the time directly from by the satellite terminal and run local NTP servers instead of syncing via the Internet? LEO satellite terminals always have onboard GNSS antennas for geolocation which is necessary to find the satellites, so integrating a local GNSS-disciplined Stratum-1 NTP server seems trivial to me.
> >>
> >>
> >> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net>:
> >> Hi Sebastian,
> >> Can we still use PTP and NTP for time synchronization in  Satellite networks or we need new protocols? If we need new protocols, do such protocols exist?
> >>
> >> Thanks
> >> Hesham
> >>
> >> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> >> Hi Hesham
> >>
> >> > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> wrote:
> >> >
> >> > Time synchronization, for satellite networks, faces several challenges:
> >> > 1. Signal Propagation Delays: Unlike terrestrial networks where signals travel through cables at the speed of light,
> >>
> >> [SM] The speed of light in your typical glas fibers (and accidentally the information propagation speed in metallic conductors) comes in roughly at 2/3 of the speed of light in vacuum, while the speed of light in air at see level is a mere 90 KM/s slower than in vacuum.
> >>
> >> > satellite communication involves signals traveling vast distances through space. This creates significant delays.
> >>
> >> [SM] Sure distances might be larger, but propagation speed is around 100000Km/s faster... my main point is speed of light is a) dependent on the medium b) not the things that differentiates space from the earth's surface here, but mere geometry and larger distances on larger spheres...
> >>
> >> > 2. Clock Drift: Even highly precise atomic clocks, used in satellites, are susceptible to "drift" - gradually losing or gaining time. This drift, caused by factors like temperature variations, radiation exposure, and power fluctuations, can lead to inconsistencies in timekeeping across the network.
> >> > 3. Signal Degradation: As signals travel through space, they can degrade due to factors like atmospheric interference, ionospheric disturbances, and solar activity. This degradation can introduce noise and errors, impacting the accuracy of time synchronization messages.
> >> > 4. Limited Resources: Satellites have limited power and processing capabilities. Implementing complex synchronization protocols can be resource-intensive, requiring careful optimization to minimize their impact on other functionalities.
> >> > 5. Evolving Technologies: As satellite technologies and applications continue to evolve, new challenges related to synchronization might emerge. For example, the integration of constellations with thousands of satellites poses unique synchronization challenges due to the sheer scale and complexity of the network.
> >> > These challenges necessitate the development of robust and efficient time synchronization protocols for satellite networks and an integrated satellite and  terrestrial networks
> >> > Are you aware of such time synchronization protocols?
> >> > I would think that using Satellite simulators is the most viable way to develop and test these protocols given that using satellites is not that easy.
> >> > Thanks
> >> > Hesham
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Starlink mailing list
> >> > Starlink@lists.bufferbloat.net
> >> > https://lists.bufferbloat.net/listinfo/starlink
> >>
> >> --
> >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
> >> --
> >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
> >
> > _______________________________________________
> > 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] Time Synchronization in Satellite Networks

[Hesham ElBakoury]

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

Time from GPS is a one way transmission from the satellites down. The
relative motion must be accounted for. It is called the Sagnac effect.

On Mon, Apr 1, 2024, 3:22 PM Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Hesham,
>
>
> > On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury@gmail.com> wrote:
> >
> > Hi Christian,
> > The problems is that Satellites move, therefore,  the delay between the
> different directions is different which violates the condition to run NTP
> and PTP.
>
> But GPS Satellites themselves are not in geostationary oprbit, and still
> we can get precision time from them... so I would argue that must be a
> solved problem, no?
>
> Regards
>         Sebastian
>
> >
> > Hesham
> >
> > On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net>
> wrote:
> > Hi Hesham,
> >
> > You do not acquire the time from a LEO satellite but directly from the
> GPS satellites which carry an atomic clock on board.
> > I'd not be aware of any LEO providing a GNSS signal but Xona plan such
> system (although not carrying proper atomic clocks but probably chip-sized
> atomic clocks that require frequent syncing with proper atomic clocks):
> > https://twitter.com/Megaconstellati/status/1708091536439673323
> >
> > There are efforts to build trapped-ion quantum clocks that are expected
> to become significantly smaller and cheaper than traditional atomic clocks
> while as accurate which would make it viable to put an atomic
> clock-equivalent on small LEO satellites. Once that happens you would have
> an independent alternative to the big GNSS birds in MEO but with stronger
> signals. I'm told that we are 5-10 years away from such trapped-ion quantum
> clocks.
> >
> > But for NTP clients, the described method (running a local NTP server in
> the satellite terminal synced to GPS) should be good enough.
> >
> > Christian
> >
> >
> > Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <
> helbakoury@gmail.com>:
> > Hi Christian,
> > How you synchronize the time of the satellites in the network? Are you
> saying each satellite has a master clock?
> >
> > Hesham
> >
> > On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net>
> wrote:
> > Why not acquire the time directly from by the satellite terminal and run
> local NTP servers instead of syncing via the Internet? LEO satellite
> terminals always have onboard GNSS antennas for geolocation which is
> necessary to find the satellites, so integrating a local GNSS-disciplined
> Stratum-1 NTP server seems trivial to me.
> >
> >
> > Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <
> starlink@lists.bufferbloat.net>:
> > Hi Sebastian,
> > Can we still use PTP and NTP for time synchronization in  Satellite
> networks or we need new protocols? If we need new protocols, do such
> protocols exist?
> >
> > Thanks
> > Hesham
> >
> > On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> > Hi Hesham
> >
> > > On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> > >
> > > Time synchronization, for satellite networks, faces several challenges:
> > > 1. Signal Propagation Delays: Unlike terrestrial networks where
> signals travel through cables at the speed of light,
> >
> > [SM] The speed of light in your typical glas fibers (and accidentally
> the information propagation speed in metallic conductors) comes in roughly
> at 2/3 of the speed of light in vacuum, while the speed of light in air at
> see level is a mere 90 KM/s slower than in vacuum.
> >
> > > satellite communication involves signals traveling vast distances
> through space. This creates significant delays.
> >
> > [SM] Sure distances might be larger, but propagation speed is around
> 100000Km/s faster... my main point is speed of light is a) dependent on the
> medium b) not the things that differentiates space from the earth's surface
> here, but mere geometry and larger distances on larger spheres...
> >
> > > 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
> are susceptible to "drift" - gradually losing or gaining time. This drift,
> caused by factors like temperature variations, radiation exposure, and
> power fluctuations, can lead to inconsistencies in timekeeping across the
> network.
> > > 3. Signal Degradation: As signals travel through space, they can
> degrade due to factors like atmospheric interference, ionospheric
> disturbances, and solar activity. This degradation can introduce noise and
> errors, impacting the accuracy of time synchronization messages.
> > > 4. Limited Resources: Satellites have limited power and processing
> capabilities. Implementing complex synchronization protocols can be
> resource-intensive, requiring careful optimization to minimize their impact
> on other functionalities.
> > > 5. Evolving Technologies: As satellite technologies and applications
> continue to evolve, new challenges related to synchronization might emerge.
> For example, the integration of constellations with thousands of satellites
> poses unique synchronization challenges due to the sheer scale and
> complexity of the network.
> > > These challenges necessitate the development of robust and efficient
> time synchronization protocols for satellite networks and an integrated
> satellite and  terrestrial networks
> > > Are you aware of such time synchronization protocols?
> > > I would think that using Satellite simulators is the most viable way
> to develop and test these protocols given that using satellites is not that
> easy.
> > > Thanks
> > > Hesham
> > >
> > >
> > >
> > > _______________________________________________
> > > Starlink mailing list
> > > Starlink@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/starlink
> >
> > --
> > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
> > --
> > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>

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

Re: [Starlink] Time Synchronization in Satellite Networks

[David Lang]

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

I don't think we are talking about relative motion (which would affect the radio 
frequency) but rather the fact that the time taken for the signal to get from 
the satellite to the ground station will vary depending on the distance between 
the satellite and the ground station, and that distance is changing, so you 
can't compensate for it as easily as you can a fixed path latency.

David Lang

On Mon, 1 Apr 2024, Hesham ElBakoury via Starlink wrote:

> Time from GPS is a one way transmission from the satellites down. The
> relative motion must be accounted for. It is called the Sagnac effect.
>
> On Mon, Apr 1, 2024, 3:22 PM Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Hesham,
>>
>>
>>> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury@gmail.com> wrote:
>>>
>>> Hi Christian,
>>> The problems is that Satellites move, therefore,  the delay between the
>> different directions is different which violates the condition to run NTP
>> and PTP.
>>
>> But GPS Satellites themselves are not in geostationary oprbit, and still
>> we can get precision time from them... so I would argue that must be a
>> solved problem, no?
>>
>> Regards
>>         Sebastian
>>
>>>
>>> Hesham
>>>
>>> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net>
>> wrote:
>>> Hi Hesham,
>>>
>>> You do not acquire the time from a LEO satellite but directly from the
>> GPS satellites which carry an atomic clock on board.
>>> I'd not be aware of any LEO providing a GNSS signal but Xona plan such
>> system (although not carrying proper atomic clocks but probably chip-sized
>> atomic clocks that require frequent syncing with proper atomic clocks):
>>> https://twitter.com/Megaconstellati/status/1708091536439673323
>>>
>>> There are efforts to build trapped-ion quantum clocks that are expected
>> to become significantly smaller and cheaper than traditional atomic clocks
>> while as accurate which would make it viable to put an atomic
>> clock-equivalent on small LEO satellites. Once that happens you would have
>> an independent alternative to the big GNSS birds in MEO but with stronger
>> signals. I'm told that we are 5-10 years away from such trapped-ion quantum
>> clocks.
>>>
>>> But for NTP clients, the described method (running a local NTP server in
>> the satellite terminal synced to GPS) should be good enough.
>>>
>>> Christian
>>>
>>>
>>> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <
>> helbakoury@gmail.com>:
>>> Hi Christian,
>>> How you synchronize the time of the satellites in the network? Are you
>> saying each satellite has a master clock?
>>>
>>> Hesham
>>>
>>> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net>
>> wrote:
>>> Why not acquire the time directly from by the satellite terminal and run
>> local NTP servers instead of syncing via the Internet? LEO satellite
>> terminals always have onboard GNSS antennas for geolocation which is
>> necessary to find the satellites, so integrating a local GNSS-disciplined
>> Stratum-1 NTP server seems trivial to me.
>>>
>>>
>>> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <
>> starlink@lists.bufferbloat.net>:
>>> Hi Sebastian,
>>> Can we still use PTP and NTP for time synchronization in  Satellite
>> networks or we need new protocols? If we need new protocols, do such
>> protocols exist?
>>>
>>> Thanks
>>> Hesham
>>>
>>> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>> Hi Hesham
>>>
>>>> On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Time synchronization, for satellite networks, faces several challenges:
>>>> 1. Signal Propagation Delays: Unlike terrestrial networks where
>> signals travel through cables at the speed of light,
>>>
>>> [SM] The speed of light in your typical glas fibers (and accidentally
>> the information propagation speed in metallic conductors) comes in roughly
>> at 2/3 of the speed of light in vacuum, while the speed of light in air at
>> see level is a mere 90 KM/s slower than in vacuum.
>>>
>>>> satellite communication involves signals traveling vast distances
>> through space. This creates significant delays.
>>>
>>> [SM] Sure distances might be larger, but propagation speed is around
>> 100000Km/s faster... my main point is speed of light is a) dependent on the
>> medium b) not the things that differentiates space from the earth's surface
>> here, but mere geometry and larger distances on larger spheres...
>>>
>>>> 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
>> are susceptible to "drift" - gradually losing or gaining time. This drift,
>> caused by factors like temperature variations, radiation exposure, and
>> power fluctuations, can lead to inconsistencies in timekeeping across the
>> network.
>>>> 3. Signal Degradation: As signals travel through space, they can
>> degrade due to factors like atmospheric interference, ionospheric
>> disturbances, and solar activity. This degradation can introduce noise and
>> errors, impacting the accuracy of time synchronization messages.
>>>> 4. Limited Resources: Satellites have limited power and processing
>> capabilities. Implementing complex synchronization protocols can be
>> resource-intensive, requiring careful optimization to minimize their impact
>> on other functionalities.
>>>> 5. Evolving Technologies: As satellite technologies and applications
>> continue to evolve, new challenges related to synchronization might emerge.
>> For example, the integration of constellations with thousands of satellites
>> poses unique synchronization challenges due to the sheer scale and
>> complexity of the network.
>>>> These challenges necessitate the development of robust and efficient
>> time synchronization protocols for satellite networks and an integrated
>> satellite and  terrestrial networks
>>>> Are you aware of such time synchronization protocols?
>>>> I would think that using Satellite simulators is the most viable way
>> to develop and test these protocols given that using satellites is not that
>> easy.
>>>> Thanks
>>>> Hesham
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>> --
>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>> gesendet.
>>> --
>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>> gesendet.
>>
>>
>

Re: [Starlink] Time Synchronization in Satellite Networks

[Vint Cerf]

[-- Attachment #1.1: Type: text/plain, Size: 7604 bytes --]

David is correct - this is why multiple exchanges and satellites are needed
to accurately synchronize and then determine location.
v


On Mon, Apr 1, 2024 at 8:34 PM David Lang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> I don't think we are talking about relative motion (which would affect the
> radio
> frequency) but rather the fact that the time taken for the signal to get
> from
> the satellite to the ground station will vary depending on the distance
> between
> the satellite and the ground station, and that distance is changing, so
> you
> can't compensate for it as easily as you can a fixed path latency.
>
> David Lang
>
> On Mon, 1 Apr 2024, Hesham ElBakoury via Starlink wrote:
>
> > Time from GPS is a one way transmission from the satellites down. The
> > relative motion must be accounted for. It is called the Sagnac effect.
> >
> > On Mon, Apr 1, 2024, 3:22 PM Sebastian Moeller <moeller0@gmx.de> wrote:
> >
> >> Hi Hesham,
> >>
> >>
> >>> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury@gmail.com>
> wrote:
> >>>
> >>> Hi Christian,
> >>> The problems is that Satellites move, therefore,  the delay between the
> >> different directions is different which violates the condition to run
> NTP
> >> and PTP.
> >>
> >> But GPS Satellites themselves are not in geostationary oprbit, and still
> >> we can get precision time from them... so I would argue that must be a
> >> solved problem, no?
> >>
> >> Regards
> >>         Sebastian
> >>
> >>>
> >>> Hesham
> >>>
> >>> On Sat, Mar 2, 2024, 8:19 AM Christian von der Ropp <cvdr@vdr.net>
> >> wrote:
> >>> Hi Hesham,
> >>>
> >>> You do not acquire the time from a LEO satellite but directly from the
> >> GPS satellites which carry an atomic clock on board.
> >>> I'd not be aware of any LEO providing a GNSS signal but Xona plan such
> >> system (although not carrying proper atomic clocks but probably
> chip-sized
> >> atomic clocks that require frequent syncing with proper atomic clocks):
> >>> https://twitter.com/Megaconstellati/status/1708091536439673323
> >>>
> >>> There are efforts to build trapped-ion quantum clocks that are expected
> >> to become significantly smaller and cheaper than traditional atomic
> clocks
> >> while as accurate which would make it viable to put an atomic
> >> clock-equivalent on small LEO satellites. Once that happens you would
> have
> >> an independent alternative to the big GNSS birds in MEO but with
> stronger
> >> signals. I'm told that we are 5-10 years away from such trapped-ion
> quantum
> >> clocks.
> >>>
> >>> But for NTP clients, the described method (running a local NTP server
> in
> >> the satellite terminal synced to GPS) should be good enough.
> >>>
> >>> Christian
> >>>
> >>>
> >>> Am 2. März 2024 18:02:47 OEZ schrieb Hesham ElBakoury <
> >> helbakoury@gmail.com>:
> >>> Hi Christian,
> >>> How you synchronize the time of the satellites in the network? Are you
> >> saying each satellite has a master clock?
> >>>
> >>> Hesham
> >>>
> >>> On Sat, Mar 2, 2024, 7:38 AM Christian von der Ropp <cvdr@vdr.net>
> >> wrote:
> >>> Why not acquire the time directly from by the satellite terminal and
> run
> >> local NTP servers instead of syncing via the Internet? LEO satellite
> >> terminals always have onboard GNSS antennas for geolocation which is
> >> necessary to find the satellites, so integrating a local
> GNSS-disciplined
> >> Stratum-1 NTP server seems trivial to me.
> >>>
> >>>
> >>> Am 2. März 2024 17:25:59 OEZ schrieb Hesham ElBakoury via Starlink <
> >> starlink@lists.bufferbloat.net>:
> >>> Hi Sebastian,
> >>> Can we still use PTP and NTP for time synchronization in  Satellite
> >> networks or we need new protocols? If we need new protocols, do such
> >> protocols exist?
> >>>
> >>> Thanks
> >>> Hesham
> >>>
> >>> On Sat, Mar 2, 2024, 7:18 AM Sebastian Moeller <moeller0@gmx.de>
> wrote:
> >>> Hi Hesham
> >>>
> >>>> On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
> >> starlink@lists.bufferbloat.net> wrote:
> >>>>
> >>>> Time synchronization, for satellite networks, faces several
> challenges:
> >>>> 1. Signal Propagation Delays: Unlike terrestrial networks where
> >> signals travel through cables at the speed of light,
> >>>
> >>> [SM] The speed of light in your typical glas fibers (and accidentally
> >> the information propagation speed in metallic conductors) comes in
> roughly
> >> at 2/3 of the speed of light in vacuum, while the speed of light in air
> at
> >> see level is a mere 90 KM/s slower than in vacuum.
> >>>
> >>>> satellite communication involves signals traveling vast distances
> >> through space. This creates significant delays.
> >>>
> >>> [SM] Sure distances might be larger, but propagation speed is around
> >> 100000Km/s faster... my main point is speed of light is a) dependent on
> the
> >> medium b) not the things that differentiates space from the earth's
> surface
> >> here, but mere geometry and larger distances on larger spheres...
> >>>
> >>>> 2. Clock Drift: Even highly precise atomic clocks, used in satellites,
> >> are susceptible to "drift" - gradually losing or gaining time. This
> drift,
> >> caused by factors like temperature variations, radiation exposure, and
> >> power fluctuations, can lead to inconsistencies in timekeeping across
> the
> >> network.
> >>>> 3. Signal Degradation: As signals travel through space, they can
> >> degrade due to factors like atmospheric interference, ionospheric
> >> disturbances, and solar activity. This degradation can introduce noise
> and
> >> errors, impacting the accuracy of time synchronization messages.
> >>>> 4. Limited Resources: Satellites have limited power and processing
> >> capabilities. Implementing complex synchronization protocols can be
> >> resource-intensive, requiring careful optimization to minimize their
> impact
> >> on other functionalities.
> >>>> 5. Evolving Technologies: As satellite technologies and applications
> >> continue to evolve, new challenges related to synchronization might
> emerge.
> >> For example, the integration of constellations with thousands of
> satellites
> >> poses unique synchronization challenges due to the sheer scale and
> >> complexity of the network.
> >>>> These challenges necessitate the development of robust and efficient
> >> time synchronization protocols for satellite networks and an integrated
> >> satellite and  terrestrial networks
> >>>> Are you aware of such time synchronization protocols?
> >>>> I would think that using Satellite simulators is the most viable way
> >> to develop and test these protocols given that using satellites is not
> that
> >> easy.
> >>>> Thanks
> >>>> Hesham
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Starlink mailing list
> >>>> Starlink@lists.bufferbloat.net
> >>>> https://lists.bufferbloat.net/listinfo/starlink
> >>>
> >>> --
> >>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> >> gesendet.
> >>> --
> >>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> >> gesendet.
> >>
> >>
> >_______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.2: Type: text/html, Size: 10570 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4006 bytes --]

Re: [Starlink] Time Synchronization in Satellite Networks

[J Pan]

accurate timing is useful for starlink itself, e.g.,
https://patents.justia.com/patent/11924821 and its users---hopefully
starlink can allow its dish to advertise the time besides location to
lan
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Tue, Apr 30, 2024 at 1:47 AM David Fernández via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> Dear Hesham,
>
> May I ask for what reason do you need the satellites to be synchronized in time? What application is requiring this? Earth observation? Then, go for GNSS-based time synchronization, as done by EO satellites in LEO: https://navi.ion.org/content/69/3/navi.531
>
> "GNSS signals could even be used for reliable navigation in lunar orbit", so also for time synchronization: https://www.nasa.gov/missions/tech-demonstration/nasa-navigation-tech-shows-timing-really-is-everything
>
> It seems that as long as your device can have a GNSS receiver, that's the best way to keep it time-synchronized. Is there anything preventing the use of GNSS on your intended application?
>
> https://lists.bufferbloat.net/pipermail/starlink/2024-March/002605.html
>
> Regards,
>
> David
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Time Synchronization in Satellite Networks

[David Fernández]

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

Dear Hesham,

May I ask for what reason do you need the satellites to be synchronized in
time? What application is requiring this? Earth observation? Then, go for
GNSS-based time synchronization, as done by EO satellites in LEO:
https://navi.ion.org/content/69/3/navi.531

"GNSS signals could even be used for reliable navigation in lunar orbit",
so also for time synchronization:
https://www.nasa.gov/missions/tech-demonstration/nasa-navigation-tech-shows-timing-really-is-everything

It seems that as long as your device can have a GNSS receiver, that's the
best way to keep it time-synchronized. Is there anything preventing the use
of GNSS on your intended application?

https://lists.bufferbloat.net/pipermail/starlink/2024-March/002605.html

Regards,

David

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