Introduction

This document proposes a feasibility study and development of strawman technology to provide time synchronization services in the Interplanetary Internet (IPN). This includes mechanisms to synchronize the onboard clocks in various communications and exploration platforms in the Mars exploration program, as well as other programs that might be funded in future. It is expected that the technology can be leveraged on the Network Time Protocol (NTP) architecture, protocols and algorithms developed over the last two decades. As explained in this document, the technology will need to be extended in certain areas, in particular for mobile platforms.

In many aspects the Mars exploration program shares common objectives with the NTP operation and security model. The platform clocks are disciplined in time and frequency relative to a universal timescale maintained on Earth. Clocks are synchronized by exchanging timestamps in client-server, peer-peer and broadcast modes. The protocol and algorithms rely on diversity and redundancy and are inherently resistant to component failures, communication outages and security threats.

One of the most important objectives in the NTP model is the highest accuracy possible under ambient conditions of network jitter and oscillator wander. In most scenarios, NTP time can be maintained to the millisecond and in special cases to the microsecond. However, this degree of precision may not be necessary or even desirable in the IPN. A useful assumption for Mars exploration is that the precision should be at least to the order of the maximum transmission delays expected in the near-Mars space, which is probably tens of milliseconds.

However, the NTP model assumes the platforms are stationary and the network path delays are relatively small and symmetric in each transmission direction. This is in general not true in the interplanetary environment; the delays are very much longer and the asymmetries very much larger. This is the central theme motivating this proposal and explored in the following sections. 

IPN Timescale

The IPN timescale runs on Earth-centric time, which simplifies experiment supervision, data collection and infrastructure maintenance. It does not seem necessary at this time to decide whether IPN time is reckoned in International Atomic Time (TAI) or Universal Coordinated Time (UTC). At some future time there may be other timescales, such as Solar-centric or Galactic-centric, but this does not seem reasonable at this time. IPN time will make no sense to a Martian, as the days, nights and seasons will precess wildly around the Mars-centric clock. This may not matter, since no indigenous population is anticipated.

It is necessary to establish a time-space reference point and rate for the IPN Earth timescale so that an event that occurs at some known spatial coordinate and at some epoch according to the IPN timescale at that coordinate occurs at the same epoch according to the IPN Earth timescale. For this purpose the IPN Earth reference point is the center of the planet and the timescale runs at the TAI rate, with or without UTC leap corrections. For the purposes of Mars exploration it is convenient to establish a secondary time-space reference point for IPN Mars at the center of that planet. The IPN Mars timescale is syntonic with IPN Earth, but it might have a fixed offset depending on the longitude of mission control. It is assumed that relativistic effects are ignored for both timescales. 

Synchronizing clocks and determining orbit elements are not independent, so knowledge of one is necessary to determine the other. As in GPS, in order to synchronize one clock to another, it is necessary to know the range and range rate between them. When the position and orbital motion can be established by external astronomical means, these values can be calculated directly. If not, the platforms may have to learn their orbit elements by independent observation of the sun and certain stars relative to the unsynchronized onboard clock. These values are then distributed to all platforms so each can construct an ephemeris to be used in predicting where and when one platform can communicate with another. However, since the orbit elements and clock frequency are interdependent, the ephemeris may have to be adjusted continuously as the clocks are adjusted to maintain global synchronization.

An important assumption in this document is that, if possible, when determining a packet timestamp the transmitter does all calculations necessary to compensate for range and range rate so that the receiver's view of the transmitter is as if the transmitter were stationary at the actual position when the packet arrives at the receiver. This simplifies processing and reduces power consumption, but is not always possible, as demonstrated later in this document.

Interplanetary Time Transfer

Time transfer between IPN Earth and IPN Mars involves the transmission of an NTP timestamp from IPN Earth and its reception at Mars orbit. Presumably, the transmitter corrects for its geographic position relative to the IPN Earth reference point, then calculates the network delay from the IPN clock to the DSN station and adds the space delay and coding delay before transmission. The receivers then know the IPN Mars time at the orbit corresponding to the center of the planet. There may be several receivers at Mars orbit, but each might hear the transmission at a slightly different time depending on the particular orbit of the receiver. If necessary, each receiver adjusts the time according to its particular position in space.

While exact details are not available, Mars orbiters carry sun and/or star sensors which help them determine their orbit and orbit elements relative to their onboard clock. These data and timestamps can be exchanged with other orbiters in housekeeping packets. At the same time the time values can be processed to synchronize the clocks using the NTP algorithms and possibly the protocol. This is somewhat complicated by the need to account for range and range rate.

Winding the Clocks on Mars

Timekeeping in the near-Mars space can use a conventional NTP subnet and stock software. NTP packets can be transmitted individually or embedded in other messages used for data request or housekeeping purposes. An interplanetary timestamp, constructed as above, might not be heard by all platforms . Those that do hear it assign stratum one greater than the transmitter and those that do not hear it one stratum above that. Through suitable choice of protocol parameters, this should happen automatically. 

For the purposes of this document, there are three classes of Mars explorers: orbiters, surface base stations and rovers. Orbiters can predict where the other orbiters and surface units are and when they can be reached. The base stations may carry a downloaded schedule of orbiter rise and fall times, but probably not much more than that. Rovers carry even less and may not be able to communicate directly with the orbiters.

Ordinarily, orbiters send NTP messages at prescribed times according to the visibility schedule calculated from the ephemeris. When visible, one or more messages can be sent for reliability purposes or to reduce incidental errors. When an orbiter sends a message to another orbiter or surface unit, it calculates the IPN Mars time the message will be received and the position of the receiver according to the ephemeris. This avoids the need for the receiver to determine the propagation time as in conventional NTP modes. However, the surface unit may not be able to calculate the receiving time at the orbiter, but this does not matter unless the orbiter is to be synchronized via the surface unit, which is unlikely.

Ordinarily, NTP clients communicate with servers on a regular, relatively frequent basis in order to track frequency changes due to temperature variations and other causes. The tracking process is implemented using a hybrid phase/frequency-lock feedback loop, which automatically adjusts the update interval and time constant to the prevailing jitter and wander characteristics. However, the orbiters cannot communicate with each other and with the base stations all the time, so the feedback loop and parameter adaptation algorithm will have to be modified. However, this scenario is not unlike the case with NTP and dial-up modems which must operate with relatively long poll intervals and missing polls due to failed connections.

Since the orbiters are moving with respect to each other and the base stations, the protocol must track the range and range rate as determined from the ephemeris. If a two-way protocol mode is used, it is possible to update both the ephemeris and the clock on a continuous basis as visibility opportunities occur. Since ephemerides are not carried by the surface units and they might not have sufficient computing resources even if the data were available, range and range rate calculations must be done by the orbiters. In some cases it may not be practical to use bidirectional time transfer modes such as client-server or peer-peer, since a two-way path might not be always available due to power conservation, etc.

Time transfer between the base stations and rovers can use NTP broadcast mode with no modifications. The most likely scenario may be to use NTP peer-peer mode between orbiters, NTP manycast (client-server) mode between orbiters and surface units and NTP broadcast mode between base stations and rovers. Peer-peer modes are useful by an orbiter to provide disciplined recovery from loss of another orbiter, while manycast modes are useful by a base station for the same purpose.

Dave sends