Subject: [dtn-users] Time Synchronization in DTN

From: 袁鹏 <[email-masked]>
Date: Tue, 19 Jun 2012 10:11:16 +0800 (CST)

Hi,

Recently I am working on time synchronization in DTN used for deep space communication. But I am confused about the function of it. Atomic clocks have been used in spacecraft, which are very precise. Then what does the time synchronization architectural work for?

Thanks for response.

Yuanp

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 18 Jun 2012 22:52:08 -0400

On 6/18/12 10:11 PM, 袁鹏 wrote:
>
> Hi,
>
> Recently I am working on time synchronization in DTN used for deep
> space communication. But I am confused about the function of it.
> Atomic clocks have been used in spacecraft, which are very
> precise. Then what does the time synchronization architectural
> work for?
>
> Thanks for response.
>
>

If you have an accurate clock, and it has been set properly, then
the issues of time synchronization might not be relevant (although a
conservative position is that clocks, like anything else, can break
and when they do it's nice to have a backup).

The work on relative time and time synchronization is targeted at
deployments of DTN on systems that have unreliable or improperly
administered clocks -- cheap, low-power, low-reliability devices.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
[email-masked]

---

From: <[email-masked]>
Date: Tue, 19 Jun 2012 10:41:35 +0100

'cheap, low power, low reliability devices' is a bit of a slur. There's a lot of
expensive military stuff that spends a lot of time being turned off completely.

The NASA Deep Impact/EPOXI spacecraft is an expensive, high-reliability,
carefully administered device exposed to extreme temperature ranges that
cause clocks to speed up and slow down.

I understand that its onboard clock was synchronised with the ground before
every DTN bundle test, to prevent the bundle protocol communications from
breaking. (See e.g. Scott Burleigh's DINET presentation of 24 March 2009.)

Using an atomic clock is an example of fixing a software problem in hardware.
Those clocks take space, they take mass, they take money. They're justified
for GPS and for some scientific space missions. They are not justified for many
others. Needing an atomic clock just because a software protocol expects
that level of clock reliability is not a good engineering tradeoff.

More generally, DTN involves disrupted communication, where outages are
expected. And clocks cannot be synchronised during these outages. They
_will_ drift. But because most bundle protocol development has been done
on internet-connected computers with NTP to sync clocks, ultimately to
atomic clock sources, it is assumed that that having accurate timing is the
norm, rather than the exception. (This is also why most bundles have
been sent over TCP. Because, hey, internet-connected computers.)

The relative time work is one crutch for a protocol
that expects to be standing on the leg of perfect timekeeping,
and on the leg of perfect underlying protocol and communications
reliability. In truth, the bundle protocol has no legs to stand on.

Lloyd Wood
http://sat-net.com/L.Wood/dtn

...which is why we're not trying to cut the bundle protocol off at its knees.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Daniel Ellard [[email-masked]]
Sent: 19 June 2012 03:52
To: [email-masked]
Subject: Re: [dtn-users] Time Synchronization in DTN

-Dan

_______________________________________________
dtn-users mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-users

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 19 Jun 2012 07:27:26 -0500

My colleague at NASA set up a very small testbed  consisting of  5  computers (DTN nodes)  to emulate a Mars to Earth via 3 Deep Space Network (DSN) nodes and a mission control center (MCS).  He has no Internet connectivity in this particular lab and little money so he begged and borrowed to get machines. He synchronized all machines.  When power cycled, the machines were all out of sync because the computers were old and the on-card batteries had died on at least one (it only takes one).  The solution was to load NTP on all the machines and keep them in sync on a back channel using the one bad machine as the NTP server.  Time only had to be relative - sort of.  Anywhere - there is your solution, just run one DTN node with NTP and make sure all disconnected systems are connected on a back channel.  Simple.  :-)

- Will

On Jun 19, 2012, at 5:41 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Lloyd Wood

Hi,

Thanks for response.

-Dan

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Tue, 19 Jun 2012 15:41:39 +0000

One note of clarification: I’m pretty sure nobody is proposing that atomic clocks must be put on spacecraft because the Bundle Protocol needs it.  We put atomic clocks on spacecraft because the spacecraft need highly stable and reliable time references for a variety of operational purposes, such as accurately time-tagging instrument observations and performing trajectory correction maneuvers at the times at which they must occur in order to have the desired effect on trajectory.  The Bundle Protocol, like many other elements of flight software and hardware, exploits this resource to make its operations simpler and more reliable.

At the same time, I don’t think there’s any serious opposition to the idea of adding cumulative bundle age as an alternative basis for bundle expiration, for environments in which accurate clocks cannot be consulted.  An Internet Draft defining that mechanism was in the works two years ago; it seems to have faded away for lack of urgency, but the idea is still very much alive.  This is a non-issue.

As for DINET: we uploaded software UTC correction offsets to EPOXI every few days as part of our routine experiment operations; the spacecraft clock itself was never adjusted.  The purpose of these correction offsets was to optimize tracking pass utilization, to enable as much data to be transmitted and received as possible, certainly not to prevent bundle protocol communications from “breaking.”  DTN was quite comfortable with less than perfect timekeeping, and of course it was also quite comfortable with less than perfect underlying protocol and communications reliability.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Tuesday, June 19, 2012 5:27 AM
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] Time Synchronization in DTN

- Will

Lloyd Wood

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]] On Behalf Of Daniel Ellard [[email-masked]]
Sent: 19 June 2012 03:52
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-users] Time Synchronization in DTN

Hi,

Thanks for response.

-Dan

--
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
[email-masked]<mailto:[email-masked]>

_______________________________________________
dtn-users mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-users
_______________________________________________
dtn-users mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-users