OTN – Lesson 6 – Converting OTL3.4 Back into OTU3 – Video 2

This blog post contains a video that serves as the 2nd of two videos that describe the functionality of the OTL3.4 Sink Terminal (aka the OTSiG/OTUk_A_Sk Atomic Function). This video focuses on Skew Compensation and ultimately combining the 4 OTL3.4 Lanes back into a Composite OTU3 signal.

OTN – Lesson 6 – Converting OTL3.4 Signals back into a Composite OTU3 Signal – Video 2 of 2

This blog post contains the second (of 2) videos that describes how we take an OTL3.4 Interface (or set of signals) and convert these signals back into a single (composite) OTU3 signal.  

This particular video completes the discussion of the OTSiG/OTUk_A_Sk Atomic Function (which, again, is a fancy word for OTL3.4 Sink Terminal).  

NOTE:  We formally introduce the OTSiG/OTUk_A_Sk Atomic Function in Lesson 9.  

This video discusses how the Lane Marker and Delay Processing Block (within the OTSiG/OTUk_A_Sk Function) evaluates all of the data and metrics coming from the four Lane Frame Alignment, Lane Alignment Recovery, and Elastic Store blocks and:

  • Measures and performs Skew Compensation,
  • Declares the dLOL (Loss of Lane Alignment) Defect Condition and 
  • Routes the de-skewed data to the 16-Byte Block MUX – which combines each of the four OTL3.4 lane signals back into a composite OTU3 signal. 

Continue reading “OTN – Lesson 6 – Converting OTL3.4 Back into OTU3 – Video 2”

OTN – Lesson 6 – Converting OTL3.4 Back into OTU3 – Video 1

This blog post contains a Video that serves as a first (of two) videos that discusses the functionality of the OTL3.4 Sink Terminal (aka OTSiG/OTUk_A_Sk Function). This video focuses on the dLOFLANE and dLOR defects.

OTN – Lesson 6 – Converting OTL3.4 Signals back into a Composite OTU3 Signal – Video 1 of 2

This blog post contains the first (of 2) videos that describe how we take an OTL3.4 Interface (or set of signals) and convert these signals back into a single (composite) OTU3 signal.  

This video introduces the OTSiG/OTUk_A_Sk Atomic Function (a fancy word for OTL3.4 Sink Terminal).  

NOTE:  We don’t mention OTSiG/OTUk_A_Sk Atomic Function until Lesson 9.  We call this function the OTL3.4 Sink Terminal.  

This video discussed how the OTSiG/OTUk_A_Sk Function accepts electrical lane signals from an Optical Module (in the OTL3.4 format) and processes these signals by:

  • Checking to see if we should declare/clear the dLOS-P (Loss of Signal – Path) Defect condition with these Electrical Lane signals, and 
  • Checking to see if we should declare/clear the dLOFLANE (Loss of Frame – of Logical Lane) defect condition.
  • Finally, we will discuss how the OTSiG/OTUk_A_Sk function checks each incoming OTL3.4 lane signal to see if it should declare the dLOR (Loss of Recovery) defect condition.  

Continue reading “OTN – Lesson 6 – Converting OTL3.4 Back into OTU3 – Video 1”

OTN – Lesson 9 – Video 11 – OTU Layer Defect Handling Requirements and Scenarios

In this video, we presume that some OTUk-Layer circuitry is declaring a certain defect condition. We then determine how OTU (and in some cases) ODU-layer circuitry is expected to respond.

OTN – Lesson 9 – Video 11 – OTU Layer Defect Scenarios

This blog post presents a video that discusses the various defects that OTN equipment can declare at the OTU Layer.  Additionally, this video will describe how OTU Layer circuitry should respond to and handle these defect conditions.  

This video will state whether OTU Layer circuitry should:

  • Transmit the SM-BDI Indicator upstream, or 
  • Transmit the ODU-AIS Maintenance Signal downstream, 
  • Increment Certain Performance Monitoring parameters, or
  • Halt Incrementing Certain Performance Monitoring parameters.

In response to each type of defect that OTU Layer circuitry can declare.

This video covers both Single-Lane (e.g., OTSi/OTUk_A_Sk) and Multi-Lane (e.g., OTSiG/OTUk_A_Sk) applications. 

Continue reading “OTN – Lesson 9 – Video 11 – OTU Layer Defect Handling Requirements and Scenarios”

OTN – Lesson 9 – Video 6 – OTU Layer Sink Direction Circuitry – OTSi/OTUk_A_Sk Function

This post presents the 6th of the 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 6 – OTU Layer Sink Direction Circuitry/Functionality – Part 4

This blog post contains a video that focuses on the OTSi/OTUk_A_Sk Atomic Function.  

The OTSi/OTUk_A_Sk Function has many of the same features/functionality as the OTSiG/OTUk_A_Sk Function.  

However, the OTSi/OTUk_A_Sk function supports the transport/reception of an OTU signal over a Single-Lane Connection (instead of 4 electrical lanes – such as the OTL3.4 or OTL4.4 Interface). Hence, this Atomic Function applies to OTU1 and OTU2 applications.  

The main difference between the OTSi/OTUk_A_Sk function and the OTSiG/OTUk_A_Sk function is that the OTSi/OTUk_A_Sk function will detect and declare the OTUk-AIS defect.  

Continue reading “OTN – Lesson 9 – Video 6 – OTU Layer Sink Direction Circuitry – OTSi/OTUk_A_Sk Function”

Defect – Definition

This post presents ITU-T G.806’s definition of a defect or defect condition.

Defect – Definition

ITU-T G.806 defines the word defect as follows:

Defect: The density of anomalies has reached a level where the ability to perform a required function has been interrupted.

We use defects as an input for performance monitoring, controlling consequent actions, and determining fault causes.

In other words, defects are bad.

If some piece of networking equipment is declaring a defect condition, it is saying it “cannot do its job properly” because of this condition.

Defects that We Cover in this Blog

We cover the following defects in this blog.

For OTN Applications

OTU Layer
  • dLOS-P – Loss of Signal – Path
  • dLOS-P[i] – Loss of Signal – Path, Electrical Lane, i
  • dLOFLANE[j] – Loss of Frame – of Logical Lane j
  • dLOR[j] – Loss of Recovery, Logical Lane j
  • dLOL – Loss of Lane Alignment
  • Excessive Skew (OTL3.4 and OTL4.4 Applications)
  • dLOF – Loss of Frame
  • dLOM – Loss of Multi-Frame
  • dAIS – (OTUk-) Alarm Indication Signal
  • dTIM – Trail Trace Identifier Mismatch
  • dBDI – Backward Defect Indicator
  • dDEG – Signal Degrade
  • dIAE – Input Alignment Error
  • dBIAE – Backward Input Alignment Error
ODU Layer
  • dAIS – (ODUk) Alarm Indication Signal
  • dLCK – Locked Status
  • dOCI – Open Connection Indication
  • dTIM – Trail Trace Identifier Mismatch
  • dBDI – Backward Defect Indicator
  • dDEG – Signal Degrade
Non-Multiplexed Applications
  • dLCS – Loss of Character Synchronization (100GBASE-R)
  • dPLM – Payload Type Mismatch
Multiplexed Applications
  • dLOOMFI – Loss of OMFI Synchronization
  • dLOFLOM[p] – Loss of Frame, Loss of Multi-Frame – ODUj Tributary Port p
  • dMSIM[p] – Multiplex Structure Identifier Mismatch – ODUj Tributary Port p
Tandem Connection Monitoring (TCM)
  • TCMi-dAIS – TCM Level i, Alarm Indication Signal
  • TCMi-dLCK – TCM Level i, Locked Status
  • TCMi-dOCI – TCM Level i, Open Connection Indication
  • TCMi-dTIM – TCM Level i, Trail Trace Identifier Mismatch
  • TCMi-dBDI – TCM Level i, Backward Defect Indicator
  • TCMi-dDEG – TCM Level i, Signal Degrade
  • TCMi-dIAE – TCM Level i, Input Alignment Error
  • TCMi-dBIAE – TCM Level i, Backward Input Alignment Error
  • dLTC – Loss of Tandem Connection Monitoring

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

Discounts Available for a Short Time!!!

What is pN_EBC at the OTUk Layer?

This blog post briefly describes the Performance-Monitoring parameter or term pN_EBC (Near-End Errored Block Count) for the OTUk-Layer.

What is the pN_EBC (Near-End Errored Block Count) Performance-Monitoring Parameter for the OTUk Layer?

This blog post aims to briefly define and describe the pN_EBC (Near-End Errored Block Count) Performance Monitoring parameter that the Sink STE (or OTUk_TT_Sk Atomic Function) will compute and tally.

The Sink STE (or OTUk_TT_Sk function) will include information on the pN_EBC parameter within each Performance Monitoring report it sends to System Management.

NOTES:

  1. The OTN PTE (or ODUP_TT_Sk Atomic Function) also monitors and generates information on the pN_EBC (Near-End Errored Block Count) parameter at the ODUk Layer. Please see the pN_EBC at ODUk Layer Post for more details on this parameter.
  2. Throughout this post, I will use the terms: Sink STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.

Introduction

At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Near-End Errored Block Counts (or SM-BIP-8 Errors).

NOTE: We refer to SM-BIP-8 errors as Near-End errors because these are errors that the Near-End Sink STE is detecting on its end. In contrast, we refer to the SM-BEI parameter as Far-End errors because that parameter reflects errors that a remote (or Far-End) Sink STE is detecting and reporting.

As the Sink STE receives and monitors its incoming OTUk signal, it will check for many things. It will continuously scan the incoming OTUk signal for bit (or symbol) errors (e.g., SM-BIP-8 errors, FEC errors, etc.) as well as Service-Affecting Defects (e.g., dTIM, dLOF, dLOM, dLOS-P, dAIS, etc.).

Definition of Terms:

Before we proceed, we need to define the following terms for this blog post:

  • Block: In this case, we define a block as an OTUk frame.
  • Errored Block: In this blog post, we define an errored block as any OTUk frame (or block) that contains at least one SM-BIP-8 error.

As the Sink STE checks the incoming OTUk signal for errors and defects, it will also keep a count of the number of errored blocks it detects for each one-second period.

At the end of a given one-second period, the Sink STE will load the total number of errored block counts (detected and tallied in the most recent one-second period) into the variable pN_EBC.

Since each type of OTUk signal (for a given value of k) transmits a different number of OTUk frames than does another OTUk signal (with a different value for k), each OTUk type will transmit a different number of blocks/second, as we show below in Table 1.

Table 1, Number of Blocks/Second for each OTUk Rate

OTUk TypeNumber of Blocks/Second
OTU120,421
OTU282,026
OTU3329,492
OTU4856,388
OTUCnn x 860,177

So How does the OTN STE tally Errored Blocks for the pN_EBC parameter?

As the Sink STE receives and monitors its OTUk signal, it will continually check for SM-BIP-8 errors.

Anytime the Sink STE receives an OTUk frame that contains at least one SM-BIP-8 error, then it will increment its internal (pN_EBC Counter) by 1.

Conversely, the Sink STE does not increment its internal pN_EBC Counter whenever it receives an OTUk frame that contains 0 SM-BIP-8 errors.

At the end of each one-second period, the Sink STE will load the contents of this internal counter into the pN_EBC parameter and include that information within its Performance Monitor report that it sends to System Management.

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

Discounts Available for a Short Time!!!

Are there any Times or Conditions during which the OTN STE will NOT tally Errored Block Counts for the pN_EBC parameter?

Yes, ITU-T G.798 states that the OTUk_TT_Sk function will stop tallying Errored Blocks for the pN_EBC parameter whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk Atomic function) asserts the CI_SSF input of the OTUk_TT_Sk function.

In other words, the OTN STE will not tally any Errored Block Counts (for the pN_EBC parameter) whenever it (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions) declares any of the following service-affecting defects conditions.

NOTE: (*) indicates that you must have a membership with THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!, to be able to access these lessons.

Additionally, the OTUk_TT_Sk function is not supposed to increment any pN_EBC counts whenever it declares the dIAE (Input Alignment Error) defect condition.

Is there such a thing as Far-End Errored Block Counts?

Throughout this post, we have used the term Near-End Errored Block Count. Does this mean that there is another parameter called Far-End Errored Block Count?

Answer: Yes, there is such a parameter. Please see the Far-End Errored Block Count post at the OTUk Layer for more details.

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

Discounts Available for a Short Time!!

And Finally, Click on the Following Image for More OTN-Related Topics 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_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 OTUk_TT_So Atomic Function?

This blog post briefly defines the OTUk_TT_So (OTUk Trail Termination Source) Atomic Function. One of the roles of this function is to insert the real Section Monitoring Overhead (SMOH) into the OTU Overhead.


What is the OTUk_TT_So Atomic Function?

We formally call the OTUk_TT_So Atomic Function the OTUk Trail Termination Source Function.

Introduction

The OTUk_TT_So function is any function that accepts data from upstream circuitry (usually the OTUk/ODUk_A_So function).  It uses the data (within this data stream) along with signals from a collocated OTUk_TT_Sk function to compute/generate and insert the OTUk Section Monitoring Overhead (SMOH) into the OTUk signal.

We have an extensive discussion of the OTUk_TT_So Atomic Function in Lesson 9 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

I show how we can connect these atomic functions below in Figure 1.

OTUk_TT_So_Function_with_OTUk/ODUk_A_So and Collocated OTUk-TT_Sk functions highlighted

Figure 1, Drawing of a Bidirectional Network (consisting of various Atomic Functions) with the OTUk/ODUk_A_So, the OTUk_TT_So, and its collocated OTUk_TT_Sk functions highlighted 

So What Does this Atomic Function Do?

If you recall, from our discussion of the OTUk/ODUk_A_So function, that function will only generate default values for the OTUk-SMOH within the OTUk signal it transmits.  The OTUk/ODUk_A_So function creates this default SMOH as a place-holder for a future (and actual) SMOH.

Computes and Inserts the Real SMOH Values into the Outbound OTUk Frames

Well, the purpose of the OTUk_TT_So function is to calculate and replace these default SMOH values with actual SMOH values.

More specifically, this function will compute and replace the following SMOH fields with actual Overhead data.

  • SM-BIP-8 field, within the Section Monitoring field
  • SM-BEI/BIAE nibble field within the Section Monitoring Byte
  • SM-BDI bit-field within the Section Monitoring Byte
  • IAE bit-field within the Section Monitoring Byte
  • SM-TTI (Trail Trace Identification) byte within the Section Monitoring field.

Afterward, the OTUk_TT_So function will transmit this OTUk data stream to either the OTSi/OTUk-a_A_S0 function (for OTU1/2 applications) or the OTSiG/OTUk-a_A_S0 function (for OTU3/4 applications). 

These functions will condition the OTUk data stream for transmission over Optical Fiber.

Why Do We Care about the SMOH from the OTUk_TT_So Function?

The SMOH that the OTUk_TT_So function computes and inserts into the OTUk data stream serves as the basis of comparison for the OTUk_TT_Sk function (at the remote Network Element).

The OTUk_TT_Sk function (at the remote end of our OTUk connection) will use this SMOH data to determine:

  • if it should declare any defect conditions, or
  • if errors have occurred during transmission between the near-end OTUk_TT_So and the remote OTUk_TT_Sk functions.

I show an illustration where both the OTUk_TT_So and OTUk_TT_Sk functions “fit into the big picture” below in Figure 2.

Roles of the SMOH within the OTUk_TT_So function

Figure 2, Drawing of Unidirectional Connection between a Source STE and a Sink STE with the OTUk_TT_So and OTUk_TT_Sk functions highlighted.  

Some Details about the OTUk_TT_So Function

Figure 3 presents a drawing of the ITU-T G.798 symbol for the OTUk_TT_So function.

OTUk_TT_So Simple Block Diagram - ITU-T G.798 Symbol

Figure 3, Simple Drawing of the OTUk_TT_So function

The OTUk_TT_So function accepts a basic OTUk data stream from the upstream OTUk/ODUk_A_So function via the OTUk_AP Interface.

The data that is output from the OTUk/ODUk_A_So function includes the Clock Signal (AI_CK), Frame Synchronization Signal (AI_FS), the Multi-Frame Synchronization Signal (AI_MFS), the OTUk data-stream (AI_D) and the IAE (Input Alignment Error) indicator (via the AI_IAE signal).

The OTUk_TT_So function is responsible for accepting data from its various interfaces and then computing and inserting the correct SMOH data into the OTUk data stream.

Figure 2 shows that this function consists of the following four different interfaces.

  • OTUk_AP
  • OTUk_CP
  • OTUk_RP and
  • OTUk_TT_So_MP

We will discuss each of these interfaces below.

Figure 4 presents a functional block diagram of the OTUk_TT_So function.

OTUk_TT_So Atomic Functional Block Diagram

Figure 4 Functional Block Diagram of the OTUk_TT_So function

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

Corporate Discounts Available!!

The OTUk_AP (OTUk Access Point) Interface

Figure 4 shows that the circuitry connected to (and driving) the OTUk_AP Interface (e.g., the OTUk/ODUk_A_So function) will supply the following signals to this interface.

  • AI_D – Bare-bones OTUk data (with the default SMOH)
  • AI_CK – The OTUk clock input signal
  • AI_FS – The OTUk Frame Start Input
  • AI_MFS – the OTUk Multi-Frame Start Input
  • AI_IAE – The OTUk Input Alignment Error Indicator Signal

The OTUk_TT_So function will then perform the following operations on these signals.

NOTE:  (*) – Indicates that you need to be a member of THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!  to see this post.  

Let’s move on to another port within this atomic function.

The OTUk_TT_So_RP (Remote Port) Interface

The OTUk_TT_So function will also accept data via the OTUk_TT_So_RP interface.  This interface consists of the following inputs.

  • RI_BEI – Remote Interface – Backward Error Indicator
  • RI_BIAE – Remote Interface – Backward Input Alignment Error Indicator
  • RI_BDI – Remote Interface – Backward Defect Indicator

The OTUk_TT_So function will operate in conjunction with a collocated Near-End OTUk_TT_Sk function and perform the following operations on these signals.

  • BDI Insertion (into the OTUk-SMOH) – The OTUk_TT_So function will accept the BDI information from the Near-End Collocated OTUk_TT_Sk function via the RI_BDI input and insert this data into the SM-BDI bit-field (within the SMOH) of the very next outbound OTUk frame.
  • BEI Insertion (into the OTUk-SMOH) – The OTUk_TT_So function will take the BEI information from the Near-End Collocated OTUk_TT_Sk function via the RI_BEI input and insert this data into the SM-BEI/BIAE nibble-field (within SMOH) of the very next outbound OTUk frame.
  • BIAE Insertion (into the OTUk-SMOH) – The OTUk_TT_So function will accept the BIAE information from the Near-End Collocated OTUk_TT_Sk function via the RI_BIAE input and (if appropriate) will insert this information into the SM-BEI/BIAE nibble-field (within the SMOH) of the very next outbound OTUk frame.

I show a drawing of our OTUk_TT_So function that is electrically connected to its collocated, Near-End OTUk_TT_Sk function via the Remote Port below in Figure 5.

OTUk_TT_So Atomic Function connected to its Collocated OTUk_TT_Sk function

Figure 5, Illustration of our OTUk_TT_So Function, along with its collocated, Near-End OTUk_TT_Sk function

We discuss the operations through the RP Interface in another post.

Next, let’s move on and discuss the Management Port of this atomic function.

The OTUk_TT_So_MP (Management Port) Interface

Finally, the OTUk_TT_So function accepts data from the OTUk_TT_So_MP Interface.  This particular interface consists of the following input pin.

  • MI_TxTI – Trail Trace Identifier Input

The function user is expected to load the contents of the outbound Trail Trace Identifier Message (64 bytes) to this input port.

The OTUk_TT_So function will then take this message data, and it will proceed to use the TTI byte-field within the OTUk-SMOH to transmit the contents of this message, one byte at a time, to the OTUk_TT_Sk function within the remote Network Element, via the OTUk data-stream.  Since the TTI Message is 64 bytes long, the OTUk_TT_So function will require 64 OTUk frames to transmit the complete TTI Message.

We will discuss these processes in greater detail in the Trail Trace Identifier post.

How the OTUk_TT_So function sources each of the various Overhead Fields within the SMOH

As we mentioned earlier, the primary responsibility of the OTUk_TT_So function is to compute/source the correct values for multiple fields within the SMOH and insert those values into the SMOH within each outbound OTUk frame.

Table 1 presents a list of Overhead-fields that the OTUk_TT_So function computes and sources.  This table also shows where this function gets its data for these Overhead fields.

Table 1, A List of the SMOH Overhead-fields that the OTUk_TT_So function computes/sources and how/where this function gets/derives this data.

Overhead FieldLocation within OTUk-SMOHSource of Data/How Derived?
BIP-8 ByteBIP-8 Byte within the Section Monitoring FieldThe OTUk_TT_So function locally computes the BIP-8 value based upon the contents within the OPUk portion of the OTUk frame.
IAE Bit-FieldThe IAE Bit-field within the Section Monitoring ByteBased upon the AI_IAE input to the function (at the OTUk_AP Interface)
BDI Bit-FieldThe BDI bit-field within the Section Monitoring byteBased upon the RI_BDI input to this function (at the Remote Port Interface).
BEI Nibble-FieldThe BEI/BIAE Nibble-field within the Section Monitoring ByteBased upon the RI_BEI and RI_BIAE inputs to this function (at the Remote Port Interface).
BIAE Nibble-FieldThe BEI/BIAE bit-fields within the Section Monitoring byte.Based upon the RI_BIAE and RI_BEI inputs to this function (at the Remote Port Interface).
TTI Byte-FieldTTI Byte within the Section Monitoring Field.The user is expected to load in the contents of the 64-byte Trace Identifier Message (TIM) into a buffer via the MI_TxTI input to this function.

The function will proceed to transmit the contents of this TIM, one byte at a time, via the TTI byte-field within each outbound OTUk Frame.

The OTUk_TT_So function will transport the entire TIM over 64 consecutive OTUk frames.

List of Input and Output Signals for the OTUk_TT_So Atomic Function

Table 2 presents a Pin Description for each of the Input/Output signals of the OTUk_TT_So Atomic Function.

Table 2, Input/Output Pin Description of the OTUk_TT_So Atomic Function

Signal NameTypeDescription
OTUk_AP Interface
AI_DInputOTUk Adapted Interface - OTUk Data Input:
The function user is expected to apply a bare-bones OTUk signal (which is output from the AI_D output of the OTUk/ODUk_A_So function) to this input pin.

NOTE: This OTUk data will contain the following fields
- Default OTUk SMOH data,
- The contents of the APS/PCC channel and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC field. This function will compute, generate and insert the appropriate OTUk-SMOH into this OTUk data-stream

The OTUk_TT_So function will sample this input signal on one of the edges of the AI_CK input clock signal.
AI_CKInputOTUk Adapted Interface - Clock Input:
The OTUk_TT_So function will sample all data and signals (that the user applies to the OTUk_AP Interface) upon one of the edges of this input clock signal. This statement applies to the following signals: AI_D, AI_FS, AI_MFS and AI_IAE.

This clock signal will also function as the timing source for this function as well.
AI_FSInputOTUk Adapted Information - Frame Start Input:
The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP Interface accepts the very first bit (or byte) of a new OTUk frame, via the AI_D inputs.

The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk frame.
AI_MFSInputOTUk Adapted Information - Multiframe Start Output:
The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP interface accepts the very first bit (or byte) of a new OTUk superframe, via the AI_D input.

The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk superframe.
AI_IAEInputOTUk Adapted Information - Input Alignment Error Input:
the OTUk/ODUk_A_So function (upstream from this function) will drive this input pin HIGH whenever it detects a frame-slip (or IAE event).

Anytime the OTUk_TT_So function detects this input pin, going from LOW to HIGH, then it should respond by setting the IAE bit-field to "1" for 16 consecutive Superframes (or 4096 consecutive OTUk frames).

Please see the blog on IAE for more information on this feature.
OTUk_CP Interface
CI_DOutputOTUk Characteristic Information - OTUk Data Output:
The OTUk_TT_So function will compute, generate and insert the SMOH (Section Monitoring Overhead) into the outbound OTUk data-stream. It will then output this OTUk data-stream via this output signal.

NOTE: This OTUk data will contain the following fields.
- The newly computed, inserted BIP-8 value
- The newly received and inserted BEI-nibble value or BIAE indicator.
- The newly received and inserted BDI bit-value.
- the newly received and inserted IAE value.
- The contents of the APS/PCC channel and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC field.

The OTUk_TT_So function will update this output signal on one of the edges of the CI_CK output clock signal.
CI_CKOutputOTUk Adapted Information - Clock Output:
The OTUk_TT_So function will output all data and signals (via the OTUk_CP interface) upon one of the edges of this output clock signal. This statement applies to the following signals: CI_D, CI_FS and CI_MFS.
CI_FSOutputOTUk Characteristic Information - Frame Start Output:
This function will drive this output pin HIGH whenever the OTUk_CP interface outputs the very first bit (or byte) of a new OTUk frame, via the CI_D output.

The OTUk_TT_So function should only pulse this output pin HIGH once for each outbound OTUk frame.
CI_MFSOutputOTUk Characteristic Information - Multiframe Start Output:
This function will drive this output pin HIGH whenever the OTUk _CP Interface outputs the very first bit (or byte) of a new OTUk Superframe via the CI_D.

The OTUk_TT_So function will drive this output pin HIGH once for each OTUk Superframe.
OTUk_TT_So_RP Interface
REI_BEIInputRemote Port Interface - BEI (Backward Error Indicator) Input:
The OTUk_TT_So function will accept one nibble of data (for each outbound OTUk frame) via this input signal and it will insert this data into the BEI/BIAE nibble-field within the Section Monitor field within each outbound OTUk frame.

The BEI value will reflect the number of BIP-8 errors that the collocated OTUk_TT_Sk function has detected and flagged within its most recently recevied and verified OTUk frame.

NOTE: If the OTUk_TT_So function receives a BIAE = 1 (via the RI_BIAE input) then it will overwrite the BEI/BIAE nibble-field with the value "1011" to denote a BIAE event.

Please see the BEI post for more information about Backward Error Indication.
RI_BIAEInputRemote Port Interface - BIAE (Backward Input Alignment Error) Input:
The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input signal and it will do either of the following, depending on the value of this single bit-field.

If BIAE = 0
Then the OTUk_TT_So function will write the BEI value that it has received via the RI_BEI input, into the BEI nibble-field within the Section Monitor byte of the next outbound OTUk frame.

If BIAE = 1
Then the OTUk_TT_So function will not write the BEI value (that it has received from the collocated OTUk_TT_Sk function). It will instead, write the value "1011" into the BEI/BIAE nibble-field, within the Section Monitor byte of the next outbound OTUk frame.
RI_BDIInputRemote Port Interface - Backward Defect Indicator Input:
The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input pin and it will write the contents of this value into the RDI bit-field (within the Section Monitor byte) of the next outbound OTUk frame.

If RI_BDI = 0
The the OTUk_TT_So function will set the BDI bit-field to "0" within the next outbound OTUk frame.

If RI_BDI = 1
Then the OTUk_TT_So function will set the BDI-bit-field to "1" within the next outbound OTUk frame.
OTUk_TT_So_MP Interface
MI_TxTIInputManagement Interface - Trail Trace Identifier Input:
The function user is expected to load in the 64-byte TTI Message into the OTUk_TT_So circuitry via this input. The OTUk_TT_So function will then transmit the message to the remote Network Element, one byte-at-a-time, over 64 consecutive outbound OTUk frames.

Has Inflation got You Down? Our Price Discount 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? ...

What is the OTUk-AIS Indicator?

This post defines and describes the OTUk-AIS signal for OTN applications.


What is the OTUk-AIS Maintenance Signal?

What exactly is an OTUk-AIS signal?

AIS is an acronym for Alarm Indication Signal.

Another post describes the role/function of AIS.

Whenever an OTN Network Equipment (NE) transmits an OTUk-AIS signal, it generates and transmits an Unframed PN-11 (e.g., PRBS11) Pattern.

More specifically, ITU-T G.709 defines this PN-11 sequence by the generating polynomial:  1 + x9 + x11.

Since this is an Unframed signal, then this means that all of the OTUk, ODUk, and OPUk overhead fields (within the OTUk signal) will be overwritten with this PN-11 pattern.

Figure 1 presents a simple illustration of an OTUk-AIS signal.

OTUk-AIS Pattern

Figure 1, Simple Illustration of an OTUk-AIS signal.

What are the timing/frequency requirements for an OTUk-AIS signal?

The OTN NE will need to transmit this signal at the same nominal bit rate as an ordinary OTUk signal.

Like any ordinary OTUk signal, the OTN STE will need to transmit this data at the nominal bit-rate ± 20ppm.

Table 1 presents the nominal bit-rates for the OTUk signals (and, in turn, for the OTUk-AIS signal) for each value of k.

Table 1, Required Bit Rates for the OTUk-AIS signal.

OTUk Bit Rate

Does the OTN NE need to align the PN-11 pattern sequence with the OTUk frame?

In short, the answer is No.

The length of the PN-11 sequence is 2047 bits (e.g., 211 – 1).  And the capacity of a given OTUk frame is 130,560 bits.

Since the numeral 130,560 is NOT an integral multiple of 2047, the PN-11 sequence will cross OTUk frame boundaries.

When would OTN Network Equipment transmit/generate an OTUk-AIS signal?

For the time being, ITU-T G.709 has not defined a set of conditions (or defects) upon which the OTN STE would transmit the OTUk-AIS signal.

ITU-T G.709 has reserved this type of signal as a placeholder for future use.

The standards committee may (at a later time) specify a set of conditions upon which an OTN STE would transmit the OTUk-AIS signal.

Additionally, ITU-T G.709 is NOT requiring that OTN Equipment or Chip Vendors design their products to be capable of generating/transmitting the OTUk-AIS signal.

However, ITU-T G.709 mandates that OTN Equipment and Chip Vendors be capable of receiving, detecting, and flagging the OTUk-AIS pattern.

Click HERE for Information on How an STE does declare and clear the dAIS (OTUk-AIS) defect condition.

Why are we even talking about an OTUk-AIS Signal if we are NOT currently required to generate it?

Once again, the Standards Committee has reserved this signal for FUTURE USE.

They envision defining conditions for which an OTN Section Terminating Equipment (STE) would generate and transmit the OTUk-AIS signal in a system application.

Is there another type of AIS signal that OTN APPLICATIONS ARE ACTIVELY USING?

Yes, ITU-T G.709 also recommends the use of ODUk-AIS.  OTN Path Terminating Equipment is actively using the ODUk-AIS indicator.

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

Temporary Discount Offered!!

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