Tag: FEC Encoding

OTN – Lesson 9 – Video 2 – OTU Layer Source Direction – Part 2

This post presents the 2nd of 11 Videos that covers training on Performance Monitoring at the OTU-Layer. This post focuses on the Source-Direction OTU-Layer Atomic Functions.

OTN – Lesson 9 – Video 2 – OTU Layer Source Direction Circuitry/Functionality – Part 2

This blog post contains a video that discusses the OTU Layer Source Direction circuitry.  This Video is the 2nd of 11 videos that focus on the OTU Layer.

This Video discusses the role/functionality of the OTSiG/OTUk_A_So Atomic Function (aka OTL3.4 or OTL4.4 Source Terminal) and the OTSi/OTUk_A_So Atomic Function (for OTU1 and OTU2 applications).   

I will briefly describe the role of these atomic functions below.

Role of the OTSiG/OTUk_A_So Atomic Function

  • To insert the FAS/MFAS fields into the Outbound OTU3/OTU4 data-stream
  • Compute the FEC-field and insert it into the backend of each outbound OTU3 or OTU4 frame.
  • Scramble the outbound OTU3/OTU4 data-stream
  • Convert an OTU3 or OTU4 signal into an OTL3.4 or OTL4.4 set of signals.  
  • Forward this OTL3.4 or OTL4.4 set of signals to an Optical Module for further processing.  

Role of the OTSi/OTUk_A_So Atomic Function

  • To insert the FAS/MFAS fields  into the outbound OTU1/OTU2 data-stream
  • Computer the FEC-field and insert it into the backend of each outbound OTU1 or OTU2 frame.
  • Scramble the outbound OTU1/OTU2 data stream.
  • Forward this scrambled (and FEC encoded) OTU1 or OTU2 data stream to an Optical Module for further processing.  

Continue reading “OTN – Lesson 9 – Video 2 – OTU Layer Source Direction – Part 2”

What is the OTSiG/OTUk_A_So Function?

This blog post briefly describes the OTSiG/OTUk-a_A_So Atomic Function. The main purpose of this Atomic Function is to either convert an OTU3 data-stream into the OTL3.4 format, or to convert the OTU4 data-stream into the OTL4.10 or OTL4.4 format.

What is the OTSiG/OTUk_A_So Atomic Function?

The expression:  OTSiG/OTUk_A_So is an abbreviation for the term:  Optical Tributary Signal Group to OTUk Adaptation Source Function.

This blog post will briefly describe the OTSiG/OTUk_A_So set of atomic functions.

Changes in Terminology

Before we proceed on with this post, we need to cover some recent changes in terminology.  Before the June 2016 Version of ITU-T G.709, the standard documents referred to this particular atomic function as the OPSM/OTUk_A_So function.

However, the standards committee has recently decided to change the wording from using the term OPSM (Optical Physical Section Multilane) to using the word OTSiG (for Optical Tributary Signal Group).

For completeness, I will tell you that ITU-T G.709 defines the term OTSiG as:

“The set of OTSi signals that supports an OTU.”

Therefore, where we used the OTSi/OTUk_A_So and OTSi/OTUk_A_Sk functions for “single-lane” applications, we will use the OTSiG/OTUk_A_So and OTSiG/OTUk_A_Sk functions for “multi-lane” applications.

In summary, to “speak the same language,” as does the standard committee, we will call this atomic function the OTSiG/OTUk_A_So atomic function.

Likewise, in another post, we will now call (what we used to call the OPSM/OTUk_A_Sk function) the OTSiG/OTUk_A_Sk function.

I have created another post that provides documentation of the relationships between some old (now obsolete) terms and the new (and approved) ones that our standard committee is currently using.

A Little More about Multi-Lane Interfaces for OTU3 and OTU4 Applications

First, we only use the OTSiG/OTUk_A_So and OTSiG/OTUk_A_Sk functions for OTU3 and OTU4 Multi-Lane applications.

We will use the OTSiG/OTUk_A_So function for OTU3 applications to model circuitry that demultiplexes an OTU3 signal into a four-lane signal (e.g., an OTL3.4 signal).  ITU-T G.709 defines the OTL3.4 signal as an approach to transporting OTU3 traffic over 4-lanes in parallel.

Likewise, we will use the OTSiG/OTUk_A_So function for OTU4 applications to model circuitry that demultiplexes (and multiplexes) an OTU4 signal into a four-lane signal (e.g., an OTL4.4 signal).  ITU-T G.709 also defines the OTL4.4 signal as an approach to transporting OTU4 traffic over 4-lanes in parallel.

Please see the blog posts for the OTL3.4 and OTL4.4 Interfaces for more information on these topics.

The OTSiG/OTUk_A_So Function

The OTSiG/OTUk_A_So function is any circuit that takes an OTUk data-stream, clock, frame-start, and multi-frame start signals and:

  • converts this data into a combined, scrambled data stream, which (in some cases) contains a FEC (Forward-Error-Correction) field, and
  • demultiplexes this data into four electrical lanes, each of which can be readily converted into the optical format (at the output pins of this function).

Once again, ITU-T G.798 states that the system designer can use this function only for the OTU3 or OTU4 rates.

For OTU1 and OTU2 rates, we recommend that the system designer use the OTSi/OTUk_A_So function instead.

We discuss the OTSi/OTUk_A_So atomic function in another post.

Figure 1 presents a simple illustration of the OTSiG/OTUk_A_So function.

OTSiG/OTUk-a_A_So Atomic Function - Simple Drawing

Figure 1, Simple Illustration of the OTSiG/OTUk_A_So function.

ITU-T G.798 defines two versions of this particular function.   Additionally, there are other versions of this function that are not specified by ITU-T G.798.  I list some popular versions of this function below in Table 1.

Table 1, List of Some Popular Versions for the OTSiG/OTUk_A_So function.  

Function NameDescriptionComments
OTSiG/OTUk-a_A_SoOTSiG to OTUk Adaptation Source Function with ITU-T G.709 Standard FEC.Can be used for OTU3 and OTU4 applications ONLY.
OTSiG/OTUk-b_A_SoOTSiG to OTUk Adaptation Source Function with No FECCan only be used for OTU3 Applications.

Cannot be used for OTU4 applications.
OTSiG/OTUk-v_A_SoOTSiG to OTUk Adaptation Source Function with Vendor-Specific FECCan be used for OTU3 and OTU4 Applications.

Not specified by ITU-T G.798.

Table 1 shows that the OTSiG/OTUk-a_A_So and the OTSiG/OTUk-v_A_So functions will compute and append some sort of FEC field to the back-end of each outbound OTUk frame.

However, this table also shows that the OTSiG/OTUk-b_A_So version does not generate the FEC field.

Consequently, ITU-T G.798 states that one can use the OTSiG/OTUk-a_A_So and OTSiG/OTUk-v_A_So functions for OTU3 and OTU4 applications.  The standard also recommends that the user NOT use the OTSiG/OTUk-b_A_So function for OTU4 applications.

The OTU4 rate requires the use of Forward-Error-Correction.

What Version will we Discuss Throughout this Post?

Throughout this post, we will be discussing the OTSiG/OTUk-a_A_So version of this atomic function.

The OTSiG/OTUk-b_A_So and OTSiG/OTUk-v_A_So atomic functions do everything that the OTSiG/OTUk-a_A_So does, except that the -b version does NO FEC Encoding, and the -v version does FEC Encoding differently than what I describe here.

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!!! Click on the Banner Below to Learn More!!

Corporate Discounts Available!!!

So What All Does this Atomic Function Do?

The OTSiG/OTUk-a_A_So function will accept the OTUk data-stream, OTUk clock signal, frame-start signal, and multi-frame start signals via the CI_D, CI_CK, CI_FS, and CI_MFS inputs (of this function) respectively, and it will perform the following tasks.

  • It will insert the FAS and MFAS fields into the outbound OTUk data stream (coincident with whenever the upstream OTUk_TT_So function asserts the CI_FS and CI_MFS inputs, respectively).
  • This function will compute and append a FEC field to the back-end of each outbound OTUk frame.
  • It will scramble this “combined” OTUk data stream (consisting of the FAS, MFAS, and FEC fields).
  • Next, this function will demultiplex and combine this data stream into four parallel lanes of OTL3.4 traffic (for OTU3 applications) and OTL4.4 traffic (for OTU4 applications).
  • This function will transmit these four lanes to external Electrical-to-Optical Conversion circuitry (which will convert our OTL3.4 or OTL4.4 traffic into the optical format).

I illustrate a Unidirectional Connection that shows where the OTSiG/OTUk-a_a_So function “fits in” within a system below in Figure 2.

OTSiG/OTUk-a_A_So_Function in End-to-End Connection

Figure 2, Illustration of an STE, transmitting an OTUk signal (over optical fiber) to another STE – the OTSiG/OTUk-a_A_So function is highlighted.  

Figure 2 shows that the OTSiG/OTUk-a_A_So function will accept traffic from the upstream OTUk_TT_So function.  The OTSiG/OTUk-a_A_So function will then perform additional processing on this data before it sends it over to optical circuitry for conversion and transport.

We will discuss this additional processing below.

Functional Description of this Atomic Function

Let’s take a closer look at this function now.

The OTSiG/OTUk-a_A_So functional blocks are different for OTU3 applications than for OTU4 applications.  Therefore, we will first walk through the Functional Block Diagram for OTU3 applications.

Afterward, we will do the same for OTU4 applications.

Review of the OTSiG/OTU3-a_A_So Functional Block Diagram – OTU3 Applications

Figure 3 presents the Functional Block Diagram of the OTSiG/OTUk-a_A_So Atomic Function for OTU3 Applications.

OTSiG/OTUk-a_A_So Functional Block Diagram - OTU3 Applications

Figure 3, Illustration of the Functional Block Diagram of the OTSiG/OTU3-a_A_So Atomic Function (for OTU3 Applications).  

Hence, Figure 3 shows that the OTU3-version of this function contains the following functional blocks.

  • FAS/MFAS Insertion Block
  • FEC Encoder Block
  • Scrambler Block
  • 16-Byte Block Distributor and Rotator Block

I will briefly discuss each of these functional blocks below.

The FAS/MFAS Insertion Block

The FAS/MFAS Insertion Block is the first block the OTU3 signal will pass through after entering this atomic function.  I illustrate the OTSiG/OTU3-a_A_So function with the FAS/MFAS Insertion block highlighted below in Figure 4.

OTSiG/OTUk-a_A_So Function - OTU3 Applications - FAS/MFAS Insertion Block Highlighted

Figure 4, Illustration of the OTSiG/OTU3-a_A_So Functional Block Diagram with the FAS/MFAS Insertion Block highlighted.  

The FAS/MFAS Insertion block will insert the FAS and MFAS fields into the outbound OTU3 data stream each time the upstream OTUk_TT_So function asserts the CI_FS input pin.

Likewise, the FAS/MFAS Insertion block will initialize the MFAS byte-field to 0x00 within the outbound OTU3 data stream each time the upstream OTUk_TT_So function asserts the CI_MFS input pin.

The FAS/MFAS Insertion block will proceed to increment the contents of the MFAS field within each OTU3 frame it generates.

The FEC Encoder Block

Once the OTU3 signal leaves the FAS/MFAS Insertion block, it will pass through the FEC Encoder block.  I show an illustration of the OTSiG/OTU3-a_A_So Functional Block Diagram, with the FEC Encoder Block Highlighted below in Figure 5.

OTSiG/OTUk-a_A_So Functional Block - OTU3 Applications - FEC Encoder Block

Figure 5, Illustration of the OTSiG/OTU3-a_A_So Functional Block Diagram with the FEC Encoder block highlighted.  

The FEC Encoder block will compute the FEC field and append this field to the back-end of each outbound OTU3 frame.

ITU-T G.709 recommends that (for a Fully-Compliant OTUk Frame), one uses the Reed Solomon RS(255,239) Code for its Forward-Error-Correction scheme.

The standard also recommends that the System Designer use Symbol-Interleaving and that the user place the resulting FEC code into a 4-row x 256-byte column field at the back-end of each outbound OTUk frame.

I show the location (that the FEC Encoder block should insert the FEC Code) within the OTUk frame below in Figure 6.

OTUk Frame with FEC Field highlighted

Figure 6, Illustration of the OTUk Frame, with the Location of the FEC-field highlighted

I discuss this Forward-Error-Correction scheme in much greater detail in another post.

Once this OTU3 data stream leaves the FEC Encoder block, it will proceed to the Scrambler block for further processing.

The Scrambler Block

I illustrate the OTSiG/OTU3-a_A_So Functional Block Diagram with the Scrambler Block highlighted below in Figure 7.

OTSiG/OTUk-a_A_So Function Block Diagram - OTU3 Applications - Scrambler Block

Figure 7, Illustration of the OTSiG/OTU3-a_A_So Functional Block Diagram with the Scrambler Block highlighted.

ITU-T G.709 requires that we scramble OTUk data before we transmit it over optical fiber.

The standard requires that we do this to ensure that this OTUk signal has sufficient bit-timing content for Clock and Data Recovery PLLs (Phase-Locked Loops) within the Sink STE (at the remote end).

ITU-T G.709 also states that the Scrambler must operate as a frame synchronous scrambler of sequence length 65,535 (e.g., 216-1), running at the OTUk rate.

Finally, ITU-T G.709 states that the Scrambler must use the generating polynomial of 1 + x + x3 + x12 + x16.

I show a simple diagram of how the user can implement the Scrambler within their OTSiG/OTUk-a_A_So function design below in Figure 8.

OTUk Scrambler within the OTSiG/OTUk_A_So Atomic Function

Figure 8, Illustration of the High-Level Block Diagram for the Frame-Synchronous Scrambler

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

16-Byte Block Distributor and Rotator Block

Once the OTU3 signal leaves the Scrambler block, it will pass through the 16-Byte Block Distributor and Rotator Block.  I illustrate the OTSiG/OTU3-a_A_So Functional Block Diagram with the 16-Byte Block Distributor and Rotator Block highlighted below in Figure 9.

OTSiG/OTUk-a_A_So Functional Block Diagram - OTU3 Applications - 16 Byte Block Distributor and Rotator

Figure 9, Illustration of the OTSiG/OTU3-a_A_So Functional Block Diagram with the 16-Byte Block Distributor and Rotator Block highlighted.

The 16-Byte Block Distributor and Rotator block will convert a composite OTU3 signal (that is of the form of a single serial data stream) into the OTL3.4 format (over four lanes) that we describe in the OTL3.4 post.

In this case, the OTSiG/OTU3-a_A_So function has four outputs (one output for each of the four OTL3.4 lanes), which we labeled AI_PLD[1] through AI_PLD[4] in Figure 9.

The user is expected to connect these four output signals to optical circuitry (that will convert this electrical data into the optical format).

We have briefly covered the OTSiG/OTUk-a_A_So function block for OTU3 applications.  Let’s move on and discuss this atomic function for OTU4 applications.

Review of the OTSiG/OTU4-a_A_So Functional Block Diagram – OTU4 Applications

I present the Functional Block Diagram of the OTSiG/OTUk-a_A_So Atomic Function for OTU4 Applications below in Figure 10.

OTSiG/OTUk-a_A_So Functional Block Diagram - OTU4 Applications

Figure 10, Illustration of the Functional Block Diagram of the OTSiG/OTU4-a_A_So Atomic Function (for OTU4 Applications)

Hence, Figure 4 shows that the OTU4 version of this function contains the following functional blocks.

  • FAS/MFAS Insertion Block
  • FEC Encoder Block
  • Scrambler Block
  • LLM (Logical Lane Marker) Insertion Block
  • 16 Byte Block Distributor and Rotator Block

I will discuss some of these Functional blocks below.  Please note that some of these blocks are identical to what I’ve presented for OTU3 applications.  I will note that whenever I come to those functional blocks.

The FAS/MFAS Insertion Block

Please see the description for the FAS/MFAS Insertion Block above for OTU3 applications.

The FEC Encoder Block

Please see the description for the FEC Encoder Block above for OTU3 applications.

The Scrambler Block

Please see the description for the Scrambler Block above for OTU3 applications.

The LLM (Logical Lane Marker) Insertion Block

Once the OTU4 signal passes through and leaves the Scrambler block, it will pass through the LLM Insertion block.

I show an illustration of the OTSiG/OTU4-a_A_So Functional Block Diagram with the LLM Insertion Block Highlighted below in Figure 11.

OTSiG/OTUk-a_A_So Functional Block Diagram - OTU4 Applications - LLM Insertion Block

Figure 11, Illustration of the OTSiG/OTU4-a_A_So Functional Block Diagram, with the LLM Insertion Block highlighted.

Two things happen at the LLM Insertion Block.

  1.  We start the process of demultiplexing the OTU4 data stream into 20 logical lanes, and
  2. We identify these Logical Lanes by inserting the appropriate LLM value into each of these 20 logical lanes (or data streams).

If you recall from the OTL4.4 blog post, whenever we encode an OTU4 signal into the OTL4.4 format, we will borrow the 3rd OA2 byte-field (within the FAS field) and use it as the Logical Lane Marker.

I show an illustration of the OTUk Framing Format, with this particular FAS byte highlighted below in Figure 12.

OTU4 Frame with 3rd OA2 Byte being used as the OTL4.4 Logical Lane Marker

Figure 12, Illustration of the OTUk Framing Format, with the 3rd OA2 Byte-field (that we use for the LLM – for OTL4.4 applications) highlighted.  

The purpose of the LLM Insertion Block is to insert a value into this “borrowed FAS-byte field” that ranges in value from 0 to 239.  This value (that we insert into this LLM field) functions as the Logical Lane ID for each of the 20 Logical Lanes.

Please see the OTL4.4 Blog Post for more information on the assignment of these Logical Lane IDs.

The 16-Byte Block Distributor and Rotator Block

Once the OTU4 signal exits the LLM Insertion Block, it will pass through the 16-Byte Block Distributor and Rotator Block.

I illustrate the OTSiG/OTU4-a_A_So functional block diagram with the 16-Byte Block Distributor and Rotator block highlighted below in Figure 13.

OTSiG/OTUk-a_A_So Functional Block Diagram - OTU4 Applications - 16-Byte Block Distributor and Rotator Block

Figure 13, Illustration of the OTSiG/OTU4-a_A_So Functional Block Diagram with the 16-Byte Block Distributor and Rotator Block highlighted.

The 16-Byte Block Distributor and Rotator Block will work with the LLM Insertion Block to demultiplex a serial OTU4 data stream into 20 logical lane signals.

Please see the OTL4.4 post for most information about the 16-Byte Block Distributor and Rotator block.

This block will then route these 20 logical lanes (with their LLM ID included) downstream towards their 5:1 Bit-Wise Multiplexers.

The 5:1 Bit-Wise Multiplexers

After the LLM Insertion and 16-Byte Distributor and Rotator blocks have demultiplexed the single OTU4 signal into 20 Logical Lane signals, these blocks will send these 20 Logical Lane signals to a set of four 5:1 Bit-Wise Multiplexers.

I illustrate the OTSiG/OTU4-a_A_So Functional Block Diagram with a set of four 5:1 Bit-Wise Multiplexers highlighted below in Figure 14.

OTSiG/OTUk-a_A_So Functional Block Diagram - OTU4 Applications - 5:1 MUX Blocks

Figure 14, Illustration of the OTSiG/OTU4-a_A_So Functional Block Diagram, with a set of four 5:1 Bit-Wise Multiplexers highlighted

The OTSiG/OTU4-a_A_So function will route each of the 20 Logical Lane signals to one of four 5:1 Bit-Wise Multiplexers.  Each of these 5:1 Bit-Wise Multiplexers will accept 5 Logical Lane signals.  These Bit-Wise Multiplexers will then bit-wise multiplex these five signals into a single electrical lane.

Therefore, since we are applying 20 Logical Lane signals to these four 5:1 Bit-Wise Multiplexers, we will combine these 20 Logical Lane signals into four electrical lane signals.   These bit-wise multiplexed 4-lane signals are our OTL4.4 signal that we can route to the nearby optical circuitry.

The OTSiG/OTU4-a_A_So function will output these four electrical signals to optical circuitry via the AI_PLD[1] through AI_PLD[4] output signals.

Function Defects

This function does not declare any defect conditions.

Function Consequent Equations

This function does not have any Consequent Action (or Equations).

Pin Description of the OTSiG/OTUk-a_A_So Function

Table 2 presents a list and description of each of the Input and Output pins of the OTSiG/OTUk-a_A_So Function.

Table 2, Pin Description of the OTSiG/OTUk-a_A_So Atomic Function

Signal NameTypeDescription
OTUk_CP Interface
CI_DInputOTUk Characteristic Information - OTUk Data Input:
The OTSiG/OTUk-a_A_So function will accept this OTU3 or OTU4 data-stream from the upstream OTUk_TT_So function. The OTSiG/OTUk-a_A_So atomic function will then convert this single OTU3 or OTU4 data-stream into the OTL3.4 or OTL4.4 format, respectively.

This OTUk data-stream will NOT include the FAS, MFAS or FEC fields.

This particular function will compute and append the FEC field to the back-end of each outbound OTU3/4 frame. This function will also use the CI_FS and CI_MFS signal to insert the FAS and MFAS fields into this single OTU3/4 data-stream, all prior to demultiplexing this OTU3/4 data-stream into 4 lanes of traffic.
CI_CKInputOTUk Characteristic Information - Clock Input:
The OTSiG/OTUk-a_A_So function will sample all data and signals (at the OTUk_CP Interface) upon one of the edges of this input clock signal. This statement applies to the CI_D, CI_FS and CI_MFS input signals.

This clock signal will also function as the timing source for this function as well.
CI_FSInputOTUk Characteristic Information - Frame Start Output:
The upstream OTUk_TT_So function will drive this output pin HIGH whenever that function outputs the very first bit (or byte) of a new OTUk frame, via the CI_D input.

The OTUk_TT_So function should only pulse this output pin HIGH once for each incoming OTUk frame.

The OTSiG/OTUk-a_A_So function will use this input signal to determine where it should denote the boundary of each OTUk frame and insert the FAS, MFAS and FEC fields into the serial OTUk data-stream, prior to it demultiplexing this data-stream into 4 electrical lanes of traffic.
CI_MFSInputOTUk Characteristic Information - Multi-Frame Start Input:
The upstream OTUk_TT_So function will drive this output pin HIGH whenever it applies the very first bit (or byte) of a new OTUk multiframe to the CI_D input.

The upstream OTUk_TT_So function will drive this output pin HIGH once for each OTUk multi-frame.

The OTSiG/OTUk-a_A_So function will use this input to determine, at which OTUk frame, it should initialize the MFAS byte-field to 0x00 (to denote the start of a new Multi-Frame).
OTSi_AP Interface
A_PLD[1]OutputOTL3.4 or OTL4.4 Electrical Output - Lane 1:
After the OTSiG/OTUk-a_A_So function computes and inserts the FEC and also includes the FAS and MFAS fields, it will demultiplex that composite OTU3/OTU4 data-stream into either the OTL3.4 or OTL4.4 format.

This particular output is Lane 1 for this 4-Lane Electrical Interface.
A_PLD[2]OutputOTL3.4 or OTL4.4 Electrical Output - Lane 2:
Please see the description for AI_PLD[1].
A_PLD[3]OutputOTL3.4 or OTL4.4 Electrical Output - Lane 3:
Please see the description of AI_PLD[3].
A_PLD[4]OutputOTL3.4 or OTL4.4 Electrical Output - Lane 4:
Please see the description of AI_PLD[1].

Clueless about OTN? We Can Help!! Click on the Banner Below for More Information!!!

Discounts Available for a Short Time!!

Click on the Image below for More Blog Posts on Optical Transport Networks.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...
Read More

What is the OTSi/OTUk_A_So Function?

This post briefly describes the OTSi/OTUk_A_So (OTSI to OTUk Adaptation Source) Atomic Function. This function will perform tasks (like FEC Encoding) to condition the OTU data stream, prior to transport over Optical Fiber.


What is the OTSi/OTUk_A_So Atomic Function?

The expression:  OTSi/OTUk_A_So is an abbreviation for the term: Optical Tributary Signal to OTUk Adaptation Source Function.

This blog post will briefly describe the OTSi/OTUk_A_So set of atomic functions.

Changes in Terminology

Before we proceed on with this post, we need to cover some recent changes in terminology. Before the June 2016 Version of ITU-T G.709, the standard documents referred to this particular atomic function as the OCh/OTUk_A_So function.

However, the standards committee has recently decided to change the wording from using the term OCh (for Optical Channel) to OTSi (for Optical Tributary Signal).

For completeness, I will tell you that ITU-T G.959.1 defines the term OTSi as:

“Optical signal that is placed within a network media channel for transport across the optical network. This may consist of a single modulated optical carrier or a group of modulated optical carriers or subcarriers.“.

Therefore, to “speak the same language” as the standard committee, we will call this atomic function the OTSi/OTUk_A_So atomic function.

Likewise, in another post, we will now call (what we used to call the OCh/OTUk_A_Sk function) the OTSi/OTUk_A_Sk function.

I have created another post that provides documentation of the relationships between some old (now obsolete) terms and the new (and approved) ones that our standard committee is currently using.

Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!

Corporate Discounts Available!!!

The OTSi/OTUk_A_So Function

The OTSi/OTUk_A_So function is any circuit that takes an OTUk data-stream, clock, frame-start, and multi-frame start signals and converts this data into a combined, scrambled data-stream, which (in some cases) contains a FEC (Forward Error Correction) field. This data stream can be readily converted into the optical format (at the output of this function).

ITU-T G.798 states that the system designer can use this function for all OTUk rates (e.g., from OTU1 through OTU4).

However, in most cases, we will typically use the OTSi/OTUk_A_So function for OTU1 and OTU2 applications. We will usually use the OTSiG/OTUk_A_So  atomic function for OTU3 and OTU4 applications.

We discuss the OTSiG/OTUk_A_So atomic function in another post.

Figure 1 presents a simple illustration of the OTSi/OTUk_A_So function.

OTSi/OTUk-a_A_So Simple Function Drawing

Figure 1, Simple Illustration of the OTSi/OTUk_A_So function.

ITU-T G.798 defines three variants of this particular function. I have listed these variants below in Table 1.

Table 1, List of the ITU-T G.798-specified Variants for the OTSi/OTUk_A_So functions

Function NameDescriptionComments
OTSi/OTUk-a_A_SoOTSi to OTUk Adaptation Source Function with ITU-T G.709 Standard FECCan be used for OTU1 through OTU4 applications
OTSi/OTUk-b_A_SoOTSi to OTUk Adaptation Source Function with No FECCannot be used for OTU4 applications
OTSi/OTUk-v_A_SoOTSi to OTUk Adaptation Function with Vendor-Specific FECCan be used for OTU1 through OTU4 applications

Table 1 shows that the OTSi/OTUk-a_A_So and the OTSi/OTUk-v_A_So functions will compute and append some FEC field to the back-end of each outbound OTUk frame.

However, this table also shows that the OTSi/OTUk-b_A_So variant does not generate the FEC field.

Consequently, ITU-T G.798 states that one can use the OTSi/OTUk-a_A_So and OTSi/OTUk-v_A_So functions for OTU1 through OTU4 applications. The standard also recommends that the user NOT use the OTSi/OTUk-b_A_So function for OTU4 applications.

The OTU4 rate requires the use of Forward-Error-Correction.

What Variant will we Discuss Throughout this Post?

Throughout this post, we will be discussing the OTSi/OTUk-a_A_So version of this atomic function.

The OTSi/OTUk-b_A_So  and OTSi/OTUk-v_A_So atomic functions do everything that the OTSi/OTUk-a_A_So does, except that the -b variant does NO FEC Encoding and the -v variant does FEC Encoding differently than what I describe here.

So What All Does this Atomic Function Do?

The OTSi/OTUk-a_A_So function will accept the OTUk data-stream, OTUk clock signal, frame-start signal, and multi-frame start signals via the CI_D, CI_CK, CI_FS, and CI_MFS inputs (of this function) respectively, and it will perform the following tasks.

  • It will insert the FAS and MFAS fields into the OTUk data stream (coincident with whenever the upstream OTUk_TT_So function asserts the CI_FS and CI_MFS input, respectively).
  • This function will compute and append a FEC field to the back-end of each outbound OTUk frame)
  • It will scramble this “combined” OTUk data stream (consisting of the FAS, MFAS, and FEC fields)
  • This function will then transmit this combined (and scrambled) data stream to external Electrical-to-Optical Conversion circuitry (which will convert our full-blown OTUk signal into the optical format).

Figure 2 illustrates a Unidirectional Connection that shows where the OTSi/OTUk-a_A_So function “fits in” within a system.

OTSi/OTUk-a_A_So Function Highlighted in Unidirectional OTUk End-to-End Connection

Figure 2, Illustration of an STE, transmitting an OTUk signal (over optical fiber) to another STE – the OTSi/OTUk-a_A_So function is highlighted.

Functional Description of this Atomic Function

Let’s take a closer look at this function now.

Figure 3 presents the Functional Block Diagram of the OTSi/OTUk-a_A_So Atomic Function.

OTSi/OTUk-a_A_So Functional Block Diagram

Figure 3, Illustration of the Functional Block Diagram of the OTSi/OTUk-a_A_So Atomic Function

Hence, Figure 3 shows that this function contains the following functional blocks.

  • MFAS/FAS Insertion Block
  • FEC Encoder Block
  • Scrambler Block

I will briefly discuss each of these functional blocks below.

The MFAS/FAS Insertion Block

The MFAS/FAS Insertion block will insert the FAS and MFAS fields into the outbound OTUk data stream each time the upstream OTUk_TT_So function asserts the CI_FS input pin.

Likewise, the MFAS/FAS Insertion block will initialize the MFAS byte-field (to 0x00) within the outbound OTUk-data-stream each time the upstream OTUk_TT_So function asserts the CI_MFS input.

The MFAS/FAS Insertion Block will proceed to increment the contents of the MFAS field within each OTUk frame it generates.

Has Inflation got You Down? Our Price Discount Can Help You Fight Inflation and Help You To Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Corporate Discounts Available!!!

The FEC Encoder Block

The FEC Encoder Block (within the OTSi/OTUk-a_A_So function) will compute the FEC field and append this field to the back-end of each outbound OTUk frame.

ITU-T G.709 recommends that (for a Fully-Compliant OTUk Frame), one uses the Reed Solomon RS(255,239) Code for its Forward-Error Correction scheme.

The standard also recommends that the System Designer use Symbol-Interleaving and that the user place the resulting FEC code into a 4-row x 256-byte column field at the back-end of each outbound OTUk frame.

I show the location (that the FEC Encoder should insert the FEC Code) within the OTUk frame below in Figure 4.

OTUk Frame with FEC Field highlighted

Figure 4, Location of FEC Code (at the back-end of each outbound OTUk frame)

Another post discusses this Forward Error Correction scheme in much greater detail.

Scrambler Block

ITU-T G.709 mandates that we scramble OTUk data before we transmit it over optical fiber.

The standard requires that we do this to ensure that this OTUk signal (that we transmit over optical fiber) has sufficient bit-timing content for Clock and Data Recovery PLLs (Phase-Locked Loops) within the Sink STE (at the remote end).

ITU-T G.709 further states that the Scrambler must operate as a frame synchronous scrambler of sequence length 65,535 (e.g., 216-1), running at the OTUk rate.

Finally, ITU-T G.709 also states that the Scrambler must use the generating polynomial of 1 + x + x3 + x12 + x16.

I show a simple diagram of how one can implement the Scrambler within their OTSi/OTUk-a_A_So function design below in Figure 5.

Scrambler Function - OTSi/OTUk-a_A_Sk function

Figure 5, High-Level Block Diagram of the Frame Synchronous Scrambler

I discuss the Scrambler function and requirements in greater detail in another post.

Once the OTSi/OTUk-a_A_So function has scrambled this outbound OTUk data stream, it will transmit it to some Electrical-to-Optical conversion circuitry (which will convert this data stream into the Optical Format) for transmission.

Function Defects

This function does not declare any defect conditions.

Function Consequent Equations

This function does not have any Consequent Action (or Equations).

Pin Description of the OTSi/OTUk-a_A_S0 Function

Table 2 presents a list and description of each of the Input and Output pins of the OTSi/OTUk-a_A_So Function.

Table 2, Pin Description of the OTSi/OTUk-a_A_So Atomic Function

Signal NameTypeDescription
OTUk_CP Interface
CI_DInputOTUk Characteristic Information - Data Input:
The function user (upstream OTUk_TT_So function) is expected to apply the OTUk data-stream via this input. This OTUk data-stream will contain all of the following portions of the OTUk frame.
- OTUk SMOH (Section Monitoring Overhead) data
- All remaining OTUk payload data (e.g., the ODUk/OPUk data).

NOTE: This data will not include the FAS, MFAS nor FEC fields.

All data that the user supplies to this input should be synchronized with the CI_CK input clock signal.

NOTE: This OTUk data-stream should be unscrambled.
CI_CKInputOTUk Characteristic Information - Clock Input:
This clock signal will sample all data that the user supplies to the CI_D, CI_FS and CI_MFS inputs.

The OTSi/OTUk-a_A_So function will also use this clock signal as its base timing source.
CI_FSInputOTUk Characteristic Information - Frame Start Input:
The upstream OTUk_TT_Sk function will drive this input signal TRUE, coincident to whenever it is supplying the very first bit or byte (of a given OTUk frame) to the CI_D input.

The OTSi/OTUk-a_A_So function will insert the FAS field into the outbound OTUk data-stream coincident to whenever the user asserts this input signal.

The upstream OTUk_TT_So function is expected to assert this signal once for each OTUk frame period.
CI_MFSInputOTUk Characteristic Information - Multiframe Start Input:
The upstream OTUk_TT_So function will drive this input signal TRUE coincident to whenever it is supplying the very first bit or byte of a given OTUk superframe to the CI_D input.

The OTSi/OTUk-a_A_So function will set the MFAS byte to 0x00 coincident to whenever the user asserts this input signal.

The upstream OTUk_TT_So function is expected to assert this signal once for each OTUk superframe period, one once every 256 OTUk frame periods.
OTSi_AP Interface
AI_PLDOutputOTSi Adapted Information - OTSi Payload Output:
The OTSi/OTUk-a_A_So function takes all of the data (that the user supplies to the CI_D input pin), along with the FAS, MFAS and FEC data that it has also inserted into this OTUk data-stream. Finally, this function will scramble this data before it outputs all of this data via this output pin.

In summary, this signal will contain a full-blown OTUk data-stream (that consists of all of its framing fields and the FEC) and is also scrambled.

The system-designer will typically route this data-stream to cicuitry that will convert or modulate this dat into the optical format (for transmission over optical fiber).

Has Inflation got You Down? Our Price Discount Can Help You Fight Inflation and Help You to Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

For More Blog Posts on Optical Transport Networks, please CLICK on the Image Below.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...
Read More

OTUkV – Functionally Compliant OTU Frames

This post describes the differences between a Fully-Compliant OTUk frame and a Functionally-Compliant OTUkV frame.

What are OTUkV/Functionally-Compliant OTUk Frames?

There are two broad categories of OTUk Frames.

  • There are the Fully-Compliant OTUk Frames (which we will refer to as OTUk frames).
  • And there are the Functionally-Compliant OTUk Frames (which we will refer to as OTUkV frames).

To help show how the OTUkV frames differ from the OTUk frames, I will first discuss the Fully-Compliant OTUk frames.

Please note that you can find a much more in-depth discussion of the Fully-Compliant OTUk Frame here in the OTUk Post.

The Fully-Compliant OTUk Frame

There is only one type of Fully-Compliant OTUk frame.

The Fully-Compliant OTUk frame is a frame that entirely complies with all the ITU-T G.709 recommendations for an OTUk frame.

It has the exact field formats and field sizes/types that are specified within ITU-T G.709.  Figure 1 presents an illustration of the Fully-Compliant OTUk frame.

ITU-T G.709 Fully Compliant OTUk Frame

Figure 1, Illustration of the Fully-Compliant OTUk Frame

The OTUk Post already discusses and defines each of these OTUk Overhead fields.  Thus, we will not repeat that information in this post.

ITU-T G.709 states that the Fully-Compliant OTUk Frame should have all the following features/attributes.

  • The overall frame size should be a 4 Row by 4080 Byte Column Structure.
  • It contains an OTUk Overhead of 14 bytes that matches the Overhead fields described in the OTUk Post.
  • The frame contains the three rows by 14-byte column ODUk Overhead field that matches the Overhead fields described in the ODUk Post.
  • The OTUk frame contains a 4 row by 3808-byte OPUk field, along with a 4 row by 2-byte column OPUk overhead that matches the Overhead fields described in the OPUk Post.
  • It includes a 4 row by 256-byte column structure for FEC (Forward Error Correction) that we can compute using the Reed Solomon, RS(255,239) scheme.

Some industry people simply refer to this type of FEC as “GFEC” (because it complies with the ITU-T G.709 requirements for FEC).

NOTE:  We will refer to the Reed-Solomon FEC (as called out in ITU-T G.709) as “GFEC” throughout the rest of this post.

If the OTUk frame differs from these characteristics by even one item, then we cannot refer to this type of frame as being a Fully-Compliant OTUk frame.

We must refer to this type of frame as a Functionally Compliant OTUkV frame.

The Functionally-Compliant OTUk (OTUkV) Frame

In contrast to the Fully-Compliant OTUk frame, ITU-T G.709 identified six (6) variations of OTUkV frames.
These six variations are:

  • OTUkV frame with Alternative 7% FEC (also referred to as the OTUk-v frame)
  • OTUkV frame with Larger/Stronger FEC
  • OTUkV frame with Smaller FEC
  • OTUkV frame without FEC
  • OTUkV frame with Different Frame Structure and FEC Area
  • OTUkV frame with Different Frame Structure and No FEC Area

We will describe each of these variations of OTUkV frames below.

NOTE:  The reader should not consider this list of types of OTUkV frames to be an exhaustive list.

Other variations within these frames are possible (and still qualify at OTUkV frames).

OTUkV Frame with Alternative 7% FEC

This type of OTUkV frame is ALMOST the same as the Fully-Compliant OTUk frame.  It has the same set of fields (payload and overhead bytes).  It also has the same frame size (e.g., 4080-byte columns by four rows).

The only difference between this particular Functionally-Compliant OTUkV frame and the Fully-Compliant OTUk frame is how we calculate the FEC.

Figure 2 illustrates the field format for this particular OTUkV frame.

Functionally Compliant OTUkV Frame with Alternative 7 Percent FEC

Figure 2, Illustration of the OTUkV Frame with Alternative 7% FEC

Other “7% FECs” exists other than the Reed-Solomon FEC (or GFEC).

If an OTUk frame uses one of these alternative types of FECs, rather than the “GFEC,” then we need to refer to this frame as an OTUkV Functionally Compliant frame.

NOTE:  Some OTN-related documentation refers to these functionally-compliant OTUk frames as OTUk-v frames.

OTUkV frame with Larger/Stronger FEC

Some applications need the use of a Stronger FEC.

These are applications in which the system design requires a much larger NCG (Net Coding Gain).

Long-Haul applications (where there are long fiber spans between 3R regenerators) are examples of such applications.

These applications will need a more robust FEC, which (in turn) will need a larger FEC area within the OTUkV frame.

Figure 3 presents an illustration of this type of OTUkV frame.

Functionally Compliant OTUkV Frame with Larger FEC

Figure 3, Illustration of the OTUkV Frame with Larger/Stronger FEC

Since we are using a larger FEC (and larger FEC area), this type of OTUkV frame will be larger than that for the Fully-Compliant OTUk frame.

This type of OTUkV frame will have 4080 + X byte columns and 4-byte rows.

NOTE:  In most cases, for a given value of k (in OTUk/kV), the Frame Repetition rate will be the same for all OTUk/kV-type frames.

For example, if you look at the OTUk post, you will see that the Frame Repetition Rate for an OTU2 signal is 82,028 frames/second.

We can state that this also means that the Frame Repetition rate for an OTU2V frame (a different size than that for the OTU2 frame) will also have this same frame repetition rate.

This means that the OTUkV frame, which is larger than its OTUk counterparts, will need to operate at a higher bit rate to transmit these frames than that to transmit the OTUk frames.

Similarly, OTUkV frames that are smaller in size than their OTUk counterparts will need to operate at a lower bit rate to transmit these frames than that to transmit the OTUk frames.

OTUkV frame with Smaller FEC

There will be applications where we will not need an FEC as large as the 7% GFEC.  In these applications, we can get away with using smaller FECs.  Figure 4 illustrates an OTUkV frame with this kind of FEC.

Functionally Compliant OTUkV Frame with Smaller FEC

Figure 4, Illustration of the OTUkV Frame with Smaller FEC

You can see that Figure 4 shows that this type of OTUkV frame is of the same frame size as that for the Fully-Compliant OTUk frame.

In this case, the actual FEC takes up less “real estate” than that for the GFEC.  However, the unused portions of the FEC field are filled with an All-Zeros pattern to “pad out” the remaining FEC byte fields.

OTUkV frame without FEC

There will be applications that will require OTUkV frames without FEC.  Some of these applications will typically be very low-latency applications (e.g., for Enterprise Applications such as Real-Time Stock Quotes, etc.).

FEC coding and decoding all require some number crunching that does consume a finite amount of time and increases latency.

Figure 5 presents an illustration of this type of OTUkV frame.

Functionally Compliant OTUkV Frame with NO FEC

Figure 5, Illustration of the OTUkV frame without FEC

NOTE:  Some applications will implement the “No-FEC” OTUkV frame by filling the entire FEC field (as drawn in Figure 1) with an all-zero pattern.

In this case, the “No-FEC OTUkV frame” would be the same size as the Fully-Compliant OTUk frame.

Figure 6 presents an illustration of this example OTUkV frame.

Fully Compliant OTUk Frame with All Zeros FEC

 

Figure 6, Illustration of the No-FEC OTUkV frame with the entire FEC field set to an All-Zeros pattern

OTUkV frame with Different Frame Structure and FEC Area

OTUkV frames of completely different Frame Structure (from the Fully-Compliant OTUk frame) can be (and are) sent out onto the OTN network.

Before the days of OTUCn, some people used these types of frames to (for example) support “200Gbps or More” Operations.

In this case, an entire OTU4/4V frame (within a given OTU4 signal) could be mapped into one of these structures.  Afterward, we could bit-interleave this structure with other structures (from another OTU4 signal) to achieve “200Gbps” transmission.

I will elaborate on the actual mechanics behind this scheme in another post.

Figure 7 illustrates the With-FEC version of this “Different Structure” OTUkV frame.

OTUkV Structure with Different Frame Structure and FEC

Figure 7, Illustration of the OTUkV Frame with Different Frame Structure and FEC Area

OTUkV frame with Different Frame Structure and No FEC Area

This type of frame would have a similar use to that in the previous section.

The only difference between this frame and that of the previous frame is that this particular frame does not contain an FEC.

Again, a possible application (for this type of frame) would be to support 200Gbps (or higher rate) applications.

In this case, we would map an OTU4/4V frame into this structure.

Afterward, we would combine this signal with another by bit-wise multiplexing this data with another such signal (from another OTU4/4V signal) when transmitting this data to the line.

In this case, we might not need the FEC because the OTU4/4V frames (carried within this structure) might already have their own FEC.

Figure 8 presents an illustration of this type of OTUkV frame.

OTUkV Structure with Different Frame Structure and No FEC

Figure 8, Illustration of the OTUkV Frame with Different Frame Structure and No FEC Area

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...
Read More

The OTU (Optical Transport Unit) Frame

This post defines and describes the OTU (Optical Transport Unit) Frame that is used in OTN (Optical Transport Networks).

What is the OTU Frame/OTUk Frame?

An OTU (Optical Transport Unit) frame is a data structure that an OTN Terminal (or Source STE) will use to transport its data to the outside world.

This post will call any entity that generates and transmits OTUk frames a Source STE (Section Terminating Equipment).  Likewise, we will call any entity that receives, processes, and terminates OTUk frames a Sink STE.  

In other words, as the Source STE accepts OPU/ODU frames to create an OTUk frame, it will encapsulate these OPU/ODU frames into an OTU frame by “tacking” on the OTUk overhead. 

Additionally, the Source STE will pre-condition each OTUk frame for transport over Optical Fiber by computing and appending an FEC (Forward Error Correction) field at the back end of the OTU frame and scrambling much of the OTUk frame data before converting this data into the optical domain and sending it out on Optical Fiber.  

Likewise, the OTU frame is a data structure that an OTN Terminal (or Sink STE) will accept as it receives data from the outside world.

In this case, the OTN Terminal (e.g., Sink STE) will perform the reverse functions as the Source STE.  

It will receive an optical signal from the remote STE and convert this data back into an electrical format.  Afterward, it will descramble this incoming OTUk data stream, decode the FEC field, and correct most symbol errors in the process.  

Finally, the Sink STE will terminate the OTUk data stream by extracting out the OPU/ODU frames and routing this data to downstream circuitry.  

To be clear, What do We Mean by Frame?

OTN, just like many other Networking Standards, uses framing to organize the data it transmits and receives.

Framing is a Data Link Layer function.  A transmitting terminal will organize a group of data bits into a specific data structure (called a “frame”) before transmitting it across a link.

Please see the post about the Data Link Layer for more information about the concept of Framing.

Please note that we are not talking about this kind of frame.

For OTN applications, we only transmit data that we have encapsulated into the form of an OTU frame out onto optical fiber.

OPUk and ODUk signals may be handled and processed internally (within a network element or an integrated circuit).

But we NEVER transmit OPUk and ODUk data onto the network (over optical fiber) unless we first encapsulate these signals into an OTUk frame and pre-condition this data for transport over Optical Fiber.

OTN Section and Path Terminating Equipment

In the OTN arena, we will often state that OTN Section Terminating Equipment (STE) is the entity that is responsible for transmitting and receiving OTUk frames.

We will also state that OTN Path Terminating Equipment (PTE) handles and processes ODUk frames.

Please see the posts for OTN Section Terminating Equipment (STE)and OTN Path Terminating Equipment (PTE) to understand the differences between these two types of equipment.

The OTUk Frame Format

Figure 1 illustrates the format for the standard ITU-T G.709-compliant OTU Frame.

OTUk Frame - Byte Format

Figure 1, Illustration of the Format of the ITU-T G.709-Compliant OTU Frame

This figure shows that an OTU Frame is a 4-Byte-Row by 4080-Byte-Column Structure.  Hence, each OTU Frame consists of (4 x 4080 =)16,320 bytes.

Please note that all OTU Frames (whether an OTU1, OTU2, OTU3, or OTU4 frame) are all the same size; therefore, each frame has exactly 16,320 bytes.

NOTE:  Since each of these OTU frames are the same size (regardless of whether we are talking about an OTU1, OTU2, OTU3, or OTU4), we will, from here on, refer to these OTU frames as OTUk frames.

The Fields within an OTUk Frame

Let’s talk about the various fields within an OTUk frame.

Some of the fields in the OTUk frame have the following labels.

  • FAS
  • MFAS
  • OTUk OH
  • FEC
  • ODUk Frame

I will briefly define each of these bytes below.

FAS – Framing Alignment Signal field

The Framing Alignment Signal field occupies the first 6 bytes within an OTUk Frame.

The first three bytes (which we sometimes call the OA1 bytes) each have a fixed value of 0xF6.

The remaining three bytes (in the FAS field), which we sometimes call the OA2 bytes, each have a fixed value of 0x28.

The purpose of the FAS bytes is to provide the remote receiving OTN terminal (e.g., the Sink STE) with this fixed pattern so that it will “know” that it is receiving the first bytes of a new OTUk frame.

The Sink STE will parse through its incoming OTUk frame data stream.  As it does this, it will search for the occurrence of three consecutive bytes (each with the value 0xF6) followed by another set of three successive bytes (each with the value 0x28).

The Sink STE will rely on these FAS bytes to acquire and maintain framing alignment/synchronization with the incoming stream of OTUk frames.

If the Sink STE repeatedly fails to acquire and maintain framing alignment/synchronization with this incoming stream of OTUk frames, it will declare the dLOF (Loss of Frame) defect condition.  

MFAS – Multi-Frame Alignment Signal byte

The MFAS byte occupies the 7th byte within an OTUk frame and “resides” immediately after the FAS bytes.

Unlike the FAS bytes, the MFAS byte’s value is not fixed, as I will explain here.  

A given Source STE will transmit OTUk frames in groups of Multi-frames.

Each of these multi-frames consists of 256 consecutive OTUk frames.

Whenever a Source STE transmits the first OTUk frame (of a given Multi-frame), it will designate this particular frame as the first frame (of this multi-frame) by setting its MFAS byte field to 0x00.

When the Source STE transmits the next OTUk frame, it will set the MFAS byte (within that particular OTUk frame) to 0x01, and so on.

As the Source STE transmits each OTUk frame, it will increment the value assigned to the MFAS byte field until it reaches the value 0xFF (or 255 in decimal format).

The Source STE will then start over with transmitting a new multi-frame and set the MFAS of this next OTUk frame to 0x00, and the process repeats indefinitely.

The MFAS is a significant byte for a receiving OTN terminal (e.g., Sink STE) to keep track of because other data (such as the TTI – Trail Trace Identifier message – that is transmitted via some of the additional overhead bytes across multiple OTUk frames).

The Source STE will align the transmission of these particular messages (e.g., the SM-TTI messages, PM-TTI messages, PSI Messages, etc.) with the MFAS byte as it transports these messages via the OTUk data stream.

Please see the relevant posts on SM-TTI (Section Monitoring – Trail Trace Identifier) Messages, PM-TTI (Path Monitoring – Trail Trace Identifier) Messages, and PSI (Payload Structure Identifier) Messages to learn more about these types of messages.  

ODUk Frame

The ODUk Frame “portion” of the OTUk frame is all the remaining data (which resides within the OTUk frame) that is not considered an OTUk Overhead field.  This includes all bytes within the ODU (Optical Data Unit) and, in turn, OPU (Optical Payload Unit) within the OTUk frame.  Please see the posts for ODUk and OPUk to learn more about those parts of the OTUk frame.

FEC – Forward Error Correction

ITU-T G.709 specifies that OTUk frames should include an FEC (Forward Error Correction) field that contains the Reed-Solomon RS (255,239) FEC codes.

NOTE:  I discuss the RS(255,239) FEC code in detail in Lesson 9, within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

The FEC field permits a Sink STE to detect and correct many symbol (or byte) errors that may have occurred during transmission.

ITU-T G.709 indicates that using FEC is optional for OTU1, OTU2, and OTU3 applications.  

However, the use of FEC is mandatory for OTU4 applications.  

Please see the OTUk FEC discussion within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!  for more information about this field.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

The Rest of OTUk OH (Overhead) fields

The remaining OTUk OH fields consist of the following three fields for a total of seven (7) bytes:

  • SM Field
  • GCC0 Field
  • OSMC (OTN Synchronizing Messaging Channel) Field
  • RES (Reserved) Field

We will briefly describe each of these fields below.

SM (Section Monitoring) Field (3 bytes)

Figure 2 shows the byte format for the Section Monitoring or SM Field.

OTU - SM (Section Monitoring) Field, TTI Byte, BIP-8 Byte, SM Byte

Figure 2, Byte-Format of the SM (Section Monitoring) Field

This figure shows that the SM Field consists of the following three bytes:

  • TTI – Trail Trace Identifier Byte
  • BIP-8 Byte
  • SM Byte

Below, we will describe each of the bytes (within the SM field).  We also discuss these fields in much greater detail in their respective posts.

TTI – Trail Trace Identifier Byte

This byte-field carries the 64-byte Section Monitoring Trail-Trace Identifier message.  Since there is only one TTI byte within each OTUk frame, the OTN Transmitter (or Source STE) will transmit 64 OTUk frames to send the entire 64-byte Trail Trace Identifier message.

Please see the Section Monitor-Trail Trace Identifier post to learn how we use this identifier in an OTN system.

BIP-8 (Section Monitoring BIP-8) Byte

The Source STE will perform a BIP-8 calculation over the entire OPUk frame within its corresponding OTUk frame.

Afterward, the Source STE will insert the results of this BIP-8 calculation into the SM-BIP-8 byte field of the outbound OTUk frame two frame periods later.

Finally, the remote Sink STE will use this BIP-8 calculation to check for bit errors during transmission.

Please see the Section Monitoring BIP-8 post for more information about how we compute and use this byte field in an OTN system.

SM (Section Monitoring) Byte

Figure 3 presents the bit format for the Section Monitoring Byte (not to be confused with the 3-byte SM field).

OTU Frame - Section Monitoring Byte Format - Optical Transport Networks

Figure 3, Bit Format of the Section Monitoring Byte

This figure shows that the SM Byte consists of the following bit fields:

  • BEI/BIAE (4 bits)
  • BDI (1 bit)
  • IAE (1 bit)
  • RES – Reserved (2 bits)

We will briefly describe each of these bit-fields below.

BEI/BIAE – Section Monitoring – Backward Error Indicator (BEI) or Backward Incoming Alignment Error (BIAE) – (4 bits)

The purpose of the BEI/BIAE nibble-field is two-fold.

  • To permit the Source STE to provide the remote Sink STE (at the far-end) with feedback on the number of SM-BIP-8 errors that the near-end (local) Sink STE is detecting within its incoming OTUk data stream.
    • The Source STE will set the BEI/BIAE nibble-field (within each outbound OTUk frame) to the SM-BEI (Backward Error Indicator) value.  
  • And to permit the Source STE to alert the remote Sink STE (again, at the far-end) that the near-end (local) Sink STE is declaring the dIAE defect condition.
    • The Source STE will accomplish this by setting the BEI/BIAE nibble-field to the value of “1011”, which carries the BIAE (Backward Input Alignment Error) Indicator.  

Table 1 presents the range of values that the Source STE can set the BEI/BIAE Nibble-field, within its outbound OTUk frames, for each of the conditions mentioned above. 

Table 1, How to Interpret the Section Monitoring BEI/BIAE bit-fields

OTUk SM_BEI/BIAE Nibble-ValueSink STE declaring the dIAE Defect?Number of SM-BIP-8 Errors DetectedComments
0000NO0Good Condition
0001NO1BIP-8 Error
0010NO2BIP-8 Errors
0011NO3BIP-8 Errors
0100NO4BIP-8 Errors
0101NO5BIP-8 Errors
0110NO6BIP-8 Errors
0111NO7BIP-8 Errors
1000NO8BIP-8 Errors
1001, 1010NO0Good Condition
1011YES0BIAE Indicator
1100 to 1111NO0Good Condition

Please see the Section Monitoring Error/Defect post to learn more about these defect and error conditions.

BDI – Section Monitoring – Backward Defect Indicator Bit Field

The purpose of the BDI bit-field is to permit the Source STE to alert the remote (far-end) Network Element that the local (near-end) Sink STE is declaring a service-affecting defect.  

This Source STE will set this bit-field to “0” or “1” depending upon whether the local (near-end) Sink STE is declaring a service-affecting defect condition (at the OTUk-layer), as I describe below.

0 – The Source STE will set the BDI bit-field to “0” if the near-end Sink STE is NOT declaring a service-affecting defect condition.

1 – The Source STE will set the BDI bit-field to “1” if the near-end Sink STE is currently declaring a service-affecting defect condition.

Please see the OTUk-BDI post to learn more about the BDI defect condition.

IAE – Section Monitoring Incoming Alignment Error Bit-Field

The Source STE will set this bit-field to “0” or “1” depending upon whether the upstream circuitry detects a frame-slip event within an ODU signal that we are ultimately mapping into this particular OTUk data stream (that this Source STE is transmitting downstream).

0 – Indicates that upstream circuitry is NOT detecting any frame-slip events (within the ODU signal we are mapping into this particular OTUk signal).   The Source STE will set the IAE bit-field to “0” (within its outbound OTU data-stream) to denote this good condition.

1 – Indicates that upstream circuitry is currently detecting a frame-slip event (within the ODU signal we are mapping into this particular OTUk signal).  The Source STE will set the IAE bit-field to “1” (within its outbound OTU data-stream) to denote this abnormal condition.

I present detailed information on the IAE bit-field within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!.

GCC0 – General Communication Channel # 0 – (2 bytes)

The GCC0 is a general communications channel for proprietary communication to the System Designer/Manufacturer.

This channel is similar to the DCC (Data Communication Channels) in SONET/SDH.

Please see the GCC0 post for more information about how the System Designer/Manufacturer can use this field.

OSMC – OTN Synchronization Messaging Channel  – 1 byte

The Network User can use the OSMC channel to transport SSM (Synchronization Status Messages) or PTP (Precision Time Protocol) messages throughout the OTN.

Please see the OSMC post for more information about how the System Designer/Manufacturer can use this field.

RES – Reserved (or Undefined) (1 byte)

OTUk Frame Repetition Rates and Bit Rates

Since all speeds (or types) of OTUk signals use the same frame size, the reason that (for example) an OTU2 runs at a faster bit rate than does an OTU1 is that the frame repetition rate for an OTU2 is higher (e.g., more rapid) than that for an OTU1.

Table 2 presents the OTUk frame period and bit rate for each type of the OTUk signal.

Table 2, Frame Periods and Bit-Rate for each kind of OTUk signal

OTUk Bit Rate and OTUk Frame Period

NOTES:

  1. This post has defined the Fully Compliant OTUk frames.   It does not address the functionally standardized OTUk frames (such as the OTUkV or OTUk-v).  Please see the posts for the OTUkV and OTUk-v frames for more information on these types of frames.
  2. This post does not discuss the new OTUCn types of OTN signals.  Please see the OTUCn post for more information on these higher-speed signals.

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!

(DISCOUNT OFFERED for a Short Time ONLY!!)

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...
Read More