Category: Optical Transport Networks

OTUk-Backward Defect Indicator

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


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

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

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

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

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

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

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

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

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

Corporate Discounts Available!!

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

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

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

NETWORK ELEMENT WEST contains the following pieces of hardware

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

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

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

Normal Condition - Network Element West and East

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

A Defect Condition

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

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

Network Element East declares Service Affecting Defect

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

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

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

Sending the OTUk-BDI Indicator in Response

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

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

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

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

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

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

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

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

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

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

Discounts Available for a Short Time!!

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

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

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

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

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

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

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

How does the OTUk Network Element transmit the dBDI indicator?

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

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

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

OTUk Overhead with SM Field Identified

Figure 4a, The SM Field within the OTUk Overhead

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

SM field with the SM Byte identified

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

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

SM Byte with OTUk-BDI field identified

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

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

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

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

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

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

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

Network Element West declares the dBDI defect condition

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

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

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

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

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

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

Network Element East declares Service-Affecting Defect

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

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

Discounts Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is 1:N Protection Switching?

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

What is the 1:n Protection Switching Architecture?

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

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

It may have an extra traffic signal.  

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

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

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

What Does All This Mean?

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

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

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

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

Basic Drawing of a 1:2 Protection Switching Scheme

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

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

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

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

NOTES:  

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

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

Corporate Discounts Available!!!

How does the 1:n Protection Switching Architecture Work?

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

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

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

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

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

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

Another Key Characteristic of a 1:N Protection Architecture

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

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

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

The Normal (No Defect) Case

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

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

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

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

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

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

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

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

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

1:2 Protection Switching Scheme - Normal Condition - Extra Traffic Signal

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

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

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

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

Figure 3 shows a drawing of this condition.

1:2 Protection Switching Scheme - Defect in Working Transport entity # 1

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

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

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

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

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

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

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

1:2 Protection Switching Scheme - Protection EventFigure 4, Illustration of our 1:2 Protection Switching Protect Group, following Protection Switching

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

This is how 1:N Protection Switching works.

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

Discounts Available for a Short Time!!

Additional Options in the 1:n Protection Switching Architecture

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

Some of these options include:

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

We will briefly discuss each of these options below.

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

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

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

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

1:2 Protection Switching Sceme - Normal with NULL Signal

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

Transmitting the FDI/AIS signal during Protection Switching

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

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

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

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

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

Revertive Protection Switching

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

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

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

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

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

Unidirectional or Bidirectional Protection Switching

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

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

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

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

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

Discounts Available for a Short Time!!

Click on the Image Below to see more Protection-Switching related content on this Blog:

Protection-Switching Related Blog

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 NULL Test Signal for OTN?

This post defines and describes the NULL Signal for OTN (Optical Transport Network) applications.

What is the NULL Test Signal for OTN?

What Exactly is the NULL Test Signal for OTN?

The NULL signal (for OTN) is an OPUk frame with all the following characteristics.

  • The PT (Payload Type) byte-field (within the PSI) is set to the value 0xFD (which indicates that this OPUk frame is transporting the NULL signal).
  • The rest of the 7 RES (Reserved) byte-fields (within the OPUk Overhead) are all set to an All-Zeros pattern (0x00).
  • All the payload bytes (within the OPUk frame) are set in an All-Zeros pattern.

Figure 1 shows a drawing of an OPUk Frame transporting the NULL signal.

OPUk_Frame transporting NULL Signal

Figure 1, An Illustration of the OPUk frame that is transporting the NULL signal

Any ODUk or OTUk frame that transports an OPUk frame with these characteristics carries the NULL signal.

Additionally, any of the following types of OPUk/ODUk signals can transport the NULL signal:

  • OPU0/ODU0
  • OPU1/ODU1
  • OPU2/ODU2
  • OPU2e/ODU2e
  • OPU3/ODU3
  • OPU4/ODU4
  • OPUflex/ODUflex

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

Corporate Discounts Available!!!

Where and How would one use the NULL Signal?

ITU-T G.709 defines the NULL signal (for OTN) as a test signal.

Therefore, the System Architect can consider the NULL signal as a tool (in the toolbox) for testing and debugging features available to an OTN system.

Some system applications will transmit the NULL signal via the Protection Transport entity within a 1:1 or 1:n protection switching scheme.  In this case, the user will send the NULL signal instead of either the Extra-Traffic Signal or the ODUk-OCI Maintenance Signal.

Figure 2 shows a drawing of the 1:2 Protection Switching scheme, in which the user is transporting the NULL signal via the Protection Transport Entity.

1:2 Protection Switching scheme using the NULL Signal

Figure 2, An Illustration of a 1:2 Protection Switching scheme that is transporting the NULL signal via the Protection Transport entity

We can use the NULL signal in any application or situation whenever we need to continuously supply an optical signal (that is carrying timing information) to keep Clock Recovery PLL circuitry (within a downstream Network Element) locked onto the timing signal in the local Network Element.

Simultaneously, the NULL signal will indicate to the downstream Network Element that the connection is working correctly and that there are no defects upstream.

The NULL signal is unlike an AIS signal, which does indicate (to downstream Network Elements) the presence of service-affecting defect conditions upstream.

How Should a System Designer create the NULL Signal for OTN Applications?

The NULL signal (for OTN applications) consists of a fixed pattern.

Therefore, the user can generate OPUk signals (transporting the NULL signal) using a Pattern Generator, which gets its timing from a local clock oscillator.

The System Designer must also ensure that this NULL Signal generator function generates both the OTUk/ODUk Frame and Multi-Frame start indicators.

The Frame Start indicator (FS) should occur every 122,368 clock cycles (or ODUk frame period).

And the Multi-Frame Start indicator (MFS) should occur every 256 frames.

ITU-T G.798 specifies an adaptation function of the name ODUkP/NULL_A_So.

This function is responsible for generating an ODUk signal transporting the NULL signal.

This adaptation function generates the NULL signal from a free-running clock source, which then maps this signal into an OPUk/ODUk frame.

Finally, this function includes the OPUk overhead (e.g., the RES and PT fields) and a default ODUk overhead.

NOTE:  In the case of the default ODUk overhead, this function will set all the ODUk overhead fields to All-Zeros, except for the PM STAT field, which will be set to the value 001 (to indicate a Normal Path Signal).

Figure 3 illustrates the ODUkP/NULL_A_So function from ITU-T G.798.

ODUkP/NULL_A_So function block diagram

Figure 3 illustrates the ODUk/NULL_A_So function from ITU-T G.798.  

What are the Timing (Frequency Accuracy), Jitter, and Wander Requirements for the NULL Signal?

Please see the ODCa (ODU Clock for Asynchronous Mapping) post for the complete Frequency Accuracy and Jitter/Wander requirements of this NULL signal.

Summary

The NULL signal, for OTN applications, is an OPUk frame that has ALL the following characteristics:

  • All the Payload bytes have the value 0x00 (All Zeros).
  • The PT (Payload Type) byte (within the PSI message) has the value of 0xFD (which identifies this particular signal as being the NULL signal)
  • All remaining OPUk overhead fields will be of the value of 0x00 (All Zeros).

Additionally, within the ODUk overhead, the PM STAT field should be set to the value 001.

The NULL signal is a test signal that one can use for test and debugging purposes.

The System Design can also use the NULL signal as a replacement signal for a signal that is unavailable due to user configuration reasons.

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

Discounts Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is the Extra Traffic Signal (for APS)?

This post defines and describes the term Extra Traffic Signal, as it is used in a Protection Switching system.


What is the Extra Traffic Signal for APS (Automatic Protection Switching) Purposes?

ITU-T G.808 Defines the Extra Traffic Signal as:
A Traffic signal is carried over the protection transport entity and/or bandwidth when that transport entity/bandwidth is not being used to protect a normal traffic signal, i.e., when the protection transport entity is on standby.  

Whenever the protection transport entity/bandwidth is required to protect or restore the normal traffic on the working transport entity, we will preempt the extra traffic.  

Extra traffic is not protected.

What Does All That Mean?

1:1 and 1:n protection switching schemes often support two types of signals.

The Normal Traffic signal is the high-priority traffic signal that we designed our protection switching scheme to protect.

A Normal Traffic signal will usually travel through a Protection Group (from one Network Element to another) via the Working Transport entity.

What if the Network Declares a Service-Affecting or Signal Degrade Defect Condition with the Working Transport Entity?

However, suppose the Network detects a service-affecting or signal degrade defect within the Working Transport entity.  In that case, the protection group will route the corresponding Normal Traffic Signal through the Protection Transport entity.

The Extra Traffic signal is a lower-priority (and therefore, pre-emptible) traffic signal that will travel through a Protection Group (from one Network Element to another) via the Protection Transport entity whenever it is in standby mode.

In other words, as long as the one (or n) Normal Traffic signals can travel on their Working Transport entities (e.g., the normal condition), then the Extra Traffic signal will use the Protection Transport entity.

The Extra Traffic Gets Dropped

However, suppose the Tail-End circuitry (within the Protection Group) declares a defect condition and asserts the SF or SD indicators.  In that case, the protection scheme will respond to this event by entirely dropping the Extra Traffic signal and routing the Normal Traffic Signal through the Protection-Transport entity in its place.

In some cases, the system operator will transmit the NULL signal, or the ODU-OCI Maintenance signal, via the Protection Transport entity, instead of the Extra-Traffic Signal.

However, unlike the NULL Signal or the ODU-OCI  Maintenance signal, the Extra Traffic Signal can transport user (or client) traffic.  The end customers need to know that their traffic is a lower priority and that Protection-Switching events can preempt (or wipe out) their traffic/service.

In some cases, the Network Service Provider can offer their customers service via an Extra Traffic Signal for a reduced price because this traffic is low priority and preemptible.  

Figure 1 presents a drawing of a 1:2 Protection Switching system.

This figure shows the Normal Traffic signals traveling on the two Working Transport entities.  Normal Traffic Signal # 1 travels along W1 (the Working Transport Entity # 1).  Further, Normal Traffic Signal # 2 travels along W2 (the Working Transport Entity # 2).  

Additionally, this figure shows the Extra Traffic Signal traveling through the Protect Transport entity (P).  

1:2 Protection Switching Architecture - Normal Condition

Figure 1, Drawing of a 1:2 Protection Switching system, with the Extra Traffic Signal highlighted.

How Protection-Switching Preempts the Extra Traffic Signal

If the Network declares a service-affecting defect within one of the Working Transport entities, all the following events will occur.

  • The affected Normal Traffic Signal will now use the Protect Transport entity instead, and
  • The Protection-Switching Network will drop (or preempt) the Extra Traffic Signal.

Figure 2 shows a drawing of the 1:2 Protection Group during protection switching.

In this case, the Network declared a defect within the Working Transport entity associated with Normal Traffic Signal # 1.

Consequently, Normal Traffic Signal # 1 is now using the Protect Transport entity, and the Protection Group is now pre-empting the Extra Traffic signal.

1:2 Protection Switching Architecture - Defect Condition

Figure 2, Drawing of a 1:2 Protection Switching system when a Protection Switch preempts the Extra Traffic signal.

NOTE:  The Extra Traffic signal cannot be a high-priority signal for the following reasons.

  • We do not protect this signal.  If a Service-Affecting defect occurs and we, in turn, lose the Extra-Traffic Signal, our Protection-Switching system will do nothing about it.
  • Even worse, the Extra-Traffic signal is also expendable should one of the Normal Traffic signals need to use the Protect Transport entity.

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

Discounts Available for a Short Time!!

Click on the Image Below to see more Protection-Switching related content on this Blog:

Protection-Switching Related Blog

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 ODUk-AIS Signal?

This post defines the ODUk-AIS Maintenance Signal. It also discusses when Network Equipment should transmit this Maintenance Signal. Finally, this post describes how a Sink PTE will declare and clear the dAIS defect.


What is the ODUk-AIS Maintenance Signal, and How does a Network Element declare the dAIS Defect Condition?

What is the ODUk-AIS Maintenance signal?

AIS is an acronym for Alarm Indication Signal.

Another post describes the general purpose/role of the AIS maintenance signal.

For OTN applications, the Network Equipment (NE) will transmit the ODUk-AIS maintenance signal by overwriting the contents of an entire ODUk frame (e.g., ODU Overhead and Payload Data) with an All-Ones pattern.

NOTE:  The variable k in the expression ODUk can be of any of the following values, depending upon the data rate:  0, 1, 2, 2e, 3, 4, and flex.

If an OTN STE were to map the ODUk-AIS Maintenance signal into an OTUk frame, then the OTN STE will be generating/transmitting a series of OTUk frames in which the FAS, MFAS, and OTUk Overhead fields are all valid.

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

However, these OTUk frames will contain an ODUk Overhead, the OPUk Overhead, and the Payload fields that have been overwritten with an All-Ones pattern.

Figure 1 presents a drawing of an OTUk frame transporting the ODUk-AIS Maintenance signal.

ODUk-AIS Pattern

Figure 1, Drawing of an OTUk frame carrying the ODUk-AIS Maintenance signal.

Please note that the ODUk-AIS pattern differs from the OTUk-AIS pattern (an Unframed PN-11 pattern).

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

The OTN STE will need to transmit this ODUk-AIS Maintenance signal at the same nominal bit rate as an ordinary ODUk/OTUk signal.

Like any ordinary 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-AIS indicator) for each value of k.

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

OTUk Bit Rate

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

An OTN STE will generate/transmit the ODUk-AIS maintenance signal anytime it has detected and declared a service-affecting defect condition (at the OTUk-layer) within the upstream traffic.

For example:  If an STE declares the dLOS-P (Loss of Signal – Path) or the dLOF (Loss of Frame) defect within its incoming OTUk signal, it will respond to this defect condition by transmitting the ODUk-AIS signal downstream.

Whenever the OTN STE transmits this ODUk-AIS maintenance signal downstream, it is (in effect) replacing the missing (or defective) ODUk signal (that the defective OTUk signal was transporting) with the ODUk-AIS maintenance signal.

In other words, the OTN STE will generate and transmit the ODUk-AIS Maintenance signal downstream rather than de-map out and transmit an ODUk signal that was likely destroyed by the service-affecting defect within its OTUk server signal.   I show this phenomenon below in Figure 2.

Service Affecting Defect at the OTUk Layer results in the tranmission of the ODUk-AIS Maintenance Signal

Figure 2, Drawing of OTN Circuitry transmitting the ODUk-AIS Maintenance Signal downstream, in response to a Service-Affecting Defect occurring within the OTUk-Layer, upstream.  

The OTN STE will generate and transmit the ODUk-AIS maintenance signal towards downstream ODUk client equipment; anytime it declares any of the following service-affecting defects in the upstream signal.

Please see the post on AIS for an in-depth write-up on when the NE will (and will not) generate the AIS pattern downstream.

How does a Sink PTE detect and declare the ODUk-AIS (or dAIS) defect condition?

The Sink PTE downstream from the STE transmitting the ODUk-AIS Maintenance signal will detect and declare the ODUk-AIS defect condition whenever it receives a STAT field value of “1, 1, 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.

The Upstream NE will set this 3-bit field to the value [1, 1, 1] because it overwrites the ODUk overhead with an All-Ones pattern whenever it transmits the ODUk-AIS Maintenance Signal.

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

How does a Sink PTE clear the ODUk-AIS defect condition?

The Sink PTE will clear the ODUk-AIS defect condition whenever it has accepted a STAT field value of something other than “[1, 1, 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.

Inflation’s Got You Down? With our Pricing, We Can Help with Inflation and Make You an OTN Expert!! Click on the Banner Below to Learn More!!!

Discounts Temporarily Available!!

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-AIS Indicator?

This post defines and describes the OTUk-AIS signal for OTN applications.


What is the OTUk-AIS Maintenance Signal?

What exactly is an OTUk-AIS signal?

AIS is an acronym for Alarm Indication Signal.

Another post describes the role/function of AIS.

Whenever an OTN Network Equipment (NE) transmits an OTUk-AIS signal, it generates and transmits an Unframed PN-11 (e.g., PRBS11) Pattern.

More specifically, ITU-T G.709 defines this PN-11 sequence by the generating polynomial:  1 + x9 + x11.

Since this is an Unframed signal, then this means that all of the OTUk, ODUk, and OPUk overhead fields (within the OTUk signal) will be overwritten with this PN-11 pattern.

Figure 1 presents a simple illustration of an OTUk-AIS signal.

OTUk-AIS Pattern

Figure 1, Simple Illustration of an OTUk-AIS signal.

What are the timing/frequency requirements for an OTUk-AIS signal?

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

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

Table 1 presents the nominal bit-rates for the OTUk signals (and, in turn, for the OTUk-AIS signal) for each value of k.

Table 1, Required Bit Rates for the OTUk-AIS signal.

OTUk Bit Rate

Does the OTN NE need to align the PN-11 pattern sequence with the OTUk frame?

In short, the answer is No.

The length of the PN-11 sequence is 2047 bits (e.g., 211 – 1).  And the capacity of a given OTUk frame is 130,560 bits.

Since the numeral 130,560 is NOT an integral multiple of 2047, the PN-11 sequence will cross OTUk frame boundaries.

When would OTN Network Equipment transmit/generate an OTUk-AIS signal?

For the time being, ITU-T G.709 has not defined a set of conditions (or defects) upon which the OTN STE would transmit the OTUk-AIS signal.

ITU-T G.709 has reserved this type of signal as a placeholder for future use.

The standards committee may (at a later time) specify a set of conditions upon which an OTN STE would transmit the OTUk-AIS signal.

Additionally, ITU-T G.709 is NOT requiring that OTN Equipment or Chip Vendors design their products to be capable of generating/transmitting the OTUk-AIS signal.

However, ITU-T G.709 mandates that OTN Equipment and Chip Vendors be capable of receiving, detecting, and flagging the OTUk-AIS pattern.

Click HERE for Information on How an STE does declare and clear the dAIS (OTUk-AIS) defect condition.

Why are we even talking about an OTUk-AIS Signal if we are NOT currently required to generate it?

Once again, the Standards Committee has reserved this signal for FUTURE USE.

They envision defining conditions for which an OTN Section Terminating Equipment (STE) would generate and transmit the OTUk-AIS signal in a system application.

Is there another type of AIS signal that OTN APPLICATIONS ARE ACTIVELY USING?

Yes, ITU-T G.709 also recommends the use of ODUk-AIS.  OTN Path Terminating Equipment is actively using the ODUk-AIS indicator.

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

Temporary Discount Offered!!

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 ODTU4.1 Structure?

This post defines the ODTU4.1 (Optical Tributary Data Unit 4.1). This post also describes how we use the ODTU4.1 structure/frame whenever we are mapping/multiplexing ODU0 signals into an OPU4 signal.


What is the ODTU4.1 Frame/Structure?  And When do We use it?

Introduction

The term, ODTU4.1, is an acronym for Optical Data Tributary Unit 4.1.

A Mapper circuit will use this structure whenever mapping and multiplexing anywhere between 1 and 80 ODU0 tributary signals into an OPU4/ODU4 server signal.

We will discuss the following topics within this blog post.

  • What does the term ODTU4.1 mean?
  • A description/definition of the ODTU4.1 frame/structure.
  • How do we use the ODTU4.1 structure when mapping/multiplexing multiple lower-speed ODU0 tributary signals into an OPU4 server signal?
    • What is the timing/frequency relationship between each ODTU4.1 signal, and
    • What is the timing/frequency relationship between each ODTU4.1 signal and the outbound OPU4 frame data?

What is the meaning of the term ODTU4.1?

The numeral 4 (within the expression ODTU4.1) reflects that we use this structure to map data into an OPU4/ODU4 server signal.

The numeral 1 (again, within the expression ODTU4.1) reflects that this structure transports a single ODU0 signal (which contains only 1 (one) 1.25Gbps-unit  of bandwidth).

Therefore, the ODTU4.1 structure only transports 1 (one) 1.25Gbps-unit (or tributary-slot) of bandwidth as we map/multiplex this data into an OPU4/ODU4 server signal.

NOTE:  I have extensively discussed how we map 80 ODU0 tributary signals into an ODU4 server signal within Lesson 5/ODU4 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

There are other similar structures, such as the ODTU4.2, ODTU4.8, ODTU4.31, and ODTU4.ts frames, that we will use to map an ODU1 (2 time-slots), ODU2/2e (8 time-slots), ODU3 (31 time-slots) and ODUflex (ts time-slots) into an OPU4 signal, respectively.

We will discuss each of these structures in other posts.

When do we use the ODTU4.1 structure?

We use these structures when mapping and multiplexing from 1 to 80 lower-speed ODU0 tributary signals into an OPU4/ODU4 server signal.

ITU-T G.709 states that whenever we map/multiplex some ODU0s into an OPU4/ODU4 signal, then we need to do this by executing the following four-step process.

  • Convert each ODU0 signal into an Extended ODU0 signal.
  • GMP map each ODU0 signal into its ODTU4.1 structure/signal, and
  • Byte-Wise Multiplex as many as 80 ODTU4.1 signals together and then
  • Load this data into the OPU4 Payload area.

ITU-T G.709 presents a series of figures on mapping/multiplex lower-speed ODUj tributary signals into a higher-speed OPUk server signal (e.g., k > j).

The standard presents the following figure on how to map/multiplex ODU0 signals into an OPU4.

ITU-T G.709 using ODTU4.1 to map ODU0s into an OPU4

Figure 1, Illustration of the ITU-T G.709 Drawing on how to Map/Multiplex up to 80 ODU0s signals into an OPU4 signal.  

I (more or less) copied Figure 1 straight out of ITU-T G.709.

I added some additional text to explain this figure and ITU-T G.709’s instructions.

Figure 1 states that we must first map a single “Extended ODU0 signal” into a single ODTU4.1 signal using GMP (Generic Mapping Procedure).

What Do We Mean by an Extended ODU0 Signal?

Before we can begin the process of mapping/multiplexing any ODU0 tributary signals into an OPU4/ODU4 server signal, we must first convert each of these ODU0 signals into an Extended ODU0 signal.

This means we need to take an ODU0 frame and then “extend it” by attaching the FAS and MFAS fields to this frame, as shown below in Figure 2.

Extended ODUk Framing Format

Figure 2, Illustration of the Extended ODU0 Framing Format

We attach the FAS and MFAS fields to each of these ODU0 frames so that the Sink PTE circuitry (at the remote end of the fiber link) can locate the boundaries of ODU0 frames as it de-maps this data from the ODTU4.1 structures.

Please see the OTU Post for more information on the FAS and MFAS fields.

Please also note that (as we include the FAS and MFAS fields within the ODU0), we fill in the rest of the OTUk Overhead to an all-zeroes pattern, and we don’t append the FEC to the back-end of the ODU0 frame.

Mapping the Extended ODU0 signals into the ODTU4.1 Signal/Structure

Once we have converted each of the ODU0 signals into Extended ODU0 signals, we will proceed to GMP map this data into the ODTU4.1 signal/structure.

After performing this mapping step, we will (from here on) be working with ODTU4.1 signals (instead of ODU0 signals) as we load this data into an OPU4/ODU4 frame structure and transport it across an optical link.

These ODU0s will remain embedded within this ODTU4.1 data stream until some “ODTU4.1 to ODU0 De-Mapper” circuit de-maps/extracts the ODU0 signals from the ODTU4.1 signals.

If we are mapping/multiplexing 80 ODU0 signals into an OPU4 signal, then we will map 80 ODU0 signals into each of their own 80 ODTU4.1 signals in parallel.

And we will then have 80 separate ODTU4.1 signals to process and manipulate.

Figure 4 (further down in this post) illustrates some “Mapping circuitry” that maps 80 ODU0 signals into 80 ODTU4.1 signals in parallel.

Byte-Wise Multiplexing the ODTU4.1 Data into the ODTUG4 Structure

Next, Figure 1 states that we must byte-wise multiplex each of the 80 ODTU4.1 signals into a single ODTUG4 data stream.

And finally, we should then map (or insert) this ODTUG4 data stream into the OPU4/ODU4 server payload.

What does the ODTU4.1 Structure Look Like?

Figure 3 presents an illustration of the ODTU4.1 Framing Format.

ODTU4.1 Frame Format

Figure 3, Illustration of the ODTU4.1 Frame Format

This figure shows that the ODTU4.1 Frame consists of two different sections.

  • The ODTU4.1 payload area and
  • The ODTU4.1 overhead area

Figure 3 also shows that the ODTU4.1 payload is a 160 Row x 95 Byte Column structure.  This figure also shows that the ODTU4.1 frame comprises 6 bytes of overhead.

Please note that 160 Rows x 95 Byte Columns = 15,200 Bytes.

This means that the payload portion of each ODTU4.1 frame will carry 15,200 bytes (the exact number of payload bytes each OPU4 frame takes).

What kind of data resides within the ODTU4.1 Payload?

In short, the ODTU4.1 Payload will contain the contents of its respective Extended ODU0 signal.

Whenever we are GMP mapping an Extended ODU0 signal into an ODTU4.1 signal, we will load the entire Extended ODU0 data stream (e.g., ODU0 overhead, FAS field, and payload data) into the ODTU4.1 payload.

We will load this data into the ODTU4.1 payload in the standard transmission order.

What kind of data resides within the ODTU4.1 Overhead?

When the Mapper circuitry GMP maps the Extended ODU0 tributary signal into the ODTU4.1 structure, it will compute and generate some GMP parameters (for this particular mapping operation).

The Mapper circuitry will compute these GMP parameters based upon the exact bit rates of the Extended ODU0 signal and that on the ODTU4.1 (Server) signal.

The Mapper circuitry will then load this GMP mapping data into the JC1 through JC6 fields (within the ODTU4.1 overhead), just as a GMP mapper would for any client signal.

This set of JC1 through JC6 fields serves the same roles as the JC1 through JC6 fields (within an OPUk structure) whenever we use GMP mapping.

How do we transport the ODTU4.1 Overhead and Payload data across the Optical Link (within an OTN)?

Please see the OMFI Post for details.

Are all the ODTU4.1 signals both frame and byte-synchronous with each other whenever we map this data into the OPU4 payload?

In short, the answer is “Yes.”

The ODTU4.1 frames and signals must have the following timing/synchronization characteristics.

  • Each of the 80 ODTU4.1 signals must be bit-synchronous with each other.
  • These ODTU4.1 signals must also be bit-synchronous with the outbound OPU4/ODU4 data stream.
  • Each of the 80 ODTU4.1 signals must be frame-synchronous with each other, and
  • All 80 ODTU4.1 signals must be frame synchronous with the 80 OPU4 Frame Superframe they will eventually be multiplexed into.

We will discuss these characteristics (of the ODTU4.1 signals) below.

BUT FIRST – What about the timing and requirements of the ODU0 tributary signals?

Each ODU0 tributary signal (that we are mapping into an OPU4/ODU4 server signal) can be utterly asynchronous to each other.

Additionally, the only absolute timing requirement for the ODU0 signals is that they have to comply with the Frequency Tolerance requirements per ITU-T G.709.

There is also no requirement that these 80 ODU0 tributary signals be frame-aligned with each other either.

However, once the ODU0 signals are each GMP mapped into their ODTU4.1 signal, then each of the ODTU4.1 signals MUST be both byte- and frame-synchronous to each other.

Each of these ODTU4.1 signals must also be bit-synchronous with the outbound OPU4/ODU4 server signal.

Additionally, each of these ODTU4.1 frames must be aligned with the 80 OPU4 frame Superframe (that they will eventually be a part of).

GMP mapping addresses the timing differences between each of the individual ODU0 tributary signals as they transition from the “ODU0 tributary signal time domains” to the “ODTU4.1/OPU4 Time Domain”.

All of this means that the ODU0 to OPU4 Mapper Circuit must ensure that “Byte 1” (the very first payload byte) within each of the 80 ODTU4.1 frames are all being applied to the “ODTU4.1 Byte MUX” simultaneously.

Let’s focus on these points in greater detail.

ODTU4.1 Signals being Bit-Synchronous with each other

Figure 4 illustrates an ODU0 tributary signal to OPU4 Mapper circuit.

This figure presents 80 sets of “ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper” blocks.

Each block is responsible for GMP mapping its ODU0 signal into an ODTU4.1 Data Signal.

ODU0 to OPU4 Mapper Circuit

Figure 4, Illustration of an ODU0 tributary signal to OPU4 Mapper Circuit

Figure 4 also shows that a single clock source (e.g., ODTU4.1 and OPU4 Clock Source) will function as the timing source for each of the 80 ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper blocks.

This means that each of the resulting ODTU4.1 signals will be generated based on and synchronized with a common clock source (e.g., the ODTU4.1 and OPU4 Clock Source, in this case).

The OPU4 Output signal will also use the ODTU4.1 and OPU4 Clock Source as its timing source.

ODTU4.1 Signals are Byte-Aligned with Each Other

Figure 5 illustrates an abbreviated byte stream for each of the 80 ODTU4.1 payload signals.

80 ODTU4.1 Byte Data Streams

Figure 5, Illustration of the Byte Streams for each of the 80 ODTU4.1 Signals (output from the ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper block in Figure 4).

This figure shows that each ODU0 Frame Extenders/ODU0 to ODTU4.1 Mapper circuit must simultaneously generate and transmit the first payload byte of their ODTU4.1 frame.

Likewise, each ODU0 Frame Extender/ODU0 to ODTU4.1 Mapper circuits must all generate and transmit the very second payload byte of their ODTU4.1 frame simultaneously, and so on.

All 80 of these byte streams will then be routed to downstream circuitry, which will byte-multiplex and map this data into the OPU4 payload, as shown below in Figure 6.

Byte Wise Multiplexing 80 ODTU4.1 Signals into the OPU4 Payload

Figure 6, Simple Illustration of Circuitry Byte-Wise Multiplexing Each (of 80) ODTU4.1 Signals into an OPU4 Payload.  

ODTU4.1 Signals MUST be Frame Aligned to the 80 OPU4 Frame Superframe

In the OMFI post, we mentioned that we would ultimately map and multiplex each of the ODTU4.1 signals into an 80 OPU4 Frame Superframe.

Figure 7 illustrates an 80 OPU4 frame Superframe we created by byte-wise multiplexing these 80 ODTU4.1 data streams together.

Full OPU4 Superframe

Figure 7, Illustration of an 80 OPU4 frame Superframe.

Looking at Row 1, Byte-Column 17 within OPU4 Frame # 1, you will see that we have designated this byte-field as “1-1“.

This designation means that this byte originated from ODTU4.1 Signal # 1 and is the very first byte (e.g., byte # 1) within that particular ODTU4.1 frame.

Likewise, we designated the next byte-field (to the right) as “2-1“.

This means that this byte originated from ODTU4.1 Signal # 2 and that it is the very first byte within that particular ODTU4.1 frame, and so on.

Figure 6 also shows that the very first payload byte (within the 80 OPU4 frame Superframe) is the very first payload byte (within an ODTU4.1 frame) that originates from ODTU4.1 Signal # 1 (e.g., byte-field “1-1“).

This figure also shows that the next 79 bytes (within this OPU4 frame) are the very first bytes (within each of their ODTU4.1 frames) originating from ODTU4.1 Signal # 2 through ODTU4.1 # 80.

We have designated the next 79 bytes as “2-1“, “3-1“, and so on, all the way to “80-1“.

This figure reinforces the fact that each of the ODTU4.1 streams must also be frame-aligned with each outbound 80 OPU4 frame Superframe.

To better appreciate these concepts, I strongly recommend you check out this portion of Lesson 5 within THE BEST DARN OTN TRAINING..PERIOD course.  

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

Discounts Available for a Short Time!!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

What is the OMFI Field?

This post defines the acronym OMFI (OPU Multi-Frame Indicator). It also describes when and how we use the OMFI field in OTN (Optical Transport Network) applications.

What is the OMFI (OPU Multi-Frame Indicator) Field?

Introduction

OMFI is an acronym for “OPU Multi-Frame Indicator.”

We use the OMFI field when mapping/multiplexing multiple lower-speed ODUj tributary signals into an ODU4 server signal (where j ranges from 0 through 3 and can include flex or 2e).

Whenever we are mapping/multiplexing these lower-speed ODUj tributary signals into an OPU4 server signal, we will do so on an 80 OPU4 frame Superframe basis.

As we map and multiplex these lower-speed ODUj tributary signals into an OPU4 signal, we will create as many as 80 sets of GMP Mapping Parameter for each Superframe.

At the Source PTE (Path Terminating Equipment), the ODUj to OPU4 Mapper Circuit will insert each of these 80 GMP Mapping Parameters into the Overhead Fields of the 80 consecutive OPU4 frames within each Superframe.

The payload portions of each of these OPU4 frames will contain multiplexed ODTU4.ts data (e.g., ODTU4.1, ODTU4.2, ODTU4.8, ODTU4.31, or ODTU4.ts data-streams).

The Source PTE will transmit these OPU4 frames to the Sink PTE (at the other end of the path).

At the Sink PTE, the OPU4 to ODUj De-Mapper circuit will need to know which set of GMP Parameter data pertains to which ODTU4.ts data-stream to properly de-map out these ODUj tributary signals from these ODTU4.ts signals, within the incoming OPU4 signal.

The de-mapper will use the OMFI field (within each OPU4 frame) to figure this out.

We will explain this concept in greater detail later on in this blog.

Where is the OMFI field located?

If we are dealing with an OPU4 frame, the OMFI field will reside within the OPU4 Overhead in Row # 4 and Column Byte # 16.

Figure 1 shows a drawing of an OPU4 frame in which we highlight the location of the OMFI field.

OMFI Location
Figure 1, Location of the OMFI field within the OPU4 Frame

The OMFI field does not exist in OPUk frames for any other rates.  The OMFI field only exists within the OPU4 frame.

In other words, OPUflex, OPU0, OPU1, OPU2, OPU2e, and OPU3 frames will NOT have an OMFI field.

When would we use the OMFI field?

We will only use the OMFI field if mapping/multiplexing some lower-speed ODUj tributary signals into an OPU4 server signal.

In other words, we would use the OMFI field if we wish to perform any of the following mapping/multiplexing operations:

  • 80 ODU0 tributary signals into an OPU4
  • 40 ODU1 tributary signals into an OPU4
  • 10 ODU2 (or ODU2e) tributary signals into an OPU4
  • 2 ODU3 tributary signals into an OPU4
  • Various combinations of rates/number of ODUflex tributary signals into an OPU4 server signal

Further, we can also use the OMFI field if we are mapping/mapping multiple combinations of rates of ODUflex signals along with the appropriate number of other ODUj tributary signals (where j can be 0, 1, 2/2e, or 3) into an OPU4 server signal.

NOTE:  We do NOT use the OMFI field if we map some non-OTN client signals (such as 100GbE/100GBASE-R) into an OPU4 signal.

So What does the OMFI field do?

The OMFI field is a byte-wide counter that counts from 0 to 79 and then overflows back to 0 repeatedly.

More specifically, a piece of OTN Network Equipment (e.g., the Source PTE) will (at some point) transmit an OPU4 frame with the OMFI field set to the value “0x00”.

When the Source PTE transmits the next OPU4 frame, it will set its OMFI byte-field to 0x01.   The Source PTE will increment the value that it writes into the OMFI byte-field within each OPU4 frame it generates and transmits.  

Eventually, the Source PTE will transmit an OPU4 frame with the OMFI field set to the value 0x4F (which is the number 79 in decimal format).

Afterward, when the Source PTE transmits the next OPU4 frame, it will set the OMFI field back to 0x00, and it will continue to send another set of 80 consecutive OPU4 frames in this manner, repeatedly.

This means that the OTN network can (and does) use the OMFI field to group 80 consecutive OPU4 frames into an OPU4 Superframe.

We will discuss these OPU4 Superframes later on in this post.

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

Corporate Discounts Available!!!

Why can’t we use the MFAS field for OPU4 Applications?

This is a good question.

The MFAS field (like the OMFI field) is a byte-wide counter.  The behavior and function of these two bytes are very similar.

NOTE:  Please see the OTUk Post for more information about the MFAS field.

The Source STE increments the value within the MFAS byte as it transmits each new OTUk frame.

However, the OMFI byte-field only counts from 0 to 79, and then it overflows back to 0 and then repeats the process.

The MFAS byte counts from 0 to 255, overflows back to 0 and then repeats the process indefinitely.

The MFAS field is convenient for grouping 256 consecutive OTUk/ODUk/OPUk frames into a 256-frame Superframe.

It is also suitable for grouping 4, 8, 16, and 32 consecutive OPUk frames in smaller Superframes. 

NOTE:  We use the MFAS byte when mapping/multiplexing lower-speed ODUj tributary signals into ODU1, ODU2, or ODU3 server signals.  

In short, the MFAS is great for grouping OPUk frames into Superframes with sizes of 2n consecutive OPUk frames (e.g., 22 = 4, 23 = 8, 24 = 16, 25 = 32, and so on).

However, no integer value for n (within the expression 2n) will give you a value of 80.

Thus, if I want to group 80 ODU4 frames into an ODU4 Superframe, the MFAS byte is useless for that purpose.

We need a different byte for this role.  This is why we have the OMFI byte field.

Would we use the OMFI field for the AMP (Asynchronous Mapping Procedure)?

In a word, “No.”

When mapping client signals into an ODU4 server signal, we will ONLY use the GMP (Generic Mapping Procedure).

We never use AMP to map client signals into an OPU4 payload.  This is NOT allowed per ITU-T G.709.

NOTE:  This statement is true, whether we are mapping non-OTN client data (such as 100GBASE-R) or lower-speed ODUj tributary signals into an OPU4 signal.

To be clear, we can use AMP to map client signals into OPU1, OPU2, and OPU3 server signals but not into an OPU4 server signal.

This is a good trick question, however.

This is a trick question because if we were using AMP to map client data into an OPUk frame, then the NJO (Negative Justification Opportunity) byte would occupy the same byte position that the OMFI field occupies for OPU4 applications.

NOTE:  Please see the AMP (Asynchronous Mapping Procedure) post for more information on the NJO byte.

How do we use the OMFI field in a system application?

Let’s assume we wish to map and multiplex 80 ODU0 tributary signals into an OPU4 server signal.

If we want to do this, ITU-T G.709 states that we should perform this mapping/multiplexing in a five-step process.

  • Convert each ODU0 signal into an Extended ODU0 signal.
  • Use GMP to map each of the 80 ODU0 signals into their ODTU4.1 structure/signal.  This step will create 80 ODTU4.1 signals.
    • As we perform this task, we will create 80 sets of GMP Mapping parameters that we will load into the Overhead Portion of 80 sets of ODTU4.1 frames.  
  • Byte interleaves all 80 of the payload portion of these ODTU4.1 signals together into a single data stream.
  • Load this byte-interleaved ODTU4.1 payload data into the OPU4 payload within each outbound OPU4 frame.
  • Load the GMP mapping parameters (within the ODTU4.1 Overhead) into the OPU4 overhead.  

Please see the Extended ODUj Post for more details on the Extended ODU0 signal.

What is an ODTU4.1 Frame/Signal?  

The standards define the ODTU4.1 as Optical Data Tributary Unit (for an OPU4/ODU4 server signal) with 1 (one) Time-Slot.

For this post, I will state that the ODTU4.1 structure/signal is an intermediate frame/signal (defined in ITU-T G.709). 

We only use this frame/signal whenever mapping/multiplexing ODU0 tributary signals into an OPU4 signal.

We present a more thorough description of the ODTU4.1 structure in another post.

Figure 2 shows a drawing of a Mapper Circuit that performs this two-step Mapping/Multiplexing Process.

ODU0 to OPU4 Mapper Circuit

Figure 2, Illustration of an 80 ODU0 Signal to OPU4 Mapper Circuit

Whenever we GMP map a given ODU0 signal into an ODTU4.1 structure, the Mapper circuit will compute the resulting GMP parameters for this single mapping operation.

What’s the Deal with the Number 80?

Since we individually map each of the 80 ODU0 tributary signals into their ODTU4.1 structure, and since each of the 80 ODU0 signals CAN be asynchronous to the remaining 79 ODU0 signals, there will be 80 unique sets of GMP mapping parameters within this OPU4 signal.

The ODU0 to OPU4 Mapper circuit will need to insert each of these 80 sets of GMP parameters into the OPU4 data stream to provide the OPU4 to ODU0 De-Mapper circuit (at the remote Sink PTE) with the GMP Justification Control information that it needs to be able to properly de-map out each of the ODU0 tributary signals from their ODTU4.1 signal.

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

Discounts Available for a Short Time!!!

So, where does the Mapper Circuit insert the GMP parameters (for all 80 ODU0s) into the OPU4 Frame?

I mentioned earlier that when mapping lower-speed ODUj tributary signals into an OPU4 signal, we execute this procedure by creating an 80 OPU4 frame Superframe.

In other words, as we map and multiplex these 80 ODU0 signals into the OPU4 signal, we will also create these 80 OPU4 frame Superframes.

In the OPU Post, I stated that each OPUk frame consists of an OPUk Payload and OPUk Overhead.

Thus, an 80 OPU4 frame Superframe will contain 80 sets of OPU4 payload and will also include 80 sets of OPU4 overhead.

Please note that each of these OPU4 Superframes contains 80 frames and we are trying to map 80 ODU0s into an OPU4 is NOT a coincidence.

This was all done by design.

ITU-T G.709 states that an ODU0 to OPU4 Mapper circuit should insert the GMP parameters (that we obtained when we GMP mapped ODU0 # 1 into its ODTU4.1 frame/signal) into the JC1 through JC6 bytes within the Overhead of OPU4 Frame # 1 (within the 80 OPU4 Frame Superframe).

Likewise, the standard also states that the Mapper should insert the GMP parameters (we obtained when we mapped ODU0 # 2 into its ODTU4.1 frame/signal) into the JC1 through JC6 bytes within the Overhead of OPU4 Frame # 2.

This process should continue to OPU4 Frame # 80.

At this point, the ODU0 to OPU4 Mapper circuit has completed its transmission of an 80 OPU4 Frame Superframe, and it should start transmitting a new Superframe by sending OPU4 Frame # 1 again (and so on).

But How Do We Know Which OPU4 Frame is OPU4 Frame # 1, # 2, and so on?

The short answer is the contents of the OMFI byte of each of these OPU4 frames.

Whenever the OMFI byte (within a given OPU4 frame) is set to “0x00”, we can state that this particular OPU4 Frame is the first frame in the 80-frame Superframe.

Hence, we can designate this frame as OPU4 Frame # 1.

Likewise, whenever the OMFI byte (within a given OPU4 frame) is set to “0x01”, we can state that this particular OPU4 frame is the second frame in the 80-frame Superframe.

Thus, we can designate this frame as OPU4 Frame # 2, and so on.

We Use the OMFI Byte to Identify Each of these 80 OPU4 frames.

Therefore, if the Sink PTE (at the remote end) receives an OPU4 frame, in which the OMFI byte is set to “0x00”, then we know the following things about the overhead data within that frame.  We understand that the data (within the JC1 through JC6 bytes) will contain the GMP parameter data we obtained when the Source PTE mapped ODU0 # 1 into its ODTU4.1 frame/signal.

Likewise, if the Sink PTE receives an OPU4 frame, in which the OMFI byte is set to “0x01”, we know the following about the overhead data within this frame.  We understand that the data (within the JC1 through JC6 bytes) will contain the GMP parameter data we obtained when the Source PTE mapped ODU0 # 2 into its ODTU4.1 frame/signal.

And so on, for the remaining 78 frames within this OPU4 frame Superframe.  

Figure 3 presents an abbreviated drawing of an 80 OPU4 Frame Superframe.

This figure also shows some helpful information about the contents of the Overhead data within each of the OPU4 frames. 

More specifically, this drawing also identifies which ODU0 to ODTU4.1 frame GMP mapping operation these overhead fields pertain to within each OPU4 frame.

80 OPU4 Frame Superframe

Figure 3, Illustration of an 80 OPU4 Frame Superframe

For example, for OPU4 Frame 1, some red text states the following:  “GMP Mapping Data associated with ODTU4.1/ODU0 # 1″. 

This text means that the six Justification Control bytes (e.g., the JC1 through JC6 byte – in the Pink Fields) contain the GMP mapping parameters that the Source PTE generated when it GMP mapped ODU0 # 1 into ODT4.1 signal # 1.    

This is handy information for the Sink PTE.  

So what does the De-Mapper Circuit do?

As the De-Mapper circuit (within the remote Sink PTE) receives and processes these OPU4 frames, it will need to execute the following two-step procedure to properly de-map and recover these ODU0 tributary signals from this incoming OPU4 data stream.

  • Byte de-interleaves the OPU4 payload data into 80 parallel streams of these ODTU4.1 signals.
  • Use GMP to de-map each ODU0 signal from their ODTU4.1 signal (e.g., de-map 80 ODU0 signals out of 80 ODTU4.1 signals)

I show an illustration of an OPU4 to 80 Channel ODU0 De-Mapper circuit below in Figure 4.

OPU4 to ODU0 De-Mapper Circuit

Figure 4, Drawing of an OPU4 to 80 Channel ODU0 De-Mapper Circuit

De-Mapping the ODU0 Signal from Each ODTU4.1 Signal

However, for the de-mapper circuit (within the Sink PTE) to do this successfully, it will need to have the correct GMP mapping parameters that the Source PTE created at the remote end. 

In other words, for the Sink PTE to de-map out ODU0 # 1 from ODTU4.1 signal # 1, it will need to have the same GMP mapping parameters that the Source PTE (at the remote end) generated when it mapped ODU0 # 1 into ODTU4.1 signal # 1, in the first place.  

Likewise, for the Sink PTE to de-map out ODU0 # 2 from ODTU4.1 signal # 2, it will need to have the same GMP mapping parameters that the Source PTE (again, at the remote end) generated when it mapped ODU0 # 2 into ODTU4.2 signal # 2.  

The Sink PTE will receive 80 sets of GMP mapping parameters within each 80 Frame OPU4 Superframe.  

How does the Sink PTE know which (of the 80) GMP mapping parameters to use if we wish to de-map out ODU0 # 1 from ODTU4.1 signal # 1?  

Answer:  It needs to use the overhead data within the OPU4 frame, in which the OMFI byte is set to 0x00.

Thus, the de-mapper circuit must rely on the OMFI value to keep this information straight.

In other words, the Sink PTE will use the OMFI byte to properly marry up each of the 80 GMP mapping parameters (within the incoming OPU4 data stream) with 80 ODTU4.1 data streams.  

Hence, using the OMFI byte, the Sink PTE will be able to correctly de-map out all 80 ODU0 signals from each of their ODTU4.1 signals that we extract from the incoming OPU4 data stream.  

Does ITU-T G.798 Define any Defects that Pertain to the OMFI field?

Yes, ITU-T G.798 does define the dLOOMFI (Loss of OMFI Synchronization) defect for applications in which we are mapping and multiplexing lower-speed ODUj signals into an OPU4/ODU4 signal.

I discuss how ODU-Layer circuitry will declare and clear the dLOOMFI defect condition within Lesson 10 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

Summary and Other Related Postings

This post describes the OMFI field (within the OPUk frame) and how we use it whenever we are mapping and multiplexing 80 ODU0 signals into an OPU4/ODU4 signal.  We also have similar postings (on the OMFI field) for the following cases.

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

Discounts Available for a Short Time!!!

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

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

OTUkV – Functionally Compliant OTU Frames

This post describes the differences between a Fully-Compliant OTUk frame and a Functionally-Compliant OTUkV frame.

What are OTUkV/Functionally-Compliant OTUk Frames?

There are two broad categories of OTUk Frames.

  • There are the Fully-Compliant OTUk Frames (which we will refer to as OTUk frames).
  • And there are the Functionally-Compliant OTUk Frames (which we will refer to as OTUkV frames).

To help show how the OTUkV frames differ from the OTUk frames, I will first discuss the Fully-Compliant OTUk frames.

Please note that you can find a much more in-depth discussion of the Fully-Compliant OTUk Frame here in the OTUk Post.

The Fully-Compliant OTUk Frame

There is only one type of Fully-Compliant OTUk frame.

The Fully-Compliant OTUk frame is a frame that entirely complies with all the ITU-T G.709 recommendations for an OTUk frame.

It has the exact field formats and field sizes/types that are specified within ITU-T G.709.  Figure 1 presents an illustration of the Fully-Compliant OTUk frame.

ITU-T G.709 Fully Compliant OTUk Frame

Figure 1, Illustration of the Fully-Compliant OTUk Frame

The OTUk Post already discusses and defines each of these OTUk Overhead fields.  Thus, we will not repeat that information in this post.

ITU-T G.709 states that the Fully-Compliant OTUk Frame should have all the following features/attributes.

  • The overall frame size should be a 4 Row by 4080 Byte Column Structure.
  • It contains an OTUk Overhead of 14 bytes that matches the Overhead fields described in the OTUk Post.
  • The frame contains the three rows by 14-byte column ODUk Overhead field that matches the Overhead fields described in the ODUk Post.
  • The OTUk frame contains a 4 row by 3808-byte OPUk field, along with a 4 row by 2-byte column OPUk overhead that matches the Overhead fields described in the OPUk Post.
  • It includes a 4 row by 256-byte column structure for FEC (Forward Error Correction) that we can compute using the Reed Solomon, RS(255,239) scheme.

Some industry people simply refer to this type of FEC as “GFEC” (because it complies with the ITU-T G.709 requirements for FEC).

NOTE:  We will refer to the Reed-Solomon FEC (as called out in ITU-T G.709) as “GFEC” throughout the rest of this post.

If the OTUk frame differs from these characteristics by even one item, then we cannot refer to this type of frame as being a Fully-Compliant OTUk frame.

We must refer to this type of frame as a Functionally Compliant OTUkV frame.

The Functionally-Compliant OTUk (OTUkV) Frame

In contrast to the Fully-Compliant OTUk frame, ITU-T G.709 identified six (6) variations of OTUkV frames.
These six variations are:

  • OTUkV frame with Alternative 7% FEC (also referred to as the OTUk-v frame)
  • OTUkV frame with Larger/Stronger FEC
  • OTUkV frame with Smaller FEC
  • OTUkV frame without FEC
  • OTUkV frame with Different Frame Structure and FEC Area
  • OTUkV frame with Different Frame Structure and No FEC Area

We will describe each of these variations of OTUkV frames below.

NOTE:  The reader should not consider this list of types of OTUkV frames to be an exhaustive list.

Other variations within these frames are possible (and still qualify at OTUkV frames).

OTUkV Frame with Alternative 7% FEC

This type of OTUkV frame is ALMOST the same as the Fully-Compliant OTUk frame.  It has the same set of fields (payload and overhead bytes).  It also has the same frame size (e.g., 4080-byte columns by four rows).

The only difference between this particular Functionally-Compliant OTUkV frame and the Fully-Compliant OTUk frame is how we calculate the FEC.

Figure 2 illustrates the field format for this particular OTUkV frame.

Functionally Compliant OTUkV Frame with Alternative 7 Percent FEC

Figure 2, Illustration of the OTUkV Frame with Alternative 7% FEC

Other “7% FECs” exists other than the Reed-Solomon FEC (or GFEC).

If an OTUk frame uses one of these alternative types of FECs, rather than the “GFEC,” then we need to refer to this frame as an OTUkV Functionally Compliant frame.

NOTE:  Some OTN-related documentation refers to these functionally-compliant OTUk frames as OTUk-v frames.

OTUkV frame with Larger/Stronger FEC

Some applications need the use of a Stronger FEC.

These are applications in which the system design requires a much larger NCG (Net Coding Gain).

Long-Haul applications (where there are long fiber spans between 3R regenerators) are examples of such applications.

These applications will need a more robust FEC, which (in turn) will need a larger FEC area within the OTUkV frame.

Figure 3 presents an illustration of this type of OTUkV frame.

Functionally Compliant OTUkV Frame with Larger FEC

Figure 3, Illustration of the OTUkV Frame with Larger/Stronger FEC

Since we are using a larger FEC (and larger FEC area), this type of OTUkV frame will be larger than that for the Fully-Compliant OTUk frame.

This type of OTUkV frame will have 4080 + X byte columns and 4-byte rows.

NOTE:  In most cases, for a given value of k (in OTUk/kV), the Frame Repetition rate will be the same for all OTUk/kV-type frames.

For example, if you look at the OTUk post, you will see that the Frame Repetition Rate for an OTU2 signal is 82,028 frames/second.

We can state that this also means that the Frame Repetition rate for an OTU2V frame (a different size than that for the OTU2 frame) will also have this same frame repetition rate.

This means that the OTUkV frame, which is larger than its OTUk counterparts, will need to operate at a higher bit rate to transmit these frames than that to transmit the OTUk frames.

Similarly, OTUkV frames that are smaller in size than their OTUk counterparts will need to operate at a lower bit rate to transmit these frames than that to transmit the OTUk frames.

OTUkV frame with Smaller FEC

There will be applications where we will not need an FEC as large as the 7% GFEC.  In these applications, we can get away with using smaller FECs.  Figure 4 illustrates an OTUkV frame with this kind of FEC.

Functionally Compliant OTUkV Frame with Smaller FEC

Figure 4, Illustration of the OTUkV Frame with Smaller FEC

You can see that Figure 4 shows that this type of OTUkV frame is of the same frame size as that for the Fully-Compliant OTUk frame.

In this case, the actual FEC takes up less “real estate” than that for the GFEC.  However, the unused portions of the FEC field are filled with an All-Zeros pattern to “pad out” the remaining FEC byte fields.

OTUkV frame without FEC

There will be applications that will require OTUkV frames without FEC.  Some of these applications will typically be very low-latency applications (e.g., for Enterprise Applications such as Real-Time Stock Quotes, etc.).

FEC coding and decoding all require some number crunching that does consume a finite amount of time and increases latency.

Figure 5 presents an illustration of this type of OTUkV frame.

Functionally Compliant OTUkV Frame with NO FEC

Figure 5, Illustration of the OTUkV frame without FEC

NOTE:  Some applications will implement the “No-FEC” OTUkV frame by filling the entire FEC field (as drawn in Figure 1) with an all-zero pattern.

In this case, the “No-FEC OTUkV frame” would be the same size as the Fully-Compliant OTUk frame.

Figure 6 presents an illustration of this example OTUkV frame.

Fully Compliant OTUk Frame with All Zeros FEC

 

Figure 6, Illustration of the No-FEC OTUkV frame with the entire FEC field set to an All-Zeros pattern

OTUkV frame with Different Frame Structure and FEC Area

OTUkV frames of completely different Frame Structure (from the Fully-Compliant OTUk frame) can be (and are) sent out onto the OTN network.

Before the days of OTUCn, some people used these types of frames to (for example) support “200Gbps or More” Operations.

In this case, an entire OTU4/4V frame (within a given OTU4 signal) could be mapped into one of these structures.  Afterward, we could bit-interleave this structure with other structures (from another OTU4 signal) to achieve “200Gbps” transmission.

I will elaborate on the actual mechanics behind this scheme in another post.

Figure 7 illustrates the With-FEC version of this “Different Structure” OTUkV frame.

OTUkV Structure with Different Frame Structure and FEC

Figure 7, Illustration of the OTUkV Frame with Different Frame Structure and FEC Area

OTUkV frame with Different Frame Structure and No FEC Area

This type of frame would have a similar use to that in the previous section.

The only difference between this frame and that of the previous frame is that this particular frame does not contain an FEC.

Again, a possible application (for this type of frame) would be to support 200Gbps (or higher rate) applications.

In this case, we would map an OTU4/4V frame into this structure.

Afterward, we would combine this signal with another by bit-wise multiplexing this data with another such signal (from another OTU4/4V signal) when transmitting this data to the line.

In this case, we might not need the FEC because the OTU4/4V frames (carried within this structure) might already have their own FEC.

Figure 8 presents an illustration of this type of OTUkV frame.

OTUkV Structure with Different Frame Structure and No FEC

Figure 8, Illustration of the OTUkV Frame with Different Frame Structure and No FEC Area

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

Discounts Available for a Short Time!!

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

OTN Related Blog

OTN Related Topics within this Blog

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

The AMP (Asynchronous Mapping Procedure)

This post discusses and describes the AMP (Asynchronous Mapping Procedure) that one can use to map client signals into OTN signals and transport them through the Optical Transport Network (OTN).

What is the AMP (Asynchronous Mapping Procedure)?

This post describes the AMP (Asynchronous Mapping Procedure) for mapping a non-OTN CBR (Constant Bit Rate) client signal into an OPUk/ODUk signal.

ITU-T G.709 also states that the system designer can use AMP to map lower-speed ODUj tributary signals into a higher-speed OPUk server signal.  We will discuss that topic in another post.

NOTE:  Whenever ITU-T G.709 discusses procedures for mapping a CBR client signal into an OPUk/ODUk signal, it will often refer to the OPUk/ODUk signal as the Server signal.  We will use the terms OPUk/ODUk and Server interchangeably throughout the rest of this post.

ITU-T G.709 also defines two other mapping procedures that one can use to map a non-OTN CBR client signal into a Server signal.

We discuss each of these two mapping procedures in other posts.

(*) – Requires membership to THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!  to see this post.  

What is the Asynchronous Mapping Procedure?

The name Asynchronous Mapping Procedure means that the timing relationship between the client signal (being mapped into an OPUk payload) and the bit-rate of the OPUk payload are close in frequency but still asynchronous.

This timing relationship is different from that for the BMP (Bit-Synchronous Mapping Procedure).

In BMP, the timing relationship between the Client Signal and the Server signal must be synchronized.  For AMP, we can say (in a “tongue-in-cheek manner”) that the timing relationship between the Client Signal and the Server signal is “close, but no cigar”!!  I’ll explain that comment below.

The System Designer must ensure that ALL the following is true before they can use the Asynchronous Mapping Procedure to map a non-OTN client signal into the OPUk payload.

  • The Client signal clock frequency must be within ±65pm of the OPUk Payload clock frequency.
  • The System-Designer must handle Rate differences (between the Client and the Server signal) via fixed and variable stuffing.
  • This ±65ppm tolerance accounts for the maximum variable stuffing (justification) limits.

How AMP Works

We begin our discussion of AMP by looking at the OPUk Overhead bytes.

In Figure 1, I illustrate the OPUk Frame (within the OTUk Frame).

OTUk Frame with OPUk Portion shown

Figure 1, Illustration of the OPUk Frame – within the OTUk Frame.

In Figure 2, I take a closer look at the OPUk frame structure and show a more detailed drawing of the OPUk Overhead Bytes within the OPUk Frame.

AMP Discussion - Basic Figure - Introduction of OPUk OH

Figure 2, Illustration of the OPUk Overhead Bytes – for AMP Applications

This figure shows five (5) Overhead Bytes that play a role in AMP.

  • JC1 – Justification Control Byte # 1
  • JC2 – Justification Control Byte # 2
  • JC3 – Justification Control Byte # 3
  • NJO – Negative Justification Opportunity Byte
  • PJO – Positive Justification Opportunity Byte

Figure 2 also shows the bit format for the three Justification Control Bytes.  This figure shows that Bits 1 through 6 (within each of these 3 bytes) are labeled RES (Reserved) and do not have a role in AMP.

This figure also shows Bits 7 and 8 (within these 3 bytes), which we have labeled JC7 and JC8, do have a role in AMP.

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

Discount Available for a Short Time!!!

Justification Events within an OPU Frame

We earlier stated that if the System Designer wishes to use AMP to map a non-OTN client signal into an OPUk frame, then they must make sure that the frequency differences between the client signal and that for the OPUk payload are within ±65ppm.

Since there is no requirement to phase-lock the OPUk Payload frequency to the client signal frequency (as ITU-T G.709 requires for BMP applications), it is unlikely that these two signals will be at the same rate.  

They will, most likely, be close (in frequency) to each other but off in one direction or the other.

In this case, the Source (OTN) Path Terminating Equipment (PTE) will generate many of its OPUk frames with no justification events.  But, because these two signal frequencies will typically not be identical, the Source PTE will eventually generate OPUk frames with justification events.  We sometimes call these justification events slip events in other forms of data communication.

NOTE:  These justification events are also similar to the pointer justification events in SONET/SDH Networks.

The Source PTE will use these Justification Events to compensate for the frequency differences between the Client and the server signal.  

Please see the post on “slip events” to understand the mechanics of slip events (e.g., why they occur and how we can elegantly handle them).

A Source PTE can generate three (3) types of OPUk frames in AMP.

  • OPUk frames with NO Justification Events (e.g., The Nominal Condition)
  • OPUk frames with Negative-Justification events (occurs periodically if the Client Bit Rate > OPUk Bit Rate)
  • OPUk frames with Positive-Justification events (appears regularly, if the Client Bit Rate < OPUk Bit Rate)

We will discuss each of these types of OPUk frames below.

The Normal Situation – The Source PTE creates an OPUk Frame with No Justification Activities.

Many of the OPUk frames that a Source PTE generates will belong to this category for AMP applications.

Figure 3 shows a drawing of an OPUk Frame, with NO Justification events occurring.

OPUk Frame - AMP Discussion - No Justification Event

 

Figure 3, An Illustration of an OPUk Frame with NO Justification events occurring

This figure shows that this OPUk frame does NOT have a Justification Event by:

  • Setting at least two (out of the three) sets of JC7 and JC8 bit-fields to [0, 0] as shown above.
  • The PJO byte field is currently carrying a client data byte (as it usually does) – in this OPUk frame.
  • The NJO byte field is NOT transporting a client data byte but is (instead) carrying a stuff byte (which is also a nominal condition).

The settings within the JC7 and JC8 bit-fields alert the Sink PTE (at the other end of the network) that there is no justification event occurring within this OPUk frame and:

  • That the PJO byte-field is currently carrying client data, and
  • The NJO byte field is transporting a stuff-byte (and is NOT transporting client data).

NOTE:  If (by design or accident) the OPUk payload rate is equivalent to the Client bit-rate, then the Source PTE will ALWAYS generate these types of OPUk frames (e.g., with NO Justification Events). 

If the System Designer has achieved this synchronous relationship (between the OPUk and the Client signal) by design, this becomes Bit-Synchronous Mapping (BMP).

Negative Stuff Event (Occurs if the Client Bit Rate > OPUk Bit Rate)

If the Client-data bit rate is slightly faster than that for the OPUk payload rate, then (with no intervention) the Mapper Buffer will eventually fill up.

AMP uses Negative-Stuffing (or Negative Justification) to prevent the Mapper buffer from Overflowing.  

In this case, the Source PTE will (temporarily) increase our Server (OPUk) signal’s bandwidth (to pull additional data out of the Mapper Buffer) by forcing both the PJO and the NJO bytes to carry client data momentarily.

Hence, for systems in which the Client data bit rate is faster than the OPUk payload bit rate, the Source PTE will periodically need to generate OPUk frames with Negative Justification to keep the Mapper Buffer from filling up.

Figure 4 shows a drawing of such an OPUk frame.

OPUk AMP Discussion - Negative Justification

 

Figure 4, Illustration of an OPUk Frame with Negative Justification occurring

This figure shows that this OPUk frame has a Negative Justification Event by setting at least two (of the three) sets of JC7 and JC8 bits to [0, 1], as I show above.  

The Source PTE will also (for this particular OPUk frame) use both the NJO and the PJO byte fields to carry client data bytes.

When the Source PTE sets the JC7 and JC8 bit-fields to these values, it notifies the Sink PTE (at the remote end of the network) of the roles of the NJO and PJO bytes within this OPUk frame.

NOTES:

  1. For the NO Justification OPUk frames, the NJO byte is considered part of the OPUk Overhead and usually does not transport any client data.  For Negative Justification OPUk frames, the NJO byte will (for this OPUk frame) be carrying client data.
  2. If the Client-data bit rate is faster than the OPUk Payload rate, then the PJO byte will ALWAYS carry client data (in every OPUk frame).  In this case, we will sometimes use the NJO byte to transport client data (within OPUk frames with justification events).

Positive Stuff Event (Occurs if the Client Bit Rate < OPUk Bit Rate)

If the Client-data bit-rate is slightly slower than that for the OPUk Payload rate, then (with no intervention) the Mapper Buffer will eventually be depleted.

AMP uses Positive-Stuffing (or Positive Justification) to avoid depleting the Mapper buffer.  

In this case, the Source PTE will temporarily reduce the Server signal’s (e.g., the OPUk signal) bandwidth (for this OPUk frame) by forcing both the PJO and the NJO bytes to transport stuff (and NOT client) data.

Hence, for designs in which the Client data bit rate is slower than the OPUk payload, the Source PTE will periodically generate OPUk frames with Positive Justification to avoid depleting the Mapper Buffer.

NOTE:  For the NO Justification OPUk Frames, the PJO byte field will be carrying client data.  But, during Positive Justification frames, the PJO byte will transport a stuff (or dummy) byte instead.  In other words, the Positive Justification OPUk frame will not carry client data within the PJO byte-field. 

This action momentarily slows the rate at which the Server pulls data out of the Mapper Buffer and keeps the buffer from depleting.

Figure 5 shows a drawing of an OPUk frame with Positive Justification occurring.

OPUK Frame - AMP Discussion - Positive Justification Frame

 

Figure 5, Illustration of an OPUk Frame with Positive Justification occurring

This figure shows that this OPUk frame has a Positive Justification event by setting at least two (of the three) sets of JC7 and JC8 bits to “[1, 1].

When the Source PTE sets the JC7 and JC8 bit-fields to these values, it notifies the Sink PTE (at the remote end of the network) of the roles of the NJO and PJO bytes within this OPUk frame.

NOTE:  If the Client data rate is slower than the OPUk Payload rate, then the NJO byte will ALWAYS function as a stuff byte (e.g., never carrying client data), and the PJO will sometimes function as a stuff byte (during OPUk frames with justification events).

Interpreting the JC7 and JC8 Bits

Table 1 summarizes how to understand the JC7 and JC8 bits (within two out of the three Justification Bytes) and the corresponding roles for the NJO and PJO bytes within the OPUk Frame.

Table 1, How to Interpret the Settings of the JC7 and JC8 bits within Two (of the Three) Justification Bytes, and the corresponding roles for the NJO and PJO bytes within the OPU Frame – When Transporting a Non-OTN Client Signal

Relationship between JC7 and JC8 bits and the Justification of OPUk

AMP and De-Mapping Jitter

AMP poses some challenges for the System Designer’s efforts to control de-mapping jitter to meet system requirements.  BMP offers the best de-mapping jitter of the three recommended Mapping Procedures.  

However, AMP imposes all of the following contributions (and challenges) to meeting de-mapping jitter requirements.

  • The presence of OTUk/ODUk/OPUk overhead bytes within the OTN signal (this challenge exists for BMP as well)
  • Fixed-byte stuffing – while mapping the client signal into the OPUk frame (this challenge exists for BMP as well)
  • Justification Events, also known as variable-stuffing, are unique to AMP.

Each Justification Event imposes 8UI-pp of mapping-related jitter within the client signal.

The System Designer will need to implement some clock-smoothing or jitter attenuation scheme to comply with de-mapping jitter requirements.

If the System Designer is transporting SONET/SDH data (which has very stringent jitter requirements) through the OTN, we recommend using BMP instead of AMP.  Otherwise, the designer will have to implement some very robust jitter attenuation solutions (at the Sink PTE) when de-mapping this client signal from the OPUk frame.

ITU-T G.709 Recommendations on Using AMP

Table 2 presents a list of the Non-OTN Client signals that ITU-T G.709 recommends using AMP when mapping these signals into each OPUk/ODUk Structures.

Table 2, List of Client Signals that ITU-T G.709 Recommends using AMP when mapping into an OPUk Structure

ITU-T G.709 Recommendations for AMP - Asynchronous Mapping Procedure

Can we use AMP for all OPUk rates?

We can use AMP for the OPU1, OPU2, and OPU3 server signals.  However, we cannot use AMP for mapping client signals into an OPU0 or OPU4 server signal.

ITU-T G.709 recommends using GMP to map client signals into OPU0 and OPU4 signals.

Summary

Table 3 summarizes the timing requirements (between the Client Clock Signal and that for the OPUk/ODUk clock) that the System Designer must follow before using any ITU-T G.709 Recommended Mapping Procedures.  Please note that I have highlighted the AMP items (within Table 3) with a “Red Rectangular” outline.

Table 3, Mapping Procedure Timing Requirements

ITU-T G.709 Requirements to use AMP - Asynchronous Mapping Procedure

 

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

Discounts Available for a Short Time!!!

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

OTN Related Blog

OTN Related Topics within this Blog

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