Lesson 2 – ODU Framing

This post provides a comprehensive review and video training of the ODU frame and its overhead fields.

Lesson 2 – ODU (Optical Data Unit) Frame Training

This post presents a video that discusses the ODU (Optical Data Unit) Frame in considerable detail.  

In addition to discussing the ODU frame format, this video also discusses the ODU overhead fields and their roles as well.

Finally, this video discusses special ODUk signals, such as ODU0, ODU2e and ODUflex.  

Continue reading “Lesson 2 – ODU Framing”

What are Consequent Equations?

This post briefly defines and describes Consequent Equations that ITU-T G.798 uses for OTN Applications.

What are Consequent Equations and How Should You Interpret Them?  

The purpose of this blog post is two-fold.

  • To describe the concept of Consequent Equations and
  • To discuss how we can use and interpret these Consequent Equations.

Introduction

Many ITU Standards (such as ITU-T G.798 for OTN Applications) will discuss many aspects of defects.  These standards will define a defect, such as dAIS (Alarm Indication Signal), dLOM (the Loss of Multi-frame) defect.  

These same standards will also define the criteria that an OTN Network Element (be it an STE or PTE) should use to declare or clear a given defect.  

For example, ITU-T G.798 specifies all of the following defects that an OTN STE can declare and clear.

And that’s all well and good.  

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

How should an STE/PTE Respond Whenever it Declares a Defect?  

However, what else should an STE do whenever it declares (for example) the dLOF defect condition?  

Does this STE have a responsibility to notify other STEs of this defect?  

Similarly, what else should a PTE do whenever it declares (for example) the dTIM (ODUk-TIM) defect condition?  

Again, does this PTE have a responsibility to notify other nearby PTEs of this defect?

The short answer to both of these questions is “Yes, for those specific defects, that I mentioned, they do have a responsibility to notify upstream and downstream equipment of the occurrence of those defect conditions“.

However, to make things more confusing, the PTE/STE are required to notify upstream and downstream PTE/STE whenever some defects occur, but not others.  

How Do We Sort out This Confusion?  

The Answer:  Consequent Equations.  

Let’s assume that a certain STE is declaring the dLOF Defect condition, as we show below in Figure 1.

Consequent Equation - OTSi/OTUk_A_Sk function declares the dLOF defect

Figure 1, Illustration of the STE (e.g., the OTSi/OTUk-a_A_Sk Atomic Function) declares the dLOF defect condition.

What happens next?

At this point, let’s write down the Consequent Equation that pertains to this STE (or the OTSi/OTUk-a_A_Sk function in this case):

aSSF <- dLOS-P or dAIS or dLOF or dLOM or AI_TSF-P

Where:

aSSF is the current state of the CI_SSF output pin (of the OTSi/OTUk-a_A_Sk function).

dLOS-P is the current state of the Loss of Signal-Path Defect condition

dAIS is the current state of the OTUk-AIS Defect Condition

dLOF is the current state of the Loss of Frame Defect Condition

dLOM is the current state of the Loss of Multi-Frame Defect Condition, and 

AI_TSF-P is the current (logical) state of the AI_TSF-P input pin (to the OTSi/OTUk-a_A_Sk atomic function).  

This consequent equation states that the STE (or OTSi/OTUk-a_A_Sk function) will assert its CI_SSF output pin, anytime it declares any of the following defect condition:

This consequent equation also states that the STE (the OTSi/OTUk-a_A_Sk function) will assert the CI_SSF output pin, anytime the upstream function asserts the AI_TSF input to this function.  

NOTE:  Please see the OTSi/OTUk_A_Sk Function Post for more information about this particular Atomic Function.  

So What Does All of This Mean?

In Figure 2, I show the OTSi/OTUk_A_Sk function now asserting its CI_SSF output pin, because it is currently declaring the dLOF defect condition.  

Consequent Equation - OTSi/OTUk_A_Sk function asserts CI_SSF due to dLOF defect

Figure 2, Illustration of the OTSi/OTUk_A_Sk Atomic Function asserting its CI_SSF output, because it is currently declaring the dLOF defect condition.  

Please note that the CI_SSF output (from the OTSi/OTUk_A_Sk function) is connected to the CI_SSF input of the (downstream) OTUk_TT_Sk function.  

OK, that’s great.  The above Consequent Equation states that the STE (e.g., the OTSi/OTUk_A_Sk function will assert the CI_SSF output pin whenever it declares the dLOF defect.  

How does that alert any other STE/PTE of the OTSi/OTUk_A_Sk function declaring the dLOF defect?

Answer:  There is more to this, and it involves more Consequent Equations.  

Let’s Take a Look at the Downstream Circuitry

Let’s now take a look at the OTUk_TT_Sk and OTUk/ODUk_A_Sk Atomic Functions (which are both downstream from the OTSi/OTUk_A_Sk function).  

In Figure 3, I show both the OTUk_TT_Sk and the OTUk/ODUk_A_Sk Atomic Functions. 

I also show that the upstream (OTSi/OTUk_A_Sk function) circuitry is now asserting the CI_SSF input (to the OTUk_TT_Sk function) – as we described above.  

Consequent Equations - Upstream Circuitry asserts CI_SSF input to the OTUk_TT_Sk function

Figure 3, Illustration of both the OTUk_TT_Sk and OTUk/ODUk_A_Sk functions – with upstream circuitry asserting the CI_SSF input pin.

Now, the OTUk_TT_Sk Atomic Function happens to have two sets of Consequent Equations:

I will list each of these equations below.

  • aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))
  • aBDI <- CI_SSF or dAIS or dTIM

I will explain each of these equations below.  

The First Consequent Equation – OTUk_TT_Sk Function

Let’s start with the first Consequent Equation for the OTUk_TT_Sk function.

aTSF <- CI_SSF or dAIS or (dTIM and (NOT TIMActDis))

Where:

aTSF is the current state of the AI_TSF output of the OTUk_TT_Sk Atomic Function.

CI_SSF is the current state of the CI_SSF input of the OTUk_TT_Sk Atomic Function.  

dAIS is the current state of the dAIS defect condition, and 

dTIM is the current state of the Trail Trace Identifier Mismatch Defect Condition.  

This Consequent Equation states that the OTUk_TT_Sk Atomic Function should assert the AI_TSF output signal anytime it declares any of the following defect conditions.

  • dTIM – Trail Trace Identifier Mismatch Defect
  • dAIS – AIS Defect

This Consequent Equation also states that the OTUk_TT_Sk function should assert the AI_TSF output whenever the upstream circuitry (eg., the OTSi/OTUk_A_Sk function) asserts the CI_SSF input pin.  

In Figure 4, I show the OTUk_TT_Sk function asserting its AI_TSF output pin because the upstream OTSi/OTUk_A_Sk function is asserting the CI_SSF input pin (to this function).  

Consequent Equation - OTUk_TT_Sk Atomic Function asserts AI_TSF due to CI_SSF being asserted

Figure 4, The OTUk_TT_Sk Atomic Function asserts the AI_TSF output pin, because the upstream OTSi/OTUk_A_Sk function is asserting its CI_SSF input pin.  

OK, now let’s take a look at the second Consequent Equation for the OTUk_TT_Sk Function.

The Second Consequent Equation – OTUk_TT_Sk Function

aBDI <- CI_SSF or dAIS or dTIM

Where:  

aBDI is the state of the RI_BDI output (of the Remote Port Interface) of the OTUk_TT_Sk function.  

We have already defined CI_SSF, dAIS and dTIM earlier in this post.  

Therefore, this Consequent Equation states that the OTUk_TT_Sk function will assert the RI_BDI output pin anytime it declares the dAIS or dTIM defect conditions.

This equation also states that the OTUk_TT_Sk function will also assert the RI_BDI output pin anytime the upstream circuitry asserts the CI_SSF input (to the OTUk_TT_Sk function).  

If you recall from the OTUk_TT_So and OTUk_TT_Sk posts, I state that anytime the OTUk_TT_Sk function asserts the RI_BDI output pin, it will command its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back out to the remote end.

I show this phenomenon below in Figure 5.  

Consequent Equation - OTUk_TT_Sk function asserts RI_BDI due to CI_SSF

Figure 5, The OTUk_TT_Sk function asserts its RI_BDI output pin, commanding its Collocated OTUk_TT_So function to transmit the BDI (Backward Defect Indicator) back to the upstream STE because its CI_SSF being driven HIGH

In Figure 5, we show that, because the STE (OTSi/OTUk_A_Sk function) declared the dLOF defect, the downstream OTUk_TT_Sk function responded by command its collocated OTUk_TT_So function to transmit the OTUk-BDI indicator back to the upstream STE (the source of the defective OTUk signal).  

However, we’re not done yet.  

Since the OTUk_TT_Sk function is also asserting its AI_TSF output, this means that it is also asserting the AI_TSF input to the (down-stream) OTUk/ODUk_A_Sk atomic function.  

Let’s move on to the OTUk/ODUk_A_Sk Atomic Function

As you can see, in Figure 5, the OTUk_TT_Sk function, by asserting its own AI_TSF output pin, is also asserting the AI_TSF input pin to the OTUk/ODUk_A_Sk function.  

And, the OTUk/ODUk_A_Sk function comes with a couple of Consequent Equations of its own.  

  • aSSF <- AI_TSF and (not MI_AdminState = LOCKED), and
  • aAIS <- AI_TSF and (not MI_AdminState = LOCKED)

Let’s take each of these equations, one at a time.

The First Consequent Equation – OTUk/ODUk_A_Sk Function

aSSF <- AI_TSF and (not MI_AdminState = LOCKED)

Where:  

aSSF is the current state of the CI_SSF output pin (from the OTUk/ODUk_A_Sk function).

AI_TSF is the current state of the AI_TSF input pin to the OTUk/ODUk_A_Sk function, and

MI_AdminState reflects the current state of the MI_AdminState input signal (which the System Operator can set).

This Consequent Equation states that the OTUk/ODUk_A_Sk function will automatically assert its CI_SSF output signal, whenever the upstream circuitry asserts its AI_TSF input, provided that the System Operator has not put the OTUk/ODUk_A_Sk function into the LOCKED state.  

In Figure 6, I show the OTUk/ODUk_A_Sk function asserting its CI_SSF output pin because the upstream circuitry is asserting its AI_TSF input pin.  

Consequent Equations - OTUk/ODUk_A_Sk function asserts its CI_SSF output pin

Figure 6, The OTUk/ODUk_A_Sk function asserts its CI_SSF output pin because the upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF input pin.

I should also point out, that APS (Automatic Protection Switching) systems will often trigger (and start protection switching) whenever the OTUk/ODUk_A_Sk function asserts its CI_SSF output pin.  

Now, let’s move on to the next Consequent Equation.  

The Second Consequent Equation – OTUk/ODUk_A_Sk Function

aAIS <- AI_TSF and (not MI_AdminState = LOCKED)

Where:

aAIS is the current state of the ODUk-AIS Maintenance Signal

If aAIS = TRUE, then this means that the OTUk/ODUk_A_Sk function is overwriting its output signal with the ODUk-AIS Maintenance signal.

Conversely, if aAIS is FALSE, then this means that the OTUk/ODUk_A_Sk function is transmitting an ODUk data-stream, that is carrying regular client traffic.  

Therefore, this Consequent Equation states that the OTUk/ODUk_A_Sk function will transmit the ODUk-AIS Maintenance Signal, anytime the upstream circuitry pulls its AI_TSF input TRUE; provided that the System Operator has NOT put the OTUk/ODUk_A_Sk function into the LOCKED State.

In Figure 7, I show an illustration of the OTUk/ODUk_A_Sk function transmitting the ODUk-AIS Maintenance Signal, because upstream circuitry (e.g., the OTUk_TT_Sk and OTSi/OTUk_A_Sk functions) is asserting its AI_TSF  input.  

Consequent Equation - OTUk/ODUk_A_Sk function transmits ODUk-AIS downstream

Figure 7, The OTUk/ODUk_A_Sk function replaces the ODUk signal (carrying client data) with the ODUk-AIS Maintenance Signal, whenever upstream circuitry asserts its AI_TSF input.  

So What Does All This Mean?

If we were to combine the OTSi/OTUk_A_Sk function, the OTUk_TT_Sk function, its Collocated OTUk_TT_So function and the OTUk/ODUk_A_Sk function into a single box, that we call OTN STE.

Then, we could state that if the OTN STE declares the dLOF defect (as we discussed earlier in this post), then that same OTN STE will do all of the following:

  • It will transmit the OTUk-BDI indicator back, towards the upstream STE.
  • The OTN STE will also replace the missing (or defective) ODUk data-stream (carrying client traffic) with the ODUk-AIS Maintenance Signal, and
  • It will also trigger APS (Automatic Protection Switching) activities, by asserting the CI_SSF output (from the OTUk/ODUk_A_Sk function).  

I show an drawing of these actions, below in Figure 8.

Consequent Equations - Overall OTN STE's response to it declaring the dLOF Defect Condition

Figure 8, Illustration of the OTN STE responding to the dLOF Defect Condition

Conclusion

Thanks to Consequent Equations, we can define and predict how an OTN STE or PTE will respond to certain defects.

I have presented Consequent Equations in each of the posts that pertain to OTN Atomic Functions.  

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

Discounts Available for a Short Time!!!

Click on the Image below, to See More OTN- or Protection-Switching-Related Posts

OTN Related Blog

OTN Related Topics within this Blog

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

Protection-Switching Related Blog Posts

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

What is the Multiplex Structure Identifier

This post briefly defines the term Multiplex Structure Identifier (MSI) for OTN Applications.


What is the Multiplex Structure Identifier (MSI) within the PSI Message?

The purpose of this post is to define the term:  Multiplex Structure Identifier.

Introduction

In another post, we spoke about the PSI (Payload Structure Identifier) Message.

That post states a few things that are of interest to this post.

  • The PSI Message is a 256-byte Message that a given Source PTE will repeatedly transmit to the Sink PTE.
  • The Source PTE will repeatedly transmit this PSI Message via the PSI byte (within each ODUk/OPUk frame).
  • The purpose of this PSI Message is to permit the Source PTE to inform the Sink PTE of the type of traffic that this particular ODUk/OPUk server signal is transporting.
  • The first byte (Byte 0 – within the PSI Message) will be the PT (or Payload Type) byte.
  • This means that there are still 255 other bytes that are available to transport information within each PSI Message.
    • The PSI post also states that there are two different types of PSI Messages.
    • The Non-Multiplexed Traffic Type of PSI Message, and
    • The Multiplexed Traffic Type of PSI Message.  

If we’re discussing the MSI (Multiplex Structure Identifier), which involves OPU/ODU server signals that are transporting numerous lower-speed ODUj tributary signals, then we will be dealing with the Multiplexed Traffic Type of PSI Message.  

I show an illustration of the PSI byte-field (within an OPU frame) and a blow-up of the  Multiplexed-Traffic Type of PSI Message below in Figure 1.

OPU Frame with PSI Byte-Field Highlighted and a Breakout of the Multiplexed Structure PSI Message

Figure 1, Illustration of the PSI byte-field and a Multiplexed-Traffic Type of PSI Message

Please note that the PSI Message, within Figure 1, does not contain a CSF (Client Signal Fail) bit-field.  Hence, you should be able to identify this PSI Message as being the Multiplexed Traffic type of PSI Message.  

A Multiplex Structure ODUk

If the Source PTE (that is transmitting an ODUk signal to the remote Sink PTE) has set the PT byte value (within each PSI Message) to either 0x20 or 0x21, then this means that this ODUk signal is a Multiplex Structure ODUk signal.

If a given ODUk signal is a Multiplex Structure ODUk signal, then this means that it is transporting at least one lower-speed ODUj tributary signal within its payload (where k > j).

NOTE:  We will talk about PT = 0x22 and ODUCn signals in another post.

In this case, the Source PTE (or upstream circuitry) has mapped and multiplexed some number of lower-speed ODUj tributary signals into this particular higher-speed ODUk server signal.

For the OTN to work correctly, the Source PTE needs to send sufficient information to Sink PTE, about the type of traffic/data that a given ODUk signal is carrying.

Hence the purpose of the PSI Message.

The Sink PTE needs more information than the PT byte value

So if the Source PTE sets the PT Byte value (within each outbound PSI Message) to 0x20 or 0x21, then it is telling the remote Sink PTE that this ODUk signal is a Multiplex Structure signal that is transporting some number of Lower-Speed ODUj tributary signals.

However, the Sink PTE needs more information for it to be able to identify and handle this ODUk data-stream accurately.

In particular, the Sink PTE needs to “know” how many, and what type of lower-speed ODUj tributary signals that this ODUk/OPUk server signal is transporting.  

We can think of the remaining bytes (within the PSI Message, following the PSI byte) as being a passenger manifest for each of the Lower-Speed ODUj Tributary signals that we are transporting within this OPUk/ODUk server.  

Depending upon the PT value and the type of OPUk/ODUk server signal, that we are working with, the number of MSI bytes (within the PSI Messages for that particular server signal) will vary, as I show below.

For PT = 0x20

  • If we’re working with an OPU1/ODU1 server signal, then the MSI will consist of 2 bytes.
  • If we’re working with an OPU2/ODU2 server signal, then the MSI will consist of 4 bytes.
  • An OPU3/ODU3 server signal will use 16 bytes for its MSI.  

For PT = 0x21

  • If we’re working an OPU2/ODU2 server signal, then the MSI will consist of 8 bytes.
  • An OPU3/ODU3 server signal will use 32 bytes for its MSI, and
  • An OPU4/ODU4 server signal will use 80 bytes for its MSI.  

Let’s Take a Look at an ODU4/OPU4 Signal

For example, if we are dealing with an ODU4 signal, and if the PT byte is set to 0x21, then the PSI Message (that this ODU4/OPU4 signal transports) would have the format that we show below in Figure 2.

Multiplex Structure Identifier for 80 ODU0 Signals within an OPU4 Signal

Figure 2, Illustration of the PSI Message for an ODU4/OPU4 that is transporting 80 ODU0 signals

Figure 2 shows the PSI Message that a Source PTE would carry (within an ODU4 signal) if that ODU4 signal were transporting 80 ODU0 signals (that it has mapped and multiplexed into this ODU4).

Please note that ODU4/OPU4 signals can transport other types of multiplexed traffic.  For example, it can carry any of the following types of multiplexed traffic.

  • 80 ODU0 signals.
  • 40 ODU1 signals
  • 10 ODU2 or ODU2e signals
  • 2 ODU3 signal
  • Some number of ODUflex signals (provided that the total bandwidth of all of these signals does not exceed 80 time-slots or the OPU4 payload carrying capacity of 104.35597533 Gbps).
  • Various combinations of each of the above signals (again, provided that the total bandwidth of all of these signals does not exceed 80 time-slots

Stuck at Home? You Can Be an Expert on OTN Before You Return to your Office!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

How to Read/Decipher these Multiplex Structure Identifier fields

Figure 2 shows that each PSI Message (starting at Byte 2) for an OPU4/ODU4 server signal, has 80 consecutive bytes of data. 

These 80 bytes (of data) are the Multiplex Structure Identifier (MSI) for this OPU4/ODU4 serval signal.  In this case, each byte of data (within the MSI) represents a bandwidth of approximately 1.25Gbps.

If we’re working with an OPU4/ODU4 server signal, then:

80 bytes x 1.25Gbps = 100Gbps.

And that makes sense because 100Gbps is the approximate bandwidth of an OPU4/ODU4 signal.  

The MSI will alert the Sink PTE of the type of Lower-Speed ODUj Tributary Signals we are transporting within this OPU4/ODU4 server signal. 

Is the Time-Slot Allocated?

The first bit-field (within each MSI byte) will indicate whether this 1.25Gbps time-slot (within this OPU4/ODU4 server signal) has been allocated or not-allocated, as I show below in Figure 3.  

If this bit-field is set to “1”, then that particular time-slot (or bandwidth) within the OPU4/ODU4 signal is allocated.  

Conversely, if this bit-field is set to “0”, then this particular time-slot (or bandwidth) within the OPU4/ODU4 server signal is NOT allocated (or not being used to transport a lower-speed ODUj tributary signal).  

NOTE:  In the PT = 0x21 post, we mention that each time-slot (for PT = 0x21 applications) represents approximately 1.25Gbps of bandwidth.

I have also included Figure 3, which will help you better understand these Multiplex Structure Identifier fields.

Mutliplex Structure Identifier Definition for OPU4 Applications

Figure 3, Multiplex Structure Identifier – Bit Definitions for ODU4/OPU4 Applications.  

The Port ID Number

The remaining 7-bits, within each MSI byte, are the Tributary Port Number (or Port ID Number.  

The Port ID Number identifies which lower-speed ODUj Tributary signal that we are transporting within this OPU4/ODU4 server signal.  

Now, since each byte (within the MSI) represents a bandwidth of 1.25Gbps, then the number of times that we see a particular Port ID Number, appearing within our 80 bytes of MSI, indicates the bandwidth (and in-turn) the type ODUj Tributary signal that we are working with.

For example, if we only see that Port ID Number = 0x00, only appears once within this set of 80 bytes, then we know that this particular ODUj Tributary signal (that corresponds with Port ID Number = 0x00) has a bandwidth of:

1 byte x 1.25Gbps = 1.25Gbps

And is most likely an ODU0 signal.  

In the case, where we see that Port ID Number = 0x00, appears twice, within this set of 80 bytes, then we know that this particular ODUj Tributary signal has a bandwidth of:

2 bytes x 1.25Gbps = 2.50Gbps

And is most likely an ODU1 signal.  

And so on.  

Up in Figure 2, I show that the MSI for this OPU4/ODU4 server signal consists of 80 bytes, in which the Port ID Numbers range from 0x00, all the way to 0x4F (or 79 in decimal format). 

This means that each of the 80 MSI bytes contains a unique Port ID value.  In other words, no two MSI bytes contain the same Port ID value.  

This set of MSI bytes indicates that this OPU4/ODU4 server signal is transporting 80 ODU0 tributary signals or 80 sets of signals with a bandwidth of 1.25Gbps.  

Other Examples of Multiplex Structure Identifiers

  • PT = 0x21 Applications
    • ODU2/OPU2 Server Applications
    • ODU3/OPU3 Server Applications
    • ODU4/OPU4 Server Applications
  • PT = 0x20 Applications
    • ODU1/OPU1 Server Applications
    • ODU2/OPU2 Server Applications
    • ODU3/OPU3 Server Applications

NOTE: We cover Multiplexed Traffic and their resulting MSIs extensively within Lesson 5 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!

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

Discounts Available for a Short Time!!

To See More OTN-Related Posts, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

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

What is the OTUk/ODUk_A_Sk Atomic Function?

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


What is the OTUk/ODUk_A_Sk Atomic Function?

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

Introduction

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

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

More specifically, this function will:

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

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

OTUk/ODUk_A_Sk Function - Adaptation Atomic Function

Figure 1, Simple Illustration of the OTUk/ODUk_A_Sk Function

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

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

The Interfaces within the OTUk/ODUk_A_Sk Function

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

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

Functional Block Diagram

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

OTUk/ODUk_A_Sk Atomic Functional Block Diagram

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

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

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

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

Corporate Discounts Available!!

So What All Does this Atomic Function Do?

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

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

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

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

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

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

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

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

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

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

Function Defects

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

Consequent Actions

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

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

I will discuss each of these consequent action equations below.

aSSF <- AI_TSF and (NOT MI_AdminState = LOCKED)

This equation means two things.

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

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

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

aAIS <- AI_TSF and (NOT MI_AdminState = LOCKED)

This equation means two things.

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

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

aSSD <- AI_TSD and (NOT MI_AdminState = LOCKED)

This equation means two things.

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

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

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

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

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

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

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

Defect Correlations

None for this function.

Performance Monitoring

None

Pin Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is the OTUk/ODUk_A_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 next 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, then 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 considerable 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.

OTUk/ODUk_A_So Simple Block Diagram - ITU-T G.798 Symbol

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 be inserting 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.

OTUk/ODUk_A_So Functional Block Diagram

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 down-stream 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 (that we’ve 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 then 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 internally generate the ODUk-LCK maintenance signal upon command.

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 traffic that is carrying user/client data will be replaced with the ODUk-LCK maintenance signal.

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 have access to 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 either enable or disable the APS Channel and to configure this particular function to operate at a specific APS Level, through both the MI_APS_En andMI_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 is signaling 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 some additional 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, that I will call a partial OTUk data-stream

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

It will just include the ODUk-portion of the OTUk frame, along with 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 of the 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 NameTypeDescription
ODUk_CP Interface
CI_DInputODUk 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_CKInputODUk 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_FSInputODUk 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_MFSInputODUk 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_APSInputODUk 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_DOutputOTUk 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_CKOutputOTUk 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_FSOutputOTUk 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_MFSOutputOTUk 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_IAEOutputOTUk 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_AdminStateInputManagement 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_EnInputManagement 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_LVLInputManagement 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.

Stuck at Home? You Can Be an Expert on OTN Before You Return to the Office!!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is an Atomic Function for OTN?

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


What is an Atomic Function for OTN Applications?

If you ever read through many of the ITU standards, particularly those documents that discuss the declaration and clearance of defect conditions, then 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 all of this, I will dedicate numerous blog postings to explaining and defining 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 also specify a functional architecture and behavior each of these functions.

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 actual 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 any chips that have the same I/O (for Traffic Data, System Management, etc.).

However, if you were to design and build networking equipment that handles OTN traffic, then you are required to perform the functions that ITU has 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 functionality that ITU has defined for those functional blocks.

Therefore, it is crucial that you understand the following:

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

If you understand both of these items, then 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 are reading about atomic functions (in ITU-T G.798), then 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

Another Way to Identify an Adaptation Function?

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

OTUk/ODUk_A_Sk Function - Adaptation Atomic Function

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

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

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

Corporate Discounts Available!!!

Trail-Termination Functions

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

Whenever you are reading about atomic functions (in ITU-T G.798), then 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 make it possible for us to declare/clear defects and to flag/count bit-errors.

I’ve listed some of the Atomic Trail-Termination Functions, that we will be discussing with 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?

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

OTUk_TT_Sk Function - Trail Trace Atomic Function

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

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

Stuck at Home? You Can Be an Expert on OTN Before You Return to your Office!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is 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 signals into the ODUk, or
  • Use the PT = 21 (or 0x21) Method for Mapping/Multiplexing the ODUj 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 are using the PT = 21 Method, this means that we will be setting 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 are using 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 method 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 SignalMapping StructureMapping MethodNumber of ODUj SignalsIntermediate StructureODUk/OPUk Signal
ODU0ODTU2.1GMP8ODTUG2ODU2/OPU2
ODUflexODTU2.tsGMP1 to 8ODTUG2ODU2/OPU2
ODU1ODTU12AMP4ODTUG2ODU2/OPU2
ODU0ODTU3.1GMP32ODTUG3ODU3/OPU3
ODUflexODTU3.tsGMP1 to 32ODTUG3ODU3/OPU3
ODU1ODTU13AMP16ODTUG3ODU3/OPU3
ODU2ODTU23AMP4ODTUG3ODU3/OPU3
ODU2eODTU3.9GMP3ODTUG3ODU3/OPU3
ODU0ODTU4.1GMP80ODTUG4ODU4/OPU4
ODUflexODTU4.tsGMP1 to 80ODTUG4ODU4/OPU4
ODU1ODTU4.2GMP40ODTUG4ODU4/OPU4
ODU2ODTU4.8GMP10ODTUG4ODU4/OPU4
ODU2eODTU4.8GMP10ODTUG4ODU4/OPU4
ODU3ODTU4.31GMP2ODTUG4ODU4/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.

ODU0 to ODU2 - Using PT = 21 Method

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.

ODUflex to ODU4 - Using PT = 21 Method

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.

ODUflex to ODU2 - Using PT = 21 Method

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.

ODU0 to ODU3 - Using PT = 21 Method

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.

ODU1 to ODU3 - Using PT = 21 Method

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.

ODU2 to ODU3 - Using PT = 21 Method

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.

ODU2e to ODU3 - Using PT = 21 Method

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.

ODUflex to ODU3 - Using PT = 21 Method

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.

ODU0 to ODU4 - Using PT = 21 Method

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.

ODU1 to ODU4 - Using PT = 21 Method

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.

ODU2 to ODU4 - Using PT = 21 Method

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.

ODU2e to ODU4 - Using PT = 21 Method

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.

ODU3 to ODU4 - Using PT = 21 Method

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.

ODUflex to ODU4 - Using PT = 21 Method

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 THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!! program to see this link.

In Conclusion

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

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

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

Stuck at Home? You Can Be an Expert on OTN Before You Return to Your Office!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is the 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 are discussing the OTN Digital Layers (e.g., the OPUk, ODUk, and OTUk layers), we can group Networking Circuits and Equipment into two broad categories.

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

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

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

You can also find a detailed discussion of both 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 need first to 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 Path and
  • ODUj to OPUk/ODUk Mapping/Multiplexing Path

We will define each of these types of Paths below.

Non-OTN Client Path

Whenever we are transporting a single non-OTN client signal (such as 100GBASE-R) over OTN (e.g., an 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 both some Path Terminating Equipment as well as some STEs.

Difference between Section Termination Equipment and Path Terminating Equipment

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

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

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

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

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

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

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

A Closer Look at the Non-OTN Client 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 path within an OTN.  This figure also indicates where this Path begins and ends within the OTN.

100GbE/OTU4 Path - Path Terminating Equipment

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

Once again, Figure 2 shows that the Non-OTN Client Path begins at the point that 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 at the point 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 of the signals (between the STE and PTE boxes) as being OTU signals.  We did not discuss these signals down at the OPU4 or ODU4 layers, as we do in Figure 2.

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 ODUj to OPUk/ODUk Mapping/Multiplexing Path

Another type of OTN Path is the ODUj to OPUk/ODUk Mapping/Multiplexing Path.

In the ODUj to OPUk/ODUk Mapping/Multiplexing Path, we can map and multiplex numerous lower-speed ODUj signals into a Higher-Speed OPUk/ODUk signal (where k > j).

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

Figure 3 presents an illustration of a Unidirectional Network that contains both a Non-OTN Client and the ODUj to OPUk/ODUk Mapping/Multiplexing set of paths.

1GbE to ODU0 to ODU4 - Path Terminating Equipment

Figure 3, A Closer Look at the ODUj to OPUk/ODUk Mapping/Multiplexing Path

NOTE: We have already described the Non-OTN Client path earlier in this post.  Hence, the reader should now 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 (at 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 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 additional processes (that we discuss in detail in other posts) before we map/multiplex this ODU0 signal into an OPU4 signal.

Once we’ve mapped the ODU0 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.

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

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

Handing the OPU4/ODU4 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 this signal through three additional sets of STEs before it arrives at the XCVR and Optical I/F at the Remote Terminal.

The remote terminal converts this signal back into the electrical format, where it also terminates both 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 the location where this OPU4 signal (and its Path) ends.

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

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

Afterward, it will transmit this data towards 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, then 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 that is 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 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 where circuitry will either map this signal into another higher-speed ODUk signal, or it will map this signal into 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 client or some number of lower-speed ODUj signals.
  • Route the de-mapped data downstream for further processing.

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

Anytime the PTE maps data (be it non-OTN client data or lower-speed ODUj 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 then attaching the ODUk overhead fields (or ODUk-PMOH) 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.

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

We will discuss each of these topics (e.g., Tandem Connection Monitoring and the APS Channel) in other posts.

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-PMOH that the PTE will use to support the monitoring of this signal as it travels through the Path.

ODU Frame with ODU Overhead Shown

Figure 4, ODUk Overhead (ODUk-PMOH), and Payload fields

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

Terminating the OPUk Overhead

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

Once the STE has terminated OTUk-SMOH, it will route the resulting ODUk signal towards down-stream 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 also strip off and 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 on this is that the PTE will rely on the ODUk-PMOH data (as we show in Figure 4) to process, manage, and ultimately terminate the ODUk stream.

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

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

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

I have included this figure below in Figure 5.

100GbE to OTU4 PTE w/ ODU4-PMOH

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

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

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

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

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

I have included this figure below in Figure 6.

1GbE to ODU0 to ODU4 - ODU0 SMOH Termination

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

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

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

I have included this figure below in Figure 7.

1GbE to ODU4 with ODU4-PMOH

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

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

De-Mapping the Client Signal from the OPUk Payload

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

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

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

Examples of PTE

  • Line Cards or Transceivers that take (for instance) 100GBASE-R data from a MAC and transports 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.

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

In another post, I discuss and 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 fact, in most cases, the PTE will not even see the OTUk-SMOH data.

Stuck at Home? You Can be an Expert on OTN Before You Return to Your Office!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is the ODUk-LCK Maintenance Signal?

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


What Is the ODUk-LCK Maintenance Signal?

LCK is an abbreviation for Locked Indicator.

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

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

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

More specifically, if we were to map the ODUk-LCK Maintenance signal into an OTU data-stream, the Source STE will 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 upon the contents within each of these OTUk frames.

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

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

What is 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.

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

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

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

OTUk Bit Rate and OTUk Frame Period

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

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

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

The ODUk-LCK maintenance signal is similar to both the ODUk-OCI and ODUk-AIS maintenance signals, in that all three of these maintenance signals serve as replacement signals to actual OTN traffic.

However, the NE will transmit the ODUk-OCI indicator whenever the OTN traffic is missing because system configuration has simply 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 because the system operator has administratively 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 in the case where 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 receives 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.

Stuck at Home? You Can Be an Expert on OTN Before You Return to the Office!! Click on the Banner Below to Learn More!!!

Discount Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is the ODUk-OCI Maintenance Signal?

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


What exactly is an ODUk-OCI Maintenance Signal?

OCI is an acronym for Open Connection Indicator.

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

In other words, if 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 will do so by generating and transmitting 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 upon the contents within each of these OTUk frames.

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

ODUk-OCI indicator

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

What is 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.

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

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

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

OTUk Bit Rate and OTUk Frame Period

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

Earlier, I mentioned that a 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 serve as the replacement to 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 that all three of these signals/indicators serve as replacement signals to 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 in the case where 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.

Stuck at Home? You Can Be an Expert on OTN Before You Return to the Office!! Click on the Banner Below to Learn More!!!

Discount Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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