The present disclosure relates to synchronizing the timing between two devices that are in communication across a network.
There are many applications where two devices communicate with each other across a network to perform various functions. In order to perform those functions, the timing references (e.g., clocks) of the two devices need to be synchronized. There are technologies available to facilitate this timing synchronization. One example of such a technology is the IEEE 1588 standard. This and other timing synchronization protocols require rather complex computations, such as 64-bit arithmetic and/or floating point arithmetic computations.
However, in many real-world deployments, devices are designed with relatively low complexity/capability microprocessors or microcontrollers, such as 16-bit microcontrollers or smaller. These devices are designed for relatively simple applications, such as the case with audio-video bridging (AVB) endpoints that present or capture sound samples. There are other applications where device cost reduction is essential. Therefore, adding the capability to perform timing synchronization would dictate the use of a more expensive microcontroller and this is undesirable because it would lead to higher product costs.
Overview
Techniques are described herein for time synchronization between two devices that communicate with each other across a network, wherein the computations needed for clock synchronization are offloaded from one device to the other, e.g., from a second device (slave) to a first device (master). Messages are received from the first device at a second device. Time of reception values for the messages received at the second device are recorded with respect to a clock of the second device. The second device sends a time value transfer message to an other device, e.g., to the first device or to a third device, wherein the time value transfer message comprises the time of reception values. On the basis of the time of reception values, the first device or the third device computes a clock correction value that represents an offset (time and/or frequency) between a clock of the first device and the clock of the second device, and sends the clock correction value to the second device. The second device then updates or adjusts its clock using the clock correction value. Thus, the second device that is remote from the first device synchronizes to the clock of the first device without having to perform the relatively intensive computations for the clock correction value.
Referring first to
The first and second devices 20 and 30 may be endpoint devices on a network. Several examples of such devices are described hereinafter. However, according to the techniques described herein, the first device 20 and second device 30 are configured so that the second device 30 does not need to perform the mathematical computations necessary to synchronize its timing (e.g., clock) with respect to the timing of the first device 20. Instead, as will become apparent from the following description, the second device 30 offloads the intensive computations necessary for the timing synchronization function to the first device 20. Therefore, the design of the second device 30 can be very low cost because it does not need to perform the intensive computations needed for timing synchronization. The first device 20 is a device that, due to the other functions it is configured to perform, already has the computational capabilities needed for these computations.
The memory 28 is, for example, a tangible processor readable memory medium, and is encoded with or otherwise stores instructions for several software programs, including master clock synchronization logic 100, network protocol stack and operating system logic 200 and sync detector and timestamp generator process logic 300. The CPU executes these software programs to perform the functions described herein. There may also be a clock process logic stored in the memory 28 to perform the function of the clock module 27 as described above.
In particular, the master clock synchronization logic 100 is the core logic executed by the CPU to provide the master clock synchronization functions described hereinafter in conjunction with FIGS. 2 and 4-6. The network protocol stack and operating system logic 200 provides higher level network communication control functions. The sync detector and timestamp generator process logic 300 generates a timestamp to represent time of occurrence (either time of departure or time of reception) of packets either transmitted or received, with respect to a clock value (wall time) generated by the clock module 27. The timestamps are clock values used to represent time of departure values and time of reception values of packets (messages) exchanged between the first and second devices 20 and 30 for purposes of the timing synchronization as will become apparent from the following description.
Similarly, the second device 30 comprises a controller 32 and a network interface module 34. The controller 32 is, for example, a microcontroller or microprocessor, and comprises a CPU 36, a clock module 37 and memory 38. The clock module 37 is configured to generate clock values that are used a timing reference, i.e., wall time, for operations of the second device 30. While
The memory 38 is, for example, a processor readable tangible memory medium, and is encoded with or otherwise stores instructions for several software programs, including slave clock synchronization logic 400, network protocol stack and operating system logic 500 and sync detector and timestamp generator process logic 500. The CPU 36 executes these software programs to perform the functions described herein. In particular, the slave clock synchronization logic 400 is the core logic executed by the CPU 36 to provide the slave clock synchronization functions described hereinafter in conjunction with
The slave clock synchronization logic 400 is configured to allow the second device 30 to offload to the master clock synchronization logic 100 in the first device the intensive computations needed to determine an offset (time and/or frequency) between the clock of the first device 20 and the clock of the second device 30. It is possible that the clock of the second device 30 may become out of sync or offset with respect to the clock of the first device 30 both in time (wall time) and/or in frequency (how fast the clock of the second device 30 counts with respect to the clock of the first device 20). The first device 20 computes a clock correction value representing this (time and/or frequency) offset and sends it to the second device 30. The second device 30 uses the clock correction value to adjust for the time and/or frequency offset and thereby become synchronized to the clock of the first device 20. Since the second device 30 does not perform these intensive computations, the processing capability of the controller 32 needed for the second device 30 can be minimal and thus the cost of the second device 30 reduced.
The second device 30 may be embodied by a relatively “lightweight” endpoint device that does not require advanced microprocessors. In some cases, only an 8-bit or 16-bit microprocessor or microcontroller is sufficient for use in the second device. This is particularly advantageous in minimizing the cost of the second device 30, for example, in radio frequency identification (RFID) sensors, other industrial Ethernet applications, as well as Internet Protocol (IP) based microphones or speakers. In addition, these techniques may be useful in devices such as electrical relays or circuit breakers in a “smart” grid network, where switches or routers are configured as masters, to communicate with the electrical relays or circuit breakers, which are configured as slaves. The electrical relays or circuit breakers therefore require minimal computational capability that in turn reduces their cost. This is particularly desirable if hundreds or even thousands of relays or circuit breakers are deployed in a smart grid network.
On the other hand, the first device (master device) is a device that typically needs relatively substantial computational capability to perform a variety of functions, such as network routing or switching functions. Therefore, the master device has the computation capability to perform the clock correction value computation described herein. The master device is better suited for this computation and the slave devices can be designed with minimal computation power, depending on their specific application, and at least for the timing synchronization function, can rely on the master device to perform the necessary computations for time synchronization.
The logic described herein, e.g., the master clock synchronization logic 100 and the slave clock synchronization logic 400, may take any of a variety of forms, so as to be encoded in one or more tangible media for execution. For example, the logic may be in the form of software code instructions stored or otherwise encoded in a computer or processor readable memory medium for execution by a processor to perform the functions described herein, as shown in
The general operational flow of the timing synchronization process between the first device 20 and the second device 30 is as follows. The second device 30, i.e., the slave, forwards time of reception and/or time of departure values of certain packets/messages sent to or received from the first device 20, to the first device 20, i.e., the master, for computing timing adjustment updates. The first device 20 makes the necessary computations using the time of reception and/or time of departure values received from the second device 30, and sends a message to the second device 30 with a clock correction value. The second device 30 uses the clock correction value to adjust or update its clock, i.e., adjust for a time and/or frequency offset between a clock of the first device 20 and a clock of the second device 30. This process may be repeated on a continuous, periodic or on-demand basis to keep the clock of the second device 30 aligned with the clock of the first device 20. Moreover, as shown in
While
Turning now to
At 110, the time of departure values for the messages with respect to the clock of the first device are recorded. There are several types of outgoing messages that the first device 20 may send, examples of which are described hereinafter in conjunction with
At 130, the first device 20 computes a clock correction value based on the time of reception values (received in the time value transfer message at 120) and the time of departure values (recorded at 110). The clock correction value represents a time and/or frequency offset between the clock of the first device and the clock of the second device. At 140, the first device 20 sends the clock correction value to the second device 30.
Thus, a master device or apparatus is provided that comprises a network interface module configured to transmit and receive messages over a network, a clock module configured to generate clock values, and a controller coupled to the network interface module and the clock module. The controller is configured to: send messages to an other apparatus, e.g., a slave device; store time of departure values for at least some of the messages in terms of clock values of the clock module; receive a time value transfer message comprising time of reception values indicating times of reception of the messages at the other apparatus with respect a clock of the other apparatus; compute a clock correction value based on the time of reception values and the time of departure values, wherein the clock correction value represents an offset (time and/or frequency) between the clock module and the clock of the other apparatus; and send the clock correction value to the other apparatus. The functions of the controller of the master device described herein may also be embodied as a processor readable memory medium storing or encoded with instructions, that when executed by a processor, cause the processor to perform the functions described herein.
Reference is now made to
At 430, the second device generates and sends at least one time value transfer message comprising the time of reception values recorded at 410 and also at 420, if performed.
At 440, the second device receives from the first device the clock correction value computed by the first device (at function 130 in
Thus, a slave device or apparatus is provided that comprises a network interface module configured to transmit and receive messages over a network, a clock module configured to generate clock values, and a controller coupled to the network interface module and the clock module. The controller is configured to: receive messages from an other apparatus, e.g., a master device; store time of reception values for the messages received with respect to the clock module; send to the other apparatus a time value transfer message comprising the time of reception values; receive from the other apparatus a clock correction value computed by the other apparatus device on the basis of the time of reception values, wherein the clock correction value represents a time and/or frequency offset between a clock of the other apparatus and the clock module; and adjust the clock module based on the clock correction value. As will become apparent herein, the controller of the slave device is configured to obtain time of departure values contained in messages received from the master device, and to include these time of departure values in the time value transfer message that is sent to the other apparatus. Furthermore, as described hereinafter in conjunction with
Referring now to
At 432, the second device 30 generates and sends a time value transfer message that contains the time of reception values T2 and T2a (both respect to the slave clock). Using the time of departure values (with respect to the master clock) T1 and T1a and the time of reception values (with respect to the slave clock) T2 and T2a, the first device 20 computes the clock correction value representing the time and/or frequency offset between the slave clock and master clock. This corresponds to the function 130 (
The main IEEE 1588 calculations, for example, are associated with time and/or frequency offset. These would normally be done in the slave device, but with the techniques described herein these computations would be performed outside the slave device, that is, either in the master device or an other device. The specific calculations are not described herein as they are fully described in the IEEE 1588 specification documents. There are also algorithms in the IEEE 1588 standard, for example, to select how to adjust the time and/or frequency offset that is totally dependent on the specific hardware, such as averaging values over numerous samples, e.g., 4, 8, 16, 32 or even 64 samples before computing a correction value. Other calculations may also be developed hereinafter.
At 142, the first device 20 sends a slave time update message containing the clock correction value to the second device 30. The second device 30 uses the clock correction value contained in the slave time update message to update or adjusts its clock. For example, the first device 20 may compute the clock correction value to be +25 μsec, indicating that the slave clock is ahead of the 25 μsec. The second device 30 therefore would adjust for this by adjusting its clock module based on the values sent by the first device 20. For example, if the clock module in the second device 30 is a 64-bit counter, the first device 20 could send a course adjustment that would force that 64-bit value to be changed. Similarly, the first device 20 may send a fine adjustment to the second device 30 that adjusts the frequency of the counter, for example, by adjusting an addend value.
The messages sent at 432 and 142 are not messages required by the IEEE 1588 standard, for example. They are additional messages that the master clock synchronization logic 100 and slave clock synchronization logic 400 are configured to generate and send. Nevertheless, an advantage of the embodiment depicted in
For example, in the context of the IEEE 15888 standard, the first message is a sync message and the second message is a follow-up message. Again, a device configured to operate as a master device in the IEEE 1588 standard, for example, sends a follow-up message a short period of time after a sync message. Thus, a follow-up message is always associated with a preceding sync message. The follow-up message comprises a precise sending time (measured as close to the physical layer of the network, that is, at the network interface module) as possible of the sync message. Thus, whereas the sync message may contain an estimated sending time of when the sync message is sent, the follow-up message contains a much more precise sending time of when the sync message is sent, again, with respect to the master clock.
At 112(1), the first device 20 sends a first sync message followed thereafter by a first follow-up message at 114(1). The second device receives the first sync message at time T2 with respect to the slave clock and records or saves the time of reception value T2. The second device receives the first follow-up message 114(1) which contains a more precise estimate of the time of departure T1 of the first sync message 112(1). The second device records the time of departure value T1 for the first sync message.
A similar process is repeated for the next sync/follow-up message pair shown at 112(2) and 114(2). The second device receives the second sync message 112(2) at time T2a with respect to the slave clock and records the time of reception value T2a. The second device receives the second follow-up message 114(2) that contains a more precise estimate of the time of departure T1a of the second sync message 112(2). The second device stores the time of departure T1a for the second sync message. This process of receiving pairs of sync/follow-up messages is repeated and additional samples may be stored at the second device. However, in general, samples for at least two pairs of sync/follow-up messages are needed.
At 432, the second device sends a time value transfer message containing the recorded time of departure values T1 and T1a of the first and second sync messages and the recorded time of reception values T2 and T2a of the first and second sync messages. The first device then computes the clock correction value from these values and at 142 sends a slave time update message to the second device 30. The second device then updates its clock using the clock correction value.
The delay request/delay response messages are exploited in accordance with the techniques described herein as follows. At 112, the first device 20 sends a sync message and the second device receives the sync message at time T2 with respect to the slave clock. The first device records/saves the time of reception value T2. At 114, the first device 20 sends a follow-up message (containing the time of departure value T1) to the second device 30 and the second device stores the time of departure value T1 of the sync message.
At 422, the second device 30 sends a delay request message to the first device 20. The second device records the time of departure T3 of the delay request message. The first device 20 receives the delay request message at time T4 and at 116 sends to the second device 30 a delay response message containing the time of reception value T4 of the delay request message. Thus, upon receiving the delay response message, the second device has time of reception value T2 of the sync message, time of departure value of the sync message, time of departure value of the delay request message and time of reception value of the delay request message. At 432, the second device 30 sends to the first device 20 a time value transfer message containing these values. The first device 20 computes the clock correction value from these values and at 142 sends a slave time update message containing the clock correction value to the second device 30. The second device 30 updates it clock using the clock correction value.
The master device can communicate with each of a plurality of slave devices to synchronize the clocks of each of the slave devices by communicating, as described above, separately with each slave device to obtain the necessary time values to compute the clock correction value between the master clock and the slave clock for each slave device.
Although the techniques are illustrated and described herein as embodied in one or more specific examples, it is nevertheless not intended to be limited to the details shown, since various modifications and structural changes may be made therein without departing from the scope of the and range of equivalents of the claims.