This blog post contains a video that serves as the 2nd of two videos that describe the functionality of the OTL3.4 Sink Terminal (aka the OTSiG/OTUk_A_Sk Atomic Function). This video focuses on Skew Compensation and ultimately combining the 4 OTL3.4 Lanes back into a Composite OTU3 signal.
OTN – Lesson 6 – Converting OTL3.4 Signals back into a Composite OTU3 Signal – Video 2 of 2
This blog post contains the second (of 2) videos that describes how we take an OTL3.4 Interface (or set of signals) and convert these signals back into a single (composite) OTU3 signal.
This particular video completes the discussion of the OTSiG/OTUk_A_Sk Atomic Function (which, again, is a fancy word for OTL3.4 Sink Terminal).
NOTE: We formally introduce the OTSiG/OTUk_A_Sk Atomic Function in Lesson 9.
This video discusses how the Lane Marker and Delay Processing Block (within the OTSiG/OTUk_A_Sk Function) evaluates all of the data and metrics coming from the four Lane Frame Alignment, Lane Alignment Recovery, and Elastic Store blocks and:
Measures and performs Skew Compensation,
Declares the dLOL (Loss of Lane Alignment) Defect Condition and
Routes the de-skewed data to the 16-Byte Block MUX – which combines each of the four OTL3.4 lane signals back into a composite OTU3 signal.
This blog post contains a Video that serves as a first (of two) videos that discusses the functionality of the OTL3.4 Sink Terminal (aka OTSiG/OTUk_A_Sk Function). This video focuses on the dLOFLANE and dLOR defects.
OTN – Lesson 6 – Converting OTL3.4 Signals back into a Composite OTU3 Signal – Video 1 of 2
This blog post contains the first (of 2) videos that describe how we take an OTL3.4 Interface (or set of signals) and convert these signals back into a single (composite) OTU3 signal.
NOTE: We don’t mention OTSiG/OTUk_A_Sk Atomic Function until Lesson 9. We call this function the OTL3.4 Sink Terminal.
This video discussed how the OTSiG/OTUk_A_Sk Function accepts electrical lane signals from an Optical Module (in the OTL3.4 format) and processes these signals by:
Checking to see if we should declare/clear the dLOS-P (Loss of Signal – Path) Defect condition with these Electrical Lane signals, and
Checking to see if we should declare/clear the dLOFLANE (Loss of Frame – of Logical Lane) defect condition.
Finally, we will discuss how the OTSiG/OTUk_A_Sk function checks each incoming OTL3.4 lane signal to see if it should declare the dLOR (Loss of Recovery) defect condition.
This post presents both information and video training on how we take an OTL4.4 signal and recombine it back into a composite OTU4 signal. This post serves as the third of 3 videos for the OTL4.4 Sink Terminal.
In this video we focus on the Lane Alignment Recovery Block and Skew Compensation.
OTN – Lesson 7 – Converting OTL4.4 Signals back into a Composite OTU4 Signal – Video 3
This blog post presents the 3rd (of a set of 3 videos) that discusses how we convert an OTL4.4 Interface (or group of signals) back into a single (composite) OTU4 signal.
In particular, this video discusses the following:
It outlines how the OTSiG/OTUk_A_Sk function declares and clears the dLOR (Loss of Recovery) defect condition, for each of the 20 Logical Lanes, by walking through the Lane Alignment Recovery Block – LOR/OOR/IR State Machine diagram.
This video also discusses Lane-to-Lane Skew Compensation, and
How the OTSiG/OTUk_A_Sk function declares or clears the dLOL defect condition, and
How the OTSiG/OTUk_A_Sk function combines the 20 Logical Lanes back into a single (composite) OTU4 signal.
This post presents both information and video training on how we take an OTL4.4 signal and recombine it back into a composite OTU4 signal. This post serves as the second of 3 videos for the OTL4.4 Sink Terminal.
OTN – Lesson 7 – Converting OTL4.4 Signals back into a Composite OTU4 Signal – Video 2 of 3
This blog post contains the 2nd of 3 videos that discusses how we convert an OTL4.4 interface (or set of signals) back into a single (composite) OTU4 signal.
This video discusses how we declare and clear the dLOFLANE (Loss of Frame of Logical Lane) defect condition (by walking through the OTL4.20 dLOFLANE/In-Frame State Machine.
This video also starts the discussion of how we declare the dLOR (Loss of Recovery) defect for each of the 20 Logical Lanes.
This post presents both information and video training on how we take an OTL4.4 signal and recombine it back into a composite OTU4 signal. This post serves as the first of 3 videos for the OTL4.4 Sink Terminal.
This video introduces the OTL4.4 Sink Terminal (and the OTSiG/OTUk_A_Sk Atomic Function) and focuses on the Lane Frame Alignment Block and the dLOFLANE/In-Frame State Machine Diagram.
OTN – Lesson 7 – Converting OTL4.4 Signals back into a Composite OTU4 Signal – Video 1 of 3
This blog post contains the first (of 3) videos that describes how we take an OTL4.4 Interface (or set of signals) and converts these signals back into a single (composite) OTU4 signal.
This video introduces the OTSiG/OTUk_A_Sk Atomic Function (a fancy word for OTL4.4 Sink Terminal).
This video discusses how the OTSiG/OTUk_A_Sk Function accepts electrical lane signals from an Optical Module (in the OTL4.4 format) and processes these signals by:
Checking to see if we should declare/clear the dLOS-P (Loss of Signal – Path) Defect condition with these Electrical Lane signals, and
De-Multiplexing these signals into the 20 Logical Lane signal.
In this video, we presume that some OTUk-Layer circuitry is declaring a certain defect condition. We then determine how OTU (and in some cases) ODU-layer circuitry is expected to respond.
OTN – Lesson 9 – Video 11 – OTU Layer Defect Scenarios
This blog post presents a video that discusses the various defects that OTN equipment can declare at the OTU Layer. Additionally, this video will describe how OTU Layer circuitry should respond to and handle these defect conditions.
This video will state whether OTU Layer circuitry should:
Transmit the SM-BDI Indicator upstream, or
Transmit the ODU-AIS Maintenance Signal downstream,
Increment Certain Performance Monitoring parameters, or
Halt Incrementing Certain Performance Monitoring parameters.
In response to each type of defect that OTU Layer circuitry can declare.
This video covers both Single-Lane (e.g., OTSi/OTUk_A_Sk) and Multi-Lane (e.g., OTSiG/OTUk_A_Sk) applications.
This post presents the 5th of 11 Videos that covers training on Performance Monitoring at the OTU Layer. This post focuses on the Sink Direction OTU-Layer Atomic Functions.
OTN – Lesson 9 – Video 5 – OTU Layer Sink Direction Circuitry/Functionality – Part 3
This blog post contains another video that focuses on (and wraps up our discussion on) the OTSiG/OTUk_A_Sk Atomic Function.
This Video serves as Part 3 within our Sink (or Receive) Direction Analysis of OTU-Layer Atomic functions. This Video is also the 5th of 11 videos within Lesson 9.
We start this Video by reviewing the complete list of defects that the OTSiG/OTUk_A_Sk function declares and clears. Afterward, I will introduce you to the following:
The concept/purpose of Consequent Equations
A Review (and interpretation) of Consequent Equations for the OTSiG/OTUk_A_Sk Atomic Function.
Introduction to Defect Correlation
A Review of the Defect Correlation Equations for the OTSiG/OTUk_A_Sk Atomic Function.
A Review of the Performance Monitoring Equations for the OTSiG/OTUk_A_Sk Atomic Function.
A Final Summary of the OTSiG/OTUk_A_Sk Atomic Function.
This post presents the 4th of 11 Videos that covers training on Performance Monitoring at the OTU-Layer. This post focuses on the Sink Direction OTU-Layer Atomic Functions.
OTN – Lesson 9 – Video 4 – OTU Layer Sink Direction Circuitry/Functionality – Part 2
This blog post contains a video that continues our discussion of the Sink (or Receive) Direction OTU-Layer Atomic Functions (circuitry).
This Video serves as Part 2 of the Sink Direction/OTU-Layer Training Videos. It is also the 4th out of 11 Videos within Lesson 9.
This Video discusses the following topics (still within the OTSiG/OTUk_A_Sk Atomic Function).
FEC Decoding, and
The Multi-Frame Alignment and dLOM (Loss of Multi-Frame) defect block.
In this case, we describe how the OTSiG/OTUk_A_Sk function declares and clears the dLOM (Loss of Multi-Frame) defect condition by walking through and discussing the dLOM/In-Multi-Frame Alignment State Machine diagram.
I wrap up this Video by discussing why clearing the dLOM defect condition is essential for handling/processing OTN signals.
This post presents the 3rd of 11 Videos that covers training on Performance Monitoring at the OTU-Layer. This post focuses on the Sink-Direction OTU-Layer Atomic Functions.
OTN – Lesson 9 – Video 3 – OTU Layer Sink Direction Circuitry/Functionality – Part 1
This blog post contains a video that begins our discussion of the Sink (Receive) Direction OTU-Layer Atomic Functions.
This Video starts with a brief re-cap of a portion of the OTSiG/OTUk_A_Sk Atomic Function (aka OTL4.4 Sink Terminal).
In this case, I specifically call out and identify portions of this Atomic Function that we discussed in Lessons 6 or 7 and those portions that we did not.
In Lesson 7, we discussed that part of the OTSiG/OTUk_A_Sk function handled OTL4.4 or OTL4.20 logical lane signals.
Lesson 6 also discussed part of the OTSiG/OTUk_A_Sk function that handled the OTL3.4 lane signal.
I also show you the differences between the OTU3 version of the OTSiG/OTUk_A_Sk function and that for OTU4.
Late in this Video, we start to discuss that portion of the OTSiG/OTUk_A_Sk function that handles the combined (composite) OTU3/OTU4 signal. This portion includes
Discussing how the OTSiG/OTUk_A_Sk function declares and clears the dLOF defect by reviewing the Frame Alignment Block – dLOF/In-Frame State Machine Diagram, and
This post briefly defines and describes Consequent Equations that ITU-T G.798 uses for OTN Applications.
What are Consequent Equations, and How Should You Interpret Them?
The purpose of this blog post is two-fold.
To describe the concept of Consequent Equations and
To discuss how we can use and interpret these Consequent Equations.
Introduction
Many ITU Standards (such as ITU-T G.798 for OTN Applications) will discuss many aspects of defects. These standards will define defects such as dAIS (Alarm Indication Signal) and dLOM (the Loss of Multi-frame).
These same standards will also define the criteria that an OTN Network Element (be it an STE or PTE) should use to declare or clear a given defect.
For example, ITU-T G.798 specifies all of the following defects that an OTN STE can declare and clear.
How should an STE/PTE Respond Whenever it Declares a Defect?
However, what else should an STE do whenever it declares (for example) the dLOF defect condition?
Does this STE have a responsibility to notify other STEs of this defect?
Similarly, what else should a PTE do whenever it declares (for example) the dTIM (ODUk-TIM) defect condition?
Again, does this PTE have a responsibility to notify other nearby PTEs of this defect?
The short answer to both of these questions is, “Yes, for those specific defects that I mentioned, they do have a responsibility to notify upstream and downstream equipment of the occurrence of those defect conditions.”
However, to confuse things, the PTE/STE must notify upstream and downstream PTE/STE whenever some defects occur, but not others.
How Do We Sort out This Confusion?
The Answer: Consequent Equations.
Let’s assume that a certain STE is declaring the dLOF Defect condition, as shown below in Figure 1.
Figure 1, Illustration of the STE (e.g., the OTSi/OTUk-a_A_Sk Atomic Function) declares the dLOF defect condition.
What happens next?
At this point, let’s write down the Consequent Equation that pertains to this STE (or the OTSi/OTUk-a_A_Sk function in this case):
AI_TSF-P is the current (logical) state of the AI_TSF-P input pin (to the OTSi/OTUk-a_A_Sk atomic function).
This consequent equation states that the STE (or OTSi/OTUk-a_A_Sk function) will assert its CI_SSF output pin anytime it declares any of the following defect conditions:
This consequent equation also states that the STE (the OTSi/OTUk-a_A_Sk function) will assert the CI_SSF output pin anytime the upstream atomic function asserts the AI_TSF input to this function.
NOTE: Please see the OTSi/OTUk_A_Sk Function Post for more information about this particular Atomic Function.
So What Does All of This Mean?
In Figure 2, I show the OTSi/OTUk_A_Sk function now asserting its CI_SSF output pin because it is currently declaring the dLOF defect condition.
Figure 2, Illustration of the OTSi/OTUk_A_Sk Atomic Function asserting its CI_SSF output because it is currently declaring the dLOF defect condition.
Please note that the CI_SSF output (from the OTSi/OTUk_A_Sk function) is connected to the CI_SSF input of the (downstream) OTUk_TT_Sk function.
OK, that’s great. The above Consequent Equation states that the STE (e.g., the OTSi/OTUk_A_Sk function will assert the CI_SSF output pin whenever it declares the dLOF defect.
How does that alert any other STE/PTE of the OTSi/OTUk_A_Sk function declaring the dLOF defect?
Answer: There is more to this, and it involves more Consequent Equations.
In Figure 3, I show the OTUk_TT_Sk and the OTUk/ODUk_A_Sk Atomic Functions.
I also show that the upstream (OTSi/OTUk_A_Sk function) circuitry is now asserting the CI_SSF input (to the OTUk_TT_Sk function) – as we described above.
Figure 3, Illustration of the OTUk_TT_Sk and OTUk/ODUk_A_Sk functions – with upstream circuitry asserting the CI_SSF input pin.
Now, the OTUk_TT_Sk Atomic Function happens to have two sets of Consequent Equations:
I will list each of these equations below.
aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))
aBDI <- CI_SSF or dAIS or dTIM
I will explain each of these equations below.
The First Consequent Equation – OTUk_TT_Sk Function
Let’s start with the first Consequent Equation for the OTUk_TT_Sk function.
aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))
Where:
aTSF is the current state of the AI_TSF output of the OTUk_TT_Sk Atomic Function.
CI_SSF is the current state of the CI_SSF input of the OTUk_TT_Sk Atomic Function.
dAIS is the current state of the dAIS defect condition, and
This Consequent Equation states that the OTUk_TT_Sk Atomic Function should assert the AI_TSF output signal anytime it declares any of the following defect conditions.
dTIM – Trail Trace Identifier Mismatch Defect
dAIS – AIS Defect
This Consequent Equation also states that the OTUk_TT_Sk function should assert the AI_TSF output whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk function) asserts the CI_SSF input pin.
In Figure 4, I show the OTUk_TT_Sk function asserting its AI_TSF output pin because the upstream OTSi/OTUk_A_Sk function is asserting the CI_SSF input pin (to this function).
Figure 4, The OTUk_TT_Sk Atomic Function asserts the AI_TSF output pin because the upstream OTSi/OTUk_A_Sk function is asserting its CI_SSF input pin.
OK, now let’s look at the second Consequent Equation for the OTUk_TT_Sk Function.
The Second Consequent Equation – OTUk_TT_Sk Function
aBDI <- CI_SSF or dAIS or dTIM
Where:
aBDI is the state of the RI_BDI output (of the Remote Port Interface) of the OTUk_TT_Sk function.
Earlier in this post, we have defined CI_SSF, dAIS, and dTIM.
Therefore, this Consequent Equation states that the OTUk_TT_Sk function will assert the RI_BDI output pin anytime it declares the dAIS or dTIM defect conditions.
This equation also states that the OTUk_TT_Sk function will also assert the RI_BDI output pin anytime the upstream circuitry asserts the CI_SSF input (to the OTUk_TT_Sk function).
If you recall from the OTUk_TT_So and OTUk_TT_Sk posts, I state that anytime the OTUk_TT_Sk function asserts the RI_BDI output pin, it will command its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back out to the remote end.
I show this phenomenon below in Figure 5.
Figure 5, The OTUk_TT_Sk function asserts its RI_BDI output pin, commanding its Collocated OTUk_TT_So function to transmit the BDI (Backward Defect Indicator) back to the upstream STE because its CI_SSF is being driven HIGH.
Figure 5 shows that because the STE (OTSi/OTUk_A_Sk function) declared the dLOF defect, the downstream OTUk_TT_Sk function responded by commanding its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back to the upstream STE (the source of the defective OTUk signal).
However, we’re not done yet.
Since the OTUk_TT_Sk function is also asserting its AI_TSF output, it is also asserting the AI_TSF input to the (down-stream) OTUk/ODUk_A_Sk atomic function.
Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You to Become an Expert at OTN!!! Click Below to Learn More!!
Let’s move on to the OTUk/ODUk_A_Sk Atomic Function
As you can see in Figure 5, the OTUk_TT_Sk function, by asserting its AI_TSF output pin, is also asserting the AI_TSF input pin to the OTUk/ODUk_A_Sk function.
And the OTUk/ODUk_A_Sk function comes with several Consequent Equations of its own.
aSSF <- AI_TSF and (not MI_AdminState = LOCKED), and
aAIS <- AI_TSF and (not MI_AdminState = LOCKED)
Let’s take each of these equations, one at a time.
The First Consequent Equation – OTUk/ODUk_A_Sk Function
aSSF <- AI_TSF and (not MI_AdminState = LOCKED)
Where:
aSSF is the current state of the CI_SSF output pin (from the OTUk/ODUk_A_Sk function).
MI_AdminState reflects the current state of the MI_AdminState input signal (which the System Operator can set).
This Consequent Equation states that the OTUk/ODUk_A_Sk function will automatically assert its CI_SSF output signal whenever the upstream circuitry asserts its AI_TSF input, provided that the System Operator has not put the OTUk/ODUk_A_Sk function into the LOCKED state.
In Figure 6, I show the OTUk/ODUk_A_Sk function asserting its CI_SSF output pin because the upstream circuitry is asserting its AI_TSF input pin.
Figure 6, The OTUk/ODUk_A_Sk function asserts its CI_SSF output pin because the upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF input pin.
I should also point out that APS (Automatic Protection Switching) systems often trigger (and start protection switching) whenever the OTUk/ODUk_A_Sk function asserts its CI_SSF output pin.
Now, let’s move on to the next Consequent Equation.
The Second Consequent Equation – OTUk/ODUk_A_Sk Function
If aAIS = TRUE, then the OTUk/ODUk_A_Sk function is overwriting its output signal with the ODUk-AIS Maintenance signal.
Conversely, if aAIS is FALSE, then the OTUk/ODUk_A_Sk function transmits an ODUk data stream, carrying regular client traffic.
Therefore, this Consequent Equation states that the OTUk/ODUk_A_Sk function will transmit the ODUk-AIS Maintenance Signal anytime the upstream circuitry pulls its AI_TSF input TRUE; provided that the System Operator has NOT put the OTUk/ODUk_A_Sk function into the LOCKED State.
In Figure 7, I illustrate the OTUk/ODUk_A_Sk function transmitting the ODUk-AIS Maintenance Signal because upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF input.
Figure 7, The OTUk/ODUk_A_Sk function replaces the ODUk signal (carrying client data) with the ODUk-AIS Maintenance Signal whenever upstream circuitry asserts its AI_TSF input.
Then, we could state that if the OTN STE declares the dLOF defect (as we discussed earlier in this post), then that same OTN STE will do all of the following:
It will transmit the OTUk-BDI indicator back towards the upstream STE.
The OTN STE will also replace the missing (or defective) ODUk data stream (carrying client traffic) with the ODUk-AIS Maintenance Signal, and
It will also trigger APS (Automatic Protection Switching) activities by asserting the CI_SSF output (from the OTUk/ODUk_A_Sk function).
I show a drawing of these actions below in Figure 8.
Figure 8, Illustration of the OTN STE responding to the dLOF Defect Condition
Conclusion
Thanks to Consequent Equations, we can define and predict how an OTN STE or PTE will respond to certain defects.
I have presented Consequent Equations in each post pertaining to OTN Atomic Functions.
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- or Protection-Switching-Related Posts
