Connect with us

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

Discussion in 'Electronic Design' started by [email protected], Jul 11, 2007.

Scroll to continue with content
  1. Guest

    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?

  2. Nico Coesel

    Nico Coesel Guest

    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.
  3. Don Bowey

    Don Bowey Guest

    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.
  4. Guest

    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.
  5. PeteS

    PeteS Guest

    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.

    2. 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.

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


  6. PeteS

    PeteS Guest

    <<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.>>

    Umm... I've very successfully repeated T1/2/3/6 systems by locking to
    the incoming clock, albeit with some buffering, and repeating the signal
    using the recovered clock.


  7. 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.

Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day