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

[Jorge Amodio <[e-mail]>]

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:
>
>    - Any solution should be extensible to any planetary body and not just
>    the moon (mentioned by Jorge).
>       - 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.
>    - Any protocols we develop should abide by international standards and
>    not a US Government mandate.
>       - 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.
>    - 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)
>    - Carsten has highlighted a draft CBOR standard
>    <https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/> defining
>    timescales/timesystems which could be used instead of the current version
>    of DTN Time in BPv7.
>       - Carsten also said that we would need to add these new time
>       systems to the registry of CBOR Timescales
>       <https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#timescales>.
>       (See also here
>       <https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-12.html#section-7.2>
>       .)
>    - 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
> <https://urldefense.us/v3/__https:/datatracker.ietf.org/doc/html/rfc9110*section-5.6.7__;Iw!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqCXrlGEmw$>
>
> > -----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/
> <https://urldefense.us/v3/__https:/datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqCT4VT9LA$>
> > >>
> > >> 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-
> <https://urldefense.us/v3/__https:/www.ietf.org/archive/id/draft-ietf-cbor-time-tag-__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqAMUA5dwg$>
> > 12.html#section-3.4
> > >> [3]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-
> <https://urldefense.us/v3/__https:/www.ietf.org/archive/id/draft-ietf-cbor-time-tag-__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqAMUA5dwg$>
> > 12.html#section-7.2
> > >> [4]: https://www.iana.org/assignments/cbor-tags/cbor-
> <https://urldefense.us/v3/__https:/www.iana.org/assignments/cbor-tags/cbor-__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqD8WYrsyw$>
> > 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
> <https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>
> > >>
> > >>
> > >> _______________________________________________
> > >> dtn mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/dtn
> <https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>
> > >
> > > _______________________________________________
> > > dtn mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dtn
> <https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> <https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!L3NcbmxrdRFdzgu8b5huVWk2ET0A1dNiP2nkhDNXnLWBHGX5n6K-aNmOedP_Hm7fyAvQfZyGIfT1Zx6RDqC7SlCQFw$>
>
>