What is the RDI (Remote Defect Indicator)?

This post defines and describes the RDI (Remote Defect Indicator) signal. It also describes how and when Network Equipment will transmit this type of signal.


What is the RDI (Remote Defect Indicator) Signal?

What does RDI Mean?

RDI is an acronym for Remote Defect Indicator.

Where is the RDI Signal Used?

RDI is a special type of alarm signal that a Network Element (within a Telecom/Datacom application) will generate and transmit (back towards upstream Network Equipment) anytime it detects some sort of servicing-affect defect within the signal from that same upstream Network Equipment.

Stated differently, the Network Element (NE) will transmit the RDI indicator (upstream) at the same time (and under the same conditions) that it will transmit the AIS signal downstream.

For example:  If an NE were to declare the LOS (Loss of Signal) or the LOF (Loss of Frame) defect within its incoming telecom/datacom signal, then it will respond to this defect condition by transmitting the RDI signal (back) upstream towards the source of the defective signal.

Whenever the Network Element transmits this RDI signal upstream, it is notifying the upstream NE that there are problems with its data.

What EXACTLY is an RDI Signal?

The exact scheme that we use to transmit the RDI signal depends upon the telecom/datacom standard and network layer that we are operating in.

However, in most cases, the Network Element will typically transmit the RDI signal by setting a certain overhead bit-field (within the signal that it is transmitting back to the remote or upstream NE) to “1”.

The Network Element will consistently set this bit-field to “1”, within each frame of data (that it is transmitting back to the remote NE) for the duration that it is declaring the defect within its incoming data stream.

Likewise, the Network Element will end its transmission of the RDI signal by clearing that same overhead bit-field to “0”.

For OTN applications, we call the RDI signal the BDI (or Backward Defect Indicator) signal.

I have included posts that define and describe the BDI signal for both the OTUk and ODUk frames.

For example, SONET Line-Terminating Equipment will transmit the RDI-L indicator and SONET Path-Terminating Equipment will transmit the RDI-P indicator.

In the case of PDH signals (e.g., T1/E1 or T3/E3) will we typically call the RDI signal by other synonymous names such as FERF (Far-End Receive Failure) or the “Yellow Alarm”.

When do we transmit the RDI Signal?

We will go through a couple of examples to illustrate how and when we will transmit the RDI signal.

Example # 1 – The Unerred/Normal Condition

Figure 1 presents a very simple illustration of a portion of a 3R Repeater/Regenerator which consists of the following components:

  • Two (2) Receive Line Interface blocks (one block is labeled W for West, and the other block is labeled E for East)
  • Two (2) Receive Framer blocks (W – West, and E – East)
  • Two (2) Transmit Line Interface blocks (W – West, and E – East)
  • Two (2) Transmit Framer blocks (W – West, and E – East)
  • CS (Clock Smoothing/Jitter Attenuation) PLL (Phase-Locked Loop)
  • AIS OSC (Stand-Alone Oscillator)
  • FIFO/Buffer
  • Two (2) Defect Decoder blocks (W – West and E – East)

In this figure, our 3R Repeater/Regenerator is receiving a good (error-free) signal from the West Terminal.

The 3R Repeater/Regenerator will first receive this signal through its Receive Line Interface (W) block.

Afterward, this signal passes through to the Receive Framer (W) block.

If the Receive Line Interface (W) and Receive Framer (W) blocks were to detect no problems within this signal, then the 3R Repeater/Regenerator would allow this signal to pass through both the Transmit Framer (E) and Transmit Line Interface (E) blocks as is.

The Receive Line Interface (W) and the Receive Framer (W) blocks would also do nothing to impact the data, that the Near-End Transmitter circuitry (e.g., the Transmit Line Interface (W) and Transmit Framer (W) blocks) is transmitting, back out to the West Terminal.

Figure 1 presents an illustration of this Normal (No Defect) Condition.

3R Repeater/Regenerator during Normal Conditions

 

Figure 1, Illustration of the 3R Repeater/Regenerator – during Good/Normal Conditions.

Please note that I have grayed out the non-relevant portions of Figure 1, to focus our discussion on this Defect Declaration to RDI Generation mechanism, on the West-side of the 3R Repeater/Regenerator circuit.

Now, we will illustrate the case where we will transmit the RDI indicator.

Example # 2 – The dLOS/Abnormal Condition

Figure 2 presents another very simple illustration of a 3R Repeater/Regenerator.

However, in this figure, there is an impairment in the signal that originates from the West Terminal such that our Network Element is now declaring the dLOS (Loss of Signal) defect with this signal.

It is possible that this signal was severed by a backhoe or some other mishap.

Nonetheless, this means that our 3R Repeater/Regenerator is no longer receiving its signal from the West Terminal.

In this situation, the 3R Repeater/Regenerator will respond by doing all the following things.

  • The Receive Line Interface (W) or the Receive Framer (W) blocks will declare the dLOS (Loss of Signal) defect with the signal that it is receiving from the West Terminal.
  • The Transmit Framer (E) and the Transmit Line Interface (E) (which resides directly behind the Receiving Line Interface and Framer blocks – that are declaring the dLOS condition) will proceed to transmit the AIS indicator (to the East Terminal) as we discussed in the AIS post of this blog.
  • Additionally, the Receive Line Interface (W) and/or the Receiver Framer (W) blocks will also send a control signal to its “near-end” transmitting circuitry [e.g., the Transmit Framer (W) and Transmit Line Interface (W) blocks] to command it to start sending the RDI signal, back out to the West Terminal.

Figure 2 presents an illustration of the dLOS/RDI Transmission Condition for our 3R Regenerator/Repeater.

3R Repeater/Regenerator when transmitting RDI

Figure 2, Illustration of the 3R Repeater/Regenerator – during the dLOS/Abnormal Condition

The Transmit Framer (W) and Transmit Line Interface (W) blocks will continue to transmit the RDI indicator to the West Terminal for the duration that the Receive Line Interface (W) and the Receive Framer (W) blocks are declaring the dLOS defect with the signal that they are receiving from the West Terminal.

The Transmit Framer (W) and Transmit Line Interface (W) blocks will cease to transmit the RDI indicator once the Receive Line Interface (W) and the Receive Framer (W) blocks clear the dLOS defect and start to receive good/normal data from the West Terminal.

In addition to the dLOS defect, the Network Element will typically transmit the RDI Indicator (upstream) in response to any of the following other defects.

  • dLOF
  • dLOFLOM
  • dPLM
  • dTIM

Why do we bother to transmit the RDI Signal?

The main reason that we send the RDI signal (back to upstream equipment) in response to service-affect defects is to alert that NE that there is a service-affecting defect, within its output signal between its location and that of the next downstream NE.

This notification aids in troubleshooting and system debugging of fault conditions in the network.

What is AIS (Alarm Indication Signal)?

This post defines and describes the AIS (Alarm Indication Signal). It also describes how and when Network Equipment will transmit this type of signal.


What is an AIS (Alarm Indication Signal)?

What does AIS Mean?

AIS is an acronym for Alarm Indication Signal.

Where is the AIS Signal Used?

The AIS signal is a special type of alarm signal that a Network Element (within a Telecom/Datacom application) will generate and transmit (in its downstream path) anytime it detects some sort of service-affecting defect upstream.

For example:

If a Network Element (NE) were to declare the LOS (Loss of Signal) or the LOF (Loss of Frame) defect within its incoming telecom/datacom signal, then it will respond to this defect condition by transmitting the AIS signal downstream.

Whenever the Network Element transmits this AIS signal downstream, it is (in effect) replacing its defective incoming signal with the AIS signal.

What EXACTLY is an AIS signal?

The exact pattern/signature of an AIS signal depends upon the telecom/datacom standard and network layer that we are operating in.

For some datacom/telecom standards, the AIS signal is transmitted (and received) as an Unframed All Ones pattern.

In other standards, will transmit the AIS indicator as a Framed All Ones pattern (e.g., where the framing alignment fields are still using normal values, but the payload fields are filled with an All Ones pattern).

Finally, the OTUk AIS pattern is an Unframed PN-11 (PRBS11) pattern.

In all cases, the NE will generate and transmit the AIS signal at the nominal line-rate (of the normally transmitted signal).

The frequency accuracy requirements for this AIS signal also depends up the governing standards for the Telecom/Datacom system.

I have included posts that define the AIS patterns for both the OTUk and ODUk types of signals (for OTN applications).

When do we transmit the AIS pattern?

We will go through a couple of examples to illustrate how and when we will transmit the AIS signal.

Example # 1 – The Unerred/Normal Condition

Figure 1 presents a very simple illustration of a portion of a 3R Repeater/Regenerator which consists of the following components:

  • Two (2) Receive Line Interface blocks (one block is labeled W for West, and the other block is labeled E for East)
  • Two (2) Receive Framer blocks (W – West, and E – East)
  • Two (2) Transmit Line Interface blocks (W – West, and E – East)
  • Two (2) Transmit Framer blocks (W – West, and E – East)
  • CS (Clock Smoothing/Jitter Attenuation) PLL (Phase-Locked Loop)
  • AIS OSC (Stand-Alone Oscillator).
  • FIFO/Buffer
  • Two (2) Defect Decoder blocks (W – West, and E – East)

In this figure, our 3R Repeater/Regenerator is receiving a good (error-free) signal from the “West Terminal.”

The 3R Repeater/Regenerator will first receive this signal through its Receive Line Interface (W) block.

Afterward, this signal passes through to the Receive Framer (W) block.

If the Receive Line Interface (W) and the Receive Framer (W) blocks were to detect no problems within this signal, then the 3R Repeater/Regenerator will allow this signal to pass through both the Transmit Framer (E) and Transmit Line Interface (E) blocks as is.

Our 3R Repeater/Regenerator will then transmit this same data to the East Terminal.

Additionally, the Transmit Framer (E) and Transmit Line Interface (E) blocks would transmit the outbound data (towards the East Terminal) based upon the Recovered Clock signal (which originated from the West Terminal and has been routed through the Clock Smoothing PLL for Jitter Attenuation purposes).

Figure 1 presents an illustration of this Normal (No Defect) Condition.

Portion of 3R Repeater/Regenerator during Normal Operation

Figure 1, Illustration of the 3R Repeater/Regenerator – during Good/Normal Conditions.

Please note that I have grayed out the non-relevant portions of Figure 1, so that we can focus our discussion on this Defect Declaration to AIS Generation mechanism, in the West-to-East Terminal Path.

Now we will illustrate the case where we will transmit the AIS indicator.

Example # 2 – The dLOS/Abnormal Condition

Figure 2 presents another very simple illustration of a 3R Repeater/Regenerator.

However, in this figure, there is an impairment in the signal that originates from the West Terminal such that our Network Element is now declaring the dLOS (Loss of Signal) defect with this signal.

It is possible that this signal was severed by a backhoe or some other mishap.

Nonetheless, this means that our 3R Repeater/Regenerator is no longer receiving its signal from the West Terminal.

This also means that our 3R Repeater/Regenerator has no data to send to the East Terminal.

In this situation, our 3R Repeater/Regenerator will respond by doing all of the following things.

The Receive Line Interface (W) or the Receive Framer (W) blocks will declare the dLOS (Loss of Signal) defect with the signal that it is receiving from the West Terminal.

The Transmit Framer (E) and Transmit Line Interface (E) (which resides directly behind the Receiving Line Interface and Framer blocks – that are declaring the dLOS condition) will proceed to transmit the AIS indicator (to the East Terminal) as a replacement signal for the signal that we are no longer receiving from the West Terminal.

Additionally, the Transmit Framer (E) and Transmit Line Interface (E) blocks would transmit the AIS pattern (towards the East Terminal) based upon the output frequency of the AIS Oscillator (which is a stand-alone oscillator – that operates at the specified line-rate/clock frequency).

Figure 2 presents an illustration of the dLOS/AIS Transmission Condition for our 3R Regenerator/Repeater.

3R Repeater/Regenerator declaring dLOS and transmitting AIS

Figure 2, Illustration of the 3R Repeater/Regenerator – during the dLOS/Abnormal Condition.

The Transmit Framer (E) and Transmit Line Interface (E) blocks will continue to transmit the AIS indicator to the East Terminal for the duration that the Receive Line Interface (W) and the Receive Framer (W) blocks are declaring the dLOS defect with the signal that they are receiving from the West Terminal.

The Transmit Framer (E) and Transmit Line Interface (E) blocks will cease to transmit the AIS indicator once the Receive Line Interface (W) and the Receive Framer (W) blocks clear the dLOS defect and start to receive good/normal data from the West Terminal.

At this point, the Transmit Framer (E) and Transmit Line Interface (E) blocks will then proceed to transmit good/normal data to the East Terminal.

In addition to the dLOS defect, the Network Element will typically transmit the AIS indicator (downstream) in response to any of the following other defects.

  • dLOF (Loss of Frame Defect)
  • dLOFLOM (Loss of Frame – Loss of Multiframe Defect)
  • dPLM (Payload Type Mismatch)
  • dTIM (Trail Trace Identifier Mismatch)

Why do we bother to transmit the AIS signal as a replacement signal?

There are several reasons why we transmit the AIS indicator downstream, in response to service-affecting defects.

I will list some of those reasons below.

  • Alerts downstream equipment that a service-affect defect has been detected upstream.
  • To suppress (or prevent) the downstream equipment from declaring their own service-affecting defect.
  • Aids in troubleshooting and system debugging.  It is a lot easier to isolate the causes of defect conditions if we know exactly which NE is declaring the defect and not the whole chain of NEs downstream.
  • Provides the downstream Receive Circuitry with a much-needed clock signal at the correct bit-rate.  Clock Recovery PLLs (Phase-Locked-Loops) and Bias Controllers (for Optical Receive circuitry) all need for upstream NEs to provide them with a line signal with the appropriate timing (bit-rate).

The AIS signal accomplishes this goal.

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 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 signals into a higher-speed OPUk signal.  We will discuss this topic in another post.

NOTE:  Whenever ITU-T G.709 discusses procedures, on how to map 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 other two mapping procedures in other posts.

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 nominally equivalent, but still asynchronous.

This timing relationship is in contrast to that for BMP (Bit-Synchronous Mapping Procedure).

In the case of BMP, the timing relationship between the Client Signal and the Server signal need to be synchronized.  In the case of 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 below.

The System Designer must ensure that ALL the following is true before he/she can use the Asynchronous Mapping Procedure to map a certain 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 both 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 taking a look at the OPUk Overhead bytes.

Figure 1 presents an illustration of the OPUk Frame (within the OTUk Frame).

OTUk Frame with OPUk Portion shown

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

Figure 2 takes a closer look at the OPUk frame structure and presents a more detailed illustration 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

Figure 2 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 breaks out and presents the bit format for each of the three Justification Control Bytes.  This figure shows that Bits 1 through 6 (within each of these 3 bytes), are labeled as RES (Reserved) and do not have a role in AMP.

But, this figure also shows that Bits 7 and 8 (within each of these 3 bytes), which we have labeled as JC7 and JC8, do have a role in AMP.

Justification Events within an OPU Structure

We earlier stated that if the System Designer wishes to use AMP for mapping a client signal into an OPUk frame, the System Designer 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 of the exact same frequency.  They will, most likely, be close (in frequency) to each other, but off in one direction or the other.

In this situation, the Source (OTN) Path Terminating Equipment (PTE) will generate most of its OPUk frames with no justification events.  But, because these two signal frequencies will typically not be identical, the Source PTE will eventually have to generate OPUk frames with justification events.  These justification events are commonly referred to as “slip events” in other forms of data communication.

NOTE:  These justification events are similar to the “pointer justification” events that can occur in SONET/SDH Networks.

The purpose of these justification events is to permit the Source PTE to compensate for these frequency differences.   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 these events).

Hence, from an AMP standpoint, a Source PTE can generate three (3) different type of OPUk frames.

  • OPUk frames with NO Justification Events (e.g., The Normal Condition)
  • OPUk frames with Negative-Justification events (occurs periodically, if the Client Bit Rate > OPUk Bit Rate)
  • OPUk frames with Positive-Justification events (occurs periodically, 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

For AMP applications, most OPUk frames, that a Source PTE generates, will belong to this category of OPUk frames.

Figure 3 presents an illustration 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

Figure 3 indicates 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 illustrated above.
  • The PJO byte field is now transporting client data (as it usually does) – in this particular OPUk frame.
  • The NJO byte field is not transporting client data (which is also a normal condition).

These settings within the JC7 and JC8 bit-fields alerts the Sink PTE (at the other end of the link) that there is no justification event occurring within this particular OPUk frame and that the PJO byte-field (also within this OPUk frame) is currently transporting client data.   This setting for the JC7 and JC8 bit-fields also alerts the Sink PTE that the NJO byte field 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 (with NO Justification Events).  If the System Designer has achieved this synchronous relationship (between the OPUk and the Client signal) by design, then this is also referred to as 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 implements “Negative-Stuffing” (or Negative Justification) to prevent the Mapper buffer from Overflowing.  In this case, the Server will (temporarily) be given more bandwidth (to “pull additional data out of the Mapper Buffer”), by designating both the PJO and the NJO bytes to temporarily carry client-data.

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

Figure 4 presents an illustration of such an OPUk frame.

OPUk AMP Discussion - Negative Justification

 

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

Figure 4 indicates 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 illustrated above.

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

NOTES:

  1. The NJO byte is normally considered to be a part of the OPUk Overhead and typically does not transport any client data.  But, during Negative Justification frames, the NJO byte will temporarily be transporting client data.
  2. If the Client-data bit rate is faster than that for the OPUk Payload rate, then the PJO byte will ALWAYS be used to transport client data, and the NJO byte will sometimes be used to transport client data (during OTUk/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 implements “Positive-Stuffing” (or Positive Justification) to prevent the Mapper buffer from becoming depleted.  In this case, the Server will (temporarily) be given less bandwidth, by designating both the PJO and the NJO byte as overhead and will not be transporting client data.

Hence, for designs in which the Client data bit rate is slower than that for the OPUk payload, the Source PTE will periodically be required to generate OPUk frames with Positive Justification, to keep the Mapper Buffer from becoming depleted.

NOTE:  The PJO byte field is normally responsible for transporting client data.  But, during Positive Justification frames, the PJO byte will assume the role of a “stuff (or dummy) byte” and will not transport any client data, within that particular OPUk frame.  This action momentarily slows the rate at which the Server is “pulling data out of the Mapper Buffer,” and keeps the buffer from being depleted.

Figure 5 presents an illustration 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

Figure 5 indicates 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], as illustrated above.

NOTE:  If the Client data rate is slower than that for 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 OTUk/OPUk frames with justification events).

Interpreting the JC7 and JC8 Bits

Table 1 summarizes how to interpret the settings of 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

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 any 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 (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 sort of clock-smoothing or jitter attenuation scheme to comply with de-mapping jitter requirements.

If the System Designer is transporting SONET/SDH data (which has stringent jitter requirements) through the OTN, he/she is strongly advised to use 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 signal from the OPUk frame.

ITU-T G.709 Recommendations on Using AMP

Table 2 lists out the Non-OTN Client signals that ITU-T G.709 recommends using AMP when mapping these signals into each of the 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 OPU1, OPU2, and OPU3.  However, we cannot use AMP for mapping client signals into an OPU0 or OPU4 signal.

ITU-T G.709 recommends that we use GMP for mapping client signal 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 of the 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

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 PSI – Payload Structure Identifier

This post describes the role of the PSI (Payload Structure Identifier) byte, within the OPUk Overhead, is used within the OTN.


What is the PSI – Payload Structure Identifier (Byte and Message)?

The PSI Byte

The PSI is an Overhead byte within the OPUk structure.  Figures 1 and 2 present the location of the PSI byte within the OPUk structure.

OPUk Frame with OPU Overhead Bytes Identified

Figure 1, Illustration of an OPUk Frame Structure with the Overhead Bytes Identified.

OPUk Frame with PSI - Payload Structure Identifier byte shown

Figure 2, Illustration of the OPUk Overhead – with the PSI Byte Identified 

The purpose of the PSI byte is to permit an OTN Path Terminating Equipment (PTE) to transport a 256-byte PSI (payload structure identifier) message throughout the OTN (Optical Transport Network).

Since each OPUk contains only 1 PSI byte, an OTN PTE will have to transmit 256 consecutive OPU frames to completely transmit this PSI message.

The OTN PTE will align its transmission of this 256 byte PSI message with the MFAS byte.

Please see the post on the OTUk Frame Structure for more information on the MFAS byte.

In other words, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x00”, then the OTN PTE will also be transmitting the first byte of the PSI message (e.g., PSI[0]) via the PSI byte-field.

Likewise, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x01”, then the OTN PTE will also be transmitting the second byte within this 256-byte message (e.g., PSI[1]) via the PSI byte field, and so on.

Figure 3 presents an illustration of the PSI Message (that the OTN PTE will transmit via the PSI byte-field).

OPUk Frame with PSI byte and PSI Message shown

Figure 3, An Illustration of an OTUk/OPUk Frame and the PSI Message (that the OTN PTE will transmit via the PSI byte-field)

The PSI Message

The PSI (Payload Structure Identifier) message is a 256-byte message that an OTN terminal will transport via the PSI byte, over the course of 256 consecutive OPUk/ODUk/OTUk frames.

PSI[0] – PT (Payload Type)

The first byte of the PSI Message (e.g., PSI[0]) carries the Payload Type (or PT).  The PT identifies the type of client data that the OPUk structure is transporting via its payload.  Table 1 presents a list of PT values along with the corresponding client data types (being transported within the OPUk Structure).

Table 1a, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part I

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1b, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part II

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1c, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part III

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1d, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part IV

PT - Payload Type - PSI Byte - Client Signal into OPUk

Other posts contain detailed information on how ITU-T G.709 recommends that the System Design map each of these client signals into their corresponding OPUk structure.

Click HERE for more information about the PT = 0x21 Method for Mapping/Multiplexing Lower-Speed ODUj signals into a Higher-Speed ODUk Signal.

The Remaining Bytes within the PSI Message

PSI bytes 1 and 3 through 255 are for “Mapping and Concatenation Specific” roles and are discussed in another post.  We also use these bytes to transport MSI (Multiplex Structure Identifier) information throughout the OTN.  We will use the MSI information for applications in which we are mapping/multiplexing lower-speed ODUj signals into higher-speed OPUk signals.

PSI byte 2, Bit 1 is the CSF (or Client Signal Fail) indicator.  PSI Byte 2, Bits 2 through 8 are currently reserved for “future standardization”.

We discuss the CSF indicator and the MSI information in other posts.

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 BMP (Bit-Synchronous Mapping Procedure)

This post describes the Bit-Synchronous Mapping (BMP) for mapping non-OTN CBR client signals into an OTN signal.


What is the BMP (Bit-Synchronous Mapping Procedure)?

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

NOTE:  Whenever ITU-T G.709 discusses procedures, on how to map a client signal into an OPUk/ODUk signal, it will often refer to the OPUk/ODUk signal as the Server signal.  Therefore, we will use the terms OPUk/ODUk and Server interchangeably, throughout the remainder 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 other two mapping procedures in other posts.

What is the Bit-Synchronous Mapping Procedure?  

The name “Bit-Synchronous Mapping Procedure” means that there is a bit-synchronous relationship between the client signal (that we are mapping into an OPUk payload) and bit-rate of the OPUk payload.

In other words, the System Designer must ensure that ALL the following conditions are true before he/she can use the Bit-Synchronous Mapping Procedure to map a certain client signal into the OPUk payload.

  • The OPUk/ODUk/OTUk clock signal must be phase-locked (or synchronized) to the client clock signal, as Figure 1 illustrates below.

Timing Requirements between Client Signal and OPUk/ODUk Signal to use Bit Synchronous Mapping Procedure - BMP

Figure 1, Illustration of the Synchronization Requirements (between the OPUk/ODUk/OTUk signal and the client signal) to use BMP

  • We must use fixed-stuffing to handled any rate differences (between the Client signal and OPUk/ODUk/OTUk signal).
    • In other words, we insert a fixed number of bits/bytes into the Server (OPUk) payload, along with the client data.
      • OPUk_rate = Client_rate + (Fixed_Stuff x Server_Frame_Rate);
  • Client bit-rate tolerances MUST NOT exceed the Server bit-rate tolerances.
    • For example, if the bit-rate tolerance for an OPUk is +/-20ppm, then the Client signal’s bit rate tolerance cannot exceed +/-20ppm.

ITU-T G.709 Recommendations on Using BMP

ITU-T G.709 recommends using BMP when mapping the following Client Signals into each of the OPUk/ODUk Structures that are listed in Table 1.

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

ITU-T G.709 Recommendations for the Bit-Synchronous Mapping Procedure (BMP)

BMP and De-Mapping Jitter

BMP offers the best de-mapping jitter, of any of the three recommended Mapping Procedures.  Fixed stuffing and the presence of the OTUk/ODUk/OPUk overhead bytes are the only contributions to mapping (and de-mapping jitter).  Justification events (which imposes 8UI-pp of mapping-related jitter) for AMP applications, do not occur in BMP.

However, the System Designer will still need to implement some sort of clock-smoothing or jitter attenuation scheme to comply with de-mapping jitter requirements.  This is especially true for SONET/SDH applications.

Summary

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

TABLE 2, MAPPING PROCEDURE TIMING REQUIREMENTS

BMP Mapping Requirements

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 are some OTN Mapping Procedures?

This post briefly lists and describes the various mapping procedures that have defined for OTN applications and specified in ITU-T G.709.


What are some Mapping Procedures for OTN?

This post reviews each of the standard procedures for mapping non-OTN client signals into an OTN (Optical Transport Network) signal.

There is another post that presents the procedure for mapping and multiplexing lower-speed ODUj signals into a higher-speed ODUk signal.

Introduction

OTN (Optical Transport Network) is a “transport technology.”  The purpose of OTN is to transport user (or client) data from “Point A” to “Point B.”

All this is analogous to a train system that transports passengers from one train station to another.  The OTN is the “train” in this case, and the client data are the passengers.

The client data can be a wide range of possible signals (or data types).  It could be 1GbE (1000BASE-X), 8Gbps Fibre Channel (FC-800), or a SONET/SDH signal.  Each of these types of signals (and more) can be transported from one location to another via the OTN.

Please note that as we discuss mapping (in this and other posts on this website), we are NOT talking the type of map that the figure below presents.

Mapping Client Signals into OPUk/ODUk/OTUk Frames

Whenever we map a client signal into an OTN signal, we are actually mapping this client signal into the OPUk portion of an OTUn frame.

Additionally, whenever we map a non-OTN client signal into the OPUk portion of an OTUn frame, we will map this client signal into the entire OPUk payload.

NOTE:  We do discuss OPUk and OTUn frames in other postings.

ITU-T G.709 has specified three types of mapping schemes that one can use when mapping client data into (or de-mapping client data from) an OPUk.

Each of these mapping procedures will use their form of rate-adaptation (e.g., adapting the rate of the client signal to that of the OTN signal).

I have discussed each of these mapping procedures, in greater detail – in other postings on this blog.

I will briefly describe each of these mapping procedures below.

BMP – Bit Synchronous Mapping Procedure

  • Requires that the following equation is true:

Client_Data_Bit_Rate = OPU_Payload_Carrying_Bit_Rate + some Fixed Stuffing

  • This means that the OPU Payload data clock signal should be phase-locked to the Client data clock signal.
  • BMP offers the best jitter performance for client signals that are de-mapped from OTN.

AMP – Asynchronous Mapping Procedure

  • AMP does not require that the timing between the Client_Data_Clock and the OPU_Payload_Data_Clock be synchronized (as is required for BMP).
  • However, the frequencies of the Client_Data_Clock and the OPU_Payload_Data_Clock signals must be within ±65ppm of each other, for AMP to be used.
  • In other words, the Client data rate can be slightly slower or faster than the OPUk Payload Carrying data rate.
  • The OTN terminal can accommodate these timing differences by performing negative or positive-stuffing on client data (at the Byte-level) in a manner similar to Pointer Adjustments in SONET/SDH.
  • De-mapping Jitter Performance for AMP is not as good as that for BMP.  The client data incurs 8 UIp-p of (pre-clock smoothing/jitter attenuation) jitter with each justification (negative or positive stuffing) event.

GMP – Generic Mapping Procedure

  • Requires that the Client bit-rate be less than or equal to the OPUk_Payload bit-rate.
  • In other words, the Client bit rate CANNOT be greater than the OPUk Payload bit rate.
  • GMP does not mandate any synchronization or frequency offset requirements.
  • One of the goals of GMP is to evenly distribute the Payload and Stuff Bytes throughout the OPUk payload to enhance de-mapping jitter performance.

When to use BMP, AMP, and GMP – per ITU-T G.709. 

ITU-T G.709 recommends the following mapping procedures for various Client signal types and OTN rates (see Tables 1 through 4 below)

Table 1, ITU-T G.709 Recommended Mapping Recommendations for SDH signals

Mapping Procedure for SDH (Synchronous Digital Hierarchy) Signals

Table 2, ITU-T G.709 Recommended Mapping Recommendations for Ethernet Signals

Mapping Procedure for Gigabit Ethernet Signals, 1000BASE-X, 10GBASE-R, 40GBASE-R, 100GBASE-R

Table 3, ITU-T G.709 Recommended Mapping Recommendations for Fibre Channel Signals

Mapping Procedure for Fibre Channel Signals

Table 4, ITU-T G.709, Recommended Mapping Recommendations for Misc Signals.

Mapping Procedures for GPON, InfiniBand Signals

Summary

Table 5 summarizes the timing requirements (between the Client Clock Signal and that for the OPUk/ODU clock) that the System Design must comply with before using any of these Mapping Procedures.

Table 5, Mapping Procedure Timing Requirements

Timing Requirements for BMP, AMP and GMP

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