Lesson 2 – OTU Framing

This post provides a comprehensive review and video training of the OTU frame and its overhead fields.

Lesson 2 – Optical Transport Unit Frame Training

This post includes a video that discusses the OTU (Optical Transport Unit) frames in considerable detail.  

In particular, this video will discuss the OTU frame format and the roles each of its overhead fields plays.

Continue reading “Lesson 2 – OTU Framing”

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:

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.

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

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.

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

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.

dLOM Defect - State Machine Hierarchy

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.

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

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.

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

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.

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

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

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

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

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

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.

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

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.

  1. 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
  2. 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

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

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

The OTU (Optical Transport Unit) Frame

This post defines and describes the OTU (Optical Transport Unit) Frame that is used in OTN (Optical Transport Networks).

What is the OTU Frame/OTUk Frame?

An OTU (Optical Transport Unit) frame is a data structure that an OTN Terminal (or Source STE) will use to transport its data to the outside world.

This post will call any entity that generates and transmits OTUk frames a Source STE (Section Terminating Equipment).  Likewise, we will call any entity that receives, processes, and terminates OTUk frames a Sink STE.  

In other words, as the Source STE accepts OPU/ODU frames to create an OTUk frame, it will encapsulate these OPU/ODU frames into an OTU frame by “tacking” on the OTUk overhead. 

Additionally, the Source STE will pre-condition each OTUk frame for transport over Optical Fiber by computing and appending an FEC (Forward Error Correction) field at the back end of the OTU frame and scrambling much of the OTUk frame data before converting this data into the optical domain and sending it out on Optical Fiber.  

Likewise, the OTU frame is a data structure that an OTN Terminal (or Sink STE) will accept as it receives data from the outside world.

In this case, the OTN Terminal (e.g., Sink STE) will perform the reverse functions as the Source STE.  

It will receive an optical signal from the remote STE and convert this data back into an electrical format.  Afterward, it will descramble this incoming OTUk data stream, decode the FEC field, and correct most symbol errors in the process.  

Finally, the Sink STE will terminate the OTUk data stream by extracting out the OPU/ODU frames and routing this data to downstream circuitry.  

To be clear, What do We Mean by Frame?

OTN, just like many other Networking Standards, uses framing to organize the data it transmits and receives.

Framing is a Data Link Layer function.  A transmitting terminal will organize a group of data bits into a specific data structure (called a “frame”) before transmitting it across a link.

Please see the post about the Data Link Layer for more information about the concept of Framing.

Please note that we are not talking about this kind of frame.

For OTN applications, we only transmit data that we have encapsulated into the form of an OTU frame out onto optical fiber.

OPUk and ODUk signals may be handled and processed internally (within a network element or an integrated circuit).

But we NEVER transmit OPUk and ODUk data onto the network (over optical fiber) unless we first encapsulate these signals into an OTUk frame and pre-condition this data for transport over Optical Fiber.

OTN Section and Path Terminating Equipment

In the OTN arena, we will often state that OTN Section Terminating Equipment (STE) is the entity that is responsible for transmitting and receiving OTUk frames.

We will also state that OTN Path Terminating Equipment (PTE) handles and processes ODUk frames.

Please see the posts for OTN Section Terminating Equipment (STE)and OTN Path Terminating Equipment (PTE) to understand the differences between these two types of equipment.

The OTUk Frame Format

Figure 1 illustrates the format for the standard ITU-T G.709-compliant OTU Frame.

OTUk Frame - Byte Format

Figure 1, Illustration of the Format of the ITU-T G.709-Compliant OTU Frame

This figure shows that an OTU Frame is a 4-Byte-Row by 4080-Byte-Column Structure.  Hence, each OTU Frame consists of (4 x 4080 =)16,320 bytes.

Please note that all OTU Frames (whether an OTU1, OTU2, OTU3, or OTU4 frame) are all the same size; therefore, each frame has exactly 16,320 bytes.

NOTE:  Since each of these OTU frames are the same size (regardless of whether we are talking about an OTU1, OTU2, OTU3, or OTU4), we will, from here on, refer to these OTU frames as OTUk frames.

The Fields within an OTUk Frame

Let’s talk about the various fields within an OTUk frame.

Some of the fields in the OTUk frame have the following labels.

  • FAS
  • MFAS
  • OTUk OH
  • FEC
  • ODUk Frame

I will briefly define each of these bytes below.

FAS – Framing Alignment Signal field

The Framing Alignment Signal field occupies the first 6 bytes within an OTUk Frame.

The first three bytes (which we sometimes call the OA1 bytes) each have a fixed value of 0xF6.

The remaining three bytes (in the FAS field), which we sometimes call the OA2 bytes, each have a fixed value of 0x28.

The purpose of the FAS bytes is to provide the remote receiving OTN terminal (e.g., the Sink STE) with this fixed pattern so that it will “know” that it is receiving the first bytes of a new OTUk frame.

The Sink STE will parse through its incoming OTUk frame data stream.  As it does this, it will search for the occurrence of three consecutive bytes (each with the value 0xF6) followed by another set of three successive bytes (each with the value 0x28).

The Sink STE will rely on these FAS bytes to acquire and maintain framing alignment/synchronization with the incoming stream of OTUk frames.

If the Sink STE repeatedly fails to acquire and maintain framing alignment/synchronization with this incoming stream of OTUk frames, it will declare the dLOF (Loss of Frame) defect condition.  

MFAS – Multi-Frame Alignment Signal byte

The MFAS byte occupies the 7th byte within an OTUk frame and “resides” immediately after the FAS bytes.

Unlike the FAS bytes, the MFAS byte’s value is not fixed, as I will explain here.  

A given Source STE will transmit OTUk frames in groups of Multi-frames.

Each of these multi-frames consists of 256 consecutive OTUk frames.

Whenever a Source STE transmits the first OTUk frame (of a given Multi-frame), it will designate this particular frame as the first frame (of this multi-frame) by setting its MFAS byte field to 0x00.

When the Source STE transmits the next OTUk frame, it will set the MFAS byte (within that particular OTUk frame) to 0x01, and so on.

As the Source STE transmits each OTUk frame, it will increment the value assigned to the MFAS byte field until it reaches the value 0xFF (or 255 in decimal format).

The Source STE will then start over with transmitting a new multi-frame and set the MFAS of this next OTUk frame to 0x00, and the process repeats indefinitely.

The MFAS is a significant byte for a receiving OTN terminal (e.g., Sink STE) to keep track of because other data (such as the TTI – Trail Trace Identifier message – that is transmitted via some of the additional overhead bytes across multiple OTUk frames).

The Source STE will align the transmission of these particular messages (e.g., the SM-TTI messages, PM-TTI messages, PSI Messages, etc.) with the MFAS byte as it transports these messages via the OTUk data stream.

Please see the relevant posts on SM-TTI (Section Monitoring – Trail Trace Identifier) Messages, PM-TTI (Path Monitoring – Trail Trace Identifier) Messages, and PSI (Payload Structure Identifier) Messages to learn more about these types of messages.  

ODUk Frame

The ODUk Frame “portion” of the OTUk frame is all the remaining data (which resides within the OTUk frame) that is not considered an OTUk Overhead field.  This includes all bytes within the ODU (Optical Data Unit) and, in turn, OPU (Optical Payload Unit) within the OTUk frame.  Please see the posts for ODUk and OPUk to learn more about those parts of the OTUk frame.

FEC – Forward Error Correction

ITU-T G.709 specifies that OTUk frames should include an FEC (Forward Error Correction) field that contains the Reed-Solomon RS (255,239) FEC codes.

NOTE:  I discuss the RS(255,239) FEC code in detail in Lesson 9, within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

The FEC field permits a Sink STE to detect and correct many symbol (or byte) errors that may have occurred during transmission.

ITU-T G.709 indicates that using FEC is optional for OTU1, OTU2, and OTU3 applications.  

However, the use of FEC is mandatory for OTU4 applications.  

Please see the OTUk FEC discussion within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!  for more information about this field.

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

Discounts Available for a Short Time!!!

The Rest of OTUk OH (Overhead) fields

The remaining OTUk OH fields consist of the following three fields for a total of seven (7) bytes:

  • SM Field
  • GCC0 Field
  • OSMC (OTN Synchronizing Messaging Channel) Field
  • RES (Reserved) Field

We will briefly describe each of these fields below.

SM (Section Monitoring) Field (3 bytes)

Figure 2 shows the byte format for the Section Monitoring or SM Field.

OTU - SM (Section Monitoring) Field, TTI Byte, BIP-8 Byte, SM Byte

Figure 2, Byte-Format of the SM (Section Monitoring) Field

This figure shows that the SM Field consists of the following three bytes:

  • TTI – Trail Trace Identifier Byte
  • BIP-8 Byte
  • SM Byte

Below, we will describe each of the bytes (within the SM field).  We also discuss these fields in much greater detail in their respective posts.

TTI – Trail Trace Identifier Byte

This byte-field carries the 64-byte Section Monitoring Trail-Trace Identifier message.  Since there is only one TTI byte within each OTUk frame, the OTN Transmitter (or Source STE) will transmit 64 OTUk frames to send the entire 64-byte Trail Trace Identifier message.

Please see the Section Monitor-Trail Trace Identifier post to learn how we use this identifier in an OTN system.

BIP-8 (Section Monitoring BIP-8) Byte

The Source STE will perform a BIP-8 calculation over the entire OPUk frame within its corresponding OTUk frame.

Afterward, the Source STE will insert the results of this BIP-8 calculation into the SM-BIP-8 byte field of the outbound OTUk frame two frame periods later.

Finally, the remote Sink STE will use this BIP-8 calculation to check for bit errors during transmission.

Please see the Section Monitoring BIP-8 post for more information about how we compute and use this byte field in an OTN system.

SM (Section Monitoring) Byte

Figure 3 presents the bit format for the Section Monitoring Byte (not to be confused with the 3-byte SM field).

OTU Frame - Section Monitoring Byte Format - Optical Transport Networks

Figure 3, Bit Format of the Section Monitoring Byte

This figure shows that the SM Byte consists of the following bit fields:

  • BEI/BIAE (4 bits)
  • BDI (1 bit)
  • IAE (1 bit)
  • RES – Reserved (2 bits)

We will briefly describe each of these bit-fields below.

BEI/BIAE – Section Monitoring – Backward Error Indicator (BEI) or Backward Incoming Alignment Error (BIAE) – (4 bits)

The purpose of the BEI/BIAE nibble-field is two-fold.

  • To permit the Source STE to provide the remote Sink STE (at the far-end) with feedback on the number of SM-BIP-8 errors that the near-end (local) Sink STE is detecting within its incoming OTUk data stream.
    • The Source STE will set the BEI/BIAE nibble-field (within each outbound OTUk frame) to the SM-BEI (Backward Error Indicator) value.  
  • And to permit the Source STE to alert the remote Sink STE (again, at the far-end) that the near-end (local) Sink STE is declaring the dIAE defect condition.
    • The Source STE will accomplish this by setting the BEI/BIAE nibble-field to the value of “1011”, which carries the BIAE (Backward Input Alignment Error) Indicator.  

Table 1 presents the range of values that the Source STE can set the BEI/BIAE Nibble-field, within its outbound OTUk frames, for each of the conditions mentioned above. 

Table 1, How to Interpret the Section Monitoring BEI/BIAE bit-fields

OTUk SM_BEI/BIAE Nibble-ValueSink STE declaring the dIAE Defect?Number of SM-BIP-8 Errors DetectedComments
0000NO0Good Condition
0001NO1BIP-8 Error
0010NO2BIP-8 Errors
0011NO3BIP-8 Errors
0100NO4BIP-8 Errors
0101NO5BIP-8 Errors
0110NO6BIP-8 Errors
0111NO7BIP-8 Errors
1000NO8BIP-8 Errors
1001, 1010NO0Good Condition
1011YES0BIAE Indicator
1100 to 1111NO0Good Condition

Please see the Section Monitoring Error/Defect post to learn more about these defect and error conditions.

BDI – Section Monitoring – Backward Defect Indicator Bit Field

The purpose of the BDI bit-field is to permit the Source STE to alert the remote (far-end) Network Element that the local (near-end) Sink STE is declaring a service-affecting defect.  

This Source STE will set this bit-field to “0” or “1” depending upon whether the local (near-end) Sink STE is declaring a service-affecting defect condition (at the OTUk-layer), as I describe below.

0 – The Source STE will set the BDI bit-field to “0” if the near-end Sink STE is NOT declaring a service-affecting defect condition.

1 – The Source STE will set the BDI bit-field to “1” if the near-end Sink STE is currently declaring a service-affecting defect condition.

Please see the OTUk-BDI post to learn more about the BDI defect condition.

IAE – Section Monitoring Incoming Alignment Error Bit-Field

The Source STE will set this bit-field to “0” or “1” depending upon whether the upstream circuitry detects a frame-slip event within an ODU signal that we are ultimately mapping into this particular OTUk data stream (that this Source STE is transmitting downstream).

0 – Indicates that upstream circuitry is NOT detecting any frame-slip events (within the ODU signal we are mapping into this particular OTUk signal).   The Source STE will set the IAE bit-field to “0” (within its outbound OTU data-stream) to denote this good condition.

1 – Indicates that upstream circuitry is currently detecting a frame-slip event (within the ODU signal we are mapping into this particular OTUk signal).  The Source STE will set the IAE bit-field to “1” (within its outbound OTU data-stream) to denote this abnormal condition.

I present detailed information on the IAE bit-field within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!.

GCC0 – General Communication Channel # 0 – (2 bytes)

The GCC0 is a general communications channel for proprietary communication to the System Designer/Manufacturer.

This channel is similar to the DCC (Data Communication Channels) in SONET/SDH.

Please see the GCC0 post for more information about how the System Designer/Manufacturer can use this field.

OSMC – OTN Synchronization Messaging Channel  – 1 byte

The Network User can use the OSMC channel to transport SSM (Synchronization Status Messages) or PTP (Precision Time Protocol) messages throughout the OTN.

Please see the OSMC post for more information about how the System Designer/Manufacturer can use this field.

RES – Reserved (or Undefined) (1 byte)

OTUk Frame Repetition Rates and Bit Rates

Since all speeds (or types) of OTUk signals use the same frame size, the reason that (for example) an OTU2 runs at a faster bit rate than does an OTU1 is that the frame repetition rate for an OTU2 is higher (e.g., more rapid) than that for an OTU1.

Table 2 presents the OTUk frame period and bit rate for each type of the OTUk signal.

Table 2, Frame Periods and Bit-Rate for each kind of OTUk signal

OTUk Bit Rate and OTUk Frame Period

NOTES:

  1. This post has defined the Fully Compliant OTUk frames.   It does not address the functionally standardized OTUk frames (such as the OTUkV or OTUk-v).  Please see the posts for the OTUkV and OTUk-v frames for more information on these types of frames.
  2. This post does not discuss the new OTUCn types of OTN signals.  Please see the OTUCn post for more information on these higher-speed signals.

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

(DISCOUNT OFFERED for a Short Time ONLY!!)

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