This blog post presents a video that discusses the APS features within some fo the Atomic Functions that we discussed in Lesson 11.
Lesson 12 – Video 13 – Detailed Implementation of APS within the Atomic Functions – Video 2
This blog post continues our discussion of the APS features within various Atomic Functions. In this case, we will present how to implement Automatic Protection Switching in great detail. In particular, we will describe the following:
APS Features within the ODUT/ODU_A_So and ODUT/ODU_A_Sk functions (ODUT/TCM Layer – SNC/S Monitoring)
How do we implement the APS features within these Atomic Functions to support TCM Layer i SNC/S Monitoring and Protection-Switching?
How do we implement a complete System-Level design (using these atomic functions along with the ODUT_TT_So and ODUT_TT_Sk Atomic Functions)?
NOTE: We discussed these atomic functions in Lesson 11. However, we did not discuss the APS features (within those functions) then.
More specifically, we discuss how our system should implement APS and the APS Communication Protocol whenever the upstream ODUT_TT_Sk Atomic Function declares either a Service-Affecting or the TCMi-dDEG defect.
This blog post includes a video that serves as the 3rd (of our 4 Videos) that discusses the ODUT_TT_Sk Atomic Function. This video focuses on the TCMi-dDEG (Signal Degrade) defect condition, Defect Correlation and Consequent Equations.
Lesson 11 – Video 5 – Tandem Connection Monitoring – ODUT_TT_Sk Atomic Function, Part THREE
This blog post contains a video that covers the third part of the Sink Direction Tandem Connection Monitoring (TCM) related Atomic Functions.
In particular, this video covers the third part of the ODUT_TT_Sk Atomic Function.
This video specifically covers the following operations (within the ODUT_TT_Sk Atomic Function).
How the ODUT_TT_Sk Atomic Function declares and clears the TCMi-dDEG (Signal Degrade) defect condition
Defect Correlation within the ODUT_TT_Sk Atomic Function. This video reviews the following Defect Correlation Equations:
cSSF <- CI_SSF or dAIS;
cLTC <- dLTC and (NOT CI_SSF);
cOCI <- dOCI and (NOT CI_SSF);
cLCK <- dLCK and (NOT CI_SSF);
cTIM <- dTIM and (NOT CI_SSF) and (NOT dAIS) and (NOT dLTC) and (NOT dOCI) and (NOT dLCK);
cDEG <- dDEG and (NOT CI_SSF) and (NOT dAIS) and (NOT dLTC) and (NOT dOCI) and (NOT dLCK) and (NOT(dTIM and (NOT TIMActDis)));
cBDI <- dBDI and (NOT CI_SSF) and (NOT dAIS) and (NOT dLTC) and (NOT dOCI) and (NOT dLCK) and (NOT dTIM) and (NOT TIMActDis)));
Consequent Equations within the ODUT_TT_Sk Atomic Function. This video review the following Consequent Equations:
aBDI <- (CI_SSF or dAIS or dLTC or dOCI or dLCK or dTIM) and TCMCI_Mode != TRANSPARENT;
aBIAE <- dIAE and TCMCI_Mode != TRANSPARENT;
aTSF <- CI_SSF or ((dAIS or (dLTC and LTCAct_Enable) or dOCI or dLCK or (dTIM and (NOT TIMActDis))) and TCMCI_Mode == OPERATIONAL;
aTSD <- dDEG and TCMCI_Mode == OPERATIONAL;
aAIS <- (dOCI or (dLTC and LTCAct_Enable) or dLCK or (dTIM and (NOT TIMActDis))) and TCMCI_Mode == OPERATIONAL;
This post presents the 6th of the 6 Videos that covers training on the Peformance Monitoring of the ODUk Layer (for Multiplexed Applications). This post focuses on the Sink Direction ODU-Layer Atomic Functions.
OTN – Lesson 10 – Video 6M – The ODU0_TT_Sk and ODUkP/CBR_ETC1000X_A_Sk Atomic Functions
This blog post contains a video that wraps up our discussion of the Sink (or Receive) Atomic Function circuitry for the ODU-Layer/Multiplexed Applications.
More specifically, this video includes a discussion of the following Atomic Functions.
This post presents the 5th of the 7 Videos that covers training on the Peformance Monitoring of the ODUk Layer (for Non-Multiplexed Applications). This post focuses on the Sink Direction ODU-Layer Atomic Functions. More specifically, this post presents a video that discusses how the ODUk_TT_Sk Atomic Function declares and clears the PM-dDEG defect condition.
OTN – Lesson 10 – Video 5N – The ODUk_TT_Sk Atomic Function
This blog post presents a video that continues our discussion of the ODUk_TT_Sk Atomic Function.
This video covers the following features within the ODUk_TT_Sk Atomic Function.
How the ODUk_TT_Sk function declares and clears the dDEG (Path Signal Degrade) defect condition?
What does the ODUk_TT_Sk function do with its AI_TSF Output pin whenever it declares a Service-Affecting defect condition?
What does the ODUk_TT_Sk function do with its AI_TSD Output pin whenever it declares the dDEG (Signal Degrade) defect condition?
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 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.
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.
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
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)
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.