Tag: Defects

What is the OTUk_TT_Sk Function?

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

What is the OTUk_TT_Sk Atomic Function?

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

Introduction

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

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

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

So What Does this Atomic Function Do?

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

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

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

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

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

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

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

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

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

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

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

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

Corporate Discounts Available!!

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

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

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

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

Some Details about the OTUk_TT_Sk Function

Figure 2 presents a simple illustration of the OTUk_TT_Sk function.

OTUk_TT_Sk Function - Trail Trace Atomic Function

Figure 2, Simple Illustration of the OTUk_TT_Sk Atomic Function

The Interfaces within the OTUk_TT_Sk Atomic Function

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

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

A Closer Look at the Interfaces within the OTUk_TT_Sk Function.

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

The OTUk_TCP (Termination Connection Point) Interface

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

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

Figure 3 presents a functional block of the OTUk_TT_Sk function.

OTUk_TT_Sk Functional Block Diagram

Figure 3, Functional Block Diagram of the OTUk_TT_Sk Function

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

  • CI_D
  • CI_CK
  • CI_FS
  • CI_MFS

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

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

The OTUk_TT_Sk_MP (Management Point) Interface

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

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

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

Discounts Available for a Short Time!!!

The OTUk_TT_Sk_RP (Remote Point) Interface

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

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

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

The OTUk_AP (Access Point) Interface (Output)

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

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

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

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

Defect Notification – Downstream

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

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

Consequent Actions

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

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

I will discuss each of these consequent action equations below.

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

Where:  

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

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

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

dTIM is the current state of the dTIM defect condition.

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

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

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

NOTES:

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

aBDI <- CI_SSF or dTIM

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

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

NOTES:

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

aBEI <- nBIPV

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

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

aBIAE <- dIAE

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

NOTES:

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

aTSD <- dDEG

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

NOTES:

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

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

The OTUk_TT_Sk Function Pin Description

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

Table 1, Pin Description of the OTUk_TT_Sk Atomic Function

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

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

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

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

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

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

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

This signal is functionally equivalent to the AIS indicator.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discounts Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is the OTUk_TT_So Atomic Function?

This blog post briefly defines the OTUk_TT_So (OTUk Trail Termination Source) Atomic Function. One of the roles of this function is to insert the real Section Monitoring Overhead (SMOH) into the OTU Overhead.


What is the OTUk_TT_So Atomic Function?

We formally call the OTUk_TT_So Atomic Function the OTUk Trail Termination Source Function.

Introduction

The OTUk_TT_So function is any function that accepts data from upstream circuitry (usually the OTUk/ODUk_A_So function).  It uses the data (within this data stream) along with signals from a collocated OTUk_TT_Sk function to compute/generate and insert the OTUk Section Monitoring Overhead (SMOH) into the OTUk signal.

We have an extensive discussion of the OTUk_TT_So Atomic Function in Lesson 9 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

I show how we can connect these atomic functions below in Figure 1.

OTUk_TT_So_Function_with_OTUk/ODUk_A_So and Collocated OTUk-TT_Sk functions highlighted

Figure 1, Drawing of a Bidirectional Network (consisting of various Atomic Functions) with the OTUk/ODUk_A_So, the OTUk_TT_So, and its collocated OTUk_TT_Sk functions highlighted 

So What Does this Atomic Function Do?

If you recall, from our discussion of the OTUk/ODUk_A_So function, that function will only generate default values for the OTUk-SMOH within the OTUk signal it transmits.  The OTUk/ODUk_A_So function creates this default SMOH as a place-holder for a future (and actual) SMOH.

Computes and Inserts the Real SMOH Values into the Outbound OTUk Frames

Well, the purpose of the OTUk_TT_So function is to calculate and replace these default SMOH values with actual SMOH values.

More specifically, this function will compute and replace the following SMOH fields with actual Overhead data.

  • SM-BIP-8 field, within the Section Monitoring field
  • SM-BEI/BIAE nibble field within the Section Monitoring Byte
  • SM-BDI bit-field within the Section Monitoring Byte
  • IAE bit-field within the Section Monitoring Byte
  • SM-TTI (Trail Trace Identification) byte within the Section Monitoring field.

Afterward, the OTUk_TT_So function will transmit this OTUk data stream to either the OTSi/OTUk-a_A_S0 function (for OTU1/2 applications) or the OTSiG/OTUk-a_A_S0 function (for OTU3/4 applications). 

These functions will condition the OTUk data stream for transmission over Optical Fiber.

Why Do We Care about the SMOH from the OTUk_TT_So Function?

The SMOH that the OTUk_TT_So function computes and inserts into the OTUk data stream serves as the basis of comparison for the OTUk_TT_Sk function (at the remote Network Element).

The OTUk_TT_Sk function (at the remote end of our OTUk connection) will use this SMOH data to determine:

  • if it should declare any defect conditions, or
  • if errors have occurred during transmission between the near-end OTUk_TT_So and the remote OTUk_TT_Sk functions.

I show an illustration where both the OTUk_TT_So and OTUk_TT_Sk functions “fit into the big picture” below in Figure 2.

Roles of the SMOH within the OTUk_TT_So function

Figure 2, Drawing of Unidirectional Connection between a Source STE and a Sink STE with the OTUk_TT_So and OTUk_TT_Sk functions highlighted.  

Some Details about the OTUk_TT_So Function

Figure 3 presents a drawing of the ITU-T G.798 symbol for the OTUk_TT_So function.

OTUk_TT_So Simple Block Diagram - ITU-T G.798 Symbol

Figure 3, Simple Drawing of the OTUk_TT_So function

The OTUk_TT_So function accepts a basic OTUk data stream from the upstream OTUk/ODUk_A_So function via the OTUk_AP Interface.

The data that is output from the OTUk/ODUk_A_So function includes the Clock Signal (AI_CK), Frame Synchronization Signal (AI_FS), the Multi-Frame Synchronization Signal (AI_MFS), the OTUk data-stream (AI_D) and the IAE (Input Alignment Error) indicator (via the AI_IAE signal).

The OTUk_TT_So function is responsible for accepting data from its various interfaces and then computing and inserting the correct SMOH data into the OTUk data stream.

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

  • OTUk_AP
  • OTUk_CP
  • OTUk_RP and
  • OTUk_TT_So_MP

We will discuss each of these interfaces below.

Figure 4 presents a functional block diagram of the OTUk_TT_So function.

OTUk_TT_So Atomic Functional Block Diagram

Figure 4 Functional Block Diagram of the OTUk_TT_So function

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

Corporate Discounts Available!!

The OTUk_AP (OTUk Access Point) Interface

Figure 4 shows that the circuitry connected to (and driving) the OTUk_AP Interface (e.g., the OTUk/ODUk_A_So function) will supply the following signals to this interface.

  • AI_D – Bare-bones OTUk data (with the default SMOH)
  • AI_CK – The OTUk clock input signal
  • AI_FS – The OTUk Frame Start Input
  • AI_MFS – the OTUk Multi-Frame Start Input
  • AI_IAE – The OTUk Input Alignment Error Indicator Signal

The OTUk_TT_So function will then perform the following operations on these signals.

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

Let’s move on to another port within this atomic function.

The OTUk_TT_So_RP (Remote Port) Interface

The OTUk_TT_So function will also accept data via the OTUk_TT_So_RP interface.  This interface consists of the following inputs.

  • RI_BEI – Remote Interface – Backward Error Indicator
  • RI_BIAE – Remote Interface – Backward Input Alignment Error Indicator
  • RI_BDI – Remote Interface – Backward Defect Indicator

The OTUk_TT_So function will operate in conjunction with a collocated Near-End OTUk_TT_Sk function and perform the following operations on these signals.

  • BDI Insertion (into the OTUk-SMOH) – The OTUk_TT_So function will accept the BDI information from the Near-End Collocated OTUk_TT_Sk function via the RI_BDI input and insert this data into the SM-BDI bit-field (within the SMOH) of the very next outbound OTUk frame.
  • BEI Insertion (into the OTUk-SMOH) – The OTUk_TT_So function will take the BEI information from the Near-End Collocated OTUk_TT_Sk function via the RI_BEI input and insert this data into the SM-BEI/BIAE nibble-field (within SMOH) of the very next outbound OTUk frame.
  • BIAE Insertion (into the OTUk-SMOH) – The OTUk_TT_So function will accept the BIAE information from the Near-End Collocated OTUk_TT_Sk function via the RI_BIAE input and (if appropriate) will insert this information into the SM-BEI/BIAE nibble-field (within the SMOH) of the very next outbound OTUk frame.

I show a drawing of our OTUk_TT_So function that is electrically connected to its collocated, Near-End OTUk_TT_Sk function via the Remote Port below in Figure 5.

OTUk_TT_So Atomic Function connected to its Collocated OTUk_TT_Sk function

Figure 5, Illustration of our OTUk_TT_So Function, along with its collocated, Near-End OTUk_TT_Sk function

We discuss the operations through the RP Interface in another post.

Next, let’s move on and discuss the Management Port of this atomic function.

The OTUk_TT_So_MP (Management Port) Interface

Finally, the OTUk_TT_So function accepts data from the OTUk_TT_So_MP Interface.  This particular interface consists of the following input pin.

  • MI_TxTI – Trail Trace Identifier Input

The function user is expected to load the contents of the outbound Trail Trace Identifier Message (64 bytes) to this input port.

The OTUk_TT_So function will then take this message data, and it will proceed to use the TTI byte-field within the OTUk-SMOH to transmit the contents of this message, one byte at a time, to the OTUk_TT_Sk function within the remote Network Element, via the OTUk data-stream.  Since the TTI Message is 64 bytes long, the OTUk_TT_So function will require 64 OTUk frames to transmit the complete TTI Message.

We will discuss these processes in greater detail in the Trail Trace Identifier post.

How the OTUk_TT_So function sources each of the various Overhead Fields within the SMOH

As we mentioned earlier, the primary responsibility of the OTUk_TT_So function is to compute/source the correct values for multiple fields within the SMOH and insert those values into the SMOH within each outbound OTUk frame.

Table 1 presents a list of Overhead-fields that the OTUk_TT_So function computes and sources.  This table also shows where this function gets its data for these Overhead fields.

Table 1, A List of the SMOH Overhead-fields that the OTUk_TT_So function computes/sources and how/where this function gets/derives this data.

Overhead FieldLocation within OTUk-SMOHSource of Data/How Derived?
BIP-8 ByteBIP-8 Byte within the Section Monitoring FieldThe OTUk_TT_So function locally computes the BIP-8 value based upon the contents within the OPUk portion of the OTUk frame.
IAE Bit-FieldThe IAE Bit-field within the Section Monitoring ByteBased upon the AI_IAE input to the function (at the OTUk_AP Interface)
BDI Bit-FieldThe BDI bit-field within the Section Monitoring byteBased upon the RI_BDI input to this function (at the Remote Port Interface).
BEI Nibble-FieldThe BEI/BIAE Nibble-field within the Section Monitoring ByteBased upon the RI_BEI and RI_BIAE inputs to this function (at the Remote Port Interface).
BIAE Nibble-FieldThe BEI/BIAE bit-fields within the Section Monitoring byte.Based upon the RI_BIAE and RI_BEI inputs to this function (at the Remote Port Interface).
TTI Byte-FieldTTI Byte within the Section Monitoring Field.The user is expected to load in the contents of the 64-byte Trace Identifier Message (TIM) into a buffer via the MI_TxTI input to this function.

The function will proceed to transmit the contents of this TIM, one byte at a time, via the TTI byte-field within each outbound OTUk Frame.

The OTUk_TT_So function will transport the entire TIM over 64 consecutive OTUk frames.

List of Input and Output Signals for the OTUk_TT_So Atomic Function

Table 2 presents a Pin Description for each of the Input/Output signals of the OTUk_TT_So Atomic Function.

Table 2, Input/Output Pin Description of the OTUk_TT_So Atomic Function

Signal NameTypeDescription
OTUk_AP Interface
AI_DInputOTUk Adapted Interface - OTUk Data Input:
The function user is expected to apply a bare-bones OTUk signal (which is output from the AI_D output of the OTUk/ODUk_A_So function) to this input pin.

NOTE: This OTUk data will contain the following fields
- Default OTUk SMOH data,
- The contents of the APS/PCC channel and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC field. This function will compute, generate and insert the appropriate OTUk-SMOH into this OTUk data-stream

The OTUk_TT_So function will sample this input signal on one of the edges of the AI_CK input clock signal.
AI_CKInputOTUk Adapted Interface - Clock Input:
The OTUk_TT_So function will sample all data and signals (that the user applies to the OTUk_AP Interface) upon one of the edges of this input clock signal. This statement applies to the following signals: AI_D, AI_FS, AI_MFS and AI_IAE.

This clock signal will also function as the timing source for this function as well.
AI_FSInputOTUk Adapted Information - Frame Start Input:
The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP Interface accepts the very first bit (or byte) of a new OTUk frame, via the AI_D inputs.

The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk frame.
AI_MFSInputOTUk Adapted Information - Multiframe Start Output:
The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP interface accepts the very first bit (or byte) of a new OTUk superframe, via the AI_D input.

The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk superframe.
AI_IAEInputOTUk Adapted Information - Input Alignment Error Input:
the OTUk/ODUk_A_So function (upstream from this function) will drive this input pin HIGH whenever it detects a frame-slip (or IAE event).

Anytime the OTUk_TT_So function detects this input pin, going from LOW to HIGH, then it should respond by setting the IAE bit-field to "1" for 16 consecutive Superframes (or 4096 consecutive OTUk frames).

Please see the blog on IAE for more information on this feature.
OTUk_CP Interface
CI_DOutputOTUk Characteristic Information - OTUk Data Output:
The OTUk_TT_So function will compute, generate and insert the SMOH (Section Monitoring Overhead) into the outbound OTUk data-stream. It will then output this OTUk data-stream via this output signal.

NOTE: This OTUk data will contain the following fields.
- The newly computed, inserted BIP-8 value
- The newly received and inserted BEI-nibble value or BIAE indicator.
- The newly received and inserted BDI bit-value.
- the newly received and inserted IAE value.
- The contents of the APS/PCC channel and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC field.

The OTUk_TT_So function will update this output signal on one of the edges of the CI_CK output clock signal.
CI_CKOutputOTUk Adapted Information - Clock Output:
The OTUk_TT_So function will output all data and signals (via the OTUk_CP interface) upon one of the edges of this output clock signal. This statement applies to the following signals: CI_D, CI_FS and CI_MFS.
CI_FSOutputOTUk Characteristic Information - Frame Start Output:
This function will drive this output pin HIGH whenever the OTUk_CP interface outputs the very first bit (or byte) of a new OTUk frame, via the CI_D output.

The OTUk_TT_So function should only pulse this output pin HIGH once for each outbound OTUk frame.
CI_MFSOutputOTUk Characteristic Information - Multiframe Start Output:
This function will drive this output pin HIGH whenever the OTUk _CP Interface outputs the very first bit (or byte) of a new OTUk Superframe via the CI_D.

The OTUk_TT_So function will drive this output pin HIGH once for each OTUk Superframe.
OTUk_TT_So_RP Interface
REI_BEIInputRemote Port Interface - BEI (Backward Error Indicator) Input:
The OTUk_TT_So function will accept one nibble of data (for each outbound OTUk frame) via this input signal and it will insert this data into the BEI/BIAE nibble-field within the Section Monitor field within each outbound OTUk frame.

The BEI value will reflect the number of BIP-8 errors that the collocated OTUk_TT_Sk function has detected and flagged within its most recently recevied and verified OTUk frame.

NOTE: If the OTUk_TT_So function receives a BIAE = 1 (via the RI_BIAE input) then it will overwrite the BEI/BIAE nibble-field with the value "1011" to denote a BIAE event.

Please see the BEI post for more information about Backward Error Indication.
RI_BIAEInputRemote Port Interface - BIAE (Backward Input Alignment Error) Input:
The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input signal and it will do either of the following, depending on the value of this single bit-field.

If BIAE = 0
Then the OTUk_TT_So function will write the BEI value that it has received via the RI_BEI input, into the BEI nibble-field within the Section Monitor byte of the next outbound OTUk frame.

If BIAE = 1
Then the OTUk_TT_So function will not write the BEI value (that it has received from the collocated OTUk_TT_Sk function). It will instead, write the value "1011" into the BEI/BIAE nibble-field, within the Section Monitor byte of the next outbound OTUk frame.
RI_BDIInputRemote Port Interface - Backward Defect Indicator Input:
The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input pin and it will write the contents of this value into the RDI bit-field (within the Section Monitor byte) of the next outbound OTUk frame.

If RI_BDI = 0
The the OTUk_TT_So function will set the BDI bit-field to "0" within the next outbound OTUk frame.

If RI_BDI = 1
Then the OTUk_TT_So function will set the BDI-bit-field to "1" within the next outbound OTUk frame.
OTUk_TT_So_MP Interface
MI_TxTIInputManagement Interface - Trail Trace Identifier Input:
The function user is expected to load in the 64-byte TTI Message into the OTUk_TT_So circuitry via this input. The OTUk_TT_So function will then transmit the message to the remote Network Element, one byte-at-a-time, over 64 consecutive outbound OTUk frames.

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

Discounts Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is the OTUk/ODUk_A_Sk Atomic Function?

This post briefly describes the OTUk/ODUk_A_Sk Atomic Function. The OTUk/ODUk_A_Sk function is also known as the OTUk to ODUk Adaptation Sink Function. This function will take an OTUk signal and it will extract/de-map out the ODUk signal within.


What is the OTUk/ODUk_A_Sk Atomic Function?

We formally call the OTUk/ODUk_A_Sk Atomic Function the OTUk to ODUk Adaptation Sink Function.

Introduction

The OTUk/ODUk_A_Sk function performs the exact reverse operation, as does the OTUk/ODUk_A_So function.

NOTE:  We extensively discuss the OTUk/ODUk_A_Sk function within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

More specifically, this function will:

  • Accept an OTUk signal (from upstream circuitry) and
  • Extract (or de-map) out an ODUk signal from this signal.

Figure 1 presents a simple illustration of the OTUk/ODUk_A_Sk function.

OTUk/ODUk_A_Sk Function - Adaptation Atomic Function

Figure 1, Simple Illustration of the OTUk/ODUk_A_Sk Function

As the OTUk/ODUk_A_Sk function converts an OTUk signal into an ODUk signal, it will terminate, process, and remove the OTUk-SMOH from this incoming OTUk data stream.  It will also extract the ODUk signal from this OTUk signal and route it to the downstream ODUk circuitry for further processing.

Please see the post on the ODUk_TT_Sk atomic function for more information on how ITU-T G.798 recommends that we handle and process ODUk signals.

The Interfaces within the OTUk/ODUk_A_Sk Function

Figure 1 shows that this function consists of the following three interfaces.

  • OTUk_AP – The OTUk Access Point:  This is the interface where the function user supplies the OTUk data to the function.  The upstream OTUk_TT_Sk function usually drives the signals within this interface.
  • ODUk_CP – The ODUk Connection Point:  This is where the function outputs ODUk data, clock, frame, and multi-frame signals (of the extracted ODUk data-stream) towards the ODUk-client circuitry.
  • OTUk/ODUk_A_So_MP – The Function Management Point:  This interface permits the function user to exercise control and monitor the activity within the OTUk/ODUk_A_Sk function.  This interface also allows the ODUk-client to access the APS channel (within the ODUk data stream).

Functional Block Diagram

Figure 2 presents the functional block diagram of the OTUk/ODUk_A_Sk function.

OTUk/ODUk_A_Sk Atomic Functional Block Diagram

Figure 2, Functional Block Diagram of the OTUk/ODUk_A_Sk Function

This figure shows the upstream equipment (e.g., the OTUk_TT_Sk function), which we typically connect to the OTUk_AP Interface (of the OTUk/ODUk_A_Sk function), will supply the following signals to this function.

  • AI_D – OTUk data (with the SMOH)
  • AI_CK – The OTUk clock input signal
  • AI_FS – The OTUk Frame Start Input signal
  • AI_MFS – The OTUk Multi-frame Start Input signal

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

Corporate Discounts Available!!

So What All Does this Atomic Function Do?

The OTUk/ODUk_A_Sk function will perform the following operations on these signals.

It will extract out/de-map the ODUk Data-Stream, the De-Mapping (ODUk) Clock Signal (ODCr), and it will generate the FS (Frame Start) and MFS (Multi-Frame Start) Signals.

The OTUk/ODUk_A_Sk function will de-map out and generate the following signals from the incoming OTUk signal.

  • ODUk Data-Stream – The ODUk Data consists of both the ODUk Overhead (PMOH) and the ODUk payload data
  • The ODUk Clock – The ODUk Clock Output signal
  • ODUk FS – The ODUk Frame Start Output
  • ODUk MFS – The ODUk Multi-frame Start Output

Extract out APS (Automatic Protection Switching) Commands from the APS Channel (within the ODUk-PMOH)

Once the OTUk/ODUk_A_Sk function has extracted the ODUk Data (which consists of the ODUk Overhead and Payload data), this function will now give the user access to the APS Channel (which is available via the APS/PCC field within the ODUk Overhead).

This function will route the APS Command information (within APS/PCC Channel) to the CI_APS output.

Transmits Either a Normal ODUk signal or the ODUk-LCK or ODUk-AIS Maintenance Signals downstream

The user can configure the OTUk/ODUk_A_Sk function to either output Normal (an ODUk signal carrying client-information) data or the ODUk-LCK maintenance signal, depending upon what the user does with the MI_AdminState input (to this function).

The user can also configure this function to automatically generate the ODUk-AIS Maintenance signal (instead of the NORMAL signal) whenever upstream circuitry asserts the AI_TSF input (to this function).

Function Defects

The OTUk/ODUk_A_Sk function does not internally declare any defects.

Consequent Actions

ITU-T G.798 presents the following equations for consequent actions within this particular function.

  • aSSF <- AI_TSF and (NOT MI_AdminState = LOCKED)
  • aAIS <- AI_TSF and (NOT MI_AdminState = LOCKED)
  • aSSD <- AI_TSD and (NOT MI_AdminState = LOCKED)

I will discuss each of these consequent action equations below.

aSSF <- AI_TSF and (NOT MI_AdminState = LOCKED)

This equation means two things.

  • The function will NOT declare the SSF (Server Signal Failure) condition if the user configures the MI_AdminState input into the LOCKED position.
  • The function will declare the SSF condition if the upstream OTUk_TT_Sk function drives the AI_TSF input pin TRUE (and if the user has NOT set the MI_AdminState to the LOCKED position).

NOTE:  If the OTUk/ODUk_A_Sk function declares the SSF condition, it will indicate so by asserting the CI_SSF output pin towards downstream circuitry.

The CI_SSF output signal is a crucial signal for Automatic Protection Switching purposes.

aAIS <- AI_TSF and (NOT MI_AdminState = LOCKED)

This equation means two things.

  • Suppose the user sets the MI_AdminState input to the LOCKED position.  In that case, this function will unconditionally generate and transmit the ODUk-LCK Maintenance Signal (via the CI_D output), regardless of the current state of the AI_TSF input to this function.
  • The OTUk/ODUk_A_Sk function will automatically generate and transmit the ODUk-AIS Maintenance Signal (via the CI_D output signal of this function) if the AI_TSF input pin is set to TRUE (provided that the MI_AdminState input is NOT set to the LOCKED position).

This equation also means that this function will only transmit a NORMAL ODUk signal (carrying client data) if the MI_AdminState input is NOT in the LOCKED position and the AI_TSF input pin is set FALSE.

aSSD <- AI_TSD and (NOT MI_AdminState = LOCKED)

This equation means two things.

  • This function will not declare the SSD (Server Signal Degrade) condition if the user configures the MI_AdminState input into the LOCKED position.
  • The function will declare the SSD condition if the upstream OTUk_TT_Sk function drives the AI_TSD input pin TRUE (and if the user has NOT set the MI_AdminState to the LOCKED position).

NOTE:  If the OTUk/ODUk_A_Sk function declares the SSD condition, it will indicate so by asserting the CI_SSD output pin towards downstream circuitry.

The CI_SSD output signal is a crucial signal for Automatic Protection Switching purposes.

How do the AI_TSF and MI_AdminState input signals affect the CI_SSF and CI_D outputs (from this function)?

The Consequent Equations for aSSF and aAIS all show that the function outputs (via the CI_SSF and CI_D pins) depend upon the state of the AI_TSF and MI_AdminState Inputs, as we offer in Table 1 below.

Table 1, Truth Table of the CI_D and CI_SSF Output Signals, based upon the AI_TSF and MI_AdminState Inputs

Relationship between AI_TSF and MI_AdminState inputs and CI_SSF and CI_D Outputs - OTUk/ODUk_A_Sk Function

Defect Correlations

None for this function.

Performance Monitoring

None

Pin Description

Table 2 presents a list and description of each input and output signal for the OTUk/ODUk_A_Sk function.

Table 2, List and Definition for each Input and Output Signal in the OTUk/ODUk_A_Sk function

Signal NameTypeDescription
OTUk_AP Interface
AI_DInputOTUk Adapted Information - OTUk Input:
The upstream OTUk_TT_Sk function is expected to apply a bare-bones OTUk data-stream to this input.

NOTE: This OTUk data will contain the following fields:
- OTUk SMOH data
- The contents of the APS/PCC channel (within the ODUk Overhead) and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC fields
AI_CKInputOTUk Adapted Information - Clock Input
This clock signal will sample all data that the user supplies to the AI_D, AI_FS, AI_MFS, AI_TSF and AI_TSD inputs.

The OTUk/ODUk_A_Sk function will also use this clock signal as its base timing source.
AI_FSInputOTUk Adapted Information - Frame Start Input:
The upstream OTUk_TT_Sk function will drive this signal TRUE; coincident to whenever it is supplying the very first bit or byte (of a given OTUk frame) to the AI_D input.

The upstream OTUk_TT_Sk function is expected to assert this signal once for each OTUk frame period.
AI_MFSInputOTUk Adapted Information - Multiframe Start Input:
The upstream OTUk_TT_Sk function will drive this signal TRUE coincident to whenever it is supplying the very first bit or byte (of a given OTUk Superframe) to the AI_D input.

The upstream OTUk_TT_Sk function is expected to assert this signal once for each OTUk superframe period, or once every 256 OTUk frame periods.
AI_TSFInputOTUk Adapted Information - Trail Signal Fail Indicator
The upsteam equipment (e.g., the OTUk_TT_Sk function) will typically assert this input pin whenever it is declaring one (or more) service-affecting defects wit the data that it is ultimately applying to the AI_D input of this function.

This signal has a similar role to the AIS signal. Please see the blog post on AIS for more information on this topic.
AI_TSDInputOTUk Adapted Information - Trail Signal Degrade Indicator Input:
The upstream equipment (e.g., the OTUk_TT_Sk function) will typically assert this input whenever it is declaring the dDEG (Signal Degrade) defect with the data that it is ultimately applying to the AI_D input of this function.
ODUk_CP Interface
CI_DOutputODUk Characteristic Information - ODUk Data Output:
The OTUk/ODUk_A_Sk function will take the ODUk data (that it has de-mapped from the OTUk signal, applied at the AI_D input) and output this data via this output signal.

However, if the user commands this function to output the ODUk-LCK Maintenance Signal, then it will do so via this output pin.

Finally, this function will also output the ODUk-AIS Maintenance Signal via this output if conditions warrant.
CI_CKOutputODUk Characteristic Information - Clock Output:
As the ODUk_CP Interface outputs data via the CI_D, CI_FS, CI_MFS, CI_APS, CI_SSF and CI_SSD outputs, all of this data will be updated on one of the clock edges of this clock output signal.
CI_FSOutputODUk Characteristic Information - Frame Start Output:
The ODUk_CP interface will pulse this output signal HIGH whenever the ODUk_CP interface outputs the very first bit (or byte) of a new ODUk frame, via the CI_D output.

This output signal will pulse HIGH once for each ODUk frame.
CI_MFSOutputODUk Characteristic Information - Multiframe Start Output:
The ODUk_CP Interface will pulse this output signal HIGH whenever the ODUk_CP interface outputs the very first bit (or byte) of a new ODUk Superframe, via the CI_D output.

This output signal will pulse HIGH once for each ODUk Superframe (or once each 256 ODUk frames).
CI_SSFOutputODUk Characteristic Information - Server Signal Failure Indicator Output:
One can think of this output pin as a buffered version of the AI_TSF input pin. This function will drive this output pin HIGH anytime the AI_TSF input pin (at the OTUk_AP Interface) is driven HIGH.

Conversely, this function will drive this output pin LOW anytime the AI_TSD input pin is driven LOW.
CI_SSDOutputODUk Characteristic Information - Server Signal Degrade Output:
One can think of this output pin as a buffered version of the AI_TSD output pin. This function will drive this output pin HIGH anytime the AI_TSD input pin (at the OTUk_AP Interface) is driven HIGH.

Conversely, this function will drive this output pin LOW anytime the AI_TSD input pin is driven LOW.
CI_APSOutputODUk Characteristic Information - APS Channel Output:
The OTUk/ODUk_A_Sk function will extract out the contents of the APS channel (from the incoming ODUk data-stream) and it will output the contents of the APS/PCC channel (as it applies to the APS Level that this OTUk/ODUk_A_Sk function is operating at).
OTUk/ODUk_A_Sk_MP Interface
MI_AdminStateInputManagement Interface - AdminState Input:
This input permits the function user to configure the OTUk/ODUk_A_Sk function to output either NORMAL ODUk data, or the ODUk-LCK maintenance signal via the CI_D output of this function.

Setting this input pin to the LOCKED state will configure the OTUk/ODUk_A_Sk function to override the NORMAL ODUk data, and the ODUk-AIS maintenance signal with the ODUk-LCK maintenance signal.
MI_APS_EnInputManagement Interface - APS Enable Input
This input permits the function user to either enable or disable APS/PCC Channel extraction from the incoming ODUk data-stream.

Setting this input pin TRUE configures the OTUk/ODUk_A_Sk function to extract the APS Messages from the APS/PCC channel (within the ODUk Overhead of the incoming ODUk data-stream) and output this data via the CI_APS output port.

Conversely, setting this input pin FALSE disables APS Message extraction from the incoming ODUk data-stream.
MI_APS_LVLInputManagement Interface - APS Level Input:
This input permits the user to specify the APS Level for this instantiation of the OTUk/ODUk_A_Sk function.

If the MI_APS_En input is TRUE, then this input pin will select the APS Level (and that portion of the APS/PCC Channel) that this function will output via the CI_APS output. Please see the APS/PCC post on more information about this protocol.

If the MI_APS_En input is FALSE, then this input will be ignored.

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

Discounts Available for a Short Time!!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is an Atomic Function for OTN?

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


What is an Atomic Function for OTN Applications?

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

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

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

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

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

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

OK, So What are these Atomic Functions?

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

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

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

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

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

OK, So Why bother with these Atomic Functions?

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

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

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

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

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

Therefore, you must understand the following:

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

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

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

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

  • Adaptation Functions and
  • Trail Termination Functions

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

Adaptation Functions

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

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

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

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

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

Another Way to Identify an Adaptation Function?

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

OTUk/ODUk_A_Sk Function - Adaptation Atomic Function

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

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

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

Corporate Discounts Available!!!

Trail-Termination Functions

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

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

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

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

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

Another way to Identify a Trail-Termination Function?

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

OTUk_TT_Sk Function - Trail Trace Atomic Function

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

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

 

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

Discounts Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is the Wait-to-Restore Period?

This post briefly defines and describes the term Wait-to-Restore for Protection-Switching systems.


What is the Wait-to-Restore Period within a Protection-Switching System?

The purpose of this post is to describe and define the Wait-to-Restore period within a Revertive Protection-Switching system.

Introduction

All Protection Groups will perform Protection-Switching, to route the Normal Traffic Signal around a defective Working Transport entity anytime it is declaring a service-affecting or signal degrade (dDEG) defect with that Working Transport entity.

In other words, the Protection Group will route the Normal Traffic Signal through the Protection Transport entity for the duration it declares this defect condition.

Whenever a Revertive Protection Group clears that defect, it will switch the Normal Traffic Signal back to flowing through the Working Transport entity.

We call this second switching procedure (to return the Protection-Group to its NORMAL, pre-protection-switching state) revertive switching.

In contrast, a Non-Revertive Protection Group will NOT perform this revertive switch, and the Normal Traffic Signal will continue to flow through the Protection Transport entity indefinitely.

When the Tail-End Node clears the Service-Affecting Defect

Protection-Switching events are very disruptive to the Normal Traffic Signal.  Each time we perform a protection-switching procedure, we induce a glitch (or a burst of bit errors) and signal discontinuity within the Normal Traffic Signal.

Therefore, Protection-Switching events should not be a common occurrence within any network.

To minimize the number of protection-switching events (occurring within a network), the Protection-Group will usually force the Tail-End Node to go through a Wait-to-Restore period after it clears the service-affecting or dDEG defect (which caused the Protection-Switching event in the first place) before it can proceed on to the next step and revert the protection-switching (and traffic).

In other words, the Tail-End Node (within a Protection-Group) will execute the following steps each time it clears a defect, which causes a protection-switching event.

  1. It clears the defect condition.
  2. The Tail-End circuit will then start a Wait-to-Restore Timer and will wait until this timer expires before it proceeds to the next step.
  3. If the Tail-End circuit declares another service-affecting defect while waiting for this Wait-to-Restore timer to expire, it will reset this timer back to zero and continue waiting.
  4. Once the Wait-to-Restore timer expires, the Tail-End circuit will revert the protection-switched configuration into the NORMAL configuration.  In other words, the Normal Traffic Signal will (once again) travel along the Working Transport entity.  

I show these same steps within the Revertive Procedure Flow Chart below.

Revertive Protection Switching Procedure Flow Chart

Figure 1, Flow-Chart of the Revertive Protection-Switching Procedure – after the Service-Affecting defect clears.

What is the purpose of using this Wait-to-Restore Period?

There are two main reasons why we use the Wait-to-Restore period in a Protection-Switching system.

  1. To make sure that the condition of the Working Transport entity has stabilized and is not still declaring intermittent defects before we start to pass the Normal Traffic signal through it again.
  2. And to reduce the number of protection-switching events within a protection group.

How Long Should the Wait-to-Restore period be?

ITU-T G.808.1 recommends that this period be between 5 and 12 minutes.

In Summary

All revertive protection-switching systems must wait through a Wait-to-Restore period (after clearing the defect condition) before executing the revertive switch.

The purpose of waiting through this Wait-to-Restore period is to prevent multiple Protection-Switching events due to intermittent defects within the Working Transport entity.

ITU-T G.808.1 recommends that this Wait-to-Restore period be between 5 and 12 minutes.

This means that the Tail-End circuit must go through this Wait-to-Restore period and declare no defects for the entire 5 to 12-minute period before it can move on to revert its protection-switching.

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

Discounts Available for a Short Time!!!

For More Information on other Protection-Switching-related Posts, Click on the Image Below.

Protection-Switching Related Blog

Protection-Switching Related Blog Posts

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

What is the PTE for OTN Applications?

This post defines and describes the Path and Path Terminating Equipment for OTN Applications.

What is Path Terminating Equipment (PTE) for OTN Applications?

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

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

I have devoted this blog post to discussing PTE (Path Terminating Equipment).

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

You can also find a detailed discussion of PTEs and STEs within Lesson 3 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!  This discussion also describes the differences between PTEs and STEs.

What is the Path?

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

For OTN applications, there are two different types of Paths.

  • A Non-OTN Client Signal Path (for Non-Multiplexed ODU traffic) and
  • An ODUk Server Signal Path (for Multiplexed ODU traffic)

We will define each of these types of Paths below.

Non-OTN Client Signal Path

When transporting a single non-OTN client signal (such as 100GBASE-R) over OTN (e.g., an ODU4/OTU4 signal in this case), the Path begins where the circuitry maps the 100GBASE-R signal into an OPU4 signal.

We can say that the 100GBASE-R signal officially enters the OTN at this point.

This Path ends at the location where the circuitry de-maps the 100GBASE-R signal from the OPU4 signal (and exits the OTN) at the other end of the network.

Figure 1 presents a simple illustration of an OTN that contains some Path Terminating Equipment and some STEs.

Difference between Section Termination Equipment and Path Terminating Equipment

Figure 1, Illustration of both PTE (Path Terminating Equipment) and STE (Section Terminating Equipment) within an Optical Transport Network

In Figure 1, we show that a Source PTE is mapping a 100GBASE-R signal into an OTU4 signal on the left-hand side of Figure 1.

The OTU4 signal transports this 100GBASE-R signal throughout this OTN and through various Section Terminating Equipment blocks labeled STE#1, STE#2, and STE#3.

Afterward, the OTU4 signal finally arrives at the Sink PTE on the right-hand side of Figure 1.

The Sink PTE then de-maps the 100GBASE-R signal from this OTU4 signal.

In the case of Figure 1, the Path (for the 100GBASE-R signal) is that portion of the OTN that exists between the Source PTE (on the left-hand side of Figure 1) and the Sink PTE (on the right-hand side of the same figure).

As this 100GBASE-R signal travels from the Source PTE to the Sink PTE, it will pass through multiple Sections and STEs (we describe in another post).  The Path is the route the 100GBASE-R signal takes (through the OTN, via the OTU4 signal).

A Closer Look at the Non-OTN Client SIGNAL Path

Now that we have a basic understanding of what a Path is, let’s take a much closer look at the Path.

Figure 2 presents a more detailed illustration of the Non-OTN Client Signal path within an OTN.  This figure also indicates where this Path begins and ends within the OTN.

100GbE/OTU4 Path - Path Terminating Equipment

Figure 2, A Closer Look at the Non-OTN Client Signal Path

Once again, Figure 2 shows that the Non-OTN Client Signal Path begins when we map the client signal into an OPU4 signal (and then an ODU4 and OTU4 signal).

In this case, we are mapping a 100GBASE-R client signal into an OPU4 signal at the OPU4 Mapper block.

This figure also shows that this same Path ends where we de-map that same client signal from the OPU4 signal (at the OPU4 De-Mapper block on the lower-right-hand side of Figure 2).

Please note that the diagram in Figure 2 is functionally equivalent to that in Figure 1.  In Figure 1, we referred to each signal (between the STE and PTE boxes) as OTU signals.  We did not discuss these signals at the OPU4 or ODU4 layers, as shown in Figure 2.

For more details on how we map a 100GBASE-R signal into an OPU4 (and ODU4) server signal, please see Lesson 4 within THE BEST DARN OTN TRAINING PERIOD!!

Let’s now move on to the other type of Path.

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

Corporate Discounts Available!!!

The ODUk Server Signal Path (for Multiplexed ODU Signals)

Another type of OTN Path is the ODUk Server Signal Path.

In the ODUk Server Signal Path, we can map and multiplex multiple lower-speed ODUj tributary signals into a Higher-Speed ODUk server signal (where k > j).

We describe the exact procedure for mapping/multiplexing lower-speed ODUj signals into a higher-speed ODUk signal in other posts.

Figure 3 illustrates a Unidirectional Network that contains both a Non-OTN Client Signal and the ODUk Server Signal set of paths.

1GbE to ODU0 to ODU4 - Path Terminating Equipment

Figure 3, A Closer Look at the ODUk Server Path

NOTE: We described the Non-OTN Client Signal path earlier in this post.  Hence, the reader should be familiar with this particular type of Path.

Handling the 1000BASE-X/OPU0/ODU0 Signals

In Figure 3, we have a 1000BASE-X (1GbE) signal that we first map into an OPU0 signal (in the Upper-Left-Hand corner of this figure).

We earlier stated that this point of mapping a non-OTN signal (such as a 1000BASE-X signal) into an OTN signal (e.g., an OPU0 in this case) is the beginning of the Non-OTN Client Signal Path.

Once we’ve mapped this signal into an OPU0, then we will also, in turn, map this OPU0 signal into an ODU0 signal.

Afterward, this ODU0 signal goes through some different processes (that we discuss in detail in other posts) before we map/multiplex this ODU0 tributary signal into an OPU4 signal.

Once we’ve mapped the ODU0 tributary signal (along with 79 other such signals) into an OPU4 signal, this point serves as the entry point for the ODU0 to OPU4/ODU4 Path.  We can also call this the ODUk Server Signal Path entry point.  

Figure 3 labeled this point as the ODU0 to OPU4 Path Demarcation Line.

This is where this OPU4 signal begins (and serves as the starting point for this particular Path).

Handing the OPU4/ODU4 Server Signal

We then quickly map this OPU4 signal into an ODU4 signal and then (eventually) into an OTU4 signal.

Afterward, we convert this OTU4 signal into an optical signal and transmit it through three additional sets of STEs before arriving at the XCVR and Optical I/F at the Remote Terminal (in the lower-left-hand corner of Figure 3).  

The remote terminal converts this signal back into the electrical format and terminates the OTU4 and ODU4 signals.

Finally, the circuitry routes the resulting OPU4 signal to the OPU4 De-Mapper block.  The OPU4 De-Mapper block then terminates this OPU4 signal.

This point serves as the OPU4 to the ODU0 Path Demarcation point.  This point is where this OPU4 signal (and its Path) ends.  We can also say that this is the end of the ODUk Server Signal Path.  

NOTE:  If you wish to learn more about how we map/multiplex lower speed ODUj tributary signals into an ODU4 Server signal, then you can check out Lesson 5 within THE BEST DARN OTN TRAINING PERIOD!!!

This circuitry will then de-map out the ODU0 tributary signal (of interest) along with as many as 79 other ODU0 tributary signals from this OPU4 signal.

Next, the ODU0 Terminator block will terminate this ODU0 signal and extract the OPU0 signal.

Afterward, it will transmit this data to the OPU0 De-Mapper block.

The OPU0 De-Mapper block will then de-map out the 1000BASE-X (1GbE) client signal from its incoming OPU0 signal.

Once the OPU0 De-Mapper block de-maps the 1000BASE-X signal from the OPU0 signal, this point serves as the Non-OTN Client Path Demarcation point.

In other words, this is the point at which this particular OPU0 signal (and its Path) ends.

How the PTE Operates in the Optical Transport Network

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

Path Termination Equipment will process data (in the electrical format) by doing many of the following functions:

In the Transmit Direction

  • Mapping data (either Non-OTN client data or lower-speed ODUj tributary data) into an OPUk signal and generating the new OPUk signal and overhead.
  • Generating the ODUk overhead or the ODUk-PMOH (Path Monitoring Overhead) and attaching the ODUk-PMOH to each outbound OPUk frame.
  • Sending this data downstream, the circuitry will either map this signal into another higher-speed ODUk signal or an OTUk frame and precondition it for transmission across the optical fiber.

NOTE:  Throughout many of the postings on this blog, we will refer to this ODUk overhead data as the ODUk-PMOH (ODUk-Path Monitoring Overhead) data.

In the Receive Direction

  • Receive ODUk data from the upstream OTUk Framer block
  • Process and Terminate the ODUk overhead (or ODUk-PMOH).  While the PTE is processing the ODUk-PMOH, it will check for the following errors and defects within the incoming ODUk signal.
    • Defects or Failures (e.g., dTIM, dPLM, dDEG, dAIS, dOCI, dLCK and PM-BDI)
    • Errors (e.g., PM-BIP-8, PM-BEI)
  • Terminate the OPUk data stream and de-map either the Non-Client OTN signal or some lower-speed ODUj tributary signals.
  • Route the de-mapped data downstream for further processing.

Mapping Data (either Non-OTN client data or lower-speed ODUj tributary data) into an OPUk/ODUk signal

Anytime the PTE maps data (be it non-OTN client data or lower-speed ODUj tributary signals) into an OPUk signal, it will do so by using some of the following mapping procedures.

As the PTE uses one of these mapping procedures to load client data into the OPUk payload, it will load its mapping parameters into the OPUk overhead.

The PTE will also alert the network of the type of traffic that it is transmitting via this OPUk signal by sending the appropriate PSI message via the PSI byte.

Please see the relevant posts for more information on this functionality.

Generating the ODUk Overhead (ODUk-PMOH)

As the PTE receives an OPUk data stream from upstream circuitry, it will precondition all this data for transport through the Path by computing and attaching the ODUk overhead fields to each outbound OPUk frame.

In particular, the PTE will attach some ODUk-PMOH fields to the OPUk frame, which will help it to detect errors and declare and clear certain defect conditions.

Other ODUk overhead fields support maintenance/monitoring features such as Tandem Connection Monitoring, the transport of APS (Automatic Protection Switching) Commands, and other forms of Equipment to Equipment (non-client related) commands and information.

In other posts, we will discuss these topics (e.g., Tandem Connection Monitoring and the APS Channel).

The critical thing to note at this point is that the PTE will use the ODUk-PMOH to monitor the overall health of the entire Path (from the point where it creates the ODUk signal to the end where it terminates this signal).

Figure 4 presents an illustration of the ODUk Overhead that the PTE will use to support the monitoring of this signal as it travels through the Path.  NOTE:  The ODUk-PMOH is the orange PM field within Figure 4.  We will discuss the PMOH in another post.  

ODU Frame with ODU Overhead Shown

Figure 4, ODUk Overhead, PMOH, and Payload fields

NOTE:  Please see the ODUk Frame post for more information on the ODUk frames and the PMOH fields.

Terminating the OPUk Overhead

After the OTUk signal has been converted into the optical format, received, and converted back into the electrical domain (by the remote terminal), the remote terminal will terminate the OTUk signal (because this equipment is an STE).

Once the STE has terminated OTUk-SMOH, it will route the resulting ODUk signal towards downstream circuitry for further processing.

At this point, the PTE will proceed to terminate the ODUk-PMOH.

As the PTE performs this task, it will check the ODUk-PMOH for the occurrence of bit errors and defects.

The PTE will report the occurrences of such errors and defects to System Management.

Additionally, the PTE will remove all ODUk-PMOH data from this incoming stream (which leaves us with just an OPUk data stream now).

This OPUk data stream is then routed to a De-Mapper block for further processing.

Important Takeaway

The critical takeaway is that the PTE will rely on the ODUk-PMOH data (as shown in Figure 4) to process, manage, and ultimately terminate the ODUk stream.

NOTE:  Each ODUk signal (whether it is a lower-speed ODUj tributary signal that we map/multiplex into a higher-speed ODUk server signal) or an ODUk signal (that is carrying a single Non-OTN client signal) will have its ODUk-PMOH data.

This means that PTE (whether it is for transporting a single Non-OTN client signal or one of many lower-speed ODUj signals) will manage and monitor its own respective ODU signal.

I have redrawn Figure 2 to show where the circuitry generates and terminates/monitors the ODU4-PMOH within the Non-OTN Client Path (of 100GBASE-R over OPU4/ODU4).  

I have included this figure below in Figure 5.

100GbE to OTU4 PTE w/ ODU4-PMOH

Figure 5, Illustration of the 100GbE to ODU4 Path.  (The Entire ODU4 Path is shaded).  

NOTE:  I have highlighted the locations where the Path Circuitry Generates and Monitors/Terminates the ODU4-PMOH (Non-OTN Client ODU4).

This also means that the circuitry (shown above in Figure 3) would require as many as 81 sets of PTE.

  • 80 sets of PTE would be required to monitor each of the 80 ODU0 signals (that we are transporting via the OPU4/ODU4 signal), and
  • One additional PTE would be required to monitor the more significant ODU4 signal.

I have also redrawn Figure 3 to show where the circuitry generates and terminates/monitors the ODU0-PMOH within the Non-OTN Client Path (of 1000BASE-X over OPU0/ODU0).  

I have included this figure below in Figure 6.

1GbE to ODU0 to ODU4 - ODU0 SMOH Termination

Figure 6, Illustration of the 1GbE to ODU0 -> ODU4 Path.  (The entire ODU0 Path is shaded).

NOTE:  In Figure 6, I have highlighted the locations where the Path Circuitry Generates and Monitors/Terminates the ODU0-PMOH (Non-OTN Client ODU0).  

Finally, I have redrawn Figure 3 (again) to show where the circuitry generates and terminates/monitors the ODU4-PMOH within the ODU0 mapped/multiplexed into OPU4/ODU4 Path.   

I have included this figure below in Figure 7.

1GbE to ODU4 with ODU4-PMOH

Figure 7, Illustration of the 1GbE to ODU0 -> ODU4 Path.   (The Entire ODU4 Path is shaded).

NOTE:  I have highlighted the Locations where the Path Circuitry Generates and Monitors/Terminates the ODU4-PMOH (ODU0 Mapped/Multiplexed into OPU4/ODU4).

De-Mapping the Client Signal from the OPUk Payload

Once the OPUk has reached the De-Mapper block, the De-Mapper block will de-map out the client data (be it non-OTN client data or lower-speed ODUj tributary signals) using the mapping parameters that the Source PTE loaded into the OPUk overhead bytes (when it was mapping these clients into the OPUk signal).

This point will be the “end of the line’ for the OPUk frame and overhead.

This circuitry will send the client data downstream for further processing (either by non-OTN system-side circuitry, such as a MAC or other PTE circuitry to handle the lower speed ODUj signals).

Examples of PTE

  • Line Cards or Transceivers take (for instance) 100GBASE-R data from a MAC and transport this data over an OTU4 connection (and vice-versa).
  • Any equipment that performs ODUj switching and grooming
  • ROADMs.

Some Final Comments about the ODUk-PMOH and PTE Equipment.

This post introduced the concept of a Path, Path Terminating Equipment (PTE), and the ODUk-PMOH (Path Monitoring Overhead).

In another post, I describe the Section, Section Terminating Equipment (STE), and the OTUk-SMOH (Section Monitoring Overhead).

STEs will use the OTUk-Layer to manage the data transmission across Sections.

STEs will only generate and process OTUk-SMOH data.  They do not process ODUk-PMOH data AT ALL.

Likewise, PTEs will use the ODUk-Layer to manage data transmission across a Path.

PTEs will only generate and process ODUk-PMOH data.  They do not process OTUk-SMOH data AT ALL.  In most cases, the PTE will not even see the OTUk-SMOH data.

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

Discounts Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is an STE for OTN Applications?

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


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

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

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

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

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

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

What is a Section?

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

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

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

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

Difference between Section Termination Equipment and Path Terminating Equipment

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

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

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

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

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

Now, we will define the term Section Terminating Equipment.

What is an STE (Section Terminating Equipment)?

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

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

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

The Source STE Operation In the Transmit Direction

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

Sink STE Operation In the Receive Direction

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

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

     

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

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

Summarizing our Definitions of Section and STE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OTUk Framing Format - Identifying Section Monitoring field

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

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

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

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

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

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

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

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

OTU Frame - Section Monitoring Byte Format - Optical Transport Networks

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

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

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

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

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

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

AN EXAMPLE OF AN STE AND ITS SECTION

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

Section Termination Equipment - End-to-End Connection

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

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

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

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

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

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

Examples of STE

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

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

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

Discounts Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is the ODUk-LCK Maintenance Signal?

This post defines and describes the ODUk-LCK (Locked) Indicator for OTN applications.


What Is the ODUk-LCK Maintenance Signal?

LCK is an abbreviation for Locked Indicator.

OTN Network Equipment will often transmit the ODUk-LCK (Locked) maintenance signal to indicate that this particular OTN interface has been administratively locked-out and is now unavailable to user traffic.

In other words, if the system operator decides to lock out (or prevent OTN traffic from flowing through) a given OTN interface, then the system will transmit the ODUk-LCK maintenance signal as a replacement signal through that OTN interface.

Whenever an OTN Network Equipment (NE) transmits an ODUk-LCK maintenance signal, it generates and transmits a framed repeating “0101 0101” pattern within the entire ODUk signal.

If we were to map the ODUk-LCK Maintenance signal into an OTU data stream, the Source STE would transmit a series of OTUk frames in which the FAS, MFAS, and OTUk Overhead fields are all valid.  The rest of the OTUk frame (e.g., the ODUk/OPUk portion of the frame) will consist of a repeating 0101 0101 pattern.

The Source STE will compute the FEC field based on the contents within these OTUk frames.

Figure 1 shows a drawing of an OTUk frame transporting the ODUk-LCK maintenance signal.

Figure 1, Illustration of an ODUk-LCK signal within an OTUk frame

What are the timing/frequency requirements for the ODUk-LCK Maintenance signal?

The Source STE will need to transmit this indicator at the same nominal bit rate for an ordinary OTUk signal.

Like any OTUk signal, the Source STE will need to transmit this data at the nominal bit-rate  ±20ppm.

Table 1 presents the nominal bit-rates for the OTUk signals (and, in turn, for the OTUk signal, whenever it is transporting the ODUk-LCK indicator) for each value of k.

Table 1, Required Bit Rates for the OTUk Signal – when transporting the ODUk-LCK signal.

OTUk Bit Rate and OTUk Frame Period

When would OTN Network Equipment transmit/generate the ODUk-LCK Maintenance signal?

Earlier, I mentioned that the Network Equipment would transmit the ODUk-LCK signal via an OTN Interface signal when the system operator has locked-out system users’ OTN traffic from using this particular OTN interface.

The ODUk-LCK maintenance signal will replace OTN traffic, which the system operator has locked out intentionally from this particular OTN interface.

The ODUk-LCK maintenance signal is similar to the ODUk-OCI and ODUk-AIS maintenance signals.  All three of these maintenance signals are replacement signals for actual OTN traffic.

However, the NE will transmit the ODUk-OCI indicator whenever the OTN traffic is missing because the system configuration has removed the OTN traffic upstream.

The NE will transmit the ODUk-AIS indicator whenever the intended OTN traffic is missing due to a service-affecting defect upstream.

The NE will transmit the ODUk-LCK indicator via an OTN interface whenever the OTN traffic is missing.  The system operator has locked out that particular OTN interface from all other OTN traffic.

One practical example of an OTN NE transmitting the ODUk-LCK indicator would be when the system operator has configured a particular port (or OTN interface) to operate in some diagnostic or loopback mode.

How does a Receive Terminal detect and declare the dLCK (ODUk-LCK) defect condition?

The Receiving NE (or Sink PTE) that is receiving the ODUk-LCK maintenance signal will declare the dLCK defect condition whenever it gets a STAT field value of [1, 0, 1] within three (3) consecutive OTUk/ODUk frames.

NOTE:  The STAT field is a 3-bit field that resides within the PM (Path Monitor) byte-field in the ODUk overhead.

This 3-bit field will have the value [1, 0, 1] because the NE overwrites the ODUk overhead with the repeating “0101 0101” pattern whenever it transmits the ODUk-LCK maintenance signal.

Please see the ODUk Frame post for more information about the STAT field.

How does a Sink PTE clear the dLCK defect condition?

The Sink PTE will clear the dLCK defect condition whenever it has accepted a STAT field value of something other than “[1, 0, 1]”.

NOTE:  The Sink PTE should accept a new STAT field value if it receives at least three (3) consecutive ODUk frames that contain a consistent STAT field value.

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

Discount Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is the ODUk-OCI Maintenance Signal?

This post defines and describes the ODUk-OCI (Open Connection Indication) signal.


What exactly is an ODUk-OCI Maintenance Signal?

OCI is an acronym for Open Connection Indicator.

OTN network equipment will often transmit the ODUk-OCI (Open Connection Indicator) Maintenance Signal to indicate that this particular OTN interface is not connected to an upstream signal (or trail termination source).

In other words, if the system configuration does not connect actual OTN traffic to an OTN interface, then the system will transmit the ODUk-OCI Maintenance signal as a replacement signal through that OTN Interface.

Whenever an OTU Network Equipment (NE) transmits an ODUk-OCI Maintenance signal, it generates and transmits a framed repeating “0110 0110” pattern within the entire ODUk signal.

More specifically, the OTN NE will generate/transmit a series of OTUk frames in which the FAS, MFAS, and OTUk Overhead fields are all valid, and the rest of the OTUk frame (e.g., the ODUk/OPUk portion of the frame) will consist of a repeating 0110 0110 pattern.

The NE will compute the FEC field based on the contents within these OTUk frames.

Figure 1 shows a simple drawing of an OTUk frame transporting the ODUk-OCI Maintenance signal.

ODUk-OCI indicator

Figure 1, Simple Illustration of an ODUk-OCI Maintenance signal within an OTUk frame

What are the timing/frequency requirements for an ODUk-OCI Maintenance signal?

The OTN NE will need to transmit this indicator at the same nominal bit rate for an ordinary OTUk signal.

Like any other OTUk signal, the OTN NE will need to transmit this data at the nominal bit-rate ±20ppm.

Table 1 presents the nominal bit-rates for the OTUk signals (and, in turn, for the OTUk signal, whenever it is transporting the ODUk-OCI Maintenance Signal) for each value of k.

Table 1, Required Bit Rates for the OTUk Signal – when transporting the ODUk-OCI Maintenance signal.

OTUk Bit Rate and OTUk Frame Period

When would OTN Network Equipment transmit/generate an ODUk-OCI signal?

Earlier, I mentioned that Network Equipment would transmit the ODUk-OCI Maintenance signal via an OTN Interface signal when the system configuration has NOT connected upstream traffic to this OTN interface.

The ODUk-OCI Maintenance signal will replace OTN traffic that was intentionally disconnected from this particular OTN interface.

The ODUk-OCI Maintenance signal is similar to the ODUk-AIS and ODUk-LCK Maintenance signals.  These three signals/indicators serve as replacement signals for actual OTN traffic.

However, the NE will transmit the ODUk-AIS indicator whenever the intended OTN traffic is missing due to a service-affecting defect upstream.

The NE will transmit the ODUk-LCK indicator whenever the OTN traffic is missing because the system operator has administratively locked out that particular OTN interface from all other OTN traffic.

Finally, the NE will transmit the ODUk-OCI maintenance signal whenever the OTN traffic is missing due to user configuration/provisioning (and not because of administrative lock-out).

One practical example of an OTN NE transmitting the ODUk-OCI indicator would be when an OTN traffic signal is not connecting a traffic signal to an OTN interface in an Optical Cross-Connect system.

How does a Receive Terminal detect and declare the dOCI (ODUk-OCI) defect condition?

The Receiving NE (or Sink PTE) that is downstream from the NE, which is transmitting the ODUk-OCI Maintenance signal, will detect and declare the dOCI defect condition whenever it receives a STAT field value of “1, 1, 0” within three (3) consecutive OTUk/ODUk frames.

NOTE:  The STAT field is a 3-bit field that resides within the PM (Path Monitor) byte-field in the ODUk overhead.

This 3-bit field will have the value [1, 1, 0] because the NE overwrites the ODUk overhead with the repeating “0110 0110” pattern whenever it transmits the ODUk-OCI indicator.

Please see the ODUk Frame post for more information about the STAT field.

How does a Sink PTE clear the dOCI defect condition?

The Sink PTE will clear the dOCI defect condition whenever it has accepted a STAT field value of something other than “[1, 1, 0]”.

NOTE:  The Sink PTE should accept a new STAT field value if it receives at least three ODUk frames that contain a consistent STAT field value.

Using the ODUk-OCI Maintenance Signal in Protection-Switching Applications

1:N and ODUk Shared-Ring Protection-Switching Systems will sometimes transport the ODUk-OCI Maintenance Signal through the Protection Transport entity (instead of the Extra-Traffic Signal) whenever we are not using the Protection Transport entity to carry the Normal Traffic Signal.

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

Discount Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

OTUk-Backward Defect Indicator

This post defines and describes the Backward Defect Indicator (dBDI) defect for the OTUk Layer


What is the dBDI (Backward Defect Indicator) defect at the OTUk Layer?

In short, the dBDI (or Backward Defect Indicator) signal is functionally equivalent to the RDI (Remote Defect Indicator) for OTN applications.

In OTN applications, Network Equipment can declare the dBDI defect at either the OTUk Layer or the ODUk Layer.

This post will discuss the dBDI defect for the OTUk Layer, which we can call the OTUk-BDI defect condition.

We address the dBDI defect for the ODUk Layer in another post.

In another post, I’ve also described the RDI (Remote Defect Indicator) signal or defect in generic terms.

In this post, we are going to describe the following items.

  • What conditions will cause an OTUk Network Element to transmit the dBDI indicator to the remote Network Element?
  • How does the OTUk Network Element transmit the dBDI indicator to the remote Network Equipment?
  • How does the OTUk Network Element receiving the dBDI signal detect and declare the dBDI defect condition?
  • And, how does the OTUk Network Element clear the dBDI defect condition?

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

Corporate Discounts Available!!

What conditions will cause an OTUk Network Element to transmit the dBDI indicator?

In Figure 1, we illustrate two Network Elements (consisting of OTUk Framers and OTUk Transceivers) exchanging OTUk traffic over Optical Fiber.

We will call one of these Network Elements NETWORK ELEMENT WEST and the other Network Element, NETWORK ELEMENT EAST.

NETWORK ELEMENT WEST contains the following pieces of hardware

  • OTUk Framer West
  • OTUk Transceiver East and
  • Optical I/F Circuitry (O->E)/(E->O)

Likewise, NETWORK ELEMENT EAST contains the following pieces of hardware.

  • OTUk Framer East
  • OTUk Transceiver East and
  • Optical I/F Circuitry (O -> E)/(E -> O)

Normal Condition - Network Element West and East

Figure 1, Illustration of two Network Elements that are connected over Optical Fiber

A Defect Condition

Now, let us imagine that some impairment occurs in the span of Optical Fiber carrying OTUk traffic from NETWORK ELEMENT WEST to NETWORK ELEMENT EAST.

This impairment will then cause NETWORK ELEMENT EAST to declare a service-affecting defect, as shown in Figure 2.

Network Element East declares Service Affecting Defect

Figure 2, Illustration of NETWORK ELEMENT EAST declaring a Service-Affecting Defect due to an impairment in Optical Fiber

NETWORK ELEMENT EAST might respond to this defect condition in several ways.  It might transmit the ODUk-AIS indicator towards downstream equipment (as a replacement signal).

NETWORK ELEMENT EAST might also invoke Protection Switching (if supported).

Sending the OTUk-BDI Indicator in Response

Finally, NETWORK ELEMENT EAST will also respond to this defect by transmitting the dBDI (or OTUk-BDI) indicator back towards the upstream Network Element (NETWORK ELEMENT WEST, in this case).

Figure 3 shows an illustration of NETWORK ELEMENT EAST, transmitting the OTUk-BDI indicator (back towards NETWORK ELEMENT WEST) in response to it declaring this service-affecting defect.

Network Element East sends OTUk-BDI signal to Network Element West

Figure 3, Illustration of NETWORK ELEMENT EAST responding to the Defect Condition by sending the OTUk-BDI indicator back towards NETWORK ELEMENT WEST

NETWORK ELEMENT EAST sends the OTUk-BDI indicator (back to NETWORK ELEMENT WEST) to alert it of this defect condition (between the two Network Elements).

In other words, NETWORK ELEMENT EAST is saying, “Hey, NETWORK ELEMENT WEST, I’m having problems with the data that you are sending me.  I’d just thought that I’d let you know”.

There are many reasons why all of these notifications are useful.

This notification gives the Overall Network a clearer picture of exactly where the problem (or impairment) is.

It can also notify maintenance personnel of these problems and provide them with helpful information before they “roll trucks.”

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

Discounts Available for a Short Time!!

So What EXACTLY are those Defects that will cause a Network Element to transmit the OTUk-BDI indicator?

The Network Element will transmit the OTUk-BDI indicator anytime it declares any service-affecting defect conditions.

(*) – Must be a member of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!  to see this material.  

The Network Element will continue to transmit the OTUk-BDI indicator for the duration it declares any of these defects.

Once the Network Element no longer declares these defect conditions, it will stop transmitting the OTUk-BDI indicator.

NOTE: ITU-T G.798 is the standards document that specifies the conditions and set of defects that will cause the Network Element to transmit the OTUk-BDI indicator to the remote terminal.

If you wish to see a detailed analysis of how ITU-T G.798 specifies these requirements, please look at the standards document itself or check out the OTUk-BDI – ITU-T G.798 Analysis post.

How does the OTUk Network Element transmit the dBDI indicator?

The Network Element will send the OTUk-BDI indicator by setting the BDI bit-field (Bit 5) within the SM (Section Monitoring) Byte, to  1, within each outbound OTUk frame.

The SM byte resides within the 3-byte SM (Section Monitoring) field of the OTUk Overhead.

Figures 4a, 4b, and 4c present the location of the BDI field.
Figure 4a presents an illustration of the SM-field within the OTUk Overhead.

OTUk Overhead with SM Field Identified

Figure 4a, The SM Field within the OTUk Overhead

Further, Figure 4b illustrates the SM byte’s location within the 3-byte SM Field (within the OTUk Overhead).

SM field with the SM Byte identified

Figure 4b, The SM-Byte within the SM Field

Finally, Figure 4c shows the location of the BDI-field within the SM-byte (within the SM-field of the OTUk Overhead).

SM Byte with OTUk-BDI field identified

Figure 4c, The Location of the BDI bit-field within the SM Byte, within the SM Field, within the OTUk Overhead

Likewise, the Network Element will end its transmission of the OTUk-BDI indicator by setting the BDI bit-field back to “0” within each outbound OTUk frame.

How does the OTUk Network Element detect and declare the dBDI indicator?

In the scenario that we described above (via Figure 3), NETWORK ELEMENT EAST will continue to transmit the OTUk-BDI signal to NETWORK ELEMENT WEST as long as it (NETWORK ELEMENT EAST) declares the service-affecting defect within its Ingress (Receive) signal.

If NETWORK ELEMENT WEST receives the OTUk-BDI indicator within at least five (5) consecutive OTUk frames, it will declare the dBDI defect condition.

In other words, if NETWORK ELEMENT WEST (or any Network Element) were to receive at least five (5) consecutive OTUk frames, in which the BDI bit-field is set to “1”, then it will declare the dBDI defect.

Figure 5 illustrates NETWORK ELEMENT WEST declaring the dBDI defect after receiving five consecutive OTUk Frames with the SM-BDI field set to “1”.

Network Element West declares the dBDI defect condition

Figure 5, Illustration of NETWORK ELEMENT WEST declaring the dBDI defect condition

How does the OTUk Network Element clear the dBDI defect condition?

Whenever NETWORK ELEMENT EAST has determined that the service-affecting defect (which caused it to transmit the dBDI signal in the first place) is cleared, it will stop sending the dBDI signal back out to NETWORK ELEMENT WEST.

NETWORK ELEMENT EAST will stop sending the dBDI signal by setting the BDI bit-field (within the SM field) to “0” within each outbound OTUk frame.

If NETWORK ELEMENT WEST (which is currently declaring the dBDI defect condition) were to receive at least five (5) consecutive OTUk frames, in which the BDI bit-field is set to “0”, then it will clear the dBDI defect.

Figure 6 illustrates NETWORK ELEMENT WEST clearing the dBDI defect after receiving five consecutive OTUk Frames with the SM-BDI field set to “0”.

Network Element East declares Service-Affecting Defect

Figure 6, Illustration of NETWORK ELEMENT WEST clearing the dBDI defect condition

Monkey Pox and Covid? It’s Scary Out There. We Can Help You Become an Expert on OTN Before It’s Safe to Venture Out!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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