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

["Anderson, Benjamin F. (GSFC-4502)" <[e-mail]>]

Hi all,

Here are a few thoughts from Cheryl Gramling at Goddard Space Flight Center on this topic. She’s leading the LTC effort:



1.            There are several Use Cases we need to work out when it comes to xTC vs UTC, where x is a body other than Earth, with LTC being the lunar body.  In general, the idea is that comms with Earth need to be identified in UTC, butfor ops around/on the Moon that do not need to involve Earth, and for precision applications or applications with a continuous accurate representation, these would use LTC.  In general, being able to identify information in two time systems (or more?) will be needed, in a similar manner to how we use UTC and Spacecraft (or Mission) Time currently.



2.            Jorge is correct – this is US policy. We still have to work this internationally and organizations like BIPM and IAU will define the standards to be used by all (universal standards, hahahaha)

Thanks,
Ben

----------------------------------------------------------------------------------------------------------
Ben Anderson

[cid:image001.png@01DA8F03.77E8CBB0]
Ground Segment Mission Manager
LuGRE Mission Manager
DTN Enterprise Lead
GSFC LuCCI Project Lead

Technology Enterprise and Mission Pathfinder Office (TEMPO), Code 450.2
Exploration and Space Communications Projects Division
NASA Goddard Space Flight Center
[e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------------------------------------------

From: dtn <[e-mail]> On Behalf Of Jorge Amodio
Sent: Friday, April 12, 2024 11:54 AM
To: [e-mail]
Cc: Sipos, Brian (JPL-9300)[John Hopkins University Applied Physics Lab] <[e-mail]>; John Dowdell <[e-mail]>; Carsten Bormann <[e-mail]>; Rieber, Richard R (US 347R) <richard.r.rieber=[e-mail]>; DTN WG <[e-mail]>; [e-mail]
Subject: [EXTERNAL] [BULK] Re: [dtn] [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.



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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Sipos, Brian J.
Sent: Friday, April 12, 2024 5:57 AM
To: Jorge Amodio <[e-mail]<mailto:[e-mail]>>; John Dowdell <[e-mail]<mailto:[e-mail]>>
Cc: Carsten Bormann <[e-mail]<mailto:[e-mail]>>; Rieber, Richard R (US 347R) <richard.r.rieber=[e-mail]<mailto:[e-mail]>>; DTN WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Jorge Amodio
> Sent: Friday, April 12, 2024 6:25 AM
> To: John Dowdell <[e-mail]<mailto:[e-mail]>>
> Cc: Carsten Bormann <[e-mail]<mailto:[e-mail]>>; Rieber, Richard R (US 347R)
> <richard.r.rieber=[e-mail]<mailto:[e-mail]>>; DTN WG
> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> >>> [phone]
> >>> _______________________________________________
> >>> dtn mailing list
> >>> [e-mail]<mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/dtn
> >>
> >>
> >> _______________________________________________
> >> dtn mailing list
> >> [e-mail]<mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/dtn
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/dtn
>
> _______________________________________________
> dtn mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dtn