You are on page 1of 1

Agilent makes light work in the OTN


The next generation optical transport network (OTN)

enables the interconnection of network elements for the
transport of different types of client signals, for example
SONET/SDH, ATM, IP/Ethernet. Frame Alignment OTUk Overhead OPUk Overhead
Frame Alignment Signal (FAS) Multi Frame Alignment Signal (MFAS) The Optical Channel Payload Unit overhead includes information to support the adaptation of client
The network node interface of the OTN is defined in ITU-T The six-byte frame alignment signal is Hex codes F6 F6 F6 28 28 28. This byte is a binary count from 0 to 255, incrementing once per frame. The Optical Transport Unit overhead is terminated where the OTUk signal is assembled and
signals. It is terminated where the OPUk is assembled and disassembled, that is, at the edges of
the OTN. OPUk OH

G.709 and includes a rich overhead and forward error Some overhead signals span multiple frames and use this signal to lock
to a common multi-frame.
disassembled. It is similar to the section overhead in SONET or the Regenerator Section
overhead in SDH.
correction. Section Monitoring contains the following subfields:
Mapping Specific Overhead

Seven bytes are reserved for mapping overhead. The use of these bytes depends on the specific
Trail Trace Identifier (TTI) client signal mapping. For example, mapping SONET/SDH uses four of these bytes for justification.

64 byte multi-frame signal, contained in one overhead byte. Contains the source and destination
access point identifiers (API) for the current section. The API are made of Country Code (CC), ITU Payload Structure Identifier (PSI)
Carrier Code (ICC) and Unique Access point code (UAPC).
This is a 256 byte multiframe signal contained within an OPUk OH byte.
The TTI also contains 32 operator-specific bytes. PSI [0] contains the payload type (PT) byte.
PSI [1] to PSI [255] are reserved for future international standardization.

ODUk Overhead Error Detection Code (BIP-8)

This byte is a Bit Interleaved Parity computed over all the bits in the OPUk (col 15 - 3824), two
frames perviously. It is used to determine error performance across a section.
Payload Type (PT)

Payload Type code points:

Backward Defect Indication (BDI)
This contains end-to-end path overhead signals and tandem connection overhead signals. The ODUk path OH is terminated where the
ODUk is assembled and disassembled. The ODUk TC OH is added and terminated at the source and sink of the corresponding tandem This one bit is high when a signal fail status
connection. has been detected in the backward direction.

Backward Error Indication (BEI)

Four bit signal to convey the number of BIP errors in the reverse direction. Only binary values 0 to 8 are valid. Any other
value is interpreted as zero.

Incoming Alignment Error (IAE)

One bit signal used to indicate a frame

alignment error in the incoming OTUk.

This may be used to suppress the counting of bit errors during a frame phase change.

Reserved (RES)
It is similar to the Path Overhead in both SONET and SDH.
Two bits are reserved for future standardization. They are set to “00”.

Path Monitoring General Communications Channel 0 (GCC0)

The three path monitoring bytes are very similar to the Section Monitoring Two bytes are allocated as a communications channel between section end points. It is a clear channel and any format
bytes except that they apply to the ODUk path. can be used. The rate is dependent upon the k value.

• Trail trace identifier (TTI) ü

• Bit-interleaved parity (BIP-8) ï refer to OTUk Overhead
• Backward defect indication (BDI) ï for explanation Mapping of SONET/SDH client signals
• Backward error indication(BEI) þ
• Status bits indicating presence of a maintenance signal (STAT). Mapping may be performed using asynchronous or bit-synchronous modes.

Path Monitoring Status (STAT)

These three bits replace the IAE and RES bits in the OTUk section monitoring
area. They are used to indicate the presence of a maintenance signal.
Tandem Connection Monitoring Activation/
ODUk PM status interpretation Deactivation coordination protocol (TCM ACT)

This one-byte signal is presently undefined.

General Communication Channels (GCC1, GCC2)

Two fields of two bytes are allocated to support two GCCs between any two network elements with access to the ODUk frame.

Automatic Protection Switching and Protection Control Path (APS/PCC)

These four bytes are currently undefined.

Fault Type and Fault Location reporting communication channel (FTFL)

This is a 256-byte multiframe signal contained within one ODUk OH byte.

Fault Indication Codes Justification Control (JC)

Tandem Connection Monitoring Overhead
There are three justification control bytes, each containing two
An optical channel can support up to six layers of tandem connection. Six sets of three bytes are used to monitor them: TCM1-6. justification control bits. The two bits are used to indicate
whether the negative or positive justification opportunity bytes
Each set of three bytes is very similar to the path monitoring bytes above, except that they apply to the tandem connection. contain data. A majority vote (two out of three JC bytes) are used
for error protection.
• Trail Trace Identifier (TTI);
• Bit Interleaved Parity 8 (BIP-8); The value contained in the Negative Justification Opportunity
• Backward Defect Indication (BDI); (NJO) and Positive Justification Opportunity (PJO) when they are
• Backward Error Indication (BEI); used as justification bytes is all zeros. In bit-synchronous mode
• Status bits indicating the presence of TCM overhead, Incoming Alignment Error, or a maintenance signal (STAT). all JC bits are set to “00” and PJO is always a data byte.
OTU type and capacity Tandem Connection Monitoring Status (STAT)
These three bits are used to indicate the presence of a maintenance signal, if there is an incoming alignment error, or if there is no
active source. The OPUk payload area is 4 ´ 3808 bytes, including the PJO byte. Groups of eight successive bits (not necessarily being a byte) of the SONET/SDH
signal are mapped into payload bytes of the OPUk.
ODUk TCM status interpretation
In the case of OPU2 and OPU3 fixed stuff bytes are added in specific columns in order to allow for future ODU multiplexing. For example four
ODU2s into an ODU3.

The FTFL field is used to report a fault type (signal fail or signal degrade) and fault location (country and operator) in the forward and backward

Experimental Overhead (EXP)

These two bytes are for experimental use by a network operator. There is no requirement to forward the EXP overhead beyond the (sub)network.

Reserved overhead (RES)

A total of nine bytes are reserved in the ODUk for future international standardization. These bytes are set to all zeros.
Forward Error Correction (FEC)
Maintenance Signals Forward Error Correction (FEC) can be used to provide more system margin if the span length remains constant or to increase span length
with a given BER objective and optical power. FEC detects and corrects errors to effectively deliver a 7 to 8 dB improvement in signal-to-
noise ratio i.e. margin. For ITU G.709 the FEC code used is a Reed-Solomon RS(255,239). This is byte interleaved to increase burst error
As telecom technology continues to evolve,
The FEC check parity bytes are added when the OTUk structure is generated and they are located in columns 3825 to 4080.
OTUk Alarm Indication Signal (OTUk-AIS) ODUk Locked (ODUk-LCK) there’s every reason to choose OmniBER
The locked maintenance signal is generated on operator
OTN now. Not only can it solve today’s Before FEC processing, each OTU row is separated into 16 sub-rows using byte-interleaving. Each FEC encoder/decoder processes one of
This is a generic signal sent downstream when a defect these sub-rows. The FEC parity check bytes are calculated over the 239 information bytes of each sub-row and transmitted in the last16
has been detected in order to suppress defects or faults. request in order to lock the signal from user access. It SONET/SDH problems, it’s ideal for testing
bytes of the same sub-row.
It consists of a pseudo-random bit sequence (PRBS) consists of a repeating “0101 0101” pattern in the entire devices and modules for the optical transport
211–1, which replaces the entire OTUk. ODUk signal, which excludes the Frame Alignment
overhead and the OTUk overhead.
network (OTN) to ITU-T G.709. It has been
ODUk Alarm Indication Signal (ODUk-AIS) designed to evolve as transmission
Client Maintenance Signal (Generic AIS) technology evolves, providing an upgrade
The ODUk alarm indication signal consists of all ones in
The generic alarm indication signal for constant bit rate
path to jitter, gigabit ethernet and 40 Gb/s.
the entire ODUk signal, excluding FTFL byte. This does Data are based on information, diagrams and figures taken from ITU-T Recommendations with the In short, it’s the platform of the future, today.
not overwrite the Frame Alignment or OTUk overhead client signals is a PRBS 211–1 repeating sequence.
kind permission of the International Telecommunication Union (ITU) as copyright holder. Where
appropriate, please consult the full text of the relevant ITU Recommendations for the authoritative
ODUk Open Connection Indication (ODUk-OCI)
version. These may be obtained from the ITU Sales Section, Place des Nations, CH-1211 Geneva 20,
An open connection indication is sent downstream when Switzerland; Tel.: +41.22.730.61.41, Fax: +41.22.730.51.94, E-mail:
no signal is detected from upstream. It consists of a
repeating “0110 0110” pattern in the entire ODUk signal,
which excludes the Frame Alignment overhead and the
OTUk overhead.
Product specification and descriptions in this document subject to change without notice.

© Agilent Technologies, Inc. 2001 • Printed in UK, 5 November, 2001 • 5988-4004EN