Optical Transport Network (OTN) - A Comprehensive Study - MapYourTech

Share and Explore the Tech Inside You!!!
MapYourTech.com (/) Share the Tech Inside You!!!
TECH-MATS (/) POSTERS (/technology) INTERVIEW BUDDY (/interview-guide)
TECH-TALK (/contact)
Standards (https://drive.google.com/folderview?id=0BwE3NGerAe3tUG40TzZqdjgtbDA&usp=sharing)
About (/about)
Optical Transport Network (OTN):A comprehensive study

(/entries/general/optical-transport-network-otn-a-comprehensive-
study)
June 11, 2013
Optical Transport Network (OTN)
ITU-T Recommendations on the OTN Transport Plane
The following table lists all of the known ITU-T Recommendations speci cally related to the OTN Transport
Plane.
Topic Title Publ.*
De nitions G.870 De nitions and Terminology for Optical Transport Networks (OTN 2004
Framework for
G.871/Y.1301 Framework for Optical Transport Network Recommendations 10/00
Recommendations
G.872 Architecture of Optical Transport Networks 11/01

Architectural
G.872 Amend. 1 Architecture of Optical Transport Networks 12/03
Aspects
G.872 Living List
ASTN/ASON recommendations are moved to speci c ASTN/ASON

Control Plane
standards page
Structures Mapping G.709/Y.1331 Network node interface for the optical transport network
03/03
(OTN)
G.709/Y.1331 Addendum 1 12/03
G.709 Living List
G.975 Forward Error Correction 10/00
G.681 Functional characteristics of intero ce long-haul line systems using

10/96
optical ampli ers, including optical multiplexing
G.798 Characteristics of optical transport network (OTN) equipment

01/02
functional blocks
Functional G.798 Amendment 1 06/02

Characteristics
G.798 Living List
G.806 Characteristics of transport equipment - Description Methodology

10/00
and Generic Functionality
G.7710/Y.1701 Common Equipment Management Requirements 11/01
G.808.1 (G.gps) Generic protection switching - Linear trail and subnetwork

12/03
protection
Protection
Switching G.873.1 Optical Transport network (OTN) - Linear Protection 03/03
G.873.1 Errata 1 Optical Transport network (OTN) - Linear Protection 10/03
G.874 Management aspects of the optical transport network element 11/01
G.874.1 Optical Transport Network (OTN) Protocol-Neutral Management

Management 01/02
Information Model For The Network Element View
Aspects
G.875 Optical Transport Network (OTN) management information model
for the network element view
Data G.7712/Y.1703 Architecture and speci cation of data communication

03/03
Communication network
Network (DCN)
G.dcn living list
G.8201 (G.optperf) Error performance parameters and objectives for multi-

09/03
operator international paths within the Optical Transport Network (OTN)
G.optperf living list

Error Performance
M.2401 (M.24otn) Error Performance Limits and Procedures for Bringing-
Into-Service and Maintenance of multi-operator international paths and 12/03
sections within Optical Transport Networks
Jitter & Wander G.8251(G.otnjit) The control of jitter and wander within the optical
11/01
Performance transport network (OTN)
G.8251 Amendment 1 The control of jitter and wander within the optical
06/02
transport network (OTN)
G.8251 Corrigendum 1 The control of jitter and wander within the optical
06/02
transport network (OTN)
G.664 General Automatic Power Shut-Down Procedures for Optical

06/99
Transport Systems
G.691 Optical Interfaces for single-channel SDH systems with Optical

10/00
Ampli ers, and STM-64 and STM-256 systems
G.692 Optical Interfaces for Multichannel Systems with Optical Ampli ers 10/98
G.693 Optical interfaces for intra-o ce systems 11/01
G.694.1 Spectral grids for WDM applications: DWDM frequency grid 06/02

Physical-Layer
Aspects G.694.2 Spectral grids for WDM applications: CWDM wavelength grid 06/02
G.695 Optical interfaces for Coarse Wavelength Division Multiplexing

2003
applications
G.696.1(G.IaDI) Intra-Domain DWDM applications 2004
G.697(G.optmon) Optical monitoring for DWDM system 2004
G.959.1 Optical Transport Networking Physical Layer Interfaces 02/01
Sup.39 (Sup.dsn) Optical System Design and Engineering Considerations 2003
G.651 Characteristics of a 50/125 um multipmode graded index optical

02/98
bre cable
G.652 Characteristics of a single-mode optical bre cable 03/03
Fibres G.653 Characteristics of a dispersion-shifted single mode optical bre cable 12/03
G.654 Characteristics of a cut-o shifted single-mode bre cable 06/02
G.655 Characteristics of a non-zero dispersion shifted single-mode optical

03/03
bre cable
Components & Sub- G.661 De nition and test methods for the relevant generic parameters of
10/98
systems optical ampli er devices and subsystems
G.662 Generic characteristics of optical bre ampli er devices and

10/98
subsystems
G.663 Application related aspects of optical bre ampli er devices and sub-

04/00
systems
G.671 Transmission characteristics of passive optical components 06/02

COMPARISON OF SDH AND OTN
(http://4.bp.blogspot.com/-sYzEE3gTmLw/UbYZNYM2ZSI/AAAAAAAAAts/9UFQO3EUItc/s1600/s19.JPG)
(http://3.bp.blogspot.com/-vSpOSMFWDCw/UbYZE9UGmrI/AAAAAAAAAtk/nXc6bqnKhOM/s1600/s20.JPG)
1 Abbreviations
( le:///D:/Documents%20and%20Settings/syada004/Desktop/pub/OTN%20tutorial.docx#_Toc285545018)
2 What is OTN/OTH
2.1 References
3 Optical transport network interface structure
3.1 Basic signal structure
3.1.1 OCh substructure
3.1.2 Full functionality OTM-n.m (n ≥ 1) structure
3.1.3 Reduced functionality OTM-nr.m and OTM-0.m structure
3.2 Information structure for the OTN interfaces
4 Multiplexing/mapping principles and bit rates
4.1 Mapping
4.2 Wavelength division multiplex
4.3 Bit rates and capacity
4.4 ODUk Time-Division Multiplex
5 OTUk, ODUk, OPUk Frame Structure
5.1 OPUk Overhead and Processing
5.1.1 Payload Structure Identi er (PSI)
5.1.2 Payload Type (PT)
5.2 ODUk Overhead and Processing
5.2.1 Path Monitoring (PM)
5.2.2 Tandem Connection Monitoring (TCM)
5.2.3 General Communication Channels (GCC1, GCC2)
5.2.4 Automatic Protection Switching and Protection Communication Channel (APS/PCC)
5.2.5 Fault Type and Fault Location reporting communication channel (FTFL)
5.3 OTUk Overhead and Processing
5.3.1 Scrambling
5.3.2 Frame Alignment Overhead
5.3.3 Section Monitoring (SM)
5.3.4 General Communication Channel 0 (GCC0)
6 OTN Maintenance Signals
6.1 OTUk maintenance signals
6.1.1 OTUk alarm indication signal (OTUk-AIS)
6.2 ODUk maintenance signals
6.2.1 ODUk Open Connection Indication (ODUk-OCI)
6.2.2 ODUk Locked (ODUk-LCK)
6.2.3 ODUk Alarm Indication Signal (ODUk-AIS)
6.3 Client maintenance signal
6.3.1 Generic AIS for constant bit rate signals
6.3.2 Client source ODUk-AIS
6.3.3 Client source ODUk-OCI
7 Defect detection
7.1 Default PLM (Payload Mismatch)
7.2 Default MSIM (Multiplex Structure Identi er Mismatch supervision)
7.3 Default LOFLOM (Loss of Frame and Multi-frame)
8 Synchronization
8.1 Introduction
8.2 Network requirements
9 Why use OTN
9.1 Forward Error Correction (FEC)
9.2 Tandem Connection Monitoring
9.3 Transparent Transport of Client Signals
9.4 Switching Scalability
1 Abbreviations ()
This document uses the following abbreviations:

0xYY YY is a value in hexadecimal presentation
3R Re-ampli cation, 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 Identi er
EXP Experimental
ExTI Expected Trace Identi er
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 Justi cation Overhead
LSB Least Signi cant Bit
MFAS Multi-Frame Alignment Signal
MFI Multi-frame Indicator
MS Maintenance Signal
MSB Most Signi cant Bit
MSI Multiplex Structure Identi er
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
OUT 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 Identi er
PT Payload Type
RES Reserved for future international standardization
RS Reed-Solomon
SAPI Source Access Point Identi er
Sk Sink
SM Section Monitoring
SMOH Section Monitoring OverHead
So Source
TC Tandem Connection
TCM Tandem Connection Monitoring
TS Tributary Slot
TxTI Transmitted Trace Identi er
UNI User-to-Network Interface
VCG Virtual Concatenation Group
VCOH Virtual Concatenation Overhead
vcPT virtual concatenated Payload Type
2 What is OTN/OTH ()
The Optical Transport Hierarchy (OTH) is a new transport technology for the OTN developed by the ITU. It is
based on the network architecture de ned in ITU G.872 “Architecture for the Optical Transport Network (OTN)”.
G.872 de nes 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 is needed to make OTN work.
However, it may be interesting to note the decision made during G.872 development:
“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. 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 de ned and
implemented, they will be included in this document.
2.1 REFERENCES ()
ITU-T Rec. G.709 (2009) “Interfaces for the Optical Transport Network (OTN)”
ITU-T Rec. G.798 (2010) “Characteristics of optical transport network hierarchy equipment functional
blocks”
ITU-T Rec. G.872 (2001) “Architecture of optical transport networks”
ITU-T Rec. G.873.1 (2006) “Optical Transport Network: Linear protection”
ITU-T Rec. G.874 (2010) “Management aspects of the optical transport network element”
ITU-T Rec. G.874.1 (2002) “Optical transport network: Protocol-neutral management information model for
the network element view”
ITU-T Rec. G.959.1 (2009) “Optical transport network physical layer interfaces”
ITU-T Rec. G.8251 (2011) “The control of jitter and wander within the optical transport network (OTN)”
3 Optical transport network interface structure ()
3.1 BASIC SIGNAL STRUCTURE ()
Figure 1 Structure of the OTN interfaces
(http://3.bp.blogspot.com/-RzhlRGvxFqw/UbYKq8jFpBI/AAAAAAAAAqY/zwqEWE-tmE8/s1600/1.JPG)
3.1.1 OCh substructure ()
The optical channel layer is further structured in layer networks in order to support the network management
and supervision functionalities:
· The optical channel with full (OCh) or reduced functionality (OChr), which provides transparent network
connections between 3R regeneration points in the OTN.
· The optical channel transport unit (OTUk/OTUkV) which provides supervision and conditions the signal for
transport between 3R regeneration points in the OTN.
· The optical channel data unit (ODUk) which provides:

· tandem connection monitoring (ODUkT)
· end-to-end path supervision (ODUkP)
· adaptation of client signals via the optical channel payload unit (OPUk)
· adaptation of OTN ODUk signals via the optical channel payload unit (OPUk)
3.1.2 Full functionality OTM-n.m (n ≥ 1) structure ()
The OTM-n.m (n ≥ 1) consists of the following layers:

· optical transmission section (OTSn)
· optical multiplex section (OMSn)
· optical channel (OCh)
· optical channel transport unit (OTUk/OTUkV)
· one or more optical channel data unit (ODUk)
3.1.3 Reduced functionality OTM-nr.m and OTM-0.m structure ()
The OTM-nr.m and OTM-0.m consist of the following layers:

· optical physical section (OPSn)
· reduced functionality optical channel (OChr)
· optical channel transport unit (OTUk/OTUkV)
· one or more optical channel data unit (ODUk)
3.2 INFORMATION STRUCTURE FOR THE OTN INTERFACES ()

(http://1.bp.blogspot.com/-uKkwEtNsQhg/UbYK4_AQoeI/AAAAAAAAAqg/jIR4BXcIQHc/s1600/2.JPG)
()
Figure 2 Principal information containment relationships
The following layers are de ned in OTN:

· OPUk: Optical channel payload unit k (k = 0, 1, 2, 3, 4)
· ODUk: Optical channel data unit k (k = 0, 1, 2, 3, 4)
· OTUk: Optical channel transport unit k (k = 1, 2, 3, 4)
· OCh: Optical channel, a single wavelength
· OMSn: Optical multiplex section of order n (Capacities for n = 0 and n = 16 are de ned)
· OTSn: Optical transmission section of order n (Capacities for n = 0 and n = 16 are de ned)
· OTM-n.m: Optical transport module of rate m with n optical channels. Possible values for m are:
1: 2.5 Gb/s
2: 10 Gb/s
3: 40 Gb/s
4: 100 Gb/s
Figure 3 shows how they are being used in a network.
(http://1.bp.blogspot.com/-kEEZ3eY-CyU/UbYK9rXzaUI/AAAAAAAAAqo/s9OVSQOgS-g/s1600/3.JPG)
()Figure ()3 OTN Network Layers ()
However for all intents and purposes there are only 4 layers
(http://3.bp.blogspot.com/-3WRllQ81wZg/UbYLJjnkdvI/AAAAAAAAAq0/Lmu6sJnpLg0/s1600/4.JPG)
Figure 4 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.
4 Multiplexing/mapping principles and bit rates ()
Figure 5 shows the relationship between various information structure elements and illustrates the multiplexing
structure and mappings (including wavelength and time division multiplexing) for the OTM-n.
(http://3.bp.blogspot.com/-LnrS5o5_6tc/UbYLQOIyteI/AAAAAAAAAq8/Ha1-u9QgTkI/s1600/5.JPG)
Figure ()5 OTM multiplexing and mapping structure
The OTS, OMS, OCh and COMMS overhead is inserted into the OOS.
4.1 MAPPING ()
The OPUk encapsulates the Client signal (e.g. SDH) and does any rate justi cation that is needed. It is analogous
to the path layer in SDH in that it is mapped at the source, de-mapped at the sink, and not modi ed by the
network.
The OPUk is mapped into an ODUk. The ODUk performs similar functions as the path overhead in SDH.
The ODUk is mapped into an OTUk[V]. The OTUk[V] contains the FEC and performs similar functions as the
section overhead in SDH.
After the FEC are added, the signal is then sent to a serializer/ deserializer to be converted to the optical domain.
The OTUk[V] is mapped into an OCh[r] and the OCh[r] is then modulated onto an OCC[r].
4.2 WAVELENGTH DIVISION MULTIPLEX ()
Up to n (n ≥ 1) OCC[r] are multiplexed into an OCG-n[r].m using wavelength division multiplexing. The OCC[r]
tributary slots of the OCG-n[r].m can be of di erent size.
The OCG-n[r].m is transported via the OTM-n[r].m. For the case of the full functionality OTM-n.m interfaces the
OSC is multiplexed into the OTM-n.m using wavelength division multiplexing.
4.3 BIT RATES AND CAPACITY ()
The data rates were constructed so that they could transfer SDH and Ethernet signals e ciently. The bit rates are
shown in the following tables:
(http://2.bp.blogspot.com/-uvvTEdqN94I/UbYba8et6dI/AAAAAAAAAvQ/9F25hK3p9Kg/s1600/23333.JPG)
Table 1 OTU types and capacity
(http://3.bp.blogspot.com/-v32zuqhAV08/UbYbf1uP0_I/AAAAAAAAAvY/S4jOCgUMrKg/s1600/2222222.JPG)
Table 2 ODU types and capacity

(http://1.bp.blogspot.com/-hewLc1VAFBw/UbYbkOunVqI/AAAAAAAAAvg/hps8vNl2oq4/s1600/2434534.JPG)
Table 3 OPU types and capacity
4.4 ODUK TIME-DIVISION MULTIPLEX ()
Figure 6 and Figure 7 show the relationship between various information structure elements and illustrate the
multiplexing structure and mappings (including wavelength and time division multiplexing) for the OTM-n. In the
multi-domain OTN any combination of the ODUk multiplexing layers may be present at a given OTN interface.
Figure 6 shows that a (non-OTN) client signal is mapped into a lower order OPU, identi ed as "OPU (L)". The OPU
(L) signal is mapped into the associated lower order ODU, identi ed as "ODU (L)". The ODU (L) signal is either
mapped into the associated OTU[V] signal, or into an ODTU. The ODTU signal is multiplexed into an ODTU Group
(ODTUG). The ODTUG signal is mapped into a higher order OPU, identi ed as "OPU (H)". The OPU (H) signal is
mapped into the associated higher order ODU, identi ed as "ODU (H)". The ODU (H) signal is mapped into the
associated OTU[V].
The OPU (L) and OPU (H) are the same information structures, but with di erent client signals. The concepts of
lower order and high order ODU are speci c to the role that ODU plays within a single domain.
(http://4.bp.blogspot.com/-
TbsEMz8qKF8/UbYLdglPQtI/AAAAAAAAArE/E8d4AUDnX8I/s1600/6.JPG)
Figure 7 shows that an OTU[V] signal is mapped either into an optical channel signal, identi ed as OCh and OChr,
or into an OTLk.n. The OCh/OChr signal is mapped into an optical channel carrier, identi ed as OCC and OCCr.
The OCC/OCCr signal is multiplexed into an OCC group, identi ed as OCG-n.m and OCG-nr.m. The OCG-n.m
signal is mapped into an OMSn. The OMSn signal is mapped into an OTSn. The OTSn signal is presented at the
OTM-n.m interface.
The OCGnr.m signal is mapped into an OPSn. The OPSn signal is presented at the OTM-nr.m interface.
A single OCCr signal is mapped into an OPS0. The OPS0 signal is presented at the OTM-0.m interface. The OTLk.n
signal is mapped into an optical transport lane carrier, identi ed as OTLC. The OTLC signal is multiplexed into an
OTLC group, identi ed as OTLCG. The OTLCG signal is mapped into an OPSMnk. The OPSMnk signal is presented
at the OTM-0.mvn interface.
(http://4.bp.blogspot.com/-PYTUfrGaCQg/UbYLoFtpqBI/AAAAAAAAArM/UDeQyIinKow/s1600/7.JPG)
5 OTUk, ODUk, OPUk Frame Structure ()
Figure 8 shows the overall frame format for an OTUk signal. The various elds will be explained in the following
sub-sections.
(http://3.bp.blogspot.com/-ZfgRIRNZmMw/UbYLtmgBpOI/AAAAAAAAArU/CAGMKPd17Lw/s1600/8.JPG)
Figure ()8 OTN frame format
5.1 OPUK OVERHEAD AND PROCESSING ()
The OPUk (k = 1,2,3) frame structure is organized in an octet-based block frame structure with 4 rows and 3810
columns.
(http://2.bp.blogspot.com/-UTo3yUajsu0/UbYLx3ktC8I/AAAAAAAAArc/JXC1QY_H8Zc/s1600/9.JPG)
Figure 9 OPUk frame structure

The two main areas of the OPUk frame are:
· OPUk overhead area
· OPUk payload area
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.
(http://2.bp.blogspot.com/-n1WW_wHGydU/UbYL2s48S6I/AAAAAAAAArk/ICBqDhYUQ8s/s1600/10.JPG)
Figure 10 OPUk frame
5.1.1 Payload Structure Identi er (PSI) ()
The 256-byte PSI signal is aligned with the ODUk multi-frame (i.e. PSI[0] is present at ODUk multi-frame 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 speci c.
5.1.2 Payload Type (PT) ()
A one-byte payload type signal is de ned in the PSI[0] byte of the payload structure identi er to indicate the
composition of the OPUk signal.
5.2 ODUK OVERHEAD AND PROCESSING ()
The ODUk (k = 1,2,3) frame structure is organized in an octet-based block frame structure with 4 rows and 3824
columns.
(http://2.bp.blogspot.com/-5AknjBp0OuE/UbYL6-CoRqI/AAAAAAAAArs/oMAf3vDBUGU/s1600/11.JPG)
Figure 11 ODUk frame structure
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 speci c 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 6 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.
(http://3.bp.blogspot.com/-Ma5o_7luwWc/UbYL-_AfRcI/AAAAAAAAAr0/fxLOaY8wqj0/s1600/12.JPG)
Figure 12 ODUk overhead
5.2.1 Path Monitoring (PM) ()
(http://3.bp.blogspot.com/-9RJy6lLaKFM/UbYMTbNVShI/AAAAAAAAAsE/AkzNtSUtdZ8/s1600/14.JPG)
Figure 13 ODUk path monitoring overhead

5.2.1.1 Trail Trace Identi er (TTI)
The TTI is a 64-Byte signal that occupies one byte of the frame and is aligned with the OTUk multi-frame. It is
transmitted 4 times per multi-frame.
5.2.1.2 BIP-8
This byte provides a bit interleaved parity-8 (BIP-8) code.
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.
5.2.1.3 Backward Defect Indication (BDI)
This is de ned to convey the “Signal Fail” status detected at the path terminating sink function, to the upstream
node.
5.2.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 4 bits can only result from
some unrelated condition and are interpreted as 0 errors.
5.2.1.5 Path Monitoring Status (STAT)
They indicate the presence of a maintenance signal.
5.2.2 Tandem Connection Monitoring (TCM) ()
There are 6 TCM’s. They can be nested or overlapping.

(http://3.bp.blogspot.com/-u6YFXIv4Ans/UbYXrgVHT5I/AAAAAAAAAsc/8ViuaD0RLYE/s1600/21.JPG)
Figure 14 ODUk tandem connection monitoring #i overhead
transmitted four times per multi-frame.
5.2.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.
The BIP-8 is only overwritten at the start of a Tandem Connection. Any existing TCM is not overwritten.
This is de ned to convey the “Signal Fail” status detected at the path terminating sink function, to the upstream
node.
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.
During an IAE condition the code "1011" is inserted into the BEI/BIAE eld and the error count is ignored.
Otherwise the error count (0-8) is inserted into the BEI/BIAE eld. The remaining 6 possible values represented by
these 4 bits can only result from some unrelated condition and are interpreted as 0 errors and BIAE not active.
5.2.2.5 TCM Monitoring Status (STAT)
For each tandem connection monitoring eld three bits are de ned 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).
5.2.2.6 Tandem Connection Monitoring ACTivation/deactivation (TCM-ACT)
Its de nition is for further study.
5.2.3 General Communication Channels (GCC1, GCC2) ()
Two elds of two bytes are allocated in the ODUk overhead to support two general communications channels
between any two network elements with access to the ODUk frame structure (i.e., at 3R regeneration points).
These are clear channels. The bytes for GCC1 are located in row 4, columns 1 and 2, and the bytes for GCC2 are
located in row 4, columns 3 and 4 of the ODUk overhead.
5.2.4 Automatic Protection Switching and Protection Communication Channel (APS/PCC) ()
Up to 8 levels of nested APS/PCC signals may be present in this eld. The APS/PCC bytes in a given frame are
assigned to a dedicated level depending on the value of MFAS as follows:
MFAS bit 678 APS/PCC channel Protection scheme using the

applies to connection APS/PCC channel
level
000 ODUk Path ODUk SNC/N
001 ODUk TCM1 ODUk SNC/S, ODUk SNC/N
111 OTUk Section ODUk SNC/I
Table 4 Multi-frame to allow separate APS/PCC for each monitoring level
For linear protection schemes, the bit assignments for these bytes and the bit-oriented protocol are given in ITU-T
Recommendation G.873.1. Bit assignment and byte oriented protocol for ring protection schemes are for further
study.
5.2.5 Fault Type and Fault Location reporting communication channel (FTFL) ()
One byte is allocated in the ODUk overhead to transport a 256-byte fault type and fault location (FTFL) message.
The byte is located in row 2, column 14 of the ODUk overhead.
5.3 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 overhead bytes in row 1,
columns 8 to 14 of the ODUk overhead are used for OTUk speci c overhead, resulting in an octet-based block
frame structure with 4 rows and 4080 columns.
The OTUk forward error correction (FEC) contains the Reed-Solomon RS(255,239) FEC codes. If no FEC is used,
xed stu bytes (all-0s pattern) are inserted.
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.
(http://1.bp.blogspot.com/-Rf-bd-VbhGk/UbYX6ckV61I/AAAAAAAAAsk/_OnHpWGsV-g/s1600/15.JPG)
Figure 15 OTUk Overhead

(http://3.bp.blogspot.com/-vuHdNbgAork/UbYX_Dw2iiI/AAAAAAAAAss/_MI38ef5RUM/s1600/16.JPG)
Figure 16 OTUk overhead
5.3.1 Scrambling ()
The OTUk signal needs su cient 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.
The generating polynomial is 1 + x + x3+ x12 + x16.
The scrambler is reset to "FFFF" (HEX) on the most signi cant 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 scrambled are added modulo 2
to the output from the x16 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.
5.3.2 Frame Alignment Overhead ()
5.3.2.1 Frame Alignment Signal (FAS)
A 6 byte OTUk-FAS signal is de ned in row 1, columns 1 to 6 of the OTUk overhead.

OA1 is "1111 0110". OA2 is "0010 1000".
(http://1.bp.blogspot.com/-meRLdAvYyGA/UbYYFLARYXI/AAAAAAAAAs0/QqdhLGZgCO8/s1600/17.JPG)
Figure 17 Frame alignment signal overhead structure

5.3.2.2 Multi-Frame Alignment Signal (MFAS)
Some of the OTUk and ODUk overhead signals span multiple OTUk/ODUk frames. A single multi-frame alignment
signal (MFAS) byte is de ned in row 1, column 7 of the OTUk/ODUk overhead The value of the MFAS byte will be
incremented each OTUk/ODUk frame and provides as such a 256 frame multi-frame.
Individual OTUk/ODUk overhead signals use this central multi-frame to lock their 2-frame, 4-frame, 8-frame, 16-
frame, 32-frame, etc. multi-frames to the principal frame.
5.3.3 Section Monitoring (SM) ()
(http://4.bp.blogspot.com/-HKZoZQK7 E/UbYMC2MpDNI/AAAAAAAAAsA/m5lpAh0yjnc/s1600/13.JPG)
Figure 18 OTUk section monitoring overhead
transmitted four times per multi-frame.
5.3.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.
Note: The OPUk includes the Justi cation Bytes, thus an OTN signal can not be retimed without de-mapping back
to the client signal.
This is de ned to convey the “Signal Fail” Status detected at the Section Terminating Sink Function, to the
upstream node.
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 eld and the error count is ignored.
Otherwise the error count (0-8) is inserted into the BEI/BIAE eld. The remaining six possible values represented
by these four bits can only result from some unrelated condition and are interpreted as 0 errors and BIAE not
active.
5.3.3.5 Incoming Alignment Error (IAE)
A single-bit incoming alignment error (IAE) signal is de ned 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.
5.3.4 General Communication Channel 0 (GCC0) ()
Two bytes are allocated in the OTUk overhead to support a general communications channel between OTUk
termination points. This is a clear channel. These bytes are located in row 1, columns 11 and 12 of the OTUk
overhead.
6 OTN Maintenance Signals ()

6.1 OTUK MAINTENANCE SIGNALS ()
6.1.1 OTUk alarm indication signal (OTUk-AIS) ()
The OTUk-AIS 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.
The PN-11 sequence is de ned by the generating polynomial 1 + x9 + x11.
6.2 ODUK MAINTENANCE SIGNALS ()
Three ODUk maintenance signals are de ned: ODUk-OCI, ODUk-LCK and ODUk-AIS.
6.2.1 ODUk Open Connection Indication (ODUk-OCI) ()
ODUk-OCI is speci ed as a repeating "0110 0110" pattern in the entire ODUk signal, excluding the frame
alignment overhead (FA OH) and OTUk overhead (OTUk OH).
The presence of ODUk-OCI is detected by monitoring the ODUk STAT bits in the PM and TCMi overhead elds.
The insertion of this is under management control. There is no defect that inserts ODUk-OCI.
6.2.2 ODUk Locked (ODUk-LCK) ()
ODUk-LCK is speci ed as a repeating "0101 0101" pattern in the entire ODUk signal, excluding the Frame
Alignment overhead (FA OH) and OTUk overhead (OTUk OH).
The presence of ODUk-LCK is detected by monitoring the ODUk STAT bits in the PM and TCMi overhead elds.
The insertion of this is under management control. There is no defect that inserts ODUk-LCK.
6.2.3 ODUk Alarm Indication Signal (ODUk-AIS) ()
ODUk-AIS is speci ed as all "1"s in the entire ODUk signal, excluding the frame alignment overhead (FA OH), OTUk
overhead (OTUk OH) and ODUk FTFL.
The presence of ODUk-AIS is detected by monitoring the ODUk STAT bits in the PM and TCMi overhead elds.
ODUk-AIS is generated if the OTUk input signal fails or it detects ODUk-OCI or ODUk-LCK on the input signal.
6.3 CLIENT MAINTENANCE SIGNAL ()
6.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.
The PN-11 sequence is de ned by the generating polynomial 1 + x9 + x11.
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 is generated as a replacement signal for the lost CBR2G5, CBR10G or
CBR40G signal.Maintenance Signal Insertion
6.3.2 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. This ODUj-AIS is then mapped into the respective timeslot in the ODUk.
6.3.3 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 This ODUj-OCI signal is then mapped into the
respective timeslot in the ODUk.
Not all equipment will have a real connection function (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 or not installed, the associated timeslot in the ODUk shall 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
shall carry an ODUj-AIS signal.
7 Defect detection ()
There are no defects detected in the multiplexer. There are defects detected in the de-multiplexer.
7.1 DEFAULT PLM (PAYLOAD MISMATCH) ()
Default PLM is declared if the accepted payload type (AcPT) is not equal to the expected payload type(s) as
de ned by the speci c adaptation function. Default PLM is cleared if the accepted payload type is equal to the
expected payload type(s).
A new payload type PT (AcPT) is accepted if a new consistent value is received in the PSI[0] byte in 3 consecutive
multi-frames.
7.2 DEFAULT MSIM (MULTIPLEX STRUCTURE IDENTIFIER MISMATCH SUPERVISION) ()
Default MSIM is declared if the accepted MSI (AcMSI) is not equal to the expected multiplex structure identi er
(ExMSI). dMSIM is cleared if the AcMSI is equal to the ExMSI. ExMSI is con gured via the management interface. A
new multiplex structure identi er 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 3 consecutive multi-frames.
7.3 DEFAULT LOFLOM (LOSS OF FRAME AND MULTI-FRAME) ()
If the frame alignment process is in the out-of-frame (OOF) state for 3 ms, default LOFLOM is declared. To
prevent from the case of intermittent OOFs, the integrating timer is reset to 0 until an in-frame (IF) condition
persists continuously for 3 ms. Default LOFLOM is cleared when the IF state persists continuously for 3 ms.
The ODUj frame and multi-frame alignment is found by searching for the framing pattern (OA1, OA2 FAS bytes)
and checking the multi-frame 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 con rmed one frame period later and an error-free multi-frame 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 multi-frame sequence. The framing pattern checked for is the OA1OA2 pattern (bytes 3
and 4 of the rst 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 multi-frame
number in 5 consecutive frames.
The frame and multi-frame start are maintained during the OOF state.
There is one of these defects for each tributary.
8 Synchronization ()
8.1 INTRODUCTION ()
OTN is transparent to the payload it transports within the ODUk. The OTN layer does not need to transport
network synchronization since network synchronization can be transported within the payload, mainly by SDH
client tributaries.
Two types of mapping have been speci ed for the transport of CBR payload, e.g. SDH.
The rst one is the asynchronous mapping, which is the most widely used, where the payload oats 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. 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 a holdover mode.
This speci cation allows for very simple implementation of timing in OTN equipments compared to SDH.
An OTN NE does not require synchronization interfaces, complex clocks with holdover mode nor SSM processing.
Another di erence 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 di erent 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.
The number of 3R regenerators that can be cascaded in tandem depends on the speci cation 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.
ODUk multiplexing has been standardized; its implication on timing has been taken into account in the relevant
recommendations.
8.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, de-mappers and multiplexers, de-
multiplexers. In order to avoid the e ects of excessive jitter and wander, the ITU-T Recommendation G.8251
recommendation speci es the maximum magnitude of jitter and wander, and the minimum jitter and wanders
tolerance, at OTN network interfaces.
The OTN generates and accumulates jitter and wander on its client signals due to the bu ers of the mapping into
ODUk and due to the ODUk multiplexing. The limits for such accumulation are given in the ITU-T
Recommendation 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 the ITU-T Recommendation G.8251.
The ITU-T Recommendation G.8251 speci es the jitter and wander tolerance. As OTN clocks do not generate
wander, no wander limit has been de ned for OTN.
The ITU-T Recommendation G.8251 speci es the di erent type of clocks that are required to perform the
following functions: the accuracy of these clocks depends on the de nition of the G.709 frame and on the
accuracy speci ed 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 ± 20 ppm.
· 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 ± 20 ppm.
· De-mapping a client signal from an ODUk and ODUk de-multiplexing: this ODCp clock is locked on an OCh
input frequency which must be within ± 20 ppm.
The ITU-T Recommendation G.8251 speci es the jitter generation of these clocks and, when applicable, noise
tolerance, jitter transfer and transient response.
All these clock functions are used for clock recovery and clock ltering of a particular signal. They never serve as
an equipment synchronization source. Therefore there is no holdover mode speci ed for these clocks since there
is no need for an accurate clock when the input signal disappears.
The ITU-T Recommendation G.8251 provides a provisional adaptation of the SDH synchronization reference chain
to include OTN islands. This is an amendment of the reference chain being de ned in the ITU-T Recommendation
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 de nition 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/de-mapping or multiplexing/de-
multiplexing operations. This adaptation of the reference chain raises a bu er size constraint for the OTN NEs in
order to keep the overall network wander performance within speci ed limits. Predominantly the mapping and
the de-mapping functions of the OTN contribute to wander accumulation due to the bu ers being involved in
these functions. The size limit of these bu ers is speci ed in the ITU-T Recommendation G.798. This allows
inserting up to 10 mapping/ multiplexing nodes per OTN island. A total of 100 mapping/de-mapping functions
can be performed on this synchronization reference chain.
The ITU-T Recommendation G.8251 presents a 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. It 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 de ned in this Recommendation.
9 Why use OTN ()
OTN o ers the following advantages relative to SDH:

· Stronger Forward Error Correction (FEC)
· 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
9.1 FORWARD ERROR CORRECTION (FEC) ()
Forward error correction is a major feature of the OTN.
Already SDH has a FEC de ned. It uses unde ned SOH bytes to transport the FEC check information and is
therefore called an in-band FEC. It allows only a limited number of FEC check information, which limits the
performance of the FEC.
For the OTN a Reed-Solomon 16 byte-interleaved FEC scheme is de ned, which uses 4 x 256 bytes of check
information per ODU frame.
(http://3.bp.blogspot.com/-bUwBC98x7oQ/UbYYSL0Ub7I/AAAAAAAAAs8/TJjH5IeFkf4/s1600/19.JPG)
Figure 19 Error correction in OTN
According to ITU-T Recommendation G.709, an Reed-Solomon (255, 239) code with a symbol size of 8 is used for
FEC. 239 input bytes are encoded in 255 output bytes. This code enables the detection of 2t = (n – k) = 16 errors in
a codeword and the correction of t = (n – k)/2 = 8 of them.
FEC has been proven to be e ective in OSNR limited systems as well as in dispersion limited systems. As for non-
linear e ects, reducing the output power leads to OSNR limitations, against which FEC is useful. FEC is less
e ective against PMD, however.
G.709 de nes 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 a 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
ampli ers by decreasing the power per channel and increasing the number of channels. (Note that changes in
non-linear e ects 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 gures, and lter
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 introduce signi cant 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 an optical path can cross more
transparent optical network elements.
This allows evolving from today’s point-to-point links to transparent, meshed optical networks with su cient
functionality.
9.2 TANDEM CONNECTION MONITORING ()
SDH monitoring is divided into section and path monitoring. A problem arises when you have “Carrier’s Carrier”
situation where it is required to monitor a segment of the path that passes another carrier network.
(http://1.bp.blogspot.com/-AcSDnvhnCPM/UbYYf9WJkNI/AAAAAAAAAtE/LlYbv24O2V8/s1600/20.JPG)
Figure ()20 Tandem Connection Monitoring
Here Operator A needs to have Operator B carries 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. SDH was modi ed to allow a single Tandem connection. G.709 allows 6.
TCM1 is used by the User to monitor the Quality of Service (QoS) that they see. TCM2 is used by the rst 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 con ict.
TCM’s also support monitoring of ODUk (G.709 w/o 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);
· sub-layer monitoring for linear 1+1, 1:1 and 1:n optical channel sub-network connection protection
switching, to determine the signal fail and signal degrade conditions;
· sub-layer monitoring for optical channel shared protection ring (SPRING) protection switching, to determine
the signal fail and signal degrade conditions;
· 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 veri cation of delivered
quality of service.
A TCM eld is assigned to a monitored connection. The number of monitored connections along an ODUk trail
may vary between 0 and 6. Monitored connections can be nested, overlapping and/or cascaded.
(http://4.bp.blogspot.com/-huijFsXrr6E/UbYYkfpEyXI/AAAAAAAAAtM/QiuuB6pvtmk/s1600/21.JPG)
Figure 21 ODUk monitored connections
Monitored connections A1-A2/B1-B2/C1-C2 and A1-A2/B3-B4 are nested, while B1-B2/B3-B4 are cascaded.
Overlapping monitored connections are also supported.
(http://4.bp.blogspot.com/-04dBRPP8YBc/UbYYrSdPTbI/AAAAAAAAAtU/AiLv7KzknZQ/s1600/22.JPG)
Figure 22 Overlapping ODUk monitored connections
9.3 TRANSPARENT TRANSPORT OF CLIENT SIGNALS ()
G.709 de nes the OPUk which can contain the entire SDH signal. This means that one can transport 4 STM-16
signals in one OTU2 and not modify any of the 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 de-mapping client).
It is also delay transparent. For example if 4 STM-16 signals are mapped into ODU1’s and then multiplexed into
an ODU2, their timing relationship is preserved until they are de-mapped back to ODU1’s.
9.4 SWITCHING SCALABILITY ()
When SDH was developed, its main purpose was to provide the transport technology for voice services. Two
switching levels were therefore de ned. A low order switching at VC-12 level supports directly the E1 voice signals
and a high order switching level at VC-4 level is used for tra c engineering. Switching levels at higher bit rates
were not foreseen.
Over time the line rate increased while the switching rate was xed. 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 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 VC-4 level.
For a 4 x 10G to 40G SDH multiplexer this means processing of 256 VC-4. This will result not only in e orts in the
equipment hardware, but also in management and operations e orts.
For e cient 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. An independent
selection for service bit rates and DWDM technology is not possible.
A operator o ering 2,5 Gbit/s IP interconnection would need a N x 2G5 DWDM system. When adding 10G services
he has to upgrade some of its wavelengths to 10G. This would lead to ine cient 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.
An operator can o er services at various bit rates (2G5, 10G …) independent of the bit rate per wavelength using
the multiplexing and inverse multiplexing features of the OTN.
OTN ALARM FLOW

(http://2.bp.blogspot.com/-132L11j9zeU/UbYY2Xa3AXI/AAAAAAAAAtc/HhFck-qhVpg/s1600/s21.JPG)
SOME MORE PICTURES RELATED TO OTN

OTN GALLERY
(http://4.bp.blogspot.com/-eCvoUHkWTbM/UbYZ0DiZSnI/AAAAAAAAAt8/T305MFwiRc4/s1600/23.jpg)
(http://3.bp.blogspot.com/-_57USsn6r18/UbYZ1ygs8gI/AAAAAAAAAug/vXb75dY7wUQ/s1600/s3.JPG)
(http://4.bp.blogspot.com/--1TSTngnU8A/UbYZ2EEyC3I/AAAAAAAAAus/ypv8WpSjDFs/s1600/s7.JPG)
(http://4.bp.blogspot.com/-qjKp8JiERaQ/UbYZ3Obu-dI/AAAAAAAAAu0/4Ma9HEeS18s/s1600/s9.JPG)
(http://3.bp.blogspot.com/-NBxmm3LhZwo/UbYZz0xYRRI/AAAAAAAAAt0/CoFVmavAHY0/s1600/s13.JPG)
(http://4.bp.blogspot.com/-0dIw2uwZ6TM/UbYZ1hDquZI/AAAAAAAAAuY/uwG4tdtCLpU/s1600/s14.JPG)
(http://3.bp.blogspot.com/-XHHL0vQBQjs/UbYZ0lZ70ZI/AAAAAAAAAuE/gOEly8PRQkI/s1600/s16.JPG)
(http://2.bp.blogspot.com/-lMBQk-PGMeE/UbYZ0xFxYmI/AAAAAAAAAuI/1X-UF3V4z58/s1600/s17multi.JPG)
(http://2.bp.blogspot.com/-QgHm0SneGjo/UbYZ1k7a0vI/AAAAAAAAAuU/QYibi4p1JXA/s1600/s18.JPG)
(http://2.bp.blogspot.com/-CoZ23aQ3JZo/UbYaRDb6U0I/AAAAAAAAAvE/J63Yb0fE5WE/s1600/11111.JPG)
Go Back
0 comments (/entries/general/optical-transport-network-otn-a-comprehensive-study#comments)
General (/entries/general)

Optical Transport Network (OTN) - A Comprehensive Study - MapYourTech

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Optical Transport Network (OTN) - A Comprehensive Study - MapYourTech

Hochgeladen von

Copyright:

Verfügbare Formate

Share and Explore the Tech Inside You!!!

MapYourTech.com (/) Share the Tech Inside You!!!

TECH-MATS (/) POSTERS (/technology) INTERVIEW BUDDY (/interview-guide)

Optical Transport Network (OTN):A comprehensive study

Topic Title Publ.*

G.872 Architecture of Optical Transport Networks 11/01

ASTN/ASON recommendations are moved to speci c ASTN/ASON

G.975 Forward Error Correction 10/00

G.681 Functional characteristics of intero ce long-haul line systems using

G.798 Characteristics of optical transport network (OTN) equipment

Functional G.798 Amendment 1 06/02

G.806 Characteristics of transport equipment - Description Methodology

G.7710/Y.1701 Common Equipment Management Requirements 11/01

G.808.1 (G.gps) Generic protection switching - Linear trail and subnetwork

G.873.1 Errata 1 Optical Transport network (OTN) - Linear Protection 10/03

G.874 Management aspects of the optical transport network element 11/01

G.874.1 Optical Transport Network (OTN) Protocol-Neutral Management

Data G.7712/Y.1703 Architecture and speci cation of data communication

G.8201 (G.optperf) Error performance parameters and objectives for multi-

G.optperf living list

G.664 General Automatic Power Shut-Down Procedures for Optical

G.691 Optical Interfaces for single-channel SDH systems with Optical

G.693 Optical interfaces for intra-o ce systems 11/01

G.694.1 Spectral grids for WDM applications: DWDM frequency grid 06/02

G.695 Optical interfaces for Coarse Wavelength Division Multiplexing

G.696.1(G.IaDI) Intra-Domain DWDM applications 2004

G.697(G.optmon) Optical monitoring for DWDM system 2004

G.959.1 Optical Transport Networking Physical Layer Interfaces 02/01

Sup.39 (Sup.dsn) Optical System Design and Engineering Considerations 2003

G.651 Characteristics of a 50/125 um multipmode graded index optical

G.652 Characteristics of a single-mode optical bre cable 03/03

Fibres G.653 Characteristics of a dispersion-shifted single mode optical bre cable 12/03

G.654 Characteristics of a cut-o shifted single-mode bre cable 06/02

G.655 Characteristics of a non-zero dispersion shifted single-mode optical

G.662 Generic characteristics of optical bre ampli er devices and

G.663 Application related aspects of optical bre ampli er devices and sub-

COMPARISON OF SDH AND OTN

This document uses the following abbreviations:

2 What is OTN/OTH ()

3.1 BASIC SIGNAL STRUCTURE ()

Figure 1 Structure of the OTN interfaces

3.1.1 OCh substructure ()

· The optical channel data unit (ODUk) which provides:

3.1.2 Full functionality OTM-n.m (n ≥ 1) structure ()

The OTM-n.m (n ≥ 1) consists of the following layers:

3.1.3 Reduced functionality OTM-nr.m and OTM-0.m structure ()

The OTM-nr.m and OTM-0.m consist of the following layers:

3.2 INFORMATION STRUCTURE FOR THE OTN INTERFACES ()

Figure 2 Principal information containment relationships

The following layers are de ned in OTN:

()Figure ()3 OTN Network Layers ()

4 Multiplexing/mapping principles and bit rates ()

Figure ()5 OTM multiplexing and mapping structure

4.2 WAVELENGTH DIVISION MULTIPLEX ()

4.3 BIT RATES AND CAPACITY ()

Table 1 OTU types and capacity

Table 2 ODU types and capacity

Table 3 OPU types and capacity

4.4 ODUK TIME-DIVISION MULTIPLEX ()

Figure ()6 OTM multiplexing and mapping structure

Figure ()7 OTM multiplexing and mapping structure

5 OTUk, ODUk, OPUk Frame Structure ()

Figure ()8 OTN frame format