OTN – Lesson 12 – APS Features within Atomic Functions – Part 2

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.

Check Out the Video Below

Continue reading “OTN – Lesson 12 – APS Features within Atomic Functions – Part 2”

OTN – Lesson 12 – Detailed Discussion of SNC/N Monitoring (Protection Switching)

This blog post presents a video that describes (in detail) SNC/N (Subnetwork Protection – Non-Intrusive) Monitoring for Protection Switching.

Lesson 12 – Video 6 – Detailed Discussion of SNC/N (Subnetwork Circuit – Non-Intrusive) Monitoring for Protection Switching

This blog post contains a video that presents a detailed discussion of SNC/N (Subnetwork Circuit – Non-Intrusive Monitoring, for Protection-Switching purposes, at the ODU Layer.

In particular, this video will discuss the following topics:

  • A Detailed Review of SNC/Ne (Subnetwork Circuit Protection/Non-Intrusive End-to-End) Monitoring, and
  • A Detailed Review of SNC/Ns (Subnetwork Circuit Protection/Non-Intrusive Sublayer) Monitoring.
  • This video shows example locations/conditions of where we would use SNC/Ne or SNC/Ns Monitoring and why we would use this form of monitoring.
  • This video also highlights the similarities and differences between SNC/Ne and SNC/Ns Monitoring.

Check Out the Video Below

Continue reading “OTN – Lesson 12 – Detailed Discussion of SNC/N Monitoring (Protection Switching)”

OTN – Lesson 12 – Detailed Discussion of SNC/I Monitoring (Protection Switching)

This blog post presents a video that describes (in detail) SNC/I (Subnetwork Circuit – Inherent) Monitoring for Protection Switching.

Lesson 12 – Video 4 – Detailed Discussion of SNC/I (Subnetwork Circuit – Inherent) Monitoring for Protection Switching

This blog post contains a video that presents a detailed discussion of SNC/I Monitoring, both at the OTU and ODU layers.

In particular, this video will discuss the following topics:

  • How to perform SNC/I Monitoring at the OTU Layer
    • What Circuitry (Atomic Functions) that we should use
    • What defects to monitor
    • Which is the Normal Traffic Signal when doing SNC/I Monitoring at the OTU Layer.
    • What happens when we declare an OTU Layer Service-Affecting defect (dLOS, dLOF, dLOM, dLOL, dLOFLOM, dLOR, dAIS, and dTIM)?
    • What happens when we declare the SM-dDEG (OTU-layer Signal Degrade) defect?
    • How does protection-switching work?
  • How to perform SNC/I Monitoring at the ODU Layer
    • What Circuitry (Atomic Functions) that we should use
    • What defects to monitor
    • Which is the Normal Traffic Signal when doing SNC/I Monitoring at the ODU Layer.
    • What happens when we declare an ODUk Server-Layer service-affecting defects (such as dAIS, dOCI, dLCK, dTIM, dLOOMFI, and dPLM)?
    • What happens when we declare ODUj Tributary-Layer service-affecting defects (such as dLOFLOM and dMSIM)
    • What happens when we declare the PM-dDEG (ODU-layer Signal Degrade) defect?
    • How does protection-switching work?

Check Out the Video Below

Continue reading “OTN – Lesson 12 – Detailed Discussion of SNC/I Monitoring (Protection Switching)”

OTN – Lesson 11 – Tandem Connection Monitoring – Sink Atomic Functions – Video 3

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;
    • aBEI <- nBIPV and TCMCI_Mode != TRANSPARENT;

Check out the Video Below.

Continue reading “OTN – Lesson 11 – Tandem Connection Monitoring – Sink Atomic Functions – Video 3”

OTN – Lesson 10 – Handling Defects at the ODU-Layer – Defect Scenario Video

In this video, we presume that some ODUk- (or OTUk-) Layer circuitry is declaring a certain defect condition. We then determine how ODU-layer circuitry is expected to respond.

OTN – Lesson 10 – Handling Defects at the ODU-Layer – Defect Scenario for Multiplexed and Non-Multiplexed Applications

This video summarizes the various defects that OTN circuitry can declare/clear at the ODU-Layer.  

This video also describes how ODU-Layer circuitry is expected to respond to each ODU-Layer (or upstream OTU-Layer) defect.  

  • Should it transmit PM-BDI (Path Monitoring – Backward Defect Indicator) upstream?
  • Should it replace the under-lying 100oBASE-X or 100GBASE-R client signal with the Link or Local Fault Indicator?  

This video answers these questions and more.  

NOTE:  This video covers both Non-Multiplexed and Multiplexed Applications.

Continue reading “OTN – Lesson 10 – Handling Defects at the ODU-Layer – Defect Scenario Video”

OTN – Lesson 10 – Video 6M – End of ODU-Layer/Multiplexed Sink Circuitry

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.

  • ODU0_TT_Sk Function, and
  • ODU0P/CBR_1000X-g_A_Sk Function

Continue reading “OTN – Lesson 10 – Video 6M – End of ODU-Layer/Multiplexed Sink Circuitry”

OTN – Lesson 10 – Video 5N – ODUk_TT_Sk Atomic Function

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?  
  • Defect Correlation Equation Analysis
  • Consequent Equation Analysis 
  • Performance Monitoring Equation Analysis

Continue reading “OTN – Lesson 10 – Video 5N – ODUk_TT_Sk Atomic Function”

OTN – Lesson 9 – Video 11 – OTU Layer Defect Handling Requirements and Scenarios

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. 

Continue reading “OTN – Lesson 9 – Video 11 – OTU Layer Defect Handling Requirements and Scenarios”

OTN – Lesson 9 – Video 8 – OTUk_TT_Sk Function

This post presents the 8th of the 11 Videos that covers training on Performance Monitoring at the OTUk Layer. This post focuses on the Sink Direction OTU-Layer Atomic Functions.

OTN – Lesson 9 – Video 8 – OTU Layer Sink Direction Circuitry/Functionality – Part 6

This blog post includes another video that continues our discussion of the OTUk_TT_Sk Atomic Function.  In this video, we focus on the following aspects of this function.  

  • How it declares and clears the dIAE (Input Alignment Error) Defect Condition
  • How it declares and clears the dBIAE (Backward Input Alignment Error) Defect Condition.
  • The dTIM (Trail Trace Identifier Mismatch) Defect Condition.  
  • The dDEG (Section – Signal Degrade) Defect Condition
  • The type of signals that the OTUk_TT_Sk function outputs via the OTUk_AP Interface – particularly the AI_TSF and AI_TSD output signals.  

Continue reading “OTN – Lesson 9 – Video 8 – OTUk_TT_Sk Function”

What are Consequent Equations?

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.

And that’s all well and good.  

NOTE: (*) – Indicates that you need to be a member of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!! to access these links.

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.

Consequent Equation - OTSi/OTUk_A_Sk function declares the dLOF defect

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

aSSF <- dLOS-P or dAIS or dLOF or dLOM or AI_TSF-P

Where:

aSSF is the current state of the CI_SSF output pin (of the OTSi/OTUk-a_A_Sk function).

dLOS-P is the current state of the Loss of Signal-Path Defect condition

dAIS is the current state of the OTUk-AIS Defect Condition

dLOF is the current state of the Loss of Frame Defect Condition

dLOM is the current state of the Loss of Multi-Frame Defect Condition, and 

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.  

Consequent Equation - OTSi/OTUk_A_Sk function asserts CI_SSF due to dLOF defect

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.  

Let’s Take a Look at the Downstream Circuitry

Let’s now look at the OTUk_TT_Sk and OTUk/ODUk_A_Sk Atomic Functions (which are both downstream from the OTSi/OTUk_A_Sk function).  

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.  

Consequent Equations - Upstream Circuitry asserts CI_SSF input to the OTUk_TT_Sk function

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 

dTIM is the current state of the Trail Trace Identifier Mismatch Defect Condition.  

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

Consequent Equation - OTUk_TT_Sk Atomic Function asserts AI_TSF due to CI_SSF being asserted

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.  

Consequent Equation - OTUk_TT_Sk function asserts RI_BDI due to CI_SSF

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

AI_TSF is the current state of the AI_TSF input pin to the OTUk/ODUk_A_Sk function, and

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.  

Consequent Equations - OTUk/ODUk_A_Sk function asserts its CI_SSF output 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

aAIS <- AI_TSF and (not MI_AdminState = LOCKED)

Where:

aAIS is the current state of the ODUk-AIS Maintenance Signal

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.  

Consequent Equation - OTUk/ODUk_A_Sk function transmits ODUk-AIS downstream

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.  

So What Does All This Mean?

If we were to combine the OTSi/OTUk_A_Sk function, the OTUk_TT_Sk function, its Collocated OTUk_TT_So function, and the OTUk/ODUk_A_Sk function into a single box, that we call OTN STE.

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.

Consequent Equations - Overall OTN STE's response to it declaring the dLOF Defect Condition

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

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? ...
Read More
Protection-Switching Related Blog

Protection-Switching Related Blog Posts

Protection-Switching Related Blog Posts Basic Protection-Switching Terms Head-End (Source Node) Hold-Off Timer Protection-Group Protection-Transport entity Selector Switch Tail-End (Sink Node) ...
Read More