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

This post presents the 5th of the 7 Videos that covers training on the Peformance Monitoring of the ODUk Layer (for Non-Multiplexed Applications). This post focuses on the Sink Direction ODU-Layer Atomic Functions.

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

This blog post presents a video that continues our discussion of the ODUk_TT_Sk Atomic Function.  

This video covers the following features within the ODUk_TT_Sk Atomic Function.

  • How it declares and clears the dDEG (Path Signal Degrade) defect condition.
  • What the ODUk_TT_Sk function do with its AI_TSF Output pin whenever it declares a Service-Affecting defect condition.
  • What the ODUk_TT_Sk function do with its AI_TSD Output pin whenever it declares the dDEG (Signal Degrade) defect condition.  
  • Defect Correlation Equation Analysis
  • Consequent Equation Analysis 
  • Performance Monitoring Equation Analysis

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

OTN – Lesson 9 – Video 9 – OTUk_TT_Sk Function/Conclusion

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

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

This blog post contains a video that concludes our discussion of the OTUk_TT_Sk Atomic Function.  

In particular, this video discusses the following aspects of the OTUk_TT_Sk Function.

  • Defect Correlation Equations/Analysis
  • Consequent Equations/Analysis
  • Performance Monitoring Equations/Analysis

Finally, this video summarizes and wraps up the training/discussion of the OTUk_TT_Sk Atomic Function.

Continue reading “OTN – Lesson 9 – Video 9 – OTUk_TT_Sk Function/Conclusion”

OTN – Lesson 9 – Video 5 – Conclusion of OTSiG/OTUk_A_Sk Function

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

OTN – Lesson 9 – Video 5 – OTU Layer Sink Direction Circuitry/Functionality – Part 3

This blog post contains another video that focuses on (and wraps up our discussion on) the OTSiG/OTUk_A_Sk Atomic Function.  

This video serves as Part 3, within our Sink (or Receive) Direction Analysis of OTU-Layer Atomic functions.  This video is also the 5th of 11 videos within Lesson 9.  

We start out this video by reviewing the complete list of defects that the OTSiG/OTUk_A_Sk function declares and clears.  Afterward, I introduce you to the following:

  • The concept/purpose of Consequent Equations
  • A Review (and interpretation) of Consequent Equations for the OTSiG/OTUk_A_Sk Atomic Function.  
  • Introduction to Defect Correlation
  • A Review of the Defect Correlation Equations for the OTSiG/OTUk_A_Sk Atomic Function.
  • A Review of the Performance Monitoring Equations for the OTSiG/OTUk_A_Sk Atomic Function.  
  • A Final Summary of the OTSiG/OTUk_A_Sk Atomic Function.  

Continue reading “OTN – Lesson 9 – Video 5 – Conclusion of OTSiG/OTUk_A_Sk Function”

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