Declaring/Clearing the dLOM Defect

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

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

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

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

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

Each of these atomic functions includes the dLOM Detection circuit.

A Note about Terminology:

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

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

A Brief Review of the OTUk Frame Structure

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

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

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

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

The MFAS Byte Increments with each Frame

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

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

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

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

This process repeats indefinitely.

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

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

Corporate Discounts Available!!

A Basic Requirement before We can Clear the dLOM Defect Condition

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

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

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

There are several reasons for this:

The Sink STE needs to find the FAS-field first

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

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

There are two reasons for this.

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

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

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

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

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

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

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

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

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

We will first discuss dLOM-Related State Machines.

The dLOM-Related State Machines

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

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

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

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

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

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

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

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

We will discuss these two state machines below.

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

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

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

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

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

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

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

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

We will discuss these two states below.

The LL-OOM State

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

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

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

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

Next_Expected_MFAS_Value = MOD(Candidate_MFAS_Value + 1, 256);

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

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

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

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

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

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

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

The LL-IM State

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

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

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

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

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

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

Discounts Available for a Short Time!!!

The OTUk-dLOM Framing Alignment/Maintenance State Machine

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

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

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

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

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

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

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

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

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

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

The dLOM/LL-OOM State

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

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

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

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

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

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

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

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

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

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

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

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

Next_Expected_MFAS_Value = MOD(Candidate_MFAS_Field + 1, 256)

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

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

Next_Expected_MFAS_Value == New_Candidate_MFAS_Value;

If the New_Candidate_MFAS_Value fails the Test

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

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

If the New_Candidate_MFAS_Value passes the Test

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

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

The dLOM/LL-IM State

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

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

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

NOTES:

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

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

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

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

We will discuss each of these possible events below.

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

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

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

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

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

Regressing to the dLOM/LL-OOM State

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

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

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

The In-Multi-Frame/LL-IM State

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

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

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

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

What Does Clearing the dLOM Defect Mean?

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

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

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

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

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

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

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

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

The In-Multi-frame/LL-OOM State

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

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

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

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

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

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

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

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

We will briefly discuss these two possible events below.

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

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

Regressing to the dLOM/LL-OOM State

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

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

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

In Summary

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

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

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

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

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

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

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

Discounts Available for a Short Time!!

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

OTN Related Topics within this Blog

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

What is the OTUk_TT_So Atomic Function?

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

What is the OTUk_TT_So Atomic Function?

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

Introduction

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

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

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

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

So What Does this Atomic Function Do?

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

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

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

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

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

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

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

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

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

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

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

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

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

Some Details about the OTUk_TT_So Function

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

Figure 3, Simple Drawing of the OTUk_TT_So function

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

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

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

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

OTUk_AP
OTUk_CP
OTUk_RP and
OTUk_TT_So_MP

We will discuss each of these interfaces below.

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

Figure 4 Functional Block Diagram of the OTUk_TT_So function

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

Corporate Discounts Available!!

The OTUk_AP (OTUk Access Point) Interface

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

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

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

SM-BIP-8 Computation and Insertion – We discuss BIP-8 Computation and Insertion in another post.
IAE (Indicator) Insertion (into the OTUk-SMOH) – We discuss IAE insertion below in another post. (*)

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

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

The OTUk_TT_So_RP (Remote Port) Interface

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

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

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

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

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

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

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

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

The OTUk_TT_So_MP (Management Port) Interface

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

MI_TxTI – Trail Trace Identifier Input

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

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

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

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

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

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

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

Overhead Field	Location within OTUk-SMOH	Source of Data/How Derived?
BIP-8 Byte	BIP-8 Byte within the Section Monitoring Field	The OTUk_TT_So function locally computes the BIP-8 value based upon the contents within the OPUk portion of the OTUk frame.
IAE Bit-Field	The IAE Bit-field within the Section Monitoring Byte	Based upon the AI_IAE input to the function (at the OTUk_AP Interface)
BDI Bit-Field	The BDI bit-field within the Section Monitoring byte	Based upon the RI_BDI input to this function (at the Remote Port Interface).
BEI Nibble-Field	The BEI/BIAE Nibble-field within the Section Monitoring Byte	Based upon the RI_BEI and RI_BIAE inputs to this function (at the Remote Port Interface).
BIAE Nibble-Field	The BEI/BIAE bit-fields within the Section Monitoring byte.	Based upon the RI_BIAE and RI_BEI inputs to this function (at the Remote Port Interface).
TTI Byte-Field	TTI Byte within the Section Monitoring Field.	The user is expected to load in the contents of the 64-byte Trace Identifier Message (TIM) into a buffer via the MI_TxTI input to this function. The function will proceed to transmit the contents of this TIM, one byte at a time, via the TTI byte-field within each outbound OTUk Frame. The OTUk_TT_So function will transport the entire TIM over 64 consecutive OTUk frames.

List of Input and Output Signals for the OTUk_TT_So Atomic Function

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

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

Signal Name	Type	Description
OTUk_AP Interface
AI_D	Input	OTUk Adapted Interface - OTUk Data Input: The function user is expected to apply a bare-bones OTUk signal (which is output from the AI_D output of the OTUk/ODUk_A_So function) to this input pin. NOTE: This OTUk data will contain the following fields - Default OTUk SMOH data, - The contents of the APS/PCC channel and - The rest of the OTUk frame. This OTUk data-stream will not include the FAS, MFAS or FEC field. This function will compute, generate and insert the appropriate OTUk-SMOH into this OTUk data-stream The OTUk_TT_So function will sample this input signal on one of the edges of the AI_CK input clock signal.
AI_CK	Input	OTUk Adapted Interface - Clock Input: The OTUk_TT_So function will sample all data and signals (that the user applies to the OTUk_AP Interface) upon one of the edges of this input clock signal. This statement applies to the following signals: AI_D, AI_FS, AI_MFS and AI_IAE. This clock signal will also function as the timing source for this function as well.
AI_FS	Input	OTUk Adapted Information - Frame Start Input: The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP Interface accepts the very first bit (or byte) of a new OTUk frame, via the AI_D inputs. The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk frame.
AI_MFS	Input	OTUk Adapted Information - Multiframe Start Output: The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP interface accepts the very first bit (or byte) of a new OTUk superframe, via the AI_D input. The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk superframe.
AI_IAE	Input	OTUk Adapted Information - Input Alignment Error Input: the OTUk/ODUk_A_So function (upstream from this function) will drive this input pin HIGH whenever it detects a frame-slip (or IAE event). Anytime the OTUk_TT_So function detects this input pin, going from LOW to HIGH, then it should respond by setting the IAE bit-field to "1" for 16 consecutive Superframes (or 4096 consecutive OTUk frames). Please see the blog on IAE for more information on this feature.
OTUk_CP Interface
CI_D	Output	OTUk Characteristic Information - OTUk Data Output: The OTUk_TT_So function will compute, generate and insert the SMOH (Section Monitoring Overhead) into the outbound OTUk data-stream. It will then output this OTUk data-stream via this output signal. NOTE: This OTUk data will contain the following fields. - The newly computed, inserted BIP-8 value - The newly received and inserted BEI-nibble value or BIAE indicator. - The newly received and inserted BDI bit-value. - the newly received and inserted IAE value. - The contents of the APS/PCC channel and - The rest of the OTUk frame. This OTUk data-stream will not include the FAS, MFAS or FEC field. The OTUk_TT_So function will update this output signal on one of the edges of the CI_CK output clock signal.
CI_CK	Output	OTUk Adapted Information - Clock Output: The OTUk_TT_So function will output all data and signals (via the OTUk_CP interface) upon one of the edges of this output clock signal. This statement applies to the following signals: CI_D, CI_FS and CI_MFS.
CI_FS	Output	OTUk Characteristic Information - Frame Start Output: This function will drive this output pin HIGH whenever the OTUk_CP interface outputs the very first bit (or byte) of a new OTUk frame, via the CI_D output. The OTUk_TT_So function should only pulse this output pin HIGH once for each outbound OTUk frame.
CI_MFS	Output	OTUk Characteristic Information - Multiframe Start Output: This function will drive this output pin HIGH whenever the OTUk _CP Interface outputs the very first bit (or byte) of a new OTUk Superframe via the CI_D. The OTUk_TT_So function will drive this output pin HIGH once for each OTUk Superframe.
OTUk_TT_So_RP Interface
REI_BEI	Input	Remote Port Interface - BEI (Backward Error Indicator) Input: The OTUk_TT_So function will accept one nibble of data (for each outbound OTUk frame) via this input signal and it will insert this data into the BEI/BIAE nibble-field within the Section Monitor field within each outbound OTUk frame. The BEI value will reflect the number of BIP-8 errors that the collocated OTUk_TT_Sk function has detected and flagged within its most recently recevied and verified OTUk frame. NOTE: If the OTUk_TT_So function receives a BIAE = 1 (via the RI_BIAE input) then it will overwrite the BEI/BIAE nibble-field with the value "1011" to denote a BIAE event. Please see the BEI post for more information about Backward Error Indication.
RI_BIAE	Input	Remote Port Interface - BIAE (Backward Input Alignment Error) Input: The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input signal and it will do either of the following, depending on the value of this single bit-field. If BIAE = 0 Then the OTUk_TT_So function will write the BEI value that it has received via the RI_BEI input, into the BEI nibble-field within the Section Monitor byte of the next outbound OTUk frame. If BIAE = 1 Then the OTUk_TT_So function will not write the BEI value (that it has received from the collocated OTUk_TT_Sk function). It will instead, write the value "1011" into the BEI/BIAE nibble-field, within the Section Monitor byte of the next outbound OTUk frame.
RI_BDI	Input	Remote Port Interface - Backward Defect Indicator Input: The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input pin and it will write the contents of this value into the RDI bit-field (within the Section Monitor byte) of the next outbound OTUk frame. If RI_BDI = 0 The the OTUk_TT_So function will set the BDI bit-field to "0" within the next outbound OTUk frame. If RI_BDI = 1 Then the OTUk_TT_So function will set the BDI-bit-field to "1" within the next outbound OTUk frame.
OTUk_TT_So_MP Interface
MI_TxTI	Input	Management Interface - Trail Trace Identifier Input: The function user is expected to load in the 64-byte TTI Message into the OTUk_TT_So circuitry via this input. The OTUk_TT_So function will then transmit the message to the remote Network Element, one byte-at-a-time, over 64 consecutive outbound OTUk frames.

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

Discounts Available for a Short Time!!

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

OTN Related Topics within this Blog

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

What is an Atomic Function for OTN?

This post briefly introduces the concept of the Atomic Functions that ITU-T G.798 uses to specify the Performance Requirements of OTN systems.

What is an Atomic Function for OTN Applications?

If you have read through many of the ITU standards, particularly those documents that discuss the declaration and clearance of defect conditions, you have come across Atomic Functions.

For OTN applications, ITU-T G.798 is the primary standard that defines and describes defect conditions.

If you want to be able to read through ITU-T G.798 and have any chance of understanding that standard, then you will need to understand what these atomic functions are.

I will tell you that you will have a tough time understanding ITU-T G.798 without understanding these atomic functions.

Therefore, to assist you with this, I will dedicate numerous blog postings to explain and define many of these atomic functions for you.

NOTE: I also cover these Atomic Functions extensively in Lesson 8 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

OK, So What are these Atomic Functions?

You can think of these atomic functions as blocks of circuitry that do certain things, like pass traffic, compute and insert overhead fields, check for, and declare or clear defects, etc.

These atomic functions are theoretical electrical or optical circuits. They have their own I/O, and ITU specifies each function’s functional architecture and behavior.

It is indeed possible that a Semiconductor Chip Vendor or System Manufacturer could make products that exactly match ITU’s descriptions for these atomic functions. However, no Semiconductor Chip Vendor nor System Manufacturer does this. Nor does ITU require this.

ITU has defined these Atomic Functions such that anyone can judiciously connect a number of them to create an Optical Network Product, such as an OTN Framer or Transceiver.

However, if you were to go onto Google and search for any (for example) OTUk_TT_Sk chips or systems on the marketplace, you will not find any. But that’s fine. ITU does not require that people designing and manufacturing OTN Equipment make chips with these same names nor have the same I/O as these Atomic Functions.

OK, So Why bother with these Atomic Functions?

The System Designer is not required to design a (for example) OTUk_TT_Sk function chip. They are NOT required to develop chips with the same I/O (for Traffic Data, System Management, etc.).

However, if you were to design and build networking equipment that handles OTN traffic, you are required to perform the functions that ITU specified for these atomic functions.

For example, if you design a line card that receives an OTUk signal and performs the following functions on this signal.

Checks for defects and declare and clear them as appropriate, and
Monitors the OTUk signal for bit errors and
Converts this OTUk signal into an ODUk signal for further processing

Although you are NOT required to have OTUk_TT_Sk and OTUk/ODUk_A_Sk atomic function chips sitting on your line card, you are required to support all of the ITU functionality defined for those functional blocks.

Therefore, you must understand the following:

Which atomic functions apply to your system (or chip) design, and
What are the requirements associated with each of these applicable atomic functions?

If you understand both of these items, you fully understand the Performance Monitoring requirements for your OTN system or chip.

What type of Atomic Functions does ITU-T G.798 define?

ITU-T G.798 defines two basic types of Atomic Functions:

Adaptation Functions and
Trail Termination Functions

I will briefly describe each of these types of Atomic Functions below.

Adaptation Functions

Adaptation Functions are responsible for terminating a signal at a particular OTN or network layer and then converting that signal into another OTN or network layer.

For example, an Adaptation function that we discuss in another post is a function that converts an ODUk signal into an OTUk signal (e.g., the OTUk/ODUk_A_So function).

Whenever you read about atomic functions (in ITU-T G.798), you can also tell that you are dealing with an Adaptation atomic function if you see the upper-case letter A within its name.

For example, I have listed some Adaptation functions that we will discuss within this blog below.

OTSi/OTUk-a_A_So – The OTSi to OTUk Adaptation Source Function with FEC (for OTU1 and OTU2 Applications)
OTSi/OTUk-a_A_Sk – The OTSi to OTUk Adaptation Sink Function with FEC (for OTU1 and OTU2 Applications)
OTSiG/OTUk-a_A_So – The OTSiG to OTUk Adaptation Source Function with FEC (for OTU3 and OTU4 Applications)
OTSiG/OTUk-a_A_Sk – The OTSiG to OTUk Adaptation Source Function with FEC (for OTU3 and OTU4 Applications)
OTUk/ODUk_A_So – The OTUk to ODUk Adaptation Source Function
OTUk/ODUk_A_Sk – The OTUk to ODUk Adaptation Sink Function
ODUkP/ODUj-21_A_So – The ODUkP to ODUj Multiplexer Source Atomic Function
ODUkP/ODUj-21_A_Sk – The ODUkP to ODUj Multiplexer Sink Atomic Function

Another Way to Identify an Adaptation Function?

ITU in general (and indeed in ITU-T G.798) will identify the Adaptation Function with trapezoidal-shaped blocks, as shown below in Figure 1.

Figure 1, A Simple Illustration of an Adaptation Function (per ITU-T G.798)

Now that we’ve briefly introduced you to Adaptation Functions let’s move on to Trail Termination Functions.

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

Corporate Discounts Available!!!

Trail-Termination Functions

Trail Termination functions are typically responsible for monitoring the quality of a signal as it travels from one reference point (where something called the Trail Termination Source function resides) to another reference point (where another thing is called the Trail Termination Sink function lies).

When you read about atomic functions (in ITU-T G.798), you can also tell that you are dealing with a Trail Termination atomic function if you see the upper-case letters TT within its name.

The Trail Termination functions allow us to declare/clear defects and flag/count bit errors.

I’ve listed some of the Atomic Trail-Termination Functions we will discuss in this blog below.

OTUk_TT_So – The OTUk Trail Termination Source Function
OTUk_TT_Sk – The OTUk Trail Termination Sink Function
ODUP_TT_So – The ODUk Trail Termination Source Function (Path)
ODUP_TT_Sk – The ODUk Trail Termination Sink Function (Path)
ODUT_TT_So – The ODUk Trail Termination Source Function (TCM)
ODUT_TT_Sk – The ODUk Trail Termination Sink Function (TCM)

Another way to Identify a Trail-Termination Function?

In general (and indeed in ITU-T G.798), ITU will identify Trail Termination Function with triangular-shaped blocks. I show an example of a drawing with a Trail-Termination below in Figure 2.

Figure 2, A Simple Illustration of a Trail Termination Function (per ITU-T G.798)

We will discuss these atomic functions in greater detail in other posts.

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

Discounts Available for a Short Time!!

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

What is OTUk-BIP-8 or SM-BIP-8?

This post describes the OTUk-BIP-8 (or Section Monitoring BIP-8) value for OTN applications. This post also describes how Networking Equipment both computes and transports this data over a fiber optic connection, as well as how Networking Equipment checks and identifies data transmission errors through the SM-BIP-8 parameter.

What is the OTUk-BIP-8 or Section Monitor (SM-BIP-8) Parameter, and How Do We Compute and Verify it?

This post will define and describe the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bit) parameter.

In particular, we will describe how the OTN uses this parameter to perform error detection at the OTUk layer.
Secondly, we will describe how a Transmitting OTUk Network Element (or a Source Section Terminating Equipment) computes and inserts the SM-BIP-8 Value into the OTUk data stream.
Third, we will describe how a Receiving OTUk Network Element (or a Sink Section Terminating Equipment) computes and verifies the SM-BIP-8 Value to check for data transmission errors.
Finally, we will discuss the results that a Receiving OTUk Network Element will come up with whenever it does compute and verify the SM-BIP-8 byte value.

NOTES:

From this point on, I will refer to the Transmitting OTUk Network Element as the Source STE (or Section Terminating Equipment). I will also refer to the Receiving OTUk Network Element as the Sink STE.
We discuss the SM-BIP-8 field extensively in Lesson 9 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

Introduction

For OTN applications, the OTUk layer supports Error Detection and Correction through two means.

FEC – Forward Error Correction and
BIP-8 – Bit Interleaved Parity – 8 bits

FEC is an Error Detection and Error-Correction scheme discussed in another post.

BIP-8 is purely an error-detection scheme. It does not support any error correction capabilities.

The OTUk, ODUk, and Tandem Connection Monitoring layers use the BIP-8 error detection scheme.

In this post, we will discuss (what we call) the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bits) scheme for the OTUk layer.

NOTE: We refer to this error detection scheme as SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bits) because this is the detection scheme that OTN Equipment would employ over a Section via STE (or Section Terminating Equipment).

Please see the post on Section Terminating Equipment for more information on this.

In another post, we discuss the PM-BIP-8 (Path Monitoring – Bit Interleaved Parity – 8 bits) scheme for the ODUk layer.

NOTE: In this post, we will interchangeably use the terms BIP-8, OTUk-BIP-8, and SM-BIP-8.

So How does the OTN use the SM-BIP-8 scheme?

In every connection between any two adjacent pieces of Networking Equipment, there is an entity that transmits data (e.g., the Source STE), and there is also an entity that receives that data (e.g., the Sink STE).

In most cases, two adjacent pieces of Networking Equipment will also be communicating with each other in a bi-directional manner.

This means that every piece of Network Equipment will transmit and receive data. This also means that every piece of Network Equipment will contain both a Source STE and a Sink STE.

For OTN application, any time a Source STE transports data to another Network Element via optical fiber or a copper medium, it must encapsulate this data into a series of back-to-back OTUk frames.

Please see the post on OTUk frames to learn more about the OTUk frame structure.

Brief Overview – How the Source STE creates and transports the SM-BIP-8 Byte Value

As the Source STE encapsulates its outbound (client and ODUk) data into a series of OTUk frames, it will perform various functions.

It will compute and append the FEC field to the back-end of each outbound OTUk frame.
It will compute and insert the SMOH (Section Monitoring Overhead) into each outbound OTUk frame. In particular, the Source STE will
- Insert the Trail Trace Message bytes into the TTI byte-field
- Set the BDI (Backward Defect Indicator) and IAE (Input Alignment Error) bit-fields to the appropriate values (depending upon Network Conditions)
- Set the BEI/BIAE nibble-field to the appropriate Value (depending upon Network Conditions).

Finally, the Source STE will compute an SM-BIP-8 value for each outbound OTUk frame.

Whenever the Source STE computes the SM-BIP-8 byte value, it will do so by performing a specific type of parity calculation over much of the data within the OTUk frame.

Afterward, the Source STE will insert this SM-BIP-8 byte value into the SMOH (Section Monitoring Overhead) within each outbound OTUk frame.

The Source STE will transport this data (e.g., the OTUk frame data and the SM-BIP-8 Value) over optical fiber to the remote Sink STE.

Brief Overview – How the Sink STE Receives and Processes the SM-BIP-8 byte Values

The Sink STE will accept and process this continuous stream of incoming OTUk frames that it is receiving from the remote Source STE.

As it processes this OTUk data stream, it will verify the SM-BIP-8 byte value within each OTUk frame it receives from the (Remote) Source STE.

The Sink STE verifies this data to check for any transmission errors that might have occurred as these OTUk frames travel from the (Remote) Source STE to the (Near-End) Sink STE.

As the Sink STE verifies this data, it will perform the same parity calculations on the data within the OTUk frames as the (remote) Source STE.

Afterward, the Sink STE will compare its “Locally-Computed” SM-BIP-8 byte value with that computed by the (remote) Source STE.

If the two values for the SM-BIP-8 byte match, then we can state that the Sink STE received the corresponding OTUk frame error-free.

On the other hand, if the two values for SM-BIP-8 do not match, then we know that the Sink STE has detected at least a one-bit error within this particular OTUk frame.

The Details – How does the Source STE generate the SM-BIP-8 Value?

Now that we have the Brief Introductory material out of the way, let’s discuss this in greater detail.

In this section, we will describe the following:

Exactly how the Source STE computes the SM-BIP-8 byte value, and
How it inserts this SM-BIP-8 byte into the OTUk data-stream, as it transmits this data to the remote Sink STE.

The Source STE and Introduction to the OTUk_TT_So Atomic Function

ITU-T G.798 refers to the Source STE, which is responsible for (among other things) computing and inserting the SM-BIP-8 Value into the OTUk SMOH as the OTUk_TT_So (OTUk Trail Termination Source) atomic function.

Please see the post on the OTUk_TT_So function to learn more about this atomic function.

NOTE: We will use the terms Source STE and the OTUk_TT_So function interchangeably throughout this post.

How do we perform a BIP-8 (Bit Interleaved Parity – 8 Bit) Calculation?

The OTUk_TT_So function will compute the SM-BIP-8 Value (for a given OTUk frame) over the data that resides within the OPU portion of that outgoing OTUk frame (e.g., byte-columns 15 through 3824).

Figure 1 presents an illustration that identifies that portion of the OTUk frame that the OTUk_TT_So function will use to perform the BIP-8 Calculations.

Figure 1, Illustration of that portion of the OTUk frame, which the OTUk_TT_So function will use for the Section Monitoring BIP-8 Calculation

NOTE: The OTUk_TT_So function will also include the OPU Overhead within these BIP-8 calculations.

This also means that the OTUk_TT_So function will compute the BIP-8 Value (4 x 3,810 =) 15,240 bytes within each outbound OTUk frame.

The OTUk_TT_So function will compute the BIP-8 Value over this 15,240-byte structure by effectively stacking all 15,240 bytes in a single byte-wide column, similar to what we show below in Figure 2.

Figure 2, Illustration of How the OTUk_TT_So function computes the BIP-8 Value

Figure 2 shows that the OTUk_TT_So function has (effectively) created a 15,240 row by an 8-bit column data structure.

The OTUk_TT_So function will then parse through each of the 8-bit columns within this data structure and compute the EVEN parity value for each of these bit-columns (over 15,240 bits).

Since there are 8-bit columns, the OTUk_TT_So function will compute eight individual EVEN parity bits (one for each bit-column).

This resulting set of the 8 EVEN parity bits is the SM-BIP-8 byte value for this particular OTUk frame.

This procedure describes how we perform a BIP-8 calculation over a block of data (such as the OPUk-portion of an OTUk frame).

How does one Source STE transport the SM-BIP-8 to another Network Element?

The OTUk_TT_So function will then take this BIP-8 byte value and insert it into the SM-BIP-8 byte field within the Section Monitoring field of the outbound OTUk frame, two frame periods later, as we show below in Figure 3.

Figure 3, Illustration of How the OTUk_TT_So function inserts the SM-BIP-8 byte values into the OTUk data-stream

The OTUk_TT_So function adds this 2-frame delay to give the Sink STE (at the remote terminal) enough time to compute and verify the SM-BIP-8 byte value (at its end).

Figures 4 and 5 together present the exact location of the SM-BIP-8 byte-field within each outbound OTUk frame.

Figure 4 illustrates the OTUk frame format, with the Section Monitoring (SM) field highlighted.

Figure 4, Illustration of the OTUk Frame with the Section Monitoring (SM) field highlighted

And Figure 5 presents an illustration of the Section Monitoring (SM) field with the SM-BIP-8 byte-field highlighted.

Figure 5, Illustration of the Section Monitoring (SM) field, with the BIP-8 byte-field highlighted

The OTUk_TT_So function will transmit this OTUk data stream (along with the locally-computed SM-BIP-8 byte value) to the remote terminal equipment.

We will discuss below how the Remote Sink STE receives and processes these OTUk frames and their SM-BIP-8 values.

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

Discounts Available for a Short Time!!!

What does the Sink STE do with the SM-BIP-8 Value?

The Sink STE performs the exact opposite role, as does the Source STE.

The Sink STE and Introduction to the OTUk_TT_Sk atomic function

ITU-T G.798 refers to the entity that (among other things) computes and verifies the SM-BIP-8 byte values (for each OTUk frame) as the OTUk_TT_Sk (OTUk Trail Termination Sink) atomic function.

Please see the post on the OTUk_TT_Sk function to learn more about this atomic function.

NOTE: We will use the terms Sink STE and OTUk_TT_Sk function interchangeably throughout the remainder of this post.

I stated earlier that the OTUk_TT_Sk function has the exact opposite role, as does the OTUk_TT_So function.

The OTUk_TT_Sk function verifies the SM-BIP-8 byte value for each OTUk frame it receives from the remote Source STE (OTUk_TT_So Function).

Once again, the purpose of having the OTUk_TT_Sk function check and verify the SM-BIP-8 byte values is to check for the occurrence of bit errors within the OTUk data stream as it travels from the OTUk_TT_So function (within the Source STE), across optical fiber, to the OTUk_TT_Sk function (within the Sink STE).

Figure 6 presents a simple illustration of an OTUk_TT_So function transporting this OTUk data stream to the OTUk_TT_Sk function at the remote terminal.

Figure 6, Illustration of the OTUk_TT_So function transporting an OTUk data-stream to the OTUk_TT_Sk function (at the remote terminal)

For your reference, the circuitry (that I show above) in Figure 6 is functionally equivalent to the Network Element connections I show below in Figure 7.

Figure 7, Illustration of the Equivalent Circuitry (in Figure 6), expressed at the Network Element Layer.

We will describe how the OTUk_TT_Sk function computes and verifies the SM-BIP-8 byte value within each incoming OTUk frame.

The OTUk_TT_Sk function computes and verifies these SM-BIP-8 byte values by executing the following two steps to process each OTUk frame it receives.

Step 1 – The OTUk_TT_Sk function will locally compute its SM-BIP-8 byte value for an incoming OTUk frame, and
Step 2 – The OTUk_TT_Sk function will then compare its locally-computed BIP-8 byte value with that which the OTUk_TT_So function (at the Remote STE) inserted into the SM-BIP-8 byte field within the incoming OTUk data-stream.

We will discuss each of these steps below.

STEP 1 – The OTUk_TT_Sk function will locally compute Its sm-BIP-8 byte value for an incoming OTUk frame.

The OTUk_TT_Sk function will locally compute its SM-BIP-8 byte value for an incoming OTUk frame by performing the same procedure that the OTUk_TT_So function did at the remote terminal (Source STE).

The OTUk_TT_Sk function will take the 15,240 bytes of data (that resides within the OPU portion of the OTUk frame), and it will (effectively) stack this data into a 15,240-row x 8-bit column structure.

Figure 8 (once again) presents a simple illustration of an OTUk frame, with the OPU portion (e.g., that portion of the OTUk frame that we use to compute the BIP-8 Value) highlighted.

Figure 8, A Simple Illustration of the OTUk Frame, with the OPU-Portion of the Frame, Highlighted.

And if we were to look at this data differently, Figure 9 presents an illustration of the 15,240 Row by 8-bit column structure that the OTUk_TT_Sk function effectively creates from the OPU portion of each incoming OTUk frame.

Figure 9, Illustration of How the OTUk_TT_Sk Computes the SM-BIP-8 byte value for each incoming OTUk frame

The OTUk_TT_Sk function will then parse through each 8-bit column (shown above in Figure 9) individually and compute the EVEN parity of the contents within each bit-column.

Note that it will perform parity calculations over 15,240 bits of data.

Once the OTUk_TT_Sk function has completed this process over each of the eight bit-columns, it will have an 8-bit expression.

This 8-bit expression is (once again) the SM-BIP-8 byte value for this particular OTUk frame.

After the OTUk_TT_Sk function computes its version of the SM-BIP-8 byte value, it needs to perform STEP 2 (of this BIP-8 Verification Process).

STEP 2 – The OTUk_TT_Sk function will compare its Locally-Computed BIP-8 Value with that inserted into the BIP-8 field (by the OTUk_TT_So function at the remote STE).

Once the OTUk_TT_Sk function reads in the contents of an OTUk frame and locally computes its SM-BIP-8 byte value (for that OTUk frame), it then needs to obtain the Value of the remotely-computed SM-BIP-8 byte-field.

If you recall, earlier in this post, I mentioned that the OTUk_TT_So function (at the remote terminal) would compute the SM-BIP-8 byte value for a given OTUk frame, and then it will insert this BIP-8 Value into the SM-BIP-8 byte-field, two OTUk frames later.

I show this relationship between the OTUk frame (that the OTUk_TT_So function computed the SM-BIP-8 byte value for) and its placement within the OTUk data stream above in Figure 3.

Therefore, the OTUk_TT_Sk function will find this remotely-computed SM-BIP-8 byte value for a given OTUk frame, two (2) OTUk frames later, within the SM-BIP-8 byte-field position.

Once the OTUk_TT_Sk function has obtained these two versions of the SM-BIP-8 byte values, it will then need to compare those two values with each other.

If the two BIP-8 byte-values are equal, then this means that this particular OTUk frame incurred no bit errors during transmission over the optical fiber.

On the other hand, if these two BIP-8 byte values are NOT the same, this particular OTUk frame DID incur bit errors during transmission over optical fiber to the Sink STE.

In this case, the OTUk_TT_Sk function must determine how many bits (between these two versions of the SM-BIP-8 byte values) are different from each other.

Stated differently, the OTUk_TT_Sk function compares its locally computed SM-BIP-8 byte value and that it reads in from the SM-BIP-8 byte-field within the incoming OTUk data-stream and will perform a bit-by-bit XOR operation with each of these byte values.

The OTUk_TT_Sk function must then count the number of “1s” that occurs during that bit-wise XOR calculation (for each incoming OTUk frame).

The OTUk_TT_Sk function will come up with any one of the following nine (9) possible results.

0 bits in Error – Error-Free Transmission
1 bit in Error
2 bits in Error
3 bits in Error
4 bits in Error
5 bits in Error
6 bits in Error
7 bits in Error
8 (or all) bits in Error

Figure 10 presents a simple illustration of the Bit-Wise XOR Operation that the OTUk_TT_Sk function performs with both the locally-computed and remotely-computed SM-BIP-8 byte values.

Figure 10, Illustration of the Bit-Wise XOR Process for Verifying and Comparing the Locally-Computed SM-BIP-8 Byte Value with the Extracted (Remotely Computed) SM-BIP-8 Byte value for a given OTUk frame

The OTUk_TT_Sk function will then need to use the results of these BIP-8 comparisons for the following purposes.

To send out the results of these comparisons to the remote terminal in the form of the SM-BEI (Section Monitor – Backward Error Indicator) Value. Please see the post on SM-BEI to learn more about this topic.
It will use these results to determine if the OTUk_TT_Sk function should declare or clear the dDEG (Signal Degrade) defect condition. (*)
To use for Performance Monitoring Purposes (e.g., to compute the pN_EBC parameter in this case). Please see the post on the pN_EBC (Near-Error Block Count) Performance Monitor parameter to learn more about this topic.

Will the OTN Network Element ever declare any defects due to excessive SM-BIP-8 errors?

Yes, if the Sink STE were to detect a large number of SM-BIP-8 byte errors over a long period (e.g., typically on the order of seconds), then the Sink STE (or OTUk_TT_Sk Function) can declare the dDEG (Signal Degrade) defect condition.

I describe how the OTUk_TT_Sk atomic function declares and clears the OTUk-dDEG (Signal Degrade) defect condition within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!

Summary

This post describes the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bit) parameter.

At a high level, we have described how the OTN uses this parameter to perform error detection at the OTUk layer.

We have also specifically described how a Source STE computes and inserts the SM-BIP-8 byte value into the OTUk data stream.

We have also described how a Sink STE computes and verifies the SM-BIP-8 byte value (within each incoming OTUk frame) to check for the occurrence of data transmission errors.

Finally, we have identified the results that a Sink STE will come up with whenever it does compute and verify the SM-BIP-8 byte value. We also mentioned that the Sink STE would use these results to:

Determine if the Sink STE should declare or clear the dDEG (Signal Degrade) defect condition.
Support the generation of Performance Monitor reports for the pN_EBC (Near-End Error Block Count) parameter to System-Level Management.
Support the generation and transmission of the SM-BEI (Section Monitoring – Backward Error Indicator) parameter within the OTUk data stream.

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

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

A Note about Terminology:

A Brief Review of the OTUk Frame Structure

The MFAS Byte Increments with each Frame

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

Corporate Discounts Available!!

A Basic Requirement before We can Clear the dLOM Defect Condition

The Sink STE needs to find the FAS-field first

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

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

The dLOM-Related State Machines

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

The LL-OOM State

The LL-IM State

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

Discounts Available for a Short Time!!!

The OTUk-dLOM Framing Alignment/Maintenance State Machine

The dLOM/LL-OOM State

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

If the New_Candidate_MFAS_Value fails the Test

If the New_Candidate_MFAS_Value passes the Test

The dLOM/LL-IM State

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

Regressing to the dLOM/LL-OOM State

The In-Multi-Frame/LL-IM State

What Does Clearing the dLOM Defect Mean?

The In-Multi-frame/LL-OOM State

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

Regressing to the dLOM/LL-OOM 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 OTUk_TT_So Atomic Function?

Introduction

So What Does this Atomic Function Do?

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

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

Some Details about the OTUk_TT_So Function

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

Corporate Discounts Available!!

The OTUk_AP (OTUk Access Point) Interface

The OTUk_TT_So_RP (Remote Port) Interface

The OTUk_TT_So_MP (Management Port) Interface

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

List of Input and Output Signals for the OTUk_TT_So Atomic Function

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

Discounts Available for a Short Time!!

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

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

OK, So What are these Atomic Functions?

OK, So Why bother with these Atomic Functions?

What type of Atomic Functions does ITU-T G.798 define?

Adaptation Functions

Another Way to Identify an Adaptation Function?

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

Corporate Discounts Available!!!

Trail-Termination Functions

Another way to Identify a Trail-Termination Function?

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

Discounts Available for a Short Time!!

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

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is the OTUk-BIP-8 or Section Monitor (SM-BIP-8) Parameter, and How Do We Compute and Verify it?

Introduction

So How does the OTN use the SM-BIP-8 scheme?

Brief Overview – How the Source STE creates and transports the SM-BIP-8 Byte Value

Brief Overview – How the Sink STE Receives and Processes the SM-BIP-8 byte Values

The Details – How does the Source STE generate the SM-BIP-8 Value?

The Source STE and Introduction to the OTUk_TT_So Atomic Function

How do we perform a BIP-8 (Bit Interleaved Parity – 8 Bit) Calculation?

How does one Source STE transport the SM-BIP-8 to another Network Element?

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

Discounts Available for a Short Time!!!

What does the Sink STE do with the SM-BIP-8 Value?

The Sink STE and Introduction to the OTUk_TT_Sk atomic function

STEP 1 – The OTUk_TT_Sk function will locally compute Its sm-BIP-8 byte value for an incoming OTUk frame.

STEP 2 – The OTUk_TT_Sk function will compare its Locally-Computed BIP-8 Value with that inserted into the BIP-8 field (by the OTUk_TT_So function at the remote STE).

Will the OTN Network Element ever declare any defects due to excessive SM-BIP-8 errors?

Summary

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

What is the OTUk_TT_So Atomic Function?

What is an Atomic Function for OTN Applications?

What is the OTUk-BIP-8 or Section Monitor (SM-BIP-8) Parameter, and How Do We Compute and Verify it?