Why synchronization is not required in otn?

1. Why Synchronization is not required in OTN(Optical Transport Network) ?
Lot of my friends discuss why we don't required synchronization in OTN. So,I decided to blog on this topic here:-
Here we will discuss the timing aspects of optical transport networks as defined by ITU-T SG15 Q13
At the time the OTN was first developed, network synchronization was carried over SDH. Because of this, a key
decision made during the definition of the first generation of the OTN hierarchy was that the OTN must be
transparent to the payloads transported within the ODUk and that the OTN layer itself does not need to transport
network synchronization. The network synchronization should still be carried within the payload, mainly by
SDH/synchronous optical network (SONET) client tributaries. The main concern was then that the synchronization
char-acteristics of the SDH tributaries are preserved when carried across the OTN network.
Figure 1. SDH Timing transparency across the OTN.
However, since SDH networks were widely deployed, an approach where the timing is directly carried by the SDH
clients was preferable. The reason behind this decision was that a single synchronization layer based on SDH was
considered simpler to technocrats. Such a solution requires that the timing of the SDH clients is carried
transparently across the OTN network, and that the phase error and wander generated by the transport through
the OTN remains with- in defined limits (Fig. 1).
The consequences of this choice are that the OTN was defined to be an asynchronous network. The clocks within
the OTN equipment are free running and the accuracy of their oscillator has been defined consistent with the
accuracy of the client and the amount of offset that can be accommodated by the OTN frame.
In addition, in order to simplify the future development of new mappings, a new container type, the ODUflex,
was developed. New clients whose rates are above ODU1 can be mapped synchronously into the ODUflex in a
process called the bit-synchronous mapping procedure. The ODUflex is then mapped to a higher-order ODU using
GMP.
Here the generic timing capabilities of OTN clocks are supported, similarly as for SDH transport. To support the
new clients, the new OTN now defines three mapping methods:
 Bit-synchronous mapping procedure (BMP): bit-synchronous mapping into the server layer (used for ODUflex
and ODU2E)
 Asynchronous mapping procedure (AMP): asynchronous mapping with dedicated stuff byte positions in the
server layer ODU (used for payloads with frequency tolerance of up to ±20 ppm)
 Generic mapping procedure (GMP): delta- sigma modulator-based approach, with equal distribution of stuff
and data in the transport container and asynchronous map- ping into ODU payload with ±20 ppm ODU clock
and ±100 ppm client accuracy.
All the above mappings support the transport of synchronization.
In particular, the OTN frame has been defined so that the justification process can accommodate an input signal
with a frequency offset of up to ±20 ppm of the nominal frequency and mapped with an internal oscillator with a
frequency range up to ±20 ppm. In addition, the frame had to support the case of ODUk multi- plexing, for which

2. both ODUk signal timings may vary within ±20 ppm.As a result, the G.709 frame was defined to accommodate up
to ±65 ppm of offset.
There is not very tricky reason behind the synchronization but to carry the legacy information transparently and
also bitrate of OTN is very high compared to 125us of SDH/SONET.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++
What ITU-T G.798.1 2003 Edition says on OTN TIMING FUNCTION
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++
The OTN does not require any synchronization functionality. The OTN – specifically the
mapping/demapping/desynchronizing and multiplexing/demultiplexing processes and justification granularity information – is
designed to transport synchronous client signals, like synchronous STM-N and synchronous Ethernet signals. When those
signals are bit synchronously mapped into the ODUk (using BMP), this ODUk will be traceable to the same clock to which the
synchronous client signal is traceable (i.e., PRC, SSU, SEC/EEC and under a signal fail condition of the synchronous client
the AIS/LF clock). When those signals are asynchronously mapped into the ODUk (using AMP or GMP), this ODUk will be
plesiochronous with a frequency/bit rate tolerance of ±20 ppm.
Non-synchronous constant bit rate client signals can be mapped bit synchronous (using BMP) or asynchronous (using AMP,
GMP) into the ODUk. In the former case, the frequency/bit rate tolerance of the ODUk will be the frequency/bit rate
tolerance of the client signal, with a maximum of ±45 ppm for k=0, 1, 2, 3, 4 and ±100 ppm for k=2e, flex. In the latter case,
the frequency/bit rate tolerance of the ODUk will be ±20 ppm.
Multiplexing of low order ODUs into a high order ODUk uses an asynchronous mapping (either AMP or GMP). The
frequency/bit rate tolerance of the high order ODUk signal is ±20 ppm.
Variable rate packet client signals are mapped into the ODUk using the generic framing procedure (GFP-F). The
frequency/bit rate tolerance of the ODUk is ±20 ppm for k=0, 1, 2, 3, 4 and ±100 ppm for k=flex.
NOTE – It is possible to use the clock from an EEC or SEC function to generate the ODUk carrying clients mapped with
AMP, GMP, or GFP-F or a multiplex of low order ODUs. Such ODUk is then traceable to an EEC, SSU or PRC. At this point in
time, such ODUk does not provide support for a Synchronization Status Message (ODUk SSM), and consequently cannot be
used as a synchronous-ODUk, i.e., as a synchronous STM-N or synchronous Ethernet replacement signal.
ODUk signals are mapped frame-synchronously into OTUk, thus the frequency/bit rate tolerance of the OTUk signals
depends on the frequency/bit rate tolerance of the ODUk signal being carried.
===================================================================================
References:
[1] ITU-T Rec. G.709/Y.1331, “Interfaces for the Optical Transport Network (OTN),” Dec. 2009.
[2] ITU-T Rec. G.8251, “The Control of Jitter and Wander within the Optical Transport Network (OTN),” Nov.
2001.
[3] ITU-T Rec. G. 810, “Definitions and Terminology for Synchronization Networks,” 1996.
[4] ITU-T Rec. G.811 “Timing Requirements at the Outputs of Primary Reference Clocks Suitable for
Plesiochronous Operation of International Digital Links,” 1988.
[5] ITU-T Rec. G.813, “Timing Characteristics of SDH Equip- ment Slave Clocks (SEC),”2003.
[6] IEEE Communications Magazine • September 2010
[7] ITU-T G.798.1 excerpt 7.3