U.S. patent application number 13/924714 was filed with the patent office on 2013-10-24 for method and apparatus for time and frequency transfer in communication networks.
The applicant listed for this patent is James AWEYA, Luis Orozco BARBOSA. Invention is credited to James AWEYA, Luis Orozco BARBOSA.
Application Number | 20130282875 13/924714 |
Document ID | / |
Family ID | 41254746 |
Filed Date | 2013-10-24 |
United States Patent
Application |
20130282875 |
Kind Code |
A1 |
AWEYA; James ; et
al. |
October 24, 2013 |
METHOD AND APPARATUS FOR TIME AND FREQUENCY TRANSFER IN
COMMUNICATION NETWORKS
Abstract
A timing system for time synchronization between a time server
and a time client. The timing system includes a time server for
generating current timestamp information and a time client having a
phase-locked loop driven client clock counter. The time client
periodically exchanges time transfer protocol messages with the
time server over a packet network, and calculates an estimated
client time based on the timestamp information. The phase-locked
loop in the time client receives periodic signals representing the
estimated server time as its input and calculates a signal which
represents the error difference between the estimated server time
and the time indicated by the time client clock counter. The error
difference eventually converges to zero or a given error range
indicating the time presented by the client clock counter, which is
driven by the phase-locked loop having locked onto the time of the
time server.
Inventors: |
AWEYA; James; (Kanata,
CA) ; BARBOSA; Luis Orozco; (Albacete, ES) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
AWEYA; James
BARBOSA; Luis Orozco |
Kanata
Albacete |
|
CA
ES |
|
|
Family ID: |
41254746 |
Appl. No.: |
13/924714 |
Filed: |
June 24, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12114252 |
May 2, 2008 |
8473638 |
|
|
13924714 |
|
|
|
|
Current U.S.
Class: |
709/219 |
Current CPC
Class: |
H03L 7/093 20130101;
H04L 67/02 20130101; H04J 3/0667 20130101; H03L 7/08 20130101; H03L
7/18 20130101 |
Class at
Publication: |
709/219 |
International
Class: |
H04L 29/08 20060101
H04L029/08 |
Claims
1. A method of time synchronization over a packet network between a
time server having a server clock and a time client having a client
clock, the method comprising, at the time client: sending time
transfer protocol messages from the time client to the time server
over a packet network, the time transfer protocol messages
comprising time stamp information; receiving time transfer protocol
messages from the time server over the packet network, the time
transfer protocol messages comprising time stamp information;
identifying time transfer protocol messages within a monitoring
interval having lowest one-way transmission delay based on the time
stamp information; periodically calculating an estimated server
time using time stamp information in the time transfer protocol
messages identified as having lowest one-way transmission delay
within the monitoring interval; and calculating an estimated client
time based on the estimated server time.
2. The method of claim 1, wherein the time stamp information in
each time transfer protocol message sent from the time client to
the time server comprises a respective first time stamp indicating
when that time transfer protocol message was sent from the time
client.
3. The method of claim 2, wherein the time stamp information in
each time transfer protocol message received at the time client
from the time server comprises a respective first time stamp
indicating when a respective associated time transfer protocol
message was sent from the time client, a respective second time
stamp indicating when the respective associated time transfer
protocol message was received at the time server and a respective
third time stamp indicating when the time transfer protocol message
was sent from the time server.
4. The method of claim 3, comprising capturing a respective fourth
time stamp for each time transfer protocol message received at the
time client, the respective fourth time stamp indicating when the
time transfer protocol message was received by the time client.
5. The method of claim 4, wherein periodically calculating an
estimated server time using the time stamp information in time
transfer protocol messages identified as having relatively low
one-way transmission delay comprises calculating the estimated
server time using: first and second time stamps associated with
time transfer protocol messages identified as having lowest one-way
transmission delay within the monitoring interval for transmission
from the time client to the time server; and third and fourth time
stamps associated with time transfer protocol messages identified
as having lowest one-way transmission delay within the monitoring
window for transmission from the time server to the time
client.
6. The method of claim 1, wherein identifying time transfer
protocol messages having lowest one-way transmission delay within
the monitoring interval comprises: capturing time stamp information
generated in a moving time window; and identifying time transfer
protocol messages having lowest one-way transmission delay in the
moving time window based on the captured time stamp
information.
7. The method of claim 6, wherein the moving time window has a
duration long enough to capture at least eight time transfer
protocol message exchanges.
8. The method of claim 1, comprising computing an error signal, the
error signal representing a difference between the estimated server
time and the estimated client time.
9. The method of claim 8, wherein the time client comprises a
phase-locked loop driven client clock counter and the estimated
client time is a time indicated by the client clock counter.
10. The method of claim 9, further comprising transforming the
error signal into a control signal for driving an oscillator, the
oscillator providing a clock frequency for the client clock
counter.
11. The method of claim 8, further comprising, when the error
signal is in a predetermined error range, deeming the estimated
client time to be synchronized with the estimated server time.
12. The method of claim 1, wherein the estimated server time is
recalculated after each exchange of time transfer protocol messages
between the time client and the time server.
13. The method of claim 1, further comprising: receiving time
transfer protocol messages sent by the time client at the time
server; and responsive to receipt of each time transfer protocol
message sent by the time client at the time server, sending a
respective associated time transfer protocol message from the time
server to the time client.
14. The method of claim 13, further comprising: receiving time
transfer protocol messages sent by plural time clients at the time
server; and responsive to receipt of each time transfer protocol
message sent by each time client, sending a respective associated
time transfer protocol message from the time server to that
respective time client.
15. The method of claim 14, further comprising, at each respective
time client: periodically calculating an estimated server time
using time stamp information in time transfer protocol messages
identified as having lowest one-way transmission delay within a
respective monitoring interval; and calculating a respective
estimated client time based on the estimated server time.
16. The method of claim 16, wherein the time stamp information in
each time transfer protocol message sent from each time client to
the time server comprises a respective first time stamp indicating
when that time transfer protocol message was sent from the time
client.
17. The method of claim 16, wherein the time stamp information in
each time transfer protocol message received at each time client
from the time server comprises a respective first time stamp
indicating when a respective associated time transfer protocol
message was sent from a respective time client, a respective second
time stamp indicating when the respective associated time transfer
protocol message was received at the time server and a respective
third time stamp indicating when the time transfer protocol message
was sent from the time server.
18. The method of claim 17, further comprising, at each time
client, capturing a respective fourth time stamp for each received
time transfer protocol message indicating when that time transfer
protocol message was received by the time client.
19. The method of claim 18, wherein periodically calculating an
estimated server time using the time stamp information in time
transfer protocol messages identified as having lowest one-way
transmission delay within a monitoring interval comprises
calculating the estimated server time using: first and second time
stamps associated with time transfer protocol messages identified
as having lowest one-way transmission delay within the monitoring
interval for transmission from the time client to the time server;
and third and fourth time stamps associated with time transfer
protocol messages identified as having lowest one-way transmission
delay within the monitoring interval for transmission from the time
server to the time client.
20. The method of claim 14, wherein identifying time transfer
protocol messages having lowest one-way transmission delay within
the monitoring interval comprises, at each time client: capturing
time stamp information generated in a moving time window; and
identifying time transfer protocol messages having lowest one-way
transmission delay within the moving time window based on the
captured time stamp information.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of U.S. patent
application Ser. No. 12/114,252, filed May 2, 2008, entitled
"METHOD AND APPARATUS FOR TIME AND FREQUENCY TRANSFER IN
COMMUNICATION NETWORKS", the entirety of which is incorporated
herein by reference.
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
[0002] n/a
FIELD OF THE INVENTION
[0003] The present invention relates to time and frequency
synchronization in packet networks and more specifically to a
method and system that incorporates a time transfer protocol and
phase-locked loop (PLL) architecture to address the problem of
packet delay variation (PDV) in packet networks.
BACKGROUND OF THE INVENTION
[0004] With the increasing need for bandwidth, Time Division
Multiplex (TDM) networks face limits in terms of scalability,
operational cost and maintenance. This results in
telecommunications carriers having to replace circuit-based
transport with packet-based (Ethernet) transport to realize cost
and operational efficiencies, meet increasing bandwidth demands
from customers at reasonable price points, bring a new level of
flexibility and dynamic configuration to the network, and offer
more tiered and time-based or on-demand services.
[0005] Synchronization is critical in the transition from
circuit-based TDM networks to packet-based networks and, in turn,
the deployment of Carrier Ethernet technology. One of the technical
challenges holding back the deployment of Carrier Ethernet has been
the requirement for very accurate clock synchronization in the
network between source and destination, which is an absolutely
essential capability for delivering wireless backhaul and leased
line services. Traditionally, these services have been delivered
over synchronous technologies like T1/E1 and SONET/SDH. Ethernet
networks, however, are asynchronous, designed originally to deliver
data and without the need for accurate clock synchronization and
distribution capabilities in the network.
[0006] Without proper frequency synchronization, packet networks
carrying timing-sensitive services can generate excessive jitter
and wander when interfacing to TDM devices. Network-wide frequency
synchronization is a new requirement driven by performance
measurement, service assurance and real-time services in next
generation networks. Service providers need to meet timing
(frequency synchronization) requirements for Circuit Emulation
Services (CES) and other services over packet switched networks
that isolate remote network elements from their source of
synchronization. Mobile operators need to ensure they can support
the synchronization accuracy needed to avoid dropped calls and
maintain quality of service (QoS).
[0007] Time (i.e., time of day or wall-clock) synchronization is
inherently important to the function of communication networks. It
provides a common time reference for all devices (switches,
routers, gateways, etc.) on the network. Without synchronized time,
accurately correlating information between devices becomes
difficult, if not impossible. In the area of network security, if a
network engineer cannot successfully compare logs between each of
the routers and all the network servers, it is very hard to develop
a reliable picture of an incident.
[0008] Presently, timing in telecom networks is delivered over
synchronous technologies like T1/E1, SONET/SDH, and Global
Positioning Systems (GPS). As a result, carriers rely on expensive
solutions such as circuit-based T1/E1 connections and GPS receivers
to ensure accurate synchronization of services across packet
networks. All of these existing timing methods involve considerable
capital investment for hardware at a large number of customer sites
or base stations. For example, a GPS receiver is installed at each
base station and used as a stable clock reference for re-timing the
CES packets between the CES interface and the base station T1/E1
input. The timing signal received by the base station is retimed to
be precise and stable. However, the disadvantage of GPS-based
re-timers is that they involve a substantial cost and
implementation burden. There is the need to equip each base station
with a GPS receiver, involving a significant capital cost. With
several million base stations in the world, the required investment
is substantial. Another concern is that the existing GPS may not be
an acceptable solution for all sites since GPS signals may be weak
indoors or in metropolitan areas. Moreover, some wireless operators
intentionally may not want to use a GPS signal controlled by the
United States.
[0009] For these reasons, telecommunications providers have been
seeking alternative solutions that would eliminate these expenses.
With recent technological developments, a growing possibility has
come to be delivering time and frequency synchronization over the
packet-based network. Such alternative synchronization solutions
over packet technology enable time and frequency synchronization to
be distributed across asynchronous Ethernet, IP, and MPLS packet
networks. Carriers can lower their operating costs by eliminating
GPS receivers and T1/E1 connections, while maintaining high-quality
service for time-sensitive applications.
[0010] Many service providers have looked at Network Time Protocol
(NTP), the most popular protocol for time synchronization over LANs
and WANs. NTP, however, currently does not meet the accuracy
requirements for telecom grade time and frequency synchronization.
The problem is that NTP packets go through the Ethernet physical
and Media Access Control (MAC) layers in the switches or routers
like any other packets, so synchronization is not addressed until
the packets reach the end-system software stack. The
synchronization signals are thus delayed by a non-deterministic
amount depending on the operating system latency.
[0011] Another protocol that promises high accuracy timing delivery
is the IEEE 1588 Precision Time Protocol (PTP). The main obstacle
to the adoption of IEEE 1588 is that the protocol cannot be
seamlessly implemented in current/existing native Ethernet
interface cards. Networks requiring this protocol would have to
replace these cards with IEEE 1588 compliant cards. The result is
the implementation of a protocol that has a cost associated with it
that the network engineer may not be willing to incur.
[0012] Exact time synchronization over packet networks is difficult
to achieve, particularly, when there are uncertainties on
transmission delays in the network, and on processing delays in the
protocol layers of the end-systems. Packet Delay Variation (PDV) is
a main cause of poor clock synchronization in communication
networks. PDV must be properly mitigated when transporting
timing-sensitive traffic over packet networks.
[0013] What is therefore needed is a method and system that allows
end-systems attempting to synchronize with a reference source to
minimize the timing uncertainties, including PDV, in order to allow
the end-systems to remain time and frequency synchronized with the
reference source.
SUMMARY OF THE INVENTION
[0014] The present invention advantageously provides a method and
system for synchronizing time and frequency between a time server
and one or more time clients over a packet network. Time transfer
messages are exchanged between the time server and the time client.
A time transfer protocol at a client governs the receipt and
utilization of timestamp information in order to identify and
discard time transfer messages that experience delay variation. The
protocol then calculates an estimated server time by incorporating
a clock offset calculated from the remaining "clean" timestamp
information. The estimated server time is periodically updated with
each exchange of time transfer protocol messages. A phase-locked
loop in the time client receives the estimated server time as its
input and calculates a signal which represents the error difference
between the estimated server time and the time indicated by a time
client clock counter. The time client clock counter is initially
loaded with the value of the first available estimated server time.
Henceforth, after each error signal generation, an oscillator in a
phase-locked loop having a frequency corresponding to the error
signal, controls and updates the time client clock counter
accordingly. Eventually, the error difference converges to zero or
a given error range indicating the time presented by the client
clock counter, which is driven by the phase-locked loop's
oscillator, has locked onto the time of the time server.
[0015] In one aspect of the invention, a timing system for time
synchronization over a packet network is provided. The timing
system includes a time server having a server clock for generating
current timestamp information, and a time client having a client
clock, the time client having a time estimation mechanism and a
phase-locked loop driven client clock counter. The time client
periodically exchanges time transfer protocol messages with the
time server over the packet network and calculates an estimated
client time based on the timestamp information.
[0016] In another aspect, a method of time synchronization over a
packet network between a time server having a sever clock and a
time client having a client clock is provided, where the time
client has a time estimation mechanism and a phase-locked loop
driven clock counter. The method includes receiving transfer
protocol messages from the time server over a packet network,
receiving timestamp information from the time server, where the
timestamp information is for use in estimating a current clock
offset between the client clock and the server clock and
identifying and discarding time transfer protocol messages that
experience delay variation periodically calculating an estimated
server time, and calculating an estimated client time based on the
estimated server time.
[0017] In yet another aspect of the invention, a timing system for
time synchronization over a packet network is provided. The timing
system includes a time server for generating timestamp information,
the time server having a server clock, and a timing transfer node
in electrical communication with the time server. The timing
transfer node transmits the timestamp information in the form of
time transfer protocol messages to one or more time clients over
the packet network, where the one or more time clients each have a
client clock. The time transfer protocol messages are periodically
exchanged between the time server and the one or more time clients
according to a time transfer protocol.
BRIEF DESCRIPTION OF THE DRAWINGS
[0018] A more complete understanding of the present invention, and
the attendant advantages and features thereof, will be more readily
understood by reference to the following detailed description when
considered in conjunction with the accompanying drawings
wherein:
[0019] FIG. 1 is a block diagram of an exemplary wireline system
architecture for time and frequency constructed in accordance with
the principles of the present invention;
[0020] FIG. 2 is a block diagram of an exemplary wireless system
architecture for time and frequency constructed in accordance with
the principles of the present invention;
[0021] FIG. 3 is a graphical representation of a two-way time
transfer protocol;
[0022] FIG. 4 is a block diagram of the time server/time client
synchronization system constructed in accordance with the
principles of the present invention;
[0023] FIG. 5 is a block diagram illustrating an alternate
embodiment of the time server/time client synchronization system
constructed in accordance with the principles of the present
invention;
[0024] FIG. 6 is a block diagram of the voltage controlled
oscillator of FIG. 4 and FIG. 5;
[0025] FIG. 7 is a graphical representation of the performance
characteristics of the controlled oscillator of FIG. 4 and FIG.
5;
[0026] FIG. 8 is a block diagram illustrating a digital-to-analog
converter controlling the frequency of the voltage controlled
oscillator of FIG. 4 and FIG. 5;
[0027] FIG. 9 is a block diagram of a closed-loop control model of
the time client PLL in accordance with the principles of the
present invention;
[0028] FIG. 10 is another block diagram of the client PLL as a
closed-loop system; and
[0029] FIG. 11 is a block diagram of an analog PLL used in
accordance with the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0030] It is to be understood that both the preceding summary and
the following detailed description are exemplary and explanatory
and are intended to provide further explanation of the invention as
claimed. Neither the summary nor the description that follows is
intended to define or limit the scope of the invention to the
particular features mentioned in the summary or in the description.
The present invention provides a method and system synchronizing
timing between a time server and a time client over a packet
network.
[0031] The present invention can be implemented in a packet network
over which time and frequency are transferred. A central timing
system is provided which consists of a time server and timing
transfer node (e.g., router, switch, gateway, wireless access
point, etc.), and time clients (e.g., router, switch, gateway,
wireless access point, desktop computer, laptop, personal digital
assistant (PDA), VoIP phone, data server, etc.). The communication
between a timer server and one or more time clients can be wireline
or wireless. Communication between the central timing system and
the time clients could be is via several networks such as Ethernet,
IP, PBT, MPLS, WiFi, WiMax, etc. The reference time source could be
GPS or a time server with a stable and accurate clock source such a
Rubidium atomic clock. The functions of the time server are the
generation of the time-critical event information and the current
time information, and transmitting them to the time clients.
[0032] In one embodiment of the invention, two components, a time
transfer protocol for message exchanges between a time server and a
time client, and a Phase-Locked Loop (PLL)/clock architecture at
the time client, are provided. The time transfer protocol allows
messages to be exchanged between a time server and a time client.
After each protocol exchange, the protocol engine in the client
estimates the current time reference at the time server. In the
protocol, timestamp information is transferred between the server
and client to allow the client to identify and discard time
transfer protocol messages that experienced delay variation. The
protocol calculates a clock offset between server and client clocks
and incorporates it in the computation of the time server's current
time.
[0033] The reference input to the PLL can be the instantaneous or
the filtered estimated time of the server. The PLL uses this
estimated time to lock onto the server clock. The PLL has four main
components: a phase detector, a loop filter, an analog controlled
oscillator, and a clock counter. The phase detector computes the
error signal as the difference between the estimated server current
time (reference signal) and the output signal of the PLL which is
the estimated client current time (PLL output). The error signal is
passed on to a loop filter which is responsible for eliminating
possible jitter and noise in the input signal. The filtered error
is then mapped/transformed into a corresponding control signal to
drive the controlled oscillator. The control signal could be
voltage for a voltage controlled oscillator (VCO), or current for a
current controlled oscillator (CCO). The controlled oscillator,
which typically has a center frequency, oscillates at a frequency
which is determined by the output signal of the loop filter.
[0034] Initially, the PLL waits for the first available server
current time estimate. When the first server time is estimated it
is loaded into the clock counter. From this point onward, the PLL
starts to operate in a closed-loop fashion. Each time the server
current time is estimated after a protocol exchange (i.e., at
sampling instant), the error difference between this value and the
current time indicated by the client clock counter is computed.
This error term is sent to the loop filter whose output controls
the frequency of the VCO. The output of the VCO in turn provides
the clock frequency of the time client and also drives the clock
counter. After a period of time, the error term is expected to
converge to zero which indicates the PLL has been locked to the
incoming time base, i.e., time base of the time server.
[0035] Referring now to the drawing figures in which like reference
designators refer to like elements, there is shown in FIG. 1 a
block diagram of a system architecture for a packet network
constructed in accordance with the principles of the present
invention and designated generally as "10". FIG. 1 and FIG. 2 show
an embodiment of a time and frequency synchronization architecture
used in accordance with the present invention. A packet network 12
over which request and response messages may be transmitted between
a time server 14 and time clients 16 can be a wireline
communication system (FIG. 1) or a wireless communication system
(FIG. 2). The architecture is composed of a central timing system,
which includes time server 14 and network nodes (not shown), which
can include but is not limited to routers, switches, gateways,
wireless access points, etc.
[0036] The architecture also includes one or more time clients 16
in communication with time server 14 via the central timing
system's network nodes. Time clients 16 can be any device capable
of receive communication signals including but not limited to
routers, switches, gateways, wireless access points, desktop
computers, laptops, personal digital assistants (PDAs), VoIP
phones, data servers and the like. Communication between the
central timing system and time clients 16 could be via a number of
different types of networks such as but not limited to Ethernet,
Internet Protocol (IP), Provider Backbone Transport (PBT), Multi
Protocol Label Switching (MPLS), WiFi, Worldwide Interoperability
for Microwave Access (WiMax) and the like.
[0037] FIG. 1 represents a wireline system architecture used in
accordance with the principles of the present invention that
achieves time and frequency synchronization in a packet network. A
reference time source 18 could be based on GPS or time server 14,
with a very stable and accurate clock source, such as for example,
a Rubidium atomic clock. The reference time source 18 could also be
taken from a Building Integrated Timing Supply (BITS) which is a
single building master timing supply. BITS generally supplies DS1
and DS0 level timing throughout a Central Office (CO). The BITS
concept minimizes the number of synchronization links entering a
CO, since only the BITS will receive timing from outside the CO.
The time server 14 actual time is represented by S. The time server
clock frequency is represented by f.sub.s and the time client clock
frequency is represented by f.sub.c. The architecture employing the
present invention transfers time to the client and at the same time
makes the client's clock frequency synchronize with the server
clock frequency.
[0038] FIG. 2 illustrates a wireless system architecture used in
accordance with the principles of the present invention that
achieves time and frequency synchronization in a packet network. In
FIG. 2, S represents the time server actual time and C represents
the client clock. The single local clock of the time client 16 is
designated as C=L.sub.dock. In the case where time client 16 has
both a free-running hardware clock and a Phased Lock Loop (PLL)
disciplined clock, these are designated, respectively, as
L.sub.clock and C. The offset of the clock S relative to C at time
t.gtoreq.0 is .theta.(t)=(C(t)-S(t)). This is referred to as the
relative offset. The skew of S relative to C at time t.gtoreq.0 is
.delta.(t)=(C'(t)-S'(t)). This is referred to as the relative skew.
Two clocks are said to be synchronized at a particular moment if
both the relative offset .theta. and skew .delta. are zero. The
ensuing discussion may sometimes refer to the relative offset and
the relative skew simply as offset and skew, respectively.
[0039] The following discussion describes a two-way time transfer
protocol for the exchange of timestamp information between a time
server 14 and a time client 16. This protocol forms a basis for the
Network Time Protocol (NTP) and IEEE 1588 Precision Time Protocol
(PTP). The underlying assumption of this protocol is that both
forward and reverse paths of the client-server communication are
symmetric in fixed communication delay.
[0040] The purpose of a two-way time transfer protocol is to have a
set of client devices determine the offset between time
measurements on their clocks and time measurements on a server
device. For example, if the variable t represents a physical time
reference, for a given client device, the offset .theta.(t) at time
t is defined by .theta.(t)=(C(t)-S(t)), where C(t) represents the
time measured on the client clock at time t, and S(t) represents
the time measured on the server clock at time t. Client devices
periodically exchange messages with the server device to allow each
client clock to recalculate the offset between its clock and the
server clock. This offset will drift with time, and so these
periodic exchanges mitigate the impact of this drift on clock
synchronization.
[0041] An assumption for time transfer is that the exchange of
protocol messages happens over a period of time so small that this
offset can safely be considered constant over this period. Another
assumption is that the transit time of a message going from the
client to a server is equal to the transit time of a message going
from the server to the client. In reality, the forward and reverse
paths have different one-way delays, i.e., have asymmetric delays.
The asymmetric delays are due to asymmetric bandwidths and
asymmetric propagation delays on the two paths. This can happen
when the physical path length, the number of network elements
(switching nodes), or the port loading in each direction differs.
Even when the two paths are symmetric, they may have radically
different delays due to asymmetric queueing. Asymmetric delays are
more prevalent in today's networks because of technologies like
ADSL (having 512 Kbps uplink and 1.5 Mbps downlink) in access
lines. In some scenarios, the issue of asymmetry can be solved by
route pinning techniques where the forward and reverse paths pass
through the same physical links and switching nodes. With route
pinning, the two directions of a route are guaranteed to traverse
the same links and nodes resulting in the "true" minimum delay
(described below) in each direction to be equal. Finally, it is
assumed that both the client and the server can measure the time
they send or receive a message.
[0042] The degree to which these assumptions are enforced in a
particular application determines the accuracy of the offset
measured at a client device. The basic principle for computing the
time offset .theta. and delay d.sub.cs=d.sub.sc=d, between the time
client 16 and server 14, is shown in FIG. 3. In any protocol
transaction, the time client 16 initially sends a request message
20 to the time server 14 that contains the timestamp T.sub.1 that
the message is sent. The server 14 notes the time T.sub.2 it
receives this message and, at a later time, sends a response
message 22 back to the client 16 containing the time T.sub.1 the
client sent the first message, the time T.sub.2 the server received
that message, and the time T.sub.3 that the server sends the
current message 22. The client 16 notes the time it receives this
message T.sub.4. Under the assumption that the delays for the two
paths are symmetric, the following relationships can be
derived:
T.sub.2=T.sub.1-.theta.+d
T.sub.4=T.sub.3+.theta.+d
From these equations, the time client computes a time offset
.theta., and fixed delay d, as follows:
.theta. = ( T 2 - T 1 ) - ( T 4 - T 3 ) 2 ##EQU00001## d = ( T 2 -
T 1 ) + ( T 4 - T 3 ) 2 ##EQU00001.2##
[0043] The degree to which these assumptions are enforced in a
particular application determines the accuracy. In practice, the
delay across the network is not constant, with the i-th packet
experiencing a different delay, d(i), where d(i) can be expressed
as d(i)=d+.epsilon.(i). The variable .epsilon.(i) represents the
sum of the random components contributed by each hop in a
particular packet transmission. The input to the client clock
synchronization algorithm thus includes an error component
corresponding to .epsilon.(i) and must be appropriately filtered to
minimize the deleterious impact of PDV on clock
synchronization.
[0044] In a clock synchronization network, the time server 14
source is a reliable, stable, and accurate reference such as a GPS
or BITS. However, the synchronization performance at time clients
16 depends on several other factors. One of these factors is the
time transfer protocol and settings. The type of time transfer
protocol and its settings (protocol messages per second, one-way or
two-way message transfer, unicast or broadcast/multicast message
distribution, redundancy of time servers, quality level of time
server source, etc.) affect synchronization performance. One-way
transfer is an asymmetric operation that only requires timing
protocol message flow originating in one direction. For example,
consider a timing flow originating at the server clock and
terminating at the client clock. Of the four timestamps {T.sub.1,
T.sub.2, T.sub.3, T.sub.4} in FIG. 3, only two are needed in this
mode {T.sub.3, T.sub.4}. Two-way timestamp operation requires
timing message flow in both directions. Thus, all four timestamps
{T.sub.1, T.sub.2, T.sub.3, T.sub.4} in FIG. 3 are employed in time
synchronization.
[0045] In a two-way time protocol transaction, the timestamp flow
is initiated by one element, typically the client in NTP and server
in IEEE 1588. One-way messaging protocols offer only frequency
distribution while two-way messaging protocols offer both frequency
and time distribution. One-way messaging protocols deliver
frequency information from the server 14 where the frequency is
known. Time distribution protocols are generally two-way (i.e.,
bidirectional) due to the requirement of network traversal delay
measurement (ranging), and they usually assume symmetric (or known
asymmetry) propagation times.
[0046] Synchronization performance is also affected by network
design and its characteristics, such as traffic loading, PDV,
packet losses, reordering of packets, software or hardware
timestamping, etc. Timing equipment with hardware timestamping has
measurement accuracies in the tens of nanoseconds. This makes the
timing hardware a smaller contributor to the overall measurement
errors in the system. PDV significantly degrades clock
synchronization because it introduces variable delays to the travel
time of time transfer protocol messages. Regardless of whether the
network is lightly or heavily loaded, messages are short or long,
or whether the network equipment use priority queueing or not, the
potential for protocol messages to experience delay variations
still exists. Timestamp filtering and minimum (min) delay selection
in addition to the use of robust algorithms can mitigate this
problem.
[0047] Another factor that influences synchronization performance
at time clients 16 is the client clock oscillator. Employing a
high-stability oscillator reduces measurement noise and improves
the ability of the client clock synchronization mechanism to filter
out transmission wander and jitter caused by network impairments
like PDV. Several factors need to be considered when selecting the
client oscillator. First, the quality of the oscillator determines
to a large extent the rate at which clock corrections must be made.
The quality of the oscillator also determines to a large extent the
time constant that can be implemented in any clock recovery loop.
The action of the clock recovery loop can be modeled in terms of a
low-pass filter. That is, the timing information implicit in the
packets (timestamps, times-of-arrival, times-of-departure, etc.) is
processed in such a way that the "dc content" of the resulting
signal contains the true timing information and the rest must be
filtered out.
[0048] When the output of a clock is examined, the high-frequency
content of the clock noise can be attributed to the local
oscillator and the low-frequency content of the clock noise can be
attributed to the reference subject to the low-pass filtering
action of the clock recovery loop. The timing reference input at
the client 16 in the case of packet-based synchronization methods
is "noisy" and the noise is related to the PDV introduced by the
network superimposed upon the clock noise of the server 14.
[0049] Still another factor that influences synchronization
performance at time clients 16 is the clock recovery loop and PLL
control. Advantageously, the present invention employs a
phase-locked loop (PLL) at a time client 16 to measure the phase
difference between its clock and that of the server to generate an
error signal. This error signal is then filtered by the loop filter
to produce a control signal which in turn is used to drive the
client oscillator. The goal is to reduce this error to zero or a
small acceptable error range. The PLL also acts to correct for
server oscillator drift (due to temperature and aging effects,
etc.), and other environmental conditions that affect oscillator
stability. PDV gets passed to the PLL input, and so the larger the
PDV and the more random its noise profile, the more sophisticated
the PLL and its loop filter has to be to accurate synchronized to
the timing reference.
[0050] As discussed below, the observed arrival times of timing
protocol messages at the client 16 are influenced by the frequency
offset (clock phase drift) of the client 16 with respect to the
server 14, and the network PDV. The former factor is tracked (i.e.,
frequency synchronization required), while the later is filtered
out by the client clock synchronization mechanism. The clock
synchronization mechanism also has to be optimized to minimize the
amount of network bandwidth consumed by timing protocol messages.
Furthermore, it is desirable that the synchronization mechanism be
designed to be robust to packet loss, packet reordering, packet
delay, PDV, and infrequent step changes in the network traversal
delays which might be due to rerouting, protection switching, or
network traffic load changes.
[0051] There are a number of tradeoffs on client clock oscillator
stability, time transfer protocol design and setting, and network
design. The more frequent the time client synchronizes, the less
stable the oscillator needs to be. This requires a network that is
less prone to congestion and transmission errors. If timing
messages experience excessive delays, delay variations, or losses,
a reduced synchronization rate (due to a lower rate of transmission
of timing messages), causes the time client 16 to accumulate timing
errors which would degrade the quality of the client clock. Under
progressively heavier load, the timing messages get delayed more,
thus allowing more time for errors to accumulate in the time client
16. When this happens, it is the oscillator type and
characteristics that become the determining factors in the amount
of synchronization time error that accumulates in the client
clock.
[0052] In situations where a high-stability oscillator is not used
at time client 16, or in the absence of an external or physical
layer frequency distribution mechanism like Synchronous Ethernet,
then a higher layer time distribution protocol (e.g., NTP, IEEE
1588, etc.) is used. Note that the time distribution protocols also
perform frequency distribution. Usually the protocol used to
distribute time across the packet network is the same protocol used
to distribute frequency.
[0053] The following discussion focuses on the use of higher layer
time distribution protocols for time and frequency
transfer-over-packet networks. Time distribution messages (i.e.,
packets) are sent from a time server 14 with timestamps measured by
the server clock 18. In the absence of queueing, contention, and
other network impairments, these packets are sent and received by a
time client 16 after a network propagation delay, that is, the
minimum (min) delay. Without queueing and additional delays, all
packets are received after this minimum delay, otherwise, they are
received with variable delay. The time client 16 measures the
arrival times of packets using its local clock but this clock can
have frequency offset with respect to the time server clock. The
observed arrival times differ from the timestamps generated by the
server 14 due to the frequency offset (the difference in frequency
between the client and server clocks) and the travel delay between
server and client, which, in turn is made up of the minimum
(electrical propagation) delay, and the extra delays due to
queueing, contention, etc.
[0054] Therefore, the present invention provides a client clock
synchronization method in order to lock the client clock frequency
f.sub.c to the server frequency f.sub.s and to measure the minimum
(intrinsic) delay, a process referred to as ranging. The accuracy
of the time at the client 16 depends on how accurate the ranging
mechanism determines the time of flight of the timing protocol
messages from the server 14 to the client 16.
[0055] With a stable oscillator at the client end, or the use of a
frequency distribution mechanism such as Synchronous Ethernet,
ranging is still required but the task of locking the client clock
frequency f.sub.c to the server frequency f.sub.s is not necessary.
However, in the absence of a stable frequency source at the client
16, the client time transfer protocol and clock synchronization
mechanisms first have to stabilize the client clock frequency, and
afterwards lock the time. The convergence time is the time to
converge to the desired time accuracy and is the sum of the time to
obtain frequency lock, and the time for the ranging procedure to
converge.
[0056] As noted earlier, the use of Synchronous Ethernet or similar
technology eliminates the first term (the time to obtain frequency
lock), thereby significantly reducing the convergence time for time
synchronization. However, if a higher layer time transfer solution
is adopted that simultaneously adapts frequency and time, then its
convergence time is longer. Once convergence is attained, the time
distribution system works continuously to minimize the steady-state
error. To achieve this, the system continues updating the client
clock frequency, and continues the ranging process to update local
time. The steady-state time error then becomes the sum of the
frequency error (wander) contribution, and the ranging error
(caused by PDV, asymmetry, loss of protocol messages, etc.).
[0057] We now consider only the one-way transfer between the server
and the client, shown in FIG. 3. The timestamp contained in a
packet is indicative of the time at the server 14 when the packet
was generated, but in some cases the timestamp reflects the time of
departure of the packet. The instant of departure/generation of the
i-th packet is designated as T.sub.S(i). The associated timestamp
is denoted by T.sub.3(i). If the source clock is ideal and
timestamping perfectly implemented, then
T.sub.S(i)=T.sub.3(i)=T(i), where T(i) is the true time epoch of
the i-th packet. This packet traverses the network and arrives at
the client at instant denoted as T.sub.C(i). The associated
timestamp is denoted as T.sub.4(i).
[0058] When considering non-ideal timestamping, the current
timestamp of each one of the {T.sub.3, T.sub.4} timestamps is a
combination of the true time epoch T(i) and two error terms and can
be represented as
T.sub.timestamp=T(i)+e.sub.clock+e.sub.timestamp,
where e.sub.clock is a direct contribution of the local clock
error, and e.sub.timestamp is the inaccuracy in the timestamp
process (which can obscure the behavior of the clock). The measured
delay d.sub.m-server.sub.--.sub.client(i) for message i can be
expressed as follows:
d.sub.m.sub.--.sub.server.sub.--.sub.client(i)=T.sub.4(i)-T.sub.3(i),
where
T.sub.4(i)=T(i)+d.sub.server-client(i)+e.sub.client.sub.--.sub.clock+e.s-
ub.client.sub.--.sub.timestamp,
T.sub.3(i)=T(i)+e.sub.server.sub.--.sub.clock+e.sub.server.sub.--.sub.ti-
mestamp,
where d.sub.server.sub.--.sub.client(i) is the server-to-client
delay experienced by the i-th packet. Thus, the
d.sub.m.sub.--.sub.server.sub.--.sub.client(i) can now be expressed
as
d m_server _client ( i ) = d server_client ( i ) + ( e client_clock
- e server_clock ) + ( e client_timestamp - e server_timestamp ) =
d fsc + sc ( i ) + ( e client_clock + e server_clock ) + ( e
client_timestamp - e server_timestamp ) ( 1 ) ##EQU00002##
where d.sub.fsc is the fixed server-to-client delay, and
.epsilon..sub.sc(i) represents the sum of the random components
contributed by each hop in the server-client direction in the i-th
packet transmission.
[0059] The above expressions reveal several properties. First, the
measured delay d.sub.m-server.sub.--.sub.client(i) is biased by the
one-way packet delay d.sub.server.sub.--.sub.client(i). The packet
delay cannot be estimated with one-way delay measurements if the
client clock offset with respect to the server 14 is not known.
One-way time transfer methods cannot establish a client clock
offset. As discussed below, the two-way transfer allows for the
determination of clock offset information. In addition, the packet
delay bias (contributed by .epsilon..sub.sc(i)) can be minimized by
selecting one-way transactions with min delay properties, that is,
using timestamp filtering and minimum delay selection, which is to
be discussed below. Further, the timestamp error at the server 14
and client 16 should be properly constrained for acceptable
operation. This could be done by using hardware timestamping as
described above.
[0060] The above discussion can be extended to the two-way
timestamp transaction. The measured delay in both directions can
then be represented, respectively, by:
d.sub.m.sub.--.sub.client.sub.--.sub.server(i)=d.sub.client.sub.--.sub.s-
erver(i)+(e.sub.server.sub.--.sub.clock-e.sub.client.sub.--.sub.clock)+(e.-
sub.server.sub.--.sub.timestamp-e.sub.client.sub.--.sub.timestamp)
d.sub.m.sub.--.sub.server.sub.--.sub.client(i)=d.sub.server.sub.--.sub.c-
lient(i)+(e.sub.client.sub.--.sub.clock-e.sub.server.sub.--.sub.clock)+(e.-
sub.client.sub.--.sub.timestamp-e.sub.server.sub.--.sub.timestamp)
where d.sub.client.sub.--.sub.server(i) is the client-to-server
delay experienced by the i-th packet. To simplify the discussion,
it is assumed that hardware timestamping is used, as a result the
timestamp errors are negligible. Thus, the offset and round-trip
delay (RTD) can be computed as:
.theta. ( i ) = d m _client _server ( i ) - d m_server _client ( i
) 2 = d client_server ( i ) - d server_client ( i ) 2 + ( e
server_clock - e client_clock ) ##EQU00003## RTD ( i ) = d m_client
_server ( i ) + d m_server _client ( i ) = d client_server ( i ) +
d server_client ( i ) = d fcs + d fsc + cs ( i ) + sc ( i )
##EQU00003.2##
where d.sub.fcs is the fixed client-to-server delay, and
.epsilon..sub.cs(i) represents the sum of the random components
contributed by each hop in the client-server direction in the i-th
packet transmission. The offset represents an estimate of the clock
correction required to align the client time to the server time and
the RTD represents an estimate of the total round-trip path
delay.
[0061] From the above expressions, it can be observed that to
obtain an unbiased offset estimate, the server-client and
client-server path delays must either be known or assumed symmetric
and, an unbiased estimate of the RTD depends on the clock errors
being the same for both directions. If the time between the two
packet exchanges is low then the clock errors can be assumed common
to both transactions.
[0062] Ranging protocols typically function by exchanging request
(RQ) and response (RP) messages, computing round-trip time using
four timestamps, estimating one-way time assuming server-client
path symmetry, and if possible, minimizing PDV effects on time
synchronization by timestamp filtering and min delay selection,
also referred to as minimum gating.
[0063] The motivation for timestamp filtering and minimum delay
selection is that there are some (timing protocol) packets that
traverse the packet network with essentially no queueing delay and
that, these packets can be identified by filtering out packet with
minimum round-trip delay. The approach adopted in NTP is to filter
out transactions with minimal traversal time in both directions
(both client-server and server-client directions).
[0064] NTP maintains a window of the last L transactions (typically
8 for a network connection). For each transaction, both the offset
estimate and the associated round-trip delay are determined. The
overall queueing noise experienced by a packet flow is directly
reflected in the round-trip delay although the magnitude of the
noise in each direction is not known. Selecting low round-trip
delay mitigates the impact of the long-tail delay distributions
experienced in packet networks permitting significant performance
improvements over clock synchronization algorithms with no packet
selection criteria. However, selecting transactions with minimum
round-trip delays is not always sufficient.
[0065] To further highlight the above point, it is assumed that the
probability of minimal delay one-way traversal is p.sub.min. Thus,
the probability of round-trip minimal delay traversal is
p.sub.min.sup.2, which is very small. Therefore, in this example,
there will not be an appreciable portion of transactions with
minimal delay. Thus, identifying a single transaction with minimal
traversal time in both directions is not effective for time
synchronization.
[0066] However, an effective method of selecting two-way
transactions with minimum delay is monitoring the four timestamps
generated by the client and server and noting those with the
minimal difference independently in each direction. The probability
of these two events is p.sub.min and not p.sub.min.sup.2.
[0067] In the scenario described above, it is expected that a
higher portion of the traversal events in each direction can be
identified. This improves the ranging performance and, thus, time
synchronization, since the time client ensures that only two
separate minimal traversal events are used in the regular time
synchronization calculations.
[0068] From the above discussion it can be see that the PDV has a
probability distribution function with a "floor". The floor is the
minimum delay that a packet (or a timing protocol message) can
experience in a given path. This "floor" can be considered to be
the condition where all queues along the path between server and
client are near their minimum when the particular packet is
transmitted. Under normal non-congested loading conditions on the
path, a fraction of the total number of packets will traverse the
network at or near this floor, even though some may experience
significantly longer delays. Under these non-congestion conditions,
store-and-forward operations in high-speed devices effectively
become forwarding efforts with packets forwarded with minimum
delay. In addition, the PDV distribution becomes more concentrated
near this floor, with a relatively large fraction of the total
packets experiencing this "minimum" or "near minimum" delay.
[0069] In reality, the floor of the PDV distribution can be limited
by the physical layer propagation delay (limited by speed of
light), timestamp resolution (hardware timestamping helps here),
delays introduced by data mapping in TDM based transport systems
(e.g., packet over SONET/SDH, xDSL, GFP, etc.), small delay
variations such as PHY clock jitter, backplane clock domain jitter,
etc., or the local clock offset tilt during packet traversal delay
"floor" assessment.
[0070] Thus, there is a notion of a minimum delay for a given
network configuration and all packets between the server 14 and
client 16 will experience no less than this minimum delay. In
particular, under low loading conditions there will be a
significant percentage of packets that experience the minimum
delay. If there are a sufficient number of packets that experience
the minimum delay, then by utilizing just these packets, the client
clock can achieve significantly better time alignment with the
server.
[0071] FIG. 4 and FIG. 5 illustrate high-level block diagrams of
exemplary client clock synchronization architectures in accordance
with the principles of the present invention. Each of these
architectures includes a time client 16 that can be divided into
two components. One component is a minimum delay and clock offset
estimation portion 24 that includes a timing protocol engine 26, a
timestamp filter and minimum delay selection module 28, a clock
offset estimation and sudden minimum delay change detection module
30, and synchronized virtual clock 32. The other component of time
client 16 is a PLL 34 for both frequency and time recovery.
[0072] The PLL 34 is the component in the architectures depicted in
FIGS. 4 and 5 that allows for joint time and frequency recovery at
the time client 14. When two clocks are not synchronized and, more
specifically, have different frequencies, time durations measured
with one clock will be different from the other. The idea is to
tune the oscillator of the PLL 34 such that the time duration
measured by the time client 16 will be consistent with that of the
time server 14, that is, they both have zero offset and skew. In
doing so, the PLL 34 achieves both time and frequency alignment at
the time client 16.
[0073] The reference input to the PLL 34 is the estimated time of
the server S. The PLL 34 uses this estimated time to lock onto the
server clock 18. The following discussion describes the main
functional blocks of the synchronization architectures of the
present invention.
[0074] The timing protocol engine module 26 is responsible for
exchanging request (RQ) messages 20 and response (RP) messages 22
with the time server 14 to obtain the four timestamps {T.sub.1,
T.sub.2, T.sub.3, T.sub.4}. Protocols such as NTP, IEEE 1588 or
variants may be used. The protocols executed here may assume
client-server path symmetry. The module may integrate hardware time
stamping of received and transmitted packets in order to improve
timestamp accuracy. The time transfer protocol may include
cryptographic authentication to prevent accidental or malicious
protocol attacks. Some of the protocol attacks include misleading
timing messages purposely distributed by false time servers, and
man-in-the-middle attacks tampering with valid timing messages.
These attacks could mislead clients 16 and interrupt reliable time
distribution to critical applications.
[0075] The timestamp filter and minimum delay selection module 28
may operate either in a "synchronous" or "asynchronous" mode. In
the "synchronous" mode, a timer is set and, out of all the
traversal events in the timer valid period, the module identifies
one separate minimal traversal event for each direction when timer
expires. In the "asynchronous" mode, out of L traversal events in
each direction, the module identifies one separate minimal
traversal event for each direction. The operation of module 28 is
such that, when there is a significant fraction of the timing
messages that experience essentially no delay, it chooses the one
with minimum delay and discards the others.
[0076] For example, let the arguments of the messages with minimum
delay identified (among all messages in the sampling period) in the
forward direction (RQ.sub.i, i=1, 2, . . . , L) and reverse
direction (RP.sub.j, j=1, 2, . . . , L) be represented,
respectively, as
im = arg { min i ( T 2 , i - T 1 , i ) } , i = 1 , 2 , , L
##EQU00004## jm = arg { min j ( T 4 , j - T 3 , j ) } , j = 1 , 2 ,
, L ##EQU00004.2##
[0077] Then the associated delay and offset are computed as
follows:
d min = ( T 2 , im - T 1 , im ) + ( T 4 , jm - T 3 , jm ) 2
##EQU00005## .theta. min = ( T 2 , im - T 1 , im ) - ( T 4 , jm - T
3 , jm ) 2 ##EQU00005.2##
[0078] The time between d.sub.min and .theta..sub.min computation
is defined as the sampling period (or estimation interval),
T.sub.sp of the system. The choice of the sampling period T.sub.sp
is done in such a way that timestamp filtering and minimum delay
selection will be effective, and the same time, the rate of
protocol messages after timestamp filtering to the client 16 is
sufficient. As discussed above, the quality and type of the
oscillator determines to a large extent the rate at which clock
corrections must be made, or equivalently, the rate of flow of
protocol messages to the client.
[0079] Having obtained the d.sub.min and .theta..sub.min values,
the d.sub.min value is passed to the clock offset estimation and
sudden minimum delay change detection module 30 where a true sudden
minimum delay detection change algorithm determines if there has
been a true change in the minimum delay which might be as a result
of, rerouting, protection switching of a route, etc. In general,
rerouting or protection switching of a route at the physical and/or
packet layers would change the transfer delay of the route. The
sudden minimum delay change mechanism is used to distinguish random
delay spikes from true (intrinsic) minimum delay changes.
Alternatively, since network symmetry is assumed here, either the
forward min delay d.sub.cs=min(T.sub.2,im-T.sub.1,im) or reverse
min delay d.sub.sc min=min(T.sub.4,jm-T.sub.3,jm) can be used in
the change detection method.
[0080] Depending upon the outcome of the sudden minimum delay
change computation, the .theta..sub.min value is low-pass filtered
to obtain {circumflex over (.theta.)}, which is then used for
client time synchronization. The filter value {circumflex over
(.theta.)} may be obtained using a simple Finite Impulse Response
(FIR) filter to more sophisticated filters such as, for example, a
Kalman filter. In one approach, the offset estimate is equal to the
instantaneous values .theta..sub.min obtained after a sampling
period, and the PLL 34 is adjusted to follow the instantaneous
value at the end of each transaction. However, since this
adjustment offset signal could result in an instantaneous phase
step, which could result in the recovered clock at the client to
exceed some or all of the application jitter/wander requirements, a
filtered offset is preferable. A short-length FIR filter is capable
of eliminating phase steps in the recovered clock. The objective is
to produce acceptable jitter and wander accumulation with suitable
PLL bandwidth, gain peaking and noise generation.
[0081] One use of the d.sub.min and .theta..sub.min values in a
change detection mechanism, is described as follows: [0082] IF a
true min delay change is detected THEN [0083] set {circumflex over
(.theta.)} value to min delay value .theta..sub.min at time of
change, discarding all history [0084] ELSE [0085] continue
filtering the .theta..sub.min values to obtain {circumflex over
(.theta.)}
[0086] A fundamental assumption is that packet paths can be viewed
as static over some interval of time, with fundamental changes
occurring infrequently. If the interval of the path update is much
larger than the packet exchange interval, the path can be treated
as constant for a given set of measurements.
[0087] The synchronized virtual clock 32 module converts the clock
offset generated by the local clock 36 into clock estimates for
client applications. The synchronized virtual clock 32 executes a
conversion function applied to the local clock L.sub.clock to
generate the server time estimate S which is the reference time
input to PLL 34 as seen in FIG. 4 and FIG. 5. One such conversion
function is
S(t)=L.sub.clock(t)-{circumflex over (.theta.)}(t)
[0088] for clock offset {circumflex over (.theta.)}(t) estimate
obtained at time t.
[0089] The estimate S (or equivalently, C) needs to be reformatted
before being used by applications on the time client 16. Formatting
involves translation between different representations (e.g.,
converting from seconds after a given reference date to date and
time), changing time zones, etc. Further processing is often needed
when the time needs to be displayed on a computer, mobile device,
etc. This processing may include identification of day of week,
translation to other calendars (e.g., Gregorian, Julian, Hebrew,
Islamic, Persian, Hindu, Chinese), conversion between International
Atomic Time (TAI) and Coordinated Universal Time (UTC), and
flagging of holidays and special dates.
[0090] Time client phase-locked loop (PLL) 34 has as its components
a phase detector 38, a loop filter 40, a controlled oscillator 42,
and a clock counter 44. The phase detector 38 computes the error
signal as the difference between the estimated server current time
(reference signal S) and the output signal of PLL 34 which is the
estimated client current time (PLL output C). The error signal is
passed on to loop filter 40 which is responsible for eliminating
possible jitter and noise in the input signal. The filtered error
is then mapped/transformed by mapping function module 46 in
conjunction with a digital-to-analog converter (DAC) 48 into a
corresponding control signal that drives controlled oscillator 42.
Details of the mapping function module 46 are provided below.
[0091] The control signal could be voltage for a voltage controlled
oscillator (VCO), or current for a current controlled oscillator
(CCO). The controlled oscillator 42, which typically has a center
frequency, oscillates at a frequency which is determined by the
output signal of loop filter 40.
[0092] The PLL 34 serves as a feedback loop that adjusts the
frequency and phase of the controlled oscillator 42 to the discrete
input signal S. Thus, the output C of the controlled oscillator 42
is a continuous-time approximation of the synchronized time S. In
FIG. 4 and FIG. 5, VCO refers broadly to all the categories of
voltage controlled oscillators such as but not limited to a Crystal
Oscillator (XO) or Simple Packaged Crystal Oscillator (SPXO),
Voltage Controlled Crystal Oscillator (VCXO), Temperature
Compensated Crystal Oscillator (TCXO), and Oven Controlled Crystal
Oscillator (OCXO). The oscillator selection has an impact on the
performance of PLL 34 and its ability to meet the required jitter
and wander specification of the intended application. Factors to
consider are frequency accuracy, frequency aging,
frequency-temperature characteristics, short-term frequency
stability, power consumption, size, and price.
[0093] An assumption behind the synchronization architectures is
that for a given clock, the oscillator 42 has a frequency that can
change, but only slowly with time. Real oscillators especially
those used in telecom and high-end applications have well-behaved
short-term frequency stabilities so it is realistic to assume here
that the oscillators used in the architectures have frequencies
that are constant or slow-varying with time. Another assumption is
that the offset .theta., skew .delta. and drift .mu. of the system
are slowly varying functions of time. It is realistic to assume
that these parameters are constant between estimation and control
instants of the PLL 34.
[0094] The clock synchronization architecture depicted in FIG. 4
has both a local free-running clock 36 and a PLL 34. The local
free-running clock 36 is not modified in any way; events happening
on the time client 16 are recorded with the time read from this
unmodified local clock 36. The output of local clock 36 is
designated as L.sub.clock and that of PLL 34 is C. PLL 34 is
considered to be a variable-frequency controlled oscillator, slaved
to a global server clock 18. The actual implementation of PLL 34
may use a hardware clock servo or may be algorithmic.
[0095] If the estimate of S is accurate (based on application
requirements) and PLL 34 is properly designed, then the output
frequency f.sub.OSC of the VCO 42 will track the reference
frequency f.sub.s of the time server 14. Thus, the clock
architecture generates time (S) and frequency (f.sub.OSC)
references that track the references at server 14. Because the
frequency f.sub.OSC of the controlled oscillator 42 is tuned to
match C to S, the characteristics of C exhibit a smooth continuous
profile instead of being piecewise linear. Also, by enhancing any
of the architecture with frequency synthesis functionalities,
multiples and sub-multiples of the nominal frequency of the PLL 34
(e.g., pulse per second (PPS) signal) can be generated for
applications at the time client 16. This is normally the case when
the PLL frequency output is not in the format required for client
applications.
[0096] In the clock architecture described in FIG. 4, the client
node implements a local timescale, i.e., a device clock 36, and
references this timescale in the time transfer messages it
transmits. The device clock 36 is independent, and is typically
driven from a local free-running crystal oscillator 50. The device
clock 36 is not adjusted or servoed to follow a server reference.
However, in FIG. 5, there is no free-running clock but instead a
PLL 34 whose output serves as the local clock. Timing protocol
messages reference this PLL driven clock.
[0097] In the architecture depicted in FIG. 5, PLL 34 output C
(which also serves as the local clock, C=L.sub.clock) is used to
determine the amount by which the time client 16 should adjust its
local clock, (that is, the PLL 34 output). The oscillator control
signal (and its corresponding output frequency f.sub.OSC) is held
constant for a sufficient length of time (the sampling period
T.sub.sp) to allow all protocol transactions between time server 14
and client 16 to complete and to obtain observation data.
[0098] A new control input and corresponding output frequency
f.sub.OSC of the system is then considered valid until the next
synchronization instant. Between control instants, the PLL output
frequency is held constant. The time elapsed between two events,
when enclosing one or more adjustments, cannot be determined
accurately because the PLL 34 cannot keep track of all the
adjustments and their cumulative effect on the local clock
C=L.sub.clock. In addition, the action of adjusting the PLL 34
introduces by itself nondeterministic error because the action of
adjusting the input requires time to produce a steady output.
[0099] Referring still to FIGS. 4 and 5, initially, the PLL 34
waits for the first available server current time estimate S(0) and
loads it into the clock counter 44. From this point onwards, PLL 34
starts to operate in a closed-loop fashion. Each time the server
current time S(n) is estimated (i.e., at discrete sampling instants
n=1, 2, 3, . . . ), the error difference e(n) between this S(n)
value and the current time indicated by the client clock counter
C(n) is computed, e(n)=S(n)-C(n). This error term is sent to the
loop filter 40 whose output controls the frequency of the VCO 42.
The output of the VCO 42 in turn provides the clock frequency of
the time client 16 and also drives a client clock counter 44. The
error term is expected to converge to zero in steady state which
means the PLL 34 has been locked to the incoming time base, i.e.,
time base of the time server 14.
[0100] This client synchronization architecture of the present
invention allows the PLL 34 to resume closed-loop operation even
after interruption of the protocol message exchange while the time
client is still powered up. Interruption of the message exchange
could be due to loss of protocol transaction packets, break in
communication link, or time server temporary unavailable. If, for
whatever reason, time transfer packets are not received, then the
PLL 34 goes into holdover mode. The holdover mode is an operating
condition of a clock in which its local controlled oscillator is
not locked to an external synchronization reference but which is
using storage techniques to maintain its accuracy with respect to
the last known frequency comparison with a synchronization
reference. The stored data is averaged to minimize the effects of
short-term variations, allowing the normal conditions to be
simulated within specifications. Holdover terminates when the
output of the clock is no longer controlled by the data stored from
a previously connected reference. The quality of the holdover
output depends on quality and type of oscillator used. The holdover
mode is different from the free-running mode which is an operating
condition of the clock in which its local oscillator is not locked
to an external synchronization reference, and is using no storage
techniques to sustain its accuracy. If the time client is powered
up again after being powered down, the PLL 34 just loads the most
recent time estimate S(n) into the clock counter 44 and resumes
closed-loop operations again.
[0101] The timestamp filter and min delay selection module 28
records the minimum delay in each direction on the route between
time server 14 and client 16. The "true" minimum delay is equal to
the non-congested intrinsic delay of the server-client route which
in turn depends on the physical path length and the number of
nodes. The nosier or lightly loaded the route is, the easier and
faster the module will find the true minimum delay. A desirable
feature in this operation is to identify true (intrinsic) minimum
delay changes and avoid false minimum delays (spikes, outliers, or
falsetickers) which can produce incorrect clock corrections.
[0102] True minimum delay changes occur, for example, when a
rerouting or protection switching of a route occurs. For example,
any of these conditions can lead to an increase in the transfer
delay, particular, the true minimum delay. Failure to detect such
true changes can give rise to clock offset errors where the current
minimum delay used in clock corrections is far below that truly
existing in the network path. The change detection technique
framework described herein helps to identify when true minimum
delay changes occur in the networks and allows appropriate actions
to be taken for clock correction.
[0103] Change detection is one way of determining when a discrete
change occurs in a given sequence of data points. Change detection
is also a factor in most tracking applications, since it is rarely
true that the system model is truly time-invariant. Some examples
include detecting motion model changes in target tracking,
positioning, navigation, or robot localization problems, using one
or a network of visual, acoustic, or radar sensors; or detecting
abnormal shape changes in computer vision/biomedical image analysis
applications, e.g., detecting abnormal human activities/actions,
abnormal shape changes in heartbeat patterns (usually the first
indicators of cardiovascular disease), or detecting abnormal brain
shape deformations during image-guided surgery. In all of the above
applications, the state (signal of interest) is not directly
observed. The observation is a noise-corrupted and nonlinear
function of the state. Very often, the changed system model is not
known, i.e., the change or abnormality is not characterized. Also,
the change may be a gradual one, e.g., a constant velocity target
slowly accelerating to a higher speed or a sudden one.
[0104] Online detection of a change can be formulated as follows.
Let Y.sub.1.sup.k be a sequence of observed random variables with
conditional densities p.sub..phi.(y.sub.k|y.sub.k-1, . . . ,
y.sub.1). Before the unknown change time t.sub.1, the parameter of
the conditional density .phi. is constant and equal to .phi..sub.0.
After the change, this parameter is equal to .phi..sub.1. In online
change detection, one is interested in detecting the occurrence of
such a change.
[0105] FIG. 6 is a block diagram of the voltage controlled
oscillator (VCO) 42 used to control the client hardware clock
counter 44 in the PLL 34 of time client 16. VCO 42 is an oscillator
that changes its frequency according to a control voltage feed to
its control input. In applications where the control signal for
frequency control is digital, a Digital-to-Analog Converter (DAC)
48 has to be implemented at the input to VCO 42. DAC 48 is a device
for converting digital signals into continuous analog signals. The
converter usually buffers the input so that the output remains the
same until the input changes.
[0106] FIG. 7 illustrates the useful operating range of the VCO
frequency-voltage characteristic curve, which is typically linear.
The VCO 42 oscillates at an angular frequency
.omega..sub.VCO(t)=2.pi.f.sub.VCO(t) which is determined by the DAC
output voltage u(t). The angular frequency of the VCO
.omega..sub.VCO(t) is given by
.omega..sub.VCO(t)=.omega..sub.nom+K.sub.VCOu(t),
where .omega..sub.nom=2.pi.f.sub.nom is the nominal or center
angular frequency of the VCO (expressed in rad/sec), f.sub.nom is
the nominal frequency in Hertz, K.sub.VCO is the VCO gain (in
rad/sec-V). The deviation of the VCO from its center frequency is
.DELTA..omega.(t)=.omega..sub.VCO(t)-.omega..sub.nom=K.sub.VCOu(t).
By definition, the VCO phase .theta..sub.VCO is given by the
integral over the frequency variation .DELTA..omega., that is,
.theta. VCO ( t ) = .intg. 0 t .DELTA..omega. ( x ) x = K VCO
.intg. 0 t u ( x ) x . ##EQU00006##
[0107] In one example, DAC.sub.res=2.sup.L represents the DAC input
resolution, where L is the DAC register length in bits, e.g., L=12
bits. The DAC output (that is, VCO input voltage), defines the VCO
output frequency as shown in FIG. 8. VCO 42 is operating with a
control input DAC.sub.nom which corresponds to the nominal
frequency f.sub.VCO=f.sub.nom. Adding a quantity-DAC.sub.corr to
DAC.sub.nom (i.e., DAC.sub.VCO=DAC.sub.nom-DAC.sub.corr) results in
a decrease in the output frequency, f.sub.VCO=f.sub.nom-.DELTA.f,
whereas adding a quantity+DAC.sub.corr to DAC.sub.nom (i.e.,
DAC.sub.VCO=DAC.sub.nom+DAC.sub.corr) results in an increase in the
output frequency, f.sub.VCO=f.sub.nom+.DELTA.f. Thus, by
appropriately controlling the quantity DAC.sub.corr added to
DAC.sub.nom, the output frequency of the VCO f.sub.VCO can be
controlled accordingly. The mapping function for the PLL 34 with
VCO 42 will be described below.
[0108] A Phased Locked Loop (PLL) is essentially a feedback control
system. Thus, mathematical models (e.g., in the form of transfer
functions) of VCO 42 are needed, along with the phase detector 38
to determine the parameters of the loop filter. Due to the discrete
nature of the PLL 34, its operations are described by linear
difference equations. The z-transform technique is employed to
analyze the general tracking (i.e., steady-state) behavior of the
PLL 34. Under the steady-state assumption, the phase error samples
are small and the general nonlinear difference equation can be
approximated by a linear one which can be solved by the z-transform
technique. When the PLL 34 has acquired lock and is not pulled out
by large phase steps, frequency steps, or phase noise applied to
its reference input, its performance can be analyzed by a linear
model.
[0109] Assuming that the phase error
.theta..sub.e(.theta..sub.e(n)=.theta..sub.s(n)-.theta..sub.OSC(n)
is the difference between the oscillator clock phase
.theta..sub.OSC(n) and the reference clock phase .theta..sub.s(n))
is within a limited range, PLL 34 as a feedback control system can
be further simplified as linear feedback control system. This
assumption is reasonable for most applications since a real PLL has
a bounded and limited locking range (expressed in
parts-per-million, ppm, of the nominal operating frequency),
outside of which locking cannot be guaranteed. The small signal
linear analysis for the PLL 34 is therefore useful for studying
steady-state equilibrium behavior and stability properties under
these same conditions.
[0110] DAC 48 and VCO 42 determine the accuracy of PLL 34. The
following variables are defined as follows:
[0111] u(n)=DAC output voltage (in volts) at discrete time n,
[0112] .DELTA.V.sub.DAC=DAC output voltage range (which is also the
VCO input voltage range)
[0113] DAC.sub.res=DAC range or resolution=2.sup.L, where L is the
DAC register length in bits, e.g., L=12 bits
[0114] Thus, given a filtered error value {tilde over (e)}(n), DAC
48 produces a voltage according to the following formula:
u ( n ) = .DELTA. V DAC DAC res e ~ ( n ) . ##EQU00007##
[0115] The above equation means that the VCO input voltage range
.DELTA.V.sub.DAC is quantized into DAC.sub.res values. It is
assumed that the error value {tilde over (e)}(n) is expressed as an
integer number 0 to DAC.sub.res-1. The z-transform of the
expression is given as
U ( z ) = .DELTA. V DAC DAC res E ~ ( z ) , ##EQU00008##
from which we get the DAC transfer function
G DAC ( z ) = U ( z ) E ~ ( z ) = .DELTA. V DAC DAC res ,
##EQU00009##
and where {tilde over (E)}(z) and U(z) are the z-transforms of
{tilde over (e)}(z) and u(z), respectively.
[0116] Since DAC 48 operates in the discrete-time domain, the
combined DAC/VCO operates also in the discrete-time domain. The
discrete-time equivalence of the VCO equations is
.theta. VCO ( n ) = i = 0 n .DELTA..omega. ( i ) = K VCO i = 0 n u
( i ) ##EQU00010##
Then denoting .THETA..sub.VCO(z) as the z-transform of
.theta..sub.VCO(n), the z-transform of VCO 42 expression is given
by
.THETA. VCO ( z ) = z - 1 K VCO 1 - z - 1 U ( z ) ,
##EQU00011##
from which we get the transfer function of VCO 42 as
G VCO ( z ) = .THETA. VCO ( z ) U ( z ) = z - 1 K VCO 1 - z - 1 .
##EQU00012##
[0117] This expression shows that VCO 42 represents a pure
integrator for phase signals. The operation of PLL 34 tracks the
reference clock and simultaneously rejects short term variations.
From a functional point of view, two requirements are specified for
a system PLL. On is to provide a very stable clock, synchronized to
the external network to run all elements of the system. The other
is to provide a stable clock in case synchronization is lost
(holdover mode). In this case, the feedback loop is open and the
circuit does not behave as a PLL.
[0118] The gain of VCO 42 can be computed from the VCO data sheet
(typically obtained from the VCO supplier). The first requirement
is the determination of the supply voltage(s) of the VCO 42 (this
can be determined from the data sheet). For example, the VCO
circuit can be powered from a unipolar +5V supply. Let the VCO
supply voltage be denoted by U.sub.supply. The VCO control signal u
is usually limited to a range which is smaller than the supply
voltage U.sub.supply. Let u.sub.min and u.sub.max be the minimum
and maximum value allowed for u, respectively.
[0119] VCO 42 is required to generate a frequency
.omega..sub.VCO.sub.--.sub.min when u(n)=u.sub.min, and the
frequency .omega..sub.VCO.sub.--.sub.max when u=u.sub.max. The
angular frequency is determined at u=U.sub.supply/2 which
corresponds to a frequency .omega..sub.nom that is considered as
the center frequency of PLL 34, irrespective of the fact that the
center frequency could be varying (e.g., due to temperature
effects, aging). The VCO gain can be calculated as
K VCO = .omega. VCO_max - .omega. VCO_min u max - u min =
.DELTA..omega. VCO .DELTA. V DAC . ##EQU00013##
[0120] The frequency axis of the VCO characteristics is sometimes
expressed in Hertz instead of radians per second. In this case, the
gain is obtained as
K VCO = 2 .pi. ( f VCO_max - f VCO_min ) u max - u min = 2 .pi.
.DELTA. f VCO .DELTA. V DAC . ##EQU00014##
[0121] Furthermore, if the frequency axis is expressed in
parts-per-million (ppm) of the VCO center frequency, the gain is
calculated as
K VCO = 2 .pi. f nom .DELTA. ppm .DELTA. V DAC , ##EQU00015##
where f.sub.nom is the VCO center frequency and .DELTA.ppm is the
VCO output frequency range in ppm. Note that
.DELTA.f.sub.VCO=f.sub.nom.DELTA.ppm.
[0122] As an alternate to the above individual DAC and VCO models,
a combined DAC/VCO control model is developed. The frequency
resolution f.sub.res of the VCO can be defined as
f res = VCO frequency range DAC range = f nom .DELTA. ppm DAC res .
##EQU00016##
[0123] The DAC input DAC.sub.VCO
(DAC.sub.VCO.epsilon.[0,DAC.sub.res-1]) can be defined as
DAC.sub.VCO(n)=DAC.sub.nom+DAC.sub.corr(n)
where DAC.sub.corr(n) is the DAC/VCO correction factor at discrete
time n, and DAC.sub.nom is the nominal DAC value (corresponding to
the nominal frequency f.sub.nom). The VCO output frequency sampled
at discrete time n can be expressed as
f VCO ( n ) = f res DAC VCO ( n ) = f res [ DAC nom + DAC corr ( n
) ] = f nom + f res DAC corr ( n ) ##EQU00017##
[0124] The above expression corresponds to an angular frequency
.omega. VCO ( n ) = .omega. nom + 2 .pi. f res DAC corr ( n ) =
.omega. nom + K DAC_VCO DAC corr ( n ) = .omega. nom +
.DELTA..omega. ( n ) , ##EQU00018## where ##EQU00018.2## K DAC_VCO
= K OSC = 2 .pi. f nom .DELTA. ppm DAC res ##EQU00018.3##
is the combined DAC-VCO gain. The phase of the VCO .theta..sub.VCO
is given by the integral over the frequency variation
.DELTA..omega.(n)=.omega..sub.VCO(n)-.omega..sub.nom as
.theta. VCO ( n ) = i = 0 n .DELTA..omega. ( i ) = K DAC_VCO i = 0
n DAC corr ( i ) , ##EQU00019##
which is consistent with the DAC and VCO models developed earlier
on.
[0125] T.sub.sp can be defined as the nominal time interval between
S estimation and as the sampling interval of the PLL at the time
client. The sampling interval T.sub.sp is quantized by the nominal
client clock f.sub.nom into M=T.sub.sp/t.sub.nom units, where
t.sub.nom=1/f.sub.nom. That is, computations are made every M PLL
clock pulses. The phase detector (PD) 38 operates at the frequency
f.sub.sp=1/T.sub.sp. The interval T.sub.sp, which is the reference
operating interval for measurement and control at the PLL, is
equivalent to 2.pi. radians or M nominal client clock ticks.
[0126] The characteristics curve of the PD 38 can be represented in
a sawtooth plot of the PD output e versus phase error .theta..sub.e
and would cover phase errors greater than 2.pi. or smaller than
-2.pi.. The curve is periodic with period 2.pi.. The PD output is
ideally linear for the entire range of input phase differences from
-2.pi. to 2.pi. radian and has maximum output at M, since it
assumes steady-state or locked state operations of the PLL, where
the linear control system models apply. Note that in the locked
state, all frequencies are close to their ideal values. In this
state the phase error range [-2.pi.,2.pi.] maps to the error range
[-M,M].
[0127] The slope of the PD characteristic curve is equivalent to
the gain of PD 38. The slope is given by
K PD = M 2 .pi. . ##EQU00020##
When the phase error is restricted to the range
2.pi.<.theta..sub.e<2.pi., the PD output becomes
e ( .theta. e ) = M 2 .pi. .theta. e = K PD .theta. e .
##EQU00021##
[0128] The PD 38 measures the phase difference
.theta..sub.e(n)=.theta..sub.s(n)-.theta..sub.OSC (n) between the
time client PLL 34 controlled oscillator phase .theta..sub.OSC(n)
and the time server (reference) clock phase .theta..sub.s(n) and
develops an output e(n) that is proportional to this phase
difference .theta..sub.e(n). This operation can be expressed as
e(n)=K.sub.PD.theta..sub.e(n)
[0129] The error signal output e(n) is then passed to the loop
filter G.sub.LF(z) to be processed into the filtered error {tilde
over (e)}(n). The transfer function of the phase detector 38 is
given as
G PD ( z ) = E ( z ) .THETA. e ( z ) = K PD = M 2 .pi. ,
##EQU00022##
where E(z) and .THETA..sub.e(z) are the z-transforms of e(z) and
.theta..sub.e(z), respectively.
[0130] The error signal e(n) from phase detector 38 is passed to a
digital loop filter, the output of which is used to adjust the
frequency f.sub.OSC of the oscillator. There are many forms of
filters that can be used as the loop filter. For example, the
digital loop filter could be implemented as a proportional plus
integral (PI) filter having transfer function G.sub.LF (z) given
by
G LF ( z ) = E ~ ( z ) E ( z ) = K + K 2 1 - z - 1 ,
##EQU00023##
where {tilde over (E)}(z) is the z-transform of the filter output
{tilde over (e)}(n), and K.sub.1 and K.sub.2 are the proportional
and integral path gains, respectively. This transfer function is
equivalent to the discrete-time control equation
{tilde over (e)}(n)={tilde over
(e)}(n-1)+(K.sub.1+K.sub.2)e(n)-K.sub.1e(n-1)
[0131] The loop filter 40 being a PI filter yields a second-order
PLL 34. The proportional gain K.sub.1 and the integral gain K.sub.2
determine the filter response. The filter gains K.sub.1 and
K.sub.2, if required, can be adjusted dynamically on the fly, with
greater gain in the startup process for fast locking (acquisition
mode) and smaller gain in steady-state for better stability and
steady-state error (tracking mode).
[0132] FIG. 9 and FIG. 10 are block diagrams illustrating PLL 34
with a well-designed loop filter. PLL 34 can eventually eliminate
the phase difference and make the controlled oscillator output
phase and frequency lock to the reference. FIG. 9 and FIG. 10 show
PLL 34 as a closed-loop feedback control system. The system is a
second-order feedback system due to the first-order low-pass
filter. The main part of loop filter 40 consists of a proportional
path with gain K.sub.1 in parallel with an integral path with gain
K.sub.2.
[0133] As a requirement for developing the linear models, we assume
that the PLL 34 is in the tracking (steady-state) mode with small
phase error about the reference phase. The design is based on the
digitization of a continuous-time system whereby the s-plane poles
and zeros of a specified differential equation are mapped to the
z-plane poles and zeros of a corresponding difference equation
using the matched pole-zero (MPZ) method. PLL 34 utilizes the
sampled-data representation of the signal throughout the loop. This
approach lends itself to implementations using digital signal
processing technology. The critical parameters of PLL 34 are
specified and their influence on loop performance is noted.
[0134] FIG. 11 is a block diagram of an analog PLL 34 used in
accordance with the present invention. The analog or
continuous-time PLL 34 consists of a phase detector 38, a loop
filter 40 and VCO 42. Phase detector 38 can simply be represented
by a constant gain K.sub.PD. VCO 42 can be modeled as a perfect
integrator in the Laplace domain as G.sub.VCO(s)=K.sub.VCO/s, where
K.sub.VCO is its gain. Loop filter 40 can be specified in Laplace
domain as F(s). In the absence of noise, the closed-loop transfer
function and normalized phase error response are specified in the
Laplace domain, respectively, as
H ( s ) = .THETA. VCO ( s ) .THETA. s ( s ) = K PD K VCO F ( s ) s
+ K PD K VCO F ( s ) , and ##EQU00024## .THETA. e ( s ) .THETA. e (
s ) = .THETA. s ( s ) - .THETA. VCO ( s ) .THETA. s ( s ) = s s + K
PD K VCO F ( s ) = 1 - H ( s ) , ##EQU00024.2##
where .THETA..sub.VCO(s), .THETA..sub.s(s), and .THETA..sub.e(s)
are the Laplace transforms of the VCO phase .theta..sub.VCO(t),
reference signal phase .theta..sub.s(t), and phase error
.theta..sub.e(t), respectively.
[0135] The order of the loop is equal to the number of perfect
integrators within the loop structure. Since the VCO 42 is modeled
as a perfect integrator, the loop is at least of order 1. If the
loop filter 40 contains one perfect integrator, then the loop is of
order 2. The order of the loop can be shown to greatly influence
the steady-state performance of the loop. The steady-state phase
error can readily be determined by means of the final value
theorem, i.e.,
lim t .fwdarw. .infin. .theta. e ( t ) = lim s .fwdarw. 0 s .THETA.
e ( s ) = lim s .fwdarw. 0 s 2 .THETA. s ( s ) s + K PD K VCO F ( s
) . ##EQU00025##
[0136] The steady-state error is defined as the deviation of the
VCO phase from the reference after the transient response has died
out. The steady-state error is simply .theta..sub.e(.infin.). It
can be shown that a first-order loop or higher will track an
initial phase offset with zero steady-state error. Moreover, a
second-order system is required to track a frequency step, while a
third-order loop must be employed to track an accelerating phase
with zero steady-state error.
[0137] A second-order lag-lead filter (also known as a
proportional-integral (PI) filter) which has transfer function
F ( s ) = 1 + s .tau. 2 s .tau. 1 , ##EQU00026##
where .tau..sub.1 and .tau..sub.2 are time constants of the filter
is also considered. The filter has a pole at s=0 and therefore
behaves like an integrator. It has infinite gain at zero frequency.
The closed-loop transfer function of PLL 34 with this filter is
obtained by
H ( s ) = 2 .zeta..omega. r s + .omega. n 2 s 2 + 2 .zeta..omega. n
s + .omega. n 2 = 2 .zeta..omega. n s + .omega. n 2 ( s - s 0 ) ( s
- s 1 ) , ##EQU00027##
where .omega..sub.n and .zeta. are the natural frequency and
damping factors, respectively, and are specified in terms of
K.sub.PD, K.sub.VCO, .tau..sub.1 and .tau..sub.2 as
.omega. n = K PD K VCO .tau. 1 , .zeta. = .omega. n .tau. 2 2 .
##EQU00028##
[0138] These two parameters are usually used to specify performance
requirements of a system. The poles of the closed loop system
are
s.sub.0,1=-.zeta..omega..sub.n.+-.j.omega..sub.n {square root over
(1-.zeta..sup.2)}.
[0139] When .zeta.>1, the poles are real; and when .zeta.<1,
the poles are complex and conjugate. When .zeta.=1, the poles are
repeated and real and the condition is called critical damping.
When .zeta.<1, the response is underdamped and the poles are
complex. The transient response of the closed-loop system is
increasingly oscillatory as the poles approach the imaginary axis
when .zeta. approaches zero. The above model can be directly
applied to the PLL in the continuous-time domain. But for systems
based on sampled data, discrete-time models have to be used.
[0140] A linearized, time-invariant, approximate transfer function
for the entire PLL 34 can be derived based on the conditions that
nonlinearity of the system quantization is neglected. The z-domain
representation of the phase detector 38, loop filter and the
controlled oscillator are given, respectively, as
G.sub.PD(z)=K.sub.PD,
G LF ( z ) = K 1 + K 2 1 - z - 1 = ( K 1 + K 2 ) z - K 1 z - 1 , G
OSC ( n ) = K OSC z - 1 1 - z - 1 = K OSC z - 1 . ##EQU00029##
[0141] Using these transfer functions, the closed-loop transfer
function of the PLL 34 becomes
H ( z ) = G PD ( z ) G LF ( z ) G OSC ( z ) 1 + G PD ( z ) G LF ( z
) G OSC ( z ) , or ##EQU00030## H ( z ) = K PD K OSC ( K 1 + K 2 )
z - K PD K OSC K 1 z 2 + [ K PD K OSC ( K 1 + K 2 ) - 2 ] z - ( K
PD K OSC K 1 - 1 ) . ##EQU00030.2##
[0142] The MPZ can be applied to th H(s) to obtain a discrete-time
system H.sub.2(z) that is of form (or relates to the discrete
transfer function) H(z). From this relationship, closed form
expressions for the loop filter gains K.sub.1 and K.sub.2 can be
derived.
[0143] In this embodiment, the goal is it to map the system that
meets the performance requirements specified by .omega..sub.n and
damping factor .zeta. to a corresponding model in the z-domain. The
MPZ method directly maps the s-plane poles and zeros of an analog
system to the corresponding z-plane poles and zeros of a
discrete-time system. Here the Modified-MPZ (MMPZ) method is used.
The method first maps the s-plane poles and zeros into the z-plane
using the relationship, z=e.sup.sT.sup.sp, where T.sub.sp is the
sampling interval. The poles of H(s) at
s=.zeta..omega..sub.n+j.omega..sub.n {square root over
(1-.zeta..sup.2)} will map to a pole of H.sub.2(z) at
T sp ( - .zeta..omega. n + j .omega. n 1 - .zeta. 2 ) .
##EQU00031##
The poles of H(s) at s=.zeta..omega..sub.n+j.omega..sub.n {square
root over (1-.zeta..sup.2)} will map to a pole of H.sub.2(z) at
T sp ( - .zeta..omega. n - j .omega. n 1 - .zeta. 2 ) .
##EQU00032##
The zero at s=.omega..sub.n/2.zeta. will map to a zero of
H.sub.2(z) at e.sup.-.omega..sup.n.sup.T.sup.sp.sup./2.zeta..
[0144] The next steps forms a discrete-time transfer function in z
with the poles and zeros determined in the previous step.
H 2 ( z ) = K DC ( z - - .omega. n T sp / 2 .zeta. ) ( z - T sp ( -
.omega. n .zeta. + j .omega. n 1 - .zeta. 2 ) ) ( z - T sp ( -
.omega. n .zeta. - j .omega. n 1 - .zeta. 2 ) ) , ##EQU00033##
[0145] where K.sub.DC is the DC or low-frequency gain of
H.sub.2(z).
[0146] The next step is to set the DC or low-frequency gain of the
discrete-time system H.sub.2 (Z) equal to that of the
continuous-time system H(s). The Final Value Theorem is often used
to find the steady state value of a time function given its Laplace
transform or z-transform. If there is a function x(t), the theorem
states, in the s-domain, that
lim t .fwdarw. .infin. x ( t ) = lim s .fwdarw. 0 sX ( s ) ,
##EQU00034##
where X(s) is the Laplace transform of x(t) and as long as all the
poles of sX(s) are in the left half-plane (LHP) of the s-plane. In
the z-domain, the theorem states that
lim k .fwdarw. .infin. x ( kT sp ) = lim z .fwdarw. 1 ( 1 - z - 1 )
X ( z ) , ##EQU00035##
where X(z) is the z-transform of x(t) and if all the poles of
(1-z.sup.-1) X(z) are inside the unit circle. The theorem can also
be use to find the DC gain of a system. The DC gain is the ratio of
the output of a system to the inputs (input presumed constant)
after all transients have decayed. To find the DC gain, we assume
there is a unit step input and use the Final Value Theorem to
compute the steady state value of the output.
[0147] Therefore for a system with transfer function G(s), the DC
gain is defined as
DC gain = lim s .fwdarw. 0 sG ( s ) 1 s = lim s .fwdarw. 0 G ( s )
, ##EQU00036##
[0148] and for a system with transfer function G(z), the DC gain is
defined as
DC gain = lim z .fwdarw. 1 ( 1 - z - 1 ) G ( z ) 1 1 - z - 1 = lim
z .fwdarw. 1 G ( z ) . ##EQU00037##
[0149] The DC gain of H(s) is obtained as
lim s .fwdarw. 0 H ( s ) = 1. ##EQU00038##
[0150] Setting the DC gain of H.sub.2(z) to that of H(s) we see
that
K.sub.DC=1.
[0151] Therefore, the transfer function H.sub.2(z) simplifies
to
H 2 ( z ) = ( z - - .omega. n T sp / 2 .zeta. ) ( z - T sp ( -
.omega. n .zeta. + j .omega. n 1 - .zeta. 2 ) ) ( z - T sp ( -
.omega. n .zeta. - j .omega. n 1 - .zeta. 2 ) ) . ##EQU00039##
[0152] The transfer function H.sub.2(z) can further be expressed
as
H 2 ( z ) = z - - .omega. n T sp / 2 .zeta. z 2 - 2 - 2 .zeta.
.omega. n T sp cos ( .omega. n T sp 1 - .zeta. 2 ) z + - 2 .zeta.
.omega. n T sp . ##EQU00040##
Comparing the denominators (or characteristic functions) of H(z)
and H.sub.2(z), we see that
- K PD K OSC K 1 + 1 = - 2 .zeta. .omega. n T sp , or ##EQU00041##
K 1 = 1 K PD K OSC [ 1 - - 2 .zeta. .omega. n T sp ] , and
##EQU00041.2## K PD K OSC ( K 1 + K 2 ) - 2 = - 2 - .zeta. .omega.
n T sp cos ( .omega. n T sp 1 - .zeta. 2 ) , or ##EQU00041.3## K 2
= 1 K PD K OSC [ 1 + - 2 .zeta. .omega. n T sp - 2 - .zeta. .omega.
n T sp cos ( .omega. n T sp 1 - .zeta. 2 ) ] . ##EQU00041.4##
[0153] Typically, performance specification for feedback control
systems often involves certain requirements associated with the
time response of the system. The setting time, t.sub.set can be
defined as the time it takes for the system transients to decay.
For PLL 34, t.sub.set is also referred to as the locking time. For
the second-order system with 0.ltoreq..zeta.<1, the setting time
(for the system to settle within 1% of the input amplitude) is
given by
t set = 4.6 .zeta. .omega. n . ##EQU00042##
[0154] Thus, for a second-order system, by specifying the settling
time, t.sub.set, and the damping factor (e.g., .zeta.=0.707), the
undamped natural frequency .omega..sub.n, and the filter gains
K.sub.1 and K.sub.2 can easily be determined from the above
equations.
[0155] The long range usefulness of PLL 34 depends on the stability
of the system, where a stable system is one which has the ability
to recover from effects of impulse-type inputs. For this reason,
system stability is considered while determining system performance
with respect to other design criteria. The stability of discrete
systems is determined by roots of the discrete system
characteristic equation
Q(z)=a.sub.nz.sup.n+a.sub.n-1z.sup.n-1+ . . .
+a.sub.1z+a.sub.0=0.
However, in this case the stability region is defined by the unit
circle |z|=1. A necessary and sufficient condition for system
stability is that all the roots of the characteristic equation have
a magnitude less one, that is, be within the unit circle, |z|<1.
This ensures that the Kronecker delta response decays with
time.
[0156] One stability criterion for discrete systems is called the
Jury test. For this test, the coefficients of the characteristic
equation are first arranged in the Jury array:
1 a 0 a 1 a 2 a n - 1 a n 2 a n a n - 1 a n - 2 a 1 a 0 3 b 0 b 1 b
2 b n - 1 4 b n - 1 b n - 2 b n - 3 b 0 5 c 0 c 1 c 2 c n - 2 6 c n
- 2 c n - 3 c n - 4 c 0 2 n - 5 r 0 r 1 r 2 r 3 2 n - 4 r 3 r 2 r 1
r 0 2 n - 3 s 0 s 1 s 2 , where ##EQU00043## b k = a 0 a n - k a n
a k , c k = b 0 b n - 1 - k b n - 1 b 0 , s 0 = r 0 r 3 r 3 r 0 , s
1 = r 0 r 2 r 3 r 1 , s 2 = r 0 r 1 r 3 r 2 . ##EQU00043.2##
[0157] The first two rows are written using the characteristic
equation coefficients and the next two rows are computed using the
determinant relationship shown above. The process is continued with
each succeeding pair of rows having one less column than the
previous pair until row 2n-3 is computed, which only has three
entries. The array is then terminated.
[0158] The necessary and sufficient condition for the roots of
Q(z)=0 to have magnitude less than one are:
Q ( 1 ) > 0 ##EQU00044## Q ( - 1 ) { > 0 for n even < 0
for n odd a 0 < a n b 0 > b n - 1 c 0 > c n - 2 r 0 > r
3 s 0 > s 2 ##EQU00044.2##
Note that if the Q(1) or Q(-1) conditions are not satisfied, the
system is unstable and is not necessary to construct the array.
[0159] For the second-order PLL, the characteristic equation is
given by the denominator of H(z), that is,
Q(z)=a.sub.2z.sup.2+a.sub.1z+a.sub.0=0,
where
a.sub.2=1
a.sub.1=K.sub.PDK.sub.OSC(K.sub.1+K.sub.2)-2
a.sub.0=-K.sub.PDK.sub.OSCK.sub.1+1
[0160] For the second-order system, the necessary and sufficient
conditions for stability are
Q(1)>0
Q(-1)>0
|a.sub.0|<|a.sub.2|
which then result in the following stability limits
0<K.sub.PDK.sub.OSCK.sub.1<2
0<K.sub.PDK.sub.OSCK.sub.2<4
from which we get
0 < K 1 < 2 K PD K OSC ; 0 < K 2 < 4 K PD K OSC .
##EQU00045##
These conditions will assure that no roots of the PLL 34 are on or
outside the unit circle.
[0161] Once filter gains K.sub.1 and K.sub.2 are obtained for a
given set of performance specifications for a second-order PLL 34
in terms of locking time (or settling time), t.sub.set, and with
the determination of a damping factor (e.g., .zeta.=0.707), the
following control equation drive the PLL:
{tilde over (e)}(n)={tilde over
(e)}(n-1)+(K.sub.1+K.sub.2)e(n)-K.sub.1e(n-1).
[0162] With DAC.sub.corr(n)={tilde over (e)}(n), the VCO control
input then becomes DAG.sub.VCO(n)=DAC.sub.nom+DAC.sub.corr(n),
rounded to the nearest integer. However, some level of mapping can
be done to condition the error signal ready for use at the
oscillator input.
[0163] As discussed above, the measurement and control are carried
out at the sampling frequency f.sub.sp which gives, essentially,
the sampling period T.sub.sp=1/f.sub.sp for the client PLL 34. The
errors e(n) from the phase detector 38 are generated at this
frequency f.sub.sp. However, the controlled oscillator operates at
the nominal frequency L.sub.nom. Also, we note that the loop filter
parameters derived above are based on the sampling frequency
f.sub.sp. Thus, the error values generated at the lower frequency
f.sub.sp have to be scaled to appropriate values so that they can
be applied to the controlled oscillator which operates at the
nominal frequency L.sub.a.
[0164] The present invention incorporates a mapping function 46 for
mapping the filtered error values generated by the loop filter 40
(which operates at the (lower) nominal frequency f.sub.sp) into
appropriate values for the controlling the oscillator (which
operates at the (higher) nominal frequency f.sub.nom).
[0165] DAC.sub.VCO(f.sub.sp,n) represents the VCO control input at
time n computed based on system parameters at the nominal sampling
frequency f.sub.sp. DAC.sub.VCO(f.sub.nom,n) represents the VCO
control input at time n computed based on system parameters at the
nominal frequency f.sub.nom. Thus, we have
f VCO ( f nom , n ) = f nom + f res DAC VCO ( f nom , n ) = M f sp
+ f res DAC VCO ( f nom , n ) ##EQU00046##
from which we get
f VCO ( f sp , n ) = f VCO ( f nom , n ) M = f sp + f res DAC VCO (
f nom , n ) M ##EQU00047##
[0166] From the above expression we define
DAC VCO ( f sp , n ) = DAC VCO ( f nom , n ) M . ##EQU00048##
[0167] We also define the DAC/VCO operations around the nominal DAC
value DAC.sub.nom and frequency f.sub.nom as
DAC VCO ( f nom , n ) = M DAC VCO ( f sp , n ) = DAC nom + DAC corr
( f nom , n ) ##EQU00049##
where DAC.sub.corr(f.sub.nom,n) is the DAC correction factor
corresponding to the nominal frequency f.sub.nom, at time n. But we
can also define the DAC/VCO operations around the DAC value
DAC.sub.sp and frequency f.sub.sp as
DAC VCO ( f sp , n ) = DAC VCO ( f nom , n ) M = DAC sp + DAC corr
( f sp , n ) ##EQU00050##
where DAC.sub.corr(f.sub.sp,n) is the DAC correction factor
corresponding to the nominal sampling frequency f.sub.sp, at time
n. From the above equation we get
DAC VCO ( f nom , n ) = M DAC VCO ( f sp , n ) = M DAC sp + M DAC
corr ( f sp , n ) ##EQU00051##
[0168] The two above equations, we see that
DAC nom = M DAC sp , and ##EQU00052## DAC corr ( f nom , n ) = M
DAC corr ( f sp , n ) = M e ~ ( f sp , n ) ##EQU00052.2##
where {tilde over (e)}(f.sub.sp,n) is the filtered error based on
the output of the phase detector 38 which operates at the nominal
sampling frequency f.sub.sp, and obtained from the loop filter 40
whose filter gains are computed based on the same nominal sampling
frequency.
[0169] The above equation shows that although the correction factor
DAC.sub.corr(f.sub.sp,n) was obtained based on the error e(n) and
the computed filter gains K.sub.1 and K.sub.2 (computed from the
system parameters and the nominal sampling frequency f.sub.sp), its
corresponding correction factor at f.sub.nom (which is the VCO
nominal output) can readily be obtained by applying the mapping
factor, MF.sub.VCO=M. Since the DAC 48 takes integer values in the
range DAC.sub.VCO.epsilon.[0,2.sup.L-1], DAC.sub.VCO is rounded to
the nearest integer before applying to the DAC 48.
[0170] The design of the client PLL 34 involves the following
steps: [0171] 1. Specify nominal system sampling period,
[0171] T sp = 1 f sp ##EQU00053##
(s), settling (locking) time, t.sub.set (s) (e.g., 1400T.sub.sp s),
and damping factor, .zeta. (e.g., 0.707) of PLL [0172] 2. Compute
phase detector Gain:
[0172] K PD = M 2 .pi. = f nom 2 .pi. f sp ##EQU00054## [0173] 3.
Compute DAC/VCO gain:
[0173] K OSC = K DAC_VCO = 2 .pi. f nom .DELTA. ppm DAC res
##EQU00055## [0174] Note: DAC length, L, DAC.sub.res=2.sup.L;
.DELTA.ppm are known quantities from the VCO and DAC spec
sheet/characteristics [0175] 4. Compute natural frequency
[0175] .omega. n = 4.6 .zeta. t set ( rad / s ) ##EQU00056## [0176]
5. Compute proportional gain of loop filter:
[0176] K 1 = 1 K PD K OSC [ 1 - - 2 .zeta. .omega. n T sp ]
##EQU00057## [0177] 6. Compute integral gain of loop filter:
[0177] K 2 = 1 K PD K OSC [ 1 - - 2 .zeta. .omega. n T sp - 2 -
.zeta. .omega. n T s cos ( .omega. n T sp 1 - .zeta. 2 ) ]
##EQU00058## [0178] 7. Are the stability conditions satisfied?
[0178] 0 < K 1 < 2 K PD K OSC = K 1 max ##EQU00059## 0 < K
2 < 4 K PD K OSC = K 2 max ##EQU00059.2##
[0179] If no, go back to Step 1 and adjust the parameters and
continue [0180] 8. Is the performance of the system satisfactory
(verified through simulations, prototype, measurements, etc.)? If
no, go back to Step 1 and adjust the parameters and continue [0181]
9. If yes in Steps 7 and 8, then end of time client PLL design.
[0182] To reflect common practice in hardware and to simplify
implementation, all gain factors can be determined to be negative
integer powers of two. The filter gains are restricted to be
2.sup.-x, with x an integer, so that coefficient multiplication is
reduced to shifting the binary word.
[0183] The methods for timestamp filtering, minimum delay selection
and offset estimation at the time client are as follows: [0184] 1.
After a sampling period T.sub.sp, select the messages RQ.sub.i,
i=1, 2, . . . , L, and the RP.sub.j, j=1, 2, . . . , L, with min
delay:
[0184] im = arg { min i ( T 2 , i - T 1 , i ) } , i = 1 , 2 , , L
jm = arg { min j ( T 4 , j - T 3 , j ) } , j = 1 , 2 , , L
##EQU00060## [0185] 2. Then compute the delay d.sub.min and time
offset .theta..sub.min from:
[0185] d min = ( T 2 , im - T 1 , im ) + ( T 4 , jm - T 3 , jm ) 2
##EQU00061## .theta. min = ( T 2 , im - T 1 , im ) - ( T 4 , jm - T
3 , jm ) 2 ##EQU00061.2## [0186] 3. Pass d.sub.min to a change
detection algorithm to determine if there is a true min delay
change on the route between server and client. [0187] IF a true min
delay change is detected THEN [0188] set {circumflex over
(.theta.)} value to min delay value .theta..sub.min at time of
change, discarding all history [0189] ELSE [0190] continue
filtering the .theta..sub.min values to obtain {circumflex over
(.theta.)} [0191] 4. Then compute estimate of server current time
S(L.sub.clock) at client using local hardware clock time
L.sub.clock and conversion function
[0191] S(L.sub.clock)=L.sub.clock-{circumflex over (.theta.)}
[0192] The method for the time client PLL computations is as
follows: Load first available time S(L.sub.clock) into PLL clock
counter, thereafter the oscillator increments the counter; wait for
the next sampling period, then compute the current time S.
[0193] The PLL method including the mapping function is described
as follows: [0194] 1. Subtract the current reading of the PLL clock
counter C from S to obtain the PLL error signal e=S-C [0195] Note
the time between d.sub.min and .theta..sub.min estimation is
defined as the sampling period of the system which has a nominal
value of T.sub.sp=1/f.sub.sp, where f.sub.sp is the sampling
frequency. This is design parameter set and is a down-sampled value
of the rate of protocol transactions (i.e., how often the time
client requests for time updates from the time server). The nominal
sampling period T.sub.sp=1/f.sub.sp is only used in the PLL design
process to obtain the design parameters for the loop filter. [0196]
2. Filter the error signal e=S-C a using the loop filter to obtain
the filtered signal error as follows:
[0196] {tilde over (e)}(n)={tilde over
(e)}(n-1)+(K.sub.1+K.sub.2)e(n)-K.sub.1e(n-1) [0197] 3. Use the
mapping function to map the filtered error from the (lower) nominal
sampling frequency f.sub.sp domain into the (higher) nominal
frequency domain of the oscillator f.sub.nom:
[0197] {tilde over (e)}.sub.mp(n)=DAC.sub.corr(n)=M{tilde over
(e)}(n) [0198] 4. Use the mapped filtered error {tilde over
(e)}.sub.mp(n) as a correction factor to modify the value of the
nominal oscillator control word to obtain the oscillator control
input:
[0198]
DAC.sub.VCO(n)=max{0,min[DAC.sub.nom+DAC.sub.corr(n),2.sup.L-1]}
[0199] 5. Wait for the next sampling period and then go to
Algorithm 1
[0200] The present invention can be realized in hardware, software,
or a combination of hardware and software. An implementation of the
method and system of the present invention can be realized in a
centralized fashion in one computing system or in a distributed
fashion where different elements are spread across several
interconnected computing systems. Any kind of computing system, or
other apparatus adapted for carrying out the methods described
herein, is suited to perform the functions described herein.
[0201] A typical combination of hardware and software could be a
specialized or general-purpose computer system having one or more
processing elements and a computer program stored on a storage
medium that, when loaded and executed, controls the computer system
such that it carries out the methods described herein. The present
invention can also be embedded in a computer program product, which
comprises all the features enabling the implementation of the
methods described herein, and which, when loaded in a computing
system is able to carry out these methods. Storage medium refers to
any volatile or non-volatile storage device.
[0202] Computer program or application in the present context means
any expression, in any language, code or notation, of a set of
instructions intended to cause a system having an information
processing capability to perform a particular function either
directly or after either or both of the following a) conversion to
another language, code or notation; b) reproduction in a different
material form. In addition, unless mention was made above to the
contrary, it should be noted that all of the accompanying drawings
are not to scale. Significantly, this invention can be embodied in
other specific forms without departing from the spirit or essential
attributes thereof, and accordingly, reference should be made to
the following claims, rather than to the foregoing specification,
as indicating the scope of the invention.
[0203] It will be appreciated by persons skilled in the art that
the present invention is not limited to what has been particularly
shown and described herein above. In addition, unless mention was
made above to the contrary, it should be noted that all of the
accompanying drawings are not to scale. A variety of modifications
and variations are possible in light of the above teachings without
departing from the scope and spirit of the invention, which is
limited only by the following claims.
* * * * *