How an OTN STE should declare and clear the dLOF (Loss of Frame) Defect Condition
The purpose of this post is to describe how an OTN STE (Section Terminating Equipment) will declare and clear the dLOF (Loss of Frame) Defect Condition.
Suppose you’re analyzing this topic from an ITU-T G.798 Atomic Function standpoint. In that case, I will tell you that the two atomic functions that are responsible for declaring and clearing the dLOF defect condition are:
- The OTSi/OTUk_A_Sk Function, and
- The OTSiG/OTUk_A_Sk Function.
Each of these atomic functions includes the dLOF Detection circuit. However, if you look closely at the OTSiG/OTUk_A_Sk function post, you will see that I do show that this particular dLOF Detection circuit is optional.
A Note About Terminology:
Throughout this blog post, I will refer to the entity containing the dLOF Detection circuit (and declares/clears the dLOF defect condition) as the Sink STE.
I’m using this terminology because it is technically correct, and it is much simpler to use that word than to use the words: OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions. However, I will use atomic function-related terms below in Table 1 (at the bottom of this post).
A Brief Review of the OTUk Frame Structure
In the OTUk Post, we mentioned that the OTUk frame consists of six framing alignment signal (FAS) bytes.
I present an illustration of the OTUk Frame Structure, with the FAS field highlighted below in Figure 1.
Figure 1, Illustration of the OTUk Frame Structure, with the FAS-Field Highlighted
Figure 1 shows that the FAS field consists of 3-byte fields (which I’ve labeled OA1) and another set of 3-byte fields, which I’ve labeled OA2.
The OA1 byte fields are each set to the fixed value of 0xF6. Similarly, the OA2 byte fields are each set to the specified value of 0x28.
Hence, this 6-byte FAS field will (for each OTUk frame) always have the fixed pattern of 0xF6, 0xF6, 0xF6, 0x28, 0x28, 0x28.
Since each OTUk frame is a 4080-byte column x 4-row structure, each frame contains 16,320 bytes. Therefore, we know that a Sink STE (or OTSi/OTUk_A_Sk function) will always receive this fixed pattern of six bytes (e.g., the FAS field) every 16,320 byte-periods.
Now that we are armed with this information, we can discuss how the Sink STE will declare and clear the dLOF defect.
The dLOF-Related State Machines
Anytime the Sink STE is powered-up and receives a stream of OTUk data, it will continually operate per two sets of state machines simultaneously.
- The OTUk-FAS OOF/IF Low-Level State Machine and
- The OTUk-dLOF Framing Alignment/Maintenance State Machine
These two state machines are hierarchical. In other words, one of these state machines operates at the low level (e.g., the OTUk-FAS OOF/IF Low-Level State Machine), and the other state machine (e.g., the OTUk-dLOF Framing Alignment/Maintenance State Machine) operates at a higher level (on top of the lower-level state machine).
I show the relationship between these two state machines below in Figure 2.
Figure 2, Illustration of the relationship between the two dLOF-Related State Machines
We will discuss each of these two state machines below.
The OTUk-FAS OOF/IF Low-Level State Machine
We will discuss the OTUk-FAS OOF/IF Low-Level State Machine first, and then we will discuss the OTUk-dLOF Framing Alignment/Maintenance State Machine later.
I present an illustration of the OTUk-FAS OOF/IF Low-Level State Machine Diagram below in Figure 3.
Figure 3, Illustration of the OTUk-FAS OOF/IF Low-Level State Machine Diagram
Figure 3 shows that the OTUk-FAS OOF/IF Low-Level State Machine consists of the following two states:
- The LL-OOF (Low-Level Out-of-Frame) State and
- The LL-IF (Low-Level In-Frame) State
From the moment the System Operator powers up the Sink STE circuitry and feeds an OTUk data stream to it (from the remote Source STE), it will continuously operate in one of these two states.
The Sink STE will (on occasion) need to transition from one state to another.
We will discuss each of these two states below.
The LL-OOF State
Whenever the System Operator first powers up a Sink STE and starts receiving an OTUk data stream (from the remote Source STE), it will operate in the LL-OOF state.
The Sink STE has not located the FAS-bytes (and the OTUk frame boundaries). Therefore, the Sink STE cannot “make sense” of this data.
While the Sink STE operates in this state, it will begin to parse through the incoming OTUk data stream. It will search for the occurrence of the FAS pattern within this data stream.
Earlier, I mentioned that this FAS-field is a 6-byte field that consists of the following fixed pattern: 0xF6, 0xF6, 0xF6, 0x28, 0x28, 0x28.
ITU-T G.798’s Requirement for Searching for the FAS field
ITU-T G.798 states that the Sink STE when operating the LL-OOF state, MUST look for a 4-byte subset of this 6-byte FAS pattern. Therefore, this 4-byte FAS pattern could be any one of the following patterns.
- 0xF6, 0xF6, 0xF6, 0x28
- 0xF6, 0xF6, 0x28, 0x28
- or 0xF6, ox28, ox28, ox28
Whenever the Sink STE has detected a set of four consecutive bytes that resembles a four-byte subset of the FAS field (as we’ve listed above), then the Sink STE will then wait an entire OTUk frame period (e.g., 16,320 bytes later) and it will check and see if that same FAS pattern is present then again.
If the Sink STE does not find the FAS pattern (one OTUk frame period later), then it will continue to parse through the incoming OTUk data stream and search for a 4-byte subset of the FAS pattern.
The Sink STE will also continue to operate in the LL-OOF state.
On the other hand, if the Sink STE does (indeed) find the FAS pattern (one OTUk frame period later), then the Sink STE will transition into the LL-IF state.
We will discuss the LL-IF State below.
The LL-IF State
Once the Sink STE enters the LL-IF state, it will continue to check for the presence of the FAS field at OTUk-frame intervals.
NOTE: Once the Sink STE enters the LL-IF state, ITU-T G.798 only requires it to check for a 3-byte subset of the FAS-field. Specifically, the standard states that the Sink STE must continue to check for the presence of the OA1, OA2, and OA2 (e.g., 0xF6, 0x28, 0x28) patterns at each OTUk frame interval.
As long as the Sink STE can consistently locate these FAS bytes at each OTUk frame interval, it will remain in the LL-IF state.
However, suppose the Sink STE were to lose synchronization with the FAS-field (of each incoming OTUk frame) such that it could not locate the FAS-field for five (5) consecutive OTUk frame periods. In that case, the Sink STE function will transition back into the LL-OOF state.
NOTE: The OTUk-FAS OOF/IF Low-Level State Machine algorithm tolerates bit errors. In other words, the presence of occasional bit errors is not enough to cause the Sink STE to transition from the LL-IF state back into the LL-OOF state.
Now that we have discussed the OTUk-FAS OOF/IF Low-Level State Machine, let’s move on and discuss the OTUk-dLOF Framing Alignment/Maintenance State Machine.
Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help Can Become an Expert on OTN!! Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!!
The OTUk-dLOF Framing Alignment/Maintenance State Machine
Figure 4 illustrates the OTUk-dLOF Framing Alignment/Maintenance State-Machine Diagram.
Figure 4, Illustration of the OTUk-dLOF Framing-Alignment/Maintenance State Machine Diagram (with State Machine Transition Criteria shown)
Hence, Figure 4 shows that the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram consists of the following four states.
- dLOF/LL-OOF State
- dLOF/LL-IF State
- In-Frame/LL-IF State
- In-Frame/LL-OOF State
The OTUk-dLOF Framing Alignment/Maintenance State Machine “rides” on top of the OTUk-FAS OOF/IF State Machine. Therefore, we can think of the OTUk-dLOF Framing Alignment/Maintenance State Machine as an extension of this Low-Level State Machine.
Hence, to illustrate that point, I have redrawn the OTUk-dLOF Framing Alignment/Maintenance State Machine diagram (that I show in Figure 4) to also show the underlying state changes within the OTUk-FAS OOF/IF State Machine. I show this redrawn figure below in Figure 5.
Figure 5, Illustration of the OTUk-dLOF Framing-Alignment/Maintenance State Machine Diagram (with OTUk-FAS OOF/IF State Machine state change information shown).
The Sink STE will transition through each of the four states (within the OTUk-dLOF Framing Alignment/Maintenance State Machine) as it also transitions between the two states within the OTUk-FAS OOF/IF Low-Level State Machine.
Whenever the System-Operator powers up the Sink STE and starts receiving an OTUk data stream, it will continually operate in one of these four states. On occasion, the Sink STE will transition from one state to another. As it does, it will either declare or clear the dLOF defect, as shown in Figures 4 and 5.
We will now “walk” through the OTUk-dLOF Framing Alignment/Maintenance State Machine.
The dLOF/LL-OOF State
Whenever the System Operator first powers up the Sink STE and is just starting to receive an OTUk data stream, it will initially operate in the dLOF/LL-OOF State, as I show below in Figure 6.
Figure 6, Illustration of the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram with the dLOF/LL-OOF State Highlighted.
In the expression dLOF/LL-OOF, the reader should already know where the LL-OOF portion (of this state’s name) originates.
When we were discussing the OTUk-FAS OOF/IF Low-Level State Machine (up above), we stated that whenever we power up the Sink STE, it is just starting to receive an OTUk data stream. It will be operating in the LL-OOF state.
What does it mean to be in the dLOF/LL-OOF State?
The dLOF portion (of the expression dLOF/LL-OOF) means that the Sink STE is currently declaring the dLOF defect condition while operating in this particular state.
In summary, whenever the Sink STE is operating in the dLOF/LL-OOF state (within the OTUk-dLOF Framing Alignment/Maintenance State Machine), then we can state the following as fact:
- The Sink STE is operating in the LL-OOF state (within the lower-level state machine, as we discussed earlier), and
- The Sink STE also declares the dLOF defect condition (as the name of this state suggests).
Whenever the Sink STE operates in this state, it has NOT located the FAS fields nor the boundaries of any OTUk frames within the incoming OTUk data stream. As far as the Sink STE is concerned, it receives nonsensical data.
While the Sink STE is operating in this state, it will parse through the incoming OTUk data stream and look for the four-byte subset of the FAS field (as we discussed earlier).
Whenever the Sink STE has detected a set of four consecutive bytes that resembles a four-byte subset of the FAS field, the Sink STE will then wait an entire OTUk frame period (e.g., 16,320 bytes) later, and it will check and see if that same FAS pattern is again present, within the OTUk data-stream.
If the Sink STE Fails to Find the FAS field
If the Sink STE does not find the FAS pattern (one OTUk frame period later), it will continue to parse through (and search) the incoming OTUk data stream for that 4-byte subset of the FAS pattern.
It will also remain in the dLOF/LL-OOF state.
If the Sink STE Successfully Locates the FAS field
On the other hand, if the Sink STE does (indeed) find the FAS pattern (one OTUk frame period, later), then the Sink STE will transition from the LL-OOF state to the LL-IF state within the OTUk-FAS OOF/IF State Machine.
As the Sink STE makes this transition within the low-level state machine, it will also transition from the dLOF/LL-OOF to the dLOF/LL-IF state within the OTUk-dLOF Framing Alignment/Maintenance State Machine.
The dLOF/LL-IF State
I illustrate the OTUk-dLOF Frame Alignment/Maintenance State-Machine diagram with the dLOF/LL-IF State highlighted below in Figure 7.
Figure 7, Illustration of the OTUk-dLOF Frame Alignment/Maintenance State-Machine Diagram, with the dLOF/LL-IF State highlighted.
Whenever the Sink STE has transitioned into the dLOF/LL-IF state, we can state that the Sink STE has located (what appears to be) the FAS fields within the incoming OTUk data stream.
NOTES:
- We refer to this state as the dLOF/LL-IF state because the Sink STE is still declaring the dLOF defect condition (just as it was while operating in the dLOF/LL-OOF state). However, the “LL-IF” portion of the state’s name (e.g., dLOF/LL-IF) reflects the fact that the Sink STE has transitioned into the LL-IF (Low-Level In-Frame) state within the lower-level state machine.
- I realize that calling this state the dLOF (Loss-of-Frame)/LL-IF (In-Frame) state is a bit of an oxymoron. In this case, the Sink STE is in-frame because it has located the FAS fields. However, it is still declaring the dLOF defect condition.
While the Sink STE is operating in the dLOF/LL-IF state, it will perform the task of continuing to confirm whether or not it has located the FAS bytes (within the incoming OTUk data stream).
Two possible things can happen from here whenever the Sink STE is operating in this state.
- It can eventually transition (or advance) into the “In-Frame/LL-IF” state, or
- It can transition (or regress) back into the dLOF/LL-OOF state.
We will discuss each of these possible events below.
Advancing to the In-Frame/LL-IF State
ITU-T G.798 requires that the Sink STE remain in the LL-IF state (at the low level) for at least 3ms before it can transition into the next state.
If the Sink STE remains in the dLOF/LL-IF state for at least 3ms (and continues to locate the FAS bytes accurately), then it will do all of the following:
- It will transition into the “In-Frame/LL-IF” state within the OTUk-dLOF Frame Alignment/Maintenance State Machine, and
- It will clear the dLOF defect condition (e;g., dLOF ⇒ 0).
I will discuss the In-Frame/LL-IF State later in this blog post.
Regressing to the dLOF/LL-OOF State
On the other hand, if the Sink STE (while operating in the dLOF/LL-IF state) were to lose synchronization with the FAS byte-fields, it can no longer locate the FAS bytes for at least five (5) consecutive OTUk frame periods. The Sink STE will transition back into the dLOF/LL-OOF state.
This means that the Sink STE will transition from the LL-IF state back into the LL-OOF state (within the Lower-Level State Machine).
Additionally, the Sink STE will continue to declare the dLOF defect condition.
The In-Frame/LL-IF State
Once the Sink STE has reached the In-Frame/LL-IF state, we can say that it operates in the NORMAL (or intended) state. We expect the Sink STE to spend most of its operating lifetime in this state.
I illustrate the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram with the In-Frame/LL-IF State highlighted below in Figure 8.
Figure 8, Illustration of the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram, with the In-Frame/LL-IF State highlighted.
Whenever the Sink STE is operating in the In-Frame/LL-IF state, it can now locate the boundaries of each incoming OTUk frame. This also means that the Sink STE should be ready to start making sense of the data within the incoming OTUk data stream. It can now begin to evaluate the OTUk data stream for other defects or error conditions.
Of course, the Sink STE is telling the whole world this fact by clearing the dLOF defect condition.
Whenever the Sink STE operates in the In-Frame/LL-IF state, it is pretty tolerant of the occurrences of bit errors. In other words, if the Sink STE were to receive an OTUk frame, such that there was (for example) a single bit-error or even a burst of errors that affects one set of FAS bytes, the Sink STE would remain in the “In-Frame/LL-IF” state.
On the other hand, if the Sink STE were to lose synchronization with the incoming OTUk data stream, such that it cannot locate valid FAS bytes for five consecutive OTUk frames, then the Sink STE will transition from the LL-IF state into the LL-OOF state (within the Low-Level State Machine).
Consequently, the Sink STE will transition from the In-Frame/LL-IF state into the In-Frame/LL-OOF state.
We discuss the In-Frame/LL-OOF State below.
The In-Frame/LL-OOF State
I illustrate the OTUk-dLOF Frame Alignment/Maintenance State Machine diagram with the In-Frame/LL-OOF State highlighted below in Figure 9.
Figure 9, Illustration of the OTUk-dLOF Frame Alignment/Maintenance State Machine diagram, with the In-Frame/LL-OOF State highlighted.
If the Sink STE transitions into the In-Frame/LL-OOF state, then it means the following things:
- The Sink STE has transitioned from the LL-IF state into the LL-OOF state within the OTUk-FAS OOF/IF Low-Level State Machine.
- The Sink STE is still NOT declaring the dLOF (Loss of Frame) defect condition (e.g., dLOF = 0).
NOTE: We refer to this state as the “In-Frame/LL-OOF” state because the Sink STE is still NOT declaring the dLOF defect condition (just as it was NOT while operating in the In-Frame/LL-IF state).
However, the LL-OOF portion of the state’s name (e.g., In-Frame/LL-OOF) reflects that the Sink STE has transitioned into the LL-OOF state (within the Low-Level State Machine).
Only one of two possible things will happen whenever the Sink STE enters the In-Frame/LL-OOF state.
- The Sink STE will eventually re-acquire synchronization with the incoming FAS frames, and it will advance back into the In-Frame/LL-OOF state, or
- The Sink STE does not re-acquire synchronization with the incoming FAS frames and eventually regresses into the dLOF/LL-OOF state.
We will briefly discuss each of these two possible events below.
Advancing Back into the In-Frame/LL-IF State
If the Sink STE can locate and re-acquire the 4-byte subset of the FAS-field, then it will transition back into the In-Frame/LL-IF state. In this case, the Sink STE will continue to clear the dLOF defect condition (dLOF = 0).
Regressing to the dLOF/LL-OOF State
ITU-T G.798 requires that the Sink STE reside in the In-Frame/LL-OOF state for 3ms before it can transition into the dLOF/LL-OOF state and declare the dLOF defect condition.
This means that if the Sink STE cannot locate the FAS field (for 3ms after transitioning into the In-Frame/LL-OOF state), it will transition into the dLOF/LL-OOF state.
Whenever the Sink STE transitions into the dLOF/LL-OOF state, it will declare the dLOF defect condition (dLOF = 1).
NOTE: If the Sink STE enters the dLOF/LL-OOF state from the In-Frame/LL-IF (by way of the In-Frame/LL-OOF state), it will operate with the exact frame-start location that it had when it was running in the In-Frame/LL-IF state.
In other words, the Sink STE will continue to look for the FAS-field in the exact location (e.g., N x 16,320-byte periods later, where N is an integer) in which it was locating the FAS-field while it was operating normally in the In-Frame/LL-IF state.
In Summary
ITU-T G.798 requires that the Sink STE be able to locate the FAS field and remain in the LL-IF state for at least 3ms before it can clear the dLOF defect condition (e.g., dLOF ⇒ CLEARED).
Further, ITU-T G.798 also requires that the Sink STE NOT be able to locate the FAS field and remain in this condition (e.g., the LL-OOF state) for at least 3ms before it can declare the dLOF defect condition (e.g., dLOF ⇒ DECLARED).
ITU-T G.798 imposes these 3ms persistency requirements (for declaring and clearing the dLOF defect) to prevent intermittent transitions between the LL-OOF and LL-IF states from causing rapid changes (or chattering) in the dLOF state.
Table 1 presents a summary of the dLOF Defect Condition and how its State affects an OTN STE’s operation when handling an OTUk signal over a Single Lane (e.g., the OTSi/OTUk_A_Sk function).
Table 1, Summary of the dLOF Defect Condition and How its State affects an OTN STE’s Operation when handling an OTUk signal over a Single Lane (e.g., the OTSi/OTUk_A_Sk function).
| Item | Description |
|---|---|
| Meaning of dLOF | The Sink STE (or OTSi/OTUk_A_Sk function) will declare the dLOF defect if it is not able to reliably locate the FAS field (and in-turn, the boundaries) of the incoming OTUk frames within the incoming data-stream. In short, if the Sink STE (OTSi/OTUk_A_Sk function) is declaring the dLOF defect condition, then it is NOT able to make any sense of the data within its OTUk data-stream. The Sink STE (and downstream circuitry) cannot perform any useful functions on this data-stream until it clears this defect. |
| Requirements to declare dLOF | The Sink STE (or OTSi/OTUk_A_Sk function) will declare the dLOF defect if it loses synchronization with the incoming FAS fields (within the incoming OTUk datastream) for at least 3ms. Additionally, the Sink STE (or OTSi/OTUk_A_Sk function) must not be declaring the dAIS (OTUk-AIS) defect condition. |
| Requirements to clear dLOF | The Sink STE (or OTSi/OTUk_A_Sk function) will clear the dLOF defect if it is able to maintain synchronization with the incoming FAS fields (within the incoming OTUk data-stream) for at least 3ms. |
| Any defects that can suppress the dLOF defect? | Yes, the Sink STE (or OTSi/OTUk_A_Sk function) cannot declare the dLOF defect, if it is currently declaring either of the following defect. - dAIS (OTUk-AIS), - dLOS-P or - TSF (Trail Signal Failure) - if upstream (optical circuitry) asserts the AI_TSF input. NOTE: Please see the blog post on the OTSi/OTUk_A_Sk function for more information about the AI_TSF signal. |
| Impact of declaring the dLOF defect on other defect conditions within the Sink STE (or OTSi/OTUk_A_Sk or OTUk_TT_Sk functions) | The Sink STE (or OTSi/OTUk_A_Sk and OTUk_TT_Sk functions) should NOT declare any of the following defects, whenever it is declaring the dLOF defect condition. - dLOM - dTIM - dDEG NOTE: Please see the blog post for the OTUk_TT_Sk Atomic Function for more information about the dTIM, dDEG defects and why the dLOF defect will affect these defect conditions. |
| Impact of declaring the dLOF defect on Downstream Circuitry (e.g., the OTUk_TT_Sk function). | The Sink STE (or OTSi/OTUk_A_Sk function) should automatically assert the CI_SSF (Server Signal Fail) signals whenever it is declaring the dLOF defect condition. This indication will notify the downstream OTUk_TT_Sk function that there is a service-affecting defect upstream. NOTE: Please see the blog post for the OTSi/OTUk_A_Sk atomic function for more information about the CI_SSF signal. |
| Impact of declaring the dLOF defect to Performance Monitoring. | The Sink STE (or OTSi/OTUk_A_Sk function) must inhibit Performance Monitor tallying of the pFECcorrErr (Number of Symbol Errors Corrected by FEC) for the duration that it is declaring the dLOF defect condition. NOTE: Whenever the Sink STE or OTSi/OTUk_A_Sk function declares the dLOF defect condition, it will also affect Performance Monitoring activities within the OTUk_TT_Sk atomic function. |
Clueless about OTN? We Can Help!! Click on the Banner Below to Learn More!!
Discounts Available for a Short Time!!
Click on the Image Below to see More OTN-Related Blog Posts.
OTN Related Topics within this Blog
