What is the OTUk/ODUk_A_So Atomic Function?

This post briefly describes the OTUk/ODUk_A_So (OTUk to ODUk Adaptation Source) Function. This function will take an ODUk signal and it will synchronously map it into an OTUk signal.

What is the OTUk/ODUk_A_So Atomic Function?

We formally call the OTUk/ODUk_A_So Atomic Function the OTUk to ODUk Adaptation Source Function.

Introduction

The OTUk/ODUk_A_So function is any circuit that (1) accepts an ODUk signal and (2) adapts (or maps) it into an OTUk signal for transmission to the following Trail Termination Function.

NOTE: If we are working with a Fully-Compliant OTUk frame, then the OTUk/ODUk_A_So function will synchronously map each ODUk frame into the OTUk frame.

On the other hand, if we are working with a Functionally-Compliant OTUkV frame, this mapping might be asynchronous.

In this post, we will assume that we are working with a Fully-Compliant OTUk frame.

NOTE: We discuss the OTUk/ODUk_A_So function in detail in Lesson 9, within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

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

Figure 1, Simple Illustration of the OTUk/ODUk_A_So function

As the OTUk/ODUk_A_So function converts an ODUk signal into an OTUk signal, it will encapsulate each ODUk frame into an OTUk frame by adding the OTUk Overhead to the ODUk structure.

Please note that the OTUk/ODUk_A_So function will only insert default values for the SMOH (Section Monitoring Overhead) within the OTUk overhead.

Functional Block Diagram for the OTUk/ODUk_A_So Function

Figure 2 presents a Functional Block Diagram for the OTUk/ODUk_A_So function.

Figure 2, Functional Block Diagram for the OTUk/ODUk_A_So function

Interfaces within the OTUk/ODUk_A_So Function

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

ODUk_CP – The ODUk Connection Point. The ODUk_CP is the interface where the ODUk-client supplies ODUk characteristic information (CI) to the OTUk/ODUk_A_So function input.
OTUk_AP – The OTUk Access Point. There is where the OTUk/ODUk_A_So function outputs OTUk data, clock, frame, and multi-frame signals (for the outbound OTUk data-stream) to downstream circuitry (towards the OTUk_TT_So function).
OTUk/ODUk_So_MP – The Function Management Point. This interface permits the function user to exercise control of the activity within the OTUk/ODUk_A_So function.

Figure 2 shows that the ODUk-client function (connected to the ODUk_CP Interface – of the OTUk/ODUk_A_So function) will supply the following signals to this function.

CI_D – ODUk Data-Stream
CI_CK – ODUk Clock Signal
CI_FS – ODUk Frame Start Signal
CI_MFS – ODUk Multiframe Start Signal
CI_APS – ODUk APS Communication Channel

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

Corporate Discounts Available!!

So What Does This Function Do?

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

Optionally Generates the ODUk-LCK Maintenance Signal

The function allows the user to configure the OTUk/ODUk_A_So function to generate the ODUk-LCK maintenance signal upon command internally.

The user can implement this command by setting the MI_AdminState input pin (at the Management Port) into the LOCKED State.

Whenever the user sets the MI_AdminState input into the LOCKED State and commands the OTUk/ODUk_A_So function to generate the ODUk-LCK maintenance signal, the timing, framing, and multi-framing for this ODUk-LCK signal will be based on the CI_CK, CI_FS and CI_MFS inputs (at the ODUk_CP Interface).

NOTE: In this case, the ODUk-LCK maintenance signal will replace the ODUk traffic carrying user/client data.

This function will, in turn, map this replacement signal into an OTUk data stream.

Please see the post on the ODUk-LCK maintenance signal for more details about the ODUk-LCK maintenance signal.

Allows User to Insert APS (Automatic Protection Switching) Commands into the APS Channel (within the ODUk-PMOH).

The OTUk/ODUk_A_So function permits the user to access the APS channel (within this ODUk signal) via some inputs (at both the OTUk/ODUk_A_So_MP and the ODUk_CP Interfaces).

More specifically, this function allows the user to enable or disable the APS Channel and configure this function to operate at a specific APS Level through the MI_APS_En and MI_APS_LVL inputs (via the OTUk/ODUk_A_So_MP Interface).

Additionally, this function permits the user to insert their own APS Commands into the APS/PCC Channel within the ODUk Overhead via the CI_APS input (at the ODUk_CP Interface).

NOTE: Please see the relevant post on the APS/PCC Channel to learn more about the APS Channel.

Generates OTUk Clock, FS (Frame Start), and MFS (Multi-Frame Start) Signals via the OTUk_AP Interface

The OTUk/ODUk_A_So function will synthesize the clock (AI_CK), frame start (AI_FS), and multi-frame start (AI_MFS) signals for the outbound OTUk signal via the OTUk_AP Interface.

The OTSiG/OTUk_A_So or OTSi/OTUk_A_So function (downstream) will use these signals to generate and insert the FAS and MFAS fields into the correct locations within the outbound OTUk data stream.

Generates the IAE (Input Alignment Error) Indicator for the downstream OTUk_TT_So function

The OTUk/ODUk_A_So function will generate the IAE (Input Alignment Error) indicator anytime it detects a frame-slip within the incoming ODUk signal (e.g., CI_FS) via the ODUk_CP Interface.

In other words, if this function detects the CI_FS signal pulsing TRUE during an unexpected clock cycle (CI_CK), then this function will drive the AI_IAE output pin HIGH.

Whenever the OTUk/ODUk_A_So function drives the AI_IAE output pin HIGH, it signals an Input Alignment Error Event. The OTUk/ODUk_A_So function will drive the AI_IAE output signal to the downstream OTUk_TT_So function.

The downstream OTUk_TT_So function will accept and perform another process with this AI_IAE output signal.

The OTUk/ODUk_A_So function will keep the AI_IAE output pin HIGH until the upstream (ODUk-circuitry) starts to assert the CI_FS input indicator during the correct (or expected) CI_CK period, once again.

Generate and Route the OTUk Data-Stream to downstream circuitry

This function will output a data stream via the AI_D output, which I will call a partial OTUk data stream.

This data stream will not contain the FAS, MFAS, or the FEC fields.

It will include the ODUk-portion of the OTUk frame and the default values for the various OTUk Overhead Fields (e.g., the Section Monitoring Overhead – SMOH).

We will then route this data stream to other circuitry (e.g., the OTUk_TT_So function) for further processing.

List of Input and Output Signals for the OTUk/ODUk_A_So Function

Table 1 presents a list and description for each OTUk/ODUk_A_So function input and output ports.

Table 1, List and Definition for each Input and Output Signal in the OTUk/ODUk_A_So function

Signal Name	Type	Description
ODUk_CP Interface
CI_D	Input	ODUk Characteristic Information - Data Input: The ODUk-client is expected to input the ODUk data via this input. This ODUk data will contain all portions of the ODUk frame.
CI_CK	Input	ODUk Characteristic Information - Clock Input: This clock signal will sample all data that the ODUk-client supplies to the CI_D, CI_FS, CI_MFS and CI_APS inputs. The OTUk/ODUk_A_So function will also use this clock signal as its timing source.
CI_FS	Input	ODUk Characteristic Information - Frame Start Input: The ODUk-client equipment will drive this signal TRUE; coincident to whenever it is supplying the very first bit or byte (of a given OTUk frame) to the CI_D input. The ODUk-client is expected to assert this signal once for each ODUk frame period. The OTUk/ODUk_A_So function will also use this input signal to determine if it should declare the IAE condition, via the AI_IAE output pin.
CI_MFS	Input	ODUk Characteristic Information - Multiframe Start Input: The system-side equipment will drive this signal TRUE coincident to whenever it is supplying the very first bit or byte (of a given ODUk/OTUk Superframe) to the CI_D input. The ODUk-client is expected to assert this signal once for each OTUk/ODUk superframe period, or once every 256 ODUk frame periods.
CI_APS	Input	ODUk Characteristic Information - APS Channel Data: The system-side equipment is expected to apply the APS Channel to this input. The function user must set the MI_APS_En input to TRUE and must place a valid value (for APS Level) at the MI_APS_LVL input pins, or the OTUk/ODUk_A_So function will ignore the data at this input. The OTUk/ODUk_A_So function will map this data into the APS/PCC channel within the ODUk data-stream. Please see the blog post about the APS/PCC channel for more information.
OTUk_AP Interface
AI_D	Output	OTUk Adapted Information - OTUk Data Output: The OTUk/ODUk_A_So function will take all of the data (that the ODUk-client applies to both the CI_D and CI_APS input pin) and will combine this data together to form a bare-bones OTUk data-stream. 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 fields. Additionally, the downstream OTUk_TT_So function will compute and generate the correct values for the OTUk-SMOH.
AI_CK	Output	OTUk Adapted Information - Clock Output: As the OTUk_AP Interface outputs data via the AI_D, AI_FS, AI_MFS and AI_IAE outputs; it will updata all of this data on one of the edges of this clock output signal.
AI_FS	Output	OTUk Adapted Information - Frame Start Output: The OTUk_AP Interface will pulse this output signal HIGH whenever the OTUk_AP Interface outputs the very first bit (or byte) of a new OTUk frame, via the AI_D output. The OTUk_AP Interface will pulse this output HIGH once for each outbound OTUk frame.
AI_MFS	Output	OTUk Adapted Information - Multiframe Start Output: The OTUk_AP Interface will pulse this output signal HIGH whenever the OTUk_AP Interface outputs the very first bit (or byte) of a new OTUk superframe, via the AI_D output. The OTUk_AP Interface will pulse this output HIGH once for each OTUk Superframe (or once each 256 OTUk frames).
AI_IAE	Output	OTUk Adapted Information - Input Alignment Error Output: The OTUk_AP Interface will drive this output signal HIGH whenever the OTUk/ODUk_A_So function detects a frame slip within the ODUk_CP Interface. More specifically, if the OTUk/ODUk_A_So determines that the upstream equipment has pulses the CI_FS input at an unexpected CI_CK period, then this function will drive this output HIGH. This function will keep this output signal HIGH until the OTUk/ODUk_A_So function starts to receive pulses at the CI_FS during the "expected" CI_CK periods again. Once the OTUk/ODUk_A_So function starts to receive pulses at the CI_FS input (during the "expected" CI_CK period) then it will drive this output pin LOW.
OTUk/ODUk_A_So_MP Interface
MI_AdminState	Input	Management Interface - AdminState Input: This input pin permits the user to configure the OTUk/ODUk_A_So function to operate in either the LOCKED State or the NORMAL state. If the user configures this function to operate in the NORMAL state, then it will map NORMAL ODUk traffic (e.g., ODUk traffic that is carrying client-data) into an OTUk frame as it passes through this function. Conversely, if the user configures this function to operate in the LOCKED state, then the function will generate and map the ODUk-LCK Maintenance signal into the outbound OTUk data-stream.
MI_APS_En	Input	Management Interface - APS Channel Enable Input: This input pin permits the user to either enable or disable the OTUk/ODUk_A_So function to/from accessing the APS/PCC channel within the ODUk overhead. Setting this input HIGH permits the OTUk/ODUk_A_So function to access (and send APS messages via) the APS/PCC channel. Setting this input LOW prevents the OTUk/ODUk_A_So function from accessing (and sending APS messages) via the APS/PCC channel.
MI_APS_LVL	Input	Management Interface - APS Level: This input permits the user to specify the APS Level, that this OTUk/ODUk_A_So function can use when it accesses the APS/PCC channel. NOTES: 1. This input is ignored if MI_APS_En = FALSE. 2. There are 8 possible valid inputs to this port. Please see the blog post on the APS/PCC channel for more information about this topic.

Has Inflation got You Down? Our Price Discount 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 Topics within this Blog

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

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:

Which atomic functions apply to your system (or chip) design, and
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.

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.

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 Topics within this Blog

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

What is PT = 0x21 for OTN Applications?

This post discusses and describes the PT = 21 Method for Mapping and Multiplexing Lower-Speed ODUj signals into a Higher-Speed ODUk Signal.

What is PT (Payload Type) = 0x21 for OTN Applications, and what does it Mean?

Whenever we are mapping/multiplexing lower-speed ODUj signals into a higher-speed ODUk signal, for up to the ODU3 rate, we have the following two options:

Use the PT = 20 (or 0x20) Method for Mapping/Multiplexing the ODUj tributary signals into the ODUk, or
Use the PT = 21 (or 0x21) Method for Mapping/Multiplexing the ODUj tributary signals into the ODUk.

If you wish to map/multiplex some lower-speed ODUj signals into an ODU4 signal, then you MUST use the PT = 21 (ox21) approach.

NOTE: We discuss the PT = 21 Approach (for mapping/multiplexing) some lower-speed ODUj tributary signals into an ODU4 in Lesson 5/ODU4 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

What is the PT = 21 Method?

Whenever we use the PT = 21 Method, we will set the PT byte (within the PSI Message) to the value 0x21 within this OPUk/ODUk signal.

The PT = 21 Method for Mapping/Multiplexing of ODUj signals into an ODUk signal has the following characteristics.

We do Mapping/Multiplexing with 1.25Gbps time-slots (instead of the 2.5Gbps time-slots for PT = 20).
In most cases, we use GMP to map the ODUj signal into the ODTUk.ts or ODTUjk structures.
However, we do use AMP as the mapping procedure in some cases.

Is the PT = 21 Method better than PT = 20 Method?

The PT = 21 Method is the newer standard and is (therefore) the preferred approach.

For example, for 2-Fibre/2-Lambda Shared-Ring Protection-Switching applications, ITU-T G.873.2 strongly recommends that the System Designer use the PT = 21 methods for combining the Working and Protection time-slots into a single ODUk signal.

Please see the 2-Fibre/2-Lambda Shared-Ring Protection-Switching post for more information on this topic.

What Mapping/Multiplexing Schemes can one use for the PT = 21 Method for Mapping/Multiplexing ODUj Signals into an ODUk Signal?

I summarize the Mapping/Multiplexing scheme information for each of the PT = 21 Cases (for Mapping/Multiplexing Numerous Lower-Speed ODUj signals into a Higher-Speed ODUk signal) in Table 1 below.

Table 1, Summary of Schemes for Mapping/Multiplexing Multiple Lower-Speed ODUj Signals into a Higher-Speed ODUk Signal, PT = 0x21

ODUj Signal	Mapping Structure	Mapping Method	Number of ODUj Signals	Intermediate Structure	ODUk/OPUk Signal
ODU0	ODTU2.1	GMP	8	ODTUG2	ODU2/OPU2
ODUflex	ODTU2.ts	GMP	1 to 8	ODTUG2	ODU2/OPU2
ODU1	ODTU12	AMP	4	ODTUG2	ODU2/OPU2
ODU0	ODTU3.1	GMP	32	ODTUG3	ODU3/OPU3
ODUflex	ODTU3.ts	GMP	1 to 32	ODTUG3	ODU3/OPU3
ODU1	ODTU13	AMP	16	ODTUG3	ODU3/OPU3
ODU2	ODTU23	AMP	4	ODTUG3	ODU3/OPU3
ODU2e	ODTU3.9	GMP	3	ODTUG3	ODU3/OPU3
ODU0	ODTU4.1	GMP	80	ODTUG4	ODU4/OPU4
ODUflex	ODTU4.ts	GMP	1 to 80	ODTUG4	ODU4/OPU4
ODU1	ODTU4.2	GMP	40	ODTUG4	ODU4/OPU4
ODU2	ODTU4.8	GMP	10	ODTUG4	ODU4/OPU4
ODU2e	ODTU4.8	GMP	10	ODTUG4	ODU4/OPU4
ODU3	ODTU4.31	GMP	2	ODTUG4	ODU4/OPU4

I have also drawn out these cases below as well.

ODU0 ⇒ ODTU2.1 ⇒ ×8 ⇒ ODTUG2 ⇒ OPU2 ⇒ ODU2

This scheme will map/multiplex as many as 8 ODU0 signals into an ODU2 signal.

Figure 1, Simple Illustration of the ODU0 -> ODU2 Multiplexing/Mapping scheme

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

ODU1 ⇒ ODTU12 ⇒ ×4 ⇒ ODTUG2 ⇒ OPU2 ⇒ ODU2

This scheme will allow one to map/multiplex as many as 4 ODU1 signals into an ODU2 signal.

Figure 2, Simple Illustration of the ODU1 -> ODU2 Multiplexing/Mapping scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

ODUflex ⇒ ODTU2.ts ⇒ ×8/ts ⇒ ODTU2G ⇒ OPU2 ⇒ ODU2

This scheme will allow one to map/multiplex anywhere from 1 to 8 ODUflex signals into an ODU2 signal.

Figure 3, Simple Illustration of the ODUflex ⇒ ODU2 Multiplexing/Mapping scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

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

Corporate Discounts Available!!

ODU0 ⇒ ODTU3.1 ⇒ ×32 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 32 ODU0 signals into an ODU3 signal.

Figure 4, Simple Illustration of the ODU0 ⇒ ODU3 Mapping/Multiplexing scheme

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

ODU1 ⇒ ODTU13 ⇒ ×16 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 16 ODU1 signals into an ODU3 signal.

Figure 5, Simple Illustration of the ODU1 ⇒ ODU3 Mapping/Multiplexing scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

ODU2 ⇒ ODTU23 ⇒ ×4 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 4 ODU2 signals into an ODU3 signal.

Figure 6, Simple Illustration of the ODU2 ⇒ ODU3 Mapping/Multiplexing scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

ODU2e ⇒ ODTU3.9 ⇒ ×3 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex as many as 3 ODU2e signals into an ODU3 signal.

Figure 7, Simple Illustration of the ODU2e ⇒ ODU3 Mapping/Multiplexing scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

ODUflex ⇒ ODTU3.ts ⇒ ×32/ts ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

This scheme will allow one to map/multiplex anywhere from 1 to 32 ODUflex signals into an ODU3 signal.

Figure 8, Simple Illustration of the ODUflex ⇒ ODU3 Mapping/Multiplexing scheme.

Click on the figure above to learn more about this Mapping/Multiplexing scheme. (COMING SOON).

ODU0 ⇒ ODTU4.1 ⇒ ×80 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many 80 ODU0 signals into an ODU4 signal.

Figure 9, Simple Illustration of the ODU0 ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or click on the figure above to learn more about this Mapping/Multiplexing scheme.

ODU1 ⇒ ODTU4.2 ⇒ ×40 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 40 ODU1 signals into an ODU4 signal.

Figure 10, Simple Illustration of the ODU1 ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme. (*).

ODU2 ⇒ ODTU4.8 ⇒ ×10 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 10 ODU2 signals into an ODU4 signal.

Figure 11, Simple Illustration of the ODU2 ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme. (*).

ODU2e ⇒ ODTU4.8 ⇒ ×10 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 10 ODU2e signals into an ODU4 signal.

Figure 12, Simple Illustration of the ODU2e ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme. (*).

ODU3 ⇒ ODTU4.31 ⇒ ×2 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex as many as 2 ODU3 signals into an ODU4 signal.

Figure 13, Simple Illustration of the ODU3 ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/Multiplexing scheme. (*).

ODUflex ⇒ ODTU4.ts ⇒ ×80/ts ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

This scheme will allow one to map/multiplex anywhere from 1 to 80 ODUflex signals into an ODU4 signal.

Figure 14, Simple Illustration of the ODUflex ⇒ ODU4 Mapping/Multiplexing scheme.

Click HERE or Click on the figure above to learn more about this Mapping/ Multiplexing scheme. (*).

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

In Conclusion

In this posting, we briefly listed the characteristic of a PT = 21 scheme for Mapping/Multiplexing multiple lower-speed ODUj tributary signals into a higher-speed ODUk server signal.

We have also listed out each of the 14 PT = 21 schemes for Mapping/Multiplexing multiple lower-speed ODUj signals into a higher-speed ODUk signal.

Please check out the relevant post for similar information on PT = 20 schemes on Mapping/Multiplexing multiple lower-speed ODUj signals into a higher-speed ODUk signal.

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 Topics within this Blog

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

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.

STE – Section Terminating Equipment and
PTE – Path Terminating Equipment

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.

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.

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.

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.

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.

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.

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.

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 Topics within this Blog

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

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.

STE – Section Terminating Equipment and
PTE – Path Terminating Equipment

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.

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.
- FEC errors (correctable and uncorrectable)
- Defects or Failures (e.g., dLOF, dLOM, dTIM, dAIS, dIAE, dBIAE, dDEG, dLOL, dLOFLANE[j], dLOS-P and SM-BDI)
- Other errors (e.g., SM-BIP-8, SM-BEI)
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.

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.

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.

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.

For the Source STE
- OTUk/ODUk_A_So – OTUk to ODUk Adaptation Source Function
- OTUk_TT_So – OTUk Trace Termination Source Function
- OTSi/OTUk_A_So – OTSi to OTUk Adaptation Source Function (Single-Lane Applications)
- OTSiG/OTUk_A_So – OTSiG to OTUk Adaptation Source Function (Multi-Lane OTU3/OTU4 Applications)
For the Sink STE
- OTUk_TT_Sk – OTUk Trace Terminating Sink Function
- OTUk/ODUk_A_Sk – OTUk to ODUk Adaptation Sink Function
- OTSi/OTUk_A_Sk – OTSi to OTUk Adaptation Sink Function (Single-Lane Applications)
- OTSiG/OTUk_A_Sk – OTSiG to OTUk Adaptation Sink Function (Multi-Lane OTU3/OTU4 Applications)

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.

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 Topics within this Blog

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

What is OTUk-BIP-8 or SM-BIP-8?

This post describes the OTUk-BIP-8 (or Section Monitoring BIP-8) value for OTN applications. This post also describes how Networking Equipment both computes and transports this data over a fiber optic connection, as well as how Networking Equipment checks and identifies data transmission errors through the SM-BIP-8 parameter.

What is the OTUk-BIP-8 or Section Monitor (SM-BIP-8) Parameter, and How Do We Compute and Verify it?

This post will define and describe the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bit) parameter.

In particular, we will describe how the OTN uses this parameter to perform error detection at the OTUk layer.
Secondly, we will describe how a Transmitting OTUk Network Element (or a Source Section Terminating Equipment) computes and inserts the SM-BIP-8 Value into the OTUk data stream.
Third, we will describe how a Receiving OTUk Network Element (or a Sink Section Terminating Equipment) computes and verifies the SM-BIP-8 Value to check for data transmission errors.
Finally, we will discuss the results that a Receiving OTUk Network Element will come up with whenever it does compute and verify the SM-BIP-8 byte value.

NOTES:

From this point on, I will refer to the Transmitting OTUk Network Element as the Source STE (or Section Terminating Equipment). I will also refer to the Receiving OTUk Network Element as the Sink STE.
We discuss the SM-BIP-8 field extensively in Lesson 9 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

Introduction

For OTN applications, the OTUk layer supports Error Detection and Correction through two means.

FEC – Forward Error Correction and
BIP-8 – Bit Interleaved Parity – 8 bits

FEC is an Error Detection and Error-Correction scheme discussed in another post.

BIP-8 is purely an error-detection scheme. It does not support any error correction capabilities.

The OTUk, ODUk, and Tandem Connection Monitoring layers use the BIP-8 error detection scheme.

In this post, we will discuss (what we call) the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bits) scheme for the OTUk layer.

NOTE: We refer to this error detection scheme as SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bits) because this is the detection scheme that OTN Equipment would employ over a Section via STE (or Section Terminating Equipment).

Please see the post on Section Terminating Equipment for more information on this.

In another post, we discuss the PM-BIP-8 (Path Monitoring – Bit Interleaved Parity – 8 bits) scheme for the ODUk layer.

NOTE: In this post, we will interchangeably use the terms BIP-8, OTUk-BIP-8, and SM-BIP-8.

So How does the OTN use the SM-BIP-8 scheme?

In every connection between any two adjacent pieces of Networking Equipment, there is an entity that transmits data (e.g., the Source STE), and there is also an entity that receives that data (e.g., the Sink STE).

In most cases, two adjacent pieces of Networking Equipment will also be communicating with each other in a bi-directional manner.

This means that every piece of Network Equipment will transmit and receive data. This also means that every piece of Network Equipment will contain both a Source STE and a Sink STE.

For OTN application, any time a Source STE transports data to another Network Element via optical fiber or a copper medium, it must encapsulate this data into a series of back-to-back OTUk frames.

Please see the post on OTUk frames to learn more about the OTUk frame structure.

Brief Overview – How the Source STE creates and transports the SM-BIP-8 Byte Value

As the Source STE encapsulates its outbound (client and ODUk) data into a series of OTUk frames, it will perform various functions.

It will compute and append the FEC field to the back-end of each outbound OTUk frame.
It will compute and insert the SMOH (Section Monitoring Overhead) into each outbound OTUk frame. In particular, the Source STE will
- Insert the Trail Trace Message bytes into the TTI byte-field
- Set the BDI (Backward Defect Indicator) and IAE (Input Alignment Error) bit-fields to the appropriate values (depending upon Network Conditions)
- Set the BEI/BIAE nibble-field to the appropriate Value (depending upon Network Conditions).

Finally, the Source STE will compute an SM-BIP-8 value for each outbound OTUk frame.

Whenever the Source STE computes the SM-BIP-8 byte value, it will do so by performing a specific type of parity calculation over much of the data within the OTUk frame.

Afterward, the Source STE will insert this SM-BIP-8 byte value into the SMOH (Section Monitoring Overhead) within each outbound OTUk frame.

The Source STE will transport this data (e.g., the OTUk frame data and the SM-BIP-8 Value) over optical fiber to the remote Sink STE.

Brief Overview – How the Sink STE Receives and Processes the SM-BIP-8 byte Values

The Sink STE will accept and process this continuous stream of incoming OTUk frames that it is receiving from the remote Source STE.

As it processes this OTUk data stream, it will verify the SM-BIP-8 byte value within each OTUk frame it receives from the (Remote) Source STE.

The Sink STE verifies this data to check for any transmission errors that might have occurred as these OTUk frames travel from the (Remote) Source STE to the (Near-End) Sink STE.

As the Sink STE verifies this data, it will perform the same parity calculations on the data within the OTUk frames as the (remote) Source STE.

Afterward, the Sink STE will compare its “Locally-Computed” SM-BIP-8 byte value with that computed by the (remote) Source STE.

If the two values for the SM-BIP-8 byte match, then we can state that the Sink STE received the corresponding OTUk frame error-free.

On the other hand, if the two values for SM-BIP-8 do not match, then we know that the Sink STE has detected at least a one-bit error within this particular OTUk frame.

The Details – How does the Source STE generate the SM-BIP-8 Value?

Now that we have the Brief Introductory material out of the way, let’s discuss this in greater detail.

In this section, we will describe the following:

Exactly how the Source STE computes the SM-BIP-8 byte value, and
How it inserts this SM-BIP-8 byte into the OTUk data-stream, as it transmits this data to the remote Sink STE.

The Source STE and Introduction to the OTUk_TT_So Atomic Function

ITU-T G.798 refers to the Source STE, which is responsible for (among other things) computing and inserting the SM-BIP-8 Value into the OTUk SMOH as the OTUk_TT_So (OTUk Trail Termination Source) atomic function.

Please see the post on the OTUk_TT_So function to learn more about this atomic function.

NOTE: We will use the terms Source STE and the OTUk_TT_So function interchangeably throughout this post.

How do we perform a BIP-8 (Bit Interleaved Parity – 8 Bit) Calculation?

The OTUk_TT_So function will compute the SM-BIP-8 Value (for a given OTUk frame) over the data that resides within the OPU portion of that outgoing OTUk frame (e.g., byte-columns 15 through 3824).

Figure 1 presents an illustration that identifies that portion of the OTUk frame that the OTUk_TT_So function will use to perform the BIP-8 Calculations.

Figure 1, Illustration of that portion of the OTUk frame, which the OTUk_TT_So function will use for the Section Monitoring BIP-8 Calculation

NOTE: The OTUk_TT_So function will also include the OPU Overhead within these BIP-8 calculations.

This also means that the OTUk_TT_So function will compute the BIP-8 Value (4 x 3,810 =) 15,240 bytes within each outbound OTUk frame.

The OTUk_TT_So function will compute the BIP-8 Value over this 15,240-byte structure by effectively stacking all 15,240 bytes in a single byte-wide column, similar to what we show below in Figure 2.

Figure 2, Illustration of How the OTUk_TT_So function computes the BIP-8 Value

Figure 2 shows that the OTUk_TT_So function has (effectively) created a 15,240 row by an 8-bit column data structure.

The OTUk_TT_So function will then parse through each of the 8-bit columns within this data structure and compute the EVEN parity value for each of these bit-columns (over 15,240 bits).

Since there are 8-bit columns, the OTUk_TT_So function will compute eight individual EVEN parity bits (one for each bit-column).

This resulting set of the 8 EVEN parity bits is the SM-BIP-8 byte value for this particular OTUk frame.

This procedure describes how we perform a BIP-8 calculation over a block of data (such as the OPUk-portion of an OTUk frame).

How does one Source STE transport the SM-BIP-8 to another Network Element?

The OTUk_TT_So function will then take this BIP-8 byte value and insert it into the SM-BIP-8 byte field within the Section Monitoring field of the outbound OTUk frame, two frame periods later, as we show below in Figure 3.

Figure 3, Illustration of How the OTUk_TT_So function inserts the SM-BIP-8 byte values into the OTUk data-stream

The OTUk_TT_So function adds this 2-frame delay to give the Sink STE (at the remote terminal) enough time to compute and verify the SM-BIP-8 byte value (at its end).

Figures 4 and 5 together present the exact location of the SM-BIP-8 byte-field within each outbound OTUk frame.

Figure 4 illustrates the OTUk frame format, with the Section Monitoring (SM) field highlighted.

Figure 4, Illustration of the OTUk Frame with the Section Monitoring (SM) field highlighted

And Figure 5 presents an illustration of the Section Monitoring (SM) field with the SM-BIP-8 byte-field highlighted.

Figure 5, Illustration of the Section Monitoring (SM) field, with the BIP-8 byte-field highlighted

The OTUk_TT_So function will transmit this OTUk data stream (along with the locally-computed SM-BIP-8 byte value) to the remote terminal equipment.

We will discuss below how the Remote Sink STE receives and processes these OTUk frames and their SM-BIP-8 values.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

What does the Sink STE do with the SM-BIP-8 Value?

The Sink STE performs the exact opposite role, as does the Source STE.

The Sink STE and Introduction to the OTUk_TT_Sk atomic function

ITU-T G.798 refers to the entity that (among other things) computes and verifies the SM-BIP-8 byte values (for each OTUk frame) as the OTUk_TT_Sk (OTUk Trail Termination Sink) atomic function.

Please see the post on the OTUk_TT_Sk function to learn more about this atomic function.

NOTE: We will use the terms Sink STE and OTUk_TT_Sk function interchangeably throughout the remainder of this post.

I stated earlier that the OTUk_TT_Sk function has the exact opposite role, as does the OTUk_TT_So function.

The OTUk_TT_Sk function verifies the SM-BIP-8 byte value for each OTUk frame it receives from the remote Source STE (OTUk_TT_So Function).

Once again, the purpose of having the OTUk_TT_Sk function check and verify the SM-BIP-8 byte values is to check for the occurrence of bit errors within the OTUk data stream as it travels from the OTUk_TT_So function (within the Source STE), across optical fiber, to the OTUk_TT_Sk function (within the Sink STE).

Figure 6 presents a simple illustration of an OTUk_TT_So function transporting this OTUk data stream to the OTUk_TT_Sk function at the remote terminal.

Figure 6, Illustration of the OTUk_TT_So function transporting an OTUk data-stream to the OTUk_TT_Sk function (at the remote terminal)

For your reference, the circuitry (that I show above) in Figure 6 is functionally equivalent to the Network Element connections I show below in Figure 7.

Figure 7, Illustration of the Equivalent Circuitry (in Figure 6), expressed at the Network Element Layer.

We will describe how the OTUk_TT_Sk function computes and verifies the SM-BIP-8 byte value within each incoming OTUk frame.

The OTUk_TT_Sk function computes and verifies these SM-BIP-8 byte values by executing the following two steps to process each OTUk frame it receives.

Step 1 – The OTUk_TT_Sk function will locally compute its SM-BIP-8 byte value for an incoming OTUk frame, and
Step 2 – The OTUk_TT_Sk function will then compare its locally-computed BIP-8 byte value with that which the OTUk_TT_So function (at the Remote STE) inserted into the SM-BIP-8 byte field within the incoming OTUk data-stream.

We will discuss each of these steps below.

STEP 1 – The OTUk_TT_Sk function will locally compute Its sm-BIP-8 byte value for an incoming OTUk frame.

The OTUk_TT_Sk function will locally compute its SM-BIP-8 byte value for an incoming OTUk frame by performing the same procedure that the OTUk_TT_So function did at the remote terminal (Source STE).

The OTUk_TT_Sk function will take the 15,240 bytes of data (that resides within the OPU portion of the OTUk frame), and it will (effectively) stack this data into a 15,240-row x 8-bit column structure.

Figure 8 (once again) presents a simple illustration of an OTUk frame, with the OPU portion (e.g., that portion of the OTUk frame that we use to compute the BIP-8 Value) highlighted.

Figure 8, A Simple Illustration of the OTUk Frame, with the OPU-Portion of the Frame, Highlighted.

And if we were to look at this data differently, Figure 9 presents an illustration of the 15,240 Row by 8-bit column structure that the OTUk_TT_Sk function effectively creates from the OPU portion of each incoming OTUk frame.

Figure 9, Illustration of How the OTUk_TT_Sk Computes the SM-BIP-8 byte value for each incoming OTUk frame

The OTUk_TT_Sk function will then parse through each 8-bit column (shown above in Figure 9) individually and compute the EVEN parity of the contents within each bit-column.

Note that it will perform parity calculations over 15,240 bits of data.

Once the OTUk_TT_Sk function has completed this process over each of the eight bit-columns, it will have an 8-bit expression.

This 8-bit expression is (once again) the SM-BIP-8 byte value for this particular OTUk frame.

After the OTUk_TT_Sk function computes its version of the SM-BIP-8 byte value, it needs to perform STEP 2 (of this BIP-8 Verification Process).

STEP 2 – The OTUk_TT_Sk function will compare its Locally-Computed BIP-8 Value with that inserted into the BIP-8 field (by the OTUk_TT_So function at the remote STE).

Once the OTUk_TT_Sk function reads in the contents of an OTUk frame and locally computes its SM-BIP-8 byte value (for that OTUk frame), it then needs to obtain the Value of the remotely-computed SM-BIP-8 byte-field.

If you recall, earlier in this post, I mentioned that the OTUk_TT_So function (at the remote terminal) would compute the SM-BIP-8 byte value for a given OTUk frame, and then it will insert this BIP-8 Value into the SM-BIP-8 byte-field, two OTUk frames later.

I show this relationship between the OTUk frame (that the OTUk_TT_So function computed the SM-BIP-8 byte value for) and its placement within the OTUk data stream above in Figure 3.

Therefore, the OTUk_TT_Sk function will find this remotely-computed SM-BIP-8 byte value for a given OTUk frame, two (2) OTUk frames later, within the SM-BIP-8 byte-field position.

Once the OTUk_TT_Sk function has obtained these two versions of the SM-BIP-8 byte values, it will then need to compare those two values with each other.

If the two BIP-8 byte-values are equal, then this means that this particular OTUk frame incurred no bit errors during transmission over the optical fiber.

On the other hand, if these two BIP-8 byte values are NOT the same, this particular OTUk frame DID incur bit errors during transmission over optical fiber to the Sink STE.

In this case, the OTUk_TT_Sk function must determine how many bits (between these two versions of the SM-BIP-8 byte values) are different from each other.

Stated differently, the OTUk_TT_Sk function compares its locally computed SM-BIP-8 byte value and that it reads in from the SM-BIP-8 byte-field within the incoming OTUk data-stream and will perform a bit-by-bit XOR operation with each of these byte values.

The OTUk_TT_Sk function must then count the number of “1s” that occurs during that bit-wise XOR calculation (for each incoming OTUk frame).

The OTUk_TT_Sk function will come up with any one of the following nine (9) possible results.

0 bits in Error – Error-Free Transmission
1 bit in Error
2 bits in Error
3 bits in Error
4 bits in Error
5 bits in Error
6 bits in Error
7 bits in Error
8 (or all) bits in Error

Figure 10 presents a simple illustration of the Bit-Wise XOR Operation that the OTUk_TT_Sk function performs with both the locally-computed and remotely-computed SM-BIP-8 byte values.

Figure 10, Illustration of the Bit-Wise XOR Process for Verifying and Comparing the Locally-Computed SM-BIP-8 Byte Value with the Extracted (Remotely Computed) SM-BIP-8 Byte value for a given OTUk frame

The OTUk_TT_Sk function will then need to use the results of these BIP-8 comparisons for the following purposes.

To send out the results of these comparisons to the remote terminal in the form of the SM-BEI (Section Monitor – Backward Error Indicator) Value. Please see the post on SM-BEI to learn more about this topic.
It will use these results to determine if the OTUk_TT_Sk function should declare or clear the dDEG (Signal Degrade) defect condition. (*)
To use for Performance Monitoring Purposes (e.g., to compute the pN_EBC parameter in this case). Please see the post on the pN_EBC (Near-Error Block Count) Performance Monitor parameter to learn more about this topic.

Will the OTN Network Element ever declare any defects due to excessive SM-BIP-8 errors?

Yes, if the Sink STE were to detect a large number of SM-BIP-8 byte errors over a long period (e.g., typically on the order of seconds), then the Sink STE (or OTUk_TT_Sk Function) can declare the dDEG (Signal Degrade) defect condition.

I describe how the OTUk_TT_Sk atomic function declares and clears the OTUk-dDEG (Signal Degrade) defect condition within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!

Summary

This post describes the SM-BIP-8 (Section Monitoring – Bit Interleaved Parity – 8 bit) parameter.

At a high level, we have described how the OTN uses this parameter to perform error detection at the OTUk layer.

We have also specifically described how a Source STE computes and inserts the SM-BIP-8 byte value into the OTUk data stream.

We have also described how a Sink STE computes and verifies the SM-BIP-8 byte value (within each incoming OTUk frame) to check for the occurrence of data transmission errors.

Finally, we have identified the results that a Sink STE will come up with whenever it does compute and verify the SM-BIP-8 byte value. We also mentioned that the Sink STE would use these results to:

Determine if the Sink STE should declare or clear the dDEG (Signal Degrade) defect condition.
Support the generation of Performance Monitor reports for the pN_EBC (Near-End Error Block Count) parameter to System-Level Management.
Support the generation and transmission of the SM-BEI (Section Monitoring – Backward Error Indicator) parameter within the OTUk data stream.

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 Topics within this Blog

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

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.

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 Topics within this Blog

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

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.

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.

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 Topics within this Blog

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

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)

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.

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.

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.

dTIM – Trail Trace Identification Mismatch Defect(*)
dAIS – OTUk-AIS Defect
dLOF – Loss of Frame Defect
dLOM – Loss of Multiframe Alignment Defect
dLOS-P/dLOS-P[i] – Loss of Signal – Payload Defect
dLOFLANE[j] – Loss of Frame – Lane Signal Defect (OTL3.4 and OTL4.4 Applications)(*)
dLOL – Loss of Lane Alignment (OTL3.4 and OTL4.4 Applications)(*)

(*) – 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.

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

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

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

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

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 Topics within this Blog

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

What is 1:N Protection Switching?

This post defines and describes the 1:n Protection Switching architecture.

What is the 1:n Protection Switching Architecture?

ITU-T G.808 defines the “1:n (protection) architecture (n >= 1) as:

A 1:n protection architecture has n normal traffic signals, n working transport entities, and one protection transport entity.

It may have an extra traffic signal.

At the source end, a normal traffic signal is either permanently connected to its working transport entity and may be connected to the protection transport entity (in the case of a broadcast bridge) or is connected to either its working or protection transport entity (in the case of a selector bridge).

The sink-end can select the normal traffic signal from either the working or the protection transport entity.

An unprotected extra traffic signal can be transported via the protection transport entity whenever the protection transport entity is not used to carry a normal traffic signal.

What Does All This Mean?

As for all Protection Groups, a 1:n Protection Architecture consists of the following elements:

n instances of the Head-End (or Source-End)
n instances of the Tail-End (or Sink-End)
and n separate Normal Traffic Signals
n sets of Working Transport entities
a single Protect Transport entity
a single Extra Traffic Signal
Protection Switching Controller (that can detect and declare defects within the Normal Traffic Signals).
An APS Communications Link/Protocol (Required)

Figure 1 shows a variation of the 1:n Protection Switching architecture.

In this case, we show a 1:2 Protection Switching Architecture.

Figure 1, Illustration of a 1:2 Protection Switching Architecture

This figure shows that a Broadcast Bridge realizes each of the two Head-Ends (of this Protection Group). We realize each of the two Tail-ends by a Selector Switch.

I have designated the Broadcast Bridges with the Blue Overlay Shading in this figure.

Likewise, I have designated the Selector Switches with the Red Overlay shading.

NOTES:

The user can also opt to realize the Head-ends with a Selector Switch for the 1:n Protection Switching Architecture.
Figure 1 includes some other bells and whistles (in the form of some additional Selector Switches) that I will discuss later in this blog.

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

Corporate Discounts Available!!!

How does the 1:n Protection Switching Architecture Work?

One of the noteworthy features of a 1:n Protection Switching Architecture is that you have a single Protection Transport entity that protects n Normal Traffic Signals.

This means that for the 1:n Protection Switching Architecture, you only need 1/n more bandwidth to transport the n Normal Traffic Signals in a protected manner, from the Head-ends to the Tail-ends (where n is the total number of Normal Traffic Signals that you are transporting via this Protection Group).

In contrast, for a 1+1 Protection Switching Architecture, you have one Protection Transport entity protecting one Normal Traffic Signal.

This means that we are providing the Normal Traffic Signal with twice the bandwidth required to transport this signal from the Head-End to the Tail-End in a protected manner.

For many applications, this is inefficient, expensive, and inconvenient.

Of course, this same ratio would also hold if you used a 1:1 Protection Switching Architecture.

Another Key Characteristic of a 1:N Protection Architecture

Another critical characteristic of a 1:N Protection Architecture is the use of Broadcast Bridges on the Head-End Circuitry. In contrast to a Permanent Bridge, during No-Defect Operation, there will not be a hardwired connection between the Normal Traffic Signal and the Working and Protection Transport entities. There is only the connection between the Normal Traffic Signal and the Working Transport Entity. When we are required to perform Protection-Switching, we will close the Broadcast Bridges and complete the electrical connection between the Normal Traffic Signal and the Protection Transport entity.

We will discuss how the 1:n Protection Switching Architecture works by examining the following cases/conditions.

The Normal (No Defect) Case
A service-affect defect occurring Working Transport entity # 1
Protection Switching (after the defect has been declared).
The Normal (No Defect) Case – also using the Extra Traffic Signal

The Normal (No Defect) Case

Figure 2 shows a drawing of the Normal (No Defect) Case.

In this case, we have two Network Elements that are exchanging data with each other.

One Network Element (which we labeled Network Element West) is transmitting data to another Network Element (which we labeled Network Element East).

In most actual applications, we would also have traffic going in the opposite direction (East to West).

But, to keep these figures simple, we are only showing one direction of traffic in each of the figures in this post.

In Figure 2, Normal Traffic Signal # 1 travels over Working Transport entity # 1.

Likewise, Normal Traffic Signal # 2 travels over Working Transport entity # 2.

Additionally, the Extra Traffic Signal is traveling over the Protection Transport entity.

There are no impairments on any of the Working Transport entities, and everything is expected in this case.

Figure 2, Illustration of the Normal (No Defect) Case

A Service-Affecting Defect occurs in Working Transport entity # 1

Now, let us assume that an impairment occurs in Working Transport entity # 1, such that some circuitry (sitting within the Tail-End of this Working Transport entity, within Network Element East) is declaring either a service-affecting defect such as SF (Signal Fail) or the signal degrade defect, such as SD (Signal Degrade).

In this case, Normal Traffic Signal # 1 can no longer travel on the Working Transport entity # 1.

Figure 3 shows a drawing of this condition.

Figure 3, Illustration of a Service-Affecting Defect Occurring in Working Transport Entity # 1

Protection Switching – After the Defect (in Working Transport Entity # 1) has been declared

Now, since the Tail-End circuitry of Working Transport entity # 1, within Network Element East) has declared this defect condition, it needs to invoke Protection Switching.

In particular, this circuitry needs to perform the following four tasks.

The circuitry within Network Element East needs to switch the local Selector Switch, which I’ve labeled SE1 (at the Tail-End of Working Transport entity # 1), away from this (now failed) Working Transport entity over to selecting the Protection Transport entity.
The Network Element East circuitry also needs to send a command across the Transport entities back to the upstream Network Element (e.g., Network Element West). In this case, Network Element East will also command Network Element West to invoke Protection Switching (for Working Transport entity # 1).
Next, Network Element West (after it has received this command from Network Element East) then needs to command the Broadcast Switch, which I’ve labeled BBW1 (at the Head-end of Working Transport Entity # 1) to switch such that Normal Traffic Signal # 1 is now also connected to the Protection Transport entity.
Finally, Network Element West needs to pre-empt the Extra Traffic signal by opening the switch that I’ve labeled SWP. Once this switch is OPEN, the Extra Traffic signal will no longer travel across the Protection Transport entity.

In this case, Normal Traffic Signal # 1 will now travel (from Network Element West to Network Element East) using the Protect Transport entity.

Figure 4 presents the resulting configuration (with Network Elements East and West) after protection switching.

Figure 4, Illustration of our 1:2 Protection Switching Protect Group, following Protection Switching

NOTE: Protection Groups using the 1:n Protection Switching scheme are required to support an APS Communications Channel to command and coordinate Protection Switching activities between the Head-ends and Tail-ends of the Protection Group.

This is how 1:N Protection Switching works.

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

Discounts Available for a Short Time!!

Additional Options in the 1:n Protection Switching Architecture

There are several options that users can use when designing a 1:n protection switching scheme.

Some of these options include:

Transmitting the NULL Signal during the Normal (No Defect) Case – as the Extra Traffic signal.
Transmitting the FDI/AIS signal during Protection Switching
Revertive Protection Switching
Unidirectional or Bidirectional protection switching

We will briefly discuss each of these options below.

Transmitting the NULL Signal during the Normal (No Defect) Case – as the Extra Traffic Signal.

In some cases, the user can transmit the NULL signal as the Extra Traffic signal (via the Protect Transport entities) anytime each of the n Working Transport entities is defect-free and is functioning properly.

In the Protection Group (discussed in this post), we could close the Switch labeled SN and open the Switch labeled SWP (within Network Element West).

This configuration setting would allow the NULL signal (that originates from Network Element West) to flow through the Protect Transport entity, as shown in Figure 5.

Figure 5, Transmitting the NULL Signal via the Protect Transport Entity, during Standby Times.

Transmitting the FDI/AIS signal during Protection Switching

In many cases, the user will transmit the FDI/AIS signal towards the circuitry downstream from Network Element East by switching the switch, which I’ve labeled SEP (within Network Element East), away from the Protect Transport entity towards the FDI/AIS signal source.

Figure 4 (above) shows Network Element East transmitting the FDI/AIS indicator towards downstream traffic during Protection Switching.

The user would typically only do this whenever the Extra Traffic Signal (e.g., the NULL signal or some other low-priority signal) has been pre-empted due to a Protection Switching event.

The purpose of transmitting this FDI/AIS signal is to alert downstream equipment of a service-affecting defect condition within one of the Working Transport entities between Network Elements East and West.

NOTE: For OTN applications, the Network Element will transmit the ODUk-AIS indicator during these protection switching events.

Revertive Protection Switching

Some Protection Groups will support Revertive operations, and others will not.

Suppose you designed a Protection Group to support Revertive operations. In that case, the Protection Group will automatically reroute the affected Normal Traffic Signal back through its Working Transport entity shortly after the servicing-affecting defect (which caused the protection switching event in the first place) has cleared.

1:n Protection Switching systems typically support Revertive operations, whereas 1+1 Protection Switching systems may NOT support Revertive operations.

If a 1:n Protection Switching system was to support Revertive operations, then the Network Element that first declared (and is now clearing) the service-affecting defect; would have to send a command back to the other (remote) Network Element to coordinate revert protection switching activities (between both the Head-Ends and Tail-Ends of the Protection Group).

Please see the post on the Revertive Operation and the Automatic Protection Switching Channel for more details on this topic.

Unidirectional or Bidirectional Protection Switching

A 1:n Protection Switching scheme can support either Unidirectional or Bidirectional Protection Switching.

If the Protection Group supports Unidirectional Protection Switching, then the Network Element (that detects and declares the Service-Affecting defect within one of the Working Transport entities) will need to send the necessary command information (back to the upstream Network Element) to command and coordinate the Unidirectional Protection Switching event.

Conversely, suppose the Protection Group supports Bidirectional Protection Switching. In that case, the Network Element (that detects and declares the Service-Affecting defect) will need to send the necessary command information (back to the upstream Network Element) to command and coordinate the Bidirectional Protection Switch.

Please see the posts for Unidirectional and Bidirectional Protection Switching for more details on this topic.

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!!

Click on the Image Below to see more Protection-Switching related content on this 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) ...

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is the OTUk/ODUk_A_So Atomic Function?

Introduction

Functional Block Diagram for the OTUk/ODUk_A_So Function

Interfaces within the OTUk/ODUk_A_So Function

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

Corporate Discounts Available!!

So What Does This Function Do?

Optionally Generates the ODUk-LCK Maintenance Signal

Allows User to Insert APS (Automatic Protection Switching) Commands into the APS Channel (within the ODUk-PMOH).

Generates OTUk Clock, FS (Frame Start), and MFS (Multi-Frame Start) Signals via the OTUk_AP Interface

Generates the IAE (Input Alignment Error) Indicator for the downstream OTUk_TT_So function

Generate and Route the OTUk Data-Stream to downstream circuitry

List of Input and Output Signals for the OTUk/ODUk_A_So Function

Has Inflation got You Down? Our Price Discount 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.

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is an Atomic Function for OTN Applications?

OK, So What are these Atomic Functions?

OK, So Why bother with these Atomic Functions?

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

Adaptation Functions

Another Way to Identify an Adaptation Function?

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

Corporate Discounts Available!!!

Trail-Termination Functions

Another way to Identify a Trail-Termination Function?

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.

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is PT (Payload Type) = 0x21 for OTN Applications, and what does it Mean?

What is the PT = 21 Method?

Is the PT = 21 Method better than PT = 20 Method?

What Mapping/Multiplexing Schemes can one use for the PT = 21 Method for Mapping/Multiplexing ODUj Signals into an ODUk Signal?

ODU0 ⇒ ODTU2.1 ⇒ ×8 ⇒ ODTUG2 ⇒ OPU2 ⇒ ODU2

ODU1 ⇒ ODTU12 ⇒ ×4 ⇒ ODTUG2 ⇒ OPU2 ⇒ ODU2

ODUflex ⇒ ODTU2.ts ⇒ ×8/ts ⇒ ODTU2G ⇒ OPU2 ⇒ ODU2

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

Corporate Discounts Available!!

ODU0 ⇒ ODTU3.1 ⇒ ×32 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

ODU1 ⇒ ODTU13 ⇒ ×16 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

ODU2 ⇒ ODTU23 ⇒ ×4 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

ODU2e ⇒ ODTU3.9 ⇒ ×3 ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

ODUflex ⇒ ODTU3.ts ⇒ ×32/ts ⇒ ODTUG3 ⇒ OPU3 ⇒ ODU3

ODU0 ⇒ ODTU4.1 ⇒ ×80 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

ODU1 ⇒ ODTU4.2 ⇒ ×40 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

ODU2 ⇒ ODTU4.8 ⇒ ×10 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

ODU2e ⇒ ODTU4.8 ⇒ ×10 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

ODU3 ⇒ ODTU4.31 ⇒ ×2 ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

ODUflex ⇒ ODTU4.ts ⇒ ×80/ts ⇒ ODTUG4 ⇒ OPU4 ⇒ ODU4

In Conclusion

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.

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

What is the Path?

Non-OTN Client Signal Path

A Closer Look at the Non-OTN Client SIGNAL 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)

Handling the 1000BASE-X/OPU0/ODU0 Signals

Handing the OPU4/ODU4 Server Signal

How the PTE Operates in the Optical Transport Network

In the Transmit Direction

In the Receive Direction

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

Generating the ODUk Overhead (ODUk-PMOH)

Terminating the OPUk Overhead

Important Takeaway

De-Mapping the Client Signal from the OPUk Payload

Examples of PTE

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

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.

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

What is a Section?

What is an STE (Section Terminating Equipment)?

The Source STE Operation In the Transmit Direction

Sink STE Operation In the Receive Direction

What is the OTUk/ODUk_A_So Atomic Function?

What is an Atomic Function for OTN Applications?

What is PT (Payload Type) = 0x21 for OTN Applications, and what does it Mean?

What is the OTUk-BIP-8 or Section Monitor (SM-BIP-8) Parameter, and How Do We Compute and Verify it?

What Is the ODUk-LCK Maintenance Signal?

What exactly is an ODUk-OCI Maintenance Signal?

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