Lesson 2 – OTU Framing

This post provides a comprehensive review and video training of the OTU frame and its overhead fields.

Lesson 2 – Optical Transport Unit Frame Training

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, along with the roles that each of its overhead fields play.

Continue reading “Lesson 2 – OTU Framing”

What is pF_EBC at the OTUk Layer?

This blog post briefly describes the term pF_EBC (Far-End Errored Block Error).

What is the pF_EBC (Far-End Errored Block Count) Parameter for the OTUk Layer?

The purpose of this blog post is to briefly define and describe the pF_EBC (Far-End Errored Block Count) parameter that the OTN (Sink) STE (or OTUk_TT_Sk Atomic Function) will compute and tally.

The Sink STE (or OTUk_TT_Sk function) will include information on the pF_EBC parameter within each Performance Monitoring report, that it sends to System Management.

NOTES:

  1. The OTN PTE (or ODUP_TT_Sk Atomic Function) also monitors and generates information on the pF_EBC (Far-End Errored Block Count) parameter at the ODUk Layer. Please see the pF_EBC at ODUk Layer Post for more details on this parameter.
  2. Throughout this post, I will be using the terms: OTN STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.

Introduction

At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Far-End Errored Block Counts (or SM-BEI errors).

As the Sink STE receives and monitors its incoming OTUk signal, it will check for many things. It will continuously check the incoming OTUk signal for bit (or symbol) errors (e.g., SM-BIP-8 errors, FEC errors, etc.). It will also check for Service-Affecting defects (e.g., dTIM, dLOM, dLOF, dAIS, dLOS-P, etc.).

As the Sink STE checks the incoming OTUk signal for errors and defects, it will also keep a count of the total number of far-end errored block, that it detects for each one-second period.

At the end of a given one-second period, the Sink STE will load the total number of far-end errored block counts (that it has detected in the most recent one-second period) into the variable pF_EBC.

Definition of Terms:

Before we proceed, we need to define the following terms for this blog post:

  • Block: In this case, we define a block as an OTUk frame.
  • Far-End Errored Block: In this blog post, we define a far-end errored block as any OTUk frame, that contains a value (anywhere from 0x01 and 0x08) for the SM-BEI count.

Since each type of OTUk signal (for a given value of k) transmits a different number of OTUk frames than do another OTUk signal (with a different value for k), each OTUk type will transmit a different number of blocks/seconds, as we show below in Table 1.

Table 1, Number of Blocks/Second for each OTUk Rate.

OTUk TypeNumber of Blocks/Second
OTU120,421
OTU282,026
OTU3329,492
OTU4856,388
OTUCnn x 860,177

So How does the OTN STE tally Errored Blocks for the pF_EBC parameter?

As the Sink STE receives and monitors its OTUk signal, it will continually check for SM-BEI counts.

Anytime the Sink STE receives an OTUk frame in which the SM-BEI value is anywhere from 1 to 8, then it will increment its internal (pF_EBC Counter) by 1.

NOTE: This means that even if the Sink STE receives an SM-BEI value of “8”, it will still just increment its pF_EBC Counter by 1 (not 8)?

Conversely, the Sink STE does not increment its internal pF_EBC Counter, whenever it receives an OTUk frame that contains an SM-BEI value of 0, or 9 through 15.

At the end of each one-second period, the Sink STE will load the contents of this internal counter into the pF_EBC parameter. The Sink STE will include that information within its Performance Monitor report, that it sends to System Management.

Are there any Times or Conditions, during which the Sink STE will NOT tally Errored Block Counts for the pF_EBC parameter?

Yes, ITU-T G.798 states that the OTUk_TT_Sk function will stop tallying Errored Blocks for the pF_EBC parameter whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk Atomic Function) asserts the CI_SSF input of the OTUk_TT_Sk function.

In other words, the Sink STE will not tally any Errored Block Counts (for the pF_EBC parameter) whenever it (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions) declare any of the following defect conditions.

  • dLOS-P – Loss of Signal – Path
  • dAIS (e.g., OTUk-AIS)
  • dLOFLoss of Frame
  • dLOMLoss of Multi-Frame
  • dLOFLANE – Loss of Frame – Logical Lane Signal (for OTL3.4, OTL4.4 or OTL4.10 applications ONLY)
  • dLOL – Loss of Lane Alignment (for OTL3.4, OTL4.4 or OTL4.10 applications ONLY)
  • Or if the upstream Optical circuitry is asserting the AI_TSF-P input pin to the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk function.

Additionally, the OTUk_TT_Sk function is not supposed to tally any pF_EBC counts whenever it is declaring the dBIAE (Backward Input Alignment Error) defect condition as well.

Is there such a thing as Near-End Errored Block Counts?

Throughout this post, we have been using the term “Far-End Errored Block Count”. Does this mean that there is another parameter called “Near-End Errored Block Count”?

Answer: Yes, there is such a parameter. Please see the post on Near-End Errored Block Count at the OTUk Layer for more details.

And Finally, Click on the Following Image for More OTN-Related Topics in this Blog.

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

What is OTUk-BEI or SM-BEI?

This post briefly defines the SM-BEI (Section Monitoring – Backward Error Indicator) parameter. It also describes how an OTN Network will transmit the SM-BEI parameter from one Network Element to another.

What is the OTUk-BEI (Backward Error Indicator) or SM-BEI Parameter?

The purpose of this post is to define the SM-BEI (Section Monitor – Backward Error Indicator) parameter that a Source STE will generate and a Sink STE will tally at the OTUk-Layer.

Introduction

In another post, we describe how the Sink STE (or the OTUk_TT_Sk function) will compute and verify the SM-BIP-8 value within each incoming OTUk frame.

NOTE: Throughout this post, I will be using the terms Sink STE and OTUk_TT_Sk function, interchangeably.

The Sink STE performs this task to check to any occurrences of bit-errors during data transmission (over optical fiber) from the STE Source Terminal to the STE Sink Terminal.

However, just as the Sink STE (through its near-end Source STE) sends out the SM-BDI indicator, back out to the remote Terminal, whenever it declares a service-affecting defect; the Sink STE (again, through its near-end Source STE) will also send out information, back out to the remote Terminal to denote the number of BIP-8 errors it has detected within each incoming OTUk frame.

We call this information the Backward-Error Indicator (or BEI) and I will explain how we generate and transport this parameter below.

A High-Level Overview of the SM-BEI Parameter and How we Use it.

Before we get into the details of how things work with the various Atomic Functions and Ports, let’s spend some time discussing the basic philosophy for transmitting the SM-BEI indicator.

Let us consider two Network Elements. We will call one Network Element, N.E East and the other Network Element N.E. West. We have connected these two networks together via a Bidirectional Optical Connection, as we show below in Figure 1.

West to East Bidirectional Optical Connection

Figure 1, Illustration of Network Elements East and West connected to each other over a Bidirectional Fiber Optic Connection.

Now let’s consider two possible cases when it comes to dealing with SM-BIP-8 errors and SM-BEI.

  • The Unerred Case (where the Number of BIP-8 Errors = 0) and
  • The Erred Case (where the Number of BIP-8 Errors = 5)

The Unerred Case (where the Number of BIP-8 Errors = 0)

For now, let’s assume, the OTUk Transceiver and OTUk Framer (within Network Element EAST) are not detecting any BIP-8 errors within a given OTUk frame.

We show this case below in Figure 2.

BIP-8 Errors - Network Element East declares NO BIP-8 Errors

Figure 2, Illustration of Network Element EAST detecting NO BIP-8 Errors within OTUk Frame # n

Please note that in Figure 2, I show that both the OTUk Transceiver and OTUk Framer blocks (within Network Element EAST) are detecting ZERO BIP-8 errors. I show this because many OTUk Transceivers will also include some OTUk Framing capability and will be able to detect and flag BIP-8 errors.

In this case, Network Element EAST will respond to this ZERO BIP-8 Error condition by setting the BEI field (within its very next outbound OTUk frame – back to Network Element WEST) to “0x00”.

In Figure 3, we show Network Element EAST setting the BEI field to 0x00, within its next outbound OTUk frame.

SM-BEI - Network Element EAST sends BEI = 0 back out to Network Element WEST

Figure 3, Illustration of Network Element EAST responding to the NO BIP-8 Error Condition by setting BEI = 0, within its next outbound OTUk frame.

Both the OTUk Transceiver and Framer (within Network Element WEST) will receive this OTUk frame (with BEI = 0) and it will “know” that the quality of its OTUk signal (out to Network Element EAST) is GOOD.

Therefore, the BEI field (within the OTUk Overhead) gives the Network Element a way to provide some feedback to an upstream Network Element about the quality of its output signal.

As long as Network Element WEST continues to receive OTUk frames with the BEI field set to 0, then it has some indication that it is transmitting a good quality OTUk signal out to Network Element EAST.

NOTE: Since this is a bidirectional connection between Network Elements EAST and WEST, then Network Element WEST can (and will) provide the same type of feedback to Network Element EAST.

Now let’s move on to the Erred Case.

The Erred Case (where the Number of BIP-8 Errors = 5)

Now that we have covered the No-Error condition, let’s cover a different condition. Let us assume that Network Element EAST has just received an OTUk frame, in which it detects 5 BIP-8 errors.

I show an illustration of this condition, below in Figure 4.

BEI - East Network detects and flags 5 BIP-8 Errors

Figure 4, Illustration of Network Element EAST detecting 5 BIP-8 Errors within OTUk Frame # n

In this case, Network Element EAST will respond to this error condition, by setting the BEI field (within its very next outbound OTUk frame – back out to Network Element WEST) to “0x05” (e.g., the same number of BIP-8 errors that it detected) within its recently received OTUk frame.

In Figure 5, we show Network Element EAST setting the BEI field to 0x05, within its next OTUk frame.

Network Element EAST sends BEI = 5 back out to Network Element WEST

Figure 5, Illustration of Network Element EAST responding to the 5 BIP-8 Error Condition by setting BEI = 5, within its next outbound OTUk frame

In this case, since Network Element EAST sets the BEI-field to “0x05” it is giving Network Element WEST some feedback that it (Network Element EAST) is having some problems with the OTUk data-stream that it is receiving from Network Element WEST.

Now that we understand the basic philosophy behind the use of the SM-BEI fields, let’s discuss the SM-BEI parameter in greater detail.

An Indepth Discussion – How Does the Sink STE generate the BEI Parameter?

In the SM-BIP-8 Post, I mentioned that the Sink STE will locally compute its own version of the SM-BIP-8 value, based upon the contents within the OPUk portion of the OTUk frame.

I also mentioned that this SM-BIP-8 value is an 8-bit value.

The Sink STE (or OTUk_TT_Sk function) will then read out the contents of the BIP-8 byte (within the Section Monitoring field) two OTUk frame periods later and it will compare these two BIP-8 values.

I show the location of the Location of the BIP-8 Value, with respect to the OTUk Frame (that we used to compute this value), below in Figure 6.

SM-BIP-8 Where we calculate and insert the SM-BIP-8 Value within an OTUk frame

Figure 6, The Location of the BIP-8 Value, with respect to the OTUk Frame (that we used to compute this value)

Comparing the Locally Computed BIP-8 Value with the Remotely Computed Value

If these byte-values (of BIP-8 values) are equal, then we can state that this particular OTUk frame incurred no bit errors during transmission over the optical fiber.

On the other hand, if these two BIP-8 values are NOT the same, then it is important that the Sink STE (or OTUk_TT_Sk function) note how many bits (between these two BIP-8 values) are different from each other.

In other words, as the OTUk_TT_Sk function makes its comparison between its locally computed BIP-8 value and that which it reads in from the BIP-8 byte-field within the incoming OTUk data-stream, it will perform a bit-by-bit XOR operation with each of these byte values.

The OTUk_TT_Sk function must then count the numbers of “1s” that occurs during this bitwise XOR comparison. The OTUk_TT_Sk function can come up with any of the following nine (9) possibilities.

  • 0 bits in Error – Error-Free Transmission
  • 1 bit in Error
  • 2 bits in Error
  • 3 bits in Error
  • 4 bits in Error
  • 5 bits in Error
  • 6 bits in Error
  • 7 bits in Error
  • 8 (all) bits in Error

In Figure 7, I show an illustration of a Bit-Wise XOR Comparator that the OTUk_TT_Sk function can use to compare its locally-computed BIP-8 value with the remotely-computed BIP-8 values.

SM-BEI - BIP-8 XOR Comparator Circuit

Figure 7, Illustration of a Bit-Wise XOR Comparator that the OTUk_TT_Sk function can use to compare its Locally-Computed BIP-8 Value with the Extracted (Remotely Computed) BIP-8 Value for a given OTUk frame.

The OTUk_TT_Sk function will then need to send these BIP-8 comparison results back out to the remote terminal (the source of OTUk signal, that we are monitoring) in the form of BEI (Backward-Error-Indicator) value.

How does the OTUk_TT_Sk send out SM-BEI Information to the Remote Terminal?

Once the OTUk_TT_Sk function has performed the comparison (between its locally computed BIP-8 value with that of the remote-computed value), it then needs to report this information back out to the remote terminal.

The OTUk_TT_Sk function will accomplish this by sending a command to its collocated OTUk_TT_So function via the BEI (or RI_BEI) port.

I show an illustration of the OTUk_TT_Sk function, its collocated OTUk_TT_So function and the BEI port, below in Figure 8.

Collocated OTUk_TT_So and OTUk_TT_Sk functions with BEI port highlighted

Figure 8, Illustration of the OTUk_TT_Sk, its collocated OTUk_TT_So function and the BEI port.

The OTUk_TT_Sk function will use the BEI port to tell the OTUk_TT_So function, what value, it should set the BEI/BIAE nibble field to during its next outbound OTUk frame.

How does the OTUk Network Element transmit the SM-BEI Indicator?

The Network Element will transmit the SM-BEI indicator by setting the BEI/BIAE nibble-field within the SM (Section Monitoring) byte, to the BEI value, within each outbound OTUk frame.

The SM byte resides within the 3-byte SM (Section Monitoring) field of the OTUk Overhead.

Figure 9a, 9b, and 9c together present the location of the BEI/BIAE field within an OTUk frame. First of all, Figure 9a presents an illustration of the SM-field within the OTUk Overhead.

Location of Section Monitoring Field within OTUk Frame

Figure 9a, The SM Field within the OTUk Overhead

Second, Figure 9b presents an illustration of the location of the SM byte, within the 3-byte SM Field.

SM field with the SM Byte identified

Figure 9b, The SM-Byte within the SM Field

Finally, Figure 9c presents an illustration of the location of the BEI/BIAE nibble-field, within the SM-byte.

Section Monitoring Byte with the SM-BEI field Highlighted

Figure 9c, The Location of the BEI/BIAE nibble-field within the SM Byte, within the SM Field, of the OTUk Overhead.

What is the Official Interpretation of the SM-BEI/BIAE Nibble, within the OTUk Frame?

The SM-BEI/BIAE Nibble (within the Section Monitoring Byte) does not only carry Backward Error Indication information. It also carries the BIAE (Backward Input Alignment Error Indicator) as well.

Table 1 presents a list that defines how we should interpret each value for the SM-BEI/BIAE Nibble.

SM-BEI/BIAE[1:4] Nibble ValueIs BIAE Declared? BEI Count (Value) if any
0000NO0
0001NO1
0010NO2
0011NO3
0100NO4
0101NO5
0110NO6
0111NO7
1000NO8
1001, 1010NO0
1011YES (BIAE)0
1100 through 1111NO0

Table 1 shows that only nibble values of 0x01 through 0x08 actually reflect some (non-zero) Backward Error Indication count.

For More Information on OTN Posts in this Blog, click on the Image below

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

What is pN_EBC at the OTUk Layer?

This blog post briefly describes the term pN_EBC (Near-End Errored Block Error).

What is the pN_EBC (Near-End Errored Block Count) Parameter for the OTUk Layer?

The purpose of this blog post is to briefly define and describe the pN_EBC (Near-End Errored Block Count) parameter that the Sink STE (or OTUk_TT_Sk Atomic Function) will compute and tally.

The Sink STE (or OTUk_TT_Sk function) will include information on the pN_EBC parameter within each Performance Monitoring report, that it sends to System Management.

NOTES:

  1. The OTN PTE (or ODUP_TT_Sk Atomic Function) also monitors and generates information on the pN_EBC (Near-End Errored Block Count) parameter at the ODUk Layer. Please see the pN_EBC at ODUk Layer Post for more details on this parameter.
  2. Throughout this post, I will be using the terms: Sink STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.

Introduction

At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Near-End Errored Block Counts (or SM-BIP-8 Errors).

As the Sink STE receives and monitors its incoming OTUk signal, it will check for many things. It will continuously check the incoming OTUk signal for bit (or symbol) errors (e.g., SM-BIP-8 errors, FEC errors, etc.) as well as Service-Affecting Defects (e.g., dTIM, dLOF, dLOM, dLOS-P, dAIS, etc.).

As the Sink STE checks the incoming OTUk signal for errors and defects, it will also keep a count of the total number of errored blocks, that it detects for each one-second period.

At the end of a given one-second period, the Sink STE will load the total number of errored block counts (that it has detected in the most recent one-second period) into the variable pN_EBC.

Definition of Terms:

Before we proceed, we need to define the following terms for this blog post:

  • Block: In this case, we define a block as an OTUk frame.
  • Errored Block: In this blog post, we define an errored block as any OTUk frame, that contains at least one BIP-8 error.

Since each type of OTUk signal (for a given value of k) transmits a different number of OTUk frames than does another OTUk signal (with a different value for k), each OTUk type will transmit a different number of blocks/second, as we show below in Table 1.

Table 1, Number of Blocks/Second for each OTUk Rate

OTUk TypeNumber of Blocks/Second
OTU120,421
OTU282,026
OTU3329,492
OTU4856,388
OTUCnn x 860,177

So How does the OTN STE tally Errored Blocks for the pN_EBC parameter?

As the Sink STE receives and monitors its OTUk signal, it will continually check for SM-BIP-8 errors.

Anytime the Sink STE receives an OTUk frame that contains at least one SM-BIP-8 error, then it will increment its internal (pN_EBC Counter) by 1.

Conversely, the Sink STE does not increment its internal pN_EBC Counter, whenever it receives an OTUk frame that contains 0 SM-BIP-8 errors.

At the end of each one-second period, the Sink STE will load the contents of this internal counter into the pN_EBC parameter and will include that information within its Performance Monitor report, that it sends to System Management.

Are there any Times or Conditions, during which the OTN STE will NOT tally Errored Block Counts for the pN_EBC parameter?

Yes, ITU-T G.798 states that the OTUk_TT_Sk function will stop tallying Errored Blocks for the pN_EBC parameter whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk Atomic function) asserts the CI_SSF input of the OTUk_TT_Sk function.

In other words, the OTN STE will not tally any Errored Block Counts (for the pN_EBC parameter) whenever it (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions) declares any of the following defects conditions.

  • dLOS-P – Loss of Signal – Path
  • dAIS (e.g., OTUk-AIS)
  • dLOFLoss of Frame
  • dLOMLoss of Multi-Frame
  • dLOFLANE – Loss of Frame – Logical Lane Signal (for OTL3.4, OTL4.4 or OTL4.10 applications ONLY)
  • dLOL – Loss of Lane Alignment (for OTL3.4, OTL4.4 or OTL4.10 applications ONLY)
  • Or if the upstream Optical circuitry is asserting the AI_TSF-P input pin to the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk function).

Additionally, the OTUk_TT_Sk function is not supposed to tally any pN_EBC counts whenever it is declaring the dIAE (Input Alignment Error) defect condition as well.

Is there such a thing as Far-End Errored Block Counts?

Throughout this post, we have been using the term “Near-End Errored Block Count”. Does this mean that there is another parameter called “Far-End Errored Block Count”?

Answer: Yes, there is such a parameter. Please see the post on Far-End Errored Block Count at the OTUk Layer for more details.

And Finally, Click on the Following Image for More OTN-Related Topics in this Blog

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

What is pF_DS at the OTUk Layer?

This blog post briefly defines the pF_DS (Far-End Defect Second) parameter – for the OTUk Layer.

What is the pF_DS (Far-End Defect Second) Parameter for the OTUk Layer?

The purpose of this blog post is to briefly define and describe the pF_DS (Far-End Defect Second) parameter that the OTN STE (or OTUk_TT_Sk Atomic Function) will declare.  

The OTN STE (or OTUk_TT_Sk function) will include information on pF_DS within each Performance Monitoring report, that it sends to System Management.  

Performance Monitoring - Another Image

NOTES:

  1. The OTN PTE (or ODUP_TT_Sk Atomic Function) also monitors and generates information on the PF_DS (Far-End Defect Second) parameter at the ODUk Layer.  Please see the pF_DS at ODUk Layer Post for more details on this parameter.
  2. Throughout this post, I will be using the terms:  OTN STE and OTUk_TT_Sk Function interchangeably.  In the context of this blog post, these two terms mean the same thing.  

Introduction

At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Far-End Defect Second events.

As the OTN STE receives and monitors its incoming OTUk signal, it will check for many things.  It will continuously check the incoming OTUk signal for Service-Affecting Defects (e.g., dBDI, dTIM, dLOF, dLOS-P, etc.) as well as bit (or symbol) errors (e.g., SM-BIP-8 errors, SM-BEI errors, FEC errors, etc.).  

Another thing that the OTN STE will do (as it continuously monitors it its incoming OTUk signal) is to divide each one-second period of (monitoring) time into the following two categories:

  • Far-End Available (Working) Seconds, and
  • Far-End Defect Seconds

Anytime the OTN STE detects and categories a given one-second period as being a Far-End Defect Second, then it will increment the pF_DS parameter and report that information to System Management.  

So When does the OTN STE detect and flag a given One-Second Period as being a “Far-End Defect Second”?

ITU-T G.798 presents the following Perfomance Monitoring Equation for the OTUk_TT_Sk function.  

pF_DS <- dBDI

Where:

dBDI is the current state of the OTUk-BDI or Backward Defect Indicator Defect (at the OTUk Layer)

The OTN STE (or OTUk_TT_Sk function) will continuously evaluate the above-mentioned equation, as it monitors its incoming OTUk signal.  

This equation states that the OTN STE will declare a given one-second period as being a “Far-End Defect Second” if it has declared the dBDI defect condition during any portion of that one-second period.  

So, if the OTUk_TT_Sk function has declared the dBDI defect condition for even a fraction of a given one-second period, it will declare that one-second period as a Far-End Defect Second.  It will also set the parameter pF_DS to 1, and report that information to System Management.  

Conversely, if the OTN STE determines that the OTUk_TT_Sk function did not declare the dBDI defect condition, at all, during a given one-second period, then it will declare that one-second period as being a Far-End Available (Working) Second.   In this case, the OTN STE will NOT set the parameter pF_DS to 1.  

Are there any Times or Conditions, during which the OTN STE should NOT tally the pF_DS Parameter?

Yes, ITU-T G.798 states that the OTUk_TT_Sk function (or System Management) should discard the previous and the current one-second period’s measurement of pF_DS whenever it declares either the dIAE (Input Alignment Error) or dBIAE (Backward Input Alignment Error) defect conditions.

We need to discard the previous one-second period reading, due to the delay of the IAE signaling indicator, coming from the remote terminal equipment.

Is there such a thing as a Near-End Defect Second?

Throughout this post, we have been using the term “Far-End Defect Second”.  Does this mean that there is another parameter called “Near-End Defect Second“?

Answer:  Yes, there is such a parameter.  Please see the post on Near-end Defect Seconds (pN_DS) at the OTUk Layer for more details.  

And Finally, CLICK on the Image Below to see More OTN-Related Topics in this Blog.  

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

What is pN_DS at the OTUk Layer?

This blog post briefly defines the pN_DS (Near-End Defect Second) parameter – for the OTUk Layer.

What is the pN_DS (Near-End Defect Second) Parameter for the OTUk Layer?  

The purpose of this blog post is to briefly define and describe the pN_DS (Near-End Defect Second) parameter that the OTN STE (or OTUk_TT_Sk Atomic Function) will declare.

The OTN STE (or OTUk_TT_Sk function) will include information on pN_DS within each Performance Monitoring report, that it sends to System Management.  

Performance Monitoring Reports

NOTES

  1. The OTN PTE (or ODUP_TT_Sk Atomic Function) also monitors and generates information on the pN_DS (Near-End Defect Second) parameter at the ODUk Layer.  Please see the pN_DS at ODUk Layer Post for more details on this parameter.  
  2. Throughout this post, I will be using the terms:  OTN STE and OTUk_TT_Sk Function interchangeably.  In the context of this blog post, these two terms mean the same thing.  

Introduction

At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Near-End Defect Second events.  

As the OTN STE receives and monitors its incoming OTUk signal, it will check for many things.  It will continuously check the incoming OTUk signal for Service-Affecting Defects (e.g., dTIM, dLOF, dLOM, dLOS-P, dAIS, etc) as well as bit (or symbol) errors (e.g., SM-BIP-8 errors, FEC errors, etc).  

Another thing that the OTN STE will do (as it continuosly monitor its incoming OTUk signal) is to divide each one-second period of (monitoring) time into the following two categories:

  • Near-End Available (Working) Seconds, and 
  • Near-End Defect Seconds

Anytime the OTN STE detects and categorizes a given one-second period as being a Near-End Defect Second, then it will increment the pN_DS parameter and report that information to System Management.  

So When does the OTN STE detect and flag a given One-Second Period as being a “Near-End Defect Second”?  

ITU-T G.798 presents the following Performance Monitoring Equation for the OTUk_TT_Sk function.

pN_DS <- CI_SSF or dAIS or dTIM

Where: 

CI_SSF is the current state of the CI_SSF input pin to the OTUk_TT_Sk Atomic Function, and

dAIS is the current state of the AIS Defect Condition, (for B100G/OTUCn applications only) and 

dTIM is the current state of the Trail Trace Identifier Message (or OTUk-TIM) defect condition.  

The OTN STE (or OTUk_TT_Sk function) will continuously evaluate the above-mentioned equation, as it monitors its incoming OTUk signal.  

This equation states that the OTN STE will declare a given one-second period as being a “Near-End Defect Second” if it determines that any of the following conditions are (or were ever) TRUE during that one-second period.

  • If the upstream circuitry (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk function) asserts the CI_SSF input pin, or
  • The OTUk_TT_Sk function is declaring the dTIM (OTUk-TIM) defect condition, or 
  • If the OTUk_TT_Sk function is declaring the dAIS defect condition (for B100G/OTUCn Applications ONLY).

So, if the OTUk_TT_Sk function determined that the upstream circuitry asserted the CI_SSF input for even a fraction of a given one-second period, then it will declare that one-second period as being a Near-End Defect Second.  It will also set the parameter pN_DS to 1, and report that information to System Management.  

Conversely, if the OTN STE determines that the NONE of those conditions were true, during the most recent one-second period, then it will declare that one-second period as being a Near-End Available (Working) Second.  In this case, the STE will not increment the pN_DS parameter.  

What causes the Upstream Circuitry to Assert the CI_SSF input pin? 

The upstream circuitry will assert the CI_SSF input pin (to the OTUk_TT_Sk function) if it declares any Service-Affecting defects with the OTUk signal that it is receiving.  

You can learn more about the conditions, that will cause the upstream circuitry to assert the CI_SSF input signal by checking out the Consequent Equations within the following posts.

  • CLICK HERE – If you are working with an OTU3 or OTU4 signal, that is operating over an OTL3.4 or OTL4.4 Interface.  
  • CLICK HERE – If you are not using an OTL3.4 o4 OTL4.4 Interface.

Are there any Times or Conditions, during which the OTN STE should NOT tally the pN_DS Parameter?

Yes, ITU-T G.798 states that the OTUk_TT_Sk function (or System Management) should discard the previous and the current one-second period’s measurement of pN_DS whenever it declares the dIAE (Input Alignment Error) defect condition.

We need to discard the previous one-second period reading, due to the delay of the IAE signaling indicator, coming from the remote terminal equipment.

Is there such a thing as a Far-End Defect Second?

Throughout this post, we have been using the term “Near-End Defect Second“.  Does this mean that there is another parameter called “Far-End Defect Second“?

Answer:  Yes, there is such a parameter.  Please see the post on Far-End Defect Seconds at the OTUk Layer for more details.  

And Finally, CLICK On the Image Below to see More OTN-Related Topics in this Blog.  

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

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 a defect, such as dAIS (Alarm Indication Signal), dLOM (the Loss of Multi-frame) defect.  

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.  

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 responsibilty 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 make things more confusing, the PTE/STE are required to 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 we show 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 condition:

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

Lets Take a Look at the Downstream Circuitry

Let’s now take a 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 both 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 both 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 (eg., 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 take a 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.  

We have already defined CI_SSF, dAIS and dTIM earlier in this post.  

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 being driven HIGH

In Figure 5, we show that, because the STE (OTSi/OTUk_A_Sk function) declared the dLOF defect, the downstream OTUk_TT_Sk function responded by command 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, this means that it is also asserting the AI_TSF input to the (down-stream) OTUk/ODUk_A_Sk atomic function.  

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 own 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 a couple of 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 will 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 this means that the OTUk/ODUk_A_Sk function is overwriting its output signal with the ODUk-AIS Maintenance signal.

Conversely, if aAIS is FALSE, then this means that the OTUk/ODUk_A_Sk function is transmitting an ODUk data-stream, that is 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 show an illustration of 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 this All 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 an 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 of the posts that pertain to OTN Atomic Functions.  

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

Declaring/Clearing the dLOM Defect

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.


How an OTN STE should declare and clear the dLOM (Loss of Multi-Frame) 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.

If you’re analyzing this topic from an ITU-T G.798 Atomic Function standpoint, then 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.

A Note about Terminology:

Throughout this blog post, I will be referring to the entity that contains 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 that it is a lot simpler to use that word than to use the words:  OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions.  However, I will be using atomic function-related terms, below in Table 1 (at the end of this post).

A Brief Review of the OTUk Frame Structure

In the OTUk Post, I stated that the OTUk frame consists of a single multi-frame alignment signal (MFAS) byte.

I present an illustration of the OTUk Frame Structure, with the MFAS-field highlighted, below in Figure 1.

OTUk Frame Format with the MFAS Byte-field Highlighted - dLOM Defect

Figure 1, Illustration 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 MFAS Byte Increments with each Frame

The S0urce STE Terminal will designate one of these OTUk frames as being the very 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 very next OTUk frame, then it will set the MFAS byte (within that particular OTUk frame) to 0x01.

The Source STE will continue to increment the MFAS byte, within each outbound OTUk frame until it has transmitted the 256th frame, within this particular multi-frame, and it has set the MFAS byte (within that frame) 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 indicate 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.

A Basic Requirement before We can Clear the dLOM Defect Condition

Before I continue with discussing 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.

It is impossible for the Sink STE to 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 will automatically lose MFAS synchronization as well.

There are several reasons for this:

The Sink STE needs to find the FAS-field first

Since 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 then locate the MFAS byte.

The FAS-field is FAR easier for the Sink STE to find than 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 simply looking for these fixed patterns.  On the other hand, the MFAS byte value changes with every OTUk frame.

Additionally, the FAS field is NEVER scrambled.  However, the MFAS byte is scrambled.

I show an illustration of an OTUk frame below, that identifies the portions of the OTUk frame that the Remote Source STE will scramble, before transmitting this OTUk frame to the Near-end Sink STE.

Scrambled Portions of an OTUk Frame - Need for dLOF to be cleared to clear dLOM

Figure 2, Illustration an OTUk Frame – Identifying the portions of the OTUk Frame that are scrambled.  

Finally, the MFAS byte-field is scrambled by a Frame-Synchronous Scrambler (at the remote Source STE)

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 to have 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 move on to discussing how the Sink STE declares and clears the dLOM defect condition.

We will first discuss the dLOM-Related State Machines.

The dLOM-Related State Machines

Once again, anytime the Sink STE is powered-up and is receiving a stream of OTUk data; it will first need to acquire FAS-frame synchronization with this incoming data-stream, as we described in the dLOF – Loss of Frame Defect blog post.

Once the Sink STE has cleared the dLOF defect condition (and can now reliably locate the FAS field within each incoming OTUk frame); then it can proceed on to locate 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 just acquired FAS-frame synchronization with the incoming OTUk frame (as has cleared the dLOF defect condition), then it will always be operating in accordance with two sets of state machines, simultaneously.

  • The OTUk-MFAS OOM/IM Low-Level State Machine and
  • The OTUk-dLOM 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-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.

dLOM Defect - State Machine Hierarchy

Figure 3, Illustration of the Relationship between the two dLOM-related State Machines

We will discuss each of these two state machines below.

The OTUk-MFAS OOM/IM Low-Level State Machine

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 present an illustration of the OTUk-MFAS OOM/IM Low-Level State Machine Diagram, below in Figure 4.

dLOM Defect - OTUk-MFAS OOM/IM (Low-Level) State Machine

Figure 4, Illustration of the OTUk-MFAS OOM/IM Low-Level State Machine Diagram

Figure 4 shows that the OTUk-MFAS OOM/IM Low-Level State Machine consists of the following two states.

  • The LL-OOM (Low-Level – Out of Multi-frame) state and
  • The LL-IM (Low-Level – In Multi-frame) state

From the moment that the System Operator powers up the Sink STE circuitry, and feeds an OTUk data-stream to it (from the remote Source STE), and has cleared the dLOF defect, then it will always be operating in one of these two states.

The Sink STE will (on occasion) need to transition from one state to the other and back.

We will discuss each of these two states below.

The LL-OOM State

Whenever a given Sink STE has first cleared 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 it 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 it will (internally) increment this value by 1.  Afterward, the Sink STE will apply this read-in value into the equation above.  The resulting new value will be the “Next _Expected_MFAS_Value” for 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 + 1” matches that of the “Next_Expected_MFAS_Value,” then it will transition into the LL-IM (Low-Level – In-Multi-Frame) state.

The LL-IM 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.

As long as the Sink STE can consistently locate these MFAS bytes at each OTUk frame interval (with the correct and properly incrementing values), then it will remain in the LL-IM state.

However, if the Sink STE were to lose synchronization with the MFAS field (of each incoming OTUk frame) such that 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 pretty tolerant of bit-errors.  In other words, the presence of some 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 discuss the OTUk-dLOM Framing Alignment/Maintenance State Machine.

The OTUk-dLOM Framing Alignment/Maintenance State Machine

I present an illustration of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram, below in Figure 5.

dLOM Defect - OTUk-dLOM Frame Alignment/Maintenance Algorithm - with Criteria shown

Figure 5, Illustration 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 the following four states.

  • dLOM/LL-OOM State
  • dLOM/LL-IM State
  • In-Multiframe/LL-IM State
  • In-Multiframe/LL-OOM State

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 also show the underlying state-changes within the OTUk-MFAS OOF/IF State Machine.  I show this redrawn figure below in Figure 6.

dLOM Defect - OTUk-dLOM Frame Alignment/Maintenance State Machine - with Low-Level Terms

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 it starts to receive an OTUk data-stream and (once it has cleared the dLOF defect), then it will always be operating in one of these four states.  On occasion, the Sink STE will transition from one state to another.  As it does this, then it will either declare or clear the dLOM defect as we above in Figures 5 and 6.

We will now walk through the OTUk-dLOM Framing Alignment/Maintenace State Machine.

The dLOM/LL-OOM State

Whenever the System Operator first powers up the Sink STE, and it is just starting to receive an OTUk data-stream, the Sink STE will first clear the dLOF defect condition.  Afterward, it will be operating in the dLOM/LL-OOM State, as I show below in Figure 7.

dLOM Defect - dLOM-OTUk Framing Alignment/Maintenance State Machine Diagram - with dLOM/LL-OOM State Highlighted

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 the receive an OTUk data-stream (and has cleared the dLOF defect condition), it will be operating in the LL-OOM state.

What does it mean to be in the dLOM/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 it is 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:

  • The Sink STE is operating in the LL-OOM State (within the Lower-Level state machine, as we discussed earlier) and
  • The Sink STE is also declaring the dLOM defect condition (as the name of this state suggests).

Whenever the Sink STE is operating 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 is only receiving some stream of back-to-back OTUk frames that it cannot make much sense of.

While the Sink STE is operating in this state, it will parse through the incoming OTUk data-stream and look for 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 a full 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 New_Candidate_MFAS_Value fails the Test

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.

If the New_Candidate_MFAS_Value passes the Test

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.

The dLOM/LL-IM State

I show an illustration of the OTUk-dLOM Frame Alignment/Maintenance State-Machine diagram, with the dLOM/LL-IM State highlighted, below in Figure 8.

dLOM Defect - dLOM-OTUk Framing Alignment/Maintenance State Machine Diagram with dLOM/LL-IM State Highlighted

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, then we can state that the Sink STE has located (what appears to be) the MFAS-byte-field within the incoming OTUk data-stream.

NOTES:

  1. We refer to this state as the dLOM/LL-IM state, because the Sink STE is still declaring the dLOM defect condition (just as it was while it was operating in the dLOM/LL-OOM state).  However, the “LL-IM” portion of the state’s name (e.g., dLOM/LL-IM) reflects the fact that the Sink STE has transitioned into the LL-IM (Low-Level In-Multi-frame) state, within the lower-level state machine.
  2. I realize that calling this state the dLOM (Loss of Multi-Frame)/LL-IM (In-Multi-Frame) state is a bit of an oxymoron.  In this case, the Sink STE is in-multi-frame, in the sense that it has located the MFAS byte-field.  However, it is still declaring the dLOM defect condition.

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, there are two possible things that can happen from here.

  1. It can eventually transition (or advance) into the “In-Multi-Frame/LL-IM” state, or
  2. It can transition (or regress) back into the dLOM/LL-OOM state.

We will discuss each of these possible events below.

Advancing to the In-Multi-Frame/LL-IM State

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 properly locate the MFAS byte) then it will do all of the following:

  • It will transition into the “In-Multi-Frame/LL-IM” state, within the OTUk-dLOM Frame Alignment/Maintenance State Machine, and
  • It will clear the dLOM defect condition (e.g., dLOM ⇒ 0).

I will discuss the In-Multi-Frame/LL-IM State, later in this blog post.

Regressing to the dLOM/LL-OOM State

On the other hand, if the Sink STE (while operating in the dLOM/LL-IM state) were to lose synchronization with the MFAS byte, such that it could no longer 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.

The In-Multi-Frame/LL-IM State

Once the Sink STE has reached the In-Multi-frame/LL-IM state, then we can say that it is operating in the NORMAL (or intended) state.  We would expect the Sink STE to spend most of its operating lifetime, in this state.

I show an illustration of the OTUk-dLOM Framing Alignment/Maintenance State Machine Diagram, with the In-Multi-frame/LL-IM State highlighted, below in Figure 9.

dLOM Defect - OTUk-dLOM Framing Alignment/Maintenance State Machine Drawing with In-Multi-Frame/LL-IM State Highlighted

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 is operating in the In-Multi-frame/LL-IM state, then it is now able to locate the MFAS byte-fields within each incoming OTUk frame.

What all Does Clearing the dLOM Defect Mean?

This also means that the Sink STE should be ready to start evaluating other aspects of this incoming OTUk data-stream (that requires multi-frame alignment).  This includes extracting out the following types of data from the incoming OTUk/ODUk data-stream.

  • Within the OTUk Overhead
    • SM-TTI (Trail Trace Identification) Messages
  • Within the ODUk Overhead
    • PM-TTI Messages
    • APS/PCC Messages
  • Within the OPUk Overhead
    • PSI Messages

The MFAS byte is also critical for those applications in which we are mapping and multiplexing lower-speed ODUj signals into higher-speed ODUk 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 is operating in the In-Multi-frame/LL-IM state, then it is quite 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 effects 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).

As a consequence, 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.

The In-Multi-frame/LL-OOM State

I show an illustration of the OTUk-dLOM Frame Alignment/Maintenance State Machine diagram with the In-Multi-frame/LL-OOM State highlighted, below in Figure 10.

dLOM Defect - dLOM-OTUk Framing Alignment/Maintenance State Machine Drawing with In-Multi-Frame/LL-OOM State Highlighted

Figure 10, Illustration 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, then it means the following things.

  • The Sink STE has transitioned from the LL-IM state, into the LL-OOM state within the OTUk-MFAS OOM/IM Low-Level State Machine.
  • The Sink STE is still NOT declaring the dLOM (Loss of Multi-frame) defect condition (e.g., dLOM = 0).

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 it was 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 the fact that the Sink STE has transitioned into the LL-OOM state (within the Low-Level State Machine).

Whenever the Sink STE enters the In-Multi-frame/LL-OOM state, then only one of two possible things will happen.

  1. The Sink STE will eventually re-acquire synchronization with the incoming MFAS bytes (within the incoming OTUk data-stream), and it will advance back into the In-Multi-frame/LL-IM state or
  2. The Sink STE does not re-acquire synchronization with the incoming MFAS bytes (within the incoming OTUk data-stream), and it eventually regresses into the dLOM/LL-OOM state.

We will briefly discuss each of these two possible events below.

Advancing Back into the In-Multi-Frame/LL-IM State

If the Sink STE can locate and re-acquire the MFAS bytes (within the incoming OTUk data-stream), then 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).

Regressing to the dLOM/LL-OOM State

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), then it will transition into the dLOM/LL-OOM state.

Whenever the Sink STE transitions into the dLOM/LL-OOM state, then it will declare the dLOM defect condition (dLOM = 1).

In Summary

ITU-T G.798 requires that the Sink STE be able to locate the MFAS byte and to consistently remain in the LL-IM state for at least 3ms before it can clear the dLOM defect condition (e.g., dLOM ⇒ CLEARED).

Additionally, ITU-T G.798 also requires that the Sink STE NOT be able to locate the MFAS byte and to 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 both declaring and clearing the dLOM defect) to prevent intermittent transitions between the LL-OOM and LL-IM states from causing intermittent transitions (or chattering) in the dLOM state.

Table 1 presents a Summary of 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

ItemDescription
Meaning of the dLOM Defect ConditionThe 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 dLOMThe 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 dLOMThe 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 STEThe 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

Click on the Image Below to see More OTN-Related Blog 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

Declaring/Clearing the dLOF Defect

This post briefly describes the dLOF (Loss of Frame) Defect Condition. It describes when an OTN STE should declare and clear the dLOF defect condition.


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.

If you’re analyzing this topic from an ITU-T G.798 Atomic Function standpoint, then I will tell you that the two atomic functions, that are responsible for declaring and clearing the dLOF defect condition are:

Each of these atomic functions includes the dLOF Detection circuit.  However, if you take a close look 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 be referring to the entity that contains 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 that it is a lot simpler to use that word than to use the words:  OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions.  However, I will be using 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.

OTUk Frame Structure with the FAS Fields Highlighted

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

Now, since each OTUk frame is a 4080-byte column x 4-row structure, each of these frames 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 condition.

The dLOF-Related State Machines

Anytime the Sink STE is powered-up and is receiving a stream of OTUk data; it will always be operating in accordance with 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.

dLOF Defect State Machine Hierarchy

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.

dLOF Defect - Low-Level State Machine Diagram

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 that the System Operator powers up the Sink STE circuitry and feeds an OTUk data-stream to it (from the remote Source STE), then it will always be operating in one of these two states.

The Sink STE will (on occasion) need to transition from one state to the other and back.

We will discuss each of these two states below.

The LL-OOF State

Whenever the System Operator first powers up a Sink STE, and it starts to receive an OTUk data-stream (from the remote Source STE), it will be operating in the LL-OOF state.

At this point, the Sink STE has not located the FAS-bytes (and the OTUk frame boundaries).  Therefore, the Sink STE is not able to “make sense” out of any of this data at this time.

While the Sink STE is operating 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 specifically states that the Sink STE, whenever it is 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 a full 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, then 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, then ITU-T G.798 only requires that it 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, 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, then it will remain in the LL-IF state.

However, if 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, then the Sink STE function will transition back into the LL-OOF state.

NOTE:  The OTUk-FAS OOF/IF Low-Level State Machine algorithm is pretty tolerant of bit-errors.  In other words, the presence of some 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 finished our discussion of the OTUk-FAS OOF/IF Low-Level State Machine; let’s move on and discuss the OTUk-dLOF Framing Alignment/Maintenance State Machine.

The OTUk-dLOF Framing Alignment/Maintenance State Machine

Figure 4 presents an illustration of the OTUk-dLOF Framing Alignment/Maintenance State-Machine Diagram.

dLOF Defect - Overall State Machine Diagram - Using Criteria Terms

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.

dLOF Defect - Overall State Machine Diagram - Using Low-Level Terms

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 it starts to receive an OTUk data-stream, it will always be operating 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 we show above 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 it is just starting to receive an OTUk data-stream, it will initially be operating in the dLOF/LL-OOF State, as I show below in Figure 6.

dLOF Defect - OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram - dLOF/OOF State Highlighted

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 first power-up the Sink STE and 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 it is 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 is also declaring the dLOF defect condition (as the name of this state suggests).

Whenever the Sink STE is operating 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 is receiving 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 a full 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 show an illustration of the OTUk-dLOF Frame Alignment/Maintenance State-Machine diagram, with the dLOF/LL-IF State highlighted, below in Figure 7.

dLOF Defect - OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram - dLOF/IF State Highlighted

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, then we can state that the Sink STE has located (what appears to be) the FAS-fields within the incoming OTUk data-stream.

NOTES:

  1. 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 it was 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.
  2. 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, in the sense that 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).

Whenever the Sink STE is operating in this state, there are two possible things that can happen from here.

  1. It can eventually transition (or advance) into the “In-Frame/LL-IF” state, or
  2. 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 continue to properly locate the FAS bytes) 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, such that it could no longer locate the FAS bytes for at least five (5) consecutive OTUk frame periods, then 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, then we can say that it is operating in the NORMAL (or intended) state.  We would expect the Sink STE to spend most of its operating lifetime, in this state.

I show an illustration of the OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram, with the In-Frame/LL-IF State highlighted, below in Figure 8.

dLOF Defect - OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram - In Frame/IF State Highlighted

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, then it is now able to 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, and it can now begin to evaluate the OTUk data-stream for other defects or error conditions as well.

Of course, the Sink STE is telling the whole world this fact by clearing the dLOF defect condition.

Whenever the Sink STE is operating in the In-Frame/LL-IF state, then it is quite 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).

As a consequence, 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 show an illustration of the OTUk-dLOF Frame Alignment/Maintenance State Machine diagram with the In-Frame/LL-OOF State highlighted, below in Figure 9.

dLOF Defect - OTUk-dLOF Framing Alignment/Maintenance State Machine Diagram - In-Frame/OOF State Highlighted

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 it was 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 the fact that the Sink STE has transitioned into the LL-OOF state (within the Low-Level State Machine).

Whenever the Sink STE enters the In-Frame/LL-OOF state, then only one of two possible things will happen.

  1. 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
  2. The Sink STE does not re-acquire synchronization with the incoming FAS frames, and it 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), then it will transition into the dLOF/LL-OOF state.

Whenever the Sink STE transitions into the dLOF/LL-OOF state, then 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), then it will operate with the same frame-start location, that it had when it was operating in the In-Frame/LL-IF state.

In other words, the Sink STE will continue to look for the FAS-field in the same 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 to consistently remain in the LL-IF state for at least 3ms before it can clear the dLOF defect condition (e.g., dLOF ⇒ CLEARED).

Additionally, ITU-T G.798 also requires that the Sink STE NOT be able to locate the FAS field and to 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 both declaring and clearing the dLOF defect) to prevent intermittent transitions between the LL-OOF and LL-IF states from causing intermittent transitions (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).

ItemDescription
Meaning of dLOFThe 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 dLOFThe 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 dLOFThe 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.

Click on the Image Below to see More OTN-Related Blog 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

Declaring/Clearing dAIS Defect (OTUk)

This post describes how an OTN STE (Section Terminating Equipment) should declare and clear the dAIS Defect Condition (OTUk-AIS).

How Should an OTN STE Declare and Clear the dAIS Defect Condition (OTUk-AIS)?

In another post, we describe the OTUk-AIS Maintenance Signal.

However, in this post, we will discuss how an STE should declare and clear the dAIS (OTUk-AIS) defect condition.

NOTE:  Please do not confuse this particular dAIS Defect (in response to the detection of the OTUk-AIS Maintenance signal) with the other AIS Defect (in response to the detection of the ODUk-AIS Maintenance Signal).  Although their names are similar, they are very different defects.

In the OTUk-AIS Maintenance Signal Post, we state that the OTUk-AIS is an Unframed PN-11 Pattern.  More specifically, ITU-T G.709 defines this PN-11 sequence by the generating polynomial:  1 + x9 + x11.

How to Detect the PN-11 Pattern?

If we want to be able to detect, declare and also clear the dAIS condition, then we need to have some ability to detect this unframed PN-11 pattern.

Fortunately, the ITU-T Standard Committee did a lot of the work for us and defined such a circuit within ITU-T G.798.

I show this Inverse PN-11 Circuit, below in Figure 1.

Inverse PN-11 Detector - for dAIS (OTUk-AIS) Detection

Figure 1, Illustration of the Inverse PN-11 Circuit

How Does this Inverse PN-11 Circuit Work?

This Inverse PN-11 Circuit makes up a big part of our dAIS Detection Circuit (that we talk about in the post on the OTSi/OTUk_A_Sk atomic function).

The user should apply both the Recovered OTUk Data and Clock Signal at the IN and Clock inputs of our Inverse PN-11 Circuit, respectively.

If OTUk Data is carrying the OTUk-AIS Maintenance signal (e.g., the Unframed PN-11 signal) and if we are applying this data to the IN input (of our circuit), then our Inverse PN-11 circuit will generate an All-Zeros Pattern at the Node, that I’ve labeled OUT.

I show our Inverse PN-11 Circuit, again, below in Figure 2.  However, I also highlight these two reference points.

OTUk-AIS is applied to Inverse PN-11 Detector

Figure 2, Illustration of the Inverse PN-11 Circuit – with the Locations of the OTUk-AIS Maintenance Signal and the Resulting All-Zeros Pattern Highlighted.  

Now before we get too excited, we need to recognize that there are two conditions that will cause our Inverse PN-11 circuit to generate an All-Zeros Pattern at the OUT node.

  1. Our Inverse PN-11 Circuit will generate the All-Zeros pattern at the OUT Node, whenever the OTUk-AIS Maintenance Signal is present at the IN input (to this circuit), and
  2. Our Inverse PN-11 Circuit will also generate the AIl-Zeros pattern (at the OUT Node), whenever someone applies an All-Zeros Pattern at the IN Input.

OTUk-AIS Maintenance Signal or All-Zeros Pattern Signal at the IN input?

Hence, whenever we are checking for the OTUk-AIS Maintenance signal, we (of course) need to check the OUT Node (or our Inverse PN-11 Circuit).

However, we also need to check and make sure that we are NOT receiving an All-Zeros pattern at the IN input.

If we are TRUELY receiving the OTUk-AIS Maintenance Signal, then we will see an All-Zeros pattern at the OUT Node, while the signal, that is present, at the IN input is NOT an All-Zero pattern.

I summarize the relationship between the signals at the IN Input, and that at the OUT location, for various signal conditions, below in Table 1.

Table 1, A Truth-Table presenting the Relationships between the various signals at the IN input and the OUT Node.

IN InputOUT NodeComments
All-Zeros SignalAll-Zeros SignalAn All-Zeros pattern at the IN Input results in an All-Zeros pattern at the OUT Node.

No OTUk-AIS.
Ordinary OTUk TrafficNon All-Zeros Pattern SignalNormal Traffic Situation
OTUk-AIS Maintenance SignalAll-Zeros SignalThe Presence of an All-Zeros Signal at the OUT Node, and the Non All-Zeros pattern at the IN input indicates OTUk-AIS.

Criteria for Declaring the dAIS Defect?

OK, we now have a basic understanding of how the Inverse PN-11 circuit works.  We also know what signals to look for, to determine if the Inverse PN-11 is detecting the OTUk-AIS Maintenance signal.  Let’s now move on to the criteria for declaring dAIS.

When checking for dAIS, ITU-T G.798 recommends that we continuously monitor both of the signals at the  IN input signal and the OUT Node.

ITU-T G.798 goes on to (effectively) state, that we should continuously check these signals over a rolling 8192 bit-interval (or sliding window, if you will).

If our Inverse PN-11 circuit detects a set of three (3) consecutive strings each of 8192-bit periods (in length), such that BOTH of the following conditions are TRUE for each of these three 8192 bit-periods, then we MUST declare the dAIS defect condition.

  • The number of 1s bits at the OUT Node is less than 256; AND
  • the number of 1s bits at the IN Input is at 256 or more.

I show an illustration of the dAIS Defect Declaration Criteria, below in Figure 3.

dAIS Defect Declaration Criteria

Figure 3, Illustration of the dAIS (OTUk-AIS) Defect Declaration Criteria.

Criteria for Clearing the dAIS Defect Condition

On the other hand, while we are declaring the dAIS defect, and if our Inverse PN-11 circuit detects a set of three (3) consecutive strings, each of 8192-bit periods (in length) such that BOTH of the following conditions are TRUE for each of these three 8192 bit periods, then we MUST clear the dAIS defect condition.

  • If the number of 1s bits at the OUT Node is at 256 or greater, or
  • If the number of 1s bits at the IN input is less than 256 in three consecutive 8192-bit intervals.

I show an illustration of the dAIS Defect Clearance Criteria, below in Figure 4.

dAIS Defect Clearance Criteria

Figure 4, Illustration of the dAIS (OTUk-AIS) Defect Clearance Criteria. 

What Entities or Atomic Functions declare and clear the dAIS (OTUk-AIS) defect condition?

If you are analyzing some of the OTUk Atomic Function, then the OTSi/OTUk_A_Sk function contain the dAIS Defect Detection circuit.

NOTE:  For Multi-Lane Applications, the OTSiG/OTUk_A_Sk function does not check for the dAIS Defect condition.

The reason for this is that if an OTL3.4 or OTL4.4 signal were carrying the OTUk-AIS Maintenance Signal (which is an Unframed PN-11 Pattern), then the OTSiG/OTUk_A_Sk function would continuously declare the dLOFLANE defect condition within each of the 4 or 20 Logical Lanes and the dLOL defect as well.

In other posts, I will use the terms:  OTN STE (Section Terminating Equipment), or Sink STE.  With the exception of Multi-Lane Applications, these entities will also declare and clear the dAIS (OTUk-AIS) defect condition.

Click on the Image below to See More OTN-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