This application claims the benefit of European patent application No. EP 11305345.8, filed Mar. 29, 2011 and the benefit of PCT patent application No. PCT/EP2012/054584, filed Mar. 15, 2012, the respective contents of which are hereby incorporated by reference in their entirety.
The present invention relates to the field of clock synchronisation in packet-switched telecommunications networks. More specifically, the present invention relates to a novel clock module for use with the IEEE 1588-2008 protocol standard.
Several synchronisation sensitive applications in packet-switched networks require methods and related devices for distributing a reference time and/or a reference frequency to several nodes across a network. Moreover, several standards have been developed in order to arrive at interoperable solutions.
One such standard is the IEEE 1588-2008, also known as 1588V2, which presents a hierarchical architecture of clocks organised in successive pairs of master and slave across a network. The 1588V2 standard introduces and defines the concepts of a Boundary Clock (BC) and a Transparent Clock (TC). These concepts consist of 1588V2 features which are added onto a network node, the latter being any network element such as an IP router or an Ethernet switch. For the remainder of the present description, a 1588V2 module (e.g. BC) points specifically to the aforementioned features, but globally also include the supporting network elements (e.g. the IP router) which participate in communicating 1588V2 messages to other distant 1588V2 modules.
As both BC and TC are implemented on a network node which consists of multiple communication ports, they should offer multiple PTP (Precision Time Protocol—another name given to the 1588 protocol) ports. The 1588V2 standard does not impose any specific mapping (e.g. one-to-one mapping) between PTP ports and the supporting network node communication ports. This detail is implementation-specific.
Functionally, a BC does not forward a synchronisation signal (e.g. 1588V2 Event messages). Instead, it recovers the time reference (i.e. timescale of the Grand Master clock) locally and then redistributes this reference down the clock hierarchy. Typically, a BC receives, from its peer master clock, a number of synchronisation messages, typically called PTP messages, and uses those messages to synchronise its own clock. In order to distribute the recovered time reference, it then produces new PTP messages, which are transmitted to its slave(s).
One advantage of BCs is that they are involved in what is known as the Best Master Clock Algorithm (BMCA) in order to determine the best candidate master clock, which is elected as the Grand Master (GM) clock and is positioned at the top of the hierarchical clock architecture. This allows for greater flexibility and for automatic reconfiguration of the clock hierarchical. Conversely, the main disadvantage of using BCs is that they are complex in terms of implementation. Moreover, their related noise accumulation effect is a complex process and is still under study in terms of attainable performance.
A TC, on the other hand, simply receives a PTP message from its master, and forwards it on to its slave. Before forwarding the PTP message to its slave however, the TC modifies a correction field of the PTP message to reflect the time it took for the PTP message, encapsulated within a packet, to transit the TC.
There are several advantages to using TCs. For example, TCs are relatively simple and efficient when compared to BCs (e.g. generally lower noise). On the other hand, TCs do provide some disadvantages as well. One important example of this is that the use of TCs can lead to the infringement of protocol specifications and/or protocol layer separation principles. This is because a TC modifies the header of a PTP message within packet payload, and this, despite the fact that it is not recognized as the destination node of the packet. This is known as “layer violation”.
Whilst the 1588V2 standard has initially specified both types of clock, these technologies are increasingly being perceived as rivals and competing pressures are being put on industrial and research entities to try and promote one or the other.
WO 2008/051123 A1 discloses a method for clock synchronization, wherein the timestamp is updated within a packet.
US 2008/075217 A1 teaches to modify the timestamp in an original synchronization packet on the fly when it passes through either one of the standard interface converters (SIC).
US 2004/258097 A1 discloses passing on a received synchronization telegram to the next node in a cascade structure, wherein each node adds a measure of delay times occurred in the transmission to and processing at that node into the existing signal.
In order to solve the problems associated with the prior art, the present invention provides a method of distributing a time reference to at least one clock in a packet-switched network using a clock module including a slave port, a master port and a local clock, the method comprises the steps of: receiving a first synchronization packet at the slave port, the first synchronization packet comprising a first master clock timestamp and being destined for the clock module;
generating at least one internal signal comprising the first master clock timestamp;
transmitting the at least one internal signal to the master port;
receiving the at least one internal signal at the master port;
determining the internal propagation time of the signal through the clock module;
calculating a second master clock timestamp based on the sum of the first master clock timestamp received with the at least one internal signal at the master port and the determined internal propagation time;
generating a second synchronization packet at the master port comprising the calculated second master clock timestamp; and
sending the second synchronization packet to at least one other clock in the packet-switched network.
In one embodiment, the step of determining the internal propagation time of the signal through the clock module includes the step of selecting a predetermined value of the internal propagation time of the signal.
The step of generating at least one internal signal can comprise the step of generating a real-time signal in which is encoded the first master clock timestamp.
Alternatively, the step of generating at least one internal signal can also comprise the step of generating a following up packet which contains the first master clock timestamp.
In another embodiment, the method further comprises the steps of:
recording a first local time of the local clock at which the first synchronization packet is received by the slave port; and
recording a second local time of the local clock at which the internal signal is received by the master port, and wherein the step of determining the internal propagation time of the signal through the clock module includes subtracting the first local time from the second local time.
Preferably, the step of generating at least one internal signal comprises the step of generating a packet which contains the first master clock timestamp.
The present invention also provides a computer program product comprising computer-executable instructions for performing the above method.
The present invention also provides a clock module for distributing a time reference to at least one clock in a packet-switched network, the clock module comprises:
a local clock;
a slave port arranged to receive a first synchronization packet, the first synchronization packet comprising a first master clock timestamp and being destined for the clock module;
internal signal generating means arranged to generate at least one internal signal comprising the first master clock timestamp;
a master port arranged to receive the at least one internal signal;
internal signal transmitting means arranged to transmit the at least one internal signal internally from the slave port to the master port;
internal propagation time determining means arranged to determine the internal propagation time of the signal through the clock module;
calculation means for calculating a second master clock timestamp based on the sum of the first master clock timestamp received with the at least one internal signal at the master port and the determined internal propagation time;
synchronization packet generating means arranged to generate a second synchronization packet at the master port comprising the calculated second master clock timestamp; and
synchronization packet sending means arranged to send the second synchronization packet to at least one other clock in the packet-switched network.
In one embodiment, the internal propagation determining means includes means arranged to select a predetermined value of the internal propagation time of the signal.
The internal signal generating means can further comprise means for generating a real-time signal in which is encoded the first master clock timestamp.
Alternatively, the internal signal generating means further comprises means for generating a following up packet which contains the first master clock timestamp.
In another embodiment, the clock module further comprises:
recording means arranged to record a first local time of the local clock at which the first synchronization packet is received by the slave port; and
recoding means arranged to record a second local time of the local clock at which the internal signal is received by the master port, and
wherein the internal propagation time determining means is arranged to determine the internal propagation time of the signal by subtracting the first local time from the second local time.
Preferably, the internal signal generating means is arranged to generate a packet which contains the first master clock timestamp.
Preferably, the clock module is further arranged to receive a delay request message from at least one of the at least one other clocks in the packet-switched network and, using the internal propagation time, send a delay response to the at least one of the at least one other clock in the packet-switched network, the delay response being indicative of the transmission delay between the clock module and the at least one of the at least one other clock in the packet-switched network.
Preferably, the first and second synchronisation packets are IEEE 1588V2 packets.
As will be appreciated, the present invention provides several advantages over the prior art. For example, the hybrid clock of the present invention combines the simplicity and predictability of a TC in terms of noise accumulation and the manageability of a BC in terms of automatic reconfiguration (e.g. Best Master Clock Algorithm). Another advantage of the present invention is that it avoids “layer violations” related to TCs.
Several specific and non-limiting embodiments of the present invention will now be described with reference to the accompanying drawings, in which:
In one exemplary embodiment of the present invention, clock module 100 is involved in the BMCA (i.e. the default BMCA or any alternate BMCA), similarly to a BC. Thus, it participates in the hierarchical clock architecture. In such an embodiment, the clock module 100 will have BC-like attributes such as a ClockID, a default DataSet, etc. In this embodiment, the clock module 100 will also send 1588V2 Announce messages, and its ports will be assigned a 1588V2-defined state: Master, Slave or Passive.
Within this clock hierarchy, the clock module 100 receives PTP messages from its peer master clock module and sends other PTP messages (i.e. these messages are new messages with regards to incoming PTP messages) to its peer slave clocks. Within this context, the network node supporting the PTP hybrid module is the destination node of incoming packets (e.g. IP packets) or incoming frames (e.g. Ethernet frames). Thus, no “layer violation” is incurred.
With reference to
In
Upon arrival of the Sync(t1) message at the slave port 101, clock module 100 produces timestamp t2. In the first embodiment of the present invention, clock module 100 encapsulates the Sync(t1) message into internal packet Service_Sync. The Service_Sync packet contains the Sync(t1) message, as well as timestamp t2 and information related to the internal context structure of the clock module 100. The internal context structure consists of a data structure which allows the system to gather (correlated) information related to the PTP flow between a given upstream ‘master’ clock (identified by the master clockID) and downstream ‘slave’ clock (identified by the slave clockID). For instance, the internal context structure stores the related computed delays t2′−t2 and t3−t3′, the clockID of the ‘master’ clock connected to the hybrid module Slave port, the clockID of the ‘slave’ clock connected to the hybrid module Master port, etc.
While the first embodiment described with reference to
When the master port receives the internal Service_Sync packet, the clock module 100 calculates the delay given by the equation t2′−t2, where t2 represents the time at which the Sync(t1) message arrived at the slave port 101 via link 105, and t2′ represents the time at which the internal Service_Sync packet arrived at the master port 102. The clock module 100 then calculates a new timestamp T1, using t1, t2′−t2 and Δ1. As shown in
Accordingly, similarly to a 1588V2 standardized BC, a clock module in accordance with the present invention uses information it receives from an upstream clock to produce a new Synch signal. The advantage of this is that, in terms of the PTP protocol, clock module 100 will be the unique destination node for each Synch message that it uses to propagate timing information. Accordingly, it will be possible for it to de-encapsulate such a Synch message without layer violation. Clock module 100 can also receive other Synch messages from other sources. If such messages are not destined for clock module 100 however, they will not be used to propagate timing information to other clock modules.
Dissimilarly to a 1588V2 standardized BC, there is no need for clock module 100 to use a “time recovery” block or any related filtering algorithms, as the new Sync(T1) message will be based on the grandmaster clock 103 time, propagation delay time Δ1, and resident time t2′-t2. Instead of this novel approach, 1588 standardized BCs receive a plurality of Sync(t1) and use these messages, together with filtering algorithms, to converge towards the reference time. This process is considerably slower and more complex than the method in accordance with the present invention. Moreover, as mentioned above, this process gives rise to low frequency wander accumulation along the synchronisation chain, degrading the synchronization accuracy.
In another operational mode of a clock module 100 in accordance with the present invention, the slave clock 104 can be set for “two-way”. When set in two way mode, a slave clock module will not only receive timing information as described above, but will also request and receive delay information relating to the propagation delay between itself and the upstream clock module 100 it is connected to. An example of this is shown in the timing diagram of
When the two-way mode is deployed at the slave clock 104, the clock module 100 is arranged to execute the same steps as above and will, and is further arranged to execute several additional steps. These operations allow the slave clock 104 to determine the upstream link delay between itself and clock module 100.
With reference to
Clock module 100 then encapsulates the Delay_Req message into an internal packet Service_Delay_Req, which the clock module 100 sends to the slave port 102. The Service_Delay_Req packet contains the Delay_Req message, as well as timestamp t3′ and the internal associated context structure. As described above, the latter allows for gathering computed delays and other correlated information related to the timing information flow across clock module 100.
As is the case for the one-way mode described above, the two-way mode described with reference to the embodiment of
When the slave port receives the internal Service_Delay_Req packet, the clock module 100 calculates the resident time of the Service_Delay_Req message. That is to say the time required for the information contained in the Service_Delay_Req message to be transmitted internally from the master port 101 to the slave port 102. With reference to
When the new Delay_Req message is received at the grandmaster clock 103, the grandmaster produces a timestamp t4, which is included in a PTP Delay_Resp(t4) message that it sends to the slave port 101 of the clock module 100.
Upon arrival of the Delay_Resp(t4) message at the slave port 101, clock module 100 encapsulates the Delay_Resp(t4) message into internal packet
Service_Delay_Resp. The Service_Delay_Resp packet contains the Delay_Resp(t4) message and is sent internally to the master port 102.
When the master port 102 receives the internal Service_Delay_Resp packet, the clock module 100 calculates a new timestamp T4, using t4, t3−t3′ and δ4, t3−t3′ having been previously memorised within the internal context structure. As shown in
With reference to
The Tn4 timestamp (“T4” timestamp related to Slave clock number n) is derived from T14 (“T4” timestamp related to the Slave clock number 1) as Tn4=T14+(tn′−t3′) assuming that the response time (the time between the reception of the Delay_Req and the transmission of the associated Delay_Resp) is constant, for simplicity. Otherwise, a delta has to be measured and taken into account within the Tn4 computation. Thus, Tn4=t4−(t3−t′3)−δ4+(tn′−t′3)=t4−(t3−tn′)−δ4, where tn′ is the timestamp captured by the hybrid clock module 100 at reception of the Delay_Req message from the slave clock n (the equivalent to t3′, though for the slave n). Accordingly, by using this embodiment, it is possible to avoid congestion of Delay_Req and Delay_Resp message at the grandmaster 103.
In this embodiment, the “distributed” or “network” clock module 300 transports the customer timing flow across itself without having to recover each Customer's time reference. Thus, there is no need to implement additional recovery blocks (e.g. several Phase-Lock-Loops) on each network node within the module 300 domain. Consequently, the proposed architecture of clock module 300 can cope with an important number of different customers (each having independent service time-of-day to be transported across the domain). The accuracy of such a method depends on the frequency offset between the Transport Network Operator (TNO) and its related customers.
Functional operations are similar to the first embodiment except that the internal information exchange, meaning the Service_Sync internal packet, is now replaced by an internal physical signal PHY-DL(t1). The physical signal PHY-DL(t1) has a propagation delay Δ2 between the PTP slave port 404 and the PTP master port 403. This delay can be considered as constant over time with regards to the targeted time accuracy, as this is a physical propagation delay. Thus, it can be measured once (e.g. measured at the clock module 400 commissioning or calibrated/engineered during its conception/design) and can be used during the whole operation period of clock module 400. Thus, Δ2 is a known value with regards to all cards within the network node supporting clock module 400.
As soon as it receives the Sync(t1) message, the PTP Slave port sends the PHY-DL(t1) physical signal towards the PTP Master port. The PHY-DL(t1) signal is an internal physical signal which comprises t1. That is to say that the t1 timestamp is embedded or encoded into the PHY-DL(t1) signal. When the master port 403 receives the internal signal PHY-DL(t1), it immediately sends towards the slave clock a Sync(T1) message at detection of PHY-DL(t1) signal. For the purpose of this detection, PHY_DL(t1) signal should embed some specific physical pattern that allows the master port 403 to recognize that it comes from the given PTP slave port 404 (and not another port), also a sequence number can also be encoded as well. The internal physical signal PHY-DL(t1) allows for communication of the t1 and the related context. At reception of this internal signal PHY-DL(t1) by the master port 403, the latter computes the timestamp T1 based on t1, Δ1 and Δ2, T1=t1+Δ1+Δ2. It also creates a new PTP Sync(T1) message in order to communicate the T1 timestamp to the Slave clock. T1 allows the slave clock 409 to synchronize its clock to the grandmaster time reference.
With reference to
In
Upon arrival of the Sync(t1) message at the slave port 504, clock module 500 produces timestamp t2 and sends out an intra-node PHY-DL1 signal as it receives the Sync(t1) message from the grandmaster 508 (or adjacent master clock). The destination of this signal is the output port node 501 (not shown) on the path towards the clock module 500 master port (i.e. master port 503 of node 502). The output port of node 501 then sends an inter-node PHY-DL2 signal as it receives the PHY-DL1 signal. This sequence of receipt, creation and transmission of intra-node and inter-node signals is recreated for every hop in the network 505. As is the case in the previous embodiment, the physical signal PHY-DL1 has a propagation delay Δ2 between the PTP slave port 504 to the PTP master port (not shown) of node 501. Similarly, PHY-DL2 has a propagation delay Δ3 between the PTP master port of node 501 (not shown) and the PTP slave port of node 502 (not shown). Finally, PHY-DL3 has a propagation delay Δ4 between the PTP slave port of node 502 (not shown) and the PTP master port 503 of node 502.
These delays can be considered as constant over time with regards to the targeted time accuracy, as this is a physical propagation delay. Thus, they can be measured once and can be used during the whole operation period of clock module 500. Thus, Δ2, Δ3, Δ4 are known values with regards to all cards within the network node supporting clock module 500. It is noted that if the transmission of the next signal (e.g. PHY-DL2) is not immediate following the reception of the previous signal (e.g. PHY-DL1), then the elapsed time between the two events can be measured by the operating point (e.g. output port of node 501) and communicated to the master port 503.
When signal PHY-DL3 is received at master port 503, the clock module 500 generates a new Sync message Sync(T′1) which estimated time stamp T′1.
In this embodiment, as the different PHY-DL signals do not convey t1 information, this later is communicated via a packet-based method (e.g. Follow-up message) by the slave port 504 to the clock module 500 master port 503. This internal message allows for communicating t1 and the related context (this context having the similar role with regards to the first embodiment) using a packet protocol for more flexibility in term of information size transported (i.e. the number of information bits transported by a physical signal is limited, while PTP timestamps can occupy up to 10 bytes). The new timestamp T1 can then be derived based on t1 and including the clock module 500 resident time (i.e. Δ2, Δ3, Δ4)+the transmit delay Δ1. Finally, T1 is communicated to the slave clock 509 by the clock module 500 via a Follow-up message, thereby completing the second step of the two-step mode. As can be seen from data flow diagram of
A person of skill in the art would readily recognize that steps of various above-described methods can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of said above-described methods. The program storage devices may be, e.g., digital memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also intended to cover computers programmed to perform said steps of the above-described methods.
The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.
The functions of the various elements shown in the Figures, including any functional blocks labelled as “processors”, may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the FIGS. are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.
It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
Number | Date | Country | Kind |
---|---|---|---|
11305345 | Mar 2011 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2012/054584 | 3/15/2012 | WO | 00 | 8/12/2013 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2012/130629 | 10/4/2012 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
6778526 | Brown et al. | Aug 2004 | B1 |
7570078 | Tang et al. | Aug 2009 | B1 |
8971356 | Geva et al. | Mar 2015 | B2 |
20040258097 | Arnold et al. | Dec 2004 | A1 |
20080075217 | Ilnicki et al. | Mar 2008 | A1 |
20090086764 | Lee | Apr 2009 | A1 |
20100020829 | Ruffini | Jan 2010 | A1 |
20100074278 | Dobjelevski et al. | Mar 2010 | A1 |
20100290572 | Garner et al. | Nov 2010 | A1 |
20110002429 | Williams et al. | Jan 2011 | A1 |
20110205886 | Maruyama et al. | Aug 2011 | A1 |
20110314197 | Hashimoto | Dec 2011 | A1 |
20120128011 | Holmeide et al. | May 2012 | A1 |
20130121352 | Shen et al. | May 2013 | A1 |
20130227008 | Yang | Aug 2013 | A1 |
20130308658 | Le Pallec et al. | Nov 2013 | A1 |
Number | Date | Country |
---|---|---|
101114896 | Jan 2008 | CN |
101599894 | Dec 2009 | CN |
101771528 | Jul 2010 | CN |
2008051123 | May 2008 | WO |
Number | Date | Country | |
---|---|---|---|
20140010244 A1 | Jan 2014 | US |