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 technochrats. 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 net- work. 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 trans- port. 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



SDH NE STM-N OTN NE OTN NE STM-N SDH NE







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.




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