Introduction
While NTP has been deployed on the seabed, onboard ships and on every continent for the past 28 years, it is probably not widely known that it has been deployed in space almost as long. NTP first flew on an AMSAT Earth satellite in the early 1980s and on another AMSAT satellite in 2000 [RAS 00]. It flew on at least two NASA Shuttle missions and in simulation experiments for future Earth-Moon missions.
The NASA/JPL space community has established three regimes of accuracy requirements, precision (1 ns to 1 ms), fine (1 ms to 1 ms) and coarse (1 ms to 1 s). In space all three regimes require some form of hardware assist, as the errors due to packet transmission times can be relatively large compared to the current Intenet deployment on Earth.
It is vital to understan that spacecraft navigation and timekeeping are intimately entwined. Spacecraft navigation requires many sets of precision position and velocity measurements in order to accurately determine orbital parameters and surface position. Navigation accuracies to the tens of meters can only be achieved by refining repeated observations using radiometric means.
Precision timekeeping in space must account for relativistic effects (red shift and time dilation), as well as satellite motion during measurements (Sagnac effect). In extreme cases timekeeping must account for the effects of the Earth troposphere and ionosphere, the solar wind and the influence of other objects in the solar system.
By far the most important consideration in space timekeeping is that distances and roundtrip times can become huge. A roundtrip to the Moon takes over 2 s, while a roundtrip to Mars takes up to 40 m and a roundtrip to the outer planets of the solar system takes several hours. In principle, NTP can work well in the fine and coarse regimes for the Earth-Moon system and for other planetary systems, but something quite different might be required for missions between planets. However, many of the fundamental algorithms intrinsic in the NTP architecture and protocol suite are well suited for planetary and deep space missions, but packaged in a different way.
The purpose of the time synchronization function in space is to align moving clocks in a gravitational inertial frame to a common timescale. Due to relativity efects, moving clocks in a gravitational field are not syntonic; that is, they do not have a common rate as assumed on Earth. The rates can differ from microseconds per day to milliseconds per day and have both secular and time varying components.
The discourse begins with a discussion on several topics necessary to understand the principles of time transfer in space. It includes an overview of the principles of orbit mechanics and state vectors which determined the position and velocity of a spacecraft relative to an inertial frame. It continues with an overview of general relativity and its effects on clocks moving in a gravitational field. Following this is a description of current spacecraft clocks and then a description of the Proximity-1 protocol used to communicate between spacecraft in the vicinity of Mars and in future the vicinity of the Moon.
Orbit Mechanics
One of the first things to learn about time transfer in space is that everything orbits something else. The Moon and Earth satellits orbit Earth, the Earth and other planets orbit the Sun, and Mars satellites orbit Mars. In most cases considered here, the mass of the planet is large compared to the mass of its satellites, so this presents a two-body problem that can be analyzed with the mathematics of astrodynamic systems as described in [BAT 71], a widely cited textbook used by the U.S. Air Force Academy.
The figure above shows a 3-dimensional rectangular coordinate system with origin the center of the Earth, but does not rotate with it or as it proceeds along its orbit. Later we will interpet this as an inertial frame. The X-Y plane coincides with the Earth mean equator plane. The X axis is the line formed by the intersection of this plane and the plane of the Earth orbit inclined at an angle of about 23.5°. The X axis points to the Sun (more precisely the first point of the constellation Aries) at the vernal equinox, the Y axis points 90° counter-clockwise from it and the Z axis coinciding with the Earth spin axis and completes a right-hand coordinate system. This is called the Geocentric Coordinate Inertial (GEI) system.
In the following, vectors are indicated in boldface. The figure also shows a typical satellite orbit defined by a plane with defined inclination and orientation relative to the equator plane. The position and velocity of a satellite in orbit is defined by a state vector consisting of a 3-element position vector r and a 3-element velocity vector v at a defined epoch t. While the state vector changes over the course of the orbit, the orbit is completely defined by the planet gravity-mass product GM and state vector sampled at any point in the orbit. For Earth, GM = 3.98659x105 kgkm3/s2. State vectors can be determined from Earth or a spacecraft by radiometeric observations of position and velocity at different times in the orbit.
The figure above shows a typical orbit plane with perifocus a major body such as Earth. In the figure a is the semi-major axis, b the semi-minor axis, ra the apoapsis (apogee for Earth) and rp the periapsis (perigee for Earth). The eccentricity is defined
e = (ra – rp) / (ra + rp).
An eccentricity near zero implies a near-circular orbit, while an eccentrity near one implies a highly eccentric orbit. While not of interest here, e = 1 implies a parabolic orbit and e > 1 implies a hyperbolic orbit. Orbits defined in this was are called conic sections.
A state vector defines and also is defined by a set of seven parameters called Keplerian or osculating elements determined for a particular epoch t. For the purposes of this discussion, only three of these elements are relevant: inclination, eccentricity and periapsis. Equatorial orbits have inclinations near 0°; polar orbits have inclinations near 90°. Most satellites have circular orbits with eccentricity near zero; some have highly eccentric orbits with minimuum altitude 800 km and maximum altitude 58,000 km.
Satellites used for planet mapping and weather observation usually operate in circular, polar, low Earth orbit (LEO altitude 800 km) with periods about 2 h. GPS satellites operate in circular, medium inclination, medium Earth orbit (MEO altitude 20,000 km) with period 12 h. Communications and broadcast satellites operate in circular, equatorial, geosynchronous Earth orbit (GEO altitude 36,000 km) with period 24 h.
Similar orbits are possible at Mars and other planets. For example, two Mars orbiters are now in circular, polar orbits at 300-400 km altitude and period about 2 h, while a third is in a hichly eccentric, medium inclination, orbit and period about 7 h. On another page is a method for predicting communitcations opportunitest between these satellites and landers will be presented.
In rinciple then, if we know the state vectors for the solar system planets at a particular time and know the GM of the Sun, we can calculate the planetary postions at some future time and thus the geometry of the ray paths between them. Knowing the distances along a path and the velocity of light, we can determine the time delay, called the light time, and thus set the planetary clocks to a common timescale.
Not so fast...
Relativistic Effects
Time transfer between vehicles in space and on the surface of planets is complicated by the effects of general relativity, including time dilation and redshift relative to an inertial reference frame (IRF). A comprehensive tutorial on general relativity is in [PET 05], while its application to time transer in the solar system is in [NEL 07].
An IRF is a rectangular coordinate system which is non-rotating, free-falling and with origin at the barycenter (zero gravity) of a planetary system. The major advantages using inertial frames is that most frames contain a single massive object, such as the Earth or the Sun, and the other objects of interest have either small mass or are too far away to have influence. Thus, the GEI frame is handy for Earth satellites, but ignores the Moon and the Sun, while the J2000 frame is handy for interplanetary missions. Inertial frames exist for the other planets as well.
Transforming a fixed position on Earth to a moving position in the GEI enertial frame described previously is a tricky business, since the Earth is not completely spherical and its spin axis wobbles due to precession and nutation effects. In the extreme, the Earth is very slowly spinning down and its spin rate itself wobbles due to tidal friction and other effects. As the Earth orbits the Sun, the GEI frame is not inertial for interplanetary missions. Astronomers and spacefarers have adopted an inertial frame called J2000 with GEI orientation and origin the solar system barycenter. Transformations from the GEI to J2000 frames take into account the Earth orbit and eccentricity.
For an object A at position xA moving at velocity vA in an IRF, the clock rate of A relative to a clock at the barycenter is
RA = 1 – vA2 / 2 c2 – U(xA) / c2,
where vA is the velocity in the IRF and U(xA) is the gravitational potential at position xA. Note that for a vector v, v2 = |v||v|, where |v| is the norm of v and is a scalar. The second term on the right is the time dilation effect; the higher the velocity of an object, the slower its clock appears relative to an object at rest in the frame. The third term on the right is the gravitational redshift; the higher the gravitational potential, the slower its clock appears relative to a barycentric clock.
As explained elsewhere, the fundamental timescale for all space missions is based on International Atomic Time (TAI), which is disciplined by a herd of as many as 250 cesium clocks in national laboratories. Proper time on Earth is defined as the time of a clock at sea level, which is called Terrestrial Dynamic Time (TT)
TT = TAI + 32.184,
where the additive term accounts for the offset from Ephemeris Time at a prior epoch. Coordinate time is defined by a clock at the barycenter of the GEI frame. As a clock on the Earth at sea level is moving in the frame, the Earth coordinate clock appears to run fast relative to TT by 60.2 ms per day with diurnal variations of 2.1 ms.. Similar means described later apply to the other planets orbiting the Sun. The J2000 coordinate clock, which reads Barycentric Dynamic Time (TDB), runs fast relative to TT by 1.2 ms/d with annual variations of 1.7 ms.
Time transfer from TT to GEI coordinate time is complicated by polar motion due to precession, in which the Earth north pole precesses over a cycle of about 25.8 thousand years, and nutation with principal affect an 18-year oscillation with amplitude about 1 s [NEL01]. Thus, any transfer from TT to GEI coordinate time must specify an epoch so that these effects can be determined. The astronomical and spacefaring communities have selected 12 h 1 January 2000 (JD 2451545.0) as this epoch, which is commonly known as the J2000 epoch. In principle, the relative timescales for all bodies would have to be integrated from the relativistic formulas since then.
Time dilation causes the GPS clock moving at 3.874 km/s to run slow by 7 ms per day relative to TT because the velocity at orbit is greater than on the surface. Gravitational redshift causes the GPS clock at an altitude of 20,000 km to run fast by 45 ms per day relative to TT because the gravitational potential at orbit is less than on the surface. The net rate 38 ms fast per day is programmed in the spacecraft before launch.
For the most precise timekeeping and navigation, additional effects need to be included. With a GPS orbitl eccentricity of 0.02, there is a relativistic sinusoidal variation in the apparent clock time of 46 ns at the orbital period of 12 h. Also, as mentioned in a later section, a Sagnac correction up to 133 ns must be included, depending on the satellite and receiver postions. Additional corrections are due to ionospheric and tropospheric effects. These corrections must be calculated in the receiver.
Time transfer between Earth and the Moon is subject to the same relativistic effects, except that these effects must be determined relative to the IRF of the Earth-Moon system. On the other hand, proper time on Earth, TT, and proper time on the Moon, called Luner Dynamic Time (LT), is determined by a clock on the surface of the rotating body, which is not an inertial frame.
To simplify analysis without introducing significant errors, we can assume an approximate IRF with origin at the center of the Earth, resulting in Geocentric Coordinated Time (TCG). The procedure is to compute the relativistic effects for time transfer from TT to TCG and in a similar manner transfer LT to TCG. The time difference between a clock on the surface of the Moon and a clock on the surface of Earth is
Considering all relativistic effects, the Moon clock runs slow relative to the Earth clock by 56 ms per day with periodic variations of 0.48 ms at the orbital period of 27.3 d.
Time transfer between Earth and Mars can be determined in a similar way, except that these effects must be determined relative to TDB. The procddure is to compute the relativistic effects for time transfer from Mars Dynamic Time (MT) on the surface to Mars coordinate time and then to TDB. In a similar manner, transfer TT to Earth coordinate time and then to TDB. The time difference between a clock on the Mars surface and a clock on the Earth surface is
Considering all relativistic effects, the Mars clock runs slow relative to the Earth clock by 0.49 ms per day with irregulat variations up to 13.1 ms.
The NASA/JPL space missions represent TDB as ephemeris time (ET), which can be confusing. For historical reasons [NEL 01] JPL mission clocks are reckoned in UTC, which makes time transfer quite awkward. First, the offset L = TAI – UTC is determined using a table of historic leap seconds derived from data provided by the International Earth Rotation Service (IERS). Finally, the ET is determined from relativistic effects as
where K is a constants and e is the eccentric anomaly of the heliocentric orbit of the Earth. This equation, which ignores short-term fluctuations, is accurate to 30 ms.
The eccentric anomaly is given by
where EB is a constant and M is the mean anomaly
where M0 and M1 are constants and t is the number of ephemeris seconds past J2000. The procedure for planets other than Earth is similar, but with different constants.
A quick wit will notice a dragon hiding in the relativistic swamp. The above discussion speaks to frequency wobbles of the cosmic watches due to orbital motion and gravitational phenomena. What might not be clear is that these wobbles change slowly and can be predicted with fashionable accuracy. The trick is to set the watches to a common . We time at some eclectic eoch (J2000) by magical means and then calculate the proper time of each watch at some cosmic event such as a supernova explosion.
Spacecraft Clocks
With few exceptions no two spacecraft are alike. Some have a frightfully expensive Ultra Stable Oscillator (USO) while others have a Sufficiently Stable Oscillators (SSO). Some are powered by photovoltaics, others by the thermal decay of a Plutonium isotope. NASA spacecraft use one kind of spacecraft data bus, ESA spacecraft use another. The ones we are interest in carry a Proximity-1 capable transceiver, which is the means to exchange timestamps used to synchronize spacecraft clocks in the vicinity of Mars.
This section describes a typical spacecraft vehhicle used for science data and telemetry. The emphasis is on those components important to maintain and discipline the spacecraft clock.
The figure above shows a typical spacecraft including a spacecraft computer (SC) a number of science instruments, communications/navigation transceivers and a mission-elapsed time counter, vicariously called SCLK. These devices are interconnected by the 1553 low-speed telemetry bus [MIL 78] and a high-speed data bus (LVDS). In the case of Mars orbiters, the DSN transceiver is used for navigation and comminications with Earth, whle the Proximity-1 transceiver is used for navigation and communications with other vehicles in Mars orbits or on the surface.
The Consulting Committee on Space Data Systems (CCSDS) has produced a set of recommendations on protocols, interfaces and formats. A detailed discussion on the 1553 bus and its influence on spacecraft engineering and standards development is in [KIL 02]. A description of ongoing CCSDS standards work to adapt the OSI reference model to the 1553, SpaceWire and CAN busses is in [PLU xx].
The SCLK is implemented in various ways depending on the particular spacecraft architecture. The most common design consistent with CCSDS time format [CCSDS 301] uses two counters that represent the seconds and fraction since some time before launch. For instance the Mars surface vehicles count only seconds and have no provision for the fraction portion. The NASA Mars orbiters implement a 256-Hz clock, so have eight bits for the fraction portion. If the SCLK fails for some reason, the mission is probably lost, so we assume it is implemented as a separate, ruggedized device accessed via the telemetry bus and runs even when the rest of the spacecraft is shut down during the Martian night.
It appears that ESA spacecraft clocks generate a pulse-per-second (PPS) signal which is sent to all devices as necessary. If resolution less than one second is required, the device implements an interpolation counter phase-locked to the PPS signal.
NASA spacecraft use the low-speed telemetry bus operating at 1 Mbps with 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. In this design the accuracy for time transfers to science instruments via the bus will be limited to order of 1 ms.
For practical and historical reasons, each SCLK counts the elapsed seconds and fraction since some time before liftoff, so each SCLK in the fleet will have a notionally constant offset with respect to any other. However, each SCLK is subject to the whims of environmental extremes, especially temperature changes [TUG 06]. However, orbiters with onboard navigation capability usuall carry a USO or SSO as the budget permits and are mostly immune to frostbite.
On occasion, the uplink telemetry from Earth includes a timestamp which specifies the UTC time upon arrival at the spacecraft. A time offset UTC0 = UTC – SCLK is determined for use later. Subsequently, the value UTC = UTC0 + SCLK represents the current UTC time.
JPL mission databases include what is called the SCLK kernel file which characterizes the clock type, tick interval and a table of clock offsets from UTC and corresponding frequency rate errors. These are in the form of segmented intervals which may or may not be concurrent or continuous, due to differences between mission phases or extended shutdowns during Mars winters. These segments allow scheduling software on Earth to interpolate and adjust telemetry commands and data events with acceptable accuracy.
Proximity-1 Protocol
The CCSDS has defined several protocols for commications over space links. In general, these protocols are designed for use where distance, and thus delays, are very large. On the other hand, our interest here is where distances are relatively small, as with Mars orbiters and landers. The CCSDS has designated the Proximity-1 architecture and protocol [CCSDS 210] for the transmission of commands, telemetry and science data between spacecraft on and near Mars (or the Moon for that matter).
The Proximity-1 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 time tag from the SCLK. In this narrative the term time tag referes to a value derived from the SCLK, while the term timestamp refers to a coordinated time scale such as UTC. This is important since the buffering and coding functions can delay a time tag in the frame data payload many and varying seconds. 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 to 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 time tags be captured at the C&S layer. The C&S time tag 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 time tag 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 time tags and a Receive Parameters SPDU to capture a specified number of local receive time tags. These are retained in buffers for later retrieval as telemetry data. In addition, there is a Time Distribution SPDU to convey time tags from one MAC to another and to broadcast the time.
SPDU frames carry no sequence numbers, so time tags associated with these frames are not useful in the present design. The specification expects that the time tags 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 wiretaps the frame type and sequence number from 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 captures 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 time tags 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 time tags 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 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 SCLK before 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.
Accuracy Expectations
This section considers the accuracy and precision expectations using the Proximity-1 protocol and Electra transceiver implementation [HAM 06]. Note that some discussion in this section reeks of high radiospeak and can be omitted for normal folks.
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 [EDW 03], a smaller, lighter version called Electra Lite and an even smaller, lighter version intended for balloons and aerobots [KUH 05[. These radios operate at UHF frequencies (390-415 and 435-450 MHz) using low-power transmitters and simple antennas. The technology is being continuously improved for the deep space ransceivers [COO 04].
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.
An analog-digital convert (ADC) 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 [MEY 05] 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) [MIL 95] 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.
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 248 / N. Thus, the device can produce any frequency from zero to 75 MHz with resolution of 1 mHz. 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 anyway.
Parting Shots: Proposed Proximity-1 Interleaved Time Service (PITS)
The current method for time synchronization in the Mars spacefleet requires the correlation function for each SCLK to be done on Earth. As the fleet grows, this can put onerous burden on the deep space network and operating procedures. This requires means to accurately measure and exchange time values between the vehicles of the fleet. These means should be an intrinsic, distributed and ubiquitous service of the fleet.
The proposed Proximity-1 Interleaved Time Service (PITS) described in this section does this using the NTP header augmented by the Proximity-1 data link protoco with certain minor modifications. PITS is applicable in NTP-like configurations involving multiple spacecraft and space links. In this design the Earth-disciplined vehicles operate as PITS primary servers and the others as PITS secondary servers and clients as in NTP. However, servers can come and go relatively frequently, depending on Earth telemetry schedule and orbit crosslink opportunities. Appropriate scenarios are described in another section of this document.
The protocol is similar to the NTP interleaved symmetric mode described in NTP Interleaved On-Wire Protocol, but with the NTP header timestamp fields replaced by timestamps determined from Proximity-1 time tags. The protocol can detect lost and duplicate packets and in addition packets that violate the interleaved rules.
In order to avoid conflict with the existing Proximity-1 provisions, we define a new, variable-length Timestamp SPDU (type 3). The C&S sublayer already sniffs the data stream for an expedited frame and captures the time tag and sequence number. In our proposal in addition it sniffs for a Timestamp SPDU and captures a time tag (only). On transmit the C&S recognizes the Timestamp SPDU, captures a time tag from SCLK and saves it in a buffer. On receive the C&S recognizes this SPDU, captures a time tag from SCLK and saves it in a buffer. No sequence numbers are necessary and capture does not need to be enabled - it is always enabled for the Timestamp SPDU.
Timestamp SPDUs are exchanged over the link several times each pass for redundancy and in order to discipline the rate offset, if needed. Only a single buffer is necessary for the transmit time tag and another for the receive time tag, since Timestamp SPDUs are never sent back to back.
The Timestamp SPDU has two 8-octet fields, one for the last transmit timestamp, the other for the last receive timestamp, both converted to UTC format. Ar each end of the link this results in four UTC timestamps which can be used by the PITS protocol described in the next section to compute the relative offset and roundtrip delay as in NTP and the IEEE 1588 Precision Time Protocol (PTP).
PITS Protocol Operations
The PITS state machine is very similar to the NTP interleaved symmetric mode state machine as described in the NTP Interleaved On-Wire Protocol page. Pseudo-code is contained in a companion briefing document NTP Interleaved Protocol for LANs and Space Data Links. While NTP supports an interleaved broadcast mode, this mode is not appropriate for the current Mars spacefleet configuration, but could be considered in a future study.
The basic idea in PITS is that each encapsulated NTP header is accompanied by a Timestamp SPDU. The encapsulating protocol is not of interest here, but it is asumed trasmitted as an exppedited UPDU. The SPDU is transmittet first with the current transmit and received state variables followed by the NTP header with the same variables. Then, the transmit time tag buffer is read, converted to UTC and saved in the transmit state variable for the next message.
Since by protocol the SPDU queue is serviced before the UPDU queues and there are no intermediate forwarding nodes, the SPDU is guaranteed to be received before the NTP header. Upon receiving the NTP header, the receiver reads the receive time tag buffer, converts to UTC and saves in the receive state variable. The transmitter and receiver then proceed using the NTP interleaved symmetric mode protocol operations.
As in NTP interleaved symmetric mode there are two sanity several checks designed to deflect duplicate or unsynchronized frames. In PITS there are additional sanity checks to detect conditions where either or both the SPDU or NTP header are lost. This is done by comparing receive and transmit timestamps in the SPDU and NTP header. If they disagree, both are discarded.
Further Reading
Rocket and Space Technology: Orbital Mechanics
References
[BAT 71] Bate, R.R., et al. Fundamentals of Astrodynamics. Dover Publications, Inc., 1971, 426 pp.
CCSDS 210.0-G-1 Proximity-1 Space Link Protocol--Rationale, Architecture, and Scenarios. Green Book. Issue 1. August 2007.
CCSDS 301.0-B-3 Time Code Formats. Blue Book. Issue 3. January 2002.
[COO 04]Cook, B., et al. Development of the advanced deep space transponder. IPN Progress Report 42-156 (February 2004).
[EDW 03] Edwards, C.D., et al. The Electra Proximity link payload for Mars relay telecommunications and navigation. Proc. 54th International Astronautical Congress (September 2003). [032150.pdf]
[HAM 06] Autonomous Software-Defined Radio Receivers for Deep Space Applications, Chapter 2: The Electra Radio, J. Hamkins and M.K. Simon, Ed., JPL Deep-Space Communications and Navigation Series, 2006.
[KIL 02] Killough, R. Integrating CCSDS and MIL-STD-1553: what you should know. Proc. IEEE 2002 Conference on Aerospace, Vol. 4, 1917-1926.
[KUH 05] 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), 1-5.
[MIL 78] Military Standard. Aircraft Internal Time Division Command/Response Multiplex Data Bus MIL STD 1553. Department of Defense, Washington DC, September 1978, 34 pp.
[NEL 07] Nelson, R.A. Relativistic time transfer in the solar system." Proc. IEEE 2007 Intenational Frequency Control Symposium, 2007 Joint with the 21st European Frequency and Time Forum (May 2007), 1278-1283.
[PET 05] Petit, G., and P. Wolf. Relativistic theory for time comparisons: a review. IOP Metrologia 42 (June 2005), 138-144.
[PLU xx] Plummer, C., et al, Standardising spacecraft onboard interfaces – the CCSDS SOIF activity. (August 2002), 1-10.
