T1/E1 near-end vs. far-end timing

I have some assumptions I would like validated/invalidated about near- end vs. far-end timing in T1/E1-based systems. Please let me know if any of my statements are incorrect:

- In either near-end or far-end system, data is essentially received by recovering a clock from the incoming data stream, and using that to receive the data.

- In a near-end system (if we provide timing), we can use our internal clock source to generate the transmit timing to the far-end. Ideally, the far-end should recover the timing that they receive (that we transmit), and use that to transmit data back to us (to the near-end); therefore, the near-end timing should be identical to the far-end timing (in frequency).

- In a far-end system, the far-end provides timing on the data they transmit to the near-end; so we should use that (instead of our internal clock source) to generate timing on the transmit side.

- A problem can occur if we are in a far-end timing setup, but we are still using internal timing for data we transmit. In this case, the far-ends frequency CAN be slightly different than our internal clocks, which would cause data to be out of sync.

Do I understand this mess?

J
Reply to
jai.dhar
Loading thread data ...

It is very simple: if you design a E1/T1 interface you should be able to act as a timing master (clock provider) or slave (clock follower) despite the mode the interface is in.

If your device is the master (clock provider) your device is leading. The other end should follow the clock coming from your device.

If you device is the slave (clock follower) your device should use the clock derived from the receiver (input) to send data to the output.

Whatever you do, don't use an external PLL to filter the received clock and use the resulting clock to transmit data. There is too much jitter on the incoming signal for the PLL to compensate.

In 99.9% of the cases the device on the other end is connected to the public network. This means that device is synchronized to the public network. In this case the line from your device has to be synchronised to the public network as well. This may take an extra E1/T1 transceiver on which only the RX is connected to extract the public network clock through a splitter.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

Yes.

Yes.

Yes. In Bell terminology, that is "Loop Timing." So far, you must be discussing timing for digital channel transmission. If all the channels were encoded analog, then each end could be locally timed.

You already said that slightly differently.

I don't follow your explanation. "Far-end" is not a fixed location. It's where you aren't at the moment.

Just remember that to have both ends in sync (assuming one or both ends aren't sync'd by a stratum 1 traceable clock), one end will be optioned for internal transmit clock and the other end will be optioned for Loop Timing (a.k.a. slave timing).

If one terminal has an external clock traceable to a stratum 1 clock, and the other end doesn't, the end with the traceable clock should be optioned for External timing and the other end should be optioned for Loop timing.

If both ends have a stratum 1 traceable timing supply, then both ends should be optioned for external transmit timing.

It appears you do.

Which means it's signal is synchronized by a Stratum 1 traceable source.

Or you may, if you wish, just loop time your transmitter. Your transmitted signal will then, also be traceable to the super-stable Stratum 1 clock.

Reply to
Don Bowey

Thanks guys for the helpful explanations... I may have got a little tripped up on semantics, but the overall concept I think I get.

I'm not designing the actual transceiver myself; I'm using an IDT T1/ E1 transceiver, but need to understand the various timing modes in order to interface with customer equipment correctly. Bottom line is that the receive clock is always recovered from incoming data stream, and transmit clock should be opposite of the other end, not the same. One end should be in loop-timing (good term!) and the other in external timing (except in Stratum 1 case). Since I don't have a stratum 1 clock, I will always be dealing with the "opposite" case.

IDT actually makes a WAN PLL that takes the jittery recovered clock and outputs a cleaned up clock for loop-timing I believe... so there appears to be some cases where this is possible.

Reply to
jai.dhar

It's a long time since I designed T1/2/3/6 stuff, but here's the outline:

  1. All data is source synchronous; i.e. the recovered clock from the data stream should be used to clock said data in.

  1. For repeaters, a separate clock may be locally provided, but is not required or even a good idea. A clock regenerator is possible using a local VCO locked to the incoming clock using a low bandwidth loop. In either case, a FIFO at least two bits deep is a very good idea to deal with short term clock / data deviations. If a new clock is generated, then #3 below is mandatory. Note that using a new clock requires you to lock to the incoming clock and use an output clock equal or greater than the incoming clock; far easier to lock to the incoming clock and use that.

  2. Clocking across the domains is left as an exercise, should the clocks be different.

Cheers

PeteS

Reply to
PeteS

Reply to
PeteS

How the clocking is set depends muchly on the network archetecture. If you're running a direct line between the locations set one end as master & the other for recovered clocking.

If you're going through a telco loop then you've most likely got DACS/MUXES/FOTS & a whole bunch of other Esses inbetween your locations. In this case I'd set both ends for recouvered & sponge your timing offa the phone companie's stratum 1 atomic clock :).

Typically with T1s at least if local & far clocks arn't properly configured you'll see slip errors popping up. The T1 spec actually, at least for D4 framing, allows for the insertion of the occaisional slip bit to keep things synced. With ESF you're probably notice packet re-transmit requests going on every few seconds.

H.

Reply to
Howard Eisenhauer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.