Subject: [TICTOC] Specifying a frequency only service

From: "STUART VENTERS" <[email-masked]>
Date: Tue, 29 Jul 2008 11:01:31 -0500

With regards if we need to specify frequency transport separately:

A key measurement for determining the performance of a time transport path is the time offset between the time source being transported and the delivered time.  (For example, the client is within 10uS of GPS.)

It seems offset should also be sufficient for characterizing a frequency transport application.

For time transport, applications may depend on both the magnitude and stability of the offset.

For frequency transport, you can choose any random offset.  What matters is the stability of the chosen offset.

Perhaps in the requirements chart, we need a row for offset magnitude and another for offset stability.
The values in each can be populated with the statistics that are important to the application.
   For magnitude, maybe a Peak or RMS value.
   For stability, maybe a reference to an MTIE or TDEV mask.

Perhaps with these rows, we don't need a special row for frequency transport.
  Frequency transport is just time transport where you don't care about the actual offset, only it's stability.

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Greg Dowd" <[email-masked]>
Date: Tue, 29 Jul 2008 09:09:43 -0700

IIRC, we had discussions about delivering both time and frequency where
the specifications didn't match.  For instance, delivering 50ppm of
frequency stability and time to a few milliseconds.  

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"Everything should be made as simple as possible, but no simpler" Albert
Einstein

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of STUART VENTERS
> Sent: Tuesday, July 29, 2008 9:02 AM
> To: [email-masked]
> Subject: [TICTOC] Specifying a frequency only service
> 
> 
> A key measurement for determining the performance of a time 
> transport path is the time offset between the time source 
> being transported and the delivered time.  (For example, the 
> client is within 10uS of GPS.)
> 
> For frequency transport, you can choose any random offset.  
> What matters is the stability of the chosen offset.
> 
> Perhaps in the requirements chart, we need a row for offset 
> magnitude and another for offset stability.
>   Frequency transport is just time transport where you don't 
> care about the actual offset, only it's stability.
> 
> 
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 29 Jul 2008 12:25:29 -0400

> frequency stability and time to a few milliseconds.

I am not sure why that is inconsistent. You could do that, for  
example, with a ~ 30 second averaging time
for the frequency estimates.

Regards
Marshall

---

From: "STUART VENTERS" <[email-masked]>
Date: Tue, 29 Jul 2008 13:54:52 -0500

Greg,

Good point, it appears we may need either a third row or a better understanding of 'frequency service'.
I was thinking a 'frequency service' assumed that over long averaging times the frequency offset is very low or zero.

For your example,
(Assuming 'few milliseconds' = 3ms)

I guess to fit 50ppm and 3ms into my proposed two rows,
    offset magnitude = 3ms Max
    offset stability = 50us/sec Max offset slew rate

But that seems kind of hoky.  If you were going to provide a 'frequency' service,
  then specifying the frequency offset in ppm might be nicer.
  I'm just not sure what the applications actually expect in a 'frequency' spec.
    (One application is a telco timing requirement to prevent slips.)
    (In which case the MTIE and TDEV masks make more sense that a ppm limit.)

I wonder if a TDEV mask covers the frequency offset requirement?
Maybe the key is understanding what spec method is preferred by the frequency applications.

Regards,

Stuart

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]]
Sent: Tuesday, July 29, 2008 11:25 AM
To: Greg Dowd
Cc: STUART VENTERS; [email-masked]
Subject: Re: [TICTOC] Specifying a frequency only service

Regards
Marshall

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 30 Jul 2008 11:34:33 +0300

Marshall

Frequently we want frequency for CES services.

Averaging over 30 seconds will give long term accuracy,
but unfortunately will not withstand TDM masks as during
the 30 second averaging time the phase error will accumulate.

Stuart

Frequency MAY be obtained from a time service without looking at
the timestamps, but there are other possibilities.

SyncE for one.  CBR streams is another.
Neither has timestamps nor have any concept of time,
but both can deliver frequency.

Y(J)S

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Jul 2008 11:48:25 +0300

Yaakov and all,
I assume that any service we discuss in this WG is a service delivered over a PSN (i.e., using packets).

Hence, IMO, this WG should not deal with "delivery of frequency only" services using SyncE - no more than delivering frequency over SONET/SDH, since neither has anything to do with packets. (If anything, GPS - which uses packets - would be more relevant:-) And, accidentally, both are amply covered by the relevant ITU-T standards.

There is nothing in this statement that prevents using frequency delivered over SyncE, SONET/SDH or any other physical layer capable of carrying frequency as a helper for:
- recovering time of day delivered over packet
- recovering other frequencies delivered over packet (as in he case of CES services using differential clock recovery schemes) etc.

But, IMHO, treatment of such a helper in this WG should not be different from treatment of  frequency taken from a directly connected atomic clock (with all the caveats regarding differences in accuracy and stability).

My 2c.
        Sasha

> [mailto:[email-masked]] On Behalf Of Yaakov Stein
> Sent: Wednesday, July 30, 2008 11:35 AM
> To: Marshall Eubanks; Greg Dowd

---

From: "Stefano Ruffini" <[email-masked]>
Date: Wed, 30 Jul 2008 15:50:44 +0200

Hi,

frequency sync distribution in the RAN backhaul (GSM, WCDMA or LTE FDD; not TDD) is one candidate where x ms time accuracy is compatible with the xx ppb req.; the stability on the short-medium term required on the radio interface would be taken care of the client oscillator and filtering charcateristics. 

The assumption is that the clock recovery mechanism is implemented directly in the base station and there is no CES in the RAN (i.e. E1 connected to the Base Station). Otherwise we are back to Yaakov point about the requirement in terms of the MTIE mask for the E1 (T1) service recovered at the output of the packet network.

Best Regards
Stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: mercoledì 30 luglio 2008 10.35
To: Marshall Eubanks; Greg Dowd
Cc: STUART VENTERS; [email-masked]
Subject: Re: [TICTOC] Specifying a frequency only service

Marshall

Averaging over 30 seconds will give long term accuracy, but unfortunately will not withstand TDM masks as during the 30 second averaging time the phase error will accumulate.

Stuart

Frequency MAY be obtained from a time service without looking at the timestamps, but there are other possibilities.

SyncE for one.  CBR streams is another.
Neither has timestamps nor have any concept of time, but both can deliver frequency.

Y(J)S

---

From: "STUART VENTERS" <[email-masked]>
Date: Wed, 30 Jul 2008 09:10:22 -0500

Yaakov,

When I need a reference to support CES,
  I'm usually interested in the reference meeting MTIE and TDEV masks.
    I may ask for frequency, but I'm mostly interested in wander.
    If the wander is ok, then the frequency seems to take care of itself.

When you say you want frequency for CES service,
  are your needs similar?

If you are trying to deliver frequency 
   and you have SyncE on-path support,
then what would be gained by
   adding a packet based timing protocol
     on top of SyncE?

If you are not going to add a packet based timing protocol,
  then isn't it outside our charter?

It seems like packet based frequency transport is only interesting when you don't have SyncE.  

Regards,

Stuart

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 3:35 AM
To: Marshall Eubanks; Greg Dowd
Cc: STUART VENTERS; [email-masked]
Subject: RE: [TICTOC] Specifying a frequency only service

Marshall

Stuart

Y(J)S