Re: [Cbor] [dtn] [EXTERNAL] Re: [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")

[[e-mail]]

Hi All,

So practically then, we have two different classes of devices:  those that 
can rely on a single unchanging time reference (UTC on Earth or LTC on the 
Moon) and those that need the ability to process multiple time references.

For those devices for which a single time reference is required, it can be 
assumed that there are not generally the delay tolerant challenges that 
face those that require multiple time references. As a result, these 
devices can use IP locally, which allows them to have less robust clocks, 
as they can be periodically synced to a local high quality time source 
like an atomic clock.  For these devices, timekeeping will be easy; 
ntpdate (or similar) can be run from a cron job (or similar) to update the 
devices clock.  I would consider, at first glance, Richard's devices to 
fall in this category, although it is also likely that many of these 
devices, including Richard's, will speak BP/IP using one of the many 
available CLA implementations, or BP alone over different channels. 
Given that fact, it may be useful to have a similar application of BP 
which performs a ntp-like function.

Those devices requiring switching between multiple time references need a 
bit more thought.  We can precompute the skew introduced by lower lunar 
gravity, as well as precompute the skew from high velocity motion. 
Perhaps that can be the delta between two measures from two different 
frames of reference, as themselves referenced to start of epoch.  That 
delta can be known for any time at any point on the two timelines, as it 
is a function of a linear skew/second over x number of seconds; a 
reasonably easy calculation to program as well.  This works well for 
stable time references (Earth or Lunar surface) as they do not change. 
When devices like the Gateway are considered, we have to recognize that 
it's flow of time itself will be generally unstable, but unstable in a 
reasonably stable pattern, as it accelerates, decelerates, and is subject 
to two different gravity wells effecting it's flow.  In this unique case, 
it may be wise to maintain state on both UTC and LTC, while also including 
a high quality clock onboard.

As we expand beyond our present ambitions, it is likely that a series of 
high quality clocks are deployed at various Lagrange points, as this 
should provide the most stable local time reference for a relay network, 
but lets solve the immediate problems first, while checking them against 
compatibility with future events of high likelihood.

Thanks,
ScottJ


On Fri, 12 Apr 2024, Jorge Amodio wrote:

> 
> Great summary Richard,
> 
> Just one quick comment, I'm not buying 100% that spacecraft's internal
> clocks will have to run exclusively on LTC, that is a very "localized"
> concept.
> 
> We will have spacecraft (well we already landed the first one after 52 years
> ;-) that will initially have to operate on Earth before launch, after
> separation from the LV they will be in transition from LEO to whatever
> trajectory is designed for that mission, in some cases that might include
> multiple orbits around Earth, in the particular case of a Moon mission we
> will get into LTI, and then reach the distance for LOI, then there are many
> variants of Lunar orbits.
> 
> Some spacecraft, like satellites in a Lunar Constellation with various
> different orbits will remain there, other spacecraft will transition to LLO
> and then land on the Moon, until then LTC will not be a good clock
> reference, even for comms after landing we will have to evaluate our DTE
> opportunities based on timing from the ground stations, etc., tables with
> predicted times for contact will be preloaded using UTC as a reference.
> 
> Now, once on the Moon's surface, for *applications* or particular *services*
> we will have to be able to support LTC, then the conversion is the other way
> around.
> 
> Plus, in a not very distant future, following the work being done on the
> idea of Moon-2-Mars, we may have spacecraft that after landing on the Moon
> may be launched from there to for example Mars, so LTC as the "internal"
> clock is not good :-)
> 
> Regards
> Jorge
> 
> 
> On Fri, Apr 12, 2024 at 12:05 PM Rieber, Richard R (US 347R)
> <[e-mail]> wrote:
>
>       Hello all,
>
>        
>
>       Thanks for a great thread! Let me summarize what I’ve heard:
>
>        o  Any solution should be extensible to any planetary body and
>           not just the moon (mentioned by Jorge).
>            o  Note that the White House’s memorandum specifically says
>               to develop a time system that is extensible to any body,
>               but the impetus and first time system will be LTC.
>        o  Any protocols we develop should abide by international
>           standards and not a US Government mandate.
>            o  For this, I 100% agree. Note that the memorandum
>               specifically states that LTC should be developed within
>               the current international standards framework. As such,
>               I think that LTC (and other planetary time systems) will
>               become a standard rather than a local US thing.
>        o  DTN Time using UTC is OK for now. (I agree, and so does John
>           Dowdell on ESA’s Moonlight mission, Jorge Amodio, and Scott
>           Burleigh)
>        o  Carsten has highlighted a draft CBOR standard defining
>           timescales/timesystems which could be used instead of the
>           current version of DTN Time in BPv7.
>            o  Carsten also said that we would need to add these new
>               time systems to the registry of CBOR Timescales. (See
>               also here.)
>        o  Brian Sipos highlighted that multiple time systems on the
>           network would create a burden on lower-level processing (and
>           I agree)
>
>        
>
>       With the thread summarized, I want to chime in a bit more. First
>       off, I’m a systems engineer, so I’m always thinking about how
>       things interact with each other. Lunar spacecraft internal
>       clocks may operate exclusively within the LTC time system. For
>       those spacecraft needing to communicate with BP, they would have
>       to convert the current LTC to UTC to populate the DTN Time
>       field. However, this time conversion is unnecessary if the
>       communication network is exclusively lunar (think communications
>       around the Artemis Base Camp). The only time we’d need to worry
>       about time conversion is bundles that flow between planetary
>       bodies. So Brian, your argument about creating lower-level
>       processing burden may be true regardless.
>
>        
>
>       Additionally, the operations could become problematic and
>       confusion if UTC is used in the bundle header for data
>       originating from a lunar spacecraft. Events are happening on the
>       moon in the LTC time system, then are reported in data that is
>       stamped with UTC. Operators could quickly be confused when
>       trying to correlate lunar-based events using data stamped in
>       UTC.
>
>        
>
>       Does anyone think we should tweak the DTN Time field to utilize
>       the CBOR Timescale/Timesystem standard Carsten mentioned? I
>       think we should. If so, we need to have a thought session on how
>       the functions for timer/duration/contact graphs/bundle status
>       reports should be tweaked to support different time systems.
>
>        
>
>       ~Rich
>
>        
>
>       From: Jorge Amodio <[e-mail]>
>       Date: Friday, April 12, 2024 at 08:55
>       To: [e-mail] <[e-mail]>
>       Cc: EXTERNAL-Sipos, Brian J (US 9300-Affiliate)
>       <[e-mail]>, John Dowdell
>       <[e-mail]>, Carsten Bormann <[e-mail]>,
>       Rieber, Richard R (US 347R) <[e-mail]>, DTN
>       WG <[e-mail]>, [e-mail] <[e-mail]>
>       Subject: [EXTERNAL] Re: [dtn] [EXT] Re: LTC timescale (Re:
>       Question regarding RFC 9171 - How to incorporate "Coordinated
>       Lunar Time")
> 
>  
> 
> 100% Agreement.
> 
>  
> 
> PNT is a completely different challenge and not only will it require
> precision timing, we still need to have an international standard for
> a lunar coordinate system which is currently under discussion.
> 
>  
> 
> One small note, space exploration is not longer confined to NASA,
> Roscosmos, nowadays ESA, JAXA, ISRO, CNSA, etc, are catching up and
> moving at a fast pace, so even when NASA has a mandate and has a
> leadership position, the "Club" now has now many more members. For
> example LNIS is not a NASA product but a collaboration between many
> space agencies and now also the commercial sector, so the standards
> development process will need to be broader and inclusive.
> 
>  
> 
> There is some standards related work being discussed at other forums
> like LSIC, LOGIC, etc.
> 
>  
> 
> It will get more complicated but with more fun .., and paperwork :-)
> 
>  
> 
> Regards
> 
> Jorge
> 
>  
> 
>  
> 
> On Fri, Apr 12, 2024 at 10:41 AM <[e-mail]> wrote:
>
>       This sounds right to me.
>
>       A general solution to the problem of coordinating
>       planetary timescales is going to be needed to support
>       accurate spacecraft position, navigation, and timing
>       considerations, which have got to be accurate to small
>       fractions of seconds.
>
>       But for bundle protocol operations the requirement is less
>       urgent.  "DTN time" is used as the basis for bundle
>       identification (together with a counter, for use when
>       multiple bundles are issued per second), for bundle
>       expiration decisions, for reporting on the occurrence of
>       bundle processing events (in optional bundle status
>       reports), for starting and stopping bundle transmission
>       and reception per published contact plans, for initiating
>       scheduled network management directives, and potentially
>       for other operational purposes.  None of these purposes
>       require universal clock alignment at sub-second
>       granularity.  It could be argued that clock inaccuracies
>       on the order of several seconds would not seriously
>       degrade the operation of the network.
>
>       The articulation and implementation of LTC is going to be
>       vital in general for operating in planetary space over the
>       coming decades, but for DTN specifically I think we are
>       going to be okay with DTN time as currently defined.
>
>       Scott
>
>       -----Original Message-----
>       From: dtn <[e-mail]> On Behalf Of Sipos, Brian
>       J.
>       Sent: Friday, April 12, 2024 5:57 AM
>       To: Jorge Amodio <[e-mail]>; John Dowdell
>       <[e-mail]>
>       Cc: Carsten Bormann <[e-mail]>; Rieber, Richard R (US
>       347R) <richard.r.rieber=[e-mail]>;
>       DTN WG <[e-mail]>; [e-mail]
>       Subject: Re: [dtn] [EXT] Re: LTC timescale (Re: Question
>       regarding RFC 9171 - How to incorporate "Coordinated Lunar
>       Time")
>
>       Richard,
>       While there are mechanisms to use alternative time scales
>       in CBOR in ways that would be backward (but not forward)
>       compatible, I agree with Jorge's rationale that "a
>       network" and a networking layer should use a consistent
>       time scale. This is similar to how early internet
>       protocols (e.g. SNMP and pre-1.0 HTTP) allowed use of
>       alternative time zones but modern versions disallow all
>       but UTC-representing timestamps (e.g.  HTTP's Date format
>       [1]) because it adds unnecessary burden onto the
>       lower-level processing that should be a higher-level
>       concern.
>
>       [1]
>       https://datatracker.ietf.org/doc/html/rfc9110#section-5.6.7
>
>       > -----Original Message-----
>       > From: dtn <[e-mail]> On Behalf Of Jorge
>       Amodio
>       > Sent: Friday, April 12, 2024 6:25 AM
>       > To: John Dowdell <[e-mail]>
>       > Cc: Carsten Bormann <[e-mail]>; Rieber, Richard R
>       (US 347R)
>       > <richard.r.rieber=[e-mail]>; DTN WG
>       > <[e-mail]>; [e-mail]
>       > Subject: [EXT] Re: [dtn] LTC timescale (Re: Question
>       regarding RFC
>       > 9171 - How to incorporate "Coordinated Lunar Time")
>       >
>       > APL external email warning: Verify sender
>       [e-mail]
>       > before clicking links or attachments
>       >
>       >
>       > I believe that for the time being until an international
>       standard not
>       > a government mandate is fully developed, implemented,
>       tested and
>       > accepted we will have to stick with UTC.
>       >
>       > Also, location based time systems should in the long
>       term be defined
>       > on a planetary basis, not only for the Moon, which
>       brings again the
>       > question of developing an international standard that
>       goes beyond the cislunar space.
>       >
>       > But still we will always need a common system of
>       reference for the
>       > whole interplanetary network, and so far for now UTC is
>       the most reasonable answer.
>       >
>       > On a planetary basis such as the Moon, for those
>       applications that
>       > require a local time system of reference we will have to
>       figure how we
>       > convert from/to UTC, but at the *application* level,
>       IMHO for comms
>       > and networking we should stick with UTC.
>       >
>       > My .02
>       >
>       > Regards
>       > -Jorge
>       >
>       > > On Apr 12, 2024, at 04:42, John Dowdell
>       > > <[e-mail]>
>       > wrote:
>       > >
>       > > Hi Carsten and Richard
>       > >
>       > > As a comms engineer working on ESA Moonlight, I’m also
>       interested in
>       > resolving this. Given timescales, I guess we’ll end up
>       going with UTC
>       > even on the moon, but in the longer term there is a need
>       for a standards-based resolution.
>       > >
>       > > - John
>       > >
>       > >> On 12 Apr 2024, at 06:58, Carsten Bormann
>       <[e-mail]> wrote:
>       > >>
>       > >> Hi Richard,
>       > >>
>       > >> I read your message with interest.
>       > >>
>       > >> draft-ietf-cbor-time-tag [1], an approved
>       specification that is
>       > >> currently in the
>       > RFC editor queue for publication as an RFC, defines a
>       versatile
>       > representation of timestamps in CBOR.
>       > >> While DTN BP does not directly use this extended time
>       tag
>       > >> currently, I would
>       > imagine that any evolution of its time representations
>       would
>       > coordinate to maintain interoperability with the
>       extended time tag.
>       > >>
>       > >> [1]:
>       https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/
>       > >>
>       > >> The extended time tag defines a way to indicate the
>       timescale in use [2].
>       > >> This is based on a IANA registry [3] that is
>       currently just listing
>       > >> UTC and TAI
>       > [4].
>       > >>
>       > >> [2]:
>       https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-
>       > 12.html#section-3.4
>       > >> [3]:
>       https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-
>       > 12.html#section-7.2
>       > >> [4]: https://www.iana.org/assignments/cbor-tags/cbor-
>       > tags.xhtml#timescales
>       > >>
>       > >> I would expect that LTC should be added to this
>       registry, and that
>       > >> a short
>       > specification could provide information about how this
>       is to be used
>       > and how this timescale interoperates with the existing
>       ones.
>       > >>
>       > >> Grüße, Carsten
>       > >>
>       > >>
>       > >>>> On 12. Apr 2024, at 06:46, Rieber, Richard R (US
>       347R)
>       > <richard.r.rieber=[e-mail]> wrote:
>       > >>>
>       > >>> Hello DTN leads,
>       > >>> I am a DTN advocate at JPL and working as the
>       Mission Operations
>       > >>> Systems
>       > Engineer on the CADRE mission. This mission is slated to
>       send 3
>       > shoe-box sized rovers to the moon on Intuitive Machine’s
>       IM-3 lander
>       > in Q1 2025. Needless to say, I’m paying attention to all
>       things moon-related and DTN-related.
>       > >>> There are two things I want to highlight:
>       > >>>   • NASA’s SCaN office has released the LunaNet
>       Interoperability
>       > specification, which mandates the use of DTN for
>       communications in
>       > Feb. 2023, and
>       > >>>   • On 4/2/2024, the White House has tasked NASA
>       with developing a
>       > “Coordinated Lunar Time”, amongst other planetary time
>       systems.
>       > >>> BP’s DTN Time (see 4.2.6 of RFC-9171) is defined as
>       milliseconds
>       > >>> since 2000-
>       > 001T00:00:00 UTC. How should this change if there is a
>       lunar time system?
>       > >>> I would imagine that Lunar spacecraft use LTC for
>       their internal
>       > >>> clocks. How
>       > do they interpret bundles sent from Earth that are
>       stamped with UTC?
>       > Must they internally convert the current LTC to UTC to
>       compare to that
>       > bundle’s DTN Time? Similarly, what time system is used
>       in the DTN Time
>       > field for bundles created by a lunar spacecraft?
>       > >>> Now imagine the Artemis Gateway that may act as a
>       communication
>       > >>> relay
>       > node. Some bundles would be from Earth and tagged with
>       UTC. Some
>       > bundles would be from the moon and may be tagged in LTC.
>       This gets quite confusing.
>       > >>> Needless to say, I think the DTN community needs to
>       have a
>       > >>> conversation
>       > about if and how the protocol must be modified to
>       support different
>       > time systems across the solar system. What’s the venue
>       for having that conversation?
>       > How would one go about proposing a protocol
>       modification?
>       > >>> Thanks in advance,
>       > >>> ~Rich
>       > >>>  Richard Rieber
>       > >>> NASA/JPL
>       > >>> Robotics Systems Engineer
>       > >>> 347R – Robotics Operations and V&V
>       [e-mail]
>       > >>> [phone]
>       > >>> _______________________________________________
>       > >>> dtn mailing list
>       > >>> [e-mail]
>       > >>> https://www.ietf.org/mailman/listinfo/dtn
>       > >>
>       > >>
>       > >> _______________________________________________
>       > >> dtn mailing list
>       > >> [e-mail]
>       > >> https://www.ietf.org/mailman/listinfo/dtn
>       > >
>       > > _______________________________________________
>       > > dtn mailing list
>       > > [e-mail]
>       > > https://www.ietf.org/mailman/listinfo/dtn
>       >
>       > _______________________________________________
>       > dtn mailing list
>       > [e-mail]
>       > https://www.ietf.org/mailman/listinfo/dtn
> 
> 
>