QUESTION:
Simplistically explain how asynchronous DS1 signals setup in an "A" end master configuration to a "Z" end sync recovery mode in either network/line/loop/recovered configuration can operate over multinode SONET rings with some associated subtending rings.
ANSWER:
This is a difficult question to give a "simplistic" answer to without losing something in the translation. However, I hope the following explanations help.
First, when one talks about "sync recovery", one has to be careful. It depends upon what the application is and how "good" the recovered clock needs to be. Please keep this in mind as the explanation evolves.
Transport of an "asynchronous" (by this I mean that the actual time-base of the underlying signal is not necessarily traceable to a G.811 primary reference clock but is within certain bounds, typically 50 ppm as per ITU-T Rec G.703 and ANSI T1.102) DS1 over a SONET transport network is achieved by first encapsulating the DS1 (nominally 1.544 Mbps) into a VT1.5 using "bit-stuffing", essentially adding "null" bits to align the DS1 clock to the SONET clock. This virtual container is transported across the SONET network and clock variations between elements are absorbed by a technique called "pointer processing" which is similar in principle to bit-stuffing. The end result of these operations is that the DS1 can be recreated at the egress node with no loss of "information" (bits). That is, the bit-pattern at the egress node matches the bit-pattern at the ingress (assuming, of course, that there are no transmission bit errors, where a 1 is decoded as a 0, or vice versa) with, of course, some delay. Needless to say, bit-stuffing and pointer processing cannot mask an indefinite frequency offset, requiring that the SONET elements comprising the transport network be appropriately synchronized.
One can make the case that data integrity, visualized as bits-in equal bits-out, implies that the average bit-rate of the DS1 at the egress node is equal to the average bit-rate at the ingress. This is true, but one has to be careful in defining "average". Whereas the long-term average may be correct, the short-term behavior may be far from perfect. That is, the DS1 signal at the egress node may have significant jitter and wander. As a bare minimum, the jitter must be small enough that the terminal equipment (at the "Z" node) can recover clock just so as to recover the data. This is addressed in the standards.
In order to use the recovered clock (at "Z") for the purposes of developing a synchronization reference, it depends on the application. It has been determined that a traffic DS1 carried over a SONET transport network is not suitable as a synchronization reference since it is not possible to maintain the notion of "traceability" to the source because of the jitter and wander introduced by bit-stuffing and pointer processing. Specifically, the standards bodies make a distinction between a "traffic interface" and a "interface suitable for synchronization". The former is adequate for feeding some terminal equipments that have a reduced requirement for quality of synchronization reference.
Though I may be treading on the requirement of being "simplistic", I am including some material from ITU-T Recommendation G.824.
ITU-T Recommendation G.824 defines the following terms. Additional definitions relating to synchronization networks are provided in ITU-T Recommendation G.810.
3.1 synchronous interface: For the purpose of this ITU-T Recommendation, a synchronous interface is defined such that the bit rate of the interface is derived from a source that is ultimately traceable to a PRC (primary reference clock).
3.2 asynchronous interface: These interfaces provide an output signal with frequency that is not traceable to a PRC and that meets the frequency offset requirements given in ITU-T Recommendation G.703.
3.3 traffic interface: These interfaces may be synchronous (i.e. normally PRC-traceable) or asynchronous (i.e. meeting the frequency offset requirements of ITU-T Recommendation G.703) and network limits are specified using the MRTIE (Maximum Relative Time Interval Error) parameter in this ITU-T Recommendation. Input jitter/wander tolerance is also specified in this ITU-T Recommendation. This interface category can be further sub-divided as follows:
- Interface is not able or required to provide synchronization. An example is an interface supporting only 44 736 kbit/s PDH signals according to ITU-T Recommendation G.703.
- Interface is not able to provide synchronization at the defined performance level, but nevertheless is used to provide timing to other network elements such as terminal equipment, remote concentrators, etc. Examples include 1544 and 44 736 kbit/s PDH signals transported on SONET/SDH, which may be subject to pointer justifications. ITU-T Recommendation G.803 recommends that these interfaces not be used for synchronization.
- Interface is able to provide synchronization at the defined performance level, in which case it is defined to be a synchronization interface.
3.4 synchronization interface: These interfaces are synchronous (i.e. normally PRC-traceable) and suitable for timing network clocks (SSUs and SECs). The network limits for synchronization interfaces are specified using MTIE (Maximum Time Interval Error) and TDEV (Time Deviation)parameters with values given in this ITU-T Recommendation. The input jitter/wander tolerance of clock equipment ports is specified in ITU-T Recommendation G.812 (for equipment containing an SSU function) and Option 2 of ITU-T Recommendation G.813 (for equipment containing an SEC function).
However, it should not be construed from the above that sync recovery is "impossible" from a traffic interface. The standards just caution the user that pointer processing has the impact of reducing the quality of time-base transfer. It is quite reasonable to assume that if the SONET Network is synchronized in a robust fashion then the likelihood of excessive pointer movements is minimized and the recovered clock from the traffic interface, with appropriate filtering, may be adequate for even some demanding applications such as timing a wireless base station. Whereas these edge clocks cannot be referred to a "stratum clocks" ("timing adaptor" is better nomenclature), they may be fit for purpose.
|
