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.
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 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_SkAtomic 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.
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.
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).
Figure 2 presents a simple illustration of the OTUk_TT_Sk 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.
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.
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
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:
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).
The AI_TSF output signal is a crucial signal for Automatic Protection Switching purposes.
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:
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.
The OTUk_TT_Sk function will assert the RI_BDI and AI_TSF output pins under the same conditions.
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:
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.
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:
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).
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 Name
Type
Description
OTUk_TCP Interface
CI_D
Input
OTUk 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_CK
Input
OTUk 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_FS
Input
OTUk 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_MFS
Input
OTUk 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_SSF
Input
OTUk 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_D
Output
OTUk 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
Output
OTUk 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_FS
Output
OTUk 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_MFS
Output
OTUk 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
Output
OTUk 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_TSD
Output
OTUk 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_BEI
Output
OTUk 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_BIAE
Output
OTUk 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_BDI
Output
OTUk 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_AcTI
Output
Management 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_ExSAPI
Input
Management 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_ExDAPI
Input
Management 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_GetAcTI
Input
Mangement 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_TIMDetMo
Input
Management 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_cTIM
Output
Management 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_cDEG
Output
Management 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_cBDI
Output
Management 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_cSSF
Output
Management 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_pIAE
Output
Management 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_pBIAE
Output
Management 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_EBC
Output
Management 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_DS
Output
Management 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_EBC
Output
Management 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_DS
Output
Management 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_1Second
Input
Management 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_DEGThr
Input
Management 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_DEGM
Input
Management 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.
