Last Updated: August 16, 2025
6 min read
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 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
Sanjay Yadav
Optical Networking Engineer & Architect • Founder, MapYourTech
Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech.
Read full bio →
Related Articles on MapYourTech
