Tag: OTUk_TT_Sk Atomic Function

What is the OTUk-SMOH?

This blog post brief defines the term “Section Monitoring Overhead” (SMOH) for OTN Applications.

What Exactly is the OTUk-SMOH (Section Monitoring Overhead)?

Throughout much of this Blog, whenever I discuss Defects or Errors at the OTUk Layer, I usually mention the expression – OTUk-SMOH.

We have also referred to this same field as the Section Monitoring Overhead or SMOH.  Each term means the same things; I can use them interchangeably in this blog post.  

What exactly is the OTUk-SMOH?

SMOH is an abbreviation for Section Monitoring Overhead.

Figure 1 presents the location of the Section Monitoring (SM) Overhead within the OTU Frame.  

OTUk Framing Format - Identifying Section Monitoring field

Figure 1, Illustration of the OTU Overhead (within an OTU Frame) – with the Section Monitoring Overhead (or SM) Highlighted.

The SM field (or the Section Monitoring Overhead) is a three-byte field. If I were to take that SM field and zoom in on it (to take a closer look), I would have the image below in Figure 2.

Byte-Level View of the Section Monitoring Field

Figure 2, Close-Up Look at the SM (or Section Monitoring) field.

Figure 2 shows that the SM field consists of 3-byte fields.

  • TTI Byte-field
  • BIP-8 Byte field and
  • the SM Byte field.

What Are These Byte-Fields Within the SMOH?

Let’s go through and define these byte-fields and the role that they take in Section-Monitoring and Management.

What is the TTI Byte field?

I present an illustration of the SM field with the TTI Byte field Highlighted in Figure 3.

Section Monitoring Field with the TTI (Trail Trace Identifier) Byte-field highlighted

Figure 3, Illustration of the SM Field with the TTI Byte Highlighted

First, “TTI Byte” means Trail Trace Identifier Byte. The purpose of the TTI byte (within the OTUk-SMOH) is to transport the Trail-Trace Identifier Messages from a Source STE to a Sink STE. I show an illustration of the Source STE (STE # 1) transporting the TTI Message to the Sink STE (STE # 2) in Figure 4.

STE transporting a TTI Message to another STE

Figure 4, Illustration of a Network Consisting of an STE transmitting the TTI Message to another STE.

Figure 4 illustrates a network that consists of two (2) pieces of equipment:

  • STE # 1, and
  • STE # 2

I will briefly define and elaborate on these pieces of equipment.

STE # 1

This piece of equipment accepts an OTU4 signal (as an input) from the left-hand side (of the figure) and ultimately outputs an OTU4 single (at the other end of this equipment) out to STE # 2

STE # 2

This piece of equipment accepts an OTU4 signal (as an input) from STE # 1 and ultimately outputs an OTU4 signal (at the other end of this equipment) out to some off-page STE.

What is the TTI Message?

Without going into the details of the TTI Message (and what it means), we will, for now, say that this is a 64-byte message (16-byte SAPI, 16-byte DAPI, and 32 bytes Operator Specific) that uniquely identifies a particular STE (Section Terminating Equipment). Figure 5 presents the byte format of the TTI Message.

Byte Format of the SM-TTI Message - Showing Synchronization between TTI Message and the MFAS Byte

Figure 5, Illustration of the Byte Format of the TTI Message

In this figure, we show that the TTI Message is a 64-byte message that:

  • Consists of 16 bytes for the SAPI (Source Access Point Identifier)
  • 16 bytes for the DAPI (Destination Access Point Identifier), and
  • 32 bytes for the Operator Specific field.

I will define the SAPI and the DAPI in another post. Another point I will make in Figure 5 is that the transmission of TTI Messages is always synchronized with the MFAS byte-field.

For this blog post, I will say that a given STE (STE # 1 in this case) will use the 64-byte TTI Message to repeatedly identify itself to the other STE (STE # 2). STE # 1 will continually transmit these TTI messages to STE # 2. STE # 2 will ensure that it consistently receives an expected (and correct) TTI Message. In other words, STE # 2 will use these TTI Messages to check and verify that it is connected to the correct STE (STE # 1).

How Do We Use the TTI Bytes to Transport the TTI Messages?

Figure 5 shows that there are 64 bytes within each TTI Message. However, Figure 3 shows only one TTI byte within the SM field (hence, only one TTI byte within an entire OTU frame). Therefore, transporting a single 64-byte TTI message over an OTU Section requires that we transport 1 TTI byte at a time over a set of 64 OTU frames.

Further, Figure 5 shows that we will synchronize our transmission of these TTI bytes with the MFAS byte.

For example, whenever the 6-LSBs of the MFAS is set to [0, 0, 0, 0, 0, 0], then we will transport the very first TTI byte of the 64-byte TTI Message. Whenever the 6-LSBs of MFAS are set to [0, 0, 0, 0, 0, 1], then we will transport the second TTI byte of the 64-byte TTI message, and so on.

The Receiving STE (STE # 2) in Figure 4 will use this relationship between the LSBs of the MFAS byte to interpret the data it receives from the Transmitting STE (STE# 1) in this case.

If the Receiving STE receives an erred (or unexpected) value for the TTI Message, then that STE can declare the dTIM (Trail-Trace Identifier Mismatch) defect. We will discuss exactly how an STE declares and clears the dTIM defect in another post.

Clueless About OTN? We Can Help! Click on the Banner Below to Learn More!

Discounts Available for a Short Time

What is the SM-BIP-8 Byte-Field?

I present an illustration of the SM field with the BIP-8 Byte-field Highlighted in Figure 6.

Section Monitoring Field with the SM-BIP-8 Byte Highlighted

Figure 6, Illustration of the SM Field with the SM-BIP-8 Byte field highlighted.

The purpose of the BIP-8 Byte field is to permit the receiving STE to perform error checking (and reporting) on each OTU frame it receives.

Without going into many details, the transmitting STE will compute the value for the BIP-8 Byte (based upon the data within the OPU Payload of a given OTU frame).

Section Monitoring BIP-8 Calculation Region

Figure 7, OPU Payload Data that the Transmitting STE uses to Compute the SM-BIP-8 Value

The transmitting STE will then insert this BIP-8 Byte within the BIP-8 Byte (of a specific OTU frame).

Section Monitoring BIP-8 Calculation and Insertion Region

Figure 8, Transmitting STE inserting the SM-BIP-8 Value into a Specific Location within the OTU data stream.

The transmitting STE will then transmit this SM-BIP-8 value (along with the rest of the data within the SM field and the OTU data stream) to the remote receiving STE.

As this Receiving STE receives and accepts an OTU data stream, it also locally computes its own value for the SM-BIP-8 byte-field (based on the data within the OPU Payload). The Receiving STE will also read in the SM-BIP-8 value (the transmitting STE computed and inserted into the SM-byte within the OTU data stream).

If the Receiving STE determines that the SM-BIP-8 value (that it reads from the SM field within the OTU data-stream) matches that of its locally computed SM-BIP-8, then it will determine that the Receive STE received an OTU frame in an un-erred manner.

On the other hand, if the Receiving STE determines that the SM-BIP-8 value (that it reads from the SM-field within the OTU data-stream) differs from that within its locally computed SM-BIP-8 value, then it will determine that the Receive STE received some OTU data in an erred manner.

The SM-BIP-8 blog post presents a detailed discussion on how the Transmitting STE computes the SM-BIP-8 value and inserts it into the SM field within the OTU frame.

What is the SM Byte field (within the SM field)?

I present an illustration of the SM field with the SM Byte field Highlighted in Figure 7.

SM Field with the SM Byte Highlighted

Figure 7, Illustration of the SM-field with the SM-byte highlighted

However, if we were to take a closer look at the SM byte (within the SM-byte), we could see that the SM-byte would consist of multiple bit fields, as shown below in Figure 8.

Section Monitoring Byte with the SM-BEI field Highlighted

Figure 8, A Closer Look at the SM-byte-field within the SM-field

Figure 8 shows that the SM-byte consists of the following bit or nibble fields.

  • BEI/BIAE Nibble-Field
  • BDI bit-field
  • IAE bit-field
  • RES field (2 bits in width)

I will briefly define these nibble and bit-fields within the SM-byte field.

BEI/BIAE – Backward Error Indicator/Backward Input Alignment Error

The Backward Error Indicator is a four-bit field that reflects the number of SM-BIP-8 errors detected by a Receiving STE (and flagged) within the remote recently received OTU frame. If this nibble field contains a value of 0x00 to 0x08, it is transporting the BEI value for a given OTU frame. Please see the blog post on the SM-BEI nibble field to learn more about this topic.

On the other hand, if the BEI/BIAE contains the value of 0x0B, then this reflects a BIAE (Back Input Alignment Error) condition. Please see the blog post on IAE and BIAE defects to learn more about this topic.

BDI – Backward Defect Indicator bit-field

If the local receiving STE declares a service-affecting defect, it will set the BDI bit-field (that it sends out to the remote terminal) to “1”. On the other hand, if the local receiving STE does not declare a service-affecting defect, it will set the BDI bit-field (that it sends out to the remote terminal) to “0”.

Please see the blog post on the SM-BDI Indicator to learn precisely how this signaling scheme works in an OTU connection.

IAE – Input Alignment Error Bit-field

It Receiving STE detects a frame slip event (upstream) within the incoming OTU data stream, then will set this IAE bit-field to “1”.

Please see the blog post on IAE and BIAE defects to learn more about this topic.

Conclusion

I have briefly discussed the Section Monitoring Overhead within this blog post. This write-up was intended to be introductory and kept at a high (and simple) level. Please check out those individual blog posts for more details on how we compute specific SMOH fields. I did not want to repeat this detailed material (calculating the SM-BIP-8 value, the SM-BEI value, etc.) in this blog post.

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

This blog post presents a video that discusses the APS features within some of the Atomic Functions that we discussed in Lessons 9 and 10.

Lesson 12 – Video 12 – Detailed Implementation of APS within the Atomic Functions – Video 1

This blog post starts our discussion of the APS Features within various Atomic Functions. In this case, we will present how to implement Automatic Protection Switching in great detail. In particular, we will describe the following:

  • APS Features within the OTUk/ODUk_A_So and OTUk/ODUk_A_Sk functions (OTU-Layer/SNC/I Monitoring)
    • How do we implement the APS features within these Atomic Functions to support OTU-Layered SNC/I Monitoring and Protection-Switching?
    • How do we implement a complete System-Level design (using these atomic functions along with the OTUk_TT_So and OTUk_TT_Sk Atomic Functions)?
      • NOTE: We discussed these atomic functions in Lesson 9. However, we did not discuss the APS features (within those functions) then.
  • APS Features within the ODUkP/ODUj-21_A_So and ODUkP/ODUj-21_A_Sk functions (ODU-Layer/SNC/I Monitoring)
    • How do we implement the APS features within these Atomic Functions to support ODU-Layered SNC/I Monitoring and Protection-Switching?
    • How do we implement a complete System-Level design (using these atomic functions along with the ODUk_TT_So and ODUk_TT_Sk Atomic Functions)?
      • NOTE: We discussed these atomic functions in Lesson 10. However, we did not discuss the APS features (within those functions) then.
  • APS Features of the ODUkP/ODUj-21_A_So and ODUkP/ODUj-21_A_Sk functions (CL-SNCG/I Monitoring)
  • How do we implement the APS features within these Atomic Functions to support CL-SNCG/I Monitoring and Protection-Switching?
  • How do we implement a complete System-Level design (using these atomic functions along with the ODUk_TT_So and ODUk_TT_Sk Atomic Functions)?
    • NOTE: We discussed these atomic functions in Lesson 10. However, we did not discuss the APS features (within those functions) then.

Check Out the Video Below

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

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 8 – OTUk_TT_Sk Function

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

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

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

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

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

OTN – Lesson 9 – Video 7 – OTUk_TT_Sk Function

This post presents the 7th 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 7 – OTU Layer Sink Direction Circuitry/Functionality – Part 5

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

This blog post contains the 5th video that discusses the Sink (or Receive) Direction Atomic Functions at the OTU Layer.  This video is also the 7th of the 11 videos for Lesson 9.  

This video focuses on the following:

  • What is the CI_SSF input pin?
  • Near-End Error Checking  – SM-BIP-8 Verification
  • Sending SM-BEI Information based upon SM-BIP-8 Verification results.  
  • Far-End Error Checking – SM-BEI Monitoring
  • What does it mean to declare or clear the SM-BDI (or dBDI – Backward Defect Indicator) defect condition.  

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

What are Consequent Equations?

This post briefly defines and describes Consequent Equations that ITU-T G.798 uses for OTN Applications.

What are Consequent Equations, and How Should You Interpret Them?  

The purpose of this blog post is two-fold.

  • To describe the concept of Consequent Equations and
  • To discuss how we can use and interpret these Consequent Equations.

Introduction

Many ITU Standards (such as ITU-T G.798 for OTN Applications) will discuss many aspects of defects. These standards will define defects such as dAIS (Alarm Indication Signal) and dLOM (the Loss of Multi-frame).  

These same standards will also define the criteria that an OTN Network Element (be it an STE or PTE) should use to declare or clear a given defect.  

For example, ITU-T G.798 specifies all of the following defects that an OTN STE can declare and clear.

And that’s all well and good.  

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

How should an STE/PTE Respond Whenever it Declares a Defect?  

However, what else should an STE do whenever it declares (for example) the dLOF defect condition?  

Does this STE have a responsibility to notify other STEs of this defect?  

Similarly, what else should a PTE do whenever it declares (for example) the dTIM (ODUk-TIM) defect condition?  

Again, does this PTE have a responsibility to notify other nearby PTEs of this defect?

The short answer to both of these questions is, “Yes, for those specific defects that I mentioned, they do have a responsibility to notify upstream and downstream equipment of the occurrence of those defect conditions.”

However, to confuse things, the PTE/STE must notify upstream and downstream PTE/STE whenever some defects occur, but not others.  

How Do We Sort out This Confusion?  

The Answer:  Consequent Equations.  

Let’s assume that a certain STE is declaring the dLOF Defect condition, as shown below in Figure 1.

Consequent Equation - OTSi/OTUk_A_Sk function declares the dLOF defect

Figure 1, Illustration of the STE (e.g., the OTSi/OTUk-a_A_Sk Atomic Function) declares the dLOF defect condition.

What happens next?

At this point, let’s write down the Consequent Equation that pertains to this STE (or the OTSi/OTUk-a_A_Sk function in this case):

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

Where:

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

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

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

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

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

AI_TSF-P is the current (logical) state of the AI_TSF-P input pin (to the OTSi/OTUk-a_A_Sk atomic function).  

This consequent equation states that the STE (or OTSi/OTUk-a_A_Sk function) will assert its CI_SSF output pin anytime it declares any of the following defect conditions:

This consequent equation also states that the STE (the OTSi/OTUk-a_A_Sk function) will assert the CI_SSF output pin anytime the upstream atomic function asserts the AI_TSF input to this function.  

NOTE:  Please see the OTSi/OTUk_A_Sk Function Post for more information about this particular Atomic Function.  

So What Does All of This Mean?

In Figure 2, I show the OTSi/OTUk_A_Sk function now asserting its CI_SSF output pin because it is currently declaring the dLOF defect condition.  

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

Figure 2, Illustration of the OTSi/OTUk_A_Sk Atomic Function asserting its CI_SSF output because it is currently declaring the dLOF defect condition.  

Please note that the CI_SSF output (from the OTSi/OTUk_A_Sk function) is connected to the CI_SSF input of the (downstream) OTUk_TT_Sk function.  

OK, that’s great. The above Consequent Equation states that the STE (e.g., the OTSi/OTUk_A_Sk function will assert the CI_SSF output pin whenever it declares the dLOF defect.  

How does that alert any other STE/PTE of the OTSi/OTUk_A_Sk function declaring the dLOF defect?

Answer:  There is more to this, and it involves more Consequent Equations.  

Let’s Take a Look at the Downstream Circuitry

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

In Figure 3, I show the OTUk_TT_Sk and the OTUk/ODUk_A_Sk Atomic Functions. 

I also show that the upstream (OTSi/OTUk_A_Sk function) circuitry is now asserting the CI_SSF input (to the OTUk_TT_Sk function) – as we described above.  

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

Figure 3, Illustration of the OTUk_TT_Sk and OTUk/ODUk_A_Sk functions – with upstream circuitry asserting the CI_SSF input pin.

Now, the OTUk_TT_Sk Atomic Function happens to have two sets of Consequent Equations:

I will list each of these equations below.

  • aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))
  • aBDI <- CI_SSF or dAIS or dTIM

I will explain each of these equations below.  

The First Consequent Equation – OTUk_TT_Sk Function

Let’s start with the first Consequent Equation for the OTUk_TT_Sk function.

aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))

Where:

aTSF is the current state of the AI_TSF output of the OTUk_TT_Sk Atomic Function.

CI_SSF is the current state of the CI_SSF input of the OTUk_TT_Sk Atomic Function.  

dAIS is the current state of the dAIS defect condition, and 

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

This Consequent Equation states that the OTUk_TT_Sk Atomic Function should assert the AI_TSF output signal anytime it declares any of the following defect conditions.

  • dTIM – Trail Trace Identifier Mismatch Defect
  • dAIS – AIS Defect

This Consequent Equation also states that the OTUk_TT_Sk function should assert the AI_TSF output whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk function) asserts the CI_SSF input pin.  

In Figure 4, I show the OTUk_TT_Sk function asserting its AI_TSF output pin because the upstream OTSi/OTUk_A_Sk function is asserting the CI_SSF input pin (to this function).  

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

Figure 4, The OTUk_TT_Sk Atomic Function asserts the AI_TSF output pin because the upstream OTSi/OTUk_A_Sk function is asserting its CI_SSF input pin.  

OK, now let’s look at the second Consequent Equation for the OTUk_TT_Sk Function.

The Second Consequent Equation – OTUk_TT_Sk Function

aBDI <- CI_SSF or dAIS or dTIM

Where:  

aBDI is the state of the RI_BDI output (of the Remote Port Interface) of the OTUk_TT_Sk function.  

Earlier in this post, we have defined CI_SSF, dAIS, and dTIM.  

Therefore, this Consequent Equation states that the OTUk_TT_Sk function will assert the RI_BDI output pin anytime it declares the dAIS or dTIM defect conditions.

This equation also states that the OTUk_TT_Sk function will also assert the RI_BDI output pin anytime the upstream circuitry asserts the CI_SSF input (to the OTUk_TT_Sk function).  

If you recall from the OTUk_TT_So and OTUk_TT_Sk posts, I state that anytime the OTUk_TT_Sk function asserts the RI_BDI output pin, it will command its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back out to the remote end.

I show this phenomenon below in Figure 5.  

Consequent Equation - OTUk_TT_Sk function asserts RI_BDI due to CI_SSF

Figure 5, The OTUk_TT_Sk function asserts its RI_BDI output pin, commanding its Collocated OTUk_TT_So function to transmit the BDI (Backward Defect Indicator) back to the upstream STE because its CI_SSF is being driven HIGH.

Figure 5 shows that because the STE (OTSi/OTUk_A_Sk function) declared the dLOF defect, the downstream OTUk_TT_Sk function responded by commanding its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back to the upstream STE (the source of the defective OTUk signal).  

However, we’re not done yet.  

Since the OTUk_TT_Sk function is also asserting its AI_TSF output, it is also asserting the AI_TSF input to the (down-stream) OTUk/ODUk_A_Sk atomic function.  

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You to Become an Expert at OTN!!! Click Below to Learn More!!

Let’s move on to the OTUk/ODUk_A_Sk Atomic Function

As you can see in Figure 5, the OTUk_TT_Sk function, by asserting its AI_TSF output pin, is also asserting the AI_TSF input pin to the OTUk/ODUk_A_Sk function.  

And the OTUk/ODUk_A_Sk function comes with several Consequent Equations of its own.  

  • aSSF <- AI_TSF and (not MI_AdminState = LOCKED), and
  • aAIS <- AI_TSF and (not MI_AdminState = LOCKED)

Let’s take each of these equations, one at a time.

The First Consequent Equation – OTUk/ODUk_A_Sk Function

aSSF <- AI_TSF and (not MI_AdminState = LOCKED)

Where:  

aSSF is the current state of the CI_SSF output pin (from the OTUk/ODUk_A_Sk function).

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

MI_AdminState reflects the current state of the MI_AdminState input signal (which the System Operator can set).

This Consequent Equation states that the OTUk/ODUk_A_Sk function will automatically assert its CI_SSF output signal whenever the upstream circuitry asserts its AI_TSF input, provided that the System Operator has not put the OTUk/ODUk_A_Sk function into the LOCKED state.  

In Figure 6, I show the OTUk/ODUk_A_Sk function asserting its CI_SSF output pin because the upstream circuitry is asserting its AI_TSF input pin.  

Consequent Equations - OTUk/ODUk_A_Sk function asserts its CI_SSF output pin

Figure 6, The OTUk/ODUk_A_Sk function asserts its CI_SSF output pin because the upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF input pin.

I should also point out that APS (Automatic Protection Switching) systems often trigger (and start protection switching) whenever the OTUk/ODUk_A_Sk function asserts its CI_SSF output pin.  

Now, let’s move on to the next Consequent Equation.  

The Second Consequent Equation – OTUk/ODUk_A_Sk Function

aAIS <- AI_TSF and (not MI_AdminState = LOCKED)

Where:

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

If aAIS = TRUE, then the OTUk/ODUk_A_Sk function is overwriting its output signal with the ODUk-AIS Maintenance signal.

Conversely, if aAIS is FALSE, then the OTUk/ODUk_A_Sk function transmits an ODUk data stream, carrying regular client traffic.  

Therefore, this Consequent Equation states that the OTUk/ODUk_A_Sk function will transmit the ODUk-AIS Maintenance Signal anytime the upstream circuitry pulls its AI_TSF input TRUE; provided that the System Operator has NOT put the OTUk/ODUk_A_Sk function into the LOCKED State.

In Figure 7, I illustrate the OTUk/ODUk_A_Sk function transmitting the ODUk-AIS Maintenance Signal because upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF  input.  

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

Figure 7, The OTUk/ODUk_A_Sk function replaces the ODUk signal (carrying client data) with the ODUk-AIS Maintenance Signal whenever upstream circuitry asserts its AI_TSF input.  

So What Does All This Mean?

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

Then, we could state that if the OTN STE declares the dLOF defect (as we discussed earlier in this post), then that same OTN STE will do all of the following:

  • It will transmit the OTUk-BDI indicator back towards the upstream STE.
  • The OTN STE will also replace the missing (or defective) ODUk data stream (carrying client traffic) with the ODUk-AIS Maintenance Signal, and
  • It will also trigger APS (Automatic Protection Switching) activities by asserting the CI_SSF output (from the OTUk/ODUk_A_Sk function).  

I show a drawing of these actions below in Figure 8.

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

Figure 8, Illustration of the OTN STE responding to the dLOF Defect Condition

Conclusion

Thanks to Consequent Equations, we can define and predict how an OTN STE or PTE will respond to certain defects.

I have presented Consequent Equations in each post pertaining to OTN Atomic Functions.  

Clueless about OTN? We Can Help!! Click on the Banner Below to Learn More.

Discounts Available for a Short Time!!!

Click on the Image below to See More OTN- or Protection-Switching-Related Posts

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...
Read More
Protection-Switching Related Blog

Protection-Switching Related Blog Posts

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

What is the OTUk_TT_Sk Function?

This blog post briefly describes the OTUk_TT_Sk (OTUk Trace Termination Sink) Atomic function. This function will check for dDEG and dTIM defect conditions. It will also detect and flag SM-BIP-8 Errors.

What is the OTUk_TT_Sk Atomic Function?

We formally call the OTUk_TT_Sk Atomic Function the OTUk Trail Termination Sink function.

Introduction

The OTUk_TT_Sk function is any circuit that accepts an OTUk data stream from the upstream OTSi/OTUk_A_Sk function (for OTU1 and OTU2 applications) or the upstream OTSiG/OTUk_A_Sk function (for OTU3 or OTU4 applications) and extracts and processes the data within the OTUk Section Monitoring Overhead (OTUk-SMOH) from the incoming OTUk signal.

The OTUk_TT_Sk function will evaluate this data to check for various defects and errors.

NOTE:  I offer an extensive discussion of the OTUk_TT_Sk Atomic Function within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!

So What Does this Atomic Function Do?

If you recall, from our discussion of the OTUk/ODUk_A_So and OTUk_TT_So functions, those two particular functions will take an ODUk signal and work together to create an OTUk data stream with some newly computed OTUk-SMOH.

The OTUk_TT_So function will then route this OTUk data stream to the OTSi/OTUk-a_A_So (for OTU1/2 applications) or the OTSiG/OTUk-a_A_So functions (for OTU3/4 applications).

These functions will condition the OTUk signal for transport.  Next, one of these functions will route this OTUk signal through other circuitry that will convert this OTUk data stream into the optical format and transport this data stream over optical fiber.

A receiving Network Element will receive this optical signal and convert this data back into the electrical format.  This electrical signal will pass through the OTSi/OTUk-a_A_Sk atomic function (for OTU1/2 applications) or the OTSiG/OTUk-a_A_Sk atomic function (for OTU3/4 applications) before it finally reaches the OTUk_TT_Sk function.

I illustrate where the OTUk_TT_Sk function “fits in the big picture” below in Figure 1.

OTUk_TT_Sk Function Highlighted in Unidirectional OTUk End-to-End Connection

Figure 1, Illustration of Unidirectional Connection between a Source STE and a Sink STE with the OTUk_TT_Sk function highlighted.

Once this OTUk data arrives at the OTUk_TT_Sk function, it will perform the following tasks on this data stream.

Extracts and Processes the OTUk-SMOH within the incoming OTUk Data-Stream

The OTUk_TT_Sk function will accept this OTUk data stream and extract and process the OTUk-SMOH data from the incoming OTUk signal.  The OTUk_TT_Sk function will evaluate this data to check for various defects and errors.

In other words, the OTUk_TT_Sk function will evaluate the OTUk_SMOH (the OTUk_TT_So function, at the remote STE) created.  The OTUk_TT_Sk function will evaluate the OTUk-SMOH to check and see if it should declare certain types of defect conditions or if certain kinds of errors have occurred within this OTUk signal during transmission over optical fiber, as we describe below.

Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!

Corporate Discounts Available!!

Detect and Flag Defects and Errors within the Incoming OTUk Data-Stream

More specifically, the OTUk_TT_So function will check the following defect conditions for (and declare or clear).

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

Additionally, the OTUk_TT_Sk function will also detect and flag the following errors (within this OTUk data stream):

Some Details about the OTUk_TT_Sk Function

Figure 2 presents a simple illustration of the OTUk_TT_Sk function.

OTUk_TT_Sk Function - Trail Trace Atomic Function

Figure 2, Simple Illustration of the OTUk_TT_Sk Atomic Function

The Interfaces within the OTUk_TT_Sk Atomic Function

Figure 2 shows that this function consists of four different interfaces.

  • OTUk_TCP – The OTUk Termination Connection Point:  This is where the function user supplies data (which most likely came from an upstream OTSi/OTUk-a_A_Sk or OTSiG/OTUk-a_A_Sk function) to the OTUk_TT_Sk function.  This data will typically consist of the entire OTUk data stream (without the FEC, which was already decoded by the upstream OTSi/OTUk-a_A_Sk or OTSiG/OTUk-a_A_Sk function).
  • OTUk_AP – The OTUk Access Point:  This is where the function outputs OTUk data, clock, frame, and multi-frame signals (of the incoming OTUk data-stream) to downstream circuitry (towards the OTUk/ODUk_A_Sk function).
  • OTUk_TT_Sk_MP – The Function Management Point:  This interface permits the function-user to exercise control and monitor the activity within the OTUk_TT_Sk function.  Some information the user can obtain from the Management Point includes Performance Monitoring and Correlated Defect Identification.
  • OTUk_TT_RP – The Function Remote Point:  This interface permits the function-user to output some information to a collocated OTUk_TT_So function.  This information includes the BDI, BEI, and BIAE indicators.  The collocated OTUk_TT_So function will respond to this signaling (from the OTUk_TT_Sk function – via the RP port) by transmitting the BEI values, BDI, and BIAE indicators back out to the Remote STE, as appropriate.

A Closer Look at the Interfaces within the OTUk_TT_Sk Function.

We will now take a closer look at these interfaces below.

The OTUk_TCP (Termination Connection Point) Interface

The OTUk_TT_Sk function accepts an OTUk data stream from either the upstream OTSi/OTUk-a_A_Sk or OTSiG/OTUk-a_A_Sk function via the OTUk_TCP Interface.

The data that either the OTSi/OTUk-a_A_Sk or the OTSiG/OTUk-a_A_Sk function outputs are a full-blown OTUk frame (that has been descrambled) by those functions.

Figure 3 presents a functional block of the OTUk_TT_Sk function.

OTUk_TT_Sk Functional Block Diagram

Figure 3, Functional Block Diagram of the OTUk_TT_Sk Function

Finally, Figure 3 shows that the equipment that we connect to the OTUk_TCP (of the OTUk_TT_Sk function) will supply the following signals to this function.

  • CI_D
  • CI_CK
  • CI_FS
  • CI_MFS

The OTUk_TT_Sk function will perform the following operations on each OTUk frame within this signal.

  • OTUk-SMOH (Section Monitoring Overhead) Extraction
  • Compute and Verify the BIP-8 Value
  • Receive and Process TTI (Trail-Trace Identifier) Messages
  • Declares and clears the following defects (as appropriate)
    • dIAE – Will also be forward to the RI_BIAE output in the form of the BIAE indicator.
    • dTIM  – Will be reported via the RI_BDI output by way of the BDI signal and will also be notified via the AI_TSF output.
    • dDEG – will also be reported via the AI_TSD output
    • dBDI
    • dBIAE

The OTUk_TT_Sk_MP (Management Point) Interface

As the OTUk_TT_Sk function performs all of the above actions on the data (that it receives via the OTUk_TCP Interface), it will tally and report all of the following performance monitoring parameters to System Management (via the Management Interface).

  • Report and Tally the following errors
    • BIP-8 Errors– reported as nBIPV (to the RI_REI output) and as nN_B in performance monitoring.
    • BEI Count – reported as nF_B in Performance Monitoring
  • To provide Performance Monitoring reports on the following parameters to System Management

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Can Help You Become an Expert on OTN!! Click Below to Learn More!!

Discounts Available for a Short Time!!!

The OTUk_TT_Sk_RP (Remote Point) Interface

The OTUk_TT_Sk_RP Interface contains three (3) output ports that the System Designer should connect to the collocated OTUk_TT_So Atomic Function.

Whenever the user connects these three (3) output pins to similarly named pins at the collocated OTUk_TT_So function, these two functions will work together to transmit backward alarm and error information to the remote STE (the source of the OTUk data-stream that this OTUk_TT_Sk function is receiving).

Please click on the appropriate links to learn more about these backward (or far-end) indicators and how the OTUk_TT_Sk function accomplishes these forms of signaling with its collocated OTUk_TT_So function.

The OTUk_AP (Access Point) Interface (Output)

The OTUk_TT_Sk function will output the following signals via the OTUk_AP Interface.

  • AI_D – OTUk Adapted Information – Data Output
  • AI_CK – OTUk Adapted Information – Clock Output
  • AI_FS – OTUk Adapted Information – Frame Start Output
  • AI_MFS – OTUk Adapted Information – Multi-Frame Start Output
  • AI_TSF – OTUk Adapted Information – Trail Signal Fail (TSF) Indicator Output
  • AI_TSD – OTUk Adapted Information – Trail Signal Degrade (TSD) Indicator Output.

In most cases, the System Designer would route these output signals to the downstream OTUk/ODUk_A_Sk function for further processing.

AI_D, AI_CK, AI_FS, and AI_MFS will contain the remaining OTUk data-stream, clock, frame-start, and multi-frame start indicators for the OTUk/ODUk_A_Sk function.

Defect Notification – Downstream

The OTUk_TT_Sk function will assert the AI_TSF output pin anytime it declares a service-affecting defect (dTIM) itself or if the upstream circuitry (e.g., the OTSiG/OTUk-a_A_Sk or the OTSi/OTUk-a_A_Sk functions) are declaring service-affecting defects and asserting the CI_SSF input to this function.

Likewise, the OTUk_TT_Sk function will assert the AI_TSD output pin anytime it declares the dDEG (Signal Degrade) defect condition.

Consequent Actions

Consequent Action Equations specify what actions an Atomic Function should take any time (and for the duration) that it declares a certain defect.  ITU-T G.798 presents the following equations for consequent actions within the OTUk_TT_Sk function.

  • aTSF <- CI_SSF or [dTIM and (NOT TIMActDis)]
  • aBDI <- CI_SSF or dTIM
  • aBEI <- nBIPV
  • aBIAE <- dIAE
  • aTSD <- dDEG

I will discuss each of these consequent action equations below.

aTSF <- CI_SSF or [dTIM and (NOT TIMActDis)]

Where:  

aTSF is the Trail Signal Fail parameter that the OTUk_TT_Sk function will set LOW or HIGH to send current defect-state information towards downstream circuitry.

If aTSF = TRUE, then the OTUk_TT_Sk function will set its AI_TSF output HIGH.  Conversely, if aTSF = FALSE, then the OTUk_TT_Sk function will set its AI_TSF output to LOW.

CI_SSF is the current state of the CI_SSF (Server Signal Fail Indicator) input from the upstream OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic functions.  The OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk function will assert this signal anytime it declares a service-affecting defect.

dTIM is the current state of the dTIM defect condition.

TIMActDis is a parameter the user can set to configure the dTIM to (optionally) drive the aTSF parameter.

This equation means that the OTUk_TT_Sk function will assert an internal signal (we call aTSF) if either of the following conditions is true.

  • The upstream circuitry (e.g., the OTSiG/OTUk-a_A_Sk or the OTSi/OTUk-a_A_Sk function) is asserting the CI_SSF input to this function, or
  • The OTUk_TT_Sk function declares the dTIM defect condition.

NOTES:

  1. If the OTUk_TT_Sk function asserts the aTSF signal, it will indicate so by asserting the AI_TSF output pin towards downstream circuitry (e.g., the OTUk/ODUk_A_Sk function).
  2. The AI_TSF output signal is a crucial signal for Automatic Protection Switching purposes.
  3. Please see the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk posts for information on what causes these two functions to drive the CI_SSF signal HIGH.

aBDI <- CI_SSF or dTIM

This equation means that the OTUk_TT_Sk function will assert another internal signal (the aBDI signal) if either of the following conditions is true.

  • The upstream circuitry (e.g., the OTSiG/OTUk-a_A_Sk or the OTSi/OTUk-a_A_Sk function) is asserting the CI_SSF input to this function, or
  • The OTUk_TT_Sk function declares the dTIM defect condition.

NOTES:

  1. If the OTUk_TT_Sk function asserts the aBDI signal, it will indicate so by asserting the RI_BDI output pin (via the Remote Point Interface).  This signaling will command the collocated OTUk_TT_So function to set its BDI bit-field to TRUE within its next outbound OTUk frame.
  2. The OTUk_TT_Sk function will assert the RI_BDI and AI_TSF output pins under the same conditions.
  3. Please see the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk posts for information on what causes these two functions to drive the CI_SSF signal HIGH.

aBEI <- nBIPV

This equation means that the OTUk_TT_Sk function will automatically set the internal signal aBEI to the total number of BIP-8 errors detected within a given OTUk frame.  This means the OTUk_TT_Sk function can set aBEI to a value between 0 and 8 within each OTUk frame.

NOTE:  If the OTUk_TT_Sk function sets aBEI to a particular value, it will set the RI_BEI output pin (via the Remote Point Interface) to this same value.  This signaling will command the collocated OTUk_TT_So function to set its BEI nibble-field to this same value (aBEI), within its next outbound OTUk frame, provided that RI_BIAE is set FALSE.

aBIAE <- dIAE

This equation means that the OTUk_TT_Sk function will assert the internal signal, aBIAE, if it declares the dIAE (Input Alignment Error) defect condition.

NOTES:

  1. If the OTUk_TT_Sk function is asserting the aBIAE signal, it will indicate so by asserting the RI_BIAE output pin (via the Remote Point Interface).  This signaling will command the collocated OTUk_TT_So function to set the BEI/BIAE nibble-field to reflect the BIAE condition within its next outbound OTUk frame.
  2. The OTUk_TT_Sk function will NOT assert the AI_TSF or RI_BDI output signals because it declares the dIAE defect condition.

aTSD <- dDEG

This equation means that the OTUk_TT_Sk function will assert the internal signal aTSD anytime it declares the OTUk-dDEG (Signal Degrade) defect condition.

NOTES:

  1.   If the OTUk_TT_Sk function is asserting the aTSD condition, it will indicate so by asserting the AI_TSD output signal towards the downstream circuitry (e.g., the OTUk/ODUk_A_Sk function in this case).
  2. The OTUk_TT_Sk function will NOT assert the RI_BDI output signal because it declares the dDEG defect condition.

The AI_TSD output signal is an essential signal for Automatic Protection Switching purposes.

The OTUk_TT_Sk Function Pin Description

Table 1 presents a Description of each of the Input and Output pins of the OTUk_TT_Sk function.

Table 1, Pin Description of the OTUk_TT_Sk Atomic Function

Signal NameTypeDescription
OTUk_TCP Interface
CI_DInputOTUk Characteristic Information - Data Input:
The OTUk_TT_Sk function will accept this data from either the upstream OTSi/OTUk-a_A_Sk or OTSiG/OTUk-a_A_Sk function via this input pin. The OTUk_TT_Sk function will then perform the following actions on this data.
- It will extract out and process the SMOH (Section Monitoring Overhead) and
-- Compute and Verify the BIP-8 data and it will detect and flag any BIP-8 errors within each OTUk frame.
-- It will extract out the Section Monitoring Byte and check the state of the BDI and IAE bit-fields.
-- It will read in the value of the BEI/BIAE nibble field and check for the BIAE indicator.
-- It will also read in and tally all non-zero (and non-BIAE) BEI values and BIP-8 errors.
-- It will extract out the TTI message and compare this read-out value with that of the expected TTI Message.

As the OTUk_TT_Sk performs all of these tasks it will declare or clear the following defect conditions (as warranted).
- dBDI
- dTIM
- dIAE
- dBIAE
- dDEG

It will tally the following events for Performance Monitoring purposes.
- pIAE - Number of seconds in which the OTUk_TT_Sk function declared the dIAE defect.
- pN_BIAE - Number of seconds in which the OTUk_TT_Sk function declared the dBIAE defect.
- pN_EBC - Number of Near-End Errored Block Counts (BIP-8 Errors).
- pN_DS - Number of Defect Seconds (seconds in which the OTUk_TT_Sk (or upstream circuitry) declared certain near-end defect conditions.
- pF_EBC - Number of Far-End Errored Block Counts (BEI Count)
- pF_DS - Number of Far-End Defect Seconds (seconds in which the OTUk_TT_Sk function is declaring the dBDI defect condition).

The OTUk_TT_Sk function will sample this data on one of the edges of the CI_CK input clock signal.
CI_CKInputOTUk Characteristic Information - Clock Input:
The OTUk_TCP Interface will use this clock input signal to sample all of the following input signals.
- CI_D
- CI_FS
- CI_MFS
- CI_SSF

This clock signal also functions as the timing source of the OTUk_TT_Sk function.
CI_FSInputOTUk Characteristic Information - Frame Start Input:
The upstream circuitry should drive this input signal HIGH whenever it is applying the very first bit/byte of a new OTUk frame to the CI_D input.

The upstream circuitry should drive this input signal HIGH once for each incoming OTUk frame.
CI_MFSInputOTUk Characteristic Information - Multi-Frame Start Input:
The upstream circuitry should drive this input signal HIGH whenever it is applying the very frist bit/byte of a new OTUk superframe to the CI_D input.

The upstream circuitry should drive this input signal HIGH once for each incoming OTUk superframe (or once every 256 OTUk frames).
CI_SSFInputOTUk Characteristic Information - Server Signal Failure Indicator Input:
This input pin indicates whether or not the upstream circuitry is declaring a service-affecting defect with the OTUk data-stream (that it is applying to the CI_D input). These service-affecting defects include:
- dLOF
- dLOM
- dAIS (for OTU1 or OTU2 applications only).

This signal is functionally equivalent to the AIS indicator.

LOW - Indicates that the upstream circuitry is NOT declaring a service-affecting defect with the OTUk signal (being applied to the CI_D input).

HIGH - Indicates that the upstream circuitry IS declaring a service-affecting defect with the OTUk signal (being applied to the CI_D input).
OTUk_AP Interface
AI_DOutputOTUk Adapted Information - Data Output:
The OTUk_TT_Sk function will output the OTUk data, after it has passed through and been processed by this function. This data will typicallly be routed to the OTUk/ODUk_A_Sk function for further processing.

This data will be updated (and output) synchronously with the AI_CK clock output signal.
AI_CK OutputOTUk Adapted Information - Clock Output:
The OTUk_TT_Sk function will update/output signals via the OTUk_AP Interface on one of the edges of this clock output signal.
- AI_D
- AI_FS
- AI_MFS
- AI_TSF
- AI_TSD
AI_FSOutputOTUk Adapted Information - Frame Start Output:
The OTUk_AP Interface will drive this output signal HIGH whenever it is also driving the very first bit/byte of a new OTUk frame via this AI_D output.

The OTUk_AP Interface will drive this output HIGH once for each outbound OTUk frame.
AI_MFSOutputOTUk Adapted Information - Multiframe Start Output:
The OTUk_AP Interface will drive this output signal HIGH whenever it is also driving the very first bit/byte of a new OTUk superframe via the AI_D output.

The OTUk_AP Interface will drive this output HIGH once for each oubound OTUk superframe.
AI_TSF OutputOTUk Adapted Information - Trail Signal Fail Output Indicator Output:
The OTUk_TT_Sk function will indicate whether or not it is declaring the Trail-Signal Fail (TSF) condition. The OTUk_TT_Sk function will declare the TSF condition, if it also declares any of the following defect conditions.
- dTIM
- SSF (if the CI_SSF input was driven HIGH due to any of the following defects within the upstream circuitry).
-- dLOF
-- dLOM
-- dAIS (OTU1/OTU2 applications only).

LOW - Indicates that the OTUk_TT_Sk function is NOT currently declaring the TSF indicator.

HIGH- Indicates that the OTUk_TT_Sk function is currently declaring the TSF indicator.
AI_TSDOutputOTUk Adapted Information - Trail Signal Declared Indicator Output:
The OTUk_TT_Sk function will use this output signal to indicate if it is declaring the Trail-Signal Defect (TSD) Condition. The OTUk_TT_Sk function will declare the TSD condition if it also declares the dDEG (Signal Degrade) defect condition.

LOW - Indicates that the OTUk_TT_Sk function is NOT currently declaring the TSD indicator.

HIGH - Indicates that the OTUk_TT_Sk function is currently declaring the TSD indicator.
OTUk_RP Interface
RI_BEIOutputOTUk Remote Point Information - Backward Error Indicator:
As the OTUk_TT_Sk function computes and verifies the BIP-8 values (within the OTUk signal that it is receiving via the CI_D input), it will output date through this output to reflect the number of BIP-8 errors that it is declaring within each incoming OTUk frame. This output signal will be connected to the RP input of its collocated OTUk_TT_So function.

If the OTUk_TT_Sk detects ZERO BIP-8 errors within the most recently received OTUk frame, then it will set RI_BEI = 0 for that OTUk frame period.

Likewise, if the OTUk_TT_Sk function detects five (5) BIP-8 errors within the most recenlty received OTUk frame, then it will set RI_BEI = 5 for that OTUk frame period.
RI_BIAEOutputOTUk Remote Point Information - Backward Input Alignment Error Indicator:
If the OTUk_TT_Sk function declares the dIAE defect condition, then it will set the RI_BIAE indicator true. This output signal will be connected to the corresponding RP Input of the collocated OTUk_TT_So function.

The collocated OTUk_TT_So function is expected to overwrite the BEI nibble-field (within the next outbound OTUk frame).

Please see the OTUk_TT_So function post for more details on this topic).
RI_BDIOutputOTUk Remote Point Information - Backward Defect Indicator:
If the OTUk_TT_Sk function declares any of the following defect conditions, then it will set this output pin TRUE.
- dTIM
- CI_SSF

The user should connect this output signal to the RI_BDI input of the collocated OTUk_TT_So function.

The collocated OTUk_TT_So function is expected to set the BDI bit-field (within the Section Monitoring byte of the SMOH) to "1" within the next outbound OTUk frame, if this output pin is TRUE.

Otherwise, the OTUk_TT_So function should set the BDI bit-field to "0" within the very next outbound OTUk frame.
OTUk_TT_So_MP Interface
MI_AcTIOutputManagement Interface - Accepted Trail Trace identifier Message Output:
The OTUk_TT_Sk function will output the contents of the Accepted Trail Trace Identifier Message via this output signal.

The OTUk_TT_Sk function will output the accepted TTI Message via this output, whenever the user issues a command requesting this data via the MI_GetAcTI input.
MI_ExSAPIInputManagement Interface - Expected SAPI (Source Access Point Identifier) Input:

The OTUk_TT_Sk function will compare the SAPI-portion of the "Accepted Trail-Trace Identification" Message (that it receives from the SMOH (within the OTUk signal) with that which the user supplies to this input.

If the two values do not match, then the OTUk_TT_Sk function will declare the dTIM defect condition.
MI_ExDAPIInputManagement Interface - Expected DAPI (Destination Access Point Identifier) Input:
The function user is expected to apply the Expected Value of the DAPI portion of the Trail-Trace Identification Message.

The OTUk_TT_Sk function will compare the DAPI portion of the "Accepted Trail-Trace Identification" Message (that it received from the SMOH (within the OTUk signal) with that which the user supplies to this input.

If the two values do not match, then the OTUk_TT_Sk function will declare the dTIM defect condition.
MI_GetAcTIInputMangement Interface - Get Accepted Message Command Input:
This input permits the user to request that the OTUk_TT_Sk function provide the user with the currently "accepted" TTI Message. Whenever the user invokes this command, the OTUk_TT_Sk function will output the contents of the currently "accepted" TTI Message via the MI_ActTI output.
MI_TIMDetMoInputManagement Interface - TIM (Trace Identifier Mismatch) Detection Mode:
This input permits the user to specify which portion of the TTI Message that the OTUk_TT_Sk function should check and verify when checking for the dTIM defect condition. Please see the dTIM blog post for more details.
MI_cTIMOutputManagement Interface - Correlated TIM (Trail-Trace Identifier Mismatch) Defect:
This output signal indicates if the OTUk_TT_Sk function is declaring the dTIM defect condition.

LOW - Indicates that the OTUk_TT_Sk function is NOT currently declaring the dTIM defect condition.

HIGH - Indicates that the OTUk_TT_Sk function is currently declaring the dTIM defect condition.
MI_cDEGOutputManagement Interface - Correlated DEG (Signal Degrade) Defect:
This output signal indicates if the OTUk_TT_Sk function is declaring the dDEG defect condition.

LOW - Indicates that the OTUk_TT_Sk function is NOT currently declaring the dDEG defect condition.

HIGH - Indicates that the OTUk_TT_Sk function is currently declaring the dDEG defect condition.
MI_cBDIOutputManagement Interface - Correlated BDI (Backward Defect Indicator) Defect:
This output signal indicates if the OTUk_TT_Sk function is declaring the dBDI defect condition.

LOW - Indicates that the OTUk_TT_Sk function is NOT currently declaring the dBDI defect condition.

HIGH - Indicates that the OTUk_TT_Sk function is currently declaring the dBDI defect condition.
MI_cSSFOutputManagement Interface - Correlated SSF (Server Signal Fail) Defect:
This output signal indicates if the OTUk_TT_Sk function is declaring the SSF defect condition.

LOW - Indicates that the OTUk_TT_Sk function is NOT currently declaring the SSF defect condition. This also means that the upstream circuitry is currently drving the CI_SSF input pin LOW.

HIGH - Indicates that the OTUk_TT_Sk function is currently declaring the SSF defect condition. This also means that upstream circuitry is currently driving the CI_SSF input pin HIGH.
MI_pIAEOutputManagement Interface - IAE Performance Monitor Parameter:
The OTUk_TT_Sk function will drive this output pin HIGH, for one full second, if it has declared the dIAE defect for any portion of the previouis one-second period.

Conversely, the function will keep this output pin LOW, for one full second, if it has NEVER declared the dIAE defect, during the previous one-second period.

This one second period will be dictated by the 1-Second Clock signal that the user supplies to the MI_1Second input to this function.
MI_pBIAEOutputManagement Interface - BIAE Performance Monitor Parameter:
The OTUk_TT_Sk function will drive this output pin HIGH for one full second, if it has declared the dBIAE defect for any portion of the previous one second period.

Conversely, the function will keep tis output pin LOW for one full second, if it has NEVER declared the dBIAE defect, during the previous one second period.

This one second period will be dictated by the 1 Second Clock signal that the user supplies to the MI_1Second input to this function.
MI_pN_EBCOutputManagement Interface - Number of Near-End Errored Block Count (BIP-8 Errors) - One Second Performance Monitoring Parameter:
The OTUk_TT_Sk function will tally and report the total number of BIP-8 errors, that it has detected and flagged (within the incoming OTUk data-stream), during the previous 1 second period.
MI_pN_DSOutputManagement Interface - Near-End Defect - One Second Performance Monitoring Parameter:
The OTUk_TT_Sk fuinction will drive this output pin HIGH for one full second, if it has declared at least one of the following defects for any portion of the previous one-second period.
- CI_SSF or
- dTIM

Conversely, the function will keep this output pin LOW, for one-full second, if it has NEVER declared any of these defect during the previous one-second period.

This one-second period will be dictated by the 1 Second Clock signal that the user supplies to the MI_1Second input to this function.
MI_pF_EBCOutputManagement Interface - Number of Far-End Errored Block Count (BEI Errors) - One Second Performance Monitoring Parameter:
The OTUk_TT_Sk function will tally and report the total number of BEI counts that it has read and captured (within the incoming OTUk data-stream) during the previous one-second period.
MI_pF_DSOutputManagement Interface - Far-End Defect - One Second Performance Monitoring Parameter:
The OTUk_TT_Sk function will drive this output pin HIGH, for one full second, if it has declared the dBDI defect for any portion of the previous one-second period.

Conversely, this function will keep this output pin LOW, for one-full second, if it has NEVER declared the dBDI defect, during the previous one-second period.
MI_1SecondInputManagement Interface - One Second Clock Input:
The user is expected to supply a clock signal, which has a frequency of 1Hz, to this input.

The Performance Monitoring portino of the OTUk_TT_Sk function will use this clock signal as its timing reference for tallying and reporting the various one-second Performance Monitoring parameters.
MI_DEGThrInputManagement Interface - The dDEG BIP-8 Error Threshold for a Bad One-Second Interval:
The user can specify the BIP-8 error threshold for which the OTUk_TT_Sk function should count a given one second period as a "Bad One-Second" period, for the sake of dDEG declaration.

If the OTUk_TT_Sk function detects DEGThr or more BIP-8 errors, during a one-second interval, then the OTUk_TT_Sk function will count that one-second interval as a "Bad" interval.

If the OTUk_TT_Sk function detects less than DEGThr BIP-8 errors, during a one-second interval, then the OTUk_TT_Sk function will NOT count that one-second as a "Bad" interval.
MI_DEGMInputManagement Interface - Number of "Bad One-Second" Intervals for dDEG Declaration:
The user can specify the minimum number of consecutive "Bad One Second" intervals that the OTUk_TT_Sk function must detect before declaring the dDEG defect condition.

If the OTUk_TT_Sk function detects and flags DEGM consecutive "Bad One-Second" Intervals, then the OTUk_TT_Sk function will declare the dDEG defect condition.

NOTE: DEGThr defines the threshold for a "Bad One-Second" interval.

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You to Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

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 an Atomic Function for OTN?

This post briefly introduces the concept of the Atomic Functions that ITU-T G.798 uses to specify the Performance Requirements of OTN systems.


What is an Atomic Function for OTN Applications?

If you have read through many of the ITU standards, particularly those documents that discuss the declaration and clearance of defect conditions, you have come across Atomic Functions.

For OTN applications, ITU-T G.798 is the primary standard that defines and describes defect conditions.

If you want to be able to read through ITU-T G.798 and have any chance of understanding that standard, then you will need to understand what these atomic functions are.

I will tell you that you will have a tough time understanding ITU-T G.798 without understanding these atomic functions.

Therefore, to assist you with this, I will dedicate numerous blog postings to explain and define many of these atomic functions for you.

NOTE:  I also cover these Atomic Functions extensively in Lesson 8 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

OK, So What are these Atomic Functions?

You can think of these atomic functions as blocks of circuitry that do certain things, like pass traffic, compute and insert overhead fields, check for, and declare or clear defects, etc.

These atomic functions are theoretical electrical or optical circuits.  They have their own I/O, and ITU specifies each function’s functional architecture and behavior.

It is indeed possible that a Semiconductor Chip Vendor or System Manufacturer could make products that exactly match ITU’s descriptions for these atomic functions.  However, no Semiconductor Chip Vendor nor System Manufacturer does this.  Nor does ITU require this.

ITU has defined these Atomic Functions such that anyone can judiciously connect a number of them to create an Optical Network Product, such as an OTN Framer or Transceiver.

However, if you were to go onto Google and search for any (for example) OTUk_TT_Sk chips or systems on the marketplace, you will not find any.  But that’s fine.  ITU does not require that people designing and manufacturing OTN Equipment make chips with these same names nor have the same I/O as these Atomic Functions.

OK, So Why bother with these Atomic Functions?

The System Designer is not required to design a (for example) OTUk_TT_Sk function chip.  They are NOT required to develop chips with the same I/O (for Traffic Data, System Management, etc.).

However, if you were to design and build networking equipment that handles OTN traffic, you are required to perform the functions that ITU specified for these atomic functions.

For example, if you design a line card that receives an OTUk signal and performs the following functions on this signal.

  • Checks for defects and declare and clear them as appropriate, and
  • Monitors the OTUk signal for bit errors and
  • Converts this OTUk signal into an ODUk signal for further processing

Although you are NOT required to have OTUk_TT_Sk and OTUk/ODUk_A_Sk atomic function chips sitting on your line card, you are required to support all of the ITU functionality defined for those functional blocks.

Therefore, you must understand the following:

  1. Which atomic functions apply to your system (or chip) design, and
  2. What are the requirements associated with each of these applicable atomic functions?

If you understand both of these items, you fully understand the Performance Monitoring requirements for your OTN system or chip.

What type of Atomic Functions does ITU-T G.798 define?

ITU-T G.798 defines two basic types of Atomic Functions:

  • Adaptation Functions and
  • Trail Termination Functions

I will briefly describe each of these types of Atomic Functions below.

Adaptation Functions

Adaptation Functions are responsible for terminating a signal at a particular OTN or network layer and then converting that signal into another OTN or network layer.

For example, an Adaptation function that we discuss in another post is a function that converts an ODUk signal into an OTUk signal (e.g., the OTUk/ODUk_A_So function).

Whenever you read about atomic functions (in ITU-T G.798), you can also tell that you are dealing with an Adaptation atomic function if you see the upper-case letter A within its name.

For example, I have listed some Adaptation functions that we will discuss within this blog below.

  • OTSi/OTUk-a_A_So – The OTSi to OTUk Adaptation Source Function with FEC (for OTU1 and OTU2 Applications)
  • OTSi/OTUk-a_A_Sk – The OTSi to OTUk Adaptation Sink Function with FEC (for OTU1 and OTU2 Applications)
  • OTSiG/OTUk-a_A_So – The OTSiG to OTUk Adaptation Source Function with FEC (for OTU3 and OTU4 Applications)
  • OTSiG/OTUk-a_A_Sk – The OTSiG to OTUk Adaptation Source Function with FEC (for OTU3 and OTU4 Applications)
  • OTUk/ODUk_A_So – The OTUk to ODUk Adaptation Source Function
  • OTUk/ODUk_A_Sk – The OTUk to ODUk Adaptation Sink Function
  • ODUkP/ODUj-21_A_So – The ODUkP to ODUj Multiplexer Source Atomic Function
  • ODUkP/ODUj-21_A_Sk – The ODUkP to ODUj Multiplexer Sink Atomic Function

Another Way to Identify an Adaptation Function?

ITU in general (and indeed in ITU-T G.798) will identify the Adaptation Function with trapezoidal-shaped blocks, as shown below in Figure 1.

OTUk/ODUk_A_Sk Function - Adaptation Atomic Function

Figure 1, A Simple Illustration of an Adaptation Function (per ITU-T G.798)

Now that we’ve briefly introduced you to Adaptation Functions let’s move on to Trail Termination Functions.

Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!

Corporate Discounts Available!!!

Trail-Termination Functions

Trail Termination functions are typically responsible for monitoring the quality of a signal as it travels from one reference point (where something called the Trail Termination Source function resides) to another reference point (where another thing is called the Trail Termination Sink function lies).

When you read about atomic functions (in ITU-T G.798), you can also tell that you are dealing with a Trail Termination atomic function if you see the upper-case letters TT within its name.

The Trail Termination functions allow us to declare/clear defects and flag/count bit errors.

I’ve listed some of the Atomic Trail-Termination Functions we will discuss in this blog below.

  • OTUk_TT_So – The OTUk Trail Termination Source Function
  • OTUk_TT_Sk – The OTUk Trail Termination Sink Function
  • ODUP_TT_So – The ODUk Trail Termination Source Function (Path)
  • ODUP_TT_Sk – The ODUk Trail Termination Sink Function (Path)
  • ODUT_TT_So – The ODUk Trail Termination Source Function (TCM)
  • ODUT_TT_Sk – The ODUk Trail Termination Sink Function (TCM)

Another way to Identify a Trail-Termination Function?

In general (and indeed in ITU-T G.798), ITU will identify Trail Termination Function with triangular-shaped blocks.  I show an example of a drawing with a Trail-Termination below in Figure 2.

OTUk_TT_Sk Function - Trail Trace Atomic Function

Figure 2, A Simple Illustration of a Trail Termination Function (per ITU-T G.798)

We will discuss these atomic functions in greater detail in other posts.

 

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You to Become an Expert on OTN!!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

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 OTUk-BIP-8 or SM-BIP-8?

This post describes the OTUk-BIP-8 (or Section Monitoring BIP-8) value for OTN applications. This post also describes how Networking Equipment both computes and transports this data over a fiber optic connection, as well as how Networking Equipment checks and identifies data transmission errors through the SM-BIP-8 parameter.


What is the OTUk-BIP-8 or Section Monitor (SM-BIP-8) Parameter, and How Do We Compute and Verify it?

This post will define and describe the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bit) parameter.

  • In particular, we will describe how the OTN uses this parameter to perform error detection at the OTUk layer.
  • Secondly, we will describe how a Transmitting OTUk Network Element (or a Source Section Terminating Equipment) computes and inserts the SM-BIP-8 Value into the OTUk data stream.
  • Third, we will describe how a Receiving OTUk Network Element (or a Sink Section Terminating Equipment) computes and verifies the SM-BIP-8 Value to check for data transmission errors.
  • Finally, we will discuss the results that a Receiving OTUk Network Element will come up with whenever it does compute and verify the SM-BIP-8 byte value.

NOTES: 

  1. From this point on, I will refer to the Transmitting OTUk Network Element as the Source STE (or Section Terminating Equipment).  I will also refer to the Receiving OTUk Network Element as the Sink STE.
  2. We discuss the SM-BIP-8 field extensively in Lesson 9 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

Introduction

For OTN applications, the OTUk layer supports Error Detection and Correction through two means.

  • FEC – Forward Error Correction and
  • BIP-8 – Bit Interleaved Parity – 8 bits

FEC is an Error Detection and Error-Correction scheme discussed in another post.

BIP-8 is purely an error-detection scheme.  It does not support any error correction capabilities.

The OTUk, ODUk, and Tandem Connection Monitoring layers use the BIP-8 error detection scheme.

In this post, we will discuss (what we call) the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bits) scheme for the OTUk layer.

NOTE:  We refer to this error detection scheme as SM-BIP-8  (Section Monitoring – Bit Interleaved Parity – 8 bits) because this is the detection scheme that OTN Equipment would employ over a Section via STE (or Section Terminating Equipment).

Please see the post on Section Terminating Equipment for more information on this.

In another post, we discuss the PM-BIP-8 (Path Monitoring – Bit Interleaved Parity – 8 bits) scheme for the ODUk layer.

NOTE:  In this post, we will interchangeably use the terms BIP-8, OTUk-BIP-8, and SM-BIP-8.

So How does the OTN use the SM-BIP-8 scheme?

In every connection between any two adjacent pieces of Networking Equipment, there is an entity that transmits data (e.g., the Source STE), and there is also an entity that receives that data (e.g., the Sink STE).

In most cases, two adjacent pieces of Networking Equipment will also be communicating with each other in a bi-directional manner.

This means that every piece of Network Equipment will transmit and receive data.  This also means that every piece of Network Equipment will contain both a Source STE and a Sink STE.

For OTN application, any time a Source STE transports data to another Network Element via optical fiber or a copper medium, it must encapsulate this data into a series of back-to-back OTUk frames.

Please see the post on OTUk frames to learn more about the OTUk frame structure.

Brief Overview – How the Source STE creates and transports the SM-BIP-8 Byte Value

As the Source STE encapsulates its outbound (client and ODUk) data into a series of OTUk frames, it will perform various functions.

  • It will compute and append the FEC field to the back-end of each outbound OTUk frame.
  • It will compute and insert the SMOH (Section Monitoring Overhead) into each outbound OTUk frame.  In particular, the Source STE will
    • Insert the Trail Trace Message bytes into the TTI byte-field
    • Set the BDI (Backward Defect Indicator) and IAE (Input Alignment Error) bit-fields to the appropriate values (depending upon Network Conditions)
    • Set the BEI/BIAE nibble-field to the appropriate Value (depending upon Network Conditions).

Finally, the Source STE will compute an SM-BIP-8 value for each outbound OTUk frame.

Whenever the Source STE computes the SM-BIP-8 byte value, it will do so by performing a specific type of parity calculation over much of the data within the OTUk frame.

Afterward, the Source STE will insert this SM-BIP-8 byte value into the SMOH (Section Monitoring Overhead) within each outbound OTUk frame.

The Source STE will transport this data (e.g., the OTUk frame data and the SM-BIP-8 Value) over optical fiber to the remote Sink STE.

Brief Overview – How the Sink STE Receives and Processes the SM-BIP-8 byte Values

The Sink STE will accept and process this continuous stream of incoming OTUk frames that it is receiving from the remote Source STE.

As it processes this OTUk data stream, it will verify the SM-BIP-8 byte value within each OTUk frame it receives from the (Remote) Source STE.

The Sink STE verifies this data to check for any transmission errors that might have occurred as these OTUk frames travel from the (Remote) Source STE to the (Near-End) Sink STE.

As the Sink STE verifies this data, it will perform the same parity calculations on the data within the OTUk frames as the (remote) Source STE.

Afterward, the Sink STE will compare its “Locally-Computed” SM-BIP-8 byte value with that computed by the (remote) Source STE.

If the two values for the SM-BIP-8 byte match, then we can state that the Sink STE received the corresponding OTUk frame error-free.

On the other hand, if the two values for SM-BIP-8 do not match, then we know that the Sink STE has detected at least a one-bit error within this particular OTUk frame.

The Details – How does the Source STE generate the SM-BIP-8 Value?

Now that we have the Brief Introductory material out of the way, let’s discuss this in greater detail.

In this section, we will describe the following:

  • Exactly how the Source STE computes the SM-BIP-8 byte value, and
  • How it inserts this SM-BIP-8 byte into the OTUk data-stream, as it transmits this data to the remote Sink STE.  

The Source STE and Introduction to the OTUk_TT_So Atomic Function

ITU-T G.798 refers to the Source STE, which is responsible for (among other things) computing and inserting the SM-BIP-8 Value into the OTUk SMOH as the OTUk_TT_So (OTUk Trail Termination Source) atomic function.

Please see the post on the OTUk_TT_So function to learn more about this atomic function.

NOTE:  We will use the terms Source STE and the OTUk_TT_So function interchangeably throughout this post.

How do we perform a BIP-8 (Bit Interleaved Parity – 8 Bit) Calculation?

The OTUk_TT_So function will compute the SM-BIP-8 Value (for a given OTUk frame) over the data that resides within the OPU portion of that outgoing OTUk frame (e.g., byte-columns 15 through 3824).

Figure 1 presents an illustration that identifies that portion of the OTUk frame that the OTUk_TT_So function will use to perform the BIP-8 Calculations.

Section Monitoring BIP-8 Calculation RegionFigure 1, Illustration of that portion of the OTUk frame, which the OTUk_TT_So function will use for the Section Monitoring BIP-8 Calculation  

NOTE:  The OTUk_TT_So function will also include the OPU Overhead within these BIP-8 calculations.

This also means that the OTUk_TT_So function will compute the BIP-8 Value (4 x 3,810 =) 15,240 bytes within each outbound OTUk frame.

The OTUk_TT_So function will compute the BIP-8 Value over this 15,240-byte structure by effectively stacking all 15,240 bytes in a single byte-wide column, similar to what we show below in Figure 2.

Section Monitoring - OTUk BIP-8 Calculation Procedure

Figure 2, Illustration of How the OTUk_TT_So function computes the BIP-8 Value

Figure 2 shows that the OTUk_TT_So function has (effectively) created a 15,240 row by an 8-bit column data structure.

The OTUk_TT_So function will then parse through each of the 8-bit columns within this data structure and compute the EVEN parity value for each of these bit-columns (over 15,240 bits).

Since there are 8-bit columns, the OTUk_TT_So function will compute eight individual EVEN parity bits (one for each bit-column).

This resulting set of the 8 EVEN parity bits is the SM-BIP-8 byte value for this particular OTUk frame.

This procedure describes how we perform a BIP-8 calculation over a block of data (such as the OPUk-portion of an OTUk frame).

How does one Source STE transport the SM-BIP-8 to another Network Element?

The OTUk_TT_So function will then take this BIP-8 byte value and insert it into the SM-BIP-8 byte field within the Section Monitoring field of the outbound OTUk frame, two frame periods later, as we show below in Figure 3.

Section Monitoring BIP-8 Calculation and Insertion Region

Figure 3, Illustration of How the OTUk_TT_So function inserts the SM-BIP-8 byte values into the OTUk data-stream  

The OTUk_TT_So function adds this 2-frame delay to give the Sink STE (at the remote terminal) enough time to compute and verify the SM-BIP-8 byte value (at its end).

Figures 4 and 5 together present the exact location of the SM-BIP-8 byte-field within each outbound OTUk frame.

Figure 4 illustrates the OTUk frame format, with the Section Monitoring (SM) field highlighted.

Location of Section Monitoring Field within OTUk Frame

Figure 4, Illustration of the OTUk Frame with the Section Monitoring (SM) field highlighted

And Figure 5 presents an illustration of the Section Monitoring (SM) field with the SM-BIP-8 byte-field highlighted.

Location of BIP-8 Byte within Section Monitoring Field

Figure 5, Illustration of the Section Monitoring (SM) field, with the BIP-8 byte-field highlighted

The OTUk_TT_So function will transmit this OTUk data stream (along with the locally-computed SM-BIP-8 byte value) to the remote terminal equipment.

We will discuss below how the Remote Sink STE receives and processes these OTUk frames and their SM-BIP-8 values.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

What does the Sink STE do with the SM-BIP-8 Value?

The Sink STE performs the exact opposite role, as does the Source STE.

The Sink STE and Introduction to the OTUk_TT_Sk atomic function

ITU-T G.798 refers to the entity that (among other things) computes and verifies the SM-BIP-8 byte values (for each OTUk frame) as the OTUk_TT_Sk (OTUk Trail Termination Sink) atomic function.

Please see the post on the OTUk_TT_Sk function to learn more about this atomic function.

NOTE:  We will use the terms Sink STE and OTUk_TT_Sk function interchangeably throughout the remainder of this post.

I stated earlier that the OTUk_TT_Sk function has the exact opposite role, as does the OTUk_TT_So function.

The OTUk_TT_Sk function verifies the SM-BIP-8 byte value for each OTUk frame it receives from the remote Source STE (OTUk_TT_So Function).

Once again, the purpose of having the OTUk_TT_Sk function check and verify the SM-BIP-8 byte values is to check for the occurrence of bit errors within the OTUk data stream as it travels from the OTUk_TT_So function (within the Source STE), across optical fiber, to the OTUk_TT_Sk function (within the Sink STE).

Figure 6 presents a simple illustration of an OTUk_TT_So function transporting this OTUk data stream to the OTUk_TT_Sk function at the remote terminal.

OTUk_TT_So to OTUk_TT_Sk unidirection connection

Figure 6, Illustration of the OTUk_TT_So function transporting an OTUk data-stream to the OTUk_TT_Sk function (at the remote terminal)

For your reference,  the circuitry (that I show above) in Figure 6 is functionally equivalent to the Network Element connections I show below in Figure 7.

Basic Network Element WEST connected to Network Element EAST bidirectionally over Fiber Optic connection

Figure 7, Illustration of the Equivalent Circuitry (in Figure 6), expressed at the Network Element Layer.  

We will describe how the OTUk_TT_Sk function computes and verifies the SM-BIP-8 byte value within each incoming OTUk frame.

The OTUk_TT_Sk function computes and verifies these SM-BIP-8 byte values by executing the following two steps to process each OTUk frame it receives.  

  • Step 1 – The OTUk_TT_Sk function will locally compute its SM-BIP-8 byte value for an incoming OTUk frame, and 
  • Step 2 – The OTUk_TT_Sk function will then compare its locally-computed BIP-8 byte value with that which the OTUk_TT_So function (at the Remote STE) inserted into the SM-BIP-8 byte field within the incoming OTUk data-stream.

We will discuss each of these steps below.

STEP 1 – The OTUk_TT_Sk function will locally compute Its sm-BIP-8 byte value for an incoming OTUk frame. 

The OTUk_TT_Sk function will locally compute its SM-BIP-8 byte value for an incoming OTUk frame by performing the same procedure that the OTUk_TT_So function did at the remote terminal (Source STE).

The OTUk_TT_Sk function will take the 15,240 bytes of data (that resides within the OPU portion of the OTUk frame), and it will (effectively) stack this data into a 15,240-row x 8-bit column structure.

Figure 8 (once again) presents a simple illustration of an OTUk frame, with the OPU portion (e.g., that portion of the OTUk frame that we use to compute the BIP-8 Value) highlighted.

Section Monitoring BIP-8 Calculation Region

Figure 8, A Simple Illustration of the OTUk Frame, with the OPU-Portion of the Frame, Highlighted.

And if we were to look at this data differently, Figure 9 presents an illustration of the 15,240 Row by 8-bit column structure that the OTUk_TT_Sk function effectively creates from the OPU portion of each incoming OTUk frame.

Section Monitoring - OTUk BIP-8 Calculation Procedure

Figure 9, Illustration of How the OTUk_TT_Sk Computes the SM-BIP-8 byte value for each incoming OTUk frame

The OTUk_TT_Sk function will then parse through each 8-bit column (shown above in Figure 9) individually and compute the EVEN parity of the contents within each bit-column.

Note that it will perform parity calculations over 15,240 bits of data.

Once the OTUk_TT_Sk function has completed this process over each of the eight bit-columns, it will have an 8-bit expression.

This 8-bit expression is (once again) the SM-BIP-8 byte value for this particular OTUk frame.

After the OTUk_TT_Sk function computes its version of the SM-BIP-8 byte value, it needs to perform STEP 2 (of this BIP-8 Verification Process).

STEP 2 – The OTUk_TT_Sk function will compare its Locally-Computed BIP-8 Value with that inserted into the BIP-8 field (by the OTUk_TT_So function at the remote STE).

Once the OTUk_TT_Sk function reads in the contents of an OTUk frame and locally computes its SM-BIP-8 byte value (for that OTUk frame), it then needs to obtain the Value of the remotely-computed SM-BIP-8 byte-field.

If you recall, earlier in this post, I mentioned that the OTUk_TT_So function (at the remote terminal) would compute the SM-BIP-8 byte value for a given OTUk frame, and then it will insert this BIP-8 Value into the SM-BIP-8 byte-field, two OTUk frames later.

I show this relationship between the OTUk frame (that the OTUk_TT_So function computed the SM-BIP-8 byte value for) and its placement within the OTUk data stream above in Figure 3.

Therefore, the OTUk_TT_Sk function will find this remotely-computed SM-BIP-8 byte value for a given OTUk frame, two (2) OTUk frames later, within the SM-BIP-8 byte-field position.

Once the OTUk_TT_Sk function has obtained these two versions of the SM-BIP-8 byte values, it will then need to compare those two values with each other.

If the two BIP-8 byte-values are equal, then this means that this particular OTUk frame incurred no bit errors during transmission over the optical fiber.

On the other hand, if these two BIP-8 byte values are NOT the same, this particular OTUk frame DID incur bit errors during transmission over optical fiber to the Sink STE. 

In this case, the OTUk_TT_Sk function must determine how many bits (between these two versions of the SM-BIP-8 byte values) are different from each other.

Stated differently, the OTUk_TT_Sk function compares its locally computed SM-BIP-8 byte value and that it reads in from the SM-BIP-8 byte-field within the incoming OTUk data-stream and will perform a bit-by-bit XOR operation with each of these byte values.

The OTUk_TT_Sk function must then count the number of “1s” that occurs during that bit-wise XOR calculation (for each incoming OTUk frame).

The OTUk_TT_Sk function will come up with any one of the following nine (9) possible results.

  • 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 (or all) bits in Error

Figure 10 presents a simple illustration of the Bit-Wise XOR Operation that the OTUk_TT_Sk function performs with both the locally-computed and remotely-computed SM-BIP-8 byte values.

BIP-8 Verification Procedure - Bitwise XOR

Figure 10, Illustration of the Bit-Wise XOR Process for Verifying and Comparing the Locally-Computed SM-BIP-8 Byte Value with the Extracted (Remotely Computed) SM-BIP-8 Byte value for a given OTUk frame

The OTUk_TT_Sk function will then need to use the results of these BIP-8 comparisons for the following purposes.

  • To send out the results of these comparisons to the remote terminal in the form of the SM-BEI (Section Monitor – Backward Error Indicator) Value.  Please see the post on SM-BEI to learn more about this topic.
  • It will use these results to determine if the OTUk_TT_Sk function should declare or clear the dDEG (Signal Degrade) defect condition.  (*)
  • To use for Performance Monitoring Purposes (e.g., to compute the pN_EBC parameter in this case).  Please see the post on the pN_EBC  (Near-Error Block Count) Performance Monitor parameter to learn more about this topic.

Will the OTN Network Element ever declare any defects due to excessive SM-BIP-8 errors?

Yes, if the Sink STE were to detect a large number of SM-BIP-8 byte errors over a long period (e.g., typically on the order of seconds), then the Sink STE (or OTUk_TT_Sk Function) can declare the dDEG (Signal Degrade) defect condition.

I describe how the OTUk_TT_Sk atomic function declares and clears the OTUk-dDEG (Signal Degrade) defect condition within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!

Summary

This post describes the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bit) parameter.

At a high level, we have described how the OTN uses this parameter to perform error detection at the OTUk layer.

We have also specifically described how a Source STE computes and inserts the SM-BIP-8 byte value into the OTUk data stream.

We have also described how a Sink STE computes and verifies the SM-BIP-8 byte value (within each incoming OTUk frame) to check for the occurrence of data transmission errors.

Finally, we have identified the results that a Sink STE will come up with whenever it does compute and verify the SM-BIP-8 byte value.  We also mentioned that the Sink STE would use these results to:

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Become an Expert on OTN!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

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