[Starlink] Time Synchronization in Satellite Networks

Mon Apr 1 20:59:26 EDT 2024

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 at 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 at gmx.de> wrote:
> >
> >> Hi Hesham,
> >>
> >>
> >>> On 2. Apr 2024, at 00:04, Hesham ElBakoury <helbakoury at 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 at 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 at 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 at 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 at 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 at gmx.de>
> wrote:
> >>> Hi Hesham
> >>>
> >>>> On 2. Mar 2024, at 16:03, Hesham ElBakoury via Starlink <
> >> starlink at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240401/167d8b5e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4006 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240401/167d8b5e/attachment.bin>