This blog posts highlights differences between OTN and SONET/SDH. It also provides links to other blog posts that focus on these differences in detail.
SONET/SDH and OTN are standard protocols for transporting signals from Point A to Point B on (mostly) optical fiber.
However, there are some key differences:
OTN (at least for OTU1 through OTU4) has a fixed frame size. SONET/SDH does not.
SONET/SDH has a fixed frame repetition rate (8000 frames/sec). OTN does not.
When mapping/muxing lower-speed tributary signals into higher-speed signals, SONET/SDH requires that all the lower-speed tributary signals be synchronous with each other and with the high-speed server signal. OTN does not need this.
OTN has a standard FEC (Forward Error Correction) mechanism. SONET/SDH does not have such a thing.
OTN offers more extensive TCM (Tandem Connection Monitoring) support than does SONET/SDH.
The SONET/SDH standards only support data rates of up to 40Gbps (or OC-768). The OTN standards support over 100Gbps (e.g., 200Gbps, 400Gbps, etc.)
The mechanisms for handling rate differences are handled differences between the two standards. SONET/SDH relies exclusively on something called “pointer processing.” OTN uses different mechanisms altogether (Bit Synchronous Mapping, Asynchronous Mapping, and the Generic Mapping Procedure).
Additional Questions (Topics) to be Answered in the Differences between OTN and SONET/SDH
How does SONET/SDH support TCM?
How does OTN support TCM?
What is the framing format B100G OTN?
What are the roles of the Individual Overheads Bytes for SONET/SDH? How are they different from that for OTN?
How do you map 3 STS-1 signals into an STS-3 signal? How is this different from mapping ODU1s into an ODU2?
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.
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.
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.
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”.
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.
This blog post briefly describes the term pF_EBC (Far-End Errored Block Error).
What is the pF_EBC (Far-End Errored Block Count) Performance Monitoring Parameter for the OTUk Layer?
The purpose of this blog post is to briefly define and describe the pF_EBC (Far-End Errored Block Count) Performance Monitoring parameter that the OTN (Sink) STE (or OTUk_TT_Sk Atomic Function) will compute and tally.
The Sink STE (or OTUk_TT_Sk function) will include information on the pF_EBC parameter within each Performance Monitoring report it sends to System Management.
NOTES:
The OTN PTE (ODUP_TT_Sk Atomic Function) also monitors and generates information on the pF_EBC (Far-End Errored Block Count) parameter at the ODUk Layer. Please see the pF_EBC at ODUk Layer Post for more details on this parameter.
Throughout this post, I will use the terms: OTN STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.
Introduction
At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Far-End Errored Block Counts (or SM-BEI errors).
As the Sink STE receives and monitors its incoming OTUk signal, it will check for many things. It will continuously scan the incoming OTUk signal for bit (or symbol) errors (e.g., SM-BIP-8, FEC, etc.). It will also check for Service-Affecting defects (e.g., dTIM, dLOM, dLOF, dAIS, dLOS-P, etc.).
New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!!
Definition of Terms:
Before we proceed, we need to define the following terms for this blog post:
Block: In this case, we define a block as an OTUk frame.
Far-End Errored Block: In this blog post, we define a far-end errored block as any OTUk frame that contains a value for the SM-BEI count that ranges anywhere between 1 and 8. Anytime the OTN STE receives a block with an SM-BEI count value of 0x0, we consider that block to be un-erred.
As the Sink STE checks the incoming OTUk signal for errors and defects, it will also record the total number of far-end errored blocks it detects for each one-second period.
At the end of a given one-second period, the Sink STE will load the total number of far-end errored block counts (detected in the most recent one-second period) into the variable pF_EBC.
The Sink STE will then report this value for pF_EBC to System Management as a part of its Performance Monitoring report.
Table 1 presents the number of blocks/second that each type of OTUk signal will transport for each value of k.
Table 1, Number of Blocks/Second for each OTUk Rate.
OTUk Type
Number of Blocks/Second
OTU1
20,421
OTU2
82,026
OTU3
329,492
OTU4
856,388
OTUCn
n x 860,177
So How does the OTN STE tally Errored Blocks for the pF_EBC parameter?
As the Sink STE receives and monitors its OTUk signal, it will continually check the SM-BEI counts within each incoming OTUk frame (or block).
Anytime the Sink STE receives an OTUk frame in which the SM-BEI value is anywhere from 1 to 8, it will increment its internal (pF_EBC Counter) by 1.
NOTE: This means that even if the Sink STE receives an SM-BEI value of “8”, it will still just increment its pF_EBC Counter by 1 (not 8).
Conversely, the Sink STE will not increment its internal pF_EBC Counter whenever it receives an OTUk frame (or block) that contains an SM-BEI value of 0, or 9 through 15. The Sink STE consider these type of OTUk frames to be un-erred.
At the end of each one-second period, the Sink STE will load the contents of this internal counter into the pF_EBC parameter. The Sink STE will then include that information within its Performance Monitor report that it sends to System Management.
Are there any Times or Conditions during which the Sink STE will NOT tally Errored Block Counts for the pF_EBC parameter?
ITU-T G.798 states that the OTUk_TT_Sk function will stop tallying Errored Blocks for the pF_EBC parameter whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk Atomic Function) asserts the CI_SSF input of the OTUk_TT_Sk function.
In other words, the Sink STE will not tally any Errored Block Counts (for the pF_EBC parameter) whenever it (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions) declare any of the following service-affecting defect conditions.
Is there such a thing as Near-End Errored Block Counts?
Throughout this post, we have used the term Far-End Errored Block Count. Does this mean that there is another parameter called Near-End Errored Block Count?
This post briefly defines the SM-BEI (Section Monitoring – Backward Error Indicator) parameter. It also describes how an OTN Network will transmit the SM-BEI parameter from one Network Element to another.
What is the OTUk-BEI (Backward Error Indicator) or SM-BEI Parameter?
The purpose of this post is to define the SM-BEI (Section Monitor – Backward Error Indicator) parameter that a Source STE will generate, and a Sink STE will tally at the OTUk-Layer.
Introduction
In another post, we describe how the Sink STE (OTUk_TT_Sk function) will compute and verify the SM-BIP-8 value within each incoming OTUk frame.
NOTE: I will use the terms Sink STE and OTUk_TT_Sk function interchangeably throughout this post.
The Sink STE performs this task to check for any occurrences of bit errors during data transmission (over optical fiber) from the STE Source Terminal to the STE Sink Terminal.
However, just as the Sink STE (through its near-end Source STE) sends the SM-BDI indicator back out to the remote Terminal whenever it declares a service-affecting defect. The Sink STE (again, through its near-end Source STE) will also send out information to the remote Terminal to reflect the number of BIP-8 errors detected within each incoming OTUk frame.
We call this information the Backward-Error Indicator (or BEI). I will explain how we generate and transport this parameter below.
A High-Level Overview of the SM-BEI Parameter and How we Use it.
Before we get into the details of how things work with the various Atomic Functions and Ports, let’s spend some time discussing the underlying philosophy for transmitting the SM-BEI indicator.
Let us consider two Network Elements. We will call one Network Element, N.E East, and the other Network Element N.E. West. We have connected these two networks via a Bidirectional Optical Connection, as shown below in Figure 1.
Figure 1, Illustration of Network Elements East and West connected over a Bidirectional Fiber Optic Connection.
Now let’s consider two possible cases when dealing with SM-BIP-8 errors and SM-BEI.
The Unerred Case (where the Number of BIP-8 Errors = 0) and
The Erred Case (where the Number of BIP-8 Errors = 5)
The Unerred Case (where the Number of BIP-8 Errors = 0)
Let’s assume that the OTUk Transceiver and OTUk Framer (within Network Element EAST) are not detecting any BIP-8 errors within a given OTUk frame.
We show this case below in Figure 2.
Figure 2, Illustration of Network Element EAST detecting NO BIP-8 Errors within OTUk frame # n
Please note that in Figure 2, I show that both the OTUk Transceiver and OTUk Framer blocks (within Network Element EAST)are detecting ZERO BIP-8 errors. I show this because many OTUk Transceivers will also include some OTUk Framing capability and can detect and flag BIP-8 errors.
In this case, Network Element EAST will respond to this ZERO BIP-8 Error condition by setting the BEI field (within its next outbound OTUk frame – back to Network Element WEST) to “0x00”.
Why “0000”?
Because that’s the Number of BIP-8 Errors that the OTUk Transceivers/Framer blocks have detected in their most recently received OTU frames.
Figure 3 shows Network Element EAST setting the BEI field to 0x00 within its next outbound OTUk frame.
Figure 3, Illustration of Network Element EAST responding to the NO BIP-8 Error Condition by setting BEI = 0 within its next outbound OTUk frame.
Both the OTUk Transceiver and Framer (within Network Element WEST) will receive this OTUk frame (with BEI = 0), and it will “know” the quality of its OTUk signal (out to Network Element EAST) is GOOD.
Therefore, the BEI field (within the OTUk Overhead) gives a Network Element a way to provide feedback to an upstream Network Element about the quality of its output signal.
As long as Network Element WEST receives OTUk frames with the BEI field set to 0, it has some indication that it is transmitting a good quality OTUk signal out to Network Element EAST.
NOTE: Since this is a bidirectional connection between Network Elements EAST and WEST, then Network Element WEST can (and will) provide the same type of feedback to Network Element EAST.
Now let’s move on to the Erred Case.
The Erred Case (where the Number of BIP-8 Errors = 5)
Now that we have covered the No-Error condition let’s cover a different situation. Let us assume that Network Element EAST has just received an OTUk frame, which detects 5 BIP-8 errors.
I show an illustration of this condition below in Figure 4.
Figure 4, Illustration of Network Element EAST detecting 5 BIP-8 Errors within OTUk Frame # n
In this case, Network Element EAST will respond to this error condition by setting the BEI field (within its very next outbound OTUk frame – back out to Network Element WEST) to “0x05” (e.g., the same number of BIP-8 errors that it detected) within its recently received OTUk frame.
Why “0x05”?
Because that’s the number of BIP-8 bit errors that Network Element EAST has detected within its most recently received OTUk frame.
Figure 5 shows Network Element EAST setting the BEI field to 0x05 within its next OTUk frame.
Figure 5, Illustration of Network Element EAST responding to the 5 BIP-8 Error Condition by setting BEI = 5 within its next outbound OTUk frame
In this case, since Network Element EAST sets the BEI-field to “0x05”, it is giving Network Element WEST some feedback that it (Network Element EAST) is having problems with the OTUk data-stream that it is receiving from Network Element WEST.
Now that we understand the underlying philosophy behind using the SM-BEI fields, let’s discuss the SM-BEI parameter in greater detail.
New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!
Discounts Available for a Short Time!!!
An In-depth Discussion – How Does the Sink STE generate the BEI Parameter?
In the SM-BIP-8 Post, I mentioned that the Sink STE would locally compute its version of the SM-BIP-8 value based upon the contents within the OPUk portion of the OTUk frame that it has received.
I also mentioned that this SM-BIP-8 value is an 8-bit value.
The Sink STE (or OTUk_TT_Sk function) will then read out the contents of the SM-BIP-8 byte two OTUk frame periods later, and it will compare these two BIP-8 values.
I show the location of the BIP-8 Value, with respect to the OTUk Frame (that we used to compute this value), below in Figure 6.
Figure 6, The Location of the BIP-8 Value, with respect to the OTUk Frame (that we used to compute this value)
Comparing the Locally Computed BIP-8 Value with the Remotely Computed Value
At this point, the Sink PTE will compare its locally-computed SM-BIP-8 value with the remotely-computed SM-BIP-8 value (read out from the SM-BIP-8 byte field – two OTUk frame periods later).
If these byte values (of BIP-8 values) are equal, then we can state that this OTUk frame incurred no bit errors during transmission over the optical fiber.
On the other hand, if these two BIP-8 values are NOT the same, then the Sink STE (or OTUk_TT_Sk function) notes how many bits (between these two BIP-8 values) must be different from each other.
In other words, as the OTUk_TT_Sk function compares its locally computed BIP-8 value and that which it reads in from the BIP-8 byte-field within the incoming OTUk data stream. It will do this by performing a bit-by-bit XOR operation with each of these byte values.
The OTUk_TT_Sk function must then count the numbers of “1s” that occur during this bitwise XOR comparison. The OTUk_TT_Sk function will come up with any 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 (all) bits in Error
In Figure 7, I show a draw of a Bit-Wise XOR Comparator that the OTUk_TT_Sk function can use to compare its locally-computed BIP-8 value with the remotely-computed BIP-8 value.
Figure 7, Illustration of a Bit-Wise XOR Comparator that the OTUk_TT_Sk function can use to compare its Locally-Computed BIP-8 Value with the Extracted (Remotely Computed) BIP-8 Value for a given OTUk frame
The OTUk_TT_Sk function will need to send these BIP-8 comparison results back out to the remote terminal (the source of the OTUk signal that we are monitoring) in the form of BEI (Backward-Error-Indicator) value.
How does the OTUk_TT_Sk send out SM-BEI Information to the Remote Terminal?
Once the OTUk_TT_Sk function has performed the comparison (between its locally computed BIP-8 value with the remote-computed value), it then needs to report this information back to the remote terminal.
The OTUk_TT_Sk function will send a command to its collocated OTUk_TT_So function via the BEI (or RI_BEI) port.
I show a drawing of the OTUk_TT_Sk function, its collocated OTUk_TT_So function, and the BEI port below in Figure 8.
Figure 8, Illustration of the OTUk_TT_Sk, its collocated OTUk_TT_So function, and the BEI port.
The OTUk_TT_Sk function will use the BEI port to tell the OTUk_TT_So function what value it should set the BEI/BIAE nibble field to during its next outbound OTUk frame.
How does the OTUk Network Element transmit the SM-BEI Indicator?
The Network Element will transmit the SM-BEI indicator by setting the BEI/BIAE nibble-field within the SM (Section Monitoring) byte, to the BEI value, within each outbound OTUk frame.
The SM byte resides within the 3-byte SM (Section Monitoring) field of the OTUk Overhead.
Figures 9a, 9b, and 9c present the BEI/BIAE nibble-field location within an OTUk frame. First, Figure 9a shows the location of the SM field within the OTUk Overhead.
Figure 9a, The SM Field within the OTUk Overhead
Second, Figure 9b shows the location of the SM byte within the 3-byte SM Field.
Figure 9b, The Location of the SM-Byte within the SM Field
Finally, Figure 9c presents the BEI/BIAE nibble-field location within the SM-byte.
Figure 9c, The Location of the BEI/BIAE nibble-field within the SM Byte, within the SM Field, of the OTUk Overhead.
What is the Official Interpretation of the SM-BEI/BIAE Nibble within the OTUk Frame?
The SM-BEI/BIAE Nibble does not just carry Backward Error Indication information. It also transports the BIAE (Backward Input Alignment Error Indicator).
Table 1 presents a list that defines how we should interpret each value for the SM-BEI/BIAE Nibble.
SM-BEI/BIAE[1:4] Nibble Value
Is OTUk_TT_Sk Declaring dIAE?
BEI Count (Value) if any
0000
NO
0
0001
NO
1
0010
NO
2
0011
NO
3
0100
NO
4
0101
NO
5
0110
NO
6
0111
NO
7
1000
NO
8
1001, 1010
NO
0
1011
YES (BIAE Indicator)
0
1100 through 1111
NO
0
This table shows that only nibble values of 0x01 through 0x08 reflect some (non-zero) Backward Error Indication count.
Summary
Each Network Element can use the BEI/BIAE Nibble-field within the SM byte to provide the remote Network Element with feedback on the number of SM-BIP-8 bit errors they are detecting.
The remote Network Element will note (and increment the pF_EBC parameter) each time it receives an OTUk frame, in which the SM-BEI/BIAE nibble-field ranges between 1 and 8.
In another post, I discuss the pF_EBC (Far-End – Error Block Count) parameter in greater detail.
Clueless about OTN? We Can Help!! 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.
This blog post briefly describes the Performance-Monitoring parameter or term pN_EBC (Near-End Errored Block Count) for the OTUk-Layer.
What is the pN_EBC (Near-End Errored Block Count) Performance-Monitoring Parameter for the OTUk Layer?
This blog post aims to briefly define and describe the pN_EBC (Near-End Errored Block Count) Performance Monitoring parameter that the Sink STE (or OTUk_TT_Sk Atomic Function) will compute and tally.
The Sink STE (or OTUk_TT_Sk function) will include information on the pN_EBC parameter within each Performance Monitoring report it sends to System Management.
NOTES:
The OTN PTE (or ODUP_TT_Sk Atomic Function) also monitors and generates information on the pN_EBC (Near-End Errored Block Count) parameter at the ODUk Layer. Please see the pN_EBC at ODUk Layer Post for more details on this parameter.
Throughout this post, I will use the terms: Sink STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.
Introduction
At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Near-End Errored Block Counts (or SM-BIP-8 Errors).
NOTE: We refer to SM-BIP-8 errors as Near-End errors because these are errors that the Near-End Sink STE is detecting on its end. In contrast, we refer to the SM-BEI parameter as Far-End errors because that parameter reflects errors that a remote (or Far-End) Sink STE is detecting and reporting.
As the Sink STE receives and monitors its incoming OTUk signal, it will check for many things. It will continuously scan the incoming OTUk signal for bit (or symbol) errors (e.g., SM-BIP-8 errors, FEC errors, etc.) as well as Service-Affecting Defects (e.g., dTIM, dLOF, dLOM, dLOS-P, dAIS, etc.).
Definition of Terms:
Before we proceed, we need to define the following terms for this blog post:
Block: In this case, we define a block as an OTUk frame.
Errored Block: In this blog post, we define an errored block as any OTUk frame (or block) that contains at least one SM-BIP-8 error.
As the Sink STE checks the incoming OTUk signal for errors and defects, it will also keep a count of the number of errored blocks it detects for each one-second period.
At the end of a given one-second period, the Sink STE will load the total number of errored block counts (detected and tallied in the most recent one-second period) into the variable pN_EBC.
Since each type of OTUk signal (for a given value of k) transmits a different number of OTUk frames than does another OTUk signal (with a different value for k), each OTUk type will transmit a different number of blocks/second, as we show below in Table 1.
Table 1, Number of Blocks/Second for each OTUk Rate
OTUk Type
Number of Blocks/Second
OTU1
20,421
OTU2
82,026
OTU3
329,492
OTU4
856,388
OTUCn
n x 860,177
So How does the OTN STE tally Errored Blocks for the pN_EBC parameter?
As the Sink STE receives and monitors its OTUk signal, it will continually check for SM-BIP-8 errors.
Anytime the Sink STE receives an OTUk frame that contains at least one SM-BIP-8 error, then it will increment its internal (pN_EBC Counter) by 1.
Conversely, the Sink STE does not increment its internal pN_EBC Counter whenever it receives an OTUk frame that contains 0 SM-BIP-8 errors.
At the end of each one-second period, the Sink STE will load the contents of this internal counter into the pN_EBC parameter and include that information within its Performance Monitor report that it sends to System Management.
New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!!
Are there any Times or Conditions during which the OTN STE will NOT tally Errored Block Counts for the pN_EBC parameter?
Yes, ITU-T G.798 states that the OTUk_TT_Sk function will stop tallying Errored Blocks for the pN_EBC parameter whenever the upstream circuitry (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk Atomic function) asserts the CI_SSF input of the OTUk_TT_Sk function.
In other words, the OTN STE will not tally any Errored Block Counts (for the pN_EBC parameter) whenever it (e.g., the OTSi/OTUk_A_Sk or OTSiG/OTUk_A_Sk functions) declares any of the following service-affecting defects conditions.
Is there such a thing as Far-End Errored Block Counts?
Throughout this post, we have used the term Near-End Errored Block Count. Does this mean that there is another parameter called Far-End Errored Block Count?
This blog post briefly defines the pF_DS (Far-End Defect Second) Performance Monitoring parameter – for the OTUk Layer.
What is the pF_DS (Far-End Defect Second) Performance-Monitoring Parameter for the OTUk Layer?
This blog post aims to briefly define and describe the pF_DS (Far-End Defect Second) Performance Monitoring parameter that the OTN STE (or OTUk_TT_Sk Atomic Function) will compute and generate.
The OTN STE (or OTUk_TT_Sk function) will include information on pF_DS within each Performance Monitoring report it sends to System Management.
NOTES:
The OTN PTE (ODUP_TT_Sk Atomic Function) also monitors and generates information on the pF_DS (Far-End Defect Second) parameter at the ODUk Layer. Please see the pF_DS at ODUk Layer Post for more details on this parameter.
Throughout this post, I will be using the terms: OTN STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.
Introduction
At the OTUk Layer, the OTN (Sink) STEis the entity that is responsible for detecting and reporting Far-End Defect Second events.
As the OTN STE receives and monitors its incoming OTUk signal, it will check for many things. It will continuously check the incoming OTUk signal for Service-Affecting Defects (e.g., dTIM(*), dLOF, dLOFLANE(*), dLOL(*), dLOM(*), dAIS (OTUk-AIS), dLOS-P, etc.) as well as bit (or symbol) errors (e.g., SM-BIP-8 errors, SM-BEI errors, FEC errors, etc.).
Another thing that the OTN STE will do (as it continuously monitors its incoming OTUk signal) is to divide each second of (monitoring) time into the following two categories:
Far-End Available (Working) Seconds, and
Far-End Defect Seconds
Anytime the OTN STE detects and categories a given one-second period as being a Far-End Defect Second, it will increment the pF_DS parameter and report that information to System Management.
New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!
Discounts Available for a Short Time!!
So When does the OTN STE detect and flag a given One-Second Period as being a “Far-End Defect Second”?
ITU-T G.798 presents the following Performance Monitoring Equation for the OTUk_TT_Sk function.
dBDIis the current state of the OTUk-BDI or the Backward Defect Indicator Defect (at the OTUk Layer).
The OTN STE (or OTUk_TT_Sk function) will continuously evaluate the above equation as it monitors its incoming OTUk signal.
This equation states that the OTN STE will declare a given one-second period as being a Far-End Defect Second if it has declared the dBDI defect condition during any portion of that one second.
A given OTN STE will declare one second as a Far-End Defect Second if the remote OTN STE declares any of the following defect conditions:
OTUk-AIS
dTIM
dLOS-P
dLOFLANE
dLOL
dLOF
dLOM
In this case, the OTN STE will increment the pF_DS parameter for each second that it categorizes as a Far-End Defect Second.
Conversely, the OTN STE will declare one second as an Available Second if the remote OTN STE is not declaring any of the defects mentioned above. The OTN STE will NOT increment the pF_DS parameter in this case.
What Does This Mean in English?
Of course, if the OTN STE declares the dBDI defect condition, then this also means that the remote STE is declaring a service-affecting defect condition. In other words, the pF_DS parameter reflects the health of the remote (or Far-End) terminal.
If the remote terminal declares no service-affecting defects, the near-end terminal will not increment the pF_DS parameter. On the other hand, if the remote terminal declares a service-affecting defect, then the near-end terminal will increment the pF_DS parameters.
So, if the OTUk_TT_Sk function has declared the dBDI defect condition for even a fraction of a given one-second period, it will declare it as a Far-End Defect Second. It will also set the parameter pF_DS to 1 and report that information to System Management.
Conversely, suppose the OTN STE determines that the OTUk_TT_Sk function did not declare the dBDI defect condition during one second period. In that case, it will declare that one-second period as being a Far-End Available (Working) Second. In this case, the OTN STE will NOT set the parameter pF_DS to 1.
Are there any Times or Conditions during which the OTN STE should NOT tally the pF_DS Parameter?
Yes, ITU-T G.798 states that the OTUk_TT_Sk function (or System Management) should discard the previous and the current one-second period’s measurement of the pF_DS parameter whenever it declares either the dIAE (Input Alignment Error)(*) or dBIAE (Backward Input Alignment Error)(*) defect conditions.
We need to discard the previous one-second period reading to account for the propagation delay of the IAE signaling indicator coming from the remote terminal equipment.
Is there such a thing as a Near-End Defect Second?
Throughout this post, we have been using the term Far-End Defect Second. Does this mean that there is another parameter called Near-End Defect Second?
Answer: Yes, there is such a parameter. Please see the post on Near-end Defect Seconds (pN_DS) at the OTUk Layer for more details.
Clueless about OTN? We Can Help!! Click on the Banner Below to Learn More.
Discounts Available for a Short Time!!
And Finally, CLICK on the Image Below to see More OTN-Related Topics in this Blog.
This blog post briefly defines the pN_DS (Near-End Defect Second) Performance-Monitoring parameter – for the OTUk Layer.
What is the pN_DS (Near-End Defect Second) Performance-Monitoring Parameter for the OTUk Layer?
This blog post aims to briefly define and describe the pN_DS (Near-End Defect Second) Performance-Monitoring parameter that the Sink STE (or OTUk_TT_Sk Atomic Function) will report.
The Sink STE (or OTUk_TT_Sk function) will include information on pN_DS within each Performance Monitoring report it sends to System Management.
NOTES:
The OTN PTE (ODUP_TT_Sk Atomic Function) also monitors and generates information on the pN_DS (Near-End Defect Second) parameter at the ODUk Layer. Please see the pN_DS at ODUk Layer Post for more details on this parameter.
Throughout this post, I will use the terms: Sink STE and OTUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.
Introduction
At the OTUk Layer, the Sink STE is the entity that is responsible for detecting, flagging, and reporting Near-End Defect Second events.
As the Sink STE receives and monitors its incoming OTUk signal, it will check for many things.
It will continuously check the incoming OTUk signal for Service-Affecting Defects (e.g., dTIM, dLOF, dLOM, dLOFLANE, dLOL, dLOS-P, dAIS, etc.) as well as bit (or symbol) errors (e.g., SM-BIP-8 errors, FEC errors, etc.).
Another thing that the Sink STE will do (as it continuously monitors its incoming OTUk signal) is to divide each second of (monitoring) time into the following two categories:
Near-End Available (Working) Seconds, and
Near-End Defect Seconds
Anytime the Sink STE detects and categorizes a given one-second period as being a Near-End Defect Second. It will increment the pN_DS parameter and report that information to System Management.
So When does the OTN STE flag a given One-Second Period as being a “Near-End Defect Second”?
ITU-T G.798 presents the following Performance Monitoring Equation for the OTUk_TT_Sk function.
pN_DS <- CI_SSF or dTIM;
Where:
CI_SSF is the current state of the CI_SSF input pin to the OTUk_TT_Sk Atomic Function, and
dTIM is the current state of the Trail Trace Identifier Message (or OTUk-TIM) defect condition.
OK, What Does that Mean in Plain English?
The above equation means that the Sink STE will classify a given one-second period as being a Near-End Defect Second anytime it declares a service-affecting defect within its incoming OTUk signal during even a fraction of that one second.
Conversely, the Sink STE will classify a given one-second period as being a Near-End Available (or Working) second if it is NOT declaring a service-affecting defect within this OTUk signal during this one second.
How to Evaluate the Performance Monitoring Equation for pN_DS?
The Sink STE (or OTUk_TT_Sk function) will continuously evaluate the above-mentioned Performance Monitoring equation as it monitors its incoming OTUk signal.
Once again, this equation states that the Sink STE will declare a given one-second period as being a “Near-End Defect Second” if it determines that any of the following conditions are (or were ever) TRUE during that one second.
NOTE: The OTSi/OTUk_A_Sk and OTSiG/OTUk_A_Sk functions will assert their CI_SSF signal if these atomic functions declare any of the following defects conditions.
dLOS-P[i], where i represents any of the four electrical lanes in an OTL3.4/OTL4.4 Interface.
dLOFLANE[j], where j represents any one of 4 or 20 logical lanes in an OTL3.4/OTL4.4 Interface.
dAIS (OTUk-AIS) – for Single-Lane (OTSi/OTUk_A_Sk Function) Applications Only.
dLOL – for OTL3.4/OTL4.4 Applications ONLY.
dLOF
dLOM
Or if the OTUk_TT_Sk function declares the dTIM (OTUk-TIM) defect condition.
So, for example, if the OTUk_TT_Sk function has determined that the upstream circuitry asserted the CI_SSF input for even a fraction of a given one-second period, then it will classify that one-second period as being a Near-End Defect Second.
It will also set the parameter pN_DS to 1 and report that information to System Management.
Conversely, suppose the Sink STE determines that NONE of those conditions were true during the most recent one-second period. In that case, it will declare that one-second period as being a Near-End Available (Working) Second.
In this case, the Sink STE will not increment the pN_DS parameter.
New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!!
Are there any Times or Conditions during which the OTN STE should NOT tally the pN_DS Parameter?
Yes, ITU-T G.798 states that the OTUk_TT_Sk function (or System Management) should discard the previous and the current one-second period’s measurement of pN_DS whenever it declares the dIAE (Input Alignment Error)(*) defect condition.
We need to discard the previous one-second period reading to account for the propagation delay of the IAE signaling indicator coming from the remote terminal equipment.
Is there such a thing as a Far-End Defect Second?
Throughout this post, we have been using the term Near-End Defect Second. Does this mean that there is another parameter called Far-End Defect Second?
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.
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.
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):
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.
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.
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.
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
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).
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.
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).
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.
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
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.
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.
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.
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
