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.

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

Each of these atomic functions includes the dLOM Detection circuit.

A Note about Terminology:

Throughout this blog post, I will be referring to the entity that contains 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 that it is a lot simpler to use that word than to use the words:  OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions.  However, I will be using 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 present an illustration of the OTUk Frame Structure, with the MFAS-field highlighted, below in Figure 1.

OTUk Frame Format with the MFAS Byte-field Highlighted - dLOM Defect

Figure 1, Illustration 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 being the very 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 very next OTUk frame, then it will set the MFAS byte (within that particular OTUk frame) to 0x01.

The Source STE will continue to increment the MFAS byte, within each outbound OTUk frame until it has transmitted the 256th frame, within this particular multi-frame, and it has set the MFAS byte (within that frame) 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 indicate 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.

A Basic Requirement before We can Clear the dLOM Defect Condition

Before I continue with discussing 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.

It is impossible for the Sink STE to 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 will automatically lose MFAS synchronization as well.

There are several reasons for this:

The Sink STE needs to find the FAS-field first

Since 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 then locate the MFAS byte.

The FAS-field is FAR easier 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 simply looking for these fixed patterns.  On the other hand, the MFAS byte value changes with every OTUk frame.

Additionally, the FAS field is NEVER scrambled.  However, the MFAS byte is scrambled.

I show an illustration of an OTUk frame below, that identifies the portions of the OTUk frame that the Remote Source STE will scramble, before transmitting this OTUk frame to the Near-end Sink STE.

Scrambled Portions of an OTUk Frame - Need for dLOF to be cleared to clear dLOM

Figure 2, Illustration an OTUk Frame – Identifying the portions of the OTUk Frame that are scrambled.  

Finally, the MFAS byte-field is 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 to have 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 move on to discussing how the Sink STE declares and clears the dLOM defect condition.

We will first discuss the dLOM-Related State Machines.

The dLOM-Related State Machines

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

Once the Sink STE has cleared the dLOF defect condition (and can now reliably locate the FAS field within each incoming OTUk frame); then it can proceed on to locate 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 just acquired FAS-frame synchronization with the incoming OTUk frame (as has cleared the dLOF defect condition), then it will always be operating in accordance with two sets of state machines, simultaneously.

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

dLOM Defect - State Machine Hierarchy

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

We will discuss each of 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 present an illustration of the OTUk-MFAS OOM/IM Low-Level State Machine Diagram, below in Figure 4.

dLOM Defect - OTUk-MFAS OOM/IM (Low-Level) State Machine

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

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

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

From the moment that the System Operator powers up the Sink STE circuitry, and feeds an OTUk data-stream to it (from the remote Source STE), and has cleared the dLOF defect, then it will always be operating in one of these two states.

The Sink STE will (on occasion) need to transition from one state to the other and back.

We will discuss each of these two states below.

The LL-OOM State

Whenever a given Sink STE has first cleared 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 it 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 it will (internally) increment this value by 1.  Afterward, the Sink STE will apply this read-in value into the equation above.  The resulting new value will be the “Next _Expected_MFAS_Value” for 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 + 1” 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.

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

However, if the Sink STE were to lose synchronization with the MFAS field (of each incoming OTUk frame) such that 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 pretty tolerant of bit-errors.  In other words, the presence of some 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 discuss the OTUk-dLOM Framing Alignment/Maintenance State Machine.

The OTUk-dLOM Framing Alignment/Maintenance State Machine

I present an illustration of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram, below in Figure 5.

dLOM Defect - OTUk-dLOM Frame Alignment/Maintenance Algorithm - with Criteria shown

Figure 5, Illustration 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 the following 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 also show the underlying state-changes within the OTUk-MFAS OOF/IF State Machine.  I show this redrawn figure below in Figure 6.

dLOM Defect - OTUk-dLOM Frame Alignment/Maintenance State Machine - with Low-Level Terms

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 it starts to receive an OTUk data-stream and (once it has cleared the dLOF defect), then it will always be operating in one of these four states.  On occasion, the Sink STE will transition from one state to another.  As it does this, then it will either declare or clear the dLOM defect as we above in Figures 5 and 6.

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

The dLOM/LL-OOM State

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

dLOM Defect - dLOM-OTUk Framing Alignment/Maintenance State Machine Diagram - with dLOM/LL-OOM State Highlighted

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 the 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 it is 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 is operating 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 is only receiving some stream of back-to-back OTUk frames that it cannot make much sense of.

While the Sink STE is operating in this state, it will parse through the incoming OTUk data-stream and look for 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 a full 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 show an illustration of the OTUk-dLOM Frame Alignment/Maintenance State-Machine diagram, with the dLOM/LL-IM State highlighted, below in Figure 8.

dLOM Defect - dLOM-OTUk Framing Alignment/Maintenance State Machine Diagram with dLOM/LL-IM State Highlighted

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, then we can state that the Sink STE has located (what appears to be) the MFAS-byte-field within the incoming OTUk data-stream.

NOTES:

  1. 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 it was 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.
  2. 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, in the sense that 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, there are two possible things that can happen from here.

  1. It can eventually transition (or advance) into the “In-Multi-Frame/LL-IM” state, or
  2. 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 properly locate the MFAS byte) 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 operating in the dLOM/LL-IM state) were to lose synchronization with the MFAS byte, such that it could no longer 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, then we can say that it is operating in the NORMAL (or intended) state.  We would expect the Sink STE to spend most of its operating lifetime, in this state.

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

dLOM Defect - OTUk-dLOM Framing Alignment/Maintenance State Machine Drawing with In-Multi-Frame/LL-IM State Highlighted

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 is operating in the In-Multi-frame/LL-IM state, then it is now able to locate the MFAS byte-fields within each incoming OTUk frame.

What all Does Clearing the dLOM Defect Mean?

This also means that the Sink STE should be ready to start evaluating other aspects of this incoming OTUk data-stream (that requires multi-frame alignment).  This includes extracting out 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 in which we are mapping and multiplexing lower-speed ODUj signals into higher-speed ODUk 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 is operating in the In-Multi-frame/LL-IM state, then it is quite 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 effects 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).

As a consequence, 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 an illustration of the OTUk-dLOM Frame Alignment/Maintenance State Machine diagram with the In-Multi-frame/LL-OOM State highlighted, below in Figure 10.

dLOM Defect - dLOM-OTUk Framing Alignment/Maintenance State Machine Drawing with In-Multi-Frame/LL-OOM State Highlighted

Figure 10, Illustration 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, then it 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 it was 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 the fact that the Sink STE has transitioned into the LL-OOM state (within the Low-Level State Machine).

Whenever the Sink STE enters the In-Multi-frame/LL-OOM state, then only one of two possible things will happen.

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

We will briefly discuss each of 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), then 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), then it will transition into the dLOM/LL-OOM state.

Whenever the Sink STE transitions into the dLOM/LL-OOM state, then 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 to consistently remain in the LL-IM state for at least 3ms before it can clear the dLOM defect condition (e.g., dLOM ⇒ CLEARED).

Additionally, ITU-T G.798 also requires that the Sink STE NOT be able to locate the MFAS byte and to 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 both declaring and clearing the dLOM defect) to prevent intermittent transitions between the LL-OOM and LL-IM states from causing intermittent transitions (or chattering) in the dLOM state.

Table 1 presents a Summary of 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

ItemDescription
Meaning of the dLOM Defect ConditionThe 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 dLOMThe 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 dLOMThe 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 STEThe 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

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is the OTUk_TT_So Atomic Function?

This blog post briefly defines the OTUk_TT_So (OTUk Trail Termination Source) Atomic Function.


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 (e.g., for example, the OTUk/ODUk_A_So function) and uses the data (within this data-stream) in addition to signals from a collocated OTUk_TT_Sk function to compute/generate and insert the OTUk Section Monitoring Overhead (SMOH) into the OTUk signal.

I show how each of these three atomic functions is connected together below in Figure 1.

OTUk_TT_So_Function_with_OTUk/ODUk_A_So and Collocated OTUk-TT_Sk functions highlighted

Figure 1, Illustration 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 particular function will only generate default values for the OTUk-SMOH, within the OTUk signal that it transmits.  You can almost say that the OTUk/ODUk_A_So function simply generates this default SMOH as a place-holder for a future (and real) SMOH.

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

Well, the purpose of the OTUk_TT_So function is to compute and replace the default SMOH values, with real values.

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

  • BIP-8 field, within the Section Monitoring field
  • BEI field within the Section Monitoring Byte
  • BDI bit-field within the Section Monitoring Byte
  • BIAE bit-field within the Section Monitoring Byte
  • 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 the SMOH data to determine:

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

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

Roles of the SMOH within the OTUk_TT_So function

Figure 2, Illustration 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 simple illustration of the OTUk_TT_So function.

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

Figure 3, Simple Illustration 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 Frame Synchronization Signal (FS), the Multi-Frame Synchronization Signal (MFS), the OTUk data-stream and the IAE (Input Alignment Error) indicator (via the AI_IAE signal).

The OTUk_TT_So function has the responsibility for computing and inserting the correct and appropriate SMOH data into the OTUk data-stream.

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

  • OTUk_AP
  • OTUk_CP
  • OTUk_RP and
  • OTUk_TT_So_MP

We will discuss each of these interfaces below.

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

OTUk_TT_So Atomic Functional Block Diagram

Figure 4 Functional Block Diagram of the OTUk_TT_So function

The OTUk_AP (OTUk Access Point) Interface

Figure 4 shows that the circuitry that is 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.

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 will 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 fields (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 bit-field (within the SMOH) of the very next outbound OTUk frame.

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

OTUk_TT_So Atomic Function connected to its Collocated OTUk_TT_Sk function

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

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

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

The OTUk_TT_So_MP (Management Port) Interface

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

  • MI_TxTI – Trail Trace Identifier Input

The function-user is expected to apply 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 longs, the OTUk_TT_So function will require 64 OTUk frames, for it 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, one of the main responsibilities of the OTUk_TT_So function is to compute/source and correct values for various fields within the SMOH and insert those values into the SMOH within each outbound OTUk frame.

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

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

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

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

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

List of Input and Output Signals for the OTUk_TT_So Atomic Function

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OTN Related Blog

OTN Related Topics within this Blog

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

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 ever read through many of the ITU standards, particularly those documents that discuss the declaration and clearance of defect conditions, then 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 all of this, I will dedicate numerous blog postings to explaining and defining many of these atomic functions for you.

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 also specify a functional architecture and behavior each of these functions.

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 do this.  Nor does ITU require this.

ITU has defined these Atomic Functions, such that anyone can judiciously connect a number of them together to create an actual 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 any chips that have the exact same I/O (for Traffic Data, System Management, etc.).

However, if you were to design and build networking equipment that handles OTN traffic, then you are required to perform the functions that ITU has 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 functionality that ITU has defined for those functional blocks.

Therefore, it is important that you understand the following:

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

If you understand both of these items, then 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 are reading about atomic functions (in ITU-T G.798), then 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

Another Way to Identify an Adaptation Function?

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

OTUk/ODUk_A_Sk Function - Adaptation Atomic Function

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

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 called the Trail Termination Sink function resides).

Whenever you are reading about atomic functions (in ITU-T G.798) then 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 make it possible for us to declare/clear defects and to flag/count bit-errors.

I’ve listed some of the Atomic Trail-Termination Functions, that we will be discussing with 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?

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

OTUk_TT_Sk Function - Trail Trace Atomic Function

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.

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

OTN Related Blog

OTN Related Topics within this Blog

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

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 BIP-8 parameter.


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

We will discuss the following topics in this post.

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

  • In particular, we will describe how the OTN uses this parameter to perform error detection at the OTUk layer.
  • Secondly, we will also 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 also describe how a Receiving OTUk Network Element (or a Sink Section Terminating Equipment) computes and verifies the SM-BIP-8 value, to check for the occurrence of data transmission errors.
  • Finally, we will discuss the type of results that a Receiving OTUk Network Element will come up with, whenever it does compute and verify the SM-BIP-8 byte value.

NOTE:  From this point, I will be referring to the Transmitting OTUk Network Element as the Source STE (or Section Terminating Equipment).  I will also be referring to the Receiving OTUk Network Element as the Sink STE.

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 mostly an Error-Correction scheme that we will discuss in another post.

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

Both the OTUk and ODUk 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 error 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 what this means.

We discuss the PM-BIP-8 (Path Monitoring) scheme for the ODUk layer in another post.

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

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 (we will call a Network Element) will be both transmitting and receiving data.  This also means that every Network Element 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 BIP-8 Value

As the Source STE encapsulates its outbound (client and ODUk) data into a series of OTUk frames, it will perform a wide variety of 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 (again, 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 value, it will do so by performing some logical/mathematical operation over much of the data within the OTUk frame.

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

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

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

The Sink STE will accept and process this continuous stream of incoming OTUk frames.

As it performs this processing, one of the things that it will do is verify the SM-BIP-8 data, within each of the OTUk frames that it is receiving from the (Remote) Source STE.

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

As the Sink STE verifies this data, it will perform the same logical/mathematical operation on the data within the OTUk frames, as did the (remote) Source STE.

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

If the two values for SM-BIP-8 matches, then we can state that the Sink STE received the corresponding OTUk frame data, in an error-free manner.

On the other hand, if the two values for SM-BIP-8 does not match, then we know that the Sink STE has detected at least 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 all of this in greater detail.

In this section, we will describe how the Source STE computes the SM-BIP-8 value.

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 Trace 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 which identifies that portion of the OTUk frame, that the OTUk_TT_So function will use to perform the BIP-8 Calculations.

Section Monitoring BIP-8 Calculation RegionFigure 1, Illustration of the 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 OH within these BIP-8 calculations.

This also means that the OTUk_TT_So function will compute the BIP-8 value over (4 x 3810 =) 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.

Section Monitoring - OTUk BIP-8 Calculation Procedure

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 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 it will compute the EVEN parity for each of these bit-columns (over 15,240 bits).

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

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

This is 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 into the 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.

Section Monitoring BIP-8 Calculation and Insertion Region

Figure 3, Illustration of How the OTUk_TT_So function inserts the BIP-8 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 then verify the BIP-8 value (at the remote-terminal).

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

Figure 4 presents an illustration of the OTUk frame format, with the Section Monitoring (SM) field highlighted.

Location of Section Monitoring Field within OTUk Frame

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 BIP-8 byte-field highlighted.

Location of BIP-8 Byte within Section Monitoring Field

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 BIP-8 value) to the remote terminal equipment.

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

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

The Sink STE has the exact opposite role as that of 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 values (for each OTUk frame) as the OTUk_TT_Sk (OTUk Trail Trace 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.

The OTUk_TT_Sk function has the exact opposite role of that of the OTUk_TT_So function.

The OTUk_TT_Sk function has the role of verifying the BIP-8 values, for each OTUk frame that it receives from the remote terminal equipment.

The purpose of having the OTUk_TT_Sk function check and verify the BIP-8 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 Transmitting Network Element), across optical fiber, to the OTUk_TT_Sk function (within the Receiving Network Element).

Figure 6 presents an illustration of an OTUk_TT_So function that is transporting data to the OTUk_TT_Sk function, at the remote terminal.

OTUk_TT_So to OTUk_TT_Sk unidirection connection

Figure 6, Illustration of the OTUk_TT_So function transporting data to the OTUk_TT_Sk function (at the remote terminal).

At the OTUk-layer, the circuitry in Figure 6 is functionally equivalent the Network Element connections that we show below in Figure 7.

Basic Network Element WEST connected to Network Element EAST bidirectionally over Fiber Optic connection

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

We will now describe how the OTUk_TT_Sk function computes and verifies the BIP-8 values within each incoming OTUk frame.

The OTUk_TT_Sk function computes and verifies these BIP-8 values by executing two steps.

  • Step 1 – The OTUk_TT_Sk function will locally compute the BIP-8 value within an incoming OTUk frame, and 
  • Step 2 – The OTUk_TT_Sk function will then compare the locally-computed BIP-8 value with that which the OTUk_TT_So function (at the Remote Transmitting Terminal) inserted into the BIP-8 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 the BIP-8 value within an incoming OTUk frame. 

The OTUk_TT_Sk function will locally compute the BIP-8 value within an OTUk frame by performing the same procedure that the OTUk_TT_So function did, at the remote terminal.

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.

Section Monitoring BIP-8 Calculation Region

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.

Section Monitoring - OTUk BIP-8 Calculation Procedure

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

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

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

Once the OTUk_TT_Sk function has completed this process, it will have an 8-bit expression.

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

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

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

Once the OTUk_TT_Sk function reads in the contents of an OTUk frame and locally computes the BIP-8 value (for that OTUk frame), it then needs to obtain the contents of the remotely-computed 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 BIP-8 value for a given OTUk frame and then it will insert this BIP-8 value into the BIP-8 byte-field, two OTUk frames later.

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

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

Once the OTUk_TT_Sk function has obtained these two BIP-8 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 values are NOT the same, then it is essential that the OTUk_TT_Sk function determine how many bits (between these two BIP-8 values) are different from each other.

Stated differently, the OTUk_TT_Sk function, as it makes its comparison between its locally computed BIP-8 value and that which it reads in from the BIP-8 field within the incoming OTUk data-stream, it 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 bitwise XOR calculation (for each OTUk frame).

The OTUk_TT_Sk function will come up with any 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 BIP-8 values.

BIP-8 Verification Procedure - Bitwise XOR

Figure 10, Illustration of the Bit-Wise XOR Process for Verifying the Locally-Computed BIP-8 Value with the Extracted (Remotely Computed) BIP-8 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 a BEI (Backward Error Indicator) value.  Please see the post on BEI (Backward Error Indicator) 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 defect condition.
  • To use for Performance Monitoring Purposes (e.g., for the pN_EBC parameter in this case).  Please see the post on the pN_EBC Performance Monitor parameter, to learn more about this topic.

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

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

Please see the post on the OTUk-dDEG (Signal Degrade) defect condition for more information about this defect.

Summary

We have described the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bit) parameter in this post.

In particular, we have described how the OTN uses this parameter to perform error detection at the OTUk layer.

Secondly, we have also described how a Transmitting OTUk Network Element computes and inserts the SM-BIP-8 value into the OTUk data-stream.

Third, we have also described how a Receiving OTUk Network Element computes and verifies the SM-BIP-8 value, to check for the occurrence of data transmission errors.

Finally, we have defined the type of results that a Receiving OTUk Network Element will come up with, whenever it does compute and verify the SM-BIP-8 byte value.  We also mentioned that the Receiving Network Element would use these results to:

  • Determine if the Receiving OTUk Network Element should declare or clear the dDEG (Signal Degradation) defect condition.
  • Support the generation of Performance Monitor reports for the pN_EBC parameter, to System-Level Management.
  • Support the generation and transmission of the BEI (Backward Error Indicator) within the OTUk data-stream.

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

OTN Related Blog

OTN Related Topics within this Blog

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