Method for estimating relative skew between clocks in packet networks

[0002] 1. Field of the Invention

[0003] The present invention relates in general to communication systems, and more particularly, to a method and system for measuring/estimating the relative skew between clocks in a packet based communication networks.

[0004] 2. Description of Related Art

[0005] Estimating the relative skew between clocks on different host machines (or referred to network nodes) in a packet network environment, such as the Internet, is relatively new since real-time applications and usage based pricing are relatively new concepts. The issue of measuring one way transit times of packets is becoming increasingly important with the emergence of real-time applications such as voice and video over the Internet. This concept of one-way transit time measurements involves comparing (specifically, taking differences of) times measured with respect to different clocks (e.g. the sender and receiver clocks). Two of the main sources of clock timing discrepancy are offset and skew. Offsets can be readily corrected. The most widely used remedy for clock offsets is a form of synchronization (e.g. using Network Time Protocol (NTP), or Global Positioning System (GPS), etc.). It should be noted, though, this synchronization zeros the clock difference between two clocks at one instant, but the clock skew will inherently cause the clocks to drift apart as time progresses. Accordingly, a clock skew can impose a serious clock timing discrepancy problem for a real-time application.

[0006] Accordingly, there is a need to develop a method to detect/correct clock skews. Specifically, there is a need to develop a method of measuring/estimating the relative skew between clocks on different host machines (or referred to network nodes) in a packet network environment such as the Internet. The present invention provides a solution to the above and other problems and offers advantages over the existing network systems.

[0007] To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method and system for estimating the relative skew between clocks in a packet communication network.

[0008] The present invention provides a method of detecting the existence of a clock skew between two different clocks. The clock offsets are predefined by a separate synchronization mechanism based on Network Time Protocol (NTP) and/or Global Positioning System (GPS) based systems. It is appreciated that other clock synchronization mechanisms can be used within the scope of the present invention.

[0009] In one embodiment of the present invention, a method for determining a clock skew between at least a first and second clocks in a network includes: transmitting a plurality of packets from a first network node to a second network node, each of the packets having a timestamp which records time measured by the first clock at the first network node; receiving one of the packets at the second network node and recording time measured by the second clock at the second network node; obtaining the timestamp of the one packet recorded at the first clock; computing a time delay between a time of transmitting the one packet and a time of receiving the one packet; computing a jitter between the time delay for the one packet and the time delay for a next packet consecutively transmitted after the one packet; averaging jitters after transmitting the plurality of packets; averaging inter-packet times, each of the inter-packet times being a time interval between transmitting two consecutive of the plurality of packets at the first network node; and determining the clock skew by dividing an average of the jitters by an average of the inter-packet times.

[0010] Further in one embodiment, the network is a packet based communication network.

[0011] Still in one embodiment, the time recordings by the first and second clocks are relative to a global clock.

[0012] The present invention is also a system of determining a clock skew between at least a first and second clocks in a network. In one embodiment, the system includes means for transmitting a plurality of packets from a first network node to a second network node, each of the packets having a timestamp which records time measured by the first clock at the first network node; means for receiving one of the packets at the second network node and recording time measured by the second clock at the second network node; and means for determining a clock skew between the first and second clocks based on the timestamps and the time measured by the second clock.

[0013] Further in one embodiment, the clock skew determining means includes means for obtaining the timestamp of the one packet recorded at the first clock; means for computing a time delay between a time of transmitting the one packet and a time of receiving the one packet; means for computing a jitter between the time delay for the one packet and the time delay for a next packet consecutively transmitted after the one packet; a first averager averaging jitters after transmitting the plurality of packets; and a second averager averaging inter-packet times, each of the inter-packet times being a time interval between transmitting two consecutive of the plurality of packets at the first network node; wherein the clock skew is determined by dividing an average of the jitters by an average of the inter-packet times.

[0014] Further, the present invention provides an article of manufacture for a computer-based data processing system, the article of manufacture including a computer readable medium having instructions for causing a computer to perform a method for determining a clock skew between at least a first and second clocks in a network, includes: transmitting a plurality of packets from a first network node to a second network node, each of the packets having a timestamp which records time measured by the first clock at the first network node; receiving one of the packets at the second network node and recording time measured by the second clock at the second network node; obtaining the timestamp of the one packet recorded at the first clock; computing a time delay between a time of transmitting the one packet and a time of receiving the one packet; computing a jitter between the time delay for the one packet and the time delay for a next packet consecutively transmitted after the one packet; averaging jitters after transmitting the plurality of packets; averaging inter-packet times, each of the inter-packet times being a time interval between transmitting two consecutive of the plurality of packets at the first network node; and determining the clock skew by dividing an average of the jitters by an average of the inter-packet times.

[0015] These and various other advantages and features of novelty which characterize the invention are pointed out with particularity in the claims annexed hereto and form a part hereof. However, for a better understanding of the invention, its advantages, and the objects obtained by its use, reference should be made to the drawings which form a further part hereof, and to accompanying descriptive matter, in which there are illustrated and described specific examples of an apparatus in accordance with the invention.

[0016] Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

[0017] FIG. 1 illustrates a schematic view of one skew measurement scheme in a packet based communication network in accordance with the present invention.

[0018] FIG. 2 is a flow chart diagram of one skew measurement scheme to be implemented at a receiver or a destination network node in accordance with the present invention.

[0019] The present invention relates in general to communication systems, and more particularly, to a method and system for measuring/estimating the relative skew between clocks in a packet based communication network.

[0020] In the following description of the exemplary embodiment, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration the specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized as structural changes may be made without departing from the scope of the present invention. It is appreciated that the present invention can be used for real-time applications on Internet or other communication networks.

[0021] The present invention provides a way of measuring/estimating the relative skew between different clocks in a packet based communication network. A preferred method utilizes timestamps available in packets sent from a sender S to a receiver D, as well as the times at which the receiver D receives such packets. The timestamps can be carried in the packet sent from the sender S to the receiver D, such that the timestamps can be read by the receiver's host computer. It is appreciated that the timestamps may be directly implemented in packets or implemented by using a separate protocol so that the same measurement can be performed. Accordingly, a clock skew measurement scheme of the present invention can be integrated into a real-time application or can be used in conjunction with new protocols specifically designed to measure the performance of packet networks such as Internet.

[0022] As defined above, t_grepresents the time measured by a global clock, which is considered as the “true” time; T_irepresents the time measured by a clock i at a network node i. The relation between T_iand t_gis as follows:

[0023] T_i=R_i*t_g+C_i

[0024] where R_iis the skew of clock i with respect to the global clock, and C_iis the offset of the clock i with respect to the global clock at tg=0. In a preferred embodiment, the skew R_iis a constant parameter and does not vary with time. It is appreciated that the skew may vary with time in which cases they may be different.

[0025] In general, clocks on different machines have different skews and offsets with respect to the global clock. As a result, there may be a difference between packet delays measured by the receiver D and the actual delay measured by the global clock. For clear illustration, a time point is defined in a network as follows: T_N,sent,Srepresents the time at which packet N was sent by the host machine of the sender S, and the time is measured by the clock of the sender S. Alternately, the second suffix can be received, and the third suffix can be any host index, such as g representing the global clock, or D representing the receiver's clock.

[0026] From the above definition of times, T_N,sent,S=R_S*T_N,sent,g+C_S. Specifically, this is the timestamp (as, for instance, in the RTP timestamp) marked by S when the sender sends the packet N. Similarly, when the packet N is received at the destination node (i.e. the receiver D), the time that the packet N is received is T_{N,received,D,}(T_N,received,D=R_D*T_N,received,g+C_D). Accordingly, the delay experienced by packet N, measured by the destination node D, is:

[0027] Del_N,D=T_N,received,D−T_N,sent,S.

[0028] It is appreciated that this measured delay coincides with the actual delay, Del_N,gmeasured by the global clock, if and only if (i) RD=RS=1 and (ii) CS=CD.

[0029] The clock timing discrepancy are clock offset and skew. In the preferred embodiment, the present invention determines how much a relative offset between two clocks is. As mentioned in the background of the invention, offsets can be readily corrected by clock synchronization (using NTP, GPS etc.). It should be noted, though, that synchronization merely zeros the clock difference between two clocks at one moment, but the skew causes the clocks to drift apart as time progresses. Thus, the clock skew detection becomes an important issue in resolving clock timing discrepancy problem. A preferred method of detecting clock skew in accordance with the present invention is discussed below in details.

[0030] One of the main ideas behind a preferred method of detecting clock skews is that a sequence of packets transmitted from the source node (sender S) to the destination node (receiver D) are monitored. The delays of the packets are determined by the receiver D. It is appreciated that this paradigm can be used for one which uses a separate protocol to generate this sequence of packets, or for one which just uses data packets (time stamped UDP (User Datagram Protocol) packets, such as ones used by multimedia applications) to dynamically perform this measurement.

[0031] As an example, consider the two consecutive packets N and N+1 which are sent by the sender S to the receiver D. The delay suffered by the two packets are:

[0032] Del_N,D=T_N,received,D−T_N,sent,Sand Del_N+1,D=T_{N+1,received,D}−T_N+1,sent,S,

[0033] respectively. Thus, a jitter measured by the receiver D is:

[0034] J_N+1,D=Del_N+1,D−Del_N,D

[0035] Substituting the detailed definitions of the quantities on the right hand side of this equality,

[0036] J_N+1,D=T_{N+1,received,D}−T_N+1,sent,S−(T_N,received,D−T_N,sent,S)

[0037] =R_D*T_{N+1,received,g}+C_D−(R_S*T_N+1,sent,g+C_S)−((R_D*T_N,received,g+C_D)−(R_S*T_N,sent,g+C_S))

[0038] =R_D*T_{N+1,received,g}−(R_S*T_N+1,sent,g)−((R_D*T_N,received,g)−(R_S*T_N,sent,g))

[0039] Accordingly, the constant offset disappears when jitter is computed. To determine the relative skew Rrel_S,D, the Rrel,_S,D=R_D/R_S. Thus,

[0040] J_N+1,D=R_D*(T_{N+1,received,g}−T_N+1,sent,g−(T_N,received,g−T_N,sent,g))+(R_D−R_S)*(T_N+1,sent,g−T_N,sent,g)

[0041] =R_D*(Del_N+1,g−Del_N,g)+(R_D−R_S)*(T_N+1,sent,g−T_N,sent,g)

[0042] =R_D*(J_N+1,g)+(R_D−R_S)*(T_N+1,sent,g−T_N,sent,g),

[0043] where J_N+1,gis the jitter measured by the global clock. T_N+1,sent,gand T_N,sent,gcan then be rewritten in terms of the timestamp put in by the senders. Thus,

[0044] J_N+1,D=R_D*(J_N+1,g)+(R_D−R_S)*((T_N+1,sent,S−C_S)/R_S−(T_N,sent,S−C_S)/R_S)

[0045] =R_D(J_N+1,g)+(T_N+1,sent,S−T_N,sent,S)*(R_D−R_S)/R_S

[0046] =R_D(J_N+1,g)+(T_N+1,sent,S−T_N,sent,S)*(Rrel_S,D−1).

[0047] Accordingly, the above expression allows one to measure the relative skew Rrel_S,D. By taking averages (ensemble or time averages, either denoted by Eav(.)) on both sides of the above equality, then

[0048] E_av(J_N+1,D)=E_av(T_N+1,sent,S−T_N,sent,S)*(Rrel,_S,D−1),

[0049] where Eav(J_N+1,g)=0. The validity of this fact can be seen in the stochastic sense since a jitter is the difference of two delays, which may be assumed to be identically distributed in the stochastic sense. In the time average sense, the explanation for this is that a non-zero mean can imply that the delays are exploding to infinity (positive average case) or they are going to be zero (negative average case). Now, note that if the source node S is sending packets at some average time interval denoted by T_inter-packet, then

[0050] E_av(J_N+1,D)=T_inter-packet*(Rrel_S,D−1).

[0051] In the above relation, all quantities, except for the relative skew Rrel_S,D,are known. Therefore, the relative skew can be readily dividing the average jitter E_av(J_N+1,D) by the average time interval T_inter-packet. In a preferred embodiment, the time average approach is used. It is appreciated that other average approach, such as ensemble average approach, can be used within the scope of the present invention.

[0052] In accordance with the above scheme, in one embodiment, a sequence of packets are sent from a sender to a receiver. A number of observations are made to obtain a more accurate estimate of the clock skew. The packets can be sent at a fixed intervals of time. It is appreciated, however, that the packets need not be sent at fixed intervals of time since all it is needed is the time average of the timestamps from the sender. Thus, if, for example, a Poisson sampling is used to generate the packet generation times, this method can remain unchanged.

[0053] The above method can be utilized in conjunction with existing applications. Real-time applications, such as some video-conferencing applications, e.g. H.323 (a protocol which enables packet based multimedia communication system) based video-conferencing applications, may need to know timing information, and hence may require the receiver to estimate the relative skew between its clock and the sender's clock. In such a situation, the timestamps available in the Real-time Transport Protocol (RTP) header of the data packets may be sufficient for the receiver to estimate/measure the relative skew. Thus, this method can potentially be integrated into applications.

[0054] One implementation of the above clock skew determination method is described below.

[0055] FIG. 1 illustrates a block diagram of skew measurement scheme in a packet based communication network 100. Packets 102, each having a timestamp 104 (either incorporated in an application or in a separate protocol), are sent from a source node 106 to a destination node 108 over the network 100. The destination node D108 measures the relative skew between a clock 110 at the source node 106 and a clock 112 at the destination node 108 by using a stream of consecutive packets from the source node 106 to the destination node 108.

[0056] The determination of the clock skew is made at the destination node 108 through the use of the relations specified in the equation described before. FIG. 2 shows an operation of the relative skew measurement at the destination node 108. The computation of a clock skew is made at the reception of each packet. The estimate of the overall clock skew becomes more and more accurate as more and more packets are received. It is appreciated that the flow chart shown in FIG. 2 is only for illustration, not for limitation. For example, the sequence of the measuring/estimating steps can be altered within the principles of the present invention.

[0057] In FIG. 2, a packet N+1 is received by a receiver in box 200. The receiver obtains the sender timestamp from the packet meanwhile recording the receiving time in box 202. A delay Del_N+1,Dis determined in box 204. A jitter is then computed in box 206. In box 208, an average jitter and an average inter-packet time are computed by averagers which are commonly used by a person skilled in the art. Finally, a relative skew Rrel_S,Dis determined in box 210.

[0058] Accordingly, the present invention provides a method for measuring/estimating the relative clock skew between network nodes in a packet based communication network. The potential use of such a scheme can be ranged from integration into applications to use by network operators as a performance measurement technique. Further, it is appreciated that the above clock skew measurement technique can be generally used for many other clock skew correction applications.

[0059] The foregoing description of the exemplary embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather by the claims appended hereto.