Yaakov,
>I believe that we managed to pin down the concepts of
>? frequency
>? phase (1 / frequency - e.g. 1 pps, no connection between different
>systems)
>? aligned phase (phase with zero or known relationship at different
>systems)
>? labeled (previously called uncalibrated) time (aligned phase events
>are labeled, but no link to official time standard, e.g. TDMA systems)
>? calibrated time (locked to UTC or national time standard)
After reading the phone call minutes, I think we are mixing 2 different ideas:
1) the timing transport method
2) status information about the quality and origin of the timing being
transported
When thinking about the first idea, I think the goal of timing transport is to
synchronize a slave clock to a master clock. If you think of a clock as being
able to provide a 1PPS output. There are at least 4 modes of timing transport
in incrementing complexity.
FREQUENCY MODE - The offset between the master and slave outputs is unknown,
but fixed within some limits (provided by jitter and wander specs). This
service is equivalent to classical telco timing distribution. It is useful for
circuit emulation and timing cell sites which are frequency division
multiplexed. We call this mode 'frequency' because the condition which causes
the offset to be constant is that the frequency of the 2 clocks is the same.
(This appears to match your 'frequency' mode above? If so, what is the 'phase'
mode?)
1PPS MODE - In addition to the above constraints, the offset between the master
and slave outputs is zero (within an accuracy spec). But we do not know which
particular pulse at the master corresponds to a particular pulse at the slave.
(In other words, the pulses are not labeled.) This service is useful for
timing cell sites which are code division multiplexed. It may also be useful
to for cell based handoffs and location services. (This appears to match your
'aligned phase' mode above?)
TIME MODE - In addition to the above constraints, the pulses at the master are
numbered sequentially, beginning at some starting point. This numbering is
transported to the slave so that it's pulses are also numbered in the same
manner. This service is useful for factory floor automation. (This appears to
match your 'labeled time' mode above? If the starting point were some official
standard, then it would match 'calibrated time' above?)
LEGAL TIME MODE - In addition to the above constraints, the slave is informed
of leap seconds. This mode is useful for applications where humans are
involved using the delivered time.
When thinking about the second idea, I think about where the master's time
comes from.
Depending on the application, the path between the master and it's master may
be different that the path from the master to our slave.
A factory automation application may have 2 requirements.
1) All the machines on the floor need to be within 1uS of each other
for coordination.
2) All the machines need to know the legal time within 1 minute for
logging.
To do this, a free running master which is set manually from time to time
should suffice.
(I guess this would be some hybrid between labeled and calibrated time?)
A telco application might transport frequency which is locked to GPS. (I guess
we would have to add a calibrated frequency mode to accommodate this.)
It seems like by mixing the 2 ideas and then choosing to label a few
combinations, we are setting ourselves up for a never ending list of additions
to the list of named combinations.
Regards,
Stuart
-----Original Message-----
From: [email protected] [mailto:[email protected]]on Behalf
Of [email protected]
Sent: Monday, May 11, 2009 2:22 AM
To: [email protected]
Subject: TICTOC Digest, Vol 33, Issue 8
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. To do so, go to
https://www.ietf.org/mailman/listinfo/tictoc
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME. You can set this option
globally for all the list digests you receive at this point.
Send TICTOC mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/tictoc
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of TICTOC digest..."
Today's Topics:
1. Re: Document with definitions discussed during the
lastTICTOC conference call (Stefano Ruffini)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 May 2009 09:22:53 +0200
From: "Stefano Ruffini" <[email protected]>
Subject: Re: [TICTOC] Document with definitions discussed during the
lastTICTOC conference call
To: "Yaakov Stein" <[email protected]>,
<[email protected]>, <[email protected]>
Message-ID:
<7d33ca0905ce1443bada4bd279acfc60067be...@eitrmmw021.eemea.ericsson.se>
Content-Type: text/plain; charset="iso-8859-1"
Hi Yaakov,
unfortunately I was not able to attend the meeting.
Comparing the definitions provisionally agreed in ITU-T and currently
included in the G.pactiming-bis draft (the definitions are copied below) with
the concepts you have discussed it seems that
Phase Synchonization (ITU-T) = aligned phase (TICTOC)
Time Synchronization (ITU-T) = labeled time + calibrated time (TICTOC)
Phase Synchronization - The term phase synchronization implies that all
associated nodes have access to reference timing signals whose significant
events occur at the same instant (within the relevant phase accuracy
requirement). In other words the term phase synchronization refers to the
process of aligning clocks with respect to phase (phase alignment).
Note: phase synchronization includes compensation for delay between the
(common) source and the associated nodes.
Note: this term might also include the notion of frame timing (that is, the
point in time when the timeslot of an outgoing frame is to be generated).
Note: the concept of phase synchronization (phase alignment) should not be
confused with the concept of phase-locking where a fixed phase offset is
allowed to be arbitrary and unknown. Phase alignment implies that this phase
offset is nominally zero. Two signals which are phase-locked are implicitly
frequency synchronized. Phase-alignment and phase-lock both imply that the Time
Error between any pair of associated nodes is bounded.
Figure 1/G.8266 - Phase Synchronization
Time synchronization - Time synchronization is the distribution of a time
reference to the real-time clocks of a telecommunications network. All the
associated nodes have access to information about time (in other words, each
period of the reference timing signal is marked and dated) and share a common
timescale and related epoch (within the relevant time accuracy requirement).
Examples of timescales are:
* UTC
* TAI
* UTC + offset (e.g. local time)
* GPS
* PTP
* Local arbitrary time
Note that distributing time synchronization is one way of achieving phase
synchronization.
Figure 2/G.8266 - Time Synchronization
Best Regards
Stefano
________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of
Yaakov Stein
Sent: luned? 11 maggio 2009 6.00
To: [email protected]; [email protected]
Subject: Re: [TICTOC] Document with definitions discussed during the lastTICTOC
conference call
Sebastien,
We discussed the definitions section of the requirements document.
I believe that we managed to pin down the concepts of
? frequency
? phase (1 / frequency - e.g. 1 pps, no connection between different
systems)
? aligned phase (phase with zero or known relationship at different
systems)
? labeled (previously called uncalibrated) time (aligned phase events
are labeled, but no link to official time standard, e.g. TDMA systems)
? calibrated time (locked to UTC or national time standard)
We also discussed stability and accuracy (which refer to one of the above)
We looked at the ITU and 1588 definitions where applicable.
Y(J)S
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, May 11, 2009 00:23
To: [email protected]
Subject: [TICTOC] Document with definitions discussed during the last TICTOC
conference call
Hello,
Since I was late during the last TICTOC conference call, I was wondering what
was the document that has been discussed during the call containing the
definitions?
Is it the requirements document? A new document? Where does the need for new
definitions come from?
Thanks in advance for the clarifications.
Just a personal opinion regarding possible new definitions in TICTOC: it would
be good as far as possible to align and re-use terms that are already defined
in other groups dealing with synchronization (e.g. NTP, IEEE1588, ITU-T...). It
would avoid confusion in the timing community in general.
Thanks.
Best Regards,
S?bastien JOBERT
R&D engineer, network synchronization
Orange Labs / France Telecom R&D
FT/RD/CORE/MCN/WAN
Tel : +33 2 96 05 20 93 - Mob : +33 6 82 69 00 50
[email protected]
<mailto:[email protected]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/tictoc/attachments/20090511/f3f77b44/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 5274 bytes
Desc: att191c3.gif
Url :
<http://www.ietf.org/mail-archive/web/tictoc/attachments/20090511/f3f77b44/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 4777 bytes
Desc: att191d4.gif
Url :
<http://www.ietf.org/mail-archive/web/tictoc/attachments/20090511/f3f77b44/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1114 bytes
Desc: image001.gif
Url :
<http://www.ietf.org/mail-archive/web/tictoc/attachments/20090511/f3f77b44/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1023 bytes
Desc: image002.gif
Url :
<http://www.ietf.org/mail-archive/web/tictoc/attachments/20090511/f3f77b44/attachment-0003.gif>
------------------------------
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
End of TICTOC Digest, Vol 33, Issue 8
*************************************
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
