Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

About G.812 timing quality

187 views
Skip to first unread message

Michel Hostettler

unread,
Jul 23, 2003, 3:20:14 PM7/23/03
to
Bonjour,

I have some problems for understanding some very basic points.

(1) Is a node clock really synonym for SSU ? In G.812 I only see the
expression "node clock" and not SSU. So, a node clock should not be a
SEC clock.


(2) The frequency accuracy ot Type VI node clocks is given Not
Applicable in the Table A.1/G.812, under prolonged holdover
conditions. I think it is commonly used, because the type VI was
formely the SSU-L in 1988.

How can we explain that it is not applicable ?


(3) So, how can we know the frequency accuracy ? In the application
notes of the vendors, it is sometimes written 10-8, or 10-9, or
2x10-10. What is the good value ?

Thanks a lot for this help.
Regards,
Michel

Huub van Helvoort

unread,
Jul 25, 2003, 5:20:30 AM7/25/03
to
Bonjour Michel,

> (1) Is a node clock really synonym for SSU ? In G.812 I only see the
> expression "node clock" and not SSU. So, a node clock should not be a
> SEC clock.

A node clock is synonym for a SEC (SDH Equipment Clock), however
it can have SSU capabilities. These capabilies are explained in
G.812.

> (2) The frequency accuracy ot Type VI node clocks is given Not
> Applicable in the Table A.1/G.812, under prolonged holdover
> conditions. I think it is commonly used, because the type VI was
> formely the SSU-L in 1988.

Type VI is only applicable for old installed equipment, new
equipment should comply to types I (ETSI), II or III (ANSI).
In G.812 types IV (embedded base in North Amaerica), V and
VI (transit resp. local node clocks from previous version
of G.812) are included for backward compatibility.

> How can we explain that it is not applicable ?

Use only types I, II or III.

> (3) So, how can we know the frequency accuracy ? In the application
> notes of the vendors, it is sometimes written 10-8, or 10-9, or
> 2x10-10. What is the good value ?

Because we are Europeans, you should use type I (ETSI)

> Thanks a lot for this help.
> Regards,
> Michel

Cheers, Huub.

--
reply to hhelvooort with 2 'o's
================================================
http://members.chello.nl/hhelvoort/
================================================
Those Romans are crazy, Obelix 50 BC

Michel Hostettler

unread,
Jul 26, 2003, 9:03:53 AM7/26/03
to
Bonjour Huub,

Thanks for your interesting information.

> A node clock is synonym for a SEC (SDH Equipment Clock), however
> it can have SSU capabilities. These capabilies are explained in
> G.812.

It seems that the use of the expression "SDH equipment clock" is
different from the use of the abbreviation SEC, even if SEC stands for
SDH equipment clock !

A SDH equipment clock can be a "SEC clock" or a "SSU clock" according
to the quality of the oscillator and the filtering.

Do you agree with that ?

> Because we are Europeans, you should use type I (ETSI)

Yes, I understand that. Unfortunately, the question is the same. You
can see in the table 1 of G.812 that the frequency accuracy is
indicated "Not applicable" for type I.

And, on contrary, there are given values for type II (1.6 10-8) and
type III (4.6 10-6).

Do you know the reason of that "Not applicable" indication, and the
real maximum value for type I.

> ...type I (ETSI)

Is there an ETSI specification equivalent to type I. I saw only ETSI
specifications for types V and VI (that's EN 300 462-7-1 for SSU-L and
EN 300 462-4-1 for SSU-T).

Cheers,
Michel

Huub van Helvoort

unread,
Jul 27, 2003, 5:03:13 PM7/27/03
to
Bonsoir Michel,

> Thanks for your interesting information.

I try to do my best, even though I am not a sync expert. ;-)

>>A node clock is synonym for a SEC (SDH Equipment Clock), however
>>it can have SSU capabilities. These capabilies are explained in
>>G.812.
>
> It seems that the use of the expression "SDH equipment clock" is
> different from the use of the abbreviation SEC, even if SEC stands for
> SDH equipment clock !
>
> A SDH equipment clock can be a "SEC clock" or a "SSU clock" according
> to the quality of the oscillator and the filtering.
>
> Do you agree with that ?

[hvh] Yes, but I would say a SEC clock cannot be used by other NE
for reference clock. A SSU clock can be used by other NE
for synchr.

>>Because we are Europeans, you should use type I (ETSI)
>
> Yes, I understand that. Unfortunately, the question is the same. You
> can see in the table 1 of G.812 that the frequency accuracy is
> indicated "Not applicable" for type I.

[hvh] This is because in the ETSI synchronisation hierarchy it
is not required. The holdover is more important.
See: http://www.tekelec-systemes.com/doc/tf13_ns_f_12453a0.pdf

> And, on contrary, there are given values for type II (1.6 10-8) and
> type III (4.6 10-6).

[hvh] this is determined by the North-American synchr. hierarchy.

> Do you know the reason of that "Not applicable" indication, and the
> real maximum value for type I.

[hvh] +/- 4.6 ppm is a value commonly used/required.

>>...type I (ETSI)
>
> Is there an ETSI specification equivalent to type I. I saw only ETSI
> specifications for types V and VI (that's EN 300 462-7-1 for SSU-L and
> EN 300 462-4-1 for SSU-T).

[hvh] the article above mentions EN 300 462-2-1

> Cheers,
> Michel

Salut, Huub.

Michel Hostettler

unread,
Jul 30, 2003, 5:59:27 PM7/30/03
to
Bonjour Huub,

Saga continuation...

> > Thanks for your interesting information.
>
> I try to do my best, even though I am not a sync expert. ;-)

Above all, don't change. We cannot be expert in all domains and, too
often, expertise and communication are not compatible qualities. It's
not your case, you are a SDH expert and a good communicator, and it is
valuable for us.

> [hvh] Yes, but I would say a SEC clock cannot be used by other NE
> for reference clock. A SSU clock can be used by other NE
> for synchr.

In holdover mode, a SEC clock can be slaved to a SEC clock of the same
quality or a clock of better quality. The first case can occured e.g.
at the end of a synchronization chain.

But you're right, a slave clock of a given quality level cannot be
slaved to a reference signal of a lower quality.


> [hvh] This is because in the ETSI synchronisation hierarchy it
> is not required. The holdover is more important.


Yes, but a frequency accuracy of a clock is also a parameter in
holdover mode. When the clock is locked, the frequency accuracy of its
output is that of the best clock in the chain.


> See: http://www.tekelec-systemes.com/doc/tf13_ns_f_12453a0.pdf

Thanks for that text, I took some information. But in my opinion, the
very first sentence ot the document doesn't give a correct view. It is
written: "in SDH and SONET, if the input rate is not equal to the
output rate in all interfaces, pieces of information can be lost or
repeated".

It depends on the offset of the rates ! For a STM-N interface, below
300 ppm, this offset is supported by pointer adjustments. Beyond,
slips occur.

Is it your opinion Huub ?


> > Do you know the reason of that "Not applicable" indication, and the
> > real maximum value for type I.
>
> [hvh] +/- 4.6 ppm is a value commonly used/required.

This accuracy is for SEC or type III SSU clocks. In G.812, it is just
indicated that the quality of type I is better than type III.

In some documents, but without precision of the type, I rather saw
10-8. I noted that it is the same value than the pull-in range, there
is certainly a connection between these parameters but they are not
exactly the same thing.

> [hvh] the article above mentions EN 300 462-2-1

This standard gives functional descriptions of PRC, SSU (SSU-L and
SSU-T), SEC clocks. Details SSU requirements are in 4-1 (for SSU-T)and
7-1 (for SSU-L). Until then, I didn't see type I SSU or equivalent
characteritics in ETSI.

Cheers,
Michel

Huub van Helvoort

unread,
Aug 1, 2003, 4:42:06 PM8/1/03
to
Bonsoir Michel,

> Saga continuation...

Yes, do you remember the "continuing story of Peyton Place"? ;-)


>>>Thanks for your interesting information.
>>
>>I try to do my best, even though I am not a sync expert. ;-)
>
>
> Above all, don't change. We cannot be expert in all domains and, too
> often, expertise and communication are not compatible qualities. It's
> not your case, you are a SDH expert and a good communicator, and it is
> valuable for us.

Thanks for your praise.

>> See: http://www.tekelec-systemes.com/doc/tf13_ns_f_12453a0.pdf
>
> Thanks for that text, I took some information. But in my opinion, the
> very first sentence ot the document doesn't give a correct view. It is
> written: "in SDH and SONET, if the input rate is not equal to the
> output rate in all interfaces, pieces of information can be lost or
> repeated".
>
> It depends on the offset of the rates ! For a STM-N interface, below
> 300 ppm, this offset is supported by pointer adjustments. Beyond,
> slips occur.
>
> Is it your opinion Huub ?

The text does not say it as clearly as you do, I see an "if" and a
"can" so they mean the possibility exists.

>>>Do you know the reason of that "Not applicable" indication, and the
>>>real maximum value for type I.
>>
>>[hvh] +/- 4.6 ppm is a value commonly used/required.
>
> This accuracy is for SEC or type III SSU clocks. In G.812, it is just
> indicated that the quality of type I is better than type III.
>
> In some documents, but without precision of the type, I rather saw
> 10-8. I noted that it is the same value than the pull-in range, there
> is certainly a connection between these parameters but they are not
> exactly the same thing.
>
>
>>[hvh] the article above mentions EN 300 462-2-1
>
> This standard gives functional descriptions of PRC, SSU (SSU-L and
> SSU-T), SEC clocks. Details SSU requirements are in 4-1 (for SSU-T)and
> 7-1 (for SSU-L). Until then, I didn't see type I SSU or equivalent
> characteritics in ETSI.

Maybe in EN 300 462-5-1 ?
But I will ask one of my former collegues, who is an expert on
this matter.

Au revoir, Huub.

> Cheers,
> Michel

Huub van Helvoort

unread,
Aug 16, 2003, 5:42:27 PM8/16/03
to
Bonsoir Michel,

Here is the answer of the expert to your question:

>>[hvh] This is because in the ETSI synchronisation hierarchy it
>> is not required. The holdover is more important.
>
> Yes, but a frequency accuracy of a clock is also a parameter in
> holdover mode. When the clock is locked, the frequency accuracy of its
> output is that of the best clock in the chain.

The "long term frequency accuracy" is applicable only for those clocks
that operate during a very long time in "free running" mode
(e.g.the G.811 clock).
Because the SSU is a "slave clock", the operation mode of this clock
is "locked" or "holdover".
The "frequency accuracy" in "holdover" is specified acurately in
section 11.2 of Rec. G.812 (see type 1 for the ETSI SSU).
These specifications are especially important for networks containing
clocks that have only one single reference.
Whenever a clcok in a network switches to "holover" because of a failure
in one or more references the network enters a situation where
"controlled slips" are produced.
The maximum allowable number of "controlled slips" is mentioned in
Rec. G.822. A network operator can calculate under these circumstances
the max. time this situation may last and when the failure has to
be fixed (MTTR).
When designing a network the selection of the appropriate clock (e.g.
type 2 in stead of type 1) can avoid unwanted situations.

Cheers, Huub.

Michel Hostettler

unread,
Aug 30, 2003, 7:20:19 PM8/30/03
to
Bonsoir Huub,

I came back from holidays in mountain to escape the terrible hot days.

Thanks for that reply from your expert, you can also thank him for
that information.

Would you let me to bring some comments, not for differing but only to
know if I am understanding correctly these difficult concepts (for
me).


> Because the SSU is a "slave clock", the operation mode of this clock
> is "locked" or "holdover".

We can also add the "free running" mode for 2 special cases. The SSU
(or SEC) has not been "locked" yet (just installed and not in line
e.g.) or the clock is in "holdover" mode since a long time (PLL
parameters are vanished).

> The "frequency accuracy" in "holdover" is specified acurately in
> section 11.2 of Rec. G.812

Thanks to you I saw another time this section, and... miraculously, I
understood what it was explained.

For a type 1 clock, I calculated the frequency accuracy, called in
this section the "fractional frequency offset", this for one year.

df/f < ou = 2.5 10-9 + 2.3 10-15 x 3.15 10+7 = 7.5 10-8

This value was not given in the table 1/G.812, and then mentionned NA
(not applicable) because there is no specified limit for the
"prolonged holdover conditions". So, we can have holdover duration of
2 years or more !

If we calculate (by the same 11.2.1 formula) the frequency accuracy
for type 2 clocks, we have df/f < ou = 38 10-8 for 1 year. But,
according to the table 1, the value cannot exceed 1.6 10-8 for 1 year.

It was this logic I didn't understand.

We can also see that the "free running" expression is not written in
G.812. One year holdover mode in prolonged conditions is already "free
running" !

>(see type 1 for the ETSI SSU).

For ETSI SSU, I just know EN 300 462-4-1 that specified SSU-T (type 5
for ITU-T), and EN 300 462-7-1 for SSU-L (type 6 for ITU-T). As far as
I know, there is no equivalent type 1 for ETSI. Is is planned in new
versions to be come, or I missed something ?

> Whenever a clcok in a network switches to "holover" because of a failure
> in one or more references the network enters a situation where
> "controlled slips" are produced.

What is the relationship between slips and pointer adjustements ? Is
the pointer adjustement pushes, goes down the slip ratio ? Perhaps,
there are slips for SOH and not for VC4, if pointers can compensate
for the frequency offset. That point is not clear for me, and for you
Huub ?

Regards,
Michel

Michel Hostettler

unread,
Aug 31, 2003, 4:51:06 PM8/31/03
to
Bonjour Huub


CORRECTION TO MY ITEM


> >(see type 1 for the ETSI SSU).
>
> For ETSI SSU, I just know EN 300 462-4-1 that specified SSU-T (type 5
> for ITU-T), and EN 300 462-7-1 for SSU-L (type 6 for ITU-T). As far as
> I know, there is no equivalent type 1 for ETSI. Is is planned in new
> versions to be come, or I missed something ?

It's more complicate than I imagined.


1. About EN 300 462-7-1

In the document scope, it is indicated :

"The present document outlines requirements for timing devices called
Synchronization Supply Units for local node applications (SSU-Ls)"

But the characteristics of the clock are not same as type VI G.812 !

And yet, in G.812, it is indicated in the annex A :

"the Type VI clock is the local node clock from the 1988 version of
this Recommendation"

Comparing characteristics of ITU type VI with ETSI SSU-L, we can see
that :

- SSU-L wander and jitter are same as ITU type I (and not type VI)
- Holdover performance has no equivalence with any ITU types.

2. About EN 300 462-4-1

In the document scope, it is indicated :

"The requirements laid down in the present document describe the
minimum performance of an SSU applied as a transit node clock"

But the characteristics of the clock are not same as type V G.812 !

And yet, in G.812, it is indicated in the annex A :

"The Type V clock is the transit node clock from the 1988 version of
this Recommendation"

In fact, we can see the "ETSI transit node clock" characteristics are
same as............ ITU type I !


3. Conclusion

- In ETSI/1998, the SSU-T term is not used
- ETSI SSU-L is not ITU type VI (formerly local node clock)

And you are right again, we can used the shorten expression "type I
ETSI SSU".

This expression would mean "ETSI transit node clock equivalent to ITU
type I clock".

Nothing is really simple.
Regards,
Michel

Huub van Helvoort

unread,
Sep 23, 2003, 3:57:14 PM9/23/03
to
Bonjour Michel,

> I came back from holidays in mountain to escape the terrible hot days.

It was hot everywhere, several weather record have been broken.

> Thanks for that reply from your expert, you can also thank him for
> that information.

I did.

> Would you let me to bring some comments, not for differing but only to
> know if I am understanding correctly these difficult concepts (for
> me).

Sure.

>>Because the SSU is a "slave clock", the operation mode of this clock
>>is "locked" or "holdover".
>
>
> We can also add the "free running" mode for 2 special cases. The SSU
> (or SEC) has not been "locked" yet (just installed and not in line
> e.g.) or the clock is in "holdover" mode since a long time (PLL
> parameters are vanished).

Yes, but very unlikely to happen in a live network, unless the
operator does not care about SLAs.

>>The "frequency accuracy" in "holdover" is specified acurately in
>>section 11.2 of Rec. G.812
>
> Thanks to you I saw another time this section, and... miraculously, I
> understood what it was explained.
>
> For a type 1 clock, I calculated the frequency accuracy, called in
> this section the "fractional frequency offset", this for one year.
>
> df/f < ou = 2.5 10-9 + 2.3 10-15 x 3.15 10+7 = 7.5 10-8
>
> This value was not given in the table 1/G.812, and then mentionned NA
> (not applicable) because there is no specified limit for the
> "prolonged holdover conditions". So, we can have holdover duration of
> 2 years or more !
>
> If we calculate (by the same 11.2.1 formula) the frequency accuracy
> for type 2 clocks, we have df/f < ou = 38 10-8 for 1 year. But,
> according to the table 1, the value cannot exceed 1.6 10-8 for 1 year.
>
> It was this logic I didn't understand.
>
> We can also see that the "free running" expression is not written in
> G.812. One year holdover mode in prolonged conditions is already "free
> running" !

I am glad you understand now.

>>(see type 1 for the ETSI SSU).
>
> For ETSI SSU, I just know EN 300 462-4-1 that specified SSU-T (type 5
> for ITU-T), and EN 300 462-7-1 for SSU-L (type 6 for ITU-T). As far as
> I know, there is no equivalent type 1 for ETSI. Is is planned in new
> versions to be come, or I missed something ?

Not that I know, but maybe it is in EN 300-462-5

>>Whenever a clcok in a network switches to "holover" because of a failure
>>in one or more references the network enters a situation where
>>"controlled slips" are produced.
>
> What is the relationship between slips and pointer adjustements ? Is
> the pointer adjustement pushes, goes down the slip ratio ? Perhaps,
> there are slips for SOH and not for VC4, if pointers can compensate
> for the frequency offset. That point is not clear for me, and for you
> Huub ?

Normally is is either slip or pointer ajustments. So if
bit slips are used the pointer is fixed. Locked to the
network clock.

> Regards,
> Michel

Huub van Helvoort

unread,
Sep 23, 2003, 4:00:56 PM9/23/03
to
Bonsoir Michel,

> CORRECTION TO MY ITEM

OK, no problem, you now understand more than I do ;-)

> Nothing is really simple.

Or as they would say at the other side of the ocean:
shit happens....

> Regards,
> Michel

0 new messages