Sierra Hardware Design – All Things Electrical Design Blog
This post provides a comprehensive review and video training of the OTU frame and its overhead fields.
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.
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.
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.
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).
In the OTUk Post, I stated that the OTUk frame consists of a single multi-frame alignment signal (MFAS) byte.
I show a drawing of the OTUk Frame Structure, with the MFAS-field highlighted below in Figure 1.
Figure 1, Drawing of the OTUk Frame Structure, with the MFAS-Field Highlighted
In the OTUk blog post, we mentioned that the Source STE Terminal would generate and transmit OTUk traffic in the form of back-to-back multi-frames. Each of these multi-frames consists of 256 consecutive OTUk frames.
The 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.
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 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.
There are two reasons for this.
The FAS field consists of a defined/fixed pattern. In other words, the FAS fields never change in value (except for the 3rd OA2 byte – for OTL4.4 and OTL4.10 applications ONLY).
The Sink STE can locate the FAS field by only looking for these fixed patterns. On the other hand, the MFAS byte value changes with every OTUk frame.
Additionally, we NEVER scramble the FAS field. However, we do scramble the MFAS byte.
I show a drawing of an OTUk frame below that identifies the portions of the OTUk frame that the Remote Source STE has scrambled before transmitting this OTUk frame to the Near-end Sink STE.
Figure 2, Drawing of an OTUk Frame – Showing the portions of the OTUk Frame that we scrambled.
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.
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.
These two state machines are hierarchical. In other words, one of these state machines operates at the low level (e.g., the OTUk-MFAS OOM/IM Low-Level State Machine), and the other state machine operates at a higher layer (on top of the low-level state machine).
I show the relationship between these two-state machines below in Figure 3.
Figure 3, Illustration of the relationship between the two dLOM-related State Machines
We will discuss these two state machines below.
We will discuss the OTUk-MFAS OOM/IM Low-Level State Machine first, and then we will discuss the OTUk-dLOM Framing Alignment/Maintenance State Machine later.
I show a drawing of the OTUk-MFAS OOM/IM Low-Level State Machine Diagram below in Figure 4.
Figure 4, Drawing of the OTUk-MFAS OOM/IM Low-Level State Machine Diagram
Figure 4 shows that the OTUk-MFAS OOM/IM Low-Level State Machine contains the following two states.
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.
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.
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.
I show a drawing of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram below in Figure 5.
Figure 5, Drawing of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram
Hence, Figure 5 shows that the OTUk-dLOM Framing Alignment/Maintenance State Machine diagram consists of four states.
The OTUk-dLOM Framing Alignment/Maintenance State Machine rides on top of the OTUk-MFAS OOM/IM State Machine. Therefore, we can think of the OTUk-dLOM Framing Alignment/Maintenance State Machine as an extension of this Low-Level State Machine.
Hence, to illustrate that point, I have redrawn the OTUk-dLOM Framing Alignment/Maintenance State Machine diagram (that I show in Figure 5) to show the conditions that cause us to transition from one state to the next within the OTUk-MFAS OOF/IF State Machine. I show this redrawn figure below in Figure 6.
Figure 6, Illustration of the OTUk-dLOM Framing-Alignment/Maintenance State Machine Diagram (with OTUk-MFAS OOF/IF State Machine state change information shown).
The Sink STE will transition through each of the four states (within the OTUk-dLOM Framing Alignment/Maintenance State Machine) as it also transitions through the two states within the OTUk-MFAS OOM/IM Low-Level State Machine.
Whenever the System Operator powers up the Sink STE and starts receiving an OTUk data stream (once it has cleared the dLOF defect), it will continually operate in one of these four states. On occasion, the Sink STE will transition from one state to another. As it does this, it will declare or clear the dLOM defect, as shown in Figures 5 and 6.
We will now walk through the OTUk-dLOM Framing Alignment/Maintenace State Machine.
When the System Operator first powers up the Sink STE and is just starting to receive an OTUk data stream, the Sink STE will first clear the dLOF defect condition. Afterward, it will operate in the dLOM/LL-OOM State, as shown below in Figure 7.
Figure 7, Illustration of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram with the dLOM/LL-OOM State Highlighted.
In the expression dLOM/LL-OOM, the reader should already know where the LL-OOM portion (of this state’s name) originates.
When we were discussing the OTUk-MFAS OOF/IF Low-Level State Machine (up above), we stated that whenever we first power up the Sink STE and it is just starting to receive an OTUk data-stream (and has cleared the dLOF defect condition), it will be operating in the LL-OOM state.
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:
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 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.
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.
I illustrate the OTUk-dLOM Frame Alignment/Maintenance State-Machine diagram with the dLOM/LL-IM State highlighted below in Figure 8.
Figure 8, Illustration of the OTUk-dLOM Frame Alignment/Maintenance State-Machine Diagram, with the dLOM/LL-IM State highlighted
Whenever the Sink STE has transitioned into the dLOM/LL-IM State, we can state that the Sink STE has located (what appears to be) the MFAS-byte-field within the incoming OTUk data stream.
NOTES:
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.
We will discuss each of these possible events below.
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:
I will discuss the In-Multi-Frame/LL-IM State later in this blog post.
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.
Once the Sink STE has reached the In-Multi-frame/LL-IM state, we can say that it operates in the NORMAL (or intended) state. We expect the Sink STE to spend most of its operating lifetime in this state.
I show a drawing of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram, with the In-Multi-frame/LL-IM State highlighted below in Figure 9.
Figure 9, Illustration of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram, with the In-Multi-Frame/LL-IM State highlighted.
Whenever the Sink STE operates in the In-Multi-frame/LL-IM state, it can locate the MFAS byte-fields within each incoming OTUk frame.
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.
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.
I show a drawing of the OTUk-dLOM Frame Alignment/Maintenance State Machine diagram with the In-Multi-frame/LL-OOM State highlighted below in Figure 10.
Figure 10, Drawing of the OTUk-dLOM Multi Frame Alignment/Maintenance State Machine diagram, with the In-Multiframe/LL-OOM State highlighted.
If the Sink STE transitions into the In-Multi-frame/LL-OOM state, this means the following things.
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.
We will briefly discuss these two possible events below.
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).
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).
ITU-T G.798 requires that the Sink STE be able to locate the MFAS byte and consistently remain in the LL-IM state for at least 3ms before it can clear the dLOM defect condition (e.g., dLOM ⇒ CLEARED).
Further, ITU-T G.798 also requires that the Sink STE NOT be able to locate the MFAS byte and remain in this condition (e.g., the LL-OOM state) for at least 3ms before it can declare the dLOM defect condition (e.g., dLOM ⇒ DECLARED).
ITU-T G.798 imposes these 3ms persistency requirements (for declaring and clearing the dLOM defect) to prevent intermittent transitions between the LL-OOM and LL-IM states from causing sporadic changes (or chattering) in the dLOM state.
Table 1 summarizes the dLOM Defect Condition and how its State affects an OTN STE’s Operation.
Table 1, Summary of the dLOM Defect Condition and How its State affects an OTN STE’s Operation
| Item | Description |
|---|---|
| Meaning of the dLOM Defect Condition | The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) will declare the dLOM defect, if it has cleared the dAIS and the dLOF defect conditions, but it is not able to reliably locate the MFAS bytes and OTUk Multi-frame boundaries, within the incoming OTUk data-stream. In other words, the Sink STE will declare the dLOM defect if it is able to find the FAS fields (within each incoming OTUk frame) but it still not able to reliably locate the MFAS bytes and align itself with each incoming 256-frame OTUk multi-frame. |
| Requirements to declare dLOM | The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) will declare the dLOM defect if it loses synchronization with the incoming MFAS bytes (and their increment value) for at least 3ms. |
| Requirements to clear dLOM | The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) will clear the dLOM defect if it is able to maintain synchronization with the incoming (and incrementing) MFAS byte-fields (within the OTUk data-stream) for at least 3ms. |
| Any defects that will suppress the dLOM defect? | Yes, the dAIS (OTUk-AIS) and dLOF defects. Or if upstream circuitry is declaring the Trail Signal Fail defect condition. If the Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) declares any of these defect conditions, then it cannot declare the dLOM defect. |
| Impact of declaring the dLOF defect on other defect conditions within the Sink STE | The Sink STE (or OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic function) should not declare any of the following defects, whenever it is also declaring the dLOM defect. - dTIM, and - dDEG |
| Impact of declaring the dLOM defect to Performance Monitoring. | None |
This post defines and describes the OTU (Optical Transport Unit) Frame that is used in OTN (Optical Transport Networks).
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.
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.
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.
Figure 1 illustrates the format for the standard ITU-T G.709-compliant OTU Frame.
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.
Let’s talk about the various fields within an OTUk frame.
Some of the fields in the OTUk frame have the following labels.
I will briefly define each of these bytes below.
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.
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.
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.
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.
The remaining OTUk OH fields consist of the following three fields for a total of seven (7) bytes:
We will briefly describe each of these fields below.
Figure 2 shows the byte format for the Section Monitoring or SM Field.
Figure 2, Byte-Format of the SM (Section Monitoring) Field
This figure shows that the SM Field consists of the following three bytes:
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.
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.
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.
Figure 3 presents the bit format for the Section Monitoring Byte (not to be confused with the 3-byte SM field).
Figure 3, Bit Format of the Section Monitoring Byte
This figure shows that the SM Byte consists of the following bit fields:
We will briefly describe each of these bit-fields below.
The purpose of the BEI/BIAE nibble-field is two-fold.
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-Value | Sink STE declaring the dIAE Defect? | Number of SM-BIP-8 Errors Detected | Comments |
|---|---|---|---|
| 0000 | NO | 0 | Good Condition |
| 0001 | NO | 1 | BIP-8 Error |
| 0010 | NO | 2 | BIP-8 Errors |
| 0011 | NO | 3 | BIP-8 Errors |
| 0100 | NO | 4 | BIP-8 Errors |
| 0101 | NO | 5 | BIP-8 Errors |
| 0110 | NO | 6 | BIP-8 Errors |
| 0111 | NO | 7 | BIP-8 Errors |
| 1000 | NO | 8 | BIP-8 Errors |
| 1001, 1010 | NO | 0 | Good Condition |
| 1011 | YES | 0 | BIAE Indicator |
| 1100 to 1111 | NO | 0 | Good Condition |
Please see the Section Monitoring Error/Defect post to learn more about these defect and error conditions.
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.
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!!.
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.
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.
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
NOTES:
