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 3 – OTU Layer Sink Direction Circuitry – Part 1

This post presents the 3rd 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 3 – OTU Layer Sink Direction Circuitry/Functionality – Part 1

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

This Video starts with a brief re-cap of a portion of the OTSiG/OTUk_A_Sk Atomic Function (aka OTL4.4 Sink Terminal).

In this case, I specifically call out and identify portions of this Atomic Function that we discussed in Lessons 6 or 7 and those portions that we did not.

In Lesson 7, we discussed that part of the OTSiG/OTUk_A_Sk function handled OTL4.4 or OTL4.20 logical lane signals.
Lesson 6 also discussed part of the OTSiG/OTUk_A_Sk function that handled the OTL3.4 lane signal.

I also show you the differences between the OTU3 version of the OTSiG/OTUk_A_Sk function and that for OTU4.

Late in this Video, we start to discuss that portion of the OTSiG/OTUk_A_Sk function that handles the combined (composite) OTU3/OTU4 signal. This portion includes

Discussing how the OTSiG/OTUk_A_Sk function declares and clears the dLOF defect by reviewing the Frame Alignment Block – dLOF/In-Frame State Machine Diagram, and
Descrambling of the OTU3/OTU4 data stream.

Continue reading “OTN – Lesson 9 – Video 3 – OTU Layer Sink Direction Circuitry – Part 1”

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 dLOF Defect

This post briefly describes the dLOF (Loss of Frame) Defect Condition. It describes when an OTN STE should declare and clear the dLOF defect condition.

How an OTN STE should declare and clear the dLOF (Loss of Frame) Defect Condition

The purpose of this post is to describe how an OTN STE (Section Terminating Equipment) will declare and clear the dLOF (Loss of 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 dLOF defect condition are:

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

Each of these atomic functions includes the dLOF Detection circuit. However, if you look closely at the OTSiG/OTUk_A_Sk function post, you will see that I do show that this particular dLOF Detection circuit is optional.

A Note About Terminology:

Throughout this blog post, I will refer to the entity containing the dLOF Detection circuit (and declares/clears the dLOF 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 the words: OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions. However, I will use atomic function-related terms below in Table 1 (at the bottom of this post).

A Brief Review of the OTUk Frame Structure

In the OTUk Post, we mentioned that the OTUk frame consists of six framing alignment signal (FAS) bytes.

I present an illustration of the OTUk Frame Structure, with the FAS field highlighted below in Figure 1.

Figure 1, Illustration of the OTUk Frame Structure, with the FAS-Field Highlighted

Figure 1 shows that the FAS field consists of 3-byte fields (which I’ve labeled OA1) and another set of 3-byte fields, which I’ve labeled OA2.

The OA1 byte fields are each set to the fixed value of 0xF6. Similarly, the OA2 byte fields are each set to the specified value of 0x28.

Hence, this 6-byte FAS field will (for each OTUk frame) always have the fixed pattern of 0xF6, 0xF6, 0xF6, 0x28, 0x28, 0x28.

Since each OTUk frame is a 4080-byte column x 4-row structure, each frame contains 16,320 bytes. Therefore, we know that a Sink STE (or OTSi/OTUk_A_Sk function) will always receive this fixed pattern of six bytes (e.g., the FAS field) every 16,320 byte-periods.

Now that we are armed with this information, we can discuss how the Sink STE will declare and clear the dLOF defect.

The dLOF-Related State Machines

Anytime the Sink STE is powered-up and receives a stream of OTUk data, it will continually operate per two sets of state machines simultaneously.

The OTUk-FAS OOF/IF Low-Level State Machine and
The OTUk-dLOF 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-FAS OOF/IF Low-Level State Machine), and the other state machine (e.g., the OTUk-dLOF Framing Alignment/Maintenance State Machine) operates at a higher level (on top of the lower-level state machine).

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

Figure 2, Illustration of the relationship between the two dLOF-Related State Machines

We will discuss each of these two state machines below.

The OTUk-FAS OOF/IF Low-Level State Machine

We will discuss the OTUk-FAS OOF/IF Low-Level State Machine first, and then we will discuss the OTUk-dLOF Framing Alignment/Maintenance State Machine later.

I present an illustration of the OTUk-FAS OOF/IF Low-Level State Machine Diagram below in Figure 3.

Figure 3, Illustration of the OTUk-FAS OOF/IF Low-Level State Machine Diagram

Figure 3 shows that the OTUk-FAS OOF/IF Low-Level State Machine consists of the following two states:

The LL-OOF (Low-Level Out-of-Frame) State and
The LL-IF (Low-Level In-Frame) State

From the moment the System Operator powers up the Sink STE circuitry and feeds an OTUk data stream to it (from the remote Source STE), it will continuously operate in one of these two states.

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

We will discuss each of these two states below.

The LL-OOF State

Whenever the System Operator first powers up a Sink STE and starts receiving an OTUk data stream (from the remote Source STE), it will operate in the LL-OOF state.

The Sink STE has not located the FAS-bytes (and the OTUk frame boundaries). Therefore, the Sink STE cannot “make sense” of this data.

While the Sink STE operates in this state, it will begin to parse through the incoming OTUk data stream. It will search for the occurrence of the FAS pattern within this data stream.

Earlier, I mentioned that this FAS-field is a 6-byte field that consists of the following fixed pattern: 0xF6, 0xF6, 0xF6, 0x28, 0x28, 0x28.

ITU-T G.798’s Requirement for Searching for the FAS field

ITU-T G.798 states that the Sink STE when operating the LL-OOF state, MUST look for a 4-byte subset of this 6-byte FAS pattern. Therefore, this 4-byte FAS pattern could be any one of the following patterns.

0xF6, 0xF6, 0xF6, 0x28
0xF6, 0xF6, 0x28, 0x28
or 0xF6, ox28, ox28, ox28

Whenever the Sink STE has detected a set of four consecutive bytes that resembles a four-byte subset of the FAS field (as we’ve listed above), then the Sink STE will then wait an entire OTUk frame period (e.g., 16,320 bytes later) and it will check and see if that same FAS pattern is present then again.

If the Sink STE does not find the FAS pattern (one OTUk frame period later), then it will continue to parse through the incoming OTUk data stream and search for a 4-byte subset of the FAS pattern.

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

On the other hand, if the Sink STE does (indeed) find the FAS pattern (one OTUk frame period later), then the Sink STE will transition into the LL-IF state.

We will discuss the LL-IF State below.

The LL-IF State

Once the Sink STE enters the LL-IF state, it will continue to check for the presence of the FAS field at OTUk-frame intervals.

NOTE: Once the Sink STE enters the LL-IF state, ITU-T G.798 only requires it to check for a 3-byte subset of the FAS-field. Specifically, the standard states that the Sink STE must continue to check for the presence of the OA1, OA2, and OA2 (e.g., 0xF6, 0x28, 0x28) patterns at each OTUk frame interval.

As long as the Sink STE can consistently locate these FAS bytes at each OTUk frame interval, it will remain in the LL-IF state.

However, suppose the Sink STE were to lose synchronization with the FAS-field (of each incoming OTUk frame) such that it could not locate the FAS-field for five (5) consecutive OTUk frame periods. In that case, the Sink STE function will transition back into the LL-OOF state.

NOTE: The OTUk-FAS OOF/IF Low-Level State Machine algorithm tolerates bit errors. In other words, the presence of occasional bit errors is not enough to cause the Sink STE to transition from the LL-IF state back into the LL-OOF state.

Now that we have discussed the OTUk-FAS OOF/IF Low-Level State Machine, let’s move on and discuss the OTUk-dLOF Framing Alignment/Maintenance State Machine.

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

Discounts Available for a Short Time!!!

The OTUk-dLOF Framing Alignment/Maintenance State Machine

Figure 4 illustrates the OTUk-dLOF Framing Alignment/Maintenance State-Machine Diagram.

Figure 4, Illustration of the OTUk-dLOF Framing-Alignment/Maintenance State Machine Diagram (with State Machine Transition Criteria shown)

Hence, Figure 4 shows that the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram consists of the following four states.

dLOF/LL-OOF State
dLOF/LL-IF State
In-Frame/LL-IF State
In-Frame/LL-OOF State

The OTUk-dLOF Framing Alignment/Maintenance State Machine “rides” on top of the OTUk-FAS OOF/IF State Machine. Therefore, we can think of the OTUk-dLOF Framing Alignment/Maintenance State Machine as an extension of this Low-Level State Machine.

Hence, to illustrate that point, I have redrawn the OTUk-dLOF Framing Alignment/Maintenance State Machine diagram (that I show in Figure 4) to also show the underlying state changes within the OTUk-FAS OOF/IF State Machine. I show this redrawn figure below in Figure 5.

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

The Sink STE will transition through each of the four states (within the OTUk-dLOF Framing Alignment/Maintenance State Machine) as it also transitions between the two states within the OTUk-FAS OOF/IF Low-Level State Machine.

Whenever the System-Operator powers up the Sink STE and starts receiving an OTUk data stream, 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, it will either declare or clear the dLOF defect, as shown in Figures 4 and 5.

We will now “walk” through the OTUk-dLOF Framing Alignment/Maintenance State Machine.

The dLOF/LL-OOF State

Whenever the System Operator first powers up the Sink STE and is just starting to receive an OTUk data stream, it will initially operate in the dLOF/LL-OOF State, as I show below in Figure 6.

Figure 6, Illustration of the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram with the dLOF/LL-OOF State Highlighted.

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

When we were discussing the OTUk-FAS OOF/IF Low-Level State Machine (up above), we stated that whenever we power up the Sink STE, it is just starting to receive an OTUk data stream. It will be operating in the LL-OOF state.

What does it mean to be in the dLOF/LL-OOF State?

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

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

The Sink STE is operating in the LL-OOF state (within the lower-level state machine, as we discussed earlier), and
The Sink STE also declares the dLOF defect condition (as the name of this state suggests).

Whenever the Sink STE operates in this state, it has NOT located the FAS fields nor the boundaries of any OTUk frames within the incoming OTUk data stream. As far as the Sink STE is concerned, it receives nonsensical data.

While the Sink STE is operating in this state, it will parse through the incoming OTUk data stream and look for the four-byte subset of the FAS field (as we discussed earlier).

Whenever the Sink STE has detected a set of four consecutive bytes that resembles a four-byte subset of the FAS field, the Sink STE will then wait an entire OTUk frame period (e.g., 16,320 bytes) later, and it will check and see if that same FAS pattern is again present, within the OTUk data-stream.

If the Sink STE Fails to Find the FAS field

If the Sink STE does not find the FAS pattern (one OTUk frame period later), it will continue to parse through (and search) the incoming OTUk data stream for that 4-byte subset of the FAS pattern.

It will also remain in the dLOF/LL-OOF state.

If the Sink STE Successfully Locates the FAS field

On the other hand, if the Sink STE does (indeed) find the FAS pattern (one OTUk frame period, later), then the Sink STE will transition from the LL-OOF state to the LL-IF state within the OTUk-FAS OOF/IF State Machine.

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

The dLOF/LL-IF State

I illustrate the OTUk-dLOF Frame Alignment/Maintenance State-Machine diagram with the dLOF/LL-IF State highlighted below in Figure 7.

Figure 7, Illustration of the OTUk-dLOF Frame Alignment/Maintenance State-Machine Diagram, with the dLOF/LL-IF State highlighted.

Whenever the Sink STE has transitioned into the dLOF/LL-IF state, we can state that the Sink STE has located (what appears to be) the FAS fields within the incoming OTUk data stream.

NOTES:

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

While the Sink STE is operating in the dLOF/LL-IF state, it will perform the task of continuing to confirm whether or not it has located the FAS bytes (within the incoming OTUk data stream).

Two possible things can happen from here whenever the Sink STE is operating in this state.

It can eventually transition (or advance) into the “In-Frame/LL-IF” state, or
It can transition (or regress) back into the dLOF/LL-OOF state.

We will discuss each of these possible events below.

Advancing to the In-Frame/LL-IF State

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

If the Sink STE remains in the dLOF/LL-IF state for at least 3ms (and continues to locate the FAS bytes accurately), then it will do all of the following:

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

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

Regressing to the dLOF/LL-OOF State

On the other hand, if the Sink STE (while operating in the dLOF/LL-IF state) were to lose synchronization with the FAS byte-fields, it can no longer locate the FAS bytes for at least five (5) consecutive OTUk frame periods. The Sink STE will transition back into the dLOF/LL-OOF state.

This means that the Sink STE will transition from the LL-IF state back into the LL-OOF state (within the Lower-Level State Machine).

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

The In-Frame/LL-IF State

Once the Sink STE has reached the In-Frame/LL-IF 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 illustrate the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram with the In-Frame/LL-IF State highlighted below in Figure 8.

Figure 8, Illustration of the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram, with the In-Frame/LL-IF State highlighted.

Whenever the Sink STE is operating in the In-Frame/LL-IF state, it can now locate the boundaries of each incoming OTUk frame. This also means that the Sink STE should be ready to start making sense of the data within the incoming OTUk data stream. It can now begin to evaluate the OTUk data stream for other defects or error conditions.

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

Whenever the Sink STE operates in the In-Frame/LL-IF 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 one set of FAS bytes, the Sink STE would remain in the “In-Frame/LL-IF” 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 FAS bytes for five consecutive OTUk frames, then the Sink STE will transition from the LL-IF state into the LL-OOF state (within the Low-Level State Machine).

Consequently, the Sink STE will transition from the In-Frame/LL-IF state into the In-Frame/LL-OOF state.

We discuss the In-Frame/LL-OOF State below.

The In-Frame/LL-OOF State

I illustrate the OTUk-dLOF Frame Alignment/Maintenance State Machine diagram with the In-Frame/LL-OOF State highlighted below in Figure 9.

Figure 9, Illustration of the OTUk-dLOF Frame Alignment/Maintenance State Machine diagram, with the In-Frame/LL-OOF State highlighted.

If the Sink STE transitions into the In-Frame/LL-OOF state, then it means the following things:

The Sink STE has transitioned from the LL-IF state into the LL-OOF state within the OTUk-FAS OOF/IF Low-Level State Machine.
The Sink STE is still NOT declaring the dLOF (Loss of Frame) defect condition (e.g., dLOF = 0).

NOTE: We refer to this state as the “In-Frame/LL-OOF” state because the Sink STE is still NOT declaring the dLOF defect condition (just as it was NOT while operating in the In-Frame/LL-IF state).

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

Only one of two possible things will happen whenever the Sink STE enters the In-Frame/LL-OOF state.

The Sink STE will eventually re-acquire synchronization with the incoming FAS frames, and it will advance back into the In-Frame/LL-OOF state, or
The Sink STE does not re-acquire synchronization with the incoming FAS frames and eventually regresses into the dLOF/LL-OOF state.

We will briefly discuss each of these two possible events below.

Advancing Back into the In-Frame/LL-IF State

If the Sink STE can locate and re-acquire the 4-byte subset of the FAS-field, then it will transition back into the In-Frame/LL-IF state. In this case, the Sink STE will continue to clear the dLOF defect condition (dLOF = 0).

Regressing to the dLOF/LL-OOF State

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

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

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

NOTE: If the Sink STE enters the dLOF/LL-OOF state from the In-Frame/LL-IF (by way of the In-Frame/LL-OOF state), it will operate with the exact frame-start location that it had when it was running in the In-Frame/LL-IF state.

In other words, the Sink STE will continue to look for the FAS-field in the exact location (e.g., N x 16,320-byte periods later, where N is an integer) in which it was locating the FAS-field while it was operating normally in the In-Frame/LL-IF state.

In Summary

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

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

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

Table 1 presents a summary of the dLOF Defect Condition and how its State affects an OTN STE’s operation when handling an OTUk signal over a Single Lane (e.g., the OTSi/OTUk_A_Sk function).

Table 1, Summary of the dLOF Defect Condition and How its State affects an OTN STE’s Operation when handling an OTUk signal over a Single Lane (e.g., the OTSi/OTUk_A_Sk function).

Item	Description
Meaning of dLOF	The Sink STE (or OTSi/OTUk_A_Sk function) will declare the dLOF defect if it is not able to reliably locate the FAS field (and in-turn, the boundaries) of the incoming OTUk frames within the incoming data-stream. In short, if the Sink STE (OTSi/OTUk_A_Sk function) is declaring the dLOF defect condition, then it is NOT able to make any sense of the data within its OTUk data-stream. The Sink STE (and downstream circuitry) cannot perform any useful functions on this data-stream until it clears this defect.
Requirements to declare dLOF	The Sink STE (or OTSi/OTUk_A_Sk function) will declare the dLOF defect if it loses synchronization with the incoming FAS fields (within the incoming OTUk datastream) for at least 3ms. Additionally, the Sink STE (or OTSi/OTUk_A_Sk function) must not be declaring the dAIS (OTUk-AIS) defect condition.
Requirements to clear dLOF	The Sink STE (or OTSi/OTUk_A_Sk function) will clear the dLOF defect if it is able to maintain synchronization with the incoming FAS fields (within the incoming OTUk data-stream) for at least 3ms.
Any defects that can suppress the dLOF defect?	Yes, the Sink STE (or OTSi/OTUk_A_Sk function) cannot declare the dLOF defect, if it is currently declaring either of the following defect. - dAIS (OTUk-AIS), - dLOS-P or - TSF (Trail Signal Failure) - if upstream (optical circuitry) asserts the AI_TSF input. NOTE: Please see the blog post on the OTSi/OTUk_A_Sk function for more information about the AI_TSF signal.
Impact of declaring the dLOF defect on other defect conditions within the Sink STE (or OTSi/OTUk_A_Sk or OTUk_TT_Sk functions)	The Sink STE (or OTSi/OTUk_A_Sk and OTUk_TT_Sk functions) should NOT declare any of the following defects, whenever it is declaring the dLOF defect condition. - dLOM - dTIM - dDEG NOTE: Please see the blog post for the OTUk_TT_Sk Atomic Function for more information about the dTIM, dDEG defects and why the dLOF defect will affect these defect conditions.
Impact of declaring the dLOF defect on Downstream Circuitry (e.g., the OTUk_TT_Sk function).	The Sink STE (or OTSi/OTUk_A_Sk function) should automatically assert the CI_SSF (Server Signal Fail) signals whenever it is declaring the dLOF defect condition. This indication will notify the downstream OTUk_TT_Sk function that there is a service-affecting defect upstream. NOTE: Please see the blog post for the OTSi/OTUk_A_Sk atomic function for more information about the CI_SSF signal.
Impact of declaring the dLOF defect to Performance Monitoring.	The Sink STE (or OTSi/OTUk_A_Sk function) must inhibit Performance Monitor tallying of the pFECcorrErr (Number of Symbol Errors Corrected by FEC) for the duration that it is declaring the dLOF defect condition. NOTE: Whenever the Sink STE or OTSi/OTUk_A_Sk function declares the dLOF defect condition, it will also affect Performance Monitoring activities within the OTUk_TT_Sk atomic function.

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.

The 16-Byte Block MUX

Please see the description for the Elastic Store Block above for OTU3 applications.

The (OTU4) Frame Alignment – dLOF Detection Blocks

Please see the description for the Elastic Store Block above for OTU3 applications.

The Descrambler Blocks

Please see the description for the Elastic Store Block above for OTU3 applications.

The FEC Decoder Block

Please see the description for the Elastic Store Block above for OTU3 applications.

The Multi-Frame Alignment – dLOM Detection Blocks

Please see the description for the Elastic Store Block above for OTU3 applications.

Consequent Actions Blocks

I illustrate the OTSiG/OTU4-a_A_Sk function with the Consequent Actions blocks highlighted below in Figure 23.

Figure 23, Illustration of the OTSiG/OTU4-a_A_Sk function with the Consequent Actions block highlighted.

In most cases, the System Designer will realize the Consequent Actions Block via digital logic circuitry that will assert the CI_SSF (Server Signal Fail) output (of the OTUk_CP Interface) anytime the OTSiG/OTUk-a_A_Sk function declares the following defect conditions.

dLOS-P – Loss of Signal Defect Condition
dLOFLANE – Loss of Frame – Lane Defect Condition(*)
dLOL – Loss of Lane Alignment Defect Condition(*)
dLOF – Loss of Frame Defect Condition (if implemented)
dLOM – Loss of Multi-Frame Alignment Defect Condition
AI_TSF – If the upstream circuitry asserts the AI_TSF-P input pin to this function.

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

The Consequent Action Equation for the OTSiG/OTUk-a_A_Sk Atomic Function

ITU-T G.798 lists the following Consequent Actions Equation below:

aSSF ⇐ dLOF or dLOM or ∑dLOS-P[i] or dLOL or ∑dLOFLANE[j] or AI_TSF

This equation means that the OTSiG/OTUk-a_A_Sk function should assert the aSSF (and, in turn, drive the CI_SSF output pin HIGH) if any of the following conditions are TRUE:

The upstream Optical Circuitry is asserting the AI_TSF-P input signal to this function, or
If the OTSiG/OTUk-a_A_Sk function is declaring any of the following defect conditions:
- dLOS-P[i] – The Loss of Signal – Path defect within any Electrical Lane i, where i can range from 1 to 4.
- dLOFLANE[j] – The Loss of Frame – Lane defect within any Logical Lane j, where j can range from 1 to 4 (for OTU3 applications) or 1 to 20 (for OTU4 applications).
- dLOL – The Loss of Lane Alignment Defect
- dLOF – The Loss of Frame Defect (with the composite OTU3 or OTU4 signal)
- dLOM – The Loss of Multi-Frame Alignment Defect (with the composite OTU3 or OTU4 signal).

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 OTSiG/OTUk-a_A_Sk function-related defect.

cLOS ⇐ ∑dLOS-P[i] and (NOT AI_TSF-P)
cLOL ⇐ (dLOL or ∑dLOFLANE[j]) and (NOT ∑dLOS-P[i]) and (NOT AI_TSF-P)
cLOF ⇐ dLOF and (NOT ∑dLOS-P[i]) and (NOT AI_TSF-P)
cLOM ⇐ dLOM and (NOT dLOF) and (NOT ∑dLOS-P[i]) and (NOT AI_TSF)

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

cLOS ⇐ ∑dLOS-P[i] and (NOT AI_TSF-P)

This equation means that the OTSiG/OTUk_A_Sk function must declare the dLOS defect (and assert the cLOS output pin) if the Clock Recovery and dLOS Detection Circuitry declares the dLOS-P signal within any one of the four electrical lane signals.

This equation also states that the OTSiG/OTUk_A_Sk function must NOT declare the dLOS (and assert the cLOS output pin) if the upstream Optical Circuitry is also asserting the AI_TSF-P input signal (to this function).

cLOL ⇐ (dLOL or ∑dLOFLANE[j]) and (NOT ∑dLOS-P[i]) and (NOT AI_TSF-P)

This equation means that the OTSiG/OTUk_A_Sk function should only declare the dLOL defect (and assert the cLOL output pin) if either of the following conditions is TRUE:

If the Lane Marker and Delay Processing block is declaring the dLOL defect, OR
If at least one of the 4 or 20 Logical Lanes declare the dLOFLANE defect conditions.

However, this equation also states that the function CANNOT declare the dLOL defect (and drive the cLOL output pin HIGH) if either of the following conditions is TRUE:

At least one Clock Recovery and dLOS Detection circuit is also declaring the dLOS-P defect conditions with any one of the four electrical lane signals, OR
The upstream circuitry currently asserts the AI_TSF-P input pin (to this function).

cLOF ⇐ dLOF and (NOT ∑dLOS-P[i]) and (NOT AI_TSF-P)

This equation means that the OTSiG/OTUk-a_A_Sk function should only declare the dLOF defect (and assert the cLOF output pin) if the Frame Alignment block and the dLOF Detection blocks declare the dLOF defect condition.

However, this equation also states that the function CANNOT declare the dLOF defect (and drive the cLOF output pin HIGH) if any of the following conditions are TRUE:

At least one Clock Recovery and dLOS Detection circuit is also declaring the dLOS-P defect conditions with any one of the four electrical lane signals, OR
The upstream optical circuitry is currently asserting the AI_TSF-P input pin (to this function).

cLOM ⇐ dLOM and (NOT dLOF) and (NOT ∑dLOS-P[i]) and (NOT AI_TSF-P)

This equation means that the OTSiG/OTUk-a_A_Sk function should only declare the dLOM defect (and assert the cLOM output pin) if the Multi-Frame Alignment block and the dLOM Detection blocks declare the dLOM defect condition.

However, this equation also states that the function CANNOT declare the dLOM defect (and drive the cLOM output pin HIGH) if any of the following conditions are TRUE:

The Frame Alignment and dLOF Detection blocks are also declaring the dLOF defect condition, or
If at least one Clock Recovery and dLOS Detection block is declaring the dLOS defect with its electrical lane signal, or
The Optical upstream circuitry is currently asserting the AI_TSF-P input pin (to this function).

Performance Monitoring

ITU-T G.798 requires that the OTSiG/OTUk-a_A_Sk Function tally and report the following Performance Monitoring parameter to System Management:

pFECcorrErr ⇐ ∑nFECcorrErr

In other words, we expect the OTSiG/OTUk-a_A_Sk function to tally and report each time the FEC Decoder block corrects an errored symbol within the incoming OTU3 or OTU4 data stream.

Pin Description

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

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

Signal	Type	Description
OTSiG Access Point - Interface
AI_PLD[1...4]	Input	OTSiG Adaptation Information - PLD (Payload) Input Ports 1 through 4: The user is expected to apply a 4-lane electrical signal to these inputs. This four-lane signal should be an OTL3.4 type of signal for OTU3 applications and an OTL4.4 type of signal for OTU4 applications. In most cases, this 4-lane electrical signal will have just recently been converted from the optical, back into the electrical format. The OTSiG/OTUk-a_A_Sk function will convert the 4-lane OTL3.4 signal back into a single-composite OTU3 signal. Likewise, this function will also convert the 4-lane OTL4.4 signal back into a single-composite OTU4 signal.
OTUk - Characteristic Information
CI_D	Output	OTUk Characteristic Information - Data Output: The OTSiG/OTUk-a_A_Sk function will output the OTUk data via this output. This OTUk data 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, however. Data that is output via this signal, will be aligned with one of the clock 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_CK	Output	OTUk 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 to one of the clock edges of this clock output signal.
CI_FS	Output	OTUk Characteristic Information - Frame Start Output: The OTUk_CP interface will pulse this output signal HIGH whenever the OTUk_CP interface outputs the very first bit (or byte) of a new OTUk frame, via the CI_D output. This output signal will pulse HIGH once for each OTUk frame.
CI_MFS	Output	OTUk Characteristic Information - Multi-Frame Start Output: The OTUk_CP Interface will pulse this output signal HIGH whenever the OTUk_CP Interface outputs the very first bit (or byte) of a new OTUk multi-frame, via the CI_D output. This output signal will pulse HIGH once for each OTUk Multi-frame (or once each 256 OTUk fraeme
CI_SSF	Output	OTUk Characteristic Information - Server Signal Failure Output: The OTUk_CP interface will assert this signal anytime the OTSiG/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 OTSiG/OTUk-a_A_Sk function is declaring any of the followiong defects. - dLOF - dLOM - dLOL - dLOFLANE (within any of the 4 or 20 logical lanes) - dLOS-P (within any of the four electrical lanes).
OTSiG/OTUk-a_A_Sk_MP Management Interface
MI_FECEn	Input	OTSiG/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 OTSiG/OTUk-a_A_Sk function. Setting this input HIGH enables FEC Decoding. Setting this input LOW disables FEC Decoding. NOTE: This input does not exist for OTU4 applications.
MI_1Second	Input	Management Interface - One Second Clock Input: The user is expeced to supply a clock signal, which has a frequency of 1Hz to this input. The Performance Monitoring portion of the OTSiG/OTUk-a_A_Sk function will use this clock signal as its timing reference for tallying and reporting the various One-Second Performance Monitoring parameters.
MI_cLOF	Output	Management Interface - Loss of Frame (Correlated) Output Indicator: This output pin indicates if the OTSiG/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 the blog post for dLOF defect, to learn more about how the OTSiG/OTUk-a_A_Sk function declares and clears the dLOF defect condition.
MI_cLOM	Output	Management Interface - Loss of Multiframe (Correlated) Output Indicator: This output pin indicates if the OSiG/OTUk-a_A_Sk function is currently declaring the dLOM defect condition. 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 this function is currently declaring the dLOM defect condition. Please see the dLOM blog post, for more information on how the OTSiG/OTUk-a_A_Sk function declares and clears the dLOM defect condition.
MI_cLOL	Output	Management Interface - Loss of Lane Alignment (Correlated) Output Indicator: This output pin ndicates if the OTSiG/OTUk-a_A_Sk function is currently declaring the dLOL defect. If this output pin is LOW, then it indicates that the function is NOT currently declaring the dLOL defect condition. Conversely, if this output pin is HIGH, then it indicates that the function is currently declaring the dLOL defect condition. Please see the dLOL blog post for more information on how the OTSiG/OTUk-a_A_Sk function declares and clears the dLOL defect condition.
MI_cLOS	Output	Management Interface - Loss of Signal (Correlated) Defect Output Indicator: This output indicates if the OTSiG/OTUk-a_A_Sk function is currently declaring the dLOS defect condition. If this output pin is LOW, then it indicates that the function is NOT currently declaring the dLOS defect condition. Conversely, if this output pin is HIGH, then it indicates that the function is currently declaring the dLOS defect condition. Please see the dLOS blog post, for more information on how the OTSiG/OTUk-a_A_Sk function declares and clears the dLOS defect condition.
MI_pFECcorrErr	Output	Management Interface - FEC Correlated Error Count Output: This output port reflects the number of symbol errors that the OTSiG/OTUk-a_A_Sk function (via the FEC Decoder) has corrected. This is a Performance Monitoring feature within the OTSiG/OTUk-a_A_Sk function. NOTE: This outputpin is INACTIVE if the MI_FECEn input pin is set LOW (to disable the FEC Decoder).

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

Discounts Available for a Short Time!!!

What is Defect Correlation?

This post briefly defines and explains what Defect Correlation means. In short, the Defect Correlation equations will specify how we expect a system to respond to a specific defect condition.

What is Defect Correlation, and How Should You Interpret It?

The purpose of this blog post is two-fold.

To describe the concept of Defect Correlation and
To discuss how to interpret the meaning of Defect Correlation and their Equations.

Introduction

Numerous ITU Standards (such as ITU-T G.798 for OTN applications) will define various aspects of defects. These standards will define a defect, such as dLOS (the Loss of Signal) and dLOF (the Loss of Frame).

These standards will (sometimes) describe the conditions that an OTN Network Element (be it an STE or PTE) should use to declare or clear a given defect.

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

dLOS-P – Loss of Signal Defect-Path
dLOFLANE[j] – Loss of Frame of Logical Lane, for Logical Lane j
dLOL – Loss of Lane Alignment Defect
dAIS – Alarm Indication Signal Defect (e.g., OTUk-AIS for STEs)
dLOF – Loss of Frame Defect
dLOM – Loss of Multi-Frame Defect
dTIM – Trail Trace Identifier Mismatch Defect(*)
dIAE – Input Alignment Error Defect(*)
dBIAE – Backward Input Alignment Error Defect(*)
dBDI – Backward Defect Indicator Defect
dDEG – Signal Degrade Defect(*)

(*) – Requires membership to THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!! to see these links.

And it is excellent that the ITU-T standard committee does this for us.

But let’s now take a closer look at these defects from a System-Level standpoint.

Should One Defect Lead to Many Other Defects?

Suppose an OTN STE declares the dLOS-P (Loss of Signal-Path) defect condition with its incoming optical lanes or signal.

This STE will declare the dLOS-P condition for one of two reasons.

Because the optical components (upstream) are detecting too little optical signal energy (within the incoming signal) or
the Clock and Data Recovery circuitry (within the STE electronics) is detecting an absence of recovered (data) signal activity for an extended period.

In Figure 1, I illustrate the OTSi/OTUk-a_A_Sk function, declaring the dLOS-P defect.

Figure 1, The OTSi/OTUk-a_A_Sk Atomic Function, declares the dLOS Defect Condition.

In either of these cases, it is clear that this OTN STE should declare the dLOS-P defect condition.

How about the dLOF Condition?

However, if that same OTN STE is not receiving any discernable signal from the remote STE, it is safe to say that it will not be receiving the FAS fields (within this now non-existent incoming data stream).

Should this OTN STE also declare the dLOF defect as well?

In Figure 2, I illustrate the OTSi/OTUk-a_A_Sk function, declaring the dLOF defect condition and the dLOS-P defect condition.

Figure 2, The OTSi/OTUk-a_A_Sk function declaring the dLOF and dLOS-P Defect Conditions

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

Corporate Discounts Available!!!

What about the dLOM Condition?

And since the OTN STE is not receiving any FAS field bytes, it cannot locate the MFAS bytes.

Should this OTN STE also declare the dLOM defect too?

In Figure 3, I illustrate the OTSi/OTUk-a_A_Sk function, declaring the dLOM, dLOF, and dLOS-P Defect conditions.

Figure 3, The OTSi/OTUk-a_A_Sk Atomic Function declaring the dLOM, dLOF, and dLOS-P Defect Conditions

How about the dTIM Condition?

Finally, since our OTN STE is not receiving any discernable signal (from the remote STE), and it cannot locate the boundaries of each incoming OTUk frame, it will certainly not obtain a Trail Trace Identification Message that matches that of the “Expected Trail Trace Identification” Message.

Should this OTN STE also declare the dTIM defect as well?

In Figure 4, I illustrate the OTUk_TT_Sk function declaring the dTIM defect, while the upstream OTSi/OTUk-a_A_Sk function reports the dLOS-P, dLOF, and dLOM defect conditions.

Figure 4, The OTUk_TT_Sk Atomic Function (downstream from the OTSi/OTUk-a_A_Sk Function) declares the dTIM defect.

Many Defects, all due to the dLOS-P Condition

In this scenario, a Loss of Signal event would cause the OTN STE to declare the dLOS, dLOF, dLOM, and dTIM defect conditions.

The OTN STE will accurately declare all four defect conditions because conditions warrant that the STE declare each of these defects.

However, allowing an STE to declare multiple defects (e.g., dLOS, dLOF, dLOM, and dTIM) can be confusing to both System-Management and the System Operator.

I could take this exercise even further and include some of the PTE/ODUk-related defects that an OTN PTE would declare (e.g., ODUk-AIS), all because of the dLOS-P condition. But I think that you get my point.

Whenever a service-affecting defect occurs, the OTN STE needs to alert System Management of a concise description of the problem (just dLOS-P in this case).

The intent should be to help the System Operator isolate the root cause of these problems.

We should not be bombarding the System Operator with a whole slew of defects, which are just artifacts of a single defect.

If the OTN STE declares the dTIM, dLOM, dLOF, and dLOS-P defects, the root cause of this problem has nothing to do with a mismatch in the Trail-Trace Identification Message.

Hence the Purpose of Defect Correlation

The purpose of Defect Correlation and Defect Correlation equations is to establish and report ONLY the root cause of problems to System Management.

The Defect Correlation Equations accomplishes this by creating a hierarchy of defects.

I’ll explain this.

Let’s list some Defect Correlation Equations for the OTSi/OTUk_A_Sk and OTUk_TT_Sk Atomic Functions.

For the OTSi/OTUk_A_Sk Atomic Function

The OTSi/OTUk_A_Sk function has the following Defect Correlation equations:

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)

Let’s also include the following Consequent Equation to bridge the OTUk_TT_Sk function to the OTSi/OTUk_A_Sk function.

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

For the OTUk_TT_Sk Function

In this case, we will focus on the Defect Correlation equation that pertains to the dTIM defect condition.

cTIM ⇐ dTIM and (NOT CI_SSF) and (NOT dAIS)

So Now Let’s Study some of these Defect Correlation Equations

Let’s start with the first equation for the OTSi/OTUk-a_A_Sk function.

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

Where:

cLOS-P is the correlated defect value of the dLOS-P defect state.

dLOS-P is the current state of the dLOS-P defect condition that the OTSi/OTUk_A_Sk function will declare or clear.

AI_TSF-P is the current state of the AI_TSF-P (Trail Signal Fail – Path Indicator) Input to the OTSi/OTUk-A_Sk function.

In this equation, the parameter that begins with the letter “c” is the correlated defect parameter (or defect) state that we ultimately report to System Management.

This equation states that we should only set the variable cLOS-P to TRUE if dLOS-P is TRUE.

In other words, we should only report the Loss of Signal condition (e.g., setting cLOS-P to TRUE) if the STE circuitry declares the dLOS-P defect (due to a lack of signal activity within the Clock Recovery Block, for example).

This equation also states that we should NOT set cLOS-P to TRUE because the upstream Optical Circuitry is declaring some other defect condition and is then asserting its AI_TSF-P output – towards the OTSi/OTUk_A_Sk function).

I show a TRUTH TABLE for this Defect Correlation Equation below in Table 1.

Table 1, TRUTH TABLE for the Defect Correlation Equation, cLOS-P ⇐ dLOS-P AND (NOT AI_TSF-P)

dLOS-P Defect	AI_TSF-P State	cLOS-P State	Comment
Cleared	FALSE	0
Declared	FALSE	1	Sets cLOS-P to TRUE, because dLOS-P is declared.
Don't Care	TRUE	0	We set cLOS-P to 0 when AI_TSF-P is TRUE.

Let’s look at another Defect Correlation Equation.

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

Where:

cLOF is the correlated value of the dLOF defect state.

dAIS is the current state of the dAIS defect condition within the OTSi/OTUk_A_Sk function.

In this equation, we are stating that we should only set cLOF = TRUE (and report the Loss of Frame condition to System Management) if the STE circuitry declares the dLOF condition.

This equation also states that we should NOT be setting cLOF = TRUE (and report the Loss of Frame Condition to System Management) if:

The STE is also declaring the dLOS-P defect, or
declaring the dAIS (OTUk-AIS) defect, or
If the upstream Optical Components assert the AI_TSF-P input to the OTSi/OTUk_A_Sk function.

If any of the three items (above) are TRUE, then we must set cLOF = FALSE.

I show the TRUTH TABLE for this Defect Correlation Equation below in Table 2.

Table 2, The TRUTH TABLE for the Defect Correlation Equation, cLOF ⇐ dLOF AND (NOT dLOS-P) AND (NOT dAIS) AND (NOT AI_TSF-P)

dLOF Defect Condition	dLOS-P Defect Condition	dAIS Defect Condition	AI_TSF-P State	cLOF State	Comments
Cleared	Cleared	Cleared	FALSE	Cleared
Declared	Cleared	Cleared	FALSE	Declared	We assert cLOF because we are declaring the dLOF Defect
Don't Care	Declared	Cleared	FALSE	Cleared	We set cLOF = 0 whenever dLOS-P is declared.
Don't Care	Cleared	Declared	FALSE	Cleared	We set cLOF = 0 whenever dAIS is declared.
Don't Care	Cleared	Cleared	TRUE	Cleared	We set cLOF = 0 whenever AI_TSF-P is driven TRUE.

At the risk of “whipping a dead horse,” I will show one more example.

cTIM ⇐ dTIM and (NOT CI_SSF) and (NOT dAIS)

Where:

cTIM is the correlated value of the dTIM defect state.

CI_SSF is the current state of the CI_SSF (Server Signal Fail Indicator) input pin to the OTUk_TT_Sk function.

If the STE circuitry declares this defect, this equation states that we must only report the Trail Trace Identifier Mismatch Defect (and set cTIM = TRUE).

This equation also states that we MUST NOT set cTIM = TRUE if any of the following is true.

The OTUk_TT_Sk function is declaring the dAIS defect condition, or
If the upstream OTSi/OTUk_A_Sk function is asserting the CI_SSF input to the OTUk_TT_Sk function.

NOTE: We have the following Consequent Equation for the CI_SSF signal (from the OTSi/OTUk_A_Sk function).

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

This equation states that if the upstream OTSi/OTUk_A_Sk function declares any of the following defects, it will set aSSF = TRUE.

dLOS-P
dAIS (OTUk-AIS)
dLOF
dLOM, or
If the upstream Optical Components assert the AI_TSF-P input to the OTSi/OTUk_A_Sk function.

If aSSF = TRUE, then the OTSi/OTUk_A_Sk function will assert the CI_SSF output signal (towards the OTUk_TT_Sk function).

Finally, we get to the bottom line.

These equations state that the STE MUST NOT set cTIM = TRUE (and MUST NOT report the Trail Trace Identifier Mismatch defect to System Management) if any of the following defect conditions are TRUE.

dLOS-P
dAIS
dLOF
dLOM
If the AI_TSF-P signal (from the upstream Optical Components) is HIGH.

Summary

I believe that you can see that using Defect Correlation Equations makes Defect Reporting and System-Management MUCH EASIER.

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

CLICK on the Image below for 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 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

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.

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 Name	Description	Comments
OTSi/OTUk-a_A_Sk	OTSi to OTUk Adaptation Sink Function with ITU-T G.709 Standard FEC	Can be used for OTU1 through OTU4 applications.
OTSi/OTUk-b_A_Sk	OTSi to OTUk Adaptation Sink Function with No FEC	Cannot be used for OTU4 applications
OTSi/OTUk-v_A_Sk	OTSi to OTUk Adaptation Sink Function with Vendor-Specific FEC	Can 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
- dLOS-P – Loss of Signal – Path
- dAIS – Alarm Indication Signal (OTUk-AIS)
- dLOF – Loss of Frame
- dLOM – Loss of Multiframe
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.

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.

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

Clock Recovery and dLOS Detection Blocks
dAIS Detection Block
Frame Alignment and dLOF Detection Blocks
Descrambler Block
FEC Decoder Block
Multi-Frame Alignment and dLOM Detection Blocks
Consequent Actions Block

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.

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.

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 + x⁹ + x¹¹.

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.

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.

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 + 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 OTSi/OTUk-a_A_Sk function design below in Figure 8.

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.

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.

dLOS-P – Loss of Signal- Path Defect Condition
dAIS – OTUk-AIS (Alarm Indication Signal) Defect Condition
dLOF – Loss of Frame Defect Condition
dLOM – Loss of Multi-Frame Defect Condition.
AI_TSF – If the upstream circuitry asserts the AI_TSF-P Input pin to this function.

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:

The OTSi/OTUk_A_Sk function declares any of the following defect conditions.
- dLOS-P – Loss of Signal – Path Defect
- dAIS – OTUk-AIS Defect
- dLOF – Loss of Frame Defect
- dLOM – Loss of Multi-Frame Alignment Defect
Or, if the upstream Optical Circuitry drives the AI_TSF (Trail Signal Fail) input pin HIGH.

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 Name	Type	Description
OTSi_AP Interface
AI_PLD	Input	OTUk 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-P	Input	Adapted 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-O	Input	Adapted 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_D	Output	OTUk 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_CK	Output	OTUk 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_FS	Output	OTUk 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_MFS	Output	OTUk 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_SSF	Output	OTUk 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_FECEn	Input	Management 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_pFECcorrErr	Output	Management 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_cLOM	Output	Management 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_cLOF	Output	Management 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_cLOS	Output	Management 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!!

What is an STE for OTN Applications?

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

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

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

STE – Section Terminating Equipment and
PTE – Path Terminating Equipment

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

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

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

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

What is a Section?

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

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

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

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

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

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

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

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

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

Now, we will define the term Section Terminating Equipment.

What is an STE (Section Terminating Equipment)?

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

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

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

The Source STE Operation In the Transmit Direction

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

Sink STE Operation In the Receive Direction

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

It receives data (from a remote Source STE) in the optical format.
The Sink STE then converts this optical data into the electrical format, where it can check and process these newly received OTUk/OTUkV frames.
As the Sink STE checks and processes this data, it will check for the following items.
- FEC errors (correctable and uncorrectable)
- Defects or Failures (e.g., dLOF, dLOM, dTIM, dAIS, dIAE, dBIAE, dDEG, dLOL, dLOFLANE[j], dLOS-P and SM-BDI)
- Other errors (e.g., SM-BIP-8, SM-BEI)
It will then pass this data to the downstream circuitry as an ODUk data stream (for further processing at the ODUk-layer).

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

Summarizing our Definitions of Section and STE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For the Source STE
- OTUk/ODUk_A_So – OTUk to ODUk Adaptation Source Function
- OTUk_TT_So – OTUk Trace Termination Source Function
- OTSi/OTUk_A_So – OTSi to OTUk Adaptation Source Function (Single-Lane Applications)
- OTSiG/OTUk_A_So – OTSiG to OTUk Adaptation Source Function (Multi-Lane OTU3/OTU4 Applications)
For the Sink STE
- OTUk_TT_Sk – OTUk Trace Terminating Sink Function
- OTUk/ODUk_A_Sk – OTUk to ODUk Adaptation Sink Function
- OTSi/OTUk_A_Sk – OTSi to OTUk Adaptation Sink Function (Single-Lane Applications)
- OTSiG/OTUk_A_Sk – OTSiG to OTUk Adaptation Sink Function (Multi-Lane OTU3/OTU4 Applications)

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

AN EXAMPLE OF AN STE AND ITS SECTION

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

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

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

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

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

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

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

Examples of STE

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

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

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

Discounts Available for a Short Time!!

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

OTN Related Topics within this Blog

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

OTUk-Backward Defect Indicator

This post defines and describes the Backward Defect Indicator (dBDI) defect for the OTUk Layer

What is the dBDI (Backward Defect Indicator) defect at the OTUk Layer?

In short, the dBDI (or Backward Defect Indicator) signal is functionally equivalent to the RDI (Remote Defect Indicator) for OTN applications.

In OTN applications, Network Equipment can declare the dBDI defect at either the OTUk Layer or the ODUk Layer.

This post will discuss the dBDI defect for the OTUk Layer, which we can call the OTUk-BDI defect condition.

We address the dBDI defect for the ODUk Layer in another post.

In another post, I’ve also described the RDI (Remote Defect Indicator) signal or defect in generic terms.

In this post, we are going to describe the following items.

What conditions will cause an OTUk Network Element to transmit the dBDI indicator to the remote Network Element?
How does the OTUk Network Element transmit the dBDI indicator to the remote Network Equipment?
How does the OTUk Network Element receiving the dBDI signal detect and declare the dBDI defect condition?
And, how does the OTUk Network Element clear the dBDI defect condition?

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

Corporate Discounts Available!!

What conditions will cause an OTUk Network Element to transmit the dBDI indicator?

In Figure 1, we illustrate two Network Elements (consisting of OTUk Framers and OTUk Transceivers) exchanging OTUk traffic over Optical Fiber.

We will call one of these Network Elements NETWORK ELEMENT WEST and the other Network Element, NETWORK ELEMENT EAST.

NETWORK ELEMENT WEST contains the following pieces of hardware

OTUk Framer West
OTUk Transceiver East and
Optical I/F Circuitry (O->E)/(E->O)

Likewise, NETWORK ELEMENT EAST contains the following pieces of hardware.

OTUk Framer East
OTUk Transceiver East and
Optical I/F Circuitry (O -> E)/(E -> O)

Figure 1, Illustration of two Network Elements that are connected over Optical Fiber

A Defect Condition

Now, let us imagine that some impairment occurs in the span of Optical Fiber carrying OTUk traffic from NETWORK ELEMENT WEST to NETWORK ELEMENT EAST.

This impairment will then cause NETWORK ELEMENT EAST to declare a service-affecting defect, as shown in Figure 2.

Figure 2, Illustration of NETWORK ELEMENT EAST declaring a Service-Affecting Defect due to an impairment in Optical Fiber

NETWORK ELEMENT EAST might respond to this defect condition in several ways. It might transmit the ODUk-AIS indicator towards downstream equipment (as a replacement signal).

NETWORK ELEMENT EAST might also invoke Protection Switching (if supported).

Sending the OTUk-BDI Indicator in Response

Finally, NETWORK ELEMENT EAST will also respond to this defect by transmitting the dBDI (or OTUk-BDI) indicator back towards the upstream Network Element (NETWORK ELEMENT WEST, in this case).

Figure 3 shows an illustration of NETWORK ELEMENT EAST, transmitting the OTUk-BDI indicator (back towards NETWORK ELEMENT WEST) in response to it declaring this service-affecting defect.

Figure 3, Illustration of NETWORK ELEMENT EAST responding to the Defect Condition by sending the OTUk-BDI indicator back towards NETWORK ELEMENT WEST

NETWORK ELEMENT EAST sends the OTUk-BDI indicator (back to NETWORK ELEMENT WEST) to alert it of this defect condition (between the two Network Elements).

In other words, NETWORK ELEMENT EAST is saying, “Hey, NETWORK ELEMENT WEST, I’m having problems with the data that you are sending me. I’d just thought that I’d let you know”.

There are many reasons why all of these notifications are useful.

This notification gives the Overall Network a clearer picture of exactly where the problem (or impairment) is.

It can also notify maintenance personnel of these problems and provide them with helpful information before they “roll trucks.”

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

Discounts Available for a Short Time!!

So What EXACTLY are those Defects that will cause a Network Element to transmit the OTUk-BDI indicator?

The Network Element will transmit the OTUk-BDI indicator anytime it declares any service-affecting defect conditions.

dTIM – Trail Trace Identification Mismatch Defect(*)
dAIS – OTUk-AIS Defect
dLOF – Loss of Frame Defect
dLOM – Loss of Multiframe Alignment Defect
dLOS-P/dLOS-P[i] – Loss of Signal – Payload Defect
dLOFLANE[j] – Loss of Frame – Lane Signal Defect (OTL3.4 and OTL4.4 Applications)(*)
dLOL – Loss of Lane Alignment (OTL3.4 and OTL4.4 Applications)(*)

(*) – Must be a member of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!! to see this material.

The Network Element will continue to transmit the OTUk-BDI indicator for the duration it declares any of these defects.

Once the Network Element no longer declares these defect conditions, it will stop transmitting the OTUk-BDI indicator.

NOTE: ITU-T G.798 is the standards document that specifies the conditions and set of defects that will cause the Network Element to transmit the OTUk-BDI indicator to the remote terminal.

If you wish to see a detailed analysis of how ITU-T G.798 specifies these requirements, please look at the standards document itself or check out the OTUk-BDI – ITU-T G.798 Analysis post.

How does the OTUk Network Element transmit the dBDI indicator?

The Network Element will send the OTUk-BDI indicator by setting the BDI bit-field (Bit 5) within the SM (Section Monitoring) Byte, to 1, within each outbound OTUk frame.

The SM byte resides within the 3-byte SM (Section Monitoring) field of the OTUk Overhead.

Figures 4a, 4b, and 4c present the location of the BDI field.
Figure 4a presents an illustration of the SM-field within the OTUk Overhead.

Figure 4a, The SM Field within the OTUk Overhead

Further, Figure 4b illustrates the SM byte’s location within the 3-byte SM Field (within the OTUk Overhead).

Figure 4b, The SM-Byte within the SM Field

Finally, Figure 4c shows the location of the BDI-field within the SM-byte (within the SM-field of the OTUk Overhead).

Figure 4c, The Location of the BDI bit-field within the SM Byte, within the SM Field, within the OTUk Overhead

Likewise, the Network Element will end its transmission of the OTUk-BDI indicator by setting the BDI bit-field back to “0” within each outbound OTUk frame.

How does the OTUk Network Element detect and declare the dBDI indicator?

In the scenario that we described above (via Figure 3), NETWORK ELEMENT EAST will continue to transmit the OTUk-BDI signal to NETWORK ELEMENT WEST as long as it (NETWORK ELEMENT EAST) declares the service-affecting defect within its Ingress (Receive) signal.

If NETWORK ELEMENT WEST receives the OTUk-BDI indicator within at least five (5) consecutive OTUk frames, it will declare the dBDI defect condition.

In other words, if NETWORK ELEMENT WEST (or any Network Element) were to receive at least five (5) consecutive OTUk frames, in which the BDI bit-field is set to “1”, then it will declare the dBDI defect.

Figure 5 illustrates NETWORK ELEMENT WEST declaring the dBDI defect after receiving five consecutive OTUk Frames with the SM-BDI field set to “1”.

Figure 5, Illustration of NETWORK ELEMENT WEST declaring the dBDI defect condition

How does the OTUk Network Element clear the dBDI defect condition?

Whenever NETWORK ELEMENT EAST has determined that the service-affecting defect (which caused it to transmit the dBDI signal in the first place) is cleared, it will stop sending the dBDI signal back out to NETWORK ELEMENT WEST.

NETWORK ELEMENT EAST will stop sending the dBDI signal by setting the BDI bit-field (within the SM field) to “0” within each outbound OTUk frame.

If NETWORK ELEMENT WEST (which is currently declaring the dBDI defect condition) were to receive at least five (5) consecutive OTUk frames, in which the BDI bit-field is set to “0”, then it will clear the dBDI defect.

Figure 6 illustrates NETWORK ELEMENT WEST clearing the dBDI defect after receiving five consecutive OTUk Frames with the SM-BDI field set to “0”.

Figure 6, Illustration of NETWORK ELEMENT WEST clearing the dBDI defect condition

Monkey Pox and Covid? It’s Scary Out There. We Can Help You Become an Expert on OTN Before It’s Safe to Venture Out!! 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 Topics within this Blog

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

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

OTN – Lesson 9 – Video 3 – OTU Layer Sink Direction Circuitry/Functionality – Part 1

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

Introduction

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

How Do We Sort out This Confusion?

So What Does All of This Mean?

Let’s Take a Look at the Downstream Circuitry

The First Consequent Equation – OTUk_TT_Sk Function

The Second Consequent Equation – OTUk_TT_Sk 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

The First Consequent Equation – OTUk/ODUk_A_Sk Function

The Second Consequent Equation – OTUk/ODUk_A_Sk Function

So What Does All This Mean?

Conclusion

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

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> How an OTN STE should declare and clear the dLOF (Loss of Frame) Defect Condition

A Note About Terminology:

A Brief Review of the OTUk Frame Structure

The dLOF-Related State Machines

The OTUk-FAS OOF/IF Low-Level State Machine

The LL-OOF State

ITU-T G.798’s Requirement for Searching for the FAS field

The LL-IF State

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

Discounts Available for a Short Time!!!

The OTUk-dLOF Framing Alignment/Maintenance State Machine

The dLOF/LL-OOF State

What does it mean to be in the dLOF/LL-OOF State?

If the Sink STE Fails to Find the FAS field

If the Sink STE Successfully Locates the FAS field

The dLOF/LL-IF State

Advancing to the In-Frame/LL-IF State

Regressing to the dLOF/LL-OOF State

The In-Frame/LL-IF State

The In-Frame/LL-OOF State

Advancing Back into the In-Frame/LL-IF State

Regressing to the dLOF/LL-OOF State

In Summary

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.

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is the OTSiG/OTUk_A_Sk Atomic Function?

Changes in Terminology

What is an OTSiG?

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

The OTSiG/OTUk_A_Sk Function

Versions of the OTSiG/OTUk_A_Sk Function

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

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?

Functional Description of this Atomic Function

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

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

Lane Frame Alignment Block (4 for OTU3 Applications)

Lane Alignment Recovery Block (4 for OTU3 Applications)

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

The Elastic Store Block (4 for OTU3 Applications)

16-Byte Block MUX (1 for OTU3 Applications)

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

Descrambler Block

FEC Decoder Block

Multi-Frame Alignment and dLOM Detection Block

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

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

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

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

The Lane Frame Alignment Block (20 for OTU4 Applications)

The Lane Alignment Recovery Blocks (20 for OTU4 Applications)

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

How an OTN STE should declare and clear the dLOF (Loss of Frame) Defect Condition

What is the OTSiG/OTUk_A_Sk Atomic Function?

What is Defect Correlation, and How Should You Interpret It?

What is the OTSi/OTUk_A_Sk Atomic Function?