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.  

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.

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.

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.

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.

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.

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

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

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.

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.

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.