Time Synchronization for Space Data Links

Introduction

One the most serious issues that must be confronted as the number of Mars orbiters and landers is augmented is the dependence on the NASA Deep Space Network (DSN) telecommand and computation services. What can take 40 minutes to accomplish from Earth can take 60 ms from near Mars. One of those services is time transfer, which is the topic of this document.

The Network Time Protocol (NTP) has been the core mechanism for time transfer on and near Earth and is planned for Moon missions in future. A natural extension is on and near Mars. NTP is inherently resistant to lost, duplicate or bogus packets. Data integrity is provided by the IP and UDP checksums. No flow-control or retransmission facilities are provided or necessary. The protocol uses timestamps, either extracted from packet headers or captured from the system clock upon the arrival or departure of a packet.

The Consultative Committee on Space Data Systems (CCSDS) has defined the Proximity-1 architecture and protocol for the transmission of command, telemetry and science data between spacecraft on and near Mars. The protocol specification includes a method for time transfer in which time related data are collected by spacecraft and sent to Earth for processing, then returned to the spacecraft for use in experiments and data collection.

This document proposes an alternative method in which most processing is done by orbiters near Mars and the demand for Earth-Mars resources is reduced. The proposed Proximity-1 protocol is similar to the NTP interleaved symmetric and interleaved broadcast modes described in NTP Interleaved On-Wire Protocol, but omits the origin timestamp used for bogus packet detection. This feature is not necessary for space data links, which are generally point-to-point and relatively invulnerable to hostile attack. The proposed protocol does not use the standard NTP header, but conveys the timestamp data in a Proximity-1 header.

The interleaved modes require peers to retain state, so the protocol does not support client/server mode. Mode selection and timing flow (stratum assignment) can be determined by configuration option or a designated message outside the scope of the proposed protocol. The protocol can detect lost and duplicate packets and, in addition, packets that violate the interleaved rules.

This document first gives an overview of the NTP interleaved protocols; in particular, how clock offsets and roundtrip times are determined. This is followed by a summary of typical spacecraft architecture and time distribution methods and then an overview of the Proximity-1 protocol. The next section describes how the the Proximity-1 time service operates and the next section the proposed interleaved protocol. The next and final sections describe DSN time transfer operations and Proximity-1 time transfer operations, respectively.

NTP Protocol

The NTP architecture includes a transmit process, which is called for every transmitted packet, and a receive process, which is called for every received packet. The state machine operates in two substates corresponding to interleaved symmetric and interleaved broadcast modes. The protocol operations are described in the NTP Interleaved On-Wire Protocol white paper. Pseudo-code is contained in a companion briefing document NTP Interleaved Protocol for LANs and Space Data Links.

In the Proximity-1 variant there are two header variables t_rec and t_xmt, which are included in a special supervisory frame, and six state variables rec, dst, aorg, borg, xmt and x for each peer described in the pseudo-code. The timestamps T₁, T₂, T₃ and T₄ are the products of the protocol used to compute the offset of B relative to A:

and the roundtrip delay

The purpose of the proposed protocol is to produce the timestamps within the framework of the Proximity-1 architecture and protocol. It should be noted that the timestamp formats in NTP and CCSDS are similar in that they are in seconds and fraction; however, the CCSDS epoch is 100 years later than NTP. Thus, it is a trivial matter to convert one format to the other.

MARSnet Architecture

The purpose of the time transfer function described in this document is to discipline spacecraft clocks to a common MARSnet timescale; in particular, UTC with or without leap seconds. This can be done using the Proximity-1 time-tag mechanism and designated protocol data units.We assume each MARSnet vehicle is assigned a unique ID and that they communicate using an internet protocol such as TCP/IP and Proximity-1 Data Link Protocol (PDLP). In principle each vehicle can communicate with any other in range and possibly via multiple direct and indirect paths. Since MARSnet is expected to operate autonomously, it has a dynamic routing algorithm and can discover and discard intermittent and multiple paths.

[The above characterization captures the design of the Hellospeak routing algorithm once used in the early Internet.]

Since delays are relatively small, we assume no end-end flow control other than TCP is necessary. As with current Earth LEOs, the communications opportunities and PDLP sessions last only a few to fifteen minutes at a time and science data may need to be soaked up by different orbiters and later combined.

Spacecraft Architecture

As shown above, a typical spacecraft vehicle includes a spacecraft computer (SC) a number of science instruments, communications/navigation transceivers and a mission-elapsed time counter (SCLK). These devices are interconnected by a low-speed telemetry bus (MIL STD 1553) and a high-speed data bus (LVDS).

The SCLK increments once per second and generates a pulse-per-second (PPS) pulse which is sent to all devices as necessary. If the SCLK fails for some reason, the mission is probably lost, so we assume it is implemented as a separate, rugged device accessed via the telemetry bus. If resolution less than one second is necessary, the device implements an interpolation counter phase-locked to the PPS signal. In the following the interpolated SCLK is called the reference clock.

The 1553 telemetry bus operates at 1 Mbps using Manchester encoding, where each device derives bit timing independently. The bus controller (BC) function is implemented by the SC. The remaining devices function as remote terminals (RT). The BC initiates all transfers and polls for responses. It can read from an RT, write to an RT or instruct one RT to write to another RT. RTs neither initiate transfers on their own nor interrupt the BC. Commands and data messages consist of up to 32 16-bit words at 1 Mbps, so a message cannot be longer than 0.5 ms. Each message is addressed to a single RT or broadcast to all RTs.

Those MARSnet spacecraft that can communicate with Earth carry a DSN transceiver, usually operating at X-band with data rates to 128 kbps and including precision rate and range rate measurements for navigation functions. All MARSnet spacecraft carry Proximity-1 transceivers operating at UHF-band with data rates to 4096 kbps and range rate only measurements.

Provisions can be made for UTC in the form of the 64-bit UTC time at liftoff, called UTC₀, in seconds and fraction. A device finds the current UTC time by adding UTC₀ to the reference clock.

The value of UTC₀ can be disciplined by the time transfer function in a manner similar to NTP. It would seem prudent for the SC to determine UTC and broadcast it shortly after the PPS signal interrupt. Devices needing to coordinate events with another vehicle, but not requiring resolution better than one second, could use these broadcasts directly.

Proximity-1 Protocol

The Proximity-1 Data Link Layer Protocol Specification includes six sublayers: I/O, Data Services, Frame, Coding and Synchronization (C&S), Physical (PHY) and Medium Access (MAC). All but the C&S and PHY layers are implemented in the SC. The C&S is implemented in dedicated chips and FPGAs, while the PHY is the RF modem itself.

The MAC is the main point of interaction for the time transfer function. It has means to instruct the C&S sublayer to intercept a 24-bit ASM marker used to delimit C&S frames and capture a timestamp from the reference clock. The MAC can also send and receive supervisory frames to and from the remote MAC for the space link.

User data units (U frames) are sent and received over the space link along with supervisory data units (P frames). There are two kinds of U frames, sequenced and expedited. Sequenced frames carry sequence numbers modulo 256, while expedited frames carry sequence numbers modulo 8. Frame numbers are visible by the C&S at both ends of the space link. The SC includes separate queues for each of these and in addition a SPDU (P frame) queue, which has no sequence numbers. The priority of these queues (leaving out some special cases) is SPDU, UPDU expedited and UPDU sequenced.

A maximum frame of 2048 octets transmitted at the minimum channel rate of 1000 bps takes 32 s in transmission, so a SPDU or expedited frame might have to wait that long. Thus, it is imperative that timestamps be captured at the C&S layer. The C&S timestamp and associated sequence number can be captured and retained for later retrieval. Note that the MAC does not have direct access to the data stream and can only inject or capture SPDU frames and enable or disable C&S timestamp capture. In particular, the MAC cannot inspect or overwrite sequenced or expedited frames.

Proximity-1 Time Service

The specification includes a Transmit Parameters SPDU to enable the remote MAC to capture a specified number of transmit timestamps and a Receive Parameters SPDU to capture a specified number of local receive timestamps. These are retained in buffers for later retrieval as telemetry data. In addition, there is a Time Distribution SPDU to convey timestamps from one MAC to another and to broadcast the time.

SPDU frames carry no sequence numbers, so timestamps associated with these frames are not useful in the present design. The specification expects that the timestamps and associated sequence numbers are captured only for expedited frames. To capture for both sequenced and expedited frames would create an ambiguity, as the sequence numbers are from different spaces. The C&S determines the frame type and sequence number in the 5-octet frame header.

This is the same approach used with the IEEE 1588 Precision Time Protocol (PTP), which expects the network interface card (NIC) to reach far into the packet to inspect the frame type, packet type (UDP/IP) and port number to determine whether this is a PTP packet and if so capturing a timestamp for later retrieval. In some designs the timestamp in the packet itself is overwritten. This of course causes a messy UDP checksum error unless explicitly disabled.

What would seem to be a prudent procedure is for the MAC to enable the C&S to capture a number of transmit and receive timestamps and send SPDUs to the other end of the link to enable the C&S to do the same thing. Then, each end sends a number of expedited frames to the other. Several cases ensue, depending on whether frames are already in the expedited queue at either end of the link. In the current design the timestamps and sequence numbers collected are returned to Earth as telemetry data.

While not in the specification, from other quaint habits lifted from available documents, captured timestamps are probably telemetered to Earth and correlated by sequence numbers to select the transmit and receive timestamps for the same packet in one direction and then the other. Since these are in mission elapsed time (SCLK) for each vehicle, those for each one must be adjusted with the respective UTC₀ at liftoff. This results in four timestamps from which the clock offset and roundtrip delay can be determined as in NTP. While probably a bug in the Proximity-1 specification, the timestamp format is specified in another CCSDS document, but there is no provision for the sequence number.

Proposed Proximity-1 Interleaved Time Service (PITS)

If the MARSnet is to become semi-autonomous, some way must be found to avoid time transfer and correlation on Earth. These functions should be an intrinsic, distributed and ubiquitous service of MARSnet. The proposed Proximity-1 Interleaved Time Service (PITS) develops a UTC reference clock for every vehicle participating in MARSnet. It is based on the assumption that one or more vehicles have been synchronized to UTC via DSN to function as a primary servers as in the NTP architecture. The other spacecrafts organize the time subnet and obtain time in a manner very similar to NTP.

First, in order to avoid conflict with the existing provisions, we define a new, variable-length Timestamp SPDU (type 3). The C&S sublayer already reaches into the data buffer to recognize an expedited frame and capture the timestamp and sequence number. On transmit the C&S recognizes the Timestamp SPDU and captures a transmit timestamp; on receive the C&S recognizes this SPDU and captures a receive timestamp. No sequence numbers are necessary and capture does not need to be enabled - it is always enabled for the Timestamp SPDU. To preserve consistency with current methods, the timestamps are from the reference clock (SCLK plus interpolated fraction).

Timestamp SPDUs are exchanged over the link several times each pass for redundancy and in order to discipline the frequency offset, if needed. Only a single timestamp buffer is necessary for the transmit timestamp and another for the receive timestamp, since Timestamp SPDUs are never sent back to back.

The Timestamp SPDU can hold two timestamps in UTC seconds and fraction format. On transmit the MAC sublayer constructs the SPDU including the last transmitted UTC timestamp and the last received UTC timestamp for the previous message. On transmit the C&S sublayer captures a reference timestamp, saves it in a buffer and hands off to the MAC sublayer. On receive the C&S captures a reference timestamp, saves it in a buffer and hands off to the MAC sublayer. These timestamps are then adjust using the UTC₀ for each end separately

Ar each end this results in four UTC timestamps which can be used by the interleaved protocol described in the next section to compute the relative offset and roundtrip delay as in NTP and IEEE 1588 Precision Time Protocol (PTP). The interleaved protocol can be used in either symmetric or broadcast mode, so is applicable in NTP-like configurations involving multiple spacecraft and space links.

In this design the DSN-disciplined vehicles operate as Proximity-1 primary servers and the others as secondary servers. However, primary servers can come and go depending on the DSN schedule and orbit crosslink opportunity. Appropriate scenarios are described in a later section of this document.

Proximity-1 Interleaved Symmetric Mode

In the Proximity-1 interleaved protocol the transmit timestamp for one Timestamp SPDU is transmitted in the next Timestamp SPDU. The trick, however, is to implement the protocol within the framework of the Proximity-1 architecture and protocol without affecting other functions. Following is a typical example of operation starting from an unsynchronized condition.

The above figure illustrates a typical scenario involving peers A and B. Note that the receive (even-numbered) timestamps are available immediately after the frame has been received, but the transmit (odd-numbered) timestamps are available only after the frame has been sent, so are sent in the next following frame. Note also that the round that begins at t₁ is not complete until t₈ and the round that begins at t₅ is not complete until t₁₂.

The Timestamp SPDU includes two timestmps t_rec and t_xmt. Each peer requires five state variables, rec, dst, aorg, borg and xmt. In addition, there is an x bit which alternates between +1 and -1 for each frame sent.

When a frame is received, t_rec is copied to rec and the receive timestamp to dst. When a frame is transmitted, if x = +1, the transmit timestamp is copied to aorg and borg is copied to t_xmt. Otherwise, if x = -1, the transmit timestamp is copied to borg and aorg is copied to t_xmt. Upon receipt and before the state variables have been updated, the timestamps are T₂ = rec, T₃ = t_xmt, and T₄ = dst. If x = +1, T₁ = aorg; if x = -1, T₁ = borg. After this, t_rec is copied to rec and the receive timestamp to dst.

There are two sanity checks designed to deflect duplicate or unsynchronized frames. While not shown in the figure, the xmt state variable is used only to detect duplicate frames. Before the state variables are updated, the frame is discarded as a duplicate if t_xmt matches xmt from the last frame received. Otherwise, t_xmt is copied to xmt. After the state variables and timestamps have been updated, the frame is discarded as unsynchronized if either T₁, T₂ or T₃ are zero.

Note that the difference between the transmit timestamp T₄ and corresponding timestamp aorg represents the output queuing delay, which can be significant in Proximity-1 operations. If this quantity is less than zero or greater than the maximum roundtrip delay plus transmission delay, the frame is misordered and should be discarded. This is called the delay test; in practice, it is a very reliable means to detect lost or crossed frames.

In the above figure t₈ is the end of the interleaved round that begins at t₁. Before the state variables have been updated, the four timestamps t₁, t₂, t₃ and t₄ are available to determine the offset and delay of B relative to A. The reader can verify the four timestamps t₃, t₄, t₅ and t₆ are available at t₁₀ to determine the offset and delay of A relative to B.

Proximity-1 Interleaved Broadcast Mode

It would seem that the Time Services SPDU in the Proximity-1 specification is intended to broadcast the current time of day according the the spacecraft clock. Used in this way could incur substantial error, as the queuing delay for the SPDU can be significant. A simple alternative is to include the transmit timestamp of the previous frame, as in the interleaved mode described above. The receiver needs only one state variable to hold the receive timestamp of the previous frame. Once the offset has been determined, this variable is overwritten by the current receive timestamp.

Accuracy Expectations

This section considers the accuracy and precision expectations using the Proximity-1 protocol and Electra transceiver implementation. The Electra radio represents the first generation of NASA software defined radios (SDR).

The transceiver is built in three versions, the original Electra transceiver shown above, a smaller, lighter version called Electra Lite and an even smaller, lighter version intended for balloons and aerobots. The radio can be reconfigured in flight in response to commands issued from Earth. According to recent documents, an even more sophisticated SDR may become available which is able to recognize each transmitted signal design and automatically configure without instructions from Earth.

samples the 70-MHz IF at about 19 Msps resulting in at least four samples per symbol at the highest data rate of 4096 kbps increasing to 16 samples per symbol at 1024 kbps. In order to reduce power as much as possible at rates below 1024 kbps , a concatenated integrate-comb (CIC) decimator is used to maintain 16 samples per symbol. Below 8 kbps the decimation is a constant 128 in order to allow enough bandwidth for the carrier tracking loop to track the Doppler signal component.

A digital transition tracking loop (DTTL) tracks the baseband symbol stream. The resolution of this loop depends on symbol rate and the number of samples per symbol. The first column in the table below shows the bit rate in kbps, the second the decimation factor, the third the number of samples per symbol and the fourth the resolution in microseconds.

The resolution is very much improved by the numeric controlled oscillator (NCO) in the DTTL and the loop time constant, but this depends on the Doppler. Loop bandwidths in the order of 10 Hz are reported at the lower data rates. In any case, accuracies to the microsecond should be achievable.

A typical NCO is shown in the above figure, which is based on the Analog Devices AD 9854 chip. It consists of an accumulator, phase increment, lookup table and DAC. The device produces a sinewave output equal to the clock frequency, in this case 300 MHz, divided by the factor 2⁴⁸ / N. Thus, the device can produce any frequency from zero to 75 MHz with resolution to one microHerz. While useful for demonstration purposes, this particular device runs rather hot and is probably overkill for most space applications. In the case of the Electra transceiver the NCOs are probably implemented in the FPGA.

DSN Time Transfer Operations

This section considers the current methods for time transfer from Earth to Mars using the Deep Space Network (DSN) range and range rate measurements. It includes a suggestion that might improve time transfer precisions to the order of nanoseconds. The scenario was developed from the material in various DSN handbooks, papers and tutorials.

Current DSN navigation operations require precise range and range rate measurements with each spacecraft separately. This is done most typically using X-band uplinks modulated with a command subcarrier at about 128 kbps and a ranging subcarrier at about 1 Mbps. Both subcarriers are phase-modulated on the carrier with the ranging subcarrier modulation index in the order of 0.2 rad. This leaves lots of signal for uplink telemetry and for the uplink and downlink carrier tracking loop to measure the range rate.

The range measurements are performed as shown in the above figure. It can be done in noncoherent (a) or coherent (b) mode or in the most demanding case coherent handover (c) mode. In this design the navigation and telecommand functions are continuous and noninterfering to each other.

At the spacecraft the uplink signal can be processed in either of two ways. In the turnaround mode shown in the above figure, the carrier tracking loop extracts the uplink frequency NCO1 and calculates the downlink frequency NCO2 at the required ratio. The composite uplink signal is demodulated, filtered and remodulated on the downlink carrier. It is the presumed intent that the uplink command subcarrier is demodulated, filtered out and replaced by the downlink telemetery subcarrier, but there is some ambiguity about this in the available documents.

In the regenerative mode shown in the above figure,the ranging subcarrier is demodulated and the symbol timing and ranging code extracted using a DTTL. This is used to remodulate the downlink carrier, thus avoiding the noise received in the uplink passband. In either mode the downlink signal is received on Earth and the subcarriers individually demodulated.

The DSN is now able to determine the range using the ranging subcarrier PN code sequence and the range rate using the DSN carrier tracking loop. Presumably, and this is not explicit in the documentation, the DSN can calculate the UTC time at the spacecraft and, after accounting for the space link delay, send the time in a command message in the same or a subsequent pass. At the spacecraft the UTC₀ can be determined as described earlier.

Unfortunately, this method does not provide precision time transfer to the spacecraft, since the time command sent in the 1553 telemetry bus is precise only to 0.5 ms. Precision time transfer could in principle be done using regenerative range mode and the Two-Way Satellite Time and Frequency Transfer (TWSTFT) technique used by the national laboratories of several countries. The technique uses a PN ranging signal as in DSN, but modulates the PN sequence to send data at a low rate. Each PN sequence determines a bit in a word of N bits with polarity determined by the bit assignment. At the spacecraft the word sequence determines the seconds boundary as well as ancillary data to record the UTC time of transmission.

In principle, it is possible in regenerative mode to extract data from the uplink ranging signal and insert data on the downlink signal as well. There are several ways this could be exploited, even exchanging timestamps in the NTP fashion as described in the next section..

MARSnet Time Transfer Operations

In the above scenario the DSN does all the navigation and time transfer functions with each spacecraft separately (except for the current Phoenix lander), so there is no need for these functions within the MARSnet orbiter segment other than the ability to report range rates on links between the orbiters and landers. If MARSnet is to become semi-autonomous, at least the time transfer function must be implemented within MARSnet.

This section explores a possible scenario in which the DSN uploads something called a hail matrix (HM) to each spacecraft which can communicate with Earth. The HM includes for each spacecraft the UTC for that spacecraft and a list of UTC pass times and durations for each other spacecraft. Note that UTC for each spacecraft might be different, depending on light time, but the HM is the same for all spacecraft.

Currently there are three orbiters and three landers in MARSnet; thus the HM has six rows and six columns. Of the orbiters, ODY and MRO are in polar, Sun-synchronous orbits, while MEX is in low orbit with high eccentricity. The polar orbiters probably see each other only rarely, but visibility from MEX must be much more interesting. With respect to the landers, this results in three ascending and three descending passes each day for ODY and MRO. One of the three orbits is near zenith, while the other two are ±15 degrees from zenith; however, not all three passes might be viable.

If the HM lifetime is assumed something like a week, each element of the matrix would have up to 42 passes for a total of 1512 passes for all spacecraft. While this may be somewhat daunting, the matrix is symmetric about the main diagonal and in many cases fewer than six passes will be available on given days and even no passes on some days. Eventually, the pass patterns will repeat depending on geometry and orbiter stationkeeping.

Thus, each spacecraft has a complete topology which can be used to predict viable passes and avoid conflict passes with other spacecraft. Initially and at occasional times after that, the HM is refreshed from Earth and redistributed within MARSnet. At these times the UTC₀ and HM for each spacecraft can be adjusted and propagated to the landers that can't communicate directly with Earth. The redistribution algorithm is perhaps best considered a modified flooding algorithm similar to that once used in the ARPAnet. Note that in cases where orbiters have no passes with each other that it might be possible that the landers function as a store/forward link. This issues should be a topic for further study.

During the week the spacecraft SCLK can drift considerably due to thermal cycling, overnight snooze, etc. At suitable intervals, perhaps during science data passes, Proximity-1 timestamps can be exchanged and the UTC clock offset (UTC₀) disciplined. Due to the presumed unstable clock frequencies, it may not be useful to discipline the UTC clock frequency. The offsets can be maintained in structures much the same way NTP manages the association table.

The next step in evolving MARSnet is to design an algorithm that might be considered a traffic cop. Its goal is to determine which spacecraft can use which pass to communicate to an other spacecraft. Presumably, each spacecraft transceiver is frequency agile, so the problem gets even more interesting. The first operational function for MARSnet is time transfer, and that is relatively simple. Future functions might include command, telemetry and science data relay and strategic means to use multiple links to increase throughput.

As in NTP some sort of distance metric needs to be designed. This might include only the stratum and time since last synchronized from Earth, called the root dispersion in NTP. Algorithms similar to NTP can construct a dynamic, minimum distance spanning tree. There is no need to elect a leader and the tree automatically reconfigures as updates are received from Earth and flooded throughout MARSnet.

While it is unlikely the existing NTP software can be used directly, due to its rather large code bloat, the generic algorithms may be useful. There are two methods to do this, using the Proximity-1 time transfer mode described above or adapting the Proximity-1 timestamps as NTP timestamps and do the time transfer using native NTP. The first method provides time transfer accurate to the symbol timing of the C&M time tags, but requires an auxiliary protocol to manage the time subnet, compute the error budget, etc.

The second method provides all these functions using the NTP protocol in its native mode. Many fields in the NTP packet header are significant in the MARSnet context, so the header can be encapsulated in a UDP/IP expedited data frame. This has the advantage that the NTP packet is compatible with other spacecraft that might use NTP but not have provisions for C&S time tags.

The system clock, implemented in most operating systems as a timer interrupt and interpolation counter, has a resolution of a few nanoseconds. From current experience and assuming a the system clock is disciplined to the PPS signal from the spacecraft SCLK, the expected accuracy of the system clock should be in the order of a few microseconds.

In order to preserve accuracy, the C&S timestamps should be used. For every transmitted NTP packet a Timestamp SPDU is transmitted, immediately afterward and the timestamp copied as the next origin timestamp in the NTP interleaved symmetric mode and the current origin timestamp actually in the NTP packet is used as the Timestamp SPDU data field.

On reception of the Timestamp SPDU, the data field is compared to the origin field in the previously received NTP packet as an error check. If the contents disagree, both the NTP packet and Timestamp SPDU are discarded. The received C&S time tag is copied as the destination timestamp. Other than these considerations, the program processes the NTP packet in the normal way.

One-Way Time Transfer Operations

This section discusses issues involved in transferring time from one spacecraft to another using only one-way space links. This scenario assumes each spacecraft has the computing capacity to determine its current state vector given an ephemeris consisting of the six Keplerian elements previously provided directly or indirectly from Earth.

Periodically, perhaps in a pass involving no science data or telemetry, the current state vector and UTC time are sent over the one-way link as expedited data. The receiver determines its current state vector and UTC time, then computes the light time from the transmitter position and receiver position in space. The sum of the transmitter UTC time and the light time establishes a new receive time and state vector. The procedure iterates until the residuals fall below a predefined threshold. As in the NTP and Proximity-1 interleaved broadcast mode, the transmit time for one message must be sent in the following message.

In order to preserve accuracy, C&S time tags are necessary and these can be obtained using the original Proximity-1 Time SPDU. Time tagging is always enabled, but those for other than the state vector SPDU are ignored.

This is only a preliminary discussion and many issues remain to be studied and resolved.

References and Partial Bibliography

Note: Some of these documents are personal communication. Others with incomplete citation were obtained via Google. In most cases the document online ID is shown.

Web tutorials

1. Basics of Space Flight
2. Rocket and Space Technology: Orbital Mechanics

   General

3. Barbieri, A. Development and flight performance of CCSDS Proximity-1 on Odyssey and the Mars Exploration Rovers. IEEEAC Paper #1044, (2005). [01559435.pdf]
4. Choi, K., et al. The implementation and validation of the new standard CCSDS file delivery protocol for multi-hopped space file transfer. (undated). [0079018.pdf]
5. Edwards, C.D., et al. An assessment of the scientific potential and perational feasibility of Mars crosslink radio science observations. International Conference on Mars. (undated) [3259.pdf]
6. Edwards, C.D., et al. A Martian Telecommunications Network: UHF Relay Support of the Mars Exploration Rovers by the Mars Global Surveyor, Mars Odyssey, and Mars Express Orbiters. xx [04-2490.pdf]
   
7. Gifford, A., et al. Solar system navigation time. SCAWAG F2F (15 December 2005). [solar system timet ransfer 121505 f2f rev4.ppt]
8. Guinn, J., and T. Ely. Preliminary results of Mars Exploration Rover in-situ radio navigation. (undated) [03-2442.pdf]
   
9. Hogie, K., and E. Criscuolo. Time transfer issues over space links. (19 November 2006). [ntp-issues-draft.ppt]
10. Kazz, G., and E. Greenberg. Mars relay operations: application of the CCSDS Proximity-1 space data link protocol. (undated) [spaceops02_p_t5_08.pdf]
11. Killough, R. Integrating CCSDS and MIL-STD-1553: what you should know. IEEEAC Paper #111, (2002) [01036904.pdf]
12. Mills, D.L., and H. Harish. Timekeeping in the Interplanetary internet. (letter report, 2004) [ipin.fm]
13. Parkes, S. CCSDS time critical onboard network service. (undated) [55932.ppt]
14. Rash, J., et al. Internet access to spacecraft. (2000). [small-sat2000paper.doc]
15. Schnurr, R., CCSDS standard on-board interfaces (SOIS) (25 September 2006) [20.ppt]
16. Tai, W. Status of NASA Mars exploration. (June, 2007). [ioag11%20nasa%mars$20exploration%20(tai).pdf]
17. Tai, W. Interoperability for Mars exploration - NASA missions andcommunicastions. (October 2006) [mars%20interop%20(tai).pdf]
18. Time Team. Issues in defining a NASA time architecture, interim report. (21 August 2006). [time team interim report rev081606-1.pdf]
19. Torgerson, L. Network time protocols. (undated). [spacentp.ppt]

    Electra and Advanced Transponder

20. Cook, B., et al. Development of the advanced deep space transponder. IPN Progress Report 42-156 (February 15, 2004).
21. Edwards, C.D., et al. The Electra Proximity link payload for Mars relay telecommunications and navigation. (undated) [032150.pdf]
22. Jedrey, T., and C, Edwards. Using Reed-Solomon on Electra/MRO. Interoffice Memo (27 March 2002).
23. Kuhn, W. A low-volume, low-mass, low-power UHF Proximity micro-transceiver for Mars exploration. Proc. 12th NASA Symposium on VLSI Design, (October 2005).
24. Chapter 2: The Electra Radio. In: Autonomous Software-Defined Radio Receivers for Deep Space Applications, Hamkins, J., and M.K. Simon, Editors, (2006). [descan09_02(electra)-1.pdf]
25. (unknown). Electra Mars Proximity-link communications and navigation payload description. (6 March 2006). [eut_scout_ao_rev_dupdate.pdf]

    Two-way time transfer

26. Davis, J.A., et al. European two-way satellite time transfer experiment using the INTELSAT (VA-FW) satellite at 307 deg E. (undated) [00333317.pdf]
27. Hanson, D.W. Fundamentals of two-way time transfer by satellite. Proc. 43rd Annual Symposium on Frequency Control (1989).
28. Kirchner, D. Two-way time transfer via communication satellites (undated) [00084975.pdf]
29. Landis, P., and I. Galysh. NRL/USNO two-way time transfer modem design. Proc. 1992 IEEE frequency control symposium.

    Deep Space Network

30. Bryant, S, and J. Berner. Operations comparison of deep space ranging types: Sequential tone vs. pseudo-noise. Proc. 2002 IEEE Aerospace Conference, (2002). [01035264.pdf] briefing slides [DS ranging type comparison2001-11-03.pdf]
31. Gatti, M. The Deep Space Network array technology progress, recent results,and future plans. DSN Array Project (briefing slides, no date). [06-0711.pdf]
32. Geldzahler, B. Deep Space Network spectrum management issues. Presentation to the NRC Committee on Radio Frequencies [CORF], May 2003. [CORF_0503-geldzahler.pdf]
33. James, M.L., et al. An autonomous diagnostic and prognostic monitoring system for NASA's Deep Space Network. DSN Array Project, (no citation) [00878428.pdf]
34. Pseudo-noise and regenerative ranging. DSMS Telecommunications Link Design Handbook, March 31, 2004. [214-1.pdf]
35. Radiometric tracking techniques for deep-space navigation. Deep-Space Communications and Navigation Series, J.H. Yuen, Editor-in-Chief. [descanso1_title.pdf]
    
36. Thornton, C.L., and J. S. Borde. Radiometric Tracking Techniques for Deep-Space Navigation. Monograph 1, Deep-Space Communications and Navigation Series, October, 2000.

    Chips and FPGAs

37. Analog Devices datasheet. AD9854: CMOS 300 MSPS quadrature complete DDS.
38. Meyer-Baese, U., et al. Cost-effective Hogenauer cascaded integrator comb decimator filter design for custom ICs. Electronic Letters 41, 3 (February 3, 2005).
39. Mileant, A., et al. The performance of the all-digital data transition tracking loop using nonlinear analysis. Proc. IEEE Transactions on Communications, 43, 2/3/4 (Febuary/March/April 1995), 1202-1215.
    
40. Mitel Semiconductors datasheet. MS13196: Local time management system.
41. Mitel Semiconductors datasheet. MS13544: Reed-Solomon and Convolutional encoder (RESCUE).
42. Tugnawat, Y., and W. Kuhn. Low temperature performance of COTS electronic components for Martian surface applications. (2006) [01655981.pdf]

    Consultive Committee on Space Data Systems (CCSDS)

43. CSDS 130.0-G-2 Overview of Space Communications Protocols. Green Book. Issue 2. December 2007.
44. CCSDS 131.0-B-1 TM Synchronization and Channel Coding. Blue Book. Issue 1. September 2003.
45. CCSDS 132.0-B-1 TM Space Data Link Protocol. Blue Book. Issue 1. September 2003.
46. CCSDS 133.0-B-1 Space Packet Protocol. Blue Book. Issue 1. September 2003.
47. CCSDS 210.0-G-1 Proximity-1 Space Link Protocol--Rationale, Architecture, and Scenarios. Green Book. Issue 1. August 2007.
48. CCSDS 211.0-B-4 Proximity-1 Space Link Protocol--Data Link Layer. Blue Book. Issue 4. July 2006.
49. CCSDS 211.1-B-3 Proximity-1 Space Link Protocol-Physical Layer. Blue Book. Issue 3. March 2006.
50. CCSDS 211.2-B-1 Proximity-1 Space Link Protocol - Coding and Synchronization Sublayer. Blue Book. Issue 1. April 2003.
51. CCSDS 231.0-B-1 TC Synchronization and Channel Coding. Blue Book. Issue 1. September 2003.
52. CCSDS 232.0-B-1 TC Space Data Link Protocol. Blue Book. Issue 1. September 2003.
53. CCSDS 301.0-B-3 Time Code Formats. Blue Book. Issue 3. January 2002.
54. CCSDS 720.1-G-3 CCSDS File Delivery Protocol (CFDP)--Part 1: Introduction and Overview. Green Book. Issue 3. April 2007.
55. CCSDS 727.0-B-4 CCSDS File Delivery Protocol (CFDP). Blue Book. Issue 4. January 2007.