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

What are Consequent Equations?

This post briefly defines and describes Consequent Equations that ITU-T G.798 uses for OTN Applications.

What are Consequent Equations, and How Should You Interpret Them?

The purpose of this blog post is two-fold.

To describe the concept of Consequent Equations and
To discuss how we can use and interpret these Consequent Equations.

Introduction

Many ITU Standards (such as ITU-T G.798 for OTN Applications) will discuss many aspects of defects. These standards will define defects such as dAIS (Alarm Indication Signal) and dLOM (the Loss of Multi-frame).

These same standards will also define the criteria that an OTN Network Element (be it an STE or PTE) should use to declare or clear a given defect.

For example, ITU-T G.798 specifies all of the following defects that an OTN STE can declare and clear.

dAIS – (OTUk-AIS)
dLOS-P (Loss of Signal-Path Defect)
dLOF – Loss of Frame Defect
dLOM – Loss of Multi-Frame Defect
dLOFLANE – Loss of Frame-Lane Signal (OTL3.4/OTL4.4/OTL4.10 Applications Only) (*)
dLOL – Loss of Lane Alignment (OTL3.4/OTL4.4/OTL4.10 Applications Only)(*)
dIAE – Input Alignment Error Defect (*)
dBIAE – Backward Input Alignment Error Defect (*)
dTIM – OTUk-Trace Identifier Mismatch Defect (*)
dBDI – OTUk-Backward Defect Indicator Defect
dDEG – OTUk-Signal Degrade Defect (*)

And that’s all well and good.

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

How should an STE/PTE Respond Whenever it Declares a Defect?

However, what else should an STE do whenever it declares (for example) the dLOF defect condition?

Does this STE have a responsibility to notify other STEs of this defect?

Similarly, what else should a PTE do whenever it declares (for example) the dTIM (ODUk-TIM) defect condition?

Again, does this PTE have a responsibility to notify other nearby PTEs of this defect?

The short answer to both of these questions is, “Yes, for those specific defects that I mentioned, they do have a responsibility to notify upstream and downstream equipment of the occurrence of those defect conditions.”

However, to confuse things, the PTE/STE must notify upstream and downstream PTE/STE whenever some defects occur, but not others.

How Do We Sort out This Confusion?

The Answer: Consequent Equations.

Let’s assume that a certain STE is declaring the dLOF Defect condition, as shown below in Figure 1.

Consequent Equation - OTSi/OTUk_A_Sk function declares the dLOF defect

Figure 1, Illustration of the STE (e.g., the OTSi/OTUk-a_A_Sk Atomic Function) declares the dLOF defect condition.

What happens next?

At this point, let’s write down the Consequent Equation that pertains to this STE (or the OTSi/OTUk-a_A_Sk function in this case):

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

Where:

aSSF is the current state of the CI_SSF output pin (of the OTSi/OTUk-a_A_Sk function).

dLOS-P is the current state of the Loss of Signal-Path Defect condition

dAIS is the current state of the OTUk-AIS Defect Condition

dLOF is the current state of the Loss of Frame Defect Condition

dLOM is the current state of the Loss of Multi-Frame Defect Condition, and

AI_TSF-P is the current (logical) state of the AI_TSF-P input pin (to the OTSi/OTUk-a_A_Sk atomic function).

This consequent equation states that the STE (or OTSi/OTUk-a_A_Sk function) will assert its CI_SSF output pin anytime it declares any of the following defect conditions:

dLOS-P – The Loss of Signal-Path Defect Condition
dAIS – The (OTUk-AIS) Defect Condition
dLOF – The Loss of Frame Defect Condition
dLOM – The Loss of Multi-Frame Defect Condition

This consequent equation also states that the STE (the OTSi/OTUk-a_A_Sk function) will assert the CI_SSF output pin anytime the upstream atomic function asserts the AI_TSF input to this function.

NOTE: Please see the OTSi/OTUk_A_Sk Function Post for more information about this particular Atomic Function.

So What Does All of This Mean?

In Figure 2, I show the OTSi/OTUk_A_Sk function now asserting its CI_SSF output pin because it is currently declaring the dLOF defect condition.

Consequent Equation - OTSi/OTUk_A_Sk function asserts CI_SSF due to dLOF defect

Figure 2, Illustration of the OTSi/OTUk_A_Sk Atomic Function asserting its CI_SSF output because it is currently declaring the dLOF defect condition.

Please note that the CI_SSF output (from the OTSi/OTUk_A_Sk function) is connected to the CI_SSF input of the (downstream) OTUk_TT_Sk function.

OK, that’s great. The above Consequent Equation states that the STE (e.g., the OTSi/OTUk_A_Sk function will assert the CI_SSF output pin whenever it declares the dLOF defect.

How does that alert any other STE/PTE of the OTSi/OTUk_A_Sk function declaring the dLOF defect?

Answer: There is more to this, and it involves more Consequent Equations.

Let’s Take a Look at the Downstream Circuitry

Let’s now look at the OTUk_TT_Sk and OTUk/ODUk_A_Sk Atomic Functions (which are both downstream from the OTSi/OTUk_A_Sk function).

In Figure 3, I show the OTUk_TT_Sk and the OTUk/ODUk_A_Sk Atomic Functions.

I also show that the upstream (OTSi/OTUk_A_Sk function) circuitry is now asserting the CI_SSF input (to the OTUk_TT_Sk function) – as we described above.

Consequent Equations - Upstream Circuitry asserts CI_SSF input to the OTUk_TT_Sk function

Figure 3, Illustration of the OTUk_TT_Sk and OTUk/ODUk_A_Sk functions – with upstream circuitry asserting the CI_SSF input pin.

Now, the OTUk_TT_Sk Atomic Function happens to have two sets of Consequent Equations:

I will list each of these equations below.

aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))
aBDI <- CI_SSF or dAIS or dTIM

I will explain each of these equations below.

The First Consequent Equation – OTUk_TT_Sk Function

Let’s start with the first Consequent Equation for the OTUk_TT_Sk function.

aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))

Where:

aTSF is the current state of the AI_TSF output of the OTUk_TT_Sk Atomic Function.

CI_SSF is the current state of the CI_SSF input of the OTUk_TT_Sk Atomic Function.

dAIS is the current state of the dAIS defect condition, and

dTIM is the current state of the Trail Trace Identifier Mismatch Defect Condition.

This Consequent Equation states that the OTUk_TT_Sk Atomic Function should assert the AI_TSF output signal anytime it declares any of the following defect conditions.

dTIM – Trail Trace Identifier Mismatch Defect
dAIS – AIS Defect

This Consequent Equation also states that the OTUk_TT_Sk function should assert the AI_TSF output whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk function) asserts the CI_SSF input pin.

In Figure 4, I show the OTUk_TT_Sk function asserting its AI_TSF output pin because the upstream OTSi/OTUk_A_Sk function is asserting the CI_SSF input pin (to this function).

Consequent Equation - OTUk_TT_Sk Atomic Function asserts AI_TSF due to CI_SSF being asserted

Figure 4, The OTUk_TT_Sk Atomic Function asserts the AI_TSF output pin because the upstream OTSi/OTUk_A_Sk function is asserting its CI_SSF input pin.

OK, now let’s look at the second Consequent Equation for the OTUk_TT_Sk Function.

The Second Consequent Equation – OTUk_TT_Sk Function

aBDI <- CI_SSF or dAIS or dTIM

Where:

aBDI is the state of the RI_BDI output (of the Remote Port Interface) of the OTUk_TT_Sk function.

Earlier in this post, we have defined CI_SSF, dAIS, and dTIM.

Therefore, this Consequent Equation states that the OTUk_TT_Sk function will assert the RI_BDI output pin anytime it declares the dAIS or dTIM defect conditions.

This equation also states that the OTUk_TT_Sk function will also assert the RI_BDI output pin anytime the upstream circuitry asserts the CI_SSF input (to the OTUk_TT_Sk function).

If you recall from the OTUk_TT_So and OTUk_TT_Sk posts, I state that anytime the OTUk_TT_Sk function asserts the RI_BDI output pin, it will command its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back out to the remote end.

I show this phenomenon below in Figure 5.

Consequent Equation - OTUk_TT_Sk function asserts RI_BDI due to CI_SSF

Figure 5, The OTUk_TT_Sk function asserts its RI_BDI output pin, commanding its Collocated OTUk_TT_So function to transmit the BDI (Backward Defect Indicator) back to the upstream STE because its CI_SSF is being driven HIGH.

Figure 5 shows that because the STE (OTSi/OTUk_A_Sk function) declared the dLOF defect, the downstream OTUk_TT_Sk function responded by commanding its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back to the upstream STE (the source of the defective OTUk signal).

However, we’re not done yet.

Since the OTUk_TT_Sk function is also asserting its AI_TSF output, it is also asserting the AI_TSF input to the (down-stream) OTUk/ODUk_A_Sk atomic function.

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

Let’s move on to the OTUk/ODUk_A_Sk Atomic Function

As you can see in Figure 5, the OTUk_TT_Sk function, by asserting its AI_TSF output pin, is also asserting the AI_TSF input pin to the OTUk/ODUk_A_Sk function.

And the OTUk/ODUk_A_Sk function comes with several Consequent Equations of its own.

aSSF <- AI_TSF and (not MI_AdminState = LOCKED), and
aAIS <- AI_TSF and (not MI_AdminState = LOCKED)

Let’s take each of these equations, one at a time.

The First Consequent Equation – OTUk/ODUk_A_Sk Function

aSSF <- AI_TSF and (not MI_AdminState = LOCKED)

Where:

aSSF is the current state of the CI_SSF output pin (from the OTUk/ODUk_A_Sk function).

AI_TSF is the current state of the AI_TSF input pin to the OTUk/ODUk_A_Sk function, and

MI_AdminState reflects the current state of the MI_AdminState input signal (which the System Operator can set).

This Consequent Equation states that the OTUk/ODUk_A_Sk function will automatically assert its CI_SSF output signal whenever the upstream circuitry asserts its AI_TSF input, provided that the System Operator has not put the OTUk/ODUk_A_Sk function into the LOCKED state.

In Figure 6, I show the OTUk/ODUk_A_Sk function asserting its CI_SSF output pin because the upstream circuitry is asserting its AI_TSF input pin.

Consequent Equations - OTUk/ODUk_A_Sk function asserts its CI_SSF output pin

Figure 6, The OTUk/ODUk_A_Sk function asserts its CI_SSF output pin because the upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF input pin.

I should also point out that APS (Automatic Protection Switching) systems often trigger (and start protection switching) whenever the OTUk/ODUk_A_Sk function asserts its CI_SSF output pin.

Now, let’s move on to the next Consequent Equation.

The Second Consequent Equation – OTUk/ODUk_A_Sk Function

aAIS <- AI_TSF and (not MI_AdminState = LOCKED)

Where:

aAIS is the current state of the ODUk-AIS Maintenance Signal.

If aAIS = TRUE, then the OTUk/ODUk_A_Sk function is overwriting its output signal with the ODUk-AIS Maintenance signal.

Conversely, if aAIS is FALSE, then the OTUk/ODUk_A_Sk function transmits an ODUk data stream, carrying regular client traffic.

Therefore, this Consequent Equation states that the OTUk/ODUk_A_Sk function will transmit the ODUk-AIS Maintenance Signal anytime the upstream circuitry pulls its AI_TSF input TRUE; provided that the System Operator has NOT put the OTUk/ODUk_A_Sk function into the LOCKED State.

In Figure 7, I illustrate the OTUk/ODUk_A_Sk function transmitting the ODUk-AIS Maintenance Signal because upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF input.

Consequent Equation - OTUk/ODUk_A_Sk function transmits ODUk-AIS downstream

Figure 7, The OTUk/ODUk_A_Sk function replaces the ODUk signal (carrying client data) with the ODUk-AIS Maintenance Signal whenever upstream circuitry asserts its AI_TSF input.

So What Does All This Mean?

If we were to combine the OTSi/OTUk_A_Sk function, the OTUk_TT_Sk function, its Collocated OTUk_TT_So function, and the OTUk/ODUk_A_Sk function into a single box, that we call OTN STE.

Then, we could state that if the OTN STE declares the dLOF defect (as we discussed earlier in this post), then that same OTN STE will do all of the following:

It will transmit the OTUk-BDI indicator back towards the upstream STE.
The OTN STE will also replace the missing (or defective) ODUk data stream (carrying client traffic) with the ODUk-AIS Maintenance Signal, and
It will also trigger APS (Automatic Protection Switching) activities by asserting the CI_SSF output (from the OTUk/ODUk_A_Sk function).

I show a drawing of these actions below in Figure 8.

Consequent Equations - Overall OTN STE's response to it declaring the dLOF Defect Condition

Figure 8, Illustration of the OTN STE responding to the dLOF Defect Condition

Conclusion

Thanks to Consequent Equations, we can define and predict how an OTN STE or PTE will respond to certain defects.

I have presented Consequent Equations in each post pertaining to OTN Atomic Functions.

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

Discounts Available for a Short Time!!!

Click on the Image below to See More OTN- or Protection-Switching-Related Posts

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

Protection-Switching Related Blog Posts

Protection-Switching Related Blog Posts Basic Protection-Switching Terms Head-End (Source Node) Hold-Off Timer Protection-Group Protection-Transport entity Selector Switch Tail-End (Sink Node) ...

Declaring/Clearing the dLOM Defect

This post briefly describes the dLOM (Loss of Multi-Frame) defect for OTN applications. This post describes how an OTN STE should declare and clear the dLOM defect condition.

How an OTN STE should declare and clear the dLOM (Loss of Multi-Frame) Defect Condition.

The purpose of this post is to describe how an OTN STE (Section Terminating Equipment) will declare and clear the dLOM (Loss of Multi-Frame) Defect Condition.

Suppose you’re analyzing this topic from an ITU-T G.798 Atomic Function standpoint. In that case, I will tell you that the two atomic functions that are responsible for declaring and clearing the dLOM defect condition are:

The OTSi/OTUk_A_Sk Function, and
The OTSiG/OTUk_A_Sk Function.

Each of these atomic functions includes the dLOM Detection circuit.

A Note about Terminology:

Throughout this blog post, I will refer to the entity containing the dLOM Detection circuit (and declares/clears the dLOM defect condition ) as the Sink STE.

I’m using this terminology because it is technically correct, and it is much simpler to use that word than to use: OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions. However, I will use atomic function-related terms below in Table 1 (at the end of this post).

A Brief Review of the OTUk Frame Structure

In the OTUk Post, I stated that the OTUk frame consists of a single multi-frame alignment signal (MFAS) byte.

I show a drawing of the OTUk Frame Structure, with the MFAS-field highlighted below in Figure 1.

Figure 1, Drawing of the OTUk Frame Structure, with the MFAS-Field Highlighted

In the OTUk blog post, we mentioned that the Source STE Terminal would generate and transmit OTUk traffic in the form of back-to-back multi-frames. Each of these multi-frames consists of 256 consecutive OTUk frames.

The MFAS Byte Increments with each Frame

The S0urce STE Terminal will designate one of these OTUk frames as the first frame within a multi-frame by setting the MFAS byte (within that particular frame) to 0x00. When the Source STE generates and transmits the next OTUk frame, it will set the MFAS byte (within that OTUk frame) to 0x01.

The Source STE will continue incrementing the MFAS byte within each outbound OTUk frame until it has transmitted the 256th frame within this multi-frame. And it has set the MFAS byte to 0xFF (or 255 in decimal format).

At this point, the Source STE has completed its transmission of a given 256-frame OTUk multi-frame, and it will start to transmit the very next multi-frame.

The Source STE will show that it is transmitting the next 256-frame multi-frame by setting the MFAS byte to 0x00 (once again) and then incrementing the value that it writes into each MFAS byte (within each outbound OTUk frame) until it reaches 0xFF (255).

This process repeats indefinitely.

Now that we have re-acquainted ourselves with the MFAS byte, we can discuss how a Sink STE will declare and clear the dLOM (Loss of Multi-frame) defect condition.

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

Corporate Discounts Available!!

A Basic Requirement before We can Clear the dLOM Defect Condition

Before I can begin to discuss the dLOM-Related State Machines (and the actual mechanics of declaring and clearing the dLOM defect). I need to be very clear about one thing.

The Sink STE can’t clear the dLOM defect condition unless it has first cleared the dLOF defect condition.

Additionally, anytime the Sink STE declares the dLOF defect condition, it loses MFAS synchronization.

There are several reasons for this:

The Sink STE needs to find the FAS-field first

The MFAS byte-field resides in Row 1, Byte 7 (within the OTUk frame). It is adjacent to the FAS field. Therefore, once the Sink STE finds the FAS field, it can quickly locate the MFAS byte.

The FAS field is FAR more accessible for the Sink STE to find than the MFAS byte.

There are two reasons for this.

The FAS field consists of a defined/fixed pattern. In other words, the FAS fields never change in value (except for the 3rd OA2 byte – for OTL4.4 and OTL4.10 applications ONLY).

The Sink STE can locate the FAS field by only looking for these fixed patterns. On the other hand, the MFAS byte value changes with every OTUk frame.

Additionally, we NEVER scramble the FAS field. However, we do scramble the MFAS byte.

I show a drawing of an OTUk frame below that identifies the portions of the OTUk frame that the Remote Source STE has scrambled before transmitting this OTUk frame to the Near-end Sink STE.

Figure 2, Drawing of an OTUk Frame – Showing the portions of the OTUk Frame that we scrambled.

Finally, the MFAS byte-field was scrambled by a Frame-Synchronous Scrambler (at the remote Source STE)

Therefore, you will need to descramble the MFAS byte (along with the rest of the OTUk frame) with a Frame-Synchronous Descrambler.

This means that the Sink STE needs proper synchronization with the incoming OTUk frames (e.g., clearing the dLOF defect) before we can even use this Frame-Synchronous Descrambler.

Now that I’ve made that point, I will discuss how the Sink STE declares and clears the dLOM defect.

We will first discuss dLOM-Related State Machines.

The dLOM-Related State Machines

Once again, whenever the Sink STE first powers up and receives a stream of OTUk data, it will first need to acquire FAS-frame synchronization with this incoming data stream, as described in the dLOF – Loss of Frame Defect blog post.

After the Sink STE has cleared the dLOF defect condition (and can now reliably locate the FAS field within each incoming OTUk frame), it can proceed to find the MFAS byte.

Figure 1 (above) shows that the MFAS byte resides in row 1, byte-column 7 (immediately following the FAS field) within the OTUk frame.

Whenever the Sink STE has acquired FAS-frame synchronization with the incoming OTUk frame (and cleared the dLOF defect condition), it will continuously operate simultaneously per two sets of state machines.

The OTUk-MFAS OOM/IM Low-Level State Machine and
The OTUk-dLOM Framing Alignment/Maintenance State Machine

These two state machines are hierarchical. In other words, one of these state machines operates at the low level (e.g., the OTUk-MFAS OOM/IM Low-Level State Machine), and the other state machine operates at a higher layer (on top of the low-level state machine).

I show the relationship between these two-state machines below in Figure 3.

Figure 3, Illustration of the relationship between the two dLOM-related State Machines

We will discuss these two state machines below.

The OTUk-MFAS OOM/IM Low-Level State Machine

We will discuss the OTUk-MFAS OOM/IM Low-Level State Machine first, and then we will discuss the OTUk-dLOM Framing Alignment/Maintenance State Machine later.

I show a drawing of the OTUk-MFAS OOM/IM Low-Level State Machine Diagram below in Figure 4.

Figure 4, Drawing of the OTUk-MFAS OOM/IM Low-Level State Machine Diagram

Figure 4 shows that the OTUk-MFAS OOM/IM Low-Level State Machine contains the following two states.

The LL-OOM (Low-Level – Out of Multi-frame) state and
The LL-IM (Low-Level – In Multi-frame) state

When the System Operator powers up the Sink STE circuitry, feeds an OTUk data stream and clears the dLOF defect, it will continually operate in one of these states.

The Sink STE will (on occasion) need to transition from one state to another.

We will discuss these two states below.

The LL-OOM State

Whenever the Sink STE first clears the dLOF defect condition, it will (initially) be operating in the LL-OOM (Low Level – Out of Multi-Frame) state.

At this point, the Sink STE either has not located the MFAS byte or is not yet in sync with the incrementing MFAS byte value within the incoming OTUk data stream.

While the Sink STE is operating in this state, it will begin to evaluate bytes (that it “believes” to be the MFAS byte-field) within each incoming OTUk frame. More specifically, the Sink STE will locate a given Candidate MFAS byte and read in its value.

The value of this MFAS byte will be between 0x00 and 0xFF (255) inclusively. The Sink STE will note this value, and it will then perform the following computation.

Next_Expected_MFAS_Value = MOD(Candidate_MFAS_Value + 1, 256);

In other words, the Sink STE will take the byte value (of the Candidate MFAS byte that it has read in) and (internally) increment this value by 1.

I hope you understand why we run this incremented Candidate_MFAS_Value through a Modulus Equation with a divisor of 256.

The Sink STE will assign this newly incremented value to the variable Next_Expected_MFAS_Value. We will use this “Next _Expected_MFAS_Value” to evaluate the next incoming OTUk frame.

The Sink STE will then wait through 16,320-byte periods (or one OTUk frame period) and then read in another Candidate MFAS value (from this next OTUk frame), and it will compare that byte value with the “Next_Expected_MFAS_Value” that it has computed.

If the Sink STE determines that this new “Candidate MFAS Value” does not match the “Next_Expected_MFAS_Value,” then it will go back and parse through the incoming OTUk data-stream and look for another byte-field (within row 1, column 7 of the incoming OTUk frame).

The Sink STE will continue to operate in the LL-OOM state.

On the other hand, if the Sink STE does (indeed) determine that the expression “Candidate MFAS value ” matches that of the “Next_Expected_MFAS_Value,” then it will transition into the LL-IM (Low-Level – In-Multi-Frame) state.

The LL-IM State

Once the Sink STE enters the LL-IM state, then it will continue to check for the presence of the correct (properly incrementing byte values within the MFAS byte) at OTUk frame intervals.

If the Sink STE can consistently locate these MFAS bytes at each OTUk frame interval (with the correct and properly incrementing values), it will remain in the LL-IM state.

However, if the Sink STE lost synchronization with the MFAS field (of each incoming OTUk frame), it could not locate the MFAS field for five (5) consecutive OTUk frame periods, then the Sink STE will transition back into the LL-OOM state.

NOTE: The OTUk-MFAS OOM/IM Low-Level State Machine algorithm is tolerant of bit errors. In other words, the presence of occasional bit-errors or a burst of bit-errors is not enough to cause the Sink STE to transition from the LL-IM back to the LL-OOM state.

Now that we have discussed the OTUk-MFAS OOM/IM Low-Level State Machine, let’s move on and describe the OTUk-dLOM Framing Alignment/Maintenance State Machine.

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

Discounts Available for a Short Time!!!

The OTUk-dLOM Framing Alignment/Maintenance State Machine

I show a drawing of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram below in Figure 5.

Figure 5, Drawing of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram

Hence, Figure 5 shows that the OTUk-dLOM Framing Alignment/Maintenance State Machine diagram consists of four states.

dLOM/LL-OOM State
dLOM/LL-IM State
In-Multiframe/LL-IM State
In-Multiframe/LL-OOM State

The OTUk-dLOM Framing Alignment/Maintenance State Machine rides on top of the OTUk-MFAS OOM/IM State Machine. Therefore, we can think of the OTUk-dLOM Framing Alignment/Maintenance State Machine as an extension of this Low-Level State Machine.

Hence, to illustrate that point, I have redrawn the OTUk-dLOM Framing Alignment/Maintenance State Machine diagram (that I show in Figure 5) to show the conditions that cause us to transition from one state to the next within the OTUk-MFAS OOF/IF State Machine. I show this redrawn figure below in Figure 6.

Figure 6, Illustration of the OTUk-dLOM Framing-Alignment/Maintenance State Machine Diagram (with OTUk-MFAS OOF/IF State Machine state change information shown).

The Sink STE will transition through each of the four states (within the OTUk-dLOM Framing Alignment/Maintenance State Machine) as it also transitions through the two states within the OTUk-MFAS OOM/IM Low-Level State Machine.

Whenever the System Operator powers up the Sink STE and starts receiving an OTUk data stream (once it has cleared the dLOF defect), it will continually operate in one of these four states. On occasion, the Sink STE will transition from one state to another. As it does this, it will declare or clear the dLOM defect, as shown in Figures 5 and 6.

We will now walk through the OTUk-dLOM Framing Alignment/Maintenace State Machine.

The dLOM/LL-OOM State

When the System Operator first powers up the Sink STE and is just starting to receive an OTUk data stream, the Sink STE will first clear the dLOF defect condition. Afterward, it will operate in the dLOM/LL-OOM State, as shown below in Figure 7.

Figure 7, Illustration of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram with the dLOM/LL-OOM State Highlighted.

In the expression dLOM/LL-OOM, the reader should already know where the LL-OOM portion (of this state’s name) originates.

When we were discussing the OTUk-MFAS OOF/IF Low-Level State Machine (up above), we stated that whenever we first power up the Sink STE and it is just starting to receive an OTUk data-stream (and has cleared the dLOF defect condition), it will be operating in the LL-OOM state.

What does it mean to be in the dLOM/LL-OOM State?

The dLOM portion (of the expression dLOM/LL-OOM) means that the Sink STE is currently declaring the dLOM defect condition while operating in this particular state.

In summary, whenever the Sink STE is operating in the dLOM/LL-OOM state (within the OTUk-dLOM Framing Alignment/Maintenance State Machine), then we can state the following as fact:

The Sink STE is operating in the LL-OOM State (within the Lower-Level state machine, as we discussed earlier) and
The Sink STE is also declaring the dLOM defect condition (as the name of this state suggests).

Whenever the Sink STE operates in this state, it has NOT located the MFAS byte-fields within the incoming OTUk data stream. As far as the Sink STE is concerned, it only receives some stream of back-to-back OTUk frames. It cannot make sense of anything else within this data stream.

While the Sink STE operates in this state, it will parse through the incoming OTUk data stream and look for the MFAS byte-field.

Whenever the Sink STE has received (what it believes to be the MFAS byte because it immediately follows the FAS field), it will read in the contents of this “Candidate MFAS field.”

Next, the Sink STE will take that “Candidate MFAS field,” and it will insert that value into the following equation and compute a value for Next_Expected_MFAS_Value:

Next_Expected_MFAS_Value = MOD(Candidate_MFAS_Field + 1, 256)

Afterward, the Sink STE will wait an entire OTUk frame period (e.g., 16,320 bytes) later, and it will read out the contents of (what it believes is the MFAS byte). We will call this new byte value the “New_Candidate_MFAS_Value.”

Next, the Sink STE will compare that “New_Candidate_MFAS_Value” with its locally computed “Next_Expected_MFAS_Value,” by testing the following equation:

Next_Expected_MFAS_Value == New_Candidate_MFAS_Value;

If the New_Candidate_MFAS_Value fails the Test

If the Sink STE determines that the New_Candidate_MFAS_Value does NOT match the Next_Expected_MFAS_Value, then it has NOT located the MFAS byte. In this case, the Sink STE will continue to parse through (and search) the incoming OTUk data stream for another candidate MFAS byte.

It will also remain in the dLOM/LL-OOM state.

If the New_Candidate_MFAS_Value passes the Test

On the other hand, if the New_Candidate_MFAS_Value does (indeed) match the value for the Next_Expected_MFAS_Value, then the Sink STE will conclude that it has located the MFAS byte value. In this case, the Sink STE will transition from the LL-OOM state to the LL-IM state within the OTUk-MFAS OOM/IM State Machine.

As the Sink STE makes this transition within the low-level state machine, it will also transition from the dLOM/LL-OOM to the dLOM/LL-IM state within the OTUk-dLOM Framing Alignment/Maintenance State Machine.

The dLOM/LL-IM State

I illustrate the OTUk-dLOM Frame Alignment/Maintenance State-Machine diagram with the dLOM/LL-IM State highlighted below in Figure 8.

Figure 8, Illustration of the OTUk-dLOM Frame Alignment/Maintenance State-Machine Diagram, with the dLOM/LL-IM State highlighted

Whenever the Sink STE has transitioned into the dLOM/LL-IM State, we can state that the Sink STE has located (what appears to be) the MFAS-byte-field within the incoming OTUk data stream.

NOTES:

We refer to this state as the dLOM/LL-IM state because the Sink STE is still declaring the dLOM defect condition (just as it was while operating in the dLOM/LL-OOM state). However, the “LL-IM” portion of the state’s name (e.g., dLOM/LL-IM) reflects the fact that the Sink STE has transitioned into the LL-IM (Low-Level In-Multi-frame) state within the lower-level state machine.
I realize that calling this state the dLOM (Loss of Multi-Frame)/LL-IM (In-Multi-Frame) state is a bit of an oxymoron. In this case, the Sink STE is in-multi-frame because it has located the MFAS byte-field. However, it is still declaring the dLOM defect condition.

While the Sink STE is still operating in the dLOM/LL-IM state, it will perform the task of continuing to confirm whether or not it has located the MFAS byte (within the incoming OTUk data stream).

Whenever the Sink STE is operating in this state, two things can happen from here.

It can eventually transition (or advance) into the “In-Multi-Frame/LL-IM” state, or
It can transition (or regress) back into the dLOM/LL-OOM state.

We will discuss each of these possible events below.

Advancing to the In-Multi-Frame/LL-IM State

ITU-T G.798 requires that the Sink STE remain in the LL-IM state (at the low level) for at least 3ms before it can transition into the next state.

If the Sink STE remains in the dLOM/LL-IM state for at least 3ms (and continues to locate the MFAS byte accurately), then it will do all of the following:

It will transition into the “In-Multi-Frame/LL-IM” state within the OTUk-dLOM Frame Alignment/Maintenance State Machine, and
It will clear the dLOM defect condition (e.g., dLOM ⇒ 0).

I will discuss the In-Multi-Frame/LL-IM State later in this blog post.

Regressing to the dLOM/LL-OOM State

On the other hand, if the Sink STE (while in the dLOM/LL-IM state) were to lose synchronization with the MFAS byte, such that it cannot locate the MFAS byte for at least five (5) consecutive OTUk frame periods, then the Sink STE will transition back into the dLOM/LL-OOM state.

This means that the Sink STE will transition from the LL-IM state back into the LL-OOM state (at the Lower-Level State Machine).

Additionally, the Sink STE will continue to declare the dLOM defect condition.

The In-Multi-Frame/LL-IM State

Once the Sink STE has reached the In-Multi-frame/LL-IM state, we can say that it operates in the NORMAL (or intended) state. We expect the Sink STE to spend most of its operating lifetime in this state.

I show a drawing of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram, with the In-Multi-frame/LL-IM State highlighted below in Figure 9.

Figure 9, Illustration of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram, with the In-Multi-Frame/LL-IM State highlighted.

Whenever the Sink STE operates in the In-Multi-frame/LL-IM state, it can locate the MFAS byte-fields within each incoming OTUk frame.

What Does Clearing the dLOM Defect Mean?

Clearing the dLOM defect also means that the Sink STE should be ready to evaluate other aspects of this incoming OTUk data stream (which requires multi-frame alignment). This includes extracting the following types of data from the incoming OTUk/ODUk data stream.

Within the OTUk Overhead
- SM-TTI (Trail Trace Identification) Messages
Within the ODUk Overhead
- PM-TTI Messages
- APS/PCC Messages
Within the OPUk Overhead
- PSI Messages

The MFAS byte is also critical for those applications where we are mapping and multiplexing lower-speed ODUj tributary signals into higher-speed ODUk server signals (where k > j).

Of course, the Sink STE is telling the whole world this fact by clearing the dLOM defect condition.

Whenever the Sink STE operates in the In-Multi-frame/LL-IM state, it is pretty tolerant of the occurrences of bit errors. In other words, if the Sink STE were to receive an OTUk frame, such that there was (for example) a single-bit error or even a burst of errors that affects an MFAS byte, the Sink STE would remain in the “In-Multi-frame/LL-IM” state.

On the other hand, if the Sink STE were to lose synchronization with the incoming OTUk data stream, such that it cannot locate valid MFAS bytes for five consecutive OTUk frames, then the Sink STE will transition from the LL-IM state into the LL-OOM state (within the Lower-Level State Machine).

Consequently, the Sink STE will transition from the In-Multi-frame/LL-IM state into the In-Multi-frame/LL-OOM state.

We discuss the In-Multi-frame/LL-OOM State below.

The In-Multi-frame/LL-OOM State

I show a drawing of the OTUk-dLOM Frame Alignment/Maintenance State Machine diagram with the In-Multi-frame/LL-OOM State highlighted below in Figure 10.

Figure 10, Drawing of the OTUk-dLOM Multi Frame Alignment/Maintenance State Machine diagram, with the In-Multiframe/LL-OOM State highlighted.

If the Sink STE transitions into the In-Multi-frame/LL-OOM state, this means the following things.

The Sink STE has transitioned from the LL-IM state into the LL-OOM state within the OTUk-MFAS OOM/IM Low-Level State Machine.
The Sink STE is still NOT declaring the dLOM (Loss of Multi-frame) defect condition (e.g., dLOM = 0).

NOTE: We refer to this state as the “In-Multi-frame/LL-OOM” state because the Sink STE is still NOT declaring the dLOM defect condition (just as it was NOT while operating in the In-Multi-frame/LL-IM state).

However, the LL-OOM portion of the state’s name (e.g., In-Multi-frame/LL-OOM) reflects that the Sink STE has transitioned into the LL-OOM state (within the Low-Level State Machine).

Only one of two possible things will happen whenever the Sink STE enters the In-Multi-frame/LL-OOM state.

The Sink STE will eventually re-acquire synchronization with the incoming MFAS bytes (within the OTUk data-stream), and it will advance back into the In-Multi-frame/LL-IM state or
The Sink STE does not re-acquire synchronization with the incoming MFAS bytes (within the OTUk data-stream), and it eventually regresses into the dLOM/LL-OOM state.

We will briefly discuss these two possible events below.

Advancing Back into the In-Multi-Frame/LL-IM State

If the Sink STE can locate and re-acquire the MFAS bytes (within the incoming OTUk data-stream), it will transition back into the In-Multi-Frame/LL-IM State. In this case, the Sink STE will continue to clear the dLOM defect condition (dLOM = 0).

Regressing to the dLOM/LL-OOM State

ITU-T G.798 requires that the Sink STE reside in the In-Multi-Frame/LL-OOM state for 3ms before it can transition into the dLOM/LL-OOM state and declare the dLOM defect condition.

This means that if the Sink STE cannot locate the MFAS-field (for 3ms after transitioning into the In-Multi-Frame/LL-OOM state), it will transition into the dLOM/LL-OOM state.

Whenever the Sink STE transitions into the dLOM/LL-OOM state, it will declare the dLOM defect condition (dLOM = 1).

In Summary

ITU-T G.798 requires that the Sink STE be able to locate the MFAS byte and consistently remain in the LL-IM state for at least 3ms before it can clear the dLOM defect condition (e.g., dLOM ⇒ CLEARED).

Further, ITU-T G.798 also requires that the Sink STE NOT be able to locate the MFAS byte and remain in this condition (e.g., the LL-OOM state) for at least 3ms before it can declare the dLOM defect condition (e.g., dLOM ⇒ DECLARED).

ITU-T G.798 imposes these 3ms persistency requirements (for declaring and clearing the dLOM defect) to prevent intermittent transitions between the LL-OOM and LL-IM states from causing sporadic changes (or chattering) in the dLOM state.

Table 1 summarizes the dLOM Defect Condition and how its State affects an OTN STE’s Operation.

Table 1, Summary of the dLOM Defect Condition and How its State affects an OTN STE’s Operation

Item	Description
Meaning of the dLOM Defect Condition	The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) will declare the dLOM defect, if it has cleared the dAIS and the dLOF defect conditions, but it is not able to reliably locate the MFAS bytes and OTUk Multi-frame boundaries, within the incoming OTUk data-stream. In other words, the Sink STE will declare the dLOM defect if it is able to find the FAS fields (within each incoming OTUk frame) but it still not able to reliably locate the MFAS bytes and align itself with each incoming 256-frame OTUk multi-frame.
Requirements to declare dLOM	The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) will declare the dLOM defect if it loses synchronization with the incoming MFAS bytes (and their increment value) for at least 3ms.
Requirements to clear dLOM	The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) will clear the dLOM defect if it is able to maintain synchronization with the incoming (and incrementing) MFAS byte-fields (within the OTUk data-stream) for at least 3ms.
Any defects that will suppress the dLOM defect?	Yes, the dAIS (OTUk-AIS) and dLOF defects. Or if upstream circuitry is declaring the Trail Signal Fail defect condition. If the Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) declares any of these defect conditions, then it cannot declare the dLOM defect.
Impact of declaring the dLOF defect on other defect conditions within the Sink STE	The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) should not declare any of the following defects, whenever it is also declaring the dLOM defect. - dTIM, and - dDEG
Impact of declaring the dLOM defect to Performance Monitoring.	None

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

Discounts Available for a Short Time!!

Click on the Image Below to see More OTN-Related Blog Posts.

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

This post briefly discusses the OTSiG/OTUk_A_Sk (OTSiG to OTUk Adaptation Sink) Function for OTU3 and OTU4 Applications.

What is the OTSiG/OTUk_A_Sk Atomic Function?

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

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

Changes in Terminology

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

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

What is an OTSiG?

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

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

In other words, an OTSiG supports transporting an OTUk signal over multiple lanes in parallel.

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

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

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

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

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

Corporate Discounts Available!!

Some More Information about Multi-Lane Interfaces for OTU3 and OTU4 Applications

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

We will use the OTSiG/OTUk_A_Sk function for OTU3 applications to model circuitry that receives and processes an OTU3 data stream via an OTL3.4 interface. ITU-T G.709 defines the OTL3.4 Interface as an approach to transporting OTU3 traffic over 4-lanes in parallel.

Likewise, we will use the OTSiG/OTUk_A_Sk function for OTU4 applications to model circuitry that receives and processes an OTU4 data stream via an OTL4.4 interface. ITU-T G.709 also defines the OTL4.4 Interface as an approach to transporting OTU4 traffic over 4-lanes in parallel.

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

The OTSiG/OTUk_A_Sk Function

The OTSiG/OTUk_A_Sk function is any circuit that takes a group of four electrical lane signals (e.g., the OTSiG signal) and converts this data back into the OTUk signal.

More specifically, the System-Designer will apply this OTSiG group of signals (which are of the OTL3.4 format for OTU3 applications and the OTL4.4 format for OTU4 applications) to the OTSiG_AP Input Interface.

NOTE: These OTL3.4 or OTL4.4 format signals carry a fully-framed, scrambled OTU3 or OTU4 data stream, often including Forward-Error-Correction.

The OTSiG/OTUk_A_Sk function will then:

Multiplex each of these four electrical lanes (of the OTL3.4 or OTL4.4 signals) back into a single OTU3 or OTU4 data stream.
Afterward, this function will descramble this OTU3/4 data stream, decode the FEC, and then convert this group of signals into OTUk data, clock, frame-start, and multi-frame-start signals.
Finally, this function will output these signals to downstream circuitry (such as the OTUk_TT_Sk function).

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

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

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

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

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

Versions of the OTSiG/OTUk_A_Sk Function

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

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

Function Name	Description	Comments
OTSiG/OTUk-a_A_Sk	OTSiG to OTUk Adaptation Sink Function with ITU-T G.709 Standard FEC.	Can be used for OTU3 and OTU4 applications ONLY.
OTSiG/OTUk-b_A_Sk	OTSiG to OTUk Adaptation Sink Function with No FEC.	Can be used for OTU3 Applications.
OTSiG/OTUk-v_A_Sk	OTSiG to OTUk Adaptation Sink Function with Vendor-Specific FEC	Can be used for OTU3 and OTU4 Applications. Not specified by ITU-T G.798.

Table 1 shows that the OTSiG/OTUk-a_A_Sk and the OTSiG/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 OTSiG/OTUk-b_A_Sk version does not support FEC decoding.

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

Network Equipment operating at the OTU4 rate is required to use Forward-Error-Correction.

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

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

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

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

Discounts Available for a Short Time!!

So What All Does this Atomic Function Do – In Detail?

The OTSiG/OTUk-a_A_Sk function will accept the 4-lanes of traffic that make up the OTSiG signals from upstream Optical-to-Electrical Conversion circuitry. This function will perform the following tasks on this incoming data stream.

Multiplexing – It will multiplex each of the four lanes of traffic of the OTL3.4 or OTL4.4 signal back into a single OTU3 or OTU4 signal, respectively.
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.
- dLOS-P – Loss of Signal – Path (for each of the four electrical lanes)
- dLOFLANE – Loss of Frame, Lane Signal – (for each of the 4 or 20 logical lanes)(*)
- dLOF – Loss of Frame (Optional)
- dLOM – Loss of Multiframe
- dLOL – Loss of Lane Alignment (*)
Assert the CI_SSF (Server Signal Fail Indicator) output signal (towards the downstream OTUk_TT_Sk function) anytime it declares any service-affecting defect.
Output the remaining OTUk data stream, the OTUk clock signal, the Frame-Start, and Multiframe Start signals to downstream circuitry (e.g., typically the OTUk_TT_Sk atomic function).

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

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

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

Functional Description of this Atomic Function

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

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

Afterward, we will do the same for OTU4 applications.

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

Figures 3 and 4 present the Functional Block Diagram of the OTSiG/OTUk-a_A_Sk Atomic Function for OTU3 applications.

NOTE: The Functional Block Diagrams for this function are rather large and complicated. Therefore, I had to spread the OTU3 Functional Block Diagram over two figures (Figures 3 and 4).

More specifically, Figure 3 presents the OTUk_CP Side of the OTSiG/OTUk-a_A_Sk function, and Figure 4 shows the OTSiG_AP Side of this function.

Figure 3, The OTUk_CP Interface Side of the OTSiG/OTUk-a_A_Sk function.

Figure 4, The OTSiG_AP Interface Side of the OTSiG/OTUk-a_A_Sk function.

Therefore, Figures 3 and 4 show that the OTU3-version of this function contains the following functional blocks.

Clock-Recovery and LOS-Detection Block
Lane Frame Alignment Block
The Lane Alignment Recovery Block
Lane-Marker and Delay-Processing Block
Elastic Store
16-Byte Block MUX
(OTU3) Frame-Alignment and dLOF-Detection Block
Descrambler Block
FEC Decoder Block
Multi-Frame Alignment and dLOM Detection Block

I will briefly discuss each of these functional blocks below.

The Clock-Recovery and dLOS-Detection Block (4 for OTU3 Applications)

Once our 4-lane Optical Signal passes through the Optical-to-Electrical Conversion (or Demodulator) circuitry, it will be an electrical OTL3.4 signal. The System-Designer should route each of these OTL3.4 electrical lanes signals to the AI_PLD[1] to AI_PLD[4] inputs to this function.

Once these electrical signals enter the OTSiG/OTU3-a_A_Sk function, they will pass through their corresponding Clock Recovery and dLOS Detection Block.

I show an illustration of the OTSiG_AP Side of the OTSiG/OTU3-a_A_Sk Functional Block Diagram below with the Clock Recovery and dLOS Detection blocks, highlighted below in Figure 5.

Figure 5, Illustration of the OTSiG_AP Side of the OTSiG/OTU3-a_A_Sk Functional Block Diagram, with the Clock Recovery and dLOS Detection blocks highlighted.

The OTSiG/OTU3-a_A_Sk function has four Clock Recovery and dLOS Detection Blocks (one for each of the four lanes within the incoming OTL3.4 signal).

The Clock Recovery block is responsible for recovering the clock signal and the data content within a given OTL3.4 lane signal via its corresponding AI_PLD[n] input pin.

Since the OTSiG/OTUk-a_A_So atomic function (at the remote STE) should have scrambled this data stream, each of these incoming lane signals should always have good timing content (or transitions) so that this Clock Recovery block can acquire and extract out both a recovered clock signal and data-stream from each of these incoming lane signals.

Suppose the Clock Recovery block (along with the dLOS Detection Block) were to determine that there is a lengthy absence in signal transitions (within its incoming lane data-stream). In that case, it will declare the dLOS-P (Loss of Signal – Path) defect for that particular electrical lane.

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

The OTSiG/OTUk-a_A_Sk function will route this recovered clock and data signal (for each electrical lane) to its Lane Frame Alignment block for further processing.

Lane Frame Alignment Block (4 for OTU3 Applications)

The OTSiG/OTU3-a_A_Sk function contains 4 Lane Frame Alignment blocks, one for each Logical (or Electrical) Lane.

I show an illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Lane Frame Alignment Blocks highlighted below in Figure 6.

Figure 6, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Lane Frame Alignment Blocks highlighted.

In the OTL3.4 post, we mention that (as we create these OTL3.4 lane signals, we purpose “Lane Rotation” as each frame boundary to ensure that each logical lane will carry the FAS-field at some point.

These Lane Frame Alignment blocks aim to acquire FAS-Frame Synchronization with their corresponding Logical Lane signal. In other words, these Lane Frame Alignment blocks strive to locate each FAS field and maintain a Lane-FAS Frame synchronization with their respective lanes.

Each Lane Frame Alignment block will also declare and clear the dLOFLANE (Loss of Frame – Lane) defect condition as appropriate. Please see the post on the dLOFLANE defect for more information about this defect condition.

The OTSiG/OTU3-a_A_Sk Function will route these logical lane signals to their own Lane Alignment Recovery Blocks.

Lane Alignment Recovery Block (4 for OTU3 Applications)

The OTSiG/OTU3-a_A_Sk Function contains four Lane Alignment Recovery blocks (one for each Logical Lane it processes).

I show an illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Lane Alignment Recovery blocks highlighted below in Figure 7.

Figure 7, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Lane Alignment Recovery blocks highlighted.

These Lane Alignment Recovery blocks aim to acquire LLM (Logical Lane Marker) Frame Synchronization with its corresponding Logical Lane signal.

The Lane Alignment Recovery blocks also have the following responsibilities:

To report the LLM value, within its logical lane, to the Lane Marker and Delay Processing block, and
To alert the Lane Marker and Delay Processing block, the instant that (the Lane Alignment Recovery block) detects and receives the LLM fields within its incoming Logical Lane data stream.

Four blocks will work in tandem with the Lane Marker and Delay Processing block to declare and clear the dLOL (Loss of Lane Alignment) defect condition.

Please see the blog post on the dLOL defect to learn more about this defect condition.

Once a given Logical Lane signal passes through the Lane Alignment Recovery block, the OTSiG/OTU3-a_A_Sk function will route these signals to the Elastic Store block for further processing.

Lane Marker and Delay Processing Block (1 for OTU3 Applications)

The OTSiG/OTU3-a_A_Sk function only has one Lane Marker and Delay Processing block.

I illustrate the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Lane Marker and Delay Processing Block highlighted below in Figure 8.

Figure 8, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Lane Marker and Delay Processing Block highlighted.

The Lane Marker and Delay Processing block have the following responsibilities:

To declare and clear the dLOL defect condition.
To compensate for skew between each of the four Logical Lanes.
And to ensure that each Logical Lane will be processed in the correct order/sequence, the OTSiG/OTU3-a_A_Sk function will successfully reconstruct the original OTU3 data stream.
To ensure that each Logical Lane has its unique value for the LLM ID.

To accomplish this, the Lane Marker and Delay Processing block will work in tandem with each of the 4 Lane Alignment Recovery blocks and the Elastic Store blocks.

In general, the Lane Marker and Delay Processing block will use the “LLM Received” information from each of the 4 Lane Alignment Recovery blocks to determine the amount of skew between them.

The Lane Marker and Delay Processing block will use the Elastic Store blocks to buffer and delay all of the “faster” Logical lanes until the “slowest” (or most delayed) Logical Lane “catches up.”

Once this slowest Logical Lane catches up, the Lane Marker and Delay Processing block will allow the 16-Byte MUX to read out the contents of the logical lane data from each of the 4 Elastic Store blocks.

The Elastic Store Block (4 for OTU3 Applications)

The OTSiG/OTU3-a_A_Sk function contains four Elastic Store blocks (one for each Logical Lane).

I illustrate the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Elastic Store blocks highlighted below in Figure 9.

Figure 9, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Elastic Store blocks highlighted.

The Elastic Store block is an array of buffers (or storage) within the four logical lanes. The OTSiG/OTU3-a_A_Sk function will load the contents of each Logical Lane data stream into this buffer as it arrives at this block.

However, the Lane Marker and Delay Processing Block will determine how long this data will remain in this Elastic Store block before it travels downstream towards the 16-Byte Block MUX.

The Lane Marker and Delay Processing block will control exactly when this Logical Lane data is read out from each of the 4 Elastic Store blocks to compensate for skew between each Logical Lanes.

16-Byte Block MUX (1 for OTU3 Applications)

The OTSiG/OTU3-a_A_Sk function contains one 16-Byte Block MUX.

I show an illustration of the OTUk_CP Interface Side of the OTSiG/OTU3-a_A_Sk Functional Block Diagram, with the 16-Byte Block MUX highlighted below in Figure 10.

Figure 10, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram (OTUk_CP Side) with the 16-Byte Block MUX Highlighted.

The purpose of the 16 Byte Block MUX is to read out the contents of each of the Elastic Store blocks (with each of the four Logical Lanes) and to multiplex this data into a single OTU3 data stream.

The 16 Byte Block MUX (as its name implies) will read out data, 16 bytes at a time, from each of the four Elastic Store blocks. Additionally, the 16-Byte Block MUX will execute these READ Operations under the direction of the Lane Marker and Delay Processing block.

The 16 Byte Block MUX, the Lane Marker, and Delay Processing Blocks, and the Lane Alignment Recovery blocks will work together to:

Compensate for skew between each of the Logical Lanes, and
Properly multiplex and (reassemble) a full-blown, serial OTU3 data stream.

After the 16-Byte Block MUX has reassembled this OTU3 data stream, it will route this data stream over to the (OTU3) Lane Frame Alignment and dLOF Detection Block for further processing.

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

Corporate Discounts Available!!!

(OTU3) Frame Alignment and dLOF Detection Blocks

Once our data stream has reached the Frame Alignment and dLOF Detection Block, we are no longer working with OTL3.4 Logical Lanes. The 16 Byte Block MUX has multiplexed all four logical lanes into a single OTU3 data stream.

I illustrate the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Frame Alignment and dLOF Detection Blocks highlighted below in Figure 11.

Figure 11, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Frame Alignment and dLOF Detection Blocks highlighted.

The only question now is: Did we multiplex the four OTL3.4 Logical Lanes together correctly?

If we were to assume all of the following conditions to be true:

That none of the four Frame Alignment Blocks (within the OTSiG/OTU3-a_A_Sk function) were declaring the dLOFLANE defect condition, and
The Lane Marker and Delay Processing block did not report any issues with Excessive Skew.

Then the 16-Byte Block MUX should have correctly and successfully multiplexed these four Logical Lanes into a single valid OTU3 data stream.

However, the (OTU3) Frame Alignment and dLOF Detection Block can serve as an additional check to ensure that our multiplexing operation is successful. This is why I’ve listed this particular functional sub-block as “Optional.”

This sub-block aims to acquire and maintain OTUk-FAS Frame Synchronization with this newly combined OTU3 data stream. If this block fails to obtain and maintain synchronization with the incoming FAS frames, it will declare the dLOF (Loss of Frame) defect condition.

Please see the dLOF (Loss of Frame) blog post for more information on how the Frame Alignment and dLOF Detection Block declare and clear the dLOF defect condition.

Once this OTU3 data stream leaves the Frame Alignment and dLOF Detection Block, it will enter the Descrambler Block for further processing.

Descrambler Block

In the OTSiG/OTUk-a_A_So blog post, I mentioned that the OTSiG/OTUk-a_A_So function would scramble the content of each outbound 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 by the remote STE.

I show an illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Descrambler block highlighted below in Figure 12.

Figure 12, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Descrambler block highlighted.

In the OTSiG/OTUk-a_A_So function, we scrambled the contents of OTUk frame, using the polynomial generating equation of 1 + x + x³ + x¹² + x¹⁶.

Therefore, the Descrambler block (within this function) will descramble the incoming OTUk data-stream (again) using the polynomial generating equation of 1 + x + x³ + x¹² + x¹⁶.

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

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

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

Once the OTU3 data stream passes through and exits the Descrambler block, it will proceed onto the FEC Decoder block for further processing.

FEC Decoder Block

I illustrate the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the FEC Decoder block highlighted below in Figure 14.

Figure 14, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the FEC Decoder block highlighted.

The OTSiG/OTU3-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 OTU3 frame, as shown below in Figure 15.

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

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

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

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

Multi-Frame Alignment and dLOM Detection Block

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

I illustrate the OTSiG/OTU3-a_A_Sk Function Block Diagram with the Multi-Frame Alignment and dLOM Detection block, highlighted below in Figure 16.

Figure 16, Illustration of the OTSiG/OTU3-a_A_Sk Functional Block Diagram with the Multi-Frame Alignment and dLOM Detection Block highlighted.

The Mult-Frame Alignment block will parse through and check the contents of the MFAS field within the incoming OTU3 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 (Loss of Multi-Frame Alignment) 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 OTU3 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 towards 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.

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

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

Corporate Discounts Available!!!

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

I present the Functional Block Diagram of the OTSiG/OTUk-a_A_Sk Atomic Function for OTU4 Applications below in Figures 14, 15, and 16.

NOTE: The Functional Block Diagrams for this function are rather large and complicated. Therefore, I had to spread the OTU3 Functional Block Diagram over three figures (Figures 17, 18, and 19).

Figure 17 presents the OTUk_CP Side of the OTSiG/OTUk-a_A_Sk function.

Figure 17, Illustration of the Functional Block Diagram of the OTSiG/OTU4-a_A_Sk Atomic Function – The OTUk_CP Interface Side

Additionally, Figure 18 presents the Middle Portion of the OTSiG/OTUk-a_A_Sk function.

Figure 18, Illustration of the Functional Block Diagram of the OTSiG/OTU4-a_A_Sk Atomic Function – The Middle Portion

Finally, Figure 19 shows the OTSiG_AP Side of this function.

Figure 19, Illustration of the Functional Block Diagram of the OTSiG/OTU4-a_A_Sk Atomic Function – The OTSiG_AP Interface Side

Hence, these figures show that the OTU4 version of this function contains the following functional sub-blocks.

The Clock Recovery and dLOS Detector Block
The 1/5 Bit De-Interleaver Blocks
The Lane Frame Alignment Blocks
The Lane Alignment Recovery Blocks
The LLM Removal Block
The Lane Marker and Delay Processing Block
The Elastic Store Blocks
The 16-Byte Block MUX
The (OTU4) Frame Alignment – dLOF Detection Block
The Descrambler Block
The FEC Decoder Block
The Multi-Frame Alignment and dLOM Detection Block

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

The Clock Recovery and dLOS Detection Block (4 for OTU4 Applications)

Please see the description for the Clock Recovery and dLOS Detection Block above for OTU3 applications.

The 1/5 Bit De-Interleaver Blocks (4 for OTU4 Applications)

Once the OTL4.4 signal passes through the Clock Recovery block, it will proceed onto the 1/5 Bit De-Interleaver blocks for further processing.

The OTSiG/OTU4-a_A_Sk function contains four of these 1/5 Bit De-Interleaver Blocks.

I illustrate the OTSiG/OTU4-a_A_Sk Functional Block Diagram with the 1/5 Bit De-Interleaver blocks highlighted below in Figure 20.

Figure 20, Illustration of the OTSiG/OTU4-a_A_Sk Functional Block Diagram with the 1/5 Bit De-Interleavers blocks highlighted.

Each lane (within the incoming OTL4.4 signal) will pass through its own 1/5 Bit De-Interleaver Blocks.

Each of these 1/5 Bit De-Interleaver blocks will bit-wise demultiplex five logical lanes of traffic from each incoming electrical lane. Therefore, when the four lanes (within an OTL4.4 signal) pass through their own 1/5 Bit De-Interleaver blocks, they will demultiplex this OTL4.4 signal into 20 logical lanes of traffic.

The Lane Frame Alignment Block (20 for OTU4 Applications)

Please see the description for the Lane Frame Alignment Block above for OTU3 applications. Please note that the OTSiG/OTU4-a_A_Sk function will have 20 blocks, whereas the OTU3 version only has 4.

The Lane Alignment Recovery Blocks (20 for OTU4 Applications)

Please see the description for the Lane Alignment Recovery Block above for OTU3 applications. Please note that the OTSiG/OTU4-a_A_Sk function will have 20 blocks, whereas the OTU3 version only has 4.

The LLM (Logical Lane Marker) Removal Blocks (20 for OTU4 Applications)

Once each Logical Lane signal passes through and exits their Lane Alignment Recovery block, they will proceed to their respective LLM Removal Blocks.

I illustrate the OTSiG/OTU4-a_A_Sk functional block diagram with the LLM Removal Blocks highlighted below in Figure 21.

Figure 21, Illustration of the OTSiG/OTU4-a_A_Sk Functional Block Diagram with the LLM Removal Blocks highlighted.

If you recall, from our OTL4.4 post, the OTSiG/OTU4-a_A_Sk function (at the remote STE) will “borrow” the 3rd OA2 byte (within the FAS field of each outbound OTU4 frame) and use it as the LLM (Logical Lane Marker) field.

I illustrate the OTU4 Frame format with this LLM (and borrowed OA2) byte-field highlighted below in Figure 22.

Figure 22, Illustration of an OTU4 Frame with the LLM Field location highlighted.

The purpose of the LLM Removal (in this function) is to remove the LLM field from this 3rd OA2 byte-field and (effectively) give this byte back to the transport system by restoring its value to 0x28.

Once the Logical Lane data stream passes through to the LLM Removal Block, it will proceed to the Elastic Store block for further processing.

The Lane Marker and Delay Processing Block (1 for OTU4 Applications)

Please see the description for the Lane Marker and Delay Processing Block above for OTU3 applications. Please note that the Lane Marker and Delay Processing Block within the OTSiG/OTU4-a_A_Sk function will be working with 20 sets of the Lane Alignment Recovery and Elastic Store Blocks for Skew Compensation purposes.

The Elastic Store Blocks (20 for OTU4 Applications)

Please see the description for the Elastic Store Block above for OTU3 applications. Please note that the OTSiG/OTU4-a_A_Sk function will have 20 blocks, whereas the OTU3 version only has 4.