Tag: SM-BEI

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.

What is an STE for OTN Applications?

This post defines and describes both a Section and Section Terminating Equipment for OTN applications. This post also defines the term: OTUk-SMOH (Section Monitoring Overhead).


What is Section Terminating Equipment (STE) for OTN Applications?

Whenever we discuss the OTN Digital Layers (e.g., the OPUk, ODUk, and OTUk layers), we can group Networking Circuits and Equipment into one of two broad categories.

I will be using these terms throughout various OTN-related posts within this blog.  So, we must have a strong understanding of these terms.

I have devoted this blog post to STE (Section Terminating Equipment).

I have devoted another post to PTE (Path Terminating Equipment).

NOTE:  I discuss STEs and PTEs extensively in Lesson 3 within THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!  I also discuss the differences between STEs and PTEs as well.  

What is a Section?

Before we define the term Section Terminating Equipment (or STE), we must first define the word Section as it pertains to an Optical Transport Network (OTN).

For OTN applications, a Section is a single optical link (or span) between two adjacent pieces of networking equipment.

NOTE:  For lower speed applications, one can realize a Section via a Copper Medium (such as CAT5 or CAT6 Cable).

Figure 1 presents a simple illustration of an Optical Transport Network with some boxes labeled PTE and others labeled STE.

Difference between Section Termination Equipment and Path Terminating Equipment

Figure 1 illustrates STE (Section Terminating Equipment) and PTE (Path Terminating Equipment).  Note:  Figure 1 shows a total of five (5) different boxes.  

Two of these boxes are labeled PTE, and three of these boxes are labeled STE.

However, in reality, all 5 of these boxes are STEs.

From a system standpoint, many PTEs are STEs.  However, not all STEs are PTEs.

We can also define a Section as any optical connections connecting these boxes (in Figure 1).

Now, we will define the term Section Terminating Equipment.

What is an STE (Section Terminating Equipment)?

For OTN applications, the basic definition of a Section Terminating Equipment is any equipment that (1) transmits data into or receives data from the Section and (2) also monitors and manages the data transmission over this Section (e.g., the optical fiber link that exists between the Near-End and the adjacent Far-End Network Equipment).

For OTN applications, the OTUk Layer is the protocol layer responsible for managing and monitoring the transmission/reception of data across a Section.

More specifically, an OTN Source (or Transmitting) STE is any equipment that performs ALL the following functions.

The Source STE Operation In the Transmit Direction

  • It will accept data from upstream circuitry (typically in the form of ODUk frames).
  • It electrically preconditions all data (that it is about to transmit to the remote Sink STE via an optical connection) by computing and attaching the OTUk (or OTUkV) overhead to this data stream.  This data will typically (but not always) include the FEC.
  • Once the Source STE has finished preconditioning this data, it will convert this electrical data into the optical format and transmit it over optical fiber to the remote Sink STE.

Sink STE Operation In the Receive Direction

The Sink (Receiving) STE performs all of the following operations.

  • It receives data (from a remote Source STE) in the optical format.
  • The Sink STE then converts this optical data into the electrical format, where it can check and process these newly received OTUk/OTUkV frames.
    As the Sink STE checks and processes this data, it will check for the following items.

     

  • It will then pass this data to the downstream circuitry as an ODUk data stream (for further processing at the ODUk-layer).

Therefore, if we were to combine our simple definition of the word Section with the description of a Section Terminating Equipment, we can say the following.

Summarizing our Definitions of Section and STE

An STE begins at the point where the Network Equipment (or the Source STE) will precondition and process electrical data in preparation for transmission over an Optical link.

Afterward, the Source STE will convert this signal into the Optical Format, transmitting this optical signal to the remote Sink (or Receiving) STE.

A Section ends (or is terminated) at the point where the Sink STE (that receives this optical signal) converts it back into the electrical format, processes this data, and sends it to downstream equipment.

How the STE Operates in the Optical Transport Network (OTN)

A Source STE will manage and monitor the transmission of this data (across a Section) by encapsulating this data into OTUk/OTUkV frames.

This Source STE will encapsulate this (ODUk) data by generating and inserting some overhead data (that we call the OTUk-SMOH [Section Monitoring Overhead]) into these OTUk/OTUkV frames.

NOTE:  In some of my other posts, I refer to this Source (or Transmitting) STE as the OTUk/ODUk_A_So, OTUk_TT_So, and OTSi/OTUk_A_S0 or OTSiG/OTUk_A_So atomic functions.

The Sink (or Receiving) STE will use this OTUk-SMOH to manage data reception across the Section.

NOTE:  In my other posts, I also refer to this Sink (or Receiving) STE as the OTUk/ODUk_A_Sk, OTUk_TT_Sk, and OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk atomic functions.

The STE STE will manage the reception of data across the Section by using this OTUk-SMOH to check for data transmission errors and service-affecting defects.

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

But when we say “OTUk-SMOH,” what exactly do we mean?

Figure 2 illustrates the OTUk Overhead data (within an OTUk frame) that the Section Terminating Equipment will process and terminate as it manages data transmission across a Section.

This figure also highlights a particular field (regarding Section Monitoring).  This figure highlights the Section Monitoring field.

OTUk Framing Format - Identifying Section Monitoring field

Figure 2, Illustration of an OTUk Frame with the OTUk SMOH Fields highlighted

I highlight the SM (or Section Monitoring) field because the actual OTUk-SMOH (that the Sink STE will use to check for the presence of defects or errors) resides within the Section Monitoring (or SM) field (within the OTUk Overhead).

In Figure 3, I focus on the Section Monitoring field and illustrate the byte format of this 3-byte field.

OTU - SM (Section Monitoring) Field, TTI Byte, BIP-8 Byte, SM Byte

Figure 3, Illustration of the Byte-Format of the Section Monitoring field.

Figure 3 shows that the Section Monitoring field contains the following three byte-fields.

  • The BIP-8 Byte
  • The TTI Byte and
  • The Section Monitoring (or SM) Byte

In Figure 4, I further focus on the SM Byte and show the bit format of that particular byte field.

OTU Frame - Section Monitoring Byte Format - Optical Transport Networks

Figure 4, Bit-Format of the SM (Section Monitoring) Byte – within the Section Monitoring field

If you have seen the OTUk Frame post, Figures 2 through 4 should look familiar.

All of the overheads fields that the Sink STE will need to check for OTUk-related defects and errors (not including FEC) reside within the SM field.

Hence, the OTUk-SMOH is the Section Monitoring field within the OTUk Overhead.

NOTE:  For “nuts and bolts” details on the Source and Sink STEs handling and processing the OTUk-SMOH, check out the posts on the following Atomic Functions.

Now let’s proceed to show an example of STE and its Section.

AN EXAMPLE OF AN STE AND ITS SECTION

Figure 5 illustrates an STE and Section within a typical OTN network connection.

Section Termination Equipment - End-to-End Connection

Figure 5, Illustration of the STE and Section (from End to End) in a Typical OTN System

Finally, Figure 5 shows that the Section and STE begin (and end) before and after the OTUk Framer Block.

Please note that the STE also includes the OTUk Framer blocks in this Figure.

The OTUk Framer Blocks (and, in some cases, the OTUk Transceiver Blocks) are responsible for generating and inserting the OTUk-SMOH into the outbound OTUk data stream.

These same functional blocks are also responsible for processing and terminating the OTUk-SMOH within the incoming OTUk data stream.

Throughout numerous blog posts, we discuss the generation and processing of the OTUk-SMOH in detail.

Examples of STE

The following is a list of examples of the various types of OTN STE that are being deployed into the network infrastructure today.

  • Any 3R type of repeater.
  • Any network element that takes electrical data and maps it into an OTUk signal for transport to another terminal over an optical (or copper) connection (e.g., equipment that transmits data through sub-marine links, etc.).
  • CFP Optical Modules that also contains the DSP Transceiver.
  • Line Cards that include CFP2/CFP4 Optical Modules and OTN Framers.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You 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