OTN – Lesson 9 – Video 4 – OTSiG/OTUk_A_Sk Function/FEC Decoding/dLOM Defect

This post presents the 4th of 11 Videos that covers training on Performance Monitoring at the OTU-Layer. This post focuses on the Sink Direction OTU-Layer Atomic Functions.

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

This blog post contains a video that continues our discussion of the Sink (or Receive) Direction OTU-Layer Atomic Functions (circuitry).  

This Video serves as Part 2 of the Sink Direction/OTU-Layer Training Videos.  It is also the 4th out of 11 Videos within Lesson 9.  

This Video discusses the following topics (still within the OTSiG/OTUk_A_Sk Atomic Function).

  • FEC Decoding, and
  • The Multi-Frame Alignment and dLOM (Loss of Multi-Frame) defect block.  

In this case, we describe how the OTSiG/OTUk_A_Sk function declares and clears the dLOM (Loss of Multi-Frame) defect condition by walking through and discussing the dLOM/In-Multi-Frame Alignment State Machine diagram.  

I wrap up this Video by discussing why clearing the dLOM defect condition is essential for handling/processing OTN signals.  

Continue reading “OTN – Lesson 9 – Video 4 – OTSiG/OTUk_A_Sk Function/FEC Decoding/dLOM Defect”

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 OTSi/OTUk_A_Sk Function?

This blog post briefly describes the OTSi/OTUk_A_Sk (OTSi to OTUk Adaptation Sink) Atomic Function. This post also describes how this atomic function declares and clears the dLOF, dLOM, and dAIS defects.


What is the OTSi/OTUk_A_Sk Atomic Function?

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

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

We discuss the OTSi/OTUk_A_Sk Atomic Function in detail in Lesson 9, within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

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_Sk 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”.

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

Likewise, in another post, we will now call (what we used to call the OCh/OTUk_A_So function) the OTSi/OTUk_A_So 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.

The OTSi/OTUk_A_Sk Function

The OTSi/OTUk_A_Sk function is any circuit that takes an OTSi electrical signal and converts this data back into the OTUk signal.

More specifically, the System-Designer will apply an OTSi signal (which will be a fully-framed and scrambled OTUk electrical signal that often includes Forward-Error-Correction) to the OTSi_AP input interface.

This function will convert this signal into OTUk data, clock, frame start, and multi-frame start signals.

This function will also decode the Forward-Error-Correction field (if available) and output these signals to downstream circuitry (such as the OTUk_TT_Sk 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_Sk function for OTU1 and OTU2 applications.  We will usually use the OTSiG/OTUk_A_Sk atomic function for OTU3 and OTU4 applications.

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

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

OTSi/OTUk-a_A_So Simple Function Drawing

Figure 1, Simple Illustration of the OTSi/OTUk_A_Sk function

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

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

Function NameDescriptionComments
OTSi/OTUk-a_A_SkOTSi to OTUk Adaptation Sink Function with ITU-T G.709 Standard FECCan be used for OTU1 through OTU4 applications.
OTSi/OTUk-b_A_SkOTSi to OTUk Adaptation Sink Function with No FECCannot be used for OTU4 applications
OTSi/OTUk-v_A_SkOTSi to OTUk Adaptation Sink Function with Vendor-Specific FECCan be used for OTU1 through OTU4 applications.

Table 1 shows that the OTSi/OTUk-a_A_Sk and the OTSi/OTUk-v_A_Sk functions will compute and decode some sort of FEC field within the backend of each incoming OTUk frame.

However, this table also shows that the OTSi/OTUk-b_A_Sk version does not support FEC decoding.

Therefore, ITU-T G.798 states that one can use the OTSi/OTUk-a_A_Sk and OTSi/OTUk-v_A_Sk functions for OTU1 through OTU4 applications.  Further, the standard recommends that the user NOT use the OTSi/OTUk-b_A_Sk function for OTU4 applications.

Network Terminals operating at the OTU4 rate are required to use Forward-Error-Correction.

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

Corporate Discounts Available!!!

What Version (of the OTSi/OTUk_A_Sk function) will we Discuss Throughout this Post?

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

The OTSi/OTUk-b_A_Sk and OTSi/OTUk-v_A_Sk atomic functions do everything that the OTSi/OTUk-a_A_So does, except that the -b version does NO FEC Decoding and the -v version does FEC Decoding differently than what I describe here.

So What All Does this Atomic Function Do?

The OTSi/OTUk-a_A_Sk function will accept an OTSi data stream from the upstream Optical-to-Electrical Conversion circuitry.  This function will perform the following tasks on this incoming data stream.

  • Descrambling – It will descramble this incoming data stream.
  • FEC Decoding – The function will decode the FEC field (within the backend of each incoming OTUk frame) and detect and correct most symbol errors within this data stream.
  • Extract the Frame-Start and Multi-Frame Start signals from this incoming data stream.
  • Detect and Flag the following service-affecting defect conditions
  • Assert the CI_SSF (Server Signal Fail Indicator) output signal (towards the downstream OTUk_TT_Sk function) anytime it declares any service-affecting defect conditions.
  • Output the remaining OTUk data stream, the OTUk clock signal, the Frame-Start, and Multi-Frame Start signals to downstream circuitry (e.g., typically the OTUk_TT_Sk atomic function).

Figure 2 illustrates a Unidirectional Connection where the OTSi/OTUk-a_A_Sk function “fits in” a system.

OTSi/OTUk-a_A_Sk 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_Sk function is highlighted. 

Functional Description of this Atomic Function

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

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

OTSi/OTUk-a_A_Sk Functional Block Diagram

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

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

I will briefly discuss each of these functional blocks below.

The Clock Recovery and dLOS (Loss of Signal Defect) Detection Blocks

The Clock Recovery block is responsible for recovering the clock signal and data content within the incoming OTSi signal via the AI_PLD input pin.

To that end, I illustrate the OTSi/OTUk-a_A_Sk Functional Block Diagram with the Clock Recovery and dLOS Detection Blocks highlighted below in Figure 4.

OTSi/OTUk-a_A_Sk Functional Block Diagram - dLOS Detection Block Highlighted

Figure 4, Illustration of the OTSi/OTUk-a_A_Sk Functional Block Diagram, with the Clock Recovery and dLOS Detection Blocks highlighted. 

Since the OTSi/OTUk-a_A_So atomic function (within the remote STE) should have scrambled this data stream, there should always be good timing content (or transitions) within the incoming OTSi signal so that this Clock Recovery block can acquire and extract out both a recovered clock signal and data-stream.

Suppose the Clock Recovery and dLOS Detection blocks determine a lengthy absence in signal transitions (within the incoming OTSi data-stream).  It will declare the dLOS-P (Loss of Signal-Path) defect condition in that case.

Please check out the dLOS blog post for more information about the dLOS-P defect condition.

The OTSi/OTUk-a_A_Sk function will route this recovered clock and data signal to the dAIS Detector and Frame Alignment blocks for further processing.

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

Discounts Available for a Short Time!!!

The dAIS (Alarm Indication State Defect) Detector Block

As the newly recovered clock and data signal travel to the Frame Alignment block, the dAIS Detector block will also parse through this data stream to see if it should declare or clear the dAIS (Alarm Indication Signal Defect) condition or not.

To make things more convenient, I present an illustration of the OTSi/OTUk-a_A_Sk Functional Block Diagram, with the AIS Detector block highlighted below in Figure 5.

OTSi/OTUk-a_A_Sk Functional Block Diagram with dAIS Detection Circuitry Highlighted

Figure 5, Illustration of the OTSi/OTUk-a_A_Sk Functional Block Diagram, with the AIS Detector block highlighted. 

In this case, the dAIS Detector block will check to see if the incoming data stream matches an OTUk-AIS maintenance signal.

ITU-T G.709 further states that the OTUk-AIS maintenance signal is an unframed PN-11 repeating pattern.

The standard defines the PN-11 sequence by the generating polynomial of 1 + x9 + x11.

Please see the blog post on the OTUk-AIS Maintenance signal for more information about this type of signal.

Additionally, please see the dAIS post for more information on how the AIS Detection circuit declares and clears the dAIS defect condition.

The Frame Alignment and dLOF (Loss of Frame Defect) Detection Blocks

As long as the dAIS Detector block is NOT declaring the dAIS defect condition, then the Frame Alignment block will process the incoming recovered block and data stream.

To make things more convenient for you, I present an illustration of the OTSi/OTUk-a_A_Sk Functional Block Diagram.  This block diagram highlights the Frame Alignment and dLOF Detection below in Figure 6.

OTSi/OTUk-a_A_Sk Functional Block Diagram - dLOF Detection Circuitry

Figure 6, Illustration of the OTSi/OTUk-a_A_Sk Functional Block Diagram with the Frame Alignment and dLOF Detection circuitry highlighted.

The incoming recovered data stream should be a full, scrambled OTUk frame.  However, the FAS field (e.g., the three OA1 and OA2 byte fields) should NOT be scrambled.

The Frame Alignment block will parse through the FAS fields within the incoming OTUk data stream.  This block and the dLOF (Loss of Frame) Detection Block will declare and clear the dLOF defect as appropriate.

Please see the blog post on the dLOF defect for more information about how the Frame Alignment and dLOF Detection blocks declare and clear the dLOF defect condition.

Descrambler Block

In the OTSi/OTUk-a_A_So  blog post, we mentioned that the OTSi/OTUk-a_A_So function would scramble the content of each OTUk frame.

That function will scramble all bytes (within each OTUk frame) except for the FAS fields.  This function will even scramble the MFAS field as well.

The purpose of the Descrambler block is to restore the content of each OTUk frame to its original state before being scrambled at the remote STE.

To that end, I illustrate the OTSi/OTUk-a_A_Sk Functional Block Diagram with the Descrambler block highlighted below in Figure 7.

OTSi/OTUk-a_A_Sk Functional Block Diagram with Descrambler Circuit Highlighted

Figure 7, Illustration of the OTSi/OTUk-a_A_Sk Functional Block Diagram, with the Descrambler block highlighted.  

In the OTSi/OTUk-a_A_So function, we scrambled the contents of each OTUk frame, using the polynomial generating equation of 1 + x + x3 + x12 + x16.

Therefore, the Descrambler block (within this function) will descramble the incoming OTUk data-stream (again) using the polynomial generating equation of 1 + x + x3 + x12 + x16.

I show a simple diagram of how one can implement the Descrambler within their OTSi/OTUk-a_A_Sk function design below in Figure 8.

OTUk Descrambler Block within the OTSi/OTUk-a_A_Sk Function

Figure 8, High-Level Block Diagram of the Frame Synchronous Descrambler

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

Next, the OTUk signal will proceed to the FEC Decoder block for further processing.

FEC (Forward-Error-Correction) Decoder Block

The OTSi/OTUk-a_A_So function (at the remote STE) is responsible for performing FEC (Forward Error Correction) Encoding.

This means that this function computed a FEC Code and inserted that code into a 4-row x 128-byte column field at the backend of each OTUk frame, as shown below in Figure 9.

OTUk Frame with FEC Field highlighted

Figure 9, Illustration of the OTUk Frame Format with the FEC Field Highlighted

The purpose of the FEC Decoder (within the OTSi/OTUk-a_A_Sk function) is to parse through the incoming OTUk data stream and (by using the contents of the FEC-field) detect and correct most symbols errors within this data stream.

The FEC Decoder block will tally any occurrences of Symbol errors (within the incoming OTUk data stream).  It will report this information to System Management via the MI_pFECcorrErr output (via the OTSi/OTUk-a_A_Sk_MP Interface).

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

Multi-Frame Alignment and dLOM (Loss of Multi-Frame Defect) Detection Blocks

Once the incoming OTUk data stream passes through the FEC Decoder block, the OTSi/OTUk-a_A_Sk function will route this signal to the Multi-Frame Alignment and dLOM Detection blocks.

The Multi-Frame Alignment block will parse through and check the contents of the MFAS field within the incoming OTUk data stream.  The Multi-Frame Alignment block will check the contents of this data stream to see if it (and the dLOM Detection Block) should declare or clear the dLOM defect condition.

Please see the blog post on the dLOM Defect for more information on how the Multi-Frame Alignment block will declare and clear the dLOM defect condition.

Removal of the FAS, MFAS, and FEC Fields from the incoming OTUk Data-stream

The Frame-Alignment block will drive the CI_FS (Frame-Start) output of the OTUk_CP Interface, HIGH for one CI_CK (Clock Signal) period, each time it detects the FAS field within its incoming OTUk data-stream.

Likewise, the Multi-Frame Alignment block will drive the CI_MFS (Multi-Frame Start) output of the OTUk_CP Interface, HIGH, for one CI_CK (Clock Signal) period each time it receives an MFAS byte with the value of 0x00.

The Frame-Alignment and Multi-Frame Alignment block will also remove the FAS and MFAS fields from the OTUk data stream (before it outputs this data stream via the CI_D output of the OTUk_CP Interface).

From this point on, the CI_FS and CI_MFS signals will now carry the framing and multi-framing alignment information downstream toward the OTUk_TT_Sk atomic function.

The FEC Decoder block will also remove the contents of the FEC field from the OTUk data stream before it outputs this data via the CI_D output pin.

Consequent Actions Block

In most cases, the Consequent Actions block will consist of digital logic circuitry that will assert the CI_SSF (Server Signal Fail) Output (of the OTUk_CP Interface) anytime the OTSi/OTUk-a_A_Sk function declares any of the following defect conditions.

Consequent Equation

ITU-T G.798 has the following Consequent Equation for the OTSi/OTUk_A_Sk function.

aSSF ⇐ dLOS-P or dAIS or dLOF or AI_TSF-P or dLOM

This Consequent Equation states that the OTSi/OTUk_A_Sk function MUST set aSSF to “1” (or drive the CI_SSF output pin to HIGH) if any of the following conditions are true:

NOTE:  Whenever this function asserts the CI_SSF output signal, it also asserts the CI_SSF input to the downstream OTUk_TT_Sk function.

Defect Correlation

If you wish to learn more about Defect Correlation and how you should interpret it, please see the Defect Correlation Post.

ITU-T G.798 specifies the following correlation equations for each OTSi/OTUk-a_A_Sk function-related defect.

  • cLOS-P ⇐ dLOS-P and (NOT AI_TSF-P)
  • cLOF ⇐ dLOF and (NOT dLOS-P) and (NOT dAIS) and (NOT AI_TSF-P)
  • cLOM ⇐ dLOM and (NOT dLOS-P) and (NOT dLOF) and (NOT dAIS) and (NOT AI_TSF-P)

I will briefly explain what each of these equations means below.

cLOS-P ⇐ dLOS-P and (NOT AI_TSF-P)

This equation means that the OTSi/OTUk-a_A_Sk function will ONLY declare the dLOS defect (and assert the cLOS-P output pin) if:

  • The Clock Recovery and LOS Detection circuitry is declaring the dLOS-P defect condition, and
  • The upstream circuitry is NOT asserting the AI_TSF-P input of this function.

In other words, the OTSi/OTUk-a_A_Sk function should only declare the dLOS defect (and assert the cLOS-P output pin) if it is internally declaring the dLOS-P defect condition.

cLOF ⇐ dLOF and (NOT dLOS-P) and (NOT dAIS) and (NOT AI_TSF-P)

This equation means that the OTSi/OTUk-a_A_Sk function will ONLY declare the dLOF defect (and assert the cLOF output pin) if:

  • The Frame Alignment and dLOF Detection circuitry declare the dLOF defect condition, and
  • The Optical upstream circuitry is NOT asserting the AI_TSF-P input of this function, and
  • The Clock Recovery and dLOS Detection circuitry is NOT currently declaring the dLOS-P defect condition, and
  • The dAIS Detection circuitry is NOT also declaring the dAIS defect condition.

In other words, the OTSi/OTUk-a_A_Sk function should only declare the dLOF defect (and assert the cLOF output pin) if it internally declares the dLOF defect condition.

cLOM ⇐ dLOM and (NOT dLOS-P) and (NOT dAIS) and (NOT dLOF) and (NOT AI_TSF-P)

This equation means that the OTSi/OTUk-a_A_Sk function will ONLY declare the dLOM defect (and assert the cLOM output pin) if:

  • The Multi-Frame Alignment and dLOM Detection circuitry declare the dLOM defect condition, and
  • The Optical upstream circuitry is NOT asserting the AI_TSF-P input of this function, and
  • The Clock Recovery and dLOS Circuitry is NOT currently declaring the dLOS-P defect condition, and
  • The dAIS Detection circuitry is NOT also declaring the dAIS defect condition,
  • The Frame Alignment and dLOF Detection circuitry are not currently declaring the dLOF defect condition.

Performance Monitoring

ITU-T G.798 requires that the OTSi/OTUk-a_A_Sk or OTSi/OTUk-v_A_Sk Functions tally and report the following Performance Monitoring parameter to System Management:

pFECcorrErr ⇐ ∑nFECcorrErr

In other words, the OTSi/OTUk-a_A_Sk or OTSi/OTUk-v_A_Sk functions are expected to tally and report each instant that the FEC Decoder block corrects an errored symbol within the incoming OTUk data stream.

Pin Description

I list the Input/Output Pin Description for the OTSi/OTUk-a_A_Sk Atomic Function below in Table 2.

Table 2, Pin Description for the OTSi/OTUk-a_A_Sk Atomic Function

Signal NameTypeDescription
OTSi_AP Interface
AI_PLDInputOTUk Adaptation Information - OTUk Payload Input:
The user is expected to apply a fully-framed and scrambled OTUk signal (with FEC) to this input port.

NOTE: In most cases, this data will be received data that has just been converted back into the electrical format (from the optical format).

The OTSi/OTUk-a_A_Sk function will accept and descramble this data and extract out all of the following data from this signal.
- FEC - It will decode the FEC and it will correct most symbol errors that this function detects within this incoming data stream.
- FAS - The Framing Alignment Signal. The Framing Alignment signal information will be output via the CI_FS output of this function.
- MFAS - The Multiframe Alignment Signal. The Multiframe Alignment signal information will be output via the CI_MFS output of this function.
- OTUk Data - The content of the rest of the unscrambled OTUk data-stream. This remaining OTUk data-stream will be output via the CI_D output of this function.
- OTUk Clock signal. The resulting OTUk clock signal will be output via the CI_CK output of this function.
AI_TSF-PInputAdapted Information - Trail Signal Fail - Path:
This signal indicates whether the upstream circuitry is declaring a service-affecting defect condition (within the signal path) with the data that is being applied to the AI_PLD input. This signal has (essentially) the same meaning as AIS.

If this signal is TRUE, then the OTSi/OTUk-a_A_Sk function will automatically set the CI_SSF output TRUE.
AI_TSF-OInputAdapted Information - Trail Signal Fail - Overhead:
This signal indicates whether upstream circuitry is declaring a service-affecting defect condition within the signal overhead.

NOTE: This signal does not reflect the health of the signal-path.
OTUk_CP Interface
CI_DOutputOTUk Characteristic Information - Data Output:
The OTSi/OTUk-a_A_Sk function will output the OTUk data-stream via this output pin. This OTUk data-stream will be unscrambled and it 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).

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

Data that is output via this signal, will be aligned with one of the edges of the CI_CK clock output signal. The system designer will typically route this signal to the CI_D input to the downstream OTUk_TT_Sk function.
CI_CKOutputOTUk Characteristic Information - Clock Output:
As the OTUk_CP interface outputs data via the CI_D, CI_FS, CI_MFS and CI_SSF outputs; all of this data will be updated on one of the clock-edges of this clock output signal.
CI_FSOutputOTUk Characteristic Information - Frame Start Output:
The OTUk_CP Interface will pulse this output signal HIGH (for one CI_CK clock period) whenever the OTUk_CP interface outputs the very first bit (or byte) of a new OTUk frame, via this CI_D output.

This output signal will pulse HIGH once for each OTUk frame.
CI_MFSOutputOTUk Characteristic Information - Multiframe Start Output:
The OTUk_CP Interface will pulse this output signal HIGH (for one CI_CK period) whenever the OTUk_CP Interface outputs the very first bit (or byte) or a new OTUk multi-frame via the CI_D output.

This output signal will pulse HIGH once for each OTUk Multi-frame (or one for every 256 OTUk frames).
CI_SSFOutputOTUk Characteristic Information - Server Signal Failure Output:
The OTUk_CP Interface will assert this signal anytime the OTSi/OTUk-a_A_Sk function is declaring a service-affecting defect with the data that it is receiving via the AI_D input).

The OTUk_CP Interface will assert this output signal, whenever the OTSi/OTUk-a_A_Sk function is declaring any of the following defects.
- dLOF
- dLOM
- dAIS
- AI_TSF (if the upstream circuitry is driving the AI_TSF-P input pin, to this function, HIGH).
OTSi/OTUk-a_A_Sk_MP
Interface
MI_FECEnInputManagement Interface - OTSi/OTUk-a_A_Sk FEC Decoding Enable/Disable Input:
This input pin permits the function user to either enable or disable FEC Decoding within the OTSi/OTUk-a_A_Sk function.

Setting this input HIGH enables FEC Decoding.

Setting this input LOW disables FEC Decoding.

If the FEC Decoder is enabled, then it will use the FEC field to correct most symbol errors within the incoming OTUk data-stream (via the AI_PLD input).
MI_pFECcorrErrOutputManagement Interface - FEC Corrected Symbol Count Output:
This output port reflects the number of symbol errors that the OTSi/OTUk-a_A_Sk function has corrected via the FEC Decoder.

This is a Performance Monitoring feature within the OTSi/OTUk-a_A_Sk function.

NOTE: This output pin is INACTIVE if the MI_FECEn input pin is set low (to disable the FEC Decoder).
MI_cLOMOutputManagement Interface - Loss of Multiframe (Correlated) Output Indicator:
This output pin indicates if the OTSi/OTUk-a_A_Sk function is currently declaring the dLOM defect.

If this input pin is LOW, then it indicates that the function is NOT currently declaring the dLOM defect condition.

Conversely, if this input pin is HIGH, then it indicates that the function is currently declaring the dLOM defect condition.

Please see the dLOM defect post for more information on this topic.
MI_cLOFOutputManagement Interface - Loss of Frame (Correlated) Output Indicator:
This output pin indicates if the OTSi/OTUk-a_A_Sk function is currently declaring the dLOF defect.

If this output pin is LOW, then it indicates that the function is NOT currently declaring the dLOF defect condition.

Conversely, if this output pin is HIGH, then it indicates that the function is currently declaring the dLOF defect condition.

Please see the blog post on the dLOF defect for more information on this topic.
MI_cLOSOutputManagement Interface - Loss of Signal (Correlated) Output Indicator:
This output pin indicates if the OTSi/OTUk-a_A_Sk function is currently declaring the dLOS defect.

If this output pin is LOW, then it indicates that the function is NOT currently declaring the dLOS defect.

Conversely, if this output pin is HIGH, then it indicates that the function is currently declaring the dLOS defect condition.

Please see the blog post on the dLOS defect, for more information about this topic.

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!!

Other OTN-Related Posts

Click on the Image below to see more OTN-Related Posts in this blog.

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? ...

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? ...

What is an STE for OTN Applications?

This post defines and describes both a Section and Section Terminating Equipment for OTN applications. This post also defines the term: OTUk-SMOH (Section Monitoring Overhead).


What is Section Terminating Equipment (STE) for OTN Applications?

Whenever we discuss the OTN Digital Layers (e.g., the OPUk, ODUk, and OTUk layers), we can group Networking Circuits and Equipment into one of two broad categories.

I will be using these terms throughout various OTN-related posts within this blog.  So, we must have a strong understanding of these terms.

I have devoted this blog post to STE (Section Terminating Equipment).

I have devoted another post to PTE (Path Terminating Equipment).

NOTE:  I discuss STEs and PTEs extensively in Lesson 3 within THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!  I also discuss the differences between STEs and PTEs as well.  

What is a Section?

Before we define the term Section Terminating Equipment (or STE), we must first define the word Section as it pertains to an Optical Transport Network (OTN).

For OTN applications, a Section is a single optical link (or span) between two adjacent pieces of networking equipment.

NOTE:  For lower speed applications, one can realize a Section via a Copper Medium (such as CAT5 or CAT6 Cable).

Figure 1 presents a simple illustration of an Optical Transport Network with some boxes labeled PTE and others labeled STE.

Difference between Section Termination Equipment and Path Terminating Equipment

Figure 1 illustrates STE (Section Terminating Equipment) and PTE (Path Terminating Equipment).  Note:  Figure 1 shows a total of five (5) different boxes.  

Two of these boxes are labeled PTE, and three of these boxes are labeled STE.

However, in reality, all 5 of these boxes are STEs.

From a system standpoint, many PTEs are STEs.  However, not all STEs are PTEs.

We can also define a Section as any optical connections connecting these boxes (in Figure 1).

Now, we will define the term Section Terminating Equipment.

What is an STE (Section Terminating Equipment)?

For OTN applications, the basic definition of a Section Terminating Equipment is any equipment that (1) transmits data into or receives data from the Section and (2) also monitors and manages the data transmission over this Section (e.g., the optical fiber link that exists between the Near-End and the adjacent Far-End Network Equipment).

For OTN applications, the OTUk Layer is the protocol layer responsible for managing and monitoring the transmission/reception of data across a Section.

More specifically, an OTN Source (or Transmitting) STE is any equipment that performs ALL the following functions.

The Source STE Operation In the Transmit Direction

  • It will accept data from upstream circuitry (typically in the form of ODUk frames).
  • It electrically preconditions all data (that it is about to transmit to the remote Sink STE via an optical connection) by computing and attaching the OTUk (or OTUkV) overhead to this data stream.  This data will typically (but not always) include the FEC.
  • Once the Source STE has finished preconditioning this data, it will convert this electrical data into the optical format and transmit it over optical fiber to the remote Sink STE.

Sink STE Operation In the Receive Direction

The Sink (Receiving) STE performs all of the following operations.

  • It receives data (from a remote Source STE) in the optical format.
  • The Sink STE then converts this optical data into the electrical format, where it can check and process these newly received OTUk/OTUkV frames.
    As the Sink STE checks and processes this data, it will check for the following items.

     

  • It will then pass this data to the downstream circuitry as an ODUk data stream (for further processing at the ODUk-layer).

Therefore, if we were to combine our simple definition of the word Section with the description of a Section Terminating Equipment, we can say the following.

Summarizing our Definitions of Section and STE

An STE begins at the point where the Network Equipment (or the Source STE) will precondition and process electrical data in preparation for transmission over an Optical link.

Afterward, the Source STE will convert this signal into the Optical Format, transmitting this optical signal to the remote Sink (or Receiving) STE.

A Section ends (or is terminated) at the point where the Sink STE (that receives this optical signal) converts it back into the electrical format, processes this data, and sends it to downstream equipment.

How the STE Operates in the Optical Transport Network (OTN)

A Source STE will manage and monitor the transmission of this data (across a Section) by encapsulating this data into OTUk/OTUkV frames.

This Source STE will encapsulate this (ODUk) data by generating and inserting some overhead data (that we call the OTUk-SMOH [Section Monitoring Overhead]) into these OTUk/OTUkV frames.

NOTE:  In some of my other posts, I refer to this Source (or Transmitting) STE as the OTUk/ODUk_A_SoOTUk_TT_So, and OTSi/OTUk_A_S0 or OTSiG/OTUk_A_So atomic functions.

The Sink (or Receiving) STE will use this OTUk-SMOH to manage data reception across the Section.

NOTE:  In my other posts, I also refer to this Sink (or Receiving) STE as the OTUk/ODUk_A_Sk, OTUk_TT_Sk, and OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic functions.

The STE STE will manage the reception of data across the Section by using this OTUk-SMOH to check for data transmission errors and service-affecting defects.

What is the OTUk-SMOH (Section Monitoring Overhead)?

But when we say “OTUk-SMOH,” what exactly do we mean?

Figure 2 illustrates the OTUk Overhead data (within an OTUk frame) that the Section Terminating Equipment will process and terminate as it manages data transmission across a Section.

This figure also highlights a particular field (regarding Section Monitoring).  This figure highlights the Section Monitoring field.

OTUk Framing Format - Identifying Section Monitoring field

Figure 2, Illustration of an OTUk Frame with the OTUk SMOH Fields highlighted

I highlight the SM (or Section Monitoring) field because the actual OTUk-SMOH (that the Sink STE will use to check for the presence of defects or errors) resides within the Section Monitoring (or SM) field (within the OTUk Overhead).

In Figure 3, I focus on the Section Monitoring field and illustrate the byte format of this 3-byte field.

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

Figure 3, Illustration of the Byte-Format of the Section Monitoring field.

Figure 3 shows that the Section Monitoring field contains the following three byte-fields.

  • The BIP-8 Byte
  • The TTI Byte and
  • The Section Monitoring (or SM) Byte

In Figure 4, I further focus on the SM Byte and show the bit format of that particular byte field.

OTU Frame - Section Monitoring Byte Format - Optical Transport Networks

Figure 4, Bit-Format of the SM (Section Monitoring) Byte – within the Section Monitoring field

If you have seen the OTUk Frame post, Figures 2 through 4 should look familiar.

All of the overheads fields that the Sink STE will need to check for OTUk-related defects and errors (not including FEC) reside within the SM field.

Hence, the OTUk-SMOH is the Section Monitoring field within the OTUk Overhead.

NOTE:  For “nuts and bolts” details on the Source and Sink STEs handling and processing the OTUk-SMOH, check out the posts on the following Atomic Functions.

Now let’s proceed to show an example of STE and its Section.

AN EXAMPLE OF AN STE AND ITS SECTION

Figure 5 illustrates an STE and Section within a typical OTN network connection.

Section Termination Equipment - End-to-End Connection

Figure 5, Illustration of the STE and Section (from End to End) in a Typical OTN System

Finally, Figure 5 shows that the Section and STE begin (and end) before and after the OTUk Framer Block.

Please note that the STE also includes the OTUk Framer blocks in this Figure.

The OTUk Framer Blocks (and, in some cases, the OTUk Transceiver Blocks) are responsible for generating and inserting the OTUk-SMOH into the outbound OTUk data stream.

These same functional blocks are also responsible for processing and terminating the OTUk-SMOH within the incoming OTUk data stream.

Throughout numerous blog posts, we discuss the generation and processing of the OTUk-SMOH in detail.

Examples of STE

The following is a list of examples of the various types of OTN STE that are being deployed into the network infrastructure today.

  • Any 3R type of repeater.
  • Any network element that takes electrical data and maps it into an OTUk signal for transport to another terminal over an optical (or copper) connection (e.g., equipment that transmits data through sub-marine links, etc.).
  • CFP Optical Modules that also contains the DSP Transceiver.
  • Line Cards that include CFP2/CFP4 Optical Modules and OTN Framers.

Has Inflation got You Down? Our Price Discounts Can Help You Beat 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? ...