Browse Prior Art Database

Proposal of Mechanism for Source Clock Recovery through Asynchronous Network

IP.com Disclosure Number: IPCOM000113166D
Original Publication Date: 1994-Jul-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 8 page(s) / 203K

Publishing Venue

IBM

Related People

Saint-Georges, E: AUTHOR

Abstract

A real-time communication (voice, video, multi-media...) between 2 points of a network needs a synchronization between them (usually at 8 kHz).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 31% of the total text.

Proposal of Mechanism for Source Clock Recovery through Asynchronous
Network

      A real-time communication (voice, video, multi-media...)
between 2 points of a network needs a synchronization between them
(usually at 8 kHz).

      Assuming that the network itself is not synchronized because it
is not required for packet transmission, a method to achieve the
clock recovery, known as "adaptive clock recovery", is proposed in
the Standard.  Based upon the monitoring of a play-out buffer, this
method has been criticized because it was not supposed to be able to
filter the low frequency jitter (wander) which may be introduced by a
packet network.

      Disclosed is a system which is able to recover a source clock
in such a way that the wander can be filtered out.

      A Low-pass filter for very low frequency means long time
constants, which are incompatible with short delay required on
real-time data connections.  For that reason, the proposal is based
upon the idea of dissociating the clock transport and recovery from
the communication itself.

Two options are possible :

1.  Use a dedicated connection for the clock transport.  This option
    brings the following advantages :

    o   The initial setting up of the output clock frequency can be
        as long as needed for the required quality, without drawback.

    o   Only one connection per clock is needed, and can be used by
        all the data connections which need to be synchronized with
        the same source clock.

    o   The clock monitoring is going on, whatever can be the dynamic
        re-allocations of the data connections.

2.  Use a data connection :
    This alternate option is to use a data connection (it is obvious
    that this connection is a real-time connection like AAL1, which
    grants that packets are sent from the source at a constant rate),
    but without using its own play-out buffer, taking the packets at
    the input of this play-out buffer, that is to say, as soon as
    they arrive in the node.

          This option does not change anything to the mechanism
    described in this proposal, but with the drawback that there is
    no more clock monitoring when the connection is off.

      At the source node, it is assumed that packets are generated at
a constant rate related to the source clock, with a nominal period
known by the destination node.  A short period would make possible to
have a better precision or a shorter setting time of the output
clock, but would require a higher bandwidth.

      If packets are ATM cells, a period of 6 ms would require about
64 kbps bandwidth.  Variable length packets would allow to carry the
same clock with a much smaller bandwidth requirement.

      It is assumed that there is no packet loss between the source
and the system input.  That means that in case of packet loss in the
network, one supposes tha...