OTNtutorial

Optical Transport Network (OTN) Tutorial
Disclaimer:
This is a Tutorial.
This is NOT a Recommendation!
This tutorial has no standards significance. It is purely
for educational purposes. In case of conflict between the
material contained in the tutorial and the material of
the relevant Recommendation the latter always prevails.
This tutorial should NOT be used as a reference; only
the relevant Recommendations can be referenced.
Summary
This document provides a tutorial for Optical Transport Network standards and their applications.
The objective is to provide the telecommunications engineers with a document that forms the basis
for understanding OTN.
Contact: Timothy P. Walker Tel: 1-978-247-8407

AMCC Fax:
USA Email: twalker@amcc.com
-2-
1 Scope.............................................................................................................................5
2 Abbreviations................................................................................................................5
3 What is OTN/OTH........................................................................................................7
3.1 OTN Standards ...............................................................................................7
4 Where is it standardized for ..........................................................................................8
5 Why use OTN...............................................................................................................8

5.1 Forward Error Correction (FEC) ....................................................................8
5.1.1 Theoretical Description ..................................................................................9
5.1.2 Coding Gain....................................................................................................11
5.2 Tandem Connection Monitoring ....................................................................14
5.3 Transparent Transport of Client Signals.........................................................17
5.4 Switching Scalability......................................................................................17
6 OTN Hierarchy Overview ............................................................................................18
7 OTUk, ODUk, OPUk Frame Structure.........................................................................20
8 OPUk Overhead and Processing...................................................................................21

8.1 OPUk Overhead Byte Descriptions ................................................................22
8.1.1 Payload Structure Identifier (PSI) ..................................................................22
8.1.2 Payload Type (PT)..........................................................................................22
8.2 Mapping Signals into an OPUk......................................................................22
8.2.1 Frequency Justification...................................................................................23
8.2.2 Mapping a CBR2G5 signal (e.g. STM-16) into OPU1 ..................................25
8.2.3 Mapping a CBR10G signal (e.g. STM-64) into OPU2 ..................................26
8.2.4 Mapping a CBR40G signal (e.g. STM-256) into OPU3 ................................26
9 ODUk Overhead and Processing ..................................................................................27

9.1 Path Monitoring (PM) Byte Descriptions.......................................................29
9.1.1 Trail Trace Identifier (TTI).............................................................................29
9.1.2 BIP-8...............................................................................................................29
9.1.3 Backward Defect Indication (BDI).................................................................29
9.1.4 Backward Error Indication and Backward Incoming Alignment Error
(BEI/BIAE).....................................................................................................30
9.1.5 Path Monitoring Status (STAT) .....................................................................30
9.2 Tandem Connection Monitoring (TCM) ........................................................30
9.2.2 BIP-8...............................................................................................................31
-3-

(BEI/BIAE).....................................................................................................31
9.2.5 TCM Monitoring Status (STAT) ....................................................................32
9.2.6 Tandem Connection Monitoring ACTivation/deactivation (TCM-ACT) ......33
9.2.7 General Communication Channels (GCC1, GCC2).......................................33
9.2.8 Automatic Protection Switching and Protection Communication Channel
(APS/PCC)......................................................................................................33
9.2.9 Fault Type and Fault Location reporting communication channel (FTFL) ....33
10 OTUk Overhead and Processing...................................................................................33

10.1 Scrambling......................................................................................................34
10.2 Frame Alignment Overhead ...........................................................................35
10.2.1 Frame alignment signal (FAS) .......................................................................35
10.2.2 Multiframe alignment signal (MFAS)............................................................35
10.3 SM Byte Descriptions.....................................................................................36
10.3.2 BIP-8...............................................................................................................37
(BEI/BIAE).....................................................................................................38
10.3.5 Incoming Alignment Error (IAE) ...................................................................39
10.4 General Communication Channel 0 (GCC0)..................................................39
11 ODUk Multiplexing......................................................................................................39
11.1 Multiplexing Data Rates.................................................................................39
11.1.1 ODU1 to ODU2 Justification Rate .................................................................39
11.2 4 x ODU1 to ODU2 Multiplexing..................................................................41
11.2.1 4 x ODU1 to ODU2 Multiplexing Structure ..................................................41
11.2.2 4 x ODU1 to ODU2 Justification Structure....................................................43
11.2.3 OPU2 Payload Structure Identifier (PSI) .......................................................44
11.2.4 OPU2 Multiplex Structure Identifier (MSI) ...................................................44
11.3 ODU1/ODU2 to ODU3 Multiplexing ............................................................46
11.3.1 ODU1/ODU2 to ODU3 Multiplexing Structure ............................................46
11.3.2 ODU1/ODU2 to ODU3 Justification Structure..............................................48
11.3.3 OPU3 Payload Structure Identifier (PSI) .......................................................49
11.3.4 OPU3 Multiplex Structure Identifier (MSI) ...................................................49
11.4 Maintenance Signal Insertion .........................................................................51
-4-
11.4.1 Client source ODUk-AIS................................................................................51

11.4.2 Client source ODUk-OCI ...............................................................................51
11.4.3 Line source ODUk-AIS ..................................................................................51
11.5 Defect detection and correlation.....................................................................52
11.5.1 dPLM (Payload Mismatch) ............................................................................52
11.5.2 cPLM ..............................................................................................................52
11.5.3 dMSIM (Multiplex Structure Identifier Mismatch supervision) ....................53
11.5.4 cMSIM............................................................................................................53
11.5.5 dLOFLOM (Loss of Frame and Multiframe) .................................................53
11.5.6 cLOFLOM......................................................................................................54
11.5.7 aAIS (AIS insertion) .......................................................................................54
11.5.8 SSF (Server Signal Fail).................................................................................54
12 ODUk Virtual Concatenation / OTN over SONET ......................................................55
13 Synchronisation ............................................................................................................55
13.1 Introduction ....................................................................................................55
13.2 Network requirements ....................................................................................55
13.3 Mapping and Multiplexing .............................................................................57
13.4 Equipment requirements .................................................................................57
14 OTN Maintenance Signals............................................................................................57

14.1 OTUk maintenance signals.............................................................................57
14.1.1 OTUk alarm indication signal (OTUk-AIS)...................................................57
14.2 ODUk maintenance signals ............................................................................58
14.2.1 ODUk Alarm Indication Signal (ODUk-AIS)................................................58
14.2.2 ODUk Open Connection Indication (ODUk-OCI).........................................58
14.2.3 ODUk Locked (ODUk-LCK) .........................................................................59
14.3 Client maintenance signal...............................................................................59
14.3.1 Generic AIS for constant bit rate signals........................................................59
15 OTN Defects .................................................................................................................60
16 Acknowledgements.......................................................................................................61
17 Bibliography .................................................................................................................61
18 Open Issues...................................................................................................................62
18.1 ODUk Virtual Concatenation / OTN over SONET........................................62
-5-
1 Scope
This document provides a tutorial for Optical Transport Network standards and their applications. The
objective is to provide the telecommunications engineers with a document that forms the basis for
understanding OTN.
2 Abbreviations
This tutorial uses the following abbreviations:
0xYY YY is a value in hexadecimal presentation
3R Reamplification, Reshaping and Retiming
ACT Activation (in the TCM ACT byte)
AI Adapted Information
AIS Alarm Indication Signal
APS Automatic Protection Switching
BDI Backward Defect Indication
BEI Backward Error Indication
BIAE Backward Incoming Alignment Error
BIP Bit Interleaved Parity
CBR Constant Bit Rate
CI Characteristic Information
CM Connection Monitoring
CRC Cyclic Redundancy Check
DAPI Destination Access Point Identifier
EXP Experimental
ExTI Expected Trace Identifier
FAS Frame Alignment Signal
FDI Forward Defect Indication
FEC Forward Error Correction
GCC General Communication Channel
IaDI Intra-Domain Interface
IAE Incoming Alignment Error
IrDI Inter-Domain Interface
JOH Justification Overhead
LSB Least Significant Bit
MFAS MultiFrame Alignment Signal
MFI Multiframe Indicator
MS Maintenance Signal
-6-
MSB Most Significant Bit

MSI Multiplex Structure Identifier
NNI Network Node Interface
OCh Optical channel with full functionality
OCI Open Connection Indication
ODU Optical Channel Data Unit
ODUk Optical Channel Data Unit-k
ODTUjk Optical channel Data Tributary Unit j into k
ODTUG Optical channel Data Tributary Unit Group
ODUk-Xv X virtually concatenated ODUk's
OH Overhead
OMS Optical Multiplex Section
OMS-OH Optical Multiplex Section Overhead
OMU Optical Multiplex Unit
ONNI Optical Network Node Interface
OOS OTM Overhead Signal
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OPUk Optical Channel Payload Unit-k
OPUk-Xv X virtually concatenated OPUk's
OSC Optical Supervisory Channel
OTH Optical Transport Hierarchy
OTM Optical Transport Module
OTN Optical Transport Network
OTS Optical Transmission Section
OTS-OH Optical Transmission Section Overhead
OTU Optical Channel Transport Unit
OTUk Optical Channel Transport Unit-k
PCC Protection Communication Channel
PM Path Monitoring
PMI Payload Missing Indication
PMOH Path Monitoring OverHead
ppm parts per million
PRBS Pseudo Random Binary Sequence
PSI Payload Structure Identifier
PT Payload Type
-7-
RES Reserved for future international standardization

RS Reed-Solomon
SAPI Source Access Point Identifier
Sk Sink
SM Section Monitoring
SMOH Section Monitoring OverHead
So Source
TC Tandem Connection
TCM Tandem Connection Monitoring
TS Tributary Slot
TxTI Transmitted Trace Identifier
UNI User-to-Network Interface
VCG Virtual Concatenation Group
VCOH Virtual Concatenation Overhead
vcPT virtual concatenated Payload Type
3 What is OTN/OTH
3.1 OTN Standards

There are many standards that fall under the umbrella of “OTN”. This document focuses on Layer 1
standards. Therefore, it does not describe the Physical or Optical layers. Furthermore, it doesn’t
describe any layers implemented in Software. Thus this document only describes the digital layer that
could be implemented in ASIC.
The Optical Transport Hierarchy OTH is a new transport technology for the Optical Transport Network
OTN developed by the ITU. It is based on the network architecture defined in ITU G.872 "Architecture
for the Optical Transport Network (OTN)"
G.872 defines an architecture that is composed of the Optical Channel (OCh), Optical Multiplex
Section (OMS) and Optical Transmission Section (OTS). It then describes the functionality that
needed to make OTN work. However, it may be interesting to note the decision made during G.872
development as noted in Section 9.1/G.872 :
“During the development of ITU-T Rec. G.709, (implementation of the Optical Channel Layer
according to ITU-T Rec. G.872 requirements), it was realized that the only techniques presently
available that could meet the requirements for associated OCh trace, as well as providing an
accurate assessment of the quality of a digital client signal, were digital techniques….”
“For this reason ITU-T Rec. G.709 chose to implement the Optical Channel by means of a digital
framed signal with digital overhead that supports the management requirements for the OCh
listed in clause 6. Furthermore this allows the use of Forward Error Correction for enhanced
system performance. This results in the introduction of two digital layer networks, the ODU and
OTU. The intention is that all client signals would be mapped into the Optical Channel via the
ODU and OTU layer networks.”
Currently there are no physical implementations of the OCh, OMS and OTS layers. As they are defined
and implemented, they will be included in this tutorial.
-8-
Thus the main implementation of OTH is that described in G.709 and G.798.
4 Where is it standardized for

The optical transport network architecture as specified in ITU-T G.872 defines two interface classes:
• Inter-domain interface (IrDI);
• Intra-domain interface (IaDI).
The OTN IrDI interfaces are defined with 3R processing at each end of the interface. This would be the
interface between Operators. It could also be thought of as the interface between different Vendors
within the same Operator (see Figure 1).
Inter-Domain Inter-Domain Inter-Domain

User IrDI Operator A IrDI Operator B IrDI
User
3R 3R 3R 3R 3R 3R
Intra-Domain Intra-Domain Intra-Domain Intra-Domain

IaDI IaDI IaDI IaDI
Figure 1 IaDI vs. IrDI
The IaDI is the interfaces within an Operator or a Vendor domain.

G.709 applies to information transferred across IrDI and IaDI interfaces. G.709 compliance by itself is
not sufficient to guarantee mid-span meet, since it doesn’t specify the electrical or optical interfaces. It
is important to note that G.709 only defines logical interfaces.
5 Why use OTN

OTN offers the following advantages relative to SONET/SDH:
• Stronger Forward Error Correction
• More Levels of Tandem Connection Monitoring (TCM)
• Transparent Transport of Client Signals
• Switching Scalability
OTN has the following disadvantages:
• Requires new hardware and management system
We will discuss the advantages and disadvantages in the following sections.
5.1 Forward Error Correction (FEC)

Forward error correction is a major feature of the OTN.
Already SDH has a FEC defined. It uses undefined SOH bytes to transport the FEC check information
and is therefore called a in-band FEC. It allows only a limited number of FEC check information,
which limits the performance of the FEC.
-9-
For the OTN a Reed-Solomon 16 byte-interleaved FEC scheme is defined, which uses 4x256 bytes of
check information per ODU frame. In addition enhanced (proprietary) FEC schemes are explicitly
allowed and widely used.
FEC has been proven to be effective in OSNR limited systems as well as in dispersion limited systems.
As for non-linear effects, reducing the output power leads to OSNR limitations, against which FEC is
useful. FEC is less effective against PMD, however.
G.709 defines a stronger Forward Error Correction for OTN that can result in up to 6.2 dB
improvement in Signal to Noise Ratio (SNR). Another way of looking at this, is that to transmit a
signal at a certain Bit Error Rate (BER) with 6.2 dB less power than without such an FEC.
The coding gain provided by the FEC can be used to:
- Increase the maximum span length and/or the number of spans, resulting in an extended reach. (Note
that this assumes that other impairments like chromatic and polarization mode dispersion are not
becoming limiting factors.)
- Increase the number of DWDM channels in a DWDM system which is limited by the output power of
the amplifiers by decreasing the power per channel and increasing the number of channels.
(Note that changes in non-linear effects due to the reduced per channel power have to be taken into
account.)
- Relax the component parameters (e.g launched power, eye mask, extinction ratio, noise figures, filter
isolation) for a given link and lower the component costs.
- but the most importantly the FEC is an enabler for transparent optical networks:
Transparent optical network elements like OADMs and PXCs introduce significant optical impairments
(e.g. attenuation). The number of transparent optical network elements that can be crossed by an optical
path before 3R regeneration is needed is therefore strongly limited. With FEC a optical path can cross
more transparent optical network elements.
This allows to evolve from today’s point-to-point links to transparent, meshed optical networks with
sufficient functionality.
Note: There is additional information on FEC in Section 11 of sup.dsn Also Appendix 1 of G.975.1
lists some additional Enhanced FEC schemes.
5.1.1 Theoretical Description
G.709 FEC implements a Reed-Solomon RS(255,239) code. A Reed-Solomon code is specified as
RS(n,k) with s-bit symbols where n is the total number of symbols per codeword, k is the number of
information symbols, and s is the size of a symbol. A codeword consists of data and parity, also known
as check symbols, added to the data. The check symbols are extra redundant bytes used to detect and
correct errors in a signal so that the original data can be recovered.
For G.709:
s = Size of the symbol = 8 bits
n = Symbols per codeword = 255 bytes
k = Information symbols per codeword = 239 bytes
A typical system is shown in Figure 2:
- 10 -
Figure 2 FEC Block Diagram
This means the encoder takes k information symbols of s bits, each, and adds check symbols to make
an n-symbol codeword. There are n-k check symbols of s bits, each. A Reed-Solomon decoder can
correct up to t symbols that contain errors in a codeword, where 2t = n-k.
The following Figure 3 shows a typical Reed-Solomon codeword:
Figure 3 Reed-Solomon Codeword
For the standard ITU recommended RS (255,239) code:

2t = n - k = 255 - 239 = 16
t=8
Hence, the decoder can correct any 8 symbols in a codeword
Reed-Solomon codes treat errors on a symbol basis; therefore, a symbol that contains all bits in error is
as easy to detect and correct as a symbol that contains a single bit-error. That is why the Reed-Solomon
code is particularly well suited to correcting burst errors (where a series of bits in the codeword are
received in error by the decoder.)
Given a symbol size s, the maximum codeword length (n) for a Reed-Solomon code is
n = 2s – 1 = 255
Interleaving data from different codewords improves the efficiency of Reed-Solomon codes because
the effect of burst errors is shared among many other codewords. By interleaving, it spreads the impact
of a noise burst over multiple symbols, which come from several codewords. As long as each
deinterleaved codeword has fewer errors than it can correct, the interleaved group of codewords will be
corrected. It is possible that some codewords will be corrected and some not if excessive errors are
encountered.
Interleaving actually integrates the error correction powers of all of the codewords included in the
interleaved group, that is the depth of the interleaver. This allows a higher rate of code and channel
efficiency and still protects against an occasional very long error. For example, if 64 codewords that
can correct 8 errors each are interleaved, the interleaved group can correct almost any combination of
symbol errors that total less than 512. It does not matter if all 512 are in one long burst, there are 512
- 11 -
one-symbol errors, or anywhere in between. Both ITU-T G.709 and ITU-T G.975 specify interleaving
as part of the transport frame to improve error-correction efficiency.
5.1.2 Coding Gain
The advantage of using FEC is that the probability of an error remaining in the decoded data is lower
than the probability of an error if an FEC algorithm, such as Reed-Solomon, is not used. This is coding
gain in essence.
Coding Gain is difference in Input SNR for a given Output BER. The Input SNR is measured either as
“Q factor” or as Eb/N0 (Section 5.1.2.2), or OSNR ().
The “Net Coding Gain” takes into effect that there was a 7% rate expansion due to the FEC. What this
means is that the data rate had to increase by 7% in order to transmit both the data and the FEC.
5.1.2.1 Coding Gain measured via Q Factor
The widely used technique of measuring coding gain is the Q-factor (Quality factor) measurement. This
technique estimates the OSNR at the optical amplifier or receiver by measuring BER vs. voltage
threshold at voltage levels where BER can be accurately determined (see Figures 4 and 5). In reality,
however, Q-factor is derived from the measurement of the eye-pattern signal. It is defined as the ratio
of peak-to-peak signal to total noise (conventionally electrical):
Figure 4 Eye Diagram
u1 = ON level average value

σ 1 = ON level noise standard deviation
u0 = OFF level average value
σ 0 = OFF level noise standard deviation
A system that requires an operating BER of 10 -15 has a Q-factor measurement of 18 dB without FEC If
RS(255, 239) FEC is employed, the Q-factor measurement decreases to 11.8 dB, yielding 6.2 dB of
coding gain.
- 12 -
BER vs Q for R-S 255 Code (t = 8)
1.0E-03
BER in
1.0E-06 BER out

No Overhead
1.0E-09
BER
1.0E-12
1.0E-15
1.0E-18
1.0E-21
10 11 12 13 14 15 16 17 18 19 20
Q (dB)
Figure 5 BER vs. Q Factor
The 6.2 dB gained through FEC would allow a transmission with longer span while maintaining the
original BER. Thus the transmission distance is improved with relatively small increase in
semiconductor content.
5.1.2.2 Coding Gain measured via Eb/N0
Another way to measure coding gain is with a plot of BER vs. Eb/N0. Eb is the bit energy and can be
described as signal power (S) times the bit time Tb. N 0 is the noise power spectral density and can be
described as the noise power (N) divided by the bandwidth (W). Thus Eb/N0 is equal to SNR *
(Bandwidth/Bit Rate). For a more thorough discussion see [Sklar]
- 13 -
-1
10
-2
10
-3
10
-4
10
-5
10 Uncorrected
-6
10
-7
10
-8 G.709
BER
10
-9
10
-10
10
-11
10
-12
10
10
-13 5.86 dB
-14
10
-15 6.2 dB
10
2 3 4 5 6 7 8 9 10 11 12 13 14 15
Eb/No
Figure 6 BER vs E b/N0
What Figure 6 shows is that for a given input SNR (Eb/N0), what the BER out of the FEC decoder
would be. Thus if one wanted to operate their system at 10-13 BER, then they would need over 14 dB
SNR without FEC or only 8.5 dB with FEC.
5.1.2.3 Coding Gain measured via OSNR
Figure 7 shows the FEC net coding gain (NCG) of various FEC schemes. These are theoretical and real
measurements results from running systems.
Coding gain is the reduction of signal-to-noise ratio due to the use of the FEC at a reference BER
The Net Coding Gain (NCG) takes into account the fact that the bandwidth extension needed for the
FEC scheme is associated with increased noise in the receiver.
For example consider a reference BER of 10-15. The SDH in-band FEC provides a NCG of 4 dB. The
standard OTN FEC a NCG of 6.2 dB and a enhanced FEC a NCG of 9.5 dB.
- 14 -
Unencoded
SDH in -band FEC
OTN standard FEC
OTN EFEC (measured)
OTN EFEC (theoretical)
FEC margins
Figure 7 Coding Gain measured via OSNR
5.2 Tandem Connection Monitoring

SONET/SDH monitoring is divided into Section, Line and Path monitoring. A problem arises when
you have “Carrier’s Carrier” situation as shown in Figure 8, where it is required to monitor a segment
of the path that passes another carrier network.
- 15 -
Border of the OTN

Client mapping into ODU
Operator A
Operator B Operator A
User
Working
User
Protection
Start of the OTN
Client mapping into ODU
protection supervision (TCM4)
domain and domain interconnect supervision (TCM3
lead operator QoS supervision (TCM2)
user QoS supervision (TCM1)
end-to-end path supervision (PM)
Figure 8 Tandem Connection Monitoring
Here Operator A needs to have Operator B carry his signal. However he also needs a way of
monitoring the signal as it passes through Operator B’s network. This is what a “Tandem connection”
is. It is a layer between Line Monitoring and Path Monitoring. SONET/SDH was modified to allow a
single Tandem connection. G.709 allows six.
TCM1 is used by the User to monitor the Quality of Service (QoS) that they see. TCM2 is used by the
first operator to monitor their end-to-end QoS. TCM3 is used by the various domains for Intra domain
monitoring. Then TCM4 is used for protection monitoring by Operator B.
There is no standard on which TCM is used by whom. The operators have to have an agreement, so that
they don’t conflict.
TCM’s also support monitoring of ODUk (G.709 w/0 FEC) connections for one or more of the
following network applications (refer to ITU-T G.805 and ITU-T G.872):
− optical UNI to UNI tandem connection monitoring; monitoring the ODUk connection through
the public transport network (from public network ingress network termination to egress
network termination);
− optical NNI to NNI tandem connection monitoring; monitoring the ODUk connection through
the network of a network operator (from operator network ingress network termination to
egress network termination);
− sublayer monitoring for linear 1+1, 1:1 and 1:n optical channel subnetwork connection
protection switching, to determine the signal fail and signal degrade conditions;
− sublayer monitoring for optical channel shared protection ring (SPRing) protection switching,
to determine the signal fail and signal degrade conditions;
- 16 -
− Monitoring an optical channel tandem connection for the purpose of detecting a signal fail or
signal degrade condition in a switched optical channel connection, to initiate automatic
restoration of the connection during fault and error conditions in the network;
− Monitoring an optical channel tandem connection for, e.g., fault localization or verification of
delivered quality of service.
A TCM field is assigned to a monitored connection as described in 15.8.2.2.6/G.709. The number of
monitored connections along an ODUk trail may vary between 0 and 6. Monitored connections can be
nested, overlapping and/or cascaded. Nesting and cascading is shown in Figure 9. Monitored
connections A1-A2/B1-B2/C1-C2 and A1-A2/B3-B4 are nested, while B1-B2/B3-B4 are cascaded.
TCM6 TCM6 TCM6 TCM6 TCM6 TCM6 TCM6

A1 B1 C1 C2 B2 B3 B4 A2
C1-C2
B1-B2 B3-B4
A1-A2
TCMi TCM OH field not in use T1543640-01
TCMi TCM OH field in use
Figure 9 ODUk monitored connections (Figure 15-16/G.709)
Overlapping monitored connections as shown in Figure 10 (B1-B2 and C1-C2) are also supported.
- 17 -
TCM6 TCM6 TCM6 TCM6 TCM6

A1 B1 C1 B2 C2 A2
C1-C2
B1-B2
A1-A2
TCMi TCM OH field not in use T1543650-01
TCMi TCM OH field in use
Figure 10 Overlapping ODUk monitored connections (Figure 15-17/G.709)
5.3 Transparent Transport of Client Signals

G.709 defines the OPUk which can contain the entire SONET/SDH signal. This means that one can
transport four STM-16/OC-48 signals in one OTU2 and not modify any of the SONET/SDH overhead.
Thus the transport of such client signals in the OTN is bit-transparent (i.e. the integrity of the whole
client signal is maintained).
It is also timing transparent. The asynchronous mapping mode transfers the input timing
(Asynchronous mapping client) to the far end (Asynchronous demapping client).
It is also delay transparent. For example if four STM-16/OC-48 signals are mapped into ODU1’s and
then multiplexed into an ODU2, their timing relationship is preserved until they are demapped back to
ODU1’s.
5.4 Switching Scalability

When SONET/SDH was developed in the mid eighties its main purpose was to provide the transport
technology for voice services. Two switching levels were therefore defined. Lower order switching at
1.5/2 Mbit/s to directly support the T1/E1 voice signals and a higher order switching level at 50/150
Mbit/s for traffic engineering. Switching levels at higher bit rates were not foreseen.
Over time the line rate increased while the switching rate was fixed. The gap between line rate and
switching bit rate widened. Furthermore new services at higher bit rates (IP, Ethernet services) had to
be supported.
Contiguous and virtual concatenation were introduce in order to solve part of the services problem as
they allow to support services above the standard SONET/SDH switching bit rates.
The gap between line or service bit rate and switching bit rate however still exists as even with
concatenation switching is performed at the STS-1/VC-4 level.
- 18 -
For a 4x10G to 40G SONET/SDH multiplexer this means processing of 256 VC-4 in the SDH case and
even worse, processing of 768 STS-1-SPEs in the SONET case. This will result not only in efforts in
the equipment hardware, but also in management and operations efforts.
For efficient equipment and network design and operations, switching at higher bit rates has to be
introduced.
One could now argue that photonic switching of wavelengths is the solution. But with photonic
switching the switching bit rate is bound to the bit rate of the wavelength and as such would be the
service. A independent selection for service bit rates and DWDM technology is not possible.
A operator offering 2.5 Gbit/s IP interconnection would need a Nx2.5G DWDM system. When adding
10 G services he has to upgrade some of its wavelengths to 10G. This would lead to inefficient network
designs.
OTN provides the solution to the problem by placing no restrictions on switching bit rates. As the line
rate grows new switching bit rates are added.
A operator can offer services at various bit rates (2.5G, 10G, …) independent of the bit rate per
wavelength using the multiplexing and inverse multiplexing features of the OTN.
6 OTN Hierarchy Overview

G.709 defines a number of layers in the OTN hierarchy (Figure 11).
Clients (e.g. STM-N, ATM, IP, Ethernet, OTN ODUk)
OPUk
ODUkP
ODUk
ODUkT
substructure
OC h
OTUkV OTUk OTUkV OTUk
OCh OChr
OMSn
OPSn
OTSn
T1543480-01
OTM-n.m OTM-0.m, OTM-nr.m

Full functionality Reduced functionality
OTM interface OTM interface
Figure 11 Full OTN Hierarchy
Figure 12 shows how they are envisioned being used in a network.

- 19 -
OTN domain
domain
optical optical sub-network
optical
sub-network
sub-network IrDI
IaDIs IaDIs
OTS OTS OTS OTS OTS OTS OTS

OMS OMS OPS OMS OMS
OCh OCh OChr OCh
OTU OTU OTU OTU
ODU
Optical line amplifier (OTS termination) 3-R regeneration (OCh, OTU termination)
Optical cross connect/add
-drop/terminal mux
Client access (ODU termination)
(OMS termination)
Figure 12 OTN Network Layers
However for all intents and purposes there are only four layers
OCh
OTUk
OTN Hierarchy
ODUk
OPUk
SONET/SDH CBR Signals
Figure 13 OTN Hierarchy
The OPUk, ODUk, and OTUk are in the electrical domain. The OCh is in the Optical domain. There
are more layers in the Optical domain than just the OCh, but they are not being used now.
The OPUk encapsulates the Client signal (e.g. SONET/SDH) and does any rate justification that is
needed. It is analogous to the Path layer in SONET/SDH in that it is mapped at the source, demapped at
the sink, and not modified by the network.
The ODUk performs similar functions as the Line Overhead in SONET/SDH.
The OTUk contains the FEC and performs similar functions as the Section Overhead in SONET/SDH.
After the FEC are added, the signal is then sent to a SERDES (Serializer/Deserializer) to be converted
to the Optical Domain.
The data rates were constructed so that they could transfer SONET/SDH signal efficiently. The bit rates
are shown in the following tables:
- 20 -
Table 1 OTU types and capacity (Table 7-1/G.709)
OTU type OTU nominal bit rate OTU bit rate tolerance
OTU1 255/238 × 2 488 320 kbit/s
OTU2 255/237 × 9 953 280 kbit/s ±20 ppm
OTU3 255/236 × 39 813 120 kbit/s
NOTE – The nominal OTUk rates are approximately: 2 666 057.143 kbit/s (OTU1), 10 709 225.316 kbit/s
(OTU2) and 43 018 413.559 kbit/s (OTU3).
Table 2 ODU types and capacity (Table 7-2/G.709)
ODU type ODU nominal bit rate ODU bit rate tolerance
ODU1 239/238 × 2 488 320 kbit/s
ODU2 239/237 × 9 953 280 kbit/s ±20 ppm
ODU3 239/236 × 39 813 120 kbit/s
NOTE – The nominal ODUk rates are approximately: 2 498 775.126 kbit/s (ODU1), 10 037 273.924 kbit/s
(ODU2) and 40 319 218.983 kbit/s (ODU3).
Table 3 OPU types and capacity (Table 7-3/G.709)
OPU type OPU Payload nominal bit rate OPU Payload bit rate tolerance
OPU1 2 488 320 kbit/s
OPU2 238/237 × 9 953 280 kbit/s ±20 ppm
OPU3 238/236 × 39 813 120 kbit/s
NOTE – The nominal OPUk Payload rates are approximately: 2 488 320.000 kbit/s (OPU1 Payload),
9 995 276.962 kbit/s (OPU2 Payload) and 40 150 519.322 kbit/s (OPU3 Payload).
Table 4 OTUk/ODUk/OPUk frame periods (Table 7-4/G.709)
OTU/ODU/OPU type Period (Note)

OTU1/ODU1/OPU1/OPU1-Xv 48.971 µs
NOTE – The period is an approximated value, rounded to 3 digits.
7 OTUk, ODUk, OPUk Frame Structure

Figure 14 shows the overall Frame format for an OTUk signal. The various fields will be explained in
the following subsections.
- 21 -
Column PM and TCMi (i=1..6)

Row 1 14 1516 17 3824 1 2 3
1 TTI BIP-8
Overhead
2
OPUk
OD
OPUk Payload
Uk
(4 x 3808 bytes) 0 1 2 3 4 5
Ov
3
erh
BDI
SAPI
ea
BEI
d
4 15
16
DAPI
BIP8 Parity Block 31
32 OPUk OH
Column # 15 16
Operator 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Specific
1 Frame Alignment overhead OTUk overhead 2 Mapping
63 specific
2 RES TCM TCM6 TCM5 TCM4 FTFL
Row#
3
ACT OPUk
3 EXP overhead
TCM3 TCM2 TCM1 PM 4 PSI
4 GCC1 GCC2 APS/PCC RES
0 PT
1
PM: Path Monitoring FTFL: Fault Type & Fault Location reporting channel TTI: Trail Trace Identifier
TCM: Tandem Connection Monitoring EXP: Experimental BIP8: Bit Interleaved Parity - level 8
BEI: Backward Error Indication RES
SAPI: Source Access Point Identifier GCC: General Communication Channel
DAPI: Destination Access Point Identifier APS: Automatic Protection Switching coordination channel BDI: Backward Defect Indication
255
RES: Reserved for future international standardisation PCC: Protection Communication Control channel STAT: Status
ACT: Activation/deactivation control channel PSI: Payload Structure Identifier
PT: Payload Type
Figure 14 OTN Frame Format (Figure 15-3/G.709)
8 OPUk Overhead and Processing

The OPUk (k = 1,2,3) frame structure is shown in Figure 15. It is organized in an octet-based block
frame structure with four rows and 3810 columns.
Column
Row 15 16 17 3824
1
OPUk overhead
2
area
OPUk payload area

(4 × 3808 bytes)
3
T1542440-00
Figure 15 OPUk frame structure (Figure 13-1/G.709)
The two main areas of the OPUk frame are:

• OPUk overhead area;
• OPUk payload area;
- 22 -
Columns 15 to 16 of the OPUk are dedicated to OPUk overhead area.

Columns 17 to 3824 of the OPUk are dedicated to OPUk payload area.
NOTE – OPUk column numbers are derived from the OPUk columns in the ODUk frame
OPUk OH information is added to the OPUk information payload to create an OPUk. It includes
information to support the adaptation of client signals. The OPUk OH is terminated where the OPUk is
assembled and disassembled.
8.1 OPUk Overhead Byte Descriptions

The OPUk Overhead bytes are shown in Figure 16
Column
Row 15 16 17 18 3824
1 RES JC
2 RES JC
3 RES JC
4 PSI NJO PJO
OPUk OH OPUk payload (4 × 3808 bytes) T1542770-00

0 PT
1
PSI 1 2 3 4 5 6 7 8
RES
JC Reserved JC
255
Figure 16 OPUk frame (Figure 17-1/G.709)

8.1.1 Payload Structure Identifier (PSI)
The 256-byte PSI signal is aligned with the ODUk multiframe (i.e. PSI[0] is present at ODUk
multiframe position 0000 0000, PSI[1] at position 0000 0001, PSI[2] at position 0000 0010, etc.).
PSI[0] contains a one-byte Payload type. PSI[1] to PSI[255] are mapping and concatenation specific.
8.1.2 Payload Type (PT)
A one-byte payload type signal is defined in the PSI[0] byte of the payload structure identifier to
indicate the composition of the OPUk signal. The code points are defined in Table 5.
8.2 Mapping Signals into an OPUk

There are a number of Payload Types defined in Table 5..
- 23 -
Table 5 Payload type code points (Table 15-8/G.709)
MSB LSB Hex code

Interpretation
1234 5678 (Note 1)
0000 0001 01 Experimental mapping (Note 3)
0000 0010 02 Asynchronous CBR mapping, see 17.1
0000 0011 03 Bit synchronous CBR mapping, see 17.1
0000 0100 04 ATM mapping, see 17.2
0000 0101 05 GFP mapping, see 17.3
0000 0110 06 Virtual Concatenated signal, see 18 (NOTE 5)
0001 0000 10 Bit stream with octet timing mapping, see 17.5.1
0001 0001 11 Bit stream without octet timing mapping, see 17.5.2
0010 0110 20 ODU multiplex structure, see 19
0101 0101 55 Not available (Note 2)
0110 0110 66 Not available (Note 2)
1000 xxxx 80-8F Reserved codes for proprietary use (Note 4)
1111 1101 FD NULL test signal mapping, see 17.4.1
1111 1110 FE PRBS test signal mapping, see 17.4.2
1111 1111 FF Not available (Note 2)
NOTE 1 – There are 226 spare codes left for future international standardization.
NOTE 2 – These values are excluded from the set of available code points. These bit patterns are present
in ODUk maintenance signals.
NOTE 3 – Value "01" is only to be used for experimental activities in cases where a mapping code is not
defined in this table.
NOTE 4 – These 16code values will not be subject to standardization.
NOTE 5 – For the payload type of the virtual concatenated signal a dedicated payload type overhead
(vcPT) is used, see 18.
The Virtual Concatenated signal and the ODU multiplex structure are dealt with later in this document.
Mapping SONET/SDH (CBR) into OPUk either synchronously or asynchronously is the most common
mapping. Synchronous mapping is a subset of asynchronous mapping, thus we will only discuss
asynchronous mapping.
8.2.1 Frequency Justification
Asynchronous mapping of a CBR2G5, CBR10G or CBR40G signal into an OPUk (k = 1,2,3) may be
performed (see Figure 17). The maximum bit-rate tolerance between OPUk and the client signal clock
that can be accommodated by this mapping scheme is ±65 ppm. With a bit-rate tolerance of ±20 ppm
for the OPUk clock, the client signal's bit-rate tolerance can be ±45 ppm. If the client’s frequency is out
of range, then there aren’t enough justification bytes in the OPUk overhead to make up the difference.
- 24 -
Column
Row 15 16 17 18 3824
1 RES JC
2 RES JC
3 RES JC
4 PSI NJO PJO
OPUk OH OPUk payload (4 × 3808 bytes) T1542770-00

0 PT
1
PSI 1 2 3 4 5 6 7 8
RES
JC Reserved JC
255
Figure 17 OPUk frame structure for the mapping of a CBR2G5, CBR10G or CBR40G signal
(Figure 17-1/G.709)
The OPUk overhead for these mappings consists of a payload structure identifier (PSI) including the
payload type (PT) and 255 bytes reserved for future international standardization (RES), three
justification control (JC) bytes, one negative justification opportunity (NJO) byte, and three bytes
reserved for future international standardization (RES). The JC bytes consist of two bits for justification
control and six bits reserved for future international standardization.
The OPUk payload for these mappings consists of 4 × 3808 bytes, including one positive justification
opportunity (PJO) byte.
The asynchronous and bit synchronous mapping processes generate the JC, NJO and PJO according to
Table 6 and Table 7, respectively. The demapping process interprets JC, NJO and PJO according to
Table 8. Majority vote (two out of three) is used to make the justification decision in the demapping
process to protect against an error in one of the three JC signals.
Table 6 JC, NJO and PJO generation by asynchronous mapping process (Table 17-1/G.709)
JC
NJO PJO
[78]
00 justification byte data byte
01 data byte data byte
10 not generated
11 justification byte justification byte
- 25 -
Table 7 JC, NJO and PJO generation by bit synchronous mapping process (Table 17-2/G.709)
JC
NJO PJO
[78]
01
10 not generated
11
Table 8 JC, NJO and PJO interpretation (Table 17-3/G.709)
JC
NJO PJO
[78]
01 data byte data byte
10 (Note) justification byte data byte
11 justification byte justification byte
NOTE – A mapper circuit does not generate this code. Due to bit errors a demapper circuit might
receive this code.
The value contained in NJO and PJO when they are used as justification bytes is all-0s. The receiver is
required to ignore the value contained in these bytes whenever they are used as justification bytes.
The OPUk signal for the asynchronous mapping is created from a locally generated clock, which is
independent of the CBR2G5, CBR10G or CBR40G client signal. The CBR2G5, CBR10G, CBR40G
signal is mapped into the OPUk using a positive/negative/zero (pnz) justification scheme.
The OPUk clock for the synchronous mapping is derived from the CBR2G5, CBR10G or CBR40G
client signal. The CBR2G5, CBR10G or CBR40G signal is mapped into the OPUk without using the
justification capability within the OPUk frame: NJO contains a justification byte, PJO contains a data
byte, and the JC signal is fixed to 00.
It should be noted that unlike SONET/SDH, there is no “Start of Payload” indication or Pointer.
8.2.2 Mapping a CBR2G5 signal (e.g. STM-16) into OPU1
Groups of 8 successive bits (not necessarily being a byte) of the CBR2G5 signal are mapped into a
Data (D) byte of the OPU1 (Figure 18). Once per OPU1 frame, it is possible to perform either a
positive or a negative justification action.
- 26 -
3824
15
16
17
18
PSI RES RES RES
3805D
JC
1 D D D
3805D
NJO JC JC
2 D D D
3 PJO D D 3805D D
4 D 3805D D
T1542780-00
Figure 18 Mapping of a CBR2G5 signal into OPU1 (Figure 17-2/G.709)
8.2.3 Mapping a CBR10G signal (e.g. STM-64) into OPU2

Groups of 8 successive bits (not necessarily being a byte) of the CBR10G signal are mapped into a
Data (D) byte of the OPU2 (Figure 19). 64 fixed stuff (FS) bytes are added in columns 1905 to 1920.
Once per OPU2 frame, it is possible to perform either a positive or a negative justification action.
1904
1905
1920
1921
3824
15
16
17
PSI RES RES RES
119 × 16D
NJO JC JC JC
1 118 × 16D 16FS
2 118 × 16D 16FS 119 × 16D
3 118 × 16D 16FS 119 × 16D

PJO
4 15D + 117 × 16D 16FS 119 × 16D

T1542790-00
Figure 19 Mapping of a CBR10G signal into OPU2 (Figure 17-3/G.709)
8.2.4 Mapping a CBR40G signal (e.g. STM-256) into OPU3

Groups of 8 successive bits (not necessarily being a byte) of the CBR40G signal are mapped into a data
(D) byte of the OPU3 (Figure 20). 128 fixed stuff (FS) bytes are added in columns 1265 to 1280 and
2545 to 2560. Once per OPU3 frame, it is possible to perform either a positive or a negative
justification action.
1264
1265
1280
1281
2544
2545
2560
2561
3824
15
16
17
PSI RES RES RES
78 × 16D 79 × 16D 79 × 16D

JC
1 16FS 16FS
78 × 16D 79 × 16D 79 × 16D

NJO JC JC
2 16FS 16FS
3 78 × 16D 16FS 79 × 16D 16FS 79 × 16D

PJO
4 15D + 77 × 16D 16FS 79 × 16D 16FS 79 × 16D

T1542800-00
Figure 20 Mapping of a CBR40G signal into OPU3 (Figure 17-4/G.709)

- 27 -
9 ODUk Overhead and Processing

The ODUk (k = 1,2,3) frame structure is shown in Figure 21. It is organized in an octet-based block
frame structure with four rows and 3824 columns.
Column
Row 1 14 15 3824
1
2 OPUk area
ODUk overhead (4 × 3810 bytes)
3 area
4
Area reserved for FA and OTUk overhead. T1542430-00
Figure 21 ODUk frame structure (Figure 12-1/G.709)
The three main areas of the ODUk frame are:

• OTUk area
• ODUk overhead area;
• OPUk area.
Columns 1 to 14 of rows 2-4 are dedicated to ODUk overhead area.
Columns 1 to 14 of row 1 are reserved for frame alignment and OTUk specific overhead.
Columns 15 to 3824 of the ODUk are dedicated to OPUk area.
ODUk OH information is added to the ODUk information payload to create an ODUk. It includes
information for maintenance and operational functions to support optical channels. The ODUk OH
consists of portions dedicated to the end-to-end ODUk path and to six levels of tandem connection
monitoring. The ODUk path OH is terminated where the ODUk is assembled and disassembled. The
TC OH is added and terminated at the source and sink of the corresponding tandem connections,
respectively.
When people talk about the ODUk, it may or may not include the bytes in row 1. If one talks about the
ODUk rate, then the bytes in row 1 are included. However if one talks about the ODUk OH then the
bytes in row 1 are not included. In the functional model (G.798) the ODUk is considered to include row
1, but with all the bytes in row 1 equal to zero (Section 14/G.798 and Section 14.3.1.1/G.798).
The ODUk overhead location is shown in Figure 22, Figure 23 and Figure 24.
Column #
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 Frame alignment overhead OTUk overhead

TCM
RES
Row #
2 TCM6 TCM5 TCM4 FTFL OPUk

ACT
overhead
3 TCM3 TCM2 TCM1 PM EXP
4 GCC1 GCC2 APS/PCC RES

T1543810-01
Figure 22 ODUk overhead (Figure 15-12/G.709)

- 28 -
PM
1 2 3
TTI BIP-8
0 1 2 3 4 5 6 7 8
BDI
SAPI BEI STAT
15
16 T1543620-01
DAPI
31
32
Operator
specific
63
Figure 23 ODUk path monitoring overhead (Figure 15-13/G.709)
TCMi
1 2 3
TTIi BIP-8i
0 1 2 3 4 5 6 7 8
BDIi
SAPI BEIi/BIAEi STATi

15
16
DAPI
31
32
Operator
Specific
63
Figure 24 ODUk tandem connection monitoring #i overhead (Figure 15-14/G.709)

- 29 -
9.1 Path Monitoring (PM) Byte Descriptions

9.1.1 Trail Trace Identifier (TTI)
The TTI is a 64-Byte signal that occupies one byte of the frame and is aligned with the OTUk
multiframe. It is transmitted four times per multiframe. The definition of what the fields’ mean is in
G.709/Section 15.2.
9.1.2 BIP-8
This byte provides a bit interleaved parity-8 (BIP-8) code. For definition of BIP-8 refer to BIP-X
definition in ITU-T G.707/Y.1322.
The ODUk BIP-8 is computed over the bits in the OPUk (columns 15 to 3824) area of ODUk frame i,
and inserted in the ODUk PM BIP-8 overhead location in the ODUk frame i+2 (Figure 25).
1 14 15 3824
1
Frame i
2
OPUk
BIP8
4
BIP8
Frame i+1
1
2
BIP8
1
Frame i+2
2
BIP8
4 T1542590-00
Figure 25 ODUk PM BIP-8 computation (Figure 15-15/G.709)
9.1.3 Backward Defect Indication (BDI)

This is defined to convey the “Signal Fail” Status detected at the Path Terminating Sink Function, to
the upstream node.
This signal is created by the consequent action of aBDI (G.798/14.2.1.2). The actual defect equations
are:
RI_BDI = aBDI = CI_SSF or dAIS or dOCI or dLCK or dTIM
dAIS, dOCI, dLCK, dTIM are all detected at the PM layer
CI_SSF = AI_TSF at TCM layer
AI_TSF = aTSF = CI_SSF or (dAIS or dLTC or dOCI or dLCK or (dTIM and not
TIMActDis)) and TCMCI_Mode == OPERATIONAL)
dAIS, dLTC, dOCI, dLCK, and dTIM are TCM defects
CI_SSF = aSSF = dAIS or dLOF or dLOM (G.798/12.3.1.2)
dAIS here is the SM AIS
- 30 -
9.1.4 Backward Error Indication and Backward Incoming Alignment Error (BEI/BIAE)
This signal is used to convey in the upstream direction the count of interleaved-bit blocks that have
been detected in error by the corresponding ODUk path monitoring sink using the BIP-8 code. This
count has nine legal values, namely 0-8 errors. The remaining seven possible values represented by
these four bits can only result from some unrelated condition and are interpreted as zero errors (Table
9).
Table 9 ODUk PM BEI interpretation (Table 15-2/G.709)
ODUk PM BEI
bits BIP violations
1234
0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
1001 to 1111 0
9.1.5 Path Monitoring Status (STAT)

They indicate the presence of a maintenance signal (Table 10). For more explanation on the different
types of maintenance signals, see Section 14 “OTN Maintenance Signals”
Table 10 ODUk PM status interpretation (Table 15-3/G.709)
PM byte 3,
bits Status
678
000 Reserved for future international standardization
001 Normal path signal
101 Maintenance signal: ODUk-LCK
110 Maintenance signal: ODUk-OCI
111 Maintenance signal: ODUk-AIS
9.2 Tandem Connection Monitoring (TCM)

There are six TCM’s. They can be nested or overlapping.
multiframe. It is transmitted four times per multiframe. The definition of what the fields’ mean is in
G.709/Section 15.2.
- 31 -
9.2.2 BIP-8
Each ODUk BIP-8 is computed over the bits in the OPUk (columns 15 to 3824) area of ODUk frame i,
and inserted in the ODUk TCM BIP-8 overhead location (associated with the tandem connection
monitoring level) in ODUk frame i+2 (Figure 26).
1 14 15 3824
1
BIP8
Frame i
2
OPUk
3
4
BIP8
1
Frame i+1
BIP8
1
Frame i+2
BIP8
4
T1542620-00
Figure 26 ODUk TCM BIP-8 computation (Figure 15-18/G.709)
The BIP-8 is only overwritten at the start of a Tandem Connection. Any existing TCM is not
overwritten.
This is defined to convey the “Signal Fail” Status detected at the Path Terminating Sink Function, to
the upstream node.
This signal is created by the consequent action of aBDI at the TCM level (G.798/14.5.1.1.2). The actual
defect equations are:
RI_BDI = aBDI = (CI_SSF or dAIS or dLTC or dOCI or dLCK or (dTIM and not TIMActDis)) and
TCMCI_Mode!= TRANSPARENT
dAIS and dTIM are TCM defects
CI_SSF = aSSF = dAIS or dLOF or dLOM (G.798.12.3.1.2)
dAIS here is the SM AIS
been detected as being in error by the corresponding ODUk tandem connection monitoring sink using
the BIP-8 code. It is also used to convey in the upstream direction an incoming alignment error (IAE)
condition that is detected in the corresponding ODUk tandem connection monitoring sink in the IAE
overhead.
- 32 -
During a IAE condition the code "1011" is inserted into the BEI/BIAE field and the error count is
ignored. Otherwise the error count (0-8) is inserted into the BEI/BIAE field. The remaining six possible
values represented by these four bits can only result from some unrelated condition and are interpreted
as zero errors (Table 11) and BIAE not active.
Table 11 ODUk TCM BEI interpretation (Table 15-4/G.709)
ODUk TCM BEI BIAE

bits BIP violations
1234
0000 false 0
0001 false 1
0010 false 2
0011 false 3
0100 false 4
0101 false 5
0110 false 6
0111 false 7
1000 false 8
1001,1010 false 0
1011 true 0
1100 to 1111 false 0
9.2.5 TCM Monitoring Status (STAT)

For each tandem connection monitoring field three bits are defined as status bits (STAT). They indicate
the presence of a maintenance signal, if there is an incoming alignment error at the source TCM, or if
there is no source TCM active (Table 12).).
- 33 -
Table 12 ODUk TCM status interpretation (Table 15-5/G.709)
TCM byte 3,
bits Status
678
000 No source TC
001 In use without IAE
010 In use with IAE
101 Maintenance signal: ODUk-LCK
110 Maintenance signal: ODUk-OCI
111 Maintenance signal: ODUk-AIS
9.2.6 Tandem Connection Monitoring ACTivation/deactivation (TCM-ACT)

Its definition is for further study.
9.2.7 General Communication Channels (GCC1, GCC2)
The protocol of the bytes in this channel is defined in G.7712/Y.1703.
9.2.8 Automatic Protection Switching and Protection Communication Channel (APS/PCC)
Up to eight levels of nested APS/PCC signals may be present in this field (Table 13). The APS/PCC
bytes in a given frame are assigned to a dedicated level depending on the value of MFAS as follows:
Table 13 Multiframe to allow separate APS/PCC for each monitoring level (Table 15-6/G.709)
MFAS bit APS/PCC channel Protection scheme using the

678 applies to connection APS/PCC channel
monitoring level (NOTE)
000 ODUk Path ODUk SNC/N
001 ODUk TCM1 ODUk SNC/S, ODUk SNC/N
111 OTUk Section ODUk SNC/I
For linear protection schemes, the bit assignments for these bytes and the bit-oriented protocol are
given in Recommendation G.873.1. Bit assignment and byte oriented protocol for ring protection
schemes are for further study.
9.2.9 Fault Type and Fault Location reporting communication channel (FTFL)
See G.709 section 15.8.2.5 for an explanation of FTFL.
10 OTUk Overhead and Processing

The OTUk (k = 1,2,3) frame structure is based on the ODUk frame structure and extends it with a
forward error correction (FEC). 256 columns are added to the ODUk frame for the FEC and the
- 34 -
overhead bytes in row 1, columns 8 to 14 of the ODUk overhead are used for OTUk specific overhead,
resulting in an octet-based block frame structure with four rows and 4080 columns.
The bit rates of the OTUk signals are defined in Table 1.
The OTUk forward error correction (FEC) contains the Reed-Solomon RS(255,239) FEC codes. If no
FEC is used, fixed stuff bytes (all-0s pattern) are inserted.
The RS(255,239) FEC code is specified in Annex A/G.709.
OTUk OH information is part of the OTUk signal structure. It includes information for operational
functions to support the transport via one or more optical channel connections. The OTUk OH is
terminated where the OTUk signal is assembled and disassembled.
The overhead is shown in Figure 27:
Column
Row 1 7 8 14 15 3824 3825 4080
1 FA OH OTUk OH
2
OTUk FEC
(4 x 256 bytes)
3
SM
Column # 1 2 3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 TTI BIP-8
1 FAS MFAS SM GCC0 RES
0 1 2 3 4 5 6 7 8
FA: Frame Alignment
BDI
IAE
FAS: Frame Alignment Signal SAPI BEI/BIAE RES
MFAS: MultiFrame Alignment Signal 15
SM: Section Monitoring 16
GCC: General Communication Channel
RES: Reserved for future international standardisation DAPI
TTI: Trail Trace Identifier
DAPI: Destination Access Point Identifier 31
SAPI: Source Access Point Identifier 32
BIP8: Bit Interleaved Parity - level 8
BEI: Backward Error Indication
BDI: Backward Defect Indication Operator
IAE: Incoming Alignment Error Specific
BIAE: Backward Incoming Alignment Error
63
Figure 27 OTUk Overhead (Figure 15-2/G.709)
10.1 Scrambling
The OTUk signal needs sufficient bit timing content to allow a clock to be recovered. A suitable bit
pattern, which prevents a long sequence of "1"s or "0"s, is provided by using a scrambler.
The operation of the scrambler is functionally identical to that of a frame synchronous scrambler of
sequence length 65535 operating at the OTUk rate.
3 12 16
The generating polynomial is 1 + x + x + x + x . Figure 28 shows a functional diagram of the frame
synchronous scrambler.
- 35 -
Data in
D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q
OTUk S S S S S S S S S S S S S S S S
clock
Scrambled
OTUk MSB of MFAS byte data out
T1542420-00
Figure 28 Frame synchronous scrambler (Figure 11-3/G.709)
The scrambler is reset to "FFFF" (HEX) on the most significant bit of the byte following the last
framing byte in the OTUk frame, i.e. the MSB of the MFAS byte. This bit, and all subsequent bits to be
16
scrambled, are added modulo 2 to the output from the x position of the scrambler. The scrambler runs
continuously throughout the complete OTUk frame. The framing bytes (FAS) of the OTUk overhead
are not scrambled.
Scrambling is performed after FEC check bytes computation and insertion into the OTUk signal.
10.2 Frame Alignment Overhead

10.2.1 Frame alignment signal (FAS)
A six byte OTUk-FAS signal (Figure 29) is defined in row 1, columns 1 to 6 of the OTUk overhead.
OA1 is "1111 0110". OA2 is "0010 1000".
FAS OH Byte 1 FAS OH Byte 2 FAS OH Byte 3 FAS OH Byte 4 FAS OH Byte 5 FAS OH Byte 6
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
OA1 OA1 OA1 OA2 OA2 OA2

T1542510-00
Figure 29 Frame alignment signal overhead structure (Figure 15-7/G.709)
10.2.2 Multiframe alignment signal (MFAS)

Some of the OTUk and ODUk overhead signals span multiple OTUk/ODUk frames. A single
multiframe alignment signal (MFAS) byte is defined in row 1, column 7 of the OTUk/ODUk overhead
(Figure 30). The value of the MFAS byte will be incremented each OTUk/ODUk frame and provides as
such a 256 frame multiframe.
- 36 -
MFAS OH Byte
1 2 3 4 5 6 7 8
.
.
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1
0 0 0 0 0 0 1 0
MFAS sequence
0 0 0 0 0 0 1 1
0 0 0 0 0 1 0 0
.
.
.
.
1 1 1 1 1 1 1 0
1 1 1 1 1 1 1 1
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 T1542520-00
.
.
Figure 30 Multiframe alignment signal overhead (Figure 15-8/G.709)
Individual OTUk/ODUk overhead signals use this central multiframe to lock their 2-frame, 4-frame, 8-
frame, 16-frame, 32-frame, etc. multiframes to the principal frame.
10.3 SM Byte Descriptions

The OTUk overhead location is shown in Figure 31 and Figure 32.
Column #
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 Frame alignment overhead SM GCC0 RES
OPUk overhead
Row #
3 ODUk overhead
4
T1542530-00
Figure 31 OTUk overhead (Figure 15-9/G.709)

- 37 -
SM
1 2 3
TTI BIP-8
0 1 2 3 4 5 6 7 8
BDI
IAE
SAPI BEI/BIAE RES
15
16
DAPI
31
32
Operator
Specific
63
Figure 32 OTUk section monitoring overhead (Figure 15-10/G.709)

multiframe. It is transmitted four times per multiframe. The definition of what the fields mean is in
G.709/Section 15.2.
10.3.2 BIP-8
The OTUk BIP-8 is computed over the bits in the OPUk (columns 15 to 3824) area of OTUk frame i,
and inserted in the OTUk BIP-8 overhead location in OTUk frame i+2 (Figure 33).
1 14 15 3824
BIP8
1
Frame i
2
OPUk
3
4
BIP8
BIP8
Frame i+1
1
2
4
BIP8
1
Frame i+2
4 T1542550-00
Figure 33 OTUk SM BIP-8 computation (Figure 15-11/G.709)

- 38 -
Note: The OPUk includes the Justification Bytes, thus an OTN signal can not be retimed without
demapping back to the client signal.
This is defined to convey the “Signal Fail” Status detected at the Section Terminating Sink Function, to
the upstream node.
This signal is created by the consequent action aBDI at the SM level (G.798/13.2.1.2). The actual
defect equations are:
RI_BDI = aBDI = CI_SSF or (dTIM and not TIMActDis)
dAIS = OTUk-AIS (G.798.6.2.6.3.1)
dTIM = G.798.6.2.2.1
been detected in error by the corresponding OTUk section monitoring sink using the BIP-8 code. It is
also used to convey in the upstream direction an incoming alignment error (IAE) condition that is
detected in the corresponding OTUk section monitoring sink in the IAE overhead.
During a IAE condition the code "1011" is inserted into the BEI/BIAE field and the error count is
ignored. Otherwise the error count (0-8) is inserted into the BEI/BIAE field. The remaining six possible
values represented by these four bits can only result from some unrelated condition and are interpreted
as zero errors (Table 14) and BIAE not active.
- 39 -
Table 14 OTUk SM BEI interpretation (Table 15-1/G.709)
OTUk SM BEI/BIAE BIAE

bits BIP violations
1234
0000 false 0
0001 false 1
0010 false 2
0011 false 3
0100 false 4
0101 false 5
0110 false 6
0111 false 7
1000 false 8
1001,1010 false 0
1011 true 0
1100 to 1111 false 0
10.3.5 Incoming Alignment Error (IAE)

A single-bit incoming alignment error (IAE) signal is defined to allow the ingress point to inform its
peer egress point that an alignment error in the incoming signal has been detected.
IAE is set to "1" to indicate a frame alignment error, otherwise it is set to "0".
The egress point may use this information to suppress the counting of bit errors, which may occur as a
result of a frame phase change of the OTUk at the ingress of the section.
G.798 shows an incoming alignment error being detected on the source side (Section 13.3.1.1/G.798).
The consequent action (AI_IAE) is then used to set the SM IAE bit (Section 13.2.1.1). Practically it is
detected on the sink side and then passed to the source side. However if one is going through an ODUk
switch, then it would need to be detected on the source side.
10.4 General Communication Channel 0 (GCC0)

The protocol of the bytes in this channel is defined in G.7712/Y.1703.
11 ODUk Multiplexing
Multiplexing in the OTN domain is defined in Section 19 of G.709. Four ODU1’s can be multiplexed
to an ODU2. Up to sixteen ODU1’s or four ODU2’s can be multiplexed to an ODU3. It is possible to
mix ODU1’s and ODU2’s in an ODU3.
For ODU2 to ODU3 multiplexing, there has to be two positive stuff opportunities! For ODU1 to ODU3
multiplexing, there is a fixed stuff in column 119! Thus the stuffing for multiplexing is different from
the stuffing for mapping. In order to understand why, it is necessary to examine the data rates.
11.1 Multiplexing Data Rates

11.1.1 ODU1 to ODU2 Justification Rate
For the case of multiplexing ODU1 to ODU2:
From Table 2 ODU1 rate = 239/238 * OC48 +- 20 ppm = 2,498,775,126 +- 49,976 b/s
- 40 -
We can put data in the "Fixed Stuff" bits of the OPU2 payload that is shown in Figure 19. Thus the
OPU2 payload is now 238/239 * ODU2 rate
or: 238/239 * 239/237 * OC192 +- 20 ppm
The OPU2 payload is time sliced for the four ODU1’s. Thus each ODU1 has:
238/237 * OC48 +- 20 ppm = 2,498,819,241 +- 49,976 b/s
The worst case frequency difference is then:
(2,498,819,241 + 49,976) - (2,498,775,126 - 49,976) = 144,067 b/s or 57.65 ppm
Thus we have to account for a data rate mismatch of 144,067 b/s by stuffing. The stuffing is done on a
multiframe basis. Each timeslot is stuffed once per four frames.
The stuffing rate is: (stuff bits/frame)/(bits/frame) * (data rate)
= (8/4)/(3824*4*8)*(238/237*OC192) = 163,364 b/s = 65 PPM
Thus in the worst case, there are enough data bytes coming in to match the outgoing rate!
From Table 2: ODU2 rate = 239/237 * OC192 +- 20 ppm = 10,037,273,930 +- 200,745 b/s
or: 238/239 * 239/236 * OC768 +- 20 ppm
The OPU3 payload is time sliced for the four ODU2’s. Thus each ODU2 has:
238/236 * OC192 +- 20 ppm = 10,037,629,830 +- 200,753 b/s
(10,037,629,830 + 200,753) - (10,037,273,930 - 200,745) = 757,398 b/s or +75 ppm
and
(10,037,629,830 - 200,753) - (10,037,273,930 + 200,745) = -45,598 b/s or -4.5 ppm
multiframe basis. This is more then the +- 65 ppm that the normal scheme can accommodate. Thus,
each timeslot has two positive stuff opportunities and one negative stuff opportunity per four frames.
The stuffing rate is: (stuff bits/frame) * (bits/sec)/(bits/frame)
= (16/4)/(3824*4*8)*(238/236*OC768) = 1,312,452 b/s = 130 PPM
Therefore in the worst case, there are enough data bytes coming in to match the outgoing rate!
From Table 2: ODU1 rate = 239/238 * OC48 +- 20 ppm = 2,498,775,126 +- 49,976 b/s
or: 238/239 * 239/236 * OC768 +- 20 ppm
The OPU3 payload is time sliced for the 16 ODU1’s. Column 119 of the time sliced ODU3 is fixed
stuff. An all-0s pattern is inserted in the fixed stuff bytes. Thus each ODU1 has:
- 41 -
237/239 * 239/236 * OC48 +- 20 ppm = 2,498,863,728 +- 49,977 b/s

(2,498,863,728 + 49,977) - (2,498,775,126 - 49,976) = 188,555 b/s or 75.46 ppm
multiframe basis. Once again each timeslot has two positive stuff opportunities and one negative stuff
opportunity per 16 frames.
The stuffing rate is: (stuff bits/frame) * (bits/sec)/(bits/frame)
= (16/16)/(3824*4*8)*(238/236*OC768) = 328,113 b/s = 130 PPM
Therefore in the worst case, there are enough data bytes coming in to match the outgoing rate!
11.2 4 x ODU1 to ODU2 Multiplexing

11.2.1 4 x ODU1 to ODU2 Multiplexing Structure
The OPU2 is divided in a number of Tributary Slots (TS) and these Tributary Slots are interleaved
within the OPU2 (Figure 34). The bytes of an ODU1 input are mapped into one of four OPU2
Tributary Slots. The bytes of the Justification Overhead to adapt the asynchronous ODU1 to the ODU2
clock rate are mapped into the OPU2 OH area.
78
00
11
10
01
00
11
MFAS
bits Row
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
1
Column
PSI PSI PSI PSI PSI PSI 15

JOH TS 1 JOH TS 4 JOH TS 3 JOH TS 2 JOH TS 1 JOH TS 4 16
OPU2 TribSlot 1 OPU2 TribSlot 1 OPU2 TribSlot 1 OPU2 TribSlot 1 OPU2 TribSlot 1 OPU2 TribSlot 1 17
(SM, GCC0 and RES) is set to all 0’s.

OPU2 TribSlot 2 OPU2 TribSlot 2 OPU2 TribSlot 2 OPU2 TribSlot 2 OPU2 TribSlot 2 OPU2 TribSlot 2
- 42 -
not suppose to be a problem according to contributions to the ITU.

4 rows. The four OPU2 TS's are byte interleaved in the OPU2 Payload area.
OPU2 Payload
OPU2 Payload
OPU2 Payload
OPU2 Payload
OPU2 Payload
OPU2 Payload
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
Figure 34 OPU2 tributary slot allocation (Figure 19-1/G.709)

However the FAS bytes can’t be removed because there is no standard on where the ODU1 frame
starts. Thus the ODU1 FAS bytes are needed to frame the recovered ODU1 signal. The OTU1 OH
It is important to note that the ODU1 frame repeats every four ODU2 frames! One of the implications
of this is that the FAS bytes in the ODU1 frame could cause false locking of the ODU2 frame. This is
An OPU2 Tributary Slot occupies 25% of the OPU2 Payload area. It is a structure with 952 columns by
- 43 -
Column
Row 1 7 8 14 15 3824
FA Overhead Fixed Stuff
1 area (all-0's)
2
OPUj area
ODUj Overhead (4 x 3810 bytes)
3 area
Figure 35 Extended ODUj frame structure (Figure 19-10/G.709)

11.2.2 4 x ODU1 to ODU2 Justification Structure
The Justification Overhead (JOH) consisting of Justification Control (JC) and Negative Justification
Opportunity (NJO) signals of the 4 OPU2 TSs are located in the overhead area, column 16 of rows 1 to
4. The JOH is assigned to the related tributary slots on a per frame base. JOH for a tributary slot is
available once every 4 frames. A 4-frame multiframe structure is used for this assignment. This
multiframe structure is locked to bits 7 and 8 of the MFAS byte as shown in Table 15 and Figure 36.
Table 15 OPU2 Justification OH tributary slots (Table 19-1/G.709)
MFAS bits JOH TS
78
00 1
01 2
10 3
11 4
The PJO1 and PJO2 bytes are in the ODU1 payload. Figure 36 shows how the bytes are distributed.
- 44 -
Column
3821
3822
3823
3824
15
16
17
Row
JC
1
JC
2
OPUk Payload
(4 x 3808 bytes)
JC
3
NJO
PSI
4 PJO
1 2 3 4 5 6 7 8
0 JC Reserved JC
1 Reserved
2 OPU2 OPU3
MFAS MFAS
PJO1 17
18
19
20
PJO2 21
22
23
24
PJO1 17
18
19
32
PJO2 33
34
35
48
MSI bits 78 bits 5678
00 0000
17
PJO1
PJO2
PJO1
PJO2
18
01 0001
PJO1
PJO2
PJO1
PJO2
10 0010
Reserved
PJO1
PJO2
11
PJO1
PJO2
1111
255
Figure 36 OPUk Multiplex Overhead (Figure 19-6/G.709)
The thing to note is that there are two PJO bytes and only one NJO bytes. This is because the timeslot
provides more capacity than is needed.
11.2.3 OPU2 Payload Structure Identifier (PSI)
Byte 0 is defined as the Payload Type and is equal to 0x20.
Byte 1 is reserved
Bytes 2-17 are the “Multiplex Structure Identifier”
Bytes 18-255 are reserved
239 bytes are reserved in the OPUk PSI for future international standardization. These bytes are located
in PSI[1] and PSI[18] to [PSI255] of the OPUk overhead. These bytes are set to all Zeros.
11.2.4 OPU2 Multiplex Structure Identifier (MSI)
The multiplex structure identifier (MSI) overhead, which encodes the ODU multiplex structure in the
OPU, is located in the mapping specific area of the PSI signal (PSI[2]... PSI[17]). The MSI indicates
the content of each tributary slot (TS) of an OPU2. The generic coding for each TS is shown in Figure
37. One byte is used for each TS.
- Bits 1 and 2 indicate the ODU type transported in the TS.
- Bits 3 to 8 indicate the tributary port of the ODU transported. This is of interest in case of
flexible assignment of ODUs to tributary slots (e.g. ODU2 into OPU3). In case of
fixed assignment the tributary port number corresponds to the tributary slot number.
- 45 -
1 2 3 4 5 6 7 8
PSI[1+i] ODU type Tributray Port # TS #i
00: ODU1 00 0000:

Tributary Port 1
01: ODU2 00 0001:
Tributary Port 2
10: ODU3 00 0010Tributary Port 3
11: Res. 00 0011Tributary Port 4
:
00 1111: Tributary Port 16
Figure 37 Generic MSI coding (Figure 19-7/G.709)
For the 4 OPU2 tributary slots 4 bytes of the PSI are used as shown in Figure 38.
- The ODU type is fixed ODU1.
- The tributary port # indicates the port number of the ODU1 that is being transported in this TS;
the assignment of ports to tributary slots is fixed, the port number equals the tributary slot number
The remaining 12 bytes of the MSI field (PSI[6] to PSI[17]) are unused. They are set to 0 and ignored
by the receiver.
1 2 3 4 5 6 7 8
PSI[2] 00 00 0000 TS1
PSI[3] 00 00 0001 TS2
PSI[4] 00 00 0010 TS3
PSI[5] 00 00 0011 TS4
Figure 38 OPU2-MSI coding (Figure 19-8/G.709)

The mapping of ODU1 signals (with up to ±20 ppm bit-rate tolerance) into the ODU2 signal is
performed as an asynchronous mapping.
The OPU2 signal for the multiplexed ODU1 structure is created from a locally generated clock, which
is independent of the ODU1 client signals.
The ODU1 signal is extended with Frame Alignment Overhead and an all-0's pattern in the OTU1
Overhead field;
The extended ODU1 signal is adapted to the locally generated ODU2 clock by means of an
asynchronous mapping with -1/0/+1/+2 positive/negative/zero (pnz) justification scheme.
The asynchronous mapping process generates the JC, NJO, PJO1 and PJO2 according to Table 16.. The
demapping process interprets JC, NJO, PJO1 and PJO2 according to Table 16.. Majority vote (two out
of three) is used to make the justification decision in the demapping process to protect against an error
in one of the three JC signals.
- 46 -
Table 16 JC, NJO, PJO1 and PJO2 generation and interpretation (Table 19-3/G.709)
JC NJO PJO1 PJO2 Interpretation
[7,8]
00 justification byte data byte data byte no justification (0)
01 data byte data byte data byte negative justification (-1)
10 justification byte justification byte justification byte double positive justification (+2)
11 justification byte justification byte data byte positive justification (+1)
The value contained in NJO, PJO1 and PJO2 when they are used as justification bytes is all-0s. The
receiver is required to ignore the value contained in these bytes whenever they are used as justification
bytes.
Note: based on the calculations for ODU1 to OPU2 mapping (See Section 11.1.1), there should never
be a need to do a “Double Positive Justification”.
11.3 ODU1/ODU2 to ODU3 Multiplexing

11.3.1 ODU1/ODU2 to ODU3 Multiplexing Structure
The OPU3 is divided in a number of Tributary Slots (TS) and these Tributary Slots are interleaved
within the OPU3 (Figure 341). The bytes of an ODU1 or ODU2 input are mapped into one or four
OPU3 Tributary Slots. The bytes of the Justification Overhead to adapt the asynchronous ODU1 or
ODU2 to the ODU3 clock rate are mapped into the OPU3 OH area.
1 NOTE TSB: In the second line has to be read Figure 39 instead of 34 ?

0000
1111
1110
0001
0000
1111
5678
MFAS
bits Row
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
4
3
2
1
1
Column
PSI PSI PSI PSI PSI PSI 15

JOH TS 1 JOH TS 16 JOH TS 15 JOH TS 2 JOH TS 1 JOH TS 16 16
(SM, GCC0 and RES) is set to all 0’s.

- 47 -
frame. This is not suppose to be a problem according to contributions to the ITU.

by 4 rows. The sixteen OPU3 TS's are byte interleaved in the OPU3 Payload area.
Figure 39 OPU3 tributary slot allocation (Figure 19-2/G.709)
OPU3 Payload
OPU3 Payload
OPU3 Payload
OPU3 Payload
OPU3 Payload
OPU3 Payload
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
(4 x 3808 bytes)
It is important to note that the ODU1 frame repeats every sixteen ODU3 frames! One of the
3821
3822
However the FAS bytes can’t be removed because there is no standard on where the ODU1 frame
starts. Thus the ODU1 FAS bytes are needed to frame the recovered ODU1 signal. The OTU1 OH
implications of this is that the FAS bytes in the ODU1 frame could cause false locking of the ODU3
An OPU3 Tributary Slot occupies 6.25% of the OPU3 Payload area. It is a structure with 238 columns
- 48 -
Column
Row 1 7 8 14 15 3824
FA Overhead Fixed Stuff
1 area (all-0's)
2
OPUj area
ODUj Overhead (4 x 3810 bytes)
3 area
Figure 40 Extended ODUj frame structure (Figure 19-10/G.709)

11.3.2 ODU1/ODU2 to ODU3 Justification Structure
The Justification Overhead (JOH) consisting of Justification Control (JC) and Negative Justification
Opportunity (NJO) signals of the 16 OPU3 TS’s are located in the overhead area, column 16 of rows 1
to 4. The JOH is assigned to the related tributary slots on a per frame base. JOH for a tributary slot is
available once every 16 frames. A 16-frame multiframe structure is used for this assignment. This
multiframe structure is locked to bits 5-8 of the MFAS byte as shown in Table 17and Figure 362.
Table 17 OPU3 Justification OH tributary slots (Table 19-2/G.709)
MFAS bits JOH TS MFAS bits JOH TS
5678 5678
0000 1 1000 9
0001 2 1001 10
0010 3 1010 11
0011 4 1011 12
0100 5 1100 13
0101 6 1101 14
0110 7 1110 15
0111 8 1111 16
The PJO1 and PJO2 bytes are in the ODU1 payload. Figure 36 shows how the bytes are distributed.
2 NOTE TSB: Figure 36 should be read Figure 41 instead?

- 49 -
Column
3821
3822
3823
3824
15
16
17
Row
JC
1
JC
2
OPUk Payload
(4 x 3808 bytes)
JC
3
NJO
PSI
4 PJO
1 2 3 4 5 6 7 8
0 JC Reserved JC
1 Reserved
2 OPU2 OPU3
MFAS MFAS
PJO1 17
18
19
20
PJO2 21
22
23
24
PJO1 17
18
19
32
PJO2 33
34
35
48
MSI bits 78 bits 5678
00 0000
17
PJO1
PJO2
PJO1
PJO2
18
01 0001
PJO1
PJO2
PJO1
PJO2
10 0010
Reserved
PJO1
PJO2
11
PJO1
PJO2
1111
255
Figure 41 OPUk Multiplex Overhead (Figure 19-6/G.709)
The thing to note is that there are two PJO bytes and only one NJO bytes. This is because the timeslot
provides more capacity than is needed.
11.3.3 OPU3 Payload Structure Identifier (PSI)
Byte 0 is defined as the Payload Type and is equal to 0x20.
Byte 1 is reserved
Bytes 2-17 are the “Multiplex Structure Identifier”
Bytes 18-255 are reserved
239 bytes are reserved in the OPUk PSI for future international standardization. These bytes are located
in PSI[1] and PSI[18] to [PSI255] of the OPUk overhead. These bytes are set to all Zeros.
11.3.4 OPU3 Multiplex Structure Identifier (MSI)
The multiplex structure identifier (MSI) overhead, which encodes the ODU multiplex structure in the
OPU, is located in the mapping specific area of the PSI signal (PSI[2]... PSI[17]). The MSI indicates
the content of each tributary slot (TS) of an OPU3. The generic coding for each TS is shown in Figure
42. One byte is used for each TS.
- Bits 1 and 2 indicate the ODU type transported in the TS.
- Bits 3 to 8 indicate the tributary port of the ODU transported. This is of interest in case of
flexible assignment of ODUs to tributary slots (e.g. ODU2 into OPU3). In case of
fixed assignment the tributary port number corresponds to the tributary slot number.
- 50 -
1 2 3 4 5 6 7 8
PSI[1+i] ODU type Tributray Port # TS #i
00: ODU1 00 0000:

Tributary Port 1
01: ODU2 00 0001:
Tributary Port 2
10: ODU3 00 0010Tributary Port 3
11: Res. 00 0011Tributary Port 4
:
00 1111: Tributary Port 16
Figure 42 Generic MSI coding (Figure 19-7/G.709)
For the 16 OPU3 tributary slots 16 bytes of the PSI are used as shown in Figure 43.
- The ODU type can be ODU1 or ODU2.
- The tributary port # indicates the port number of the ODU1/2 that is being transported in this
TS; for the case of ODU2 a flexible assignment of tributary ports to tributary slots is possible, for the
case of ODU1 this assignment is fixed, the port number equals the slot number. ODU2 tributary ports
are numbered 1 to 4.
1 2 3 4 5 6 7 8
PSI[2] ODU type Tributray Port # TS1
Figure 43 OPU3-MSI coding (Figure 19-9/G.709)

The mapping of ODU1/ODU2 signals (with up to ±20 ppm bit-rate tolerance) into the ODU3 signal is
performed as an asynchronous mapping.
- 51 -
The OPU3 signal for the multiplexed ODU1/ODU2 structure is created from a locally generated clock,
which is independent of the ODU1/ODU2 client signals.
The ODU1/ODU2 signal is extended with Frame Alignment Overhead and an all-0's pattern in the
OTU1 Overhead field;
The extended ODU1/ODU2 signal is adapted to the locally generated ODU3 clock by means of an
asynchronous mapping with -1/0/+1/+2 positive/negative/zero (pnz) justification scheme.
The asynchronous mapping process generates the JC, NJO, PJO1 and PJO2 according to Table 18. The
demapping process interprets JC, NJO, PJO1 and PJO2 according to Table 18. Majority vote (two out
of three) is used to make the justification decision in the demapping process to protect against an error
in one of the three JC signals.
Table 18 JC, NJO, PJO1 and PJO2 generation and interpretation (Table 19-3/G.709)
JC NJO PJO1 PJO2 Interpretation
[7,8]
00 justification byte data byte data byte no justification (0)
01 data byte data byte data byte negative justification (-1)
10 justification byte justification byte justification byte double positive justification (+2)
11 justification byte justification byte data byte positive justification (+1)
The value contained in NJO, PJO1 and PJO2 when they are used as justification bytes is all-0s. The
receiver is required to ignore the value contained in these bytes whenever they are used as justification
bytes.
11.4 Maintenance Signal Insertion

11.4.1 Client source ODUk-AIS
During a signal fail condition of the incoming ODUj client signal (e.g. OTUj-LOF), this failed
incoming signal will be replaced by the ODUj-AIS signal as specified in G.709/16.5.1. This ODUj-
AIS is then mapped into the respective timeslot in the ODUk.
11.4.2 Client source ODUk-OCI
For the case the ODUj is received from the output of a fabric (ODUj connection function), the
incoming signal may contain (case of open matrix connection) the ODUj-OCI signal as specified in
G.709/16.5.2. This ODUj-OCI signal is then mapped into the respective timeslot in the ODUk.
Not all equipment will have a real connection function (i.e. switch fabric) implemented; instead the
presence/absence of tributary interface port units represents the presence/absence of a matrix
connection. If such unit is intentionally absent (i.e. not installed), the associated timeslot in the ODUk
should carry an ODUj-OCI signal. If such unit is installed but temporarily removed as part of a repair
action, the associated timeslot in the ODUk should carry an ODUj-AIS signal.
11.4.3 Line source ODUk-AIS
During signal fail condition of the incoming ODUk/OPUk signal (e.g. in the case of an ODUk-AIS,
ODUk-LCK, ODUk-OCI condition) the ODUj-AIS pattern as specified in G.709/16.5.1 is generated as
a replacement signal for the lost ODUj signal.
This signal is selected by the consequent action “aAIS”.
The clock, frame start and multiframes start are independent from the incoming clock.
NOTE: This means if the line clock is lost, an external reference or free run local clock is required to
generate the AIS signal.
- 52 -
11.5 Defect detection and correlation

There are no defects detected in the Multiplexer. There are defects detected in the Demultiplexer. A
functional model of the Demultiplexer is shown in Figure 44.
ODUj_CP[1] ODUj_CP[n] ODUi_CP[1] ODUi_CP[m]
CI_MFS
CI_MFS
CI_MFS
CI_MFS
CI_SSF
CI_SSF
CI_SSF
CI_SSF
CI_CK
CI_CK
CI_CK
CI_CK
CI_FS
CI_FS
CI_FS
CI_FS
CI_D
CI_D
CI_D
CI_D
aAIS
aSSF
dPLM dMSIM
dPLM dMSIM
dPLM dMSIM
dPLM dMSIM
Select normal/AIS Consequent
actions
Normal AIS
dLOFLOM
Generate
MFS
CK
FS
D
ODUj-AIS
(n+m) × MI_cLOFLOM
MFS FS CK AI_TSF MI_cLOFLOM

correlations
Frame &
Defect
ODUkP/ODU[i]j_A_Sk_MP
multiframe dLOFLOM
alignment detection
D CK
WR
Elastic store
generator
WR
Clock
RD
RD
Extract JC
D TS# Active D TS# Active D TS# Active D TS# Active

Demultiplexer MI_Active
Multiplex dMSIM Defect MI_cMSIM

structure dMSIM dPLM correlations MI_cPLM
MI_AutoMS
MI_ExMSI
Extract MSI MSI process MI_AcMSI
dPLM
Extract PT PT process MI_AcPT
AI_D AI_CK AI_FS AI_MFS AI_TSF

ODUkP_AP G.798AMD.1
F14-51
Figure 44 ODUkP/ODU[i]j_A_Sk processes (Figure 14-51/G.798)
11.5.1 dPLM (Payload Mismatch)

dPLM is declared if the accepted payload type (AcPT) is not equal to the expected payload type(s) as
defined by the specific adaptation function. dPLM is cleared is the accepted payload type is equal to the
expected payload type(s) as defined by the specific adaptation function.
Note - An adaptation function may support more than one payload type.
A new payload type PT (AcPT) is accepted if a new consistent value is received in the PSI[0] byte in X
consecutive multiframes. X is 3.
11.5.2 cPLM
cPLM == dPLM and (not AI_TSF)
- 53 -
AI_TSF = aTSF = CI_SSF or dAIS or dOCI or dLCK or (dTIM and not TIMActDis)
(G.798.14.2.1.2)
(dAIS, dOCI, dLCK, dTIM are all detected at the PM layer)
CI_SSF = AI_TSF (at TCM layer)
TIMActDis)) and TCMCI_Mode == OPERATIONAL) (G.798.14.5.1.2.2)
(dAIS, dLTC, dOCI, dLCK, and dTIM are TCM defects)
(dAIS here is the SM AIS)
11.5.3 dMSIM (Multiplex Structure Identifier Mismatch supervision)
dMSIM is declared if the accepted MSI (AcMSI) is not equal to the expected multiplex structure
identifier (ExMSI). dMSIM is cleared if the AcMSI is equal to the ExMSI. ExMSI is configured via the
management interface. A new multiplex structure identifier MSI (AcMSI) is accepted if a new
consistent value is received in the MSI bytes of the PSI overhead (PSI[2...5] for ODU2, PSI[2...17] for
ODU3) in X consecutive multiframes. X is 3.
11.5.4 cMSIM
cMSIM == dMSIM and (not dPLM) and (not AI_TSF)
(G.798.14.2.1.2)
TIMActDis)) and TCMCI_Mode==OPERATIONAL) (G.798.14.5.1.2.2)
11.5.5 dLOFLOM (Loss of Frame and Multiframe)
If the frame alignment process is in the out-of-frame (OOF) state for 3 ms, dLOFLOM is declared. To
provide for the case of intermittent OOFs, the integrating timer is reset to zero until an in-frame (IF)
condition persists continuously for 3 ms. dLOFLOM is cleared when the IF state persists continuously
for 3 ms.
The ODUj frame and multiframe alignment is found by searching for the framing pattern (OA1, OA2
FAS bytes) and checking the multiframe sequence (MFAS byte) contained in the ODUj frame.
In the out-of-frame state the framing pattern searched for is the full set of the OA1 and OA2 bytes. The
in-frame (IF) is entered if this set is found and confirmed one frame period later and an error-free
multiframe sequence is found in the MFAS bytes of the two frames.
In the in-frame state (IF) the frame alignment signal is continuously checked with the presumed frame
start position and the expected multiframe sequence. The framing pattern checked for is the OA1OA2
pattern (bytes 3 and 4 of the first row of the ODUj[/i] frame). The out of frame state (OOF) is entered if
this subset is not found at the correct position in 5 consecutive frames or the received MFAS does not
match with the expected multiframe number in 5 consecutive frames.
- 54 -
The frame and multiframe start are maintained during the OOF state.
There is one of these defects for each tributary.
11.5.6 cLOFLOM
cLOFLOM == dLOFLOM and (not dMSIM) and (not dPLM) and (not AI_TSF) and (Active)
(“Active” is provisioned by the management interface)
(G.798.14.2.1.2)
11.5.7 aAIS (AIS insertion)
For each ODUj:
aAIS == AI_TSF or dPLM or dMSIM or dLOFLOM or (not Active)
(“not Active” is provisioned by the management interface)
(G.798.14.2.1.2)
11.5.8 SSF (Server Signal Fail)
For each ODUj:
aSSF == AI_TSF or dPLM or dMSIM or dLOFLOM or (not Active)
(“not Active” is provisioned by the management interface)
(G.798.14.2.1.2)
- 55 -

12 ODUk Virtual Concatenation / OTN over SONET

TBD
Editors Note: Who wants to write this?
13 Synchronisation
13.1 Introduction
Basic statements on timing in OTN has been done by ITU-SG13 during its February 2000 meeting. It
has been decided that OTN must be transparent to the payload it transports within the ODUk and that
the OTN layer does not need to transport network synchronization since network synchronization can
be transported within the payload, mainly by SDH/SONET client tributaries. In order to meet these
requirements the OTN frame has been designed so that the client mapping/demapping and the transfer
through OTN network equipments and 3R regenerators, do not prevent SDH tributaries to meet the
G.825 jitter and wander requirements. Two types of mapping have been specified for the transport of
CBR payload, e.g. SDH/SONET. The first one is the asynchronous mapping, which is the most widely
used, where the payload floats within the OTN frame. In this case, there is no frequency relationship
between the payload and the OTN frame frequencies, thus simple free running oscillators can be used
to generate the OTN frame. The second is the synchronous mapping where the timing used to generate
the OTN frame is extracted from a CBR client tributary, e.g. SDH/SONET; in case of LOS of the input
client, the OTN frequency that does not transport payload is generated by a free running oscillator,
without need for an holdover mode.
This specification allows for very simple implementation of timing in OTN equipments compared to
SDH/SONET. SDH/SONET has been specified to be a network layer able to transport network
synchronization because its introduction in the network could corrupt the existing 2 Mbit/s
synchronization network with the VC12 pointer adjustments.
An OTN NE do not require synchronization interfaces, complex clocks with holdover mode nor SSM
processing. Another difference with SDH is that there is no geographical option for the timing aspects
of OTN.
OTN transports client signals into a G.709 frame, OTUk, that is transported by an OCh on one lambda
of the Optical Transport Module (OTM). Each lambda carries its G.709 frame with its own frequency,
there is no common clock for the different OTUk of the OTM.
A trail through OTN is generated in an OTN NE that maps the client into an ODUk and terminated in
another OTN NE that de-maps the client signal from the ODUk. Between the 2 OTN trail terminations,
there might be 3R regenerators, which are equipments that perform complete regeneration of the pulse
shape, clock recovery and retiming within required jitter limits (see fig27/G.872 and Annex A/G.872).
The number of 3R regenerators that can be cascaded in tandem depends on the specification of this
regenerator and on the jitter and wander generation and tolerance applicable to the OTUk interfaces; it
is stated to be at least 50 in G.8251.
ODUk multiplexing has been standardized, its implication on timing has been taken into account in the
relevant recommendations.
13.2 Network requirements

In an OTN, jitter and wander accumulate on transmission path according to the generation and transfer
characteristics of interconnected equipments, 3R regenerators, client mappers, demappers and
- 56 -
multiplexers, demultiplexers. In order to avoid the effects of excessive jitter and wander, G.8251
recommendation specifies the maximum magnitude of jitter and wander, and the minimum jitter and
wander tolerance at OTN network interfaces. These specifications have been established together with
the definition of the clocks required by all functions defined for OTN, i.e client mapping/ demapping,
ODUk multiplexing/demultiplexing and 3R regenerators.
The OTN generates and accumulates jitter and wander on its client signals due to the buffers of the
mapping into ODUk and due to the ODUk multiplexing. The limits for such accumulation are given in
G.825 for SDH signal clients. Jitter and wander is also accumulated on the OTN signals itself due to
the ODUk multiplexing and 3R jitter generation. The network limits for this are given in G.8251,
section 5.
G.8251 specifies the jitter and wander tolerance in section 6. As OTN clocks do not generate wander,
no wander limit has been defined for OTN. G.8251, and its amendment 1 for ODUk multiplexing,
specifies the different type of clocks that are required to perform the following functions (see Table
A.1/G.8251): the accuracy of these clocks depends on the definition of the G.709 frame and on the
accuracy specified for the clients.
- Asynchronous mapping of a client into an ODUk and ODUk multiplexing: this ODCa clock is
a free- running clock with a frequency accuracy of ±20ppm.
- Synchronous mapping of a client into an ODUk: this ODCb clock is locked on the client
frequency.
- 3R regeneration: this ODCr clock is locked on an OCh input frequency which must be within
±20ppm.
- Demapping a client signal from an ODUk and ODUk demultiplexing: this ODCp clock is
locked on an OCh input frequency which must be within ±20ppm.
G.8251 Annex A specifies the jitter generation of these clocks and, when applicable, noise tolerance,
jitter transfer and transient response.
Note: All these clock functions are used for clock recovery and clock filtering of a particular signal.
They never serve as an equipment synchronization source. Therefore there is no holdover mode
specified for these clocks since there is no need for an accurate clock when the input signal disappears.
This is a major difference compared to SDH.
G.8251 appendix 2 provides a provisional adaptation of the SDH synchronization reference chain to
include OTN islands. This is an amendment of the reference chain being defined in G.803. Considering
that SDH may be transported by OTN islands, the SEC will no longer be present but replaced by OTN
NEs. This leads to the definition of a reference chain where all SECs located between 2 SSUs are
replaced by an OTN island. The local part of the reference chain, after the last SSU can still support 20
SECs in tandem. Each of these islands may be composed of OTN NEs performing mapping/demapping
or multiplexing/demultiplexing operations. This adaptation of the reference chain raises a buffer size
constraint for the OTN NEs in order to keep the overall network wander performance within specified
limits. Predominantly the mapping and the demapping functions of the OTN contribute to wander
accumulation due to the buffers being involved in these functions. The size limit of these buffers is
specified in recommendation ITU-T G.798. This allows to insert up to 10 mapping/ multiplexing nodes
per OTN island. A total of 100 mapping/demapping functions can be performed on this synchronization
reference chain.
- 57 -
G.8251 appendix 3 presents an Hypothetic Reference Model for 3R regenerator jitter accumulation:
according to this model, at any OTUk interface the jitter will remain within network limits in a chain of
one mapping clock and up to 50 cascaded 3R regenerators plus a de-mapping clock. Appendix 4 reports
the results of extensive simulations showing that it is possible to have 50 OTN regenerators without
exceeding the network limits of OTUk interfaces, assuming the regenerators comply with the model
defined in this appendix. Appendix 7, published in the amendment 1, reports CBRx and ODUj[/i]
payload jitter and wander accumulation analyses.
13.3 Mapping and Multiplexing

These topics have been already presented in previous sections of this tutorial related to G.709 frame
where the justification process is specified.
Note that two different mappings of CBR client has been specified, asynchronous and bit synchronous.
The asynchronous mapping uses a -1/0/+1 justification scheme and the maximum size of the buffers
have been specified to be 2, 8 and 32 bytes respectively for the STM 16, 64 and 256 SDH clients.
These mappings have been specified so that an asynchronous demapper may extract the CBR client
signal mapped according to both techniques.
The multiplexing process is unique and based on an asynchronous multiplexing scheme.
It is important to know that the justification process has been defined so that all client signals and the
G.709 (OTN signals) may have a frequency range of up to ±20 ppm .
13.4 Equipment requirements

Detailed specifications related to atomic functions contributing to timing and jitter are defined in
G.798. An important requirement is that the demapping function must have a maximum bandwidth of
300 Hz.
14 OTN Maintenance Signals
14.1 OTUk maintenance signals

14.1.1 OTUk alarm indication signal (OTUk-AIS)
The OTUk-AIS (Figure 45) is a generic-AIS signal. Since the OTUk capacity (130 560 bits) is not an
integer multiple of the PN-11 sequence length (2047 bits), the PN-11 sequence may cross an OTUk
frame boundary.
1 14 15 3824 3825 4080

1
2
Repeating PN-11 sequence
3
4
T1543670-01
Figure 45 OTUk-AIS (Figure 16-1/G.709)

9 11
The PN-11 sequence is defined by the generating polynomial 1 + x + x as specified in 5.2/O.150.
(See Figure 46)
- 58 -
D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q Generic-AIS
Clock
T1543710-01
Figure 46 Generic-AIS generating circuit (Figure 16-5/G.709)
NOTE – OTUk-AIS is defined to support a future server layer application. OTN equipment should be
capable of detecting the presence of such a signal, but it is not required to generate such a signal.
14.2 ODUk maintenance signals

Three ODUk maintenance signals are defined: ODUk-AIS, ODUk-OCI and ODUk-LCK.
14.2.1 ODUk Alarm Indication Signal (ODUk-AIS)
ODUk-AIS is specified as all "1"s in the entire ODUk signal, excluding the frame alignment overhead
(FA OH), OTUk overhead (OTUk OH) and ODUk FTFL (Figure 47).
1 78 14 17 3824
1 FA OH OTUk OH
STAT
STAT
STAT
FTFL
2
All-1s pattern
STAT
STAT
STAT
STAT
4
T1543680-01
Figure 47 ODUk-AIS (Figure 16-2/G.709)
The presence of ODUk-AIS is detected by monitoring the ODUk STAT bits in the PM and TCMi
overhead fields.
ODUk-AIS is generated if the OTUk input signal fails (Section 13.3.1.2/G.798) or it detects ODUk-
OCI or ODUk-LCK on the input signal (Section 14.5.1.1.2/G.798)
14.2.2 ODUk Open Connection Indication (ODUk-OCI)
ODUk-OCI is specified as a repeating "0110 0110" pattern in the entire ODUk signal, excluding the
frame alignment overhead (FA OH) and OTUk overhead (OTUk OH) (Figure 48).
1 78 14 17 3824
1 FA OH OTUk OH
STAT
STAT
STAT
2
Repeating "0110 0110" pattern
STAT
STAT
STAT
STAT
4
T1543690-01
Figure 48 ODUk-OCI (Figure 16-3/G.709)
NOTE – The repeating "0110 0110" pattern is the default pattern; other patterns are also allowed as
long as the STAT bits in the PM and TCMi overhead fields are set to "110".
- 59 -
The presence of ODUk-OCI is detected by monitoring the ODUk STAT bits in the PM and TCMi
overhead fields.
The insertion of this is under management control. There is no defect that inserts ODUk-OCI.
14.2.3 ODUk Locked (ODUk-LCK)
ODUk-LCK is specified as a repeating "0101 0101" pattern in the entire ODUk signal, excluding the
Frame Alignment overhead (FA OH) and OTUk overhead (OTUk OH) (Figure 49).
1 78 14 17 3824
1 FA OH OTUk OH
STAT
STAT
STAT
2
Repeating "0101 0101" pattern
STAT
STAT
STAT
STAT
4
T1543700-01
Figure 49 ODUk-LCK (Figure 16-4/G.709)
NOTE – The repeating "0101 0101" pattern is the default pattern; other patterns are also allowed as
long as the STAT bits in the PM and TCMi overhead fields are set to "101".
The presence of ODUk-LCK is detected by monitoring the ODUk STAT bits in the PM and TCMi
overhead fields.
The insertion of this is under management control. There is no defect that inserts ODUk-LCK.
14.3 Client maintenance signal

14.3.1 Generic AIS for constant bit rate signals
The generic-AIS signal is a signal with a 2047-bit polynomial number 11 (PN-11) repeating sequence.
9 11
The PN-11 sequence is defined by the generating polynomial 1 + x + x as specified in 5.2/O.150.
(Figure 50)
D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q D Q Generic-AIS
Clock
T1543710-01
Figure 50 Generic-AIS generating circuit (Figure 16-5/G.709)
During a signal fail condition of the incoming CBR2G5, CBR10G or CBR40G client signal (e.g. in the
case of a loss of input signal), this failed incoming signal is replaced by the generic-AIS signal, and is
then mapped into the OPUk.
During signal fail condition of the incoming ODUk/OPUk signal (e.g. in the case of an ODUk-AIS,
ODUk-LCK, ODUk-OCI condition) the generic-AIS pattern as specified in 16.6.1 is generated as a
replacement signal for the lost CBR2G5, CBR10G or CBR40G signal.
- 60 -
15 OTN Defects
G.798 defines all the defects for OTN. The document is very large and complex. The following
diagrams (Figures 51 and 52) give a summary of the various defects. They are intended as a “Cheat
Sheet” to use when reading G.798
OCh_AP Layer AI_TSF-P

MI_cLOM FAS Frame
MI_FECEn OCh_AP to MI_cLOF Alignment
OTUk_CP MI_pFECcorrErr (12.3.1.3)
Fig. 12-25
RI_BDI
OTUk_CP Layer, CI_SSF RI_BIAE
MI_TIMActDis OTUk_TCP Layer MI_pN_EBC
MI_AcTI
MI_ExSAPI MI_pN_DS
MI_cTIM
MI_ExDAPI
OTUk_TCP to MI_cDEG MI_pF_EBC SM
MI_GetAcTI
OTUk_AP MI_cBDI MI_pF_DS
Monitor
MI_TIMDetMo
MI_cSSF RI_BEI (13.2.1.2)
MI_1second Fig. 13-7
MI_DEGThr
OTUk_AP Layer AI_TSF MI_pIAE
MI_pBIAE
MI_DEGM AI_TSD
OTUk_AP to (13.3.1.2)
ODUk_CP Fig. 13-16
ODUk AIS Insert
ODUk_CP Layer, CI_SSF RI_BIAE

RI_BDI
ODUk_TCP Layer CI_SSD MI_AcTI
MI_TIMActDis MI_pIAE
MI_cOCI
MI_ExSAPI MI_pBIAE
MI_cTIM
MI_ExDAPI
ODUk_TCP to MI_cDEG
MI_pN_EBC TCM
MI_GetAcTI
ODUkT_AP MI_cBDI
MI_pN_DS Monitor
MI_TIMDetMo
MI_cSSF
MI_pF_EBC (14.5.1.1.2)
MI_1second
MI_cLCK
MI_pF_DS Fig. 14-37
MI_DEGThr AI_TSF RI_BEI
MI_cLTC
MI_DEGM ODUkT_AP Layer AI_TSD
AI_AIS
MI_AdminState
TCMCI_ACTEn OTUkT_AP to TCMCI_ACTRx (14.5.1.2.2)
TCMCI_ACTTx ODUk_CP TCMCI_AcSTAT[1...6] Fig. 14-44
TCMCI_Mode
ODUk AIS Insert
TCMCI_Level
CI_SSF
ODUk_CP Layer
RI_BDI
MI_TIMActDis CI_SSD
MI_AcTI
MI_ExSAPI MI_pN_EBC
MI_cOCI
MI_ExDAPI
ODUk_CP to MI_cTIM
MI_pN_DS PM
MI_TIMDetMo
ODUkP_AP MI_cDEG
MI_pF_EBC Monitor
MI_1second
MI_cBDI
MI_pF_DS (14.2.1.2)
MI_DEGThr
MI_cSSF
RI_BEI Fig. 14-14
MI_DEGM
MI_cLCK
ODUkP_AP Layer AI_TSD
AI_TSF
CBR
ODUkP_AP to MI_cPLM Demapping
MI_Active
CBR_CP MI_AcPT (14.3.1.3)
Fig. 14-21
CBR AIS Insert CI_SSF
Figure 51 OTN Receive Defects

- 61 -
CBR_CP to CBR
MI_Active ODUkP_AP Mapping
(14.3.1.1)
ODUk_AP Layer
RI_BDI ODUkP_AP to
RI_BEI ODUk_CP PM Insertion
MI_TxTI (14.2.1.1)
ODUk_CP Layer
MI_AdminState
CPI_ACTTx ODUk_CP to
CPI_ACTEn ODUkT_AP CPI_AcSTAT[1...6] TCM/ACT Insertion
CPI_Mode CPI_ACTRx (14.5.1.2.1)
CPI_Level
ODUkT_AP Layer
RI_BDI
RI_BEI
ODUkT_AP to TCM Insertion
RI_BIAE
ODUk_CP (14.5.1.1.1)
MI_TxTI
CPI_Level
CPI_Mode
ODUk_TCP Layer
ODUk_CP Layer
ODUk_CP to (13.3.1.1)
OTUk_AP
OTUk_AP Layer AI_IAE

RI_BDI
RI_BEI
OTUk_AP to
RI_BIAE
OTUk_CP SM Insertion
MI_TxTI
(13.2.1.1)
OTUk_TCP Layer
OTUk_CP Layer
OTUk_CP to (12.3.1.1)
OCh_AP
OCh_AP Layer
Figure 52 OTN Transmit Defects
16 Acknowledgements
I (Tim Walker) would like to thank the following people whose help and documents I used freely:
Maarten Vissars, Juergen Heiles, Gilles Joncour, Ghani Abbas, Jean-Loup Ferrant, Shahrukh Merchant,
Lieven Levrau.
17 Bibliography
http://ties.itu.int/u/tsg15/sg15/wp3/q11/g709/g709-intro-v2.ppt
- 62 -
http://ties.itu.int/u/tsg15/sg15/wp3/q11/g709/oth_public_09_2002.ppt
[Sklar] “Digital Communications”, 2nd Edition, 2001, Prentice-Hall
ITU-T G.709 (01/03), Interfaces for the Optical Transport Network (OTN)
ITU-T G.798 (5/02), Characteristics of Optical Transport Network (OTN) Hierarchy Equipment
Functional Blocks
ITU-T G.872 (10/01), Architecture for the Optical Transport Network (OTN)
ITU-T G.8251 (10/01), The Control of Jitter and Wander within the Optical Transport Network
18 Open Issues
18.1 ODUk Virtual Concatenation / OTN over SONET

Needs description (volunteers?)
_____________

OTNtutorial

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OTNtutorial

Uploaded by

Copyright:

Available Formats

Optical Transport Network (OTN) Tutorial

Contact: Timothy P. Walker Tel: 1-978-247-8407

4 Where is it standardized for ..........................................................................................8

5 Why use OTN...............................................................................................................8

6 OTN Hierarchy Overview ............................................................................................18

7 OTUk, ODUk, OPUk Frame Structure.........................................................................20

8 OPUk Overhead and Processing...................................................................................21

9 ODUk Overhead and Processing ..................................................................................27

9.2.4 Backward Error Indication and Backward Incoming Alignment Error

10 OTUk Overhead and Processing...................................................................................33

11.4.1 Client source ODUk-AIS................................................................................51

12 ODUk Virtual Concatenation / OTN over SONET ......................................................55

14 OTN Maintenance Signals............................................................................................57

15 OTN Defects .................................................................................................................60

MSB Most Significant Bit

RES Reserved for future international standardization

3.1 OTN Standards

4 Where is it standardized for

Inter-Domain Inter-Domain Inter-Domain

Intra-Domain Intra-Domain Intra-Domain Intra-Domain

Figure 1 IaDI vs. IrDI

The IaDI is the interfaces within an Operator or a Vendor domain.

5 Why use OTN

5.1 Forward Error Correction (FEC)

Figure 2 FEC Block Diagram

Figure 3 Reed-Solomon Codeword

For the standard ITU recommended RS (255,239) code:

Figure 4 Eye Diagram

u1 = ON level average value

BER vs Q for R-S 255 Code (t = 8)

1.0E-06 BER out

Figure 5 BER vs. Q Factor

Figure 6 BER vs E b/N0

Figure 7 Coding Gain measured via OSNR

5.2 Tandem Connection Monitoring

Border of the OTN

Figure 8 Tandem Connection Monitoring

TCM6 TCM6 TCM6 TCM6 TCM6 TCM6 TCM6

TCMi TCM OH field not in use T1543640-01

TCMi TCM OH field in use

Figure 9 ODUk monitored connections (Figure 15-16/G.709)

TCM6 TCM6 TCM6 TCM6 TCM6

TCMi TCM OH field not in use T1543650-01

TCMi TCM OH field in use

Figure 10 Overlapping ODUk monitored connections (Figure 15-17/G.709)

5.3 Transparent Transport of Client Signals

5.4 Switching Scalability

6 OTN Hierarchy Overview

OTUkV OTUk OTUkV OTUk

OTM-n.m OTM-0.m, OTM-nr.m

Figure 11 Full OTN Hierarchy

Figure 12 shows how they are envisioned being used in a network.

OTS OTS OTS OTS OTS OTS OTS

Figure 12 OTN Network Layers

SONET/SDH CBR Signals

Figure 13 OTN Hierarchy

Table 1 OTU types and capacity (Table 7-1/G.709)

Table 2 ODU types and capacity (Table 7-2/G.709)

Table 3 OPU types and capacity (Table 7-3/G.709)

Table 4 OTUk/ODUk/OPUk frame periods (Table 7-4/G.709)

OTU/ODU/OPU type Period (Note)

7 OTUk, ODUk, OPUk Frame Structure

Column PM and TCMi (i=1..6)