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

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 is the OPU – Optical Payload Unit?

This post presents the definition of an OPU – Optical Payload Unit, within an OTU Frame.


What is the OPU – Optical Payload Unit?

An OPU (Optical Payload Unit) is that portion of an OTU Frame that transports “payload” or “client-data” throughout the Optical Transport Network.

An OPU is a subset of both an ODU (Optical Data Unit) and an OTU (Optical Transport Unit) Frame.

Figure 1 presents an illustration of an OTU Frame and also identifies the location of the OPU frame.

OPUk Frame - Byte Format

Figure 1, Illustration of an OTU Frame with the OPU Portion (of the Frame) identified.  

The OPU (just like its larger OTU cousin) will typically be given a designation such as OPU0, OPU1, OPU2, OPU3, and OPU4, depending upon the “data rate” or the Data Carrying Capacity of this structure.

Table 1 lists out the data carrying capacity for each of these types of OPU structures.

Table 1, The Data Carrying (Rate) or Capacity of each OPU Structure.

OPUk Bit Rates, OPU0, OPU1, OPU2, OPU2e, OPU3, OPU4, OPUC4

From this point forward, we will refer to the OPU structure as an OPUk (where k can be 0, 1, 2, etc… as presented in Table 1).

NOTE:  We describe the ODUflex/OPUflex structure in another post.

The Basic OPUk Frame Format

An OPUk frame consist of two types of bytes:

  • Payload Bytes (which are used to transport the Client Data) and
  • Overhead Bytes, which permit OTN equipment to manage the transport of this data.

ITU-T G.709 typically draws the OPUk Payload as a 4-Row x 3808-Byte-Column Structure, yielding a total of 15,232 bytes.

The OPUk Structure also includes 8 Overhead Bytes as well.  Hence, the full OPUk Frame (of OPU Payload and Overhead) is a 4-Row x 3810-Byte Column Structure, yielding a total of 15,240 bytes.

Figure 2 presents a Generic Illustration of the OPUk Framing Format with the OPUk Overhead Bytes highlighted.

Generic OPUk Frame

Figure 2, Illustration of a Generic View of the OPUk Structure (e.g., OPUk Payload with the Overhead Bytes highlighted).  

I refer to Figure 2 as being a “Generic Illustration” of the OPUk Structure, because it includes all possible names/roles for the Overhead bytes.

The names and roles of each of these OPUk Overhead bytes will change depending on which of the following four (4) modes that our system is operating in.

  • When operating at the OPU0 through OPU3 rates and using AMP/BMP Mapping
  • For the OPU0 through OPU3 rates and using GMP Mapping and
  • If operating at the OPU4 rate and using GMP Mapping to map/de-map Non-OTN Clients
  • For the OPU4 rate and using GMP Mapping to map/de-map lower-speed ODUj signals into/from this OPU4 signal.

We will briefly illustrate and describe the roles for the OPUk overhead for each of these operating modes.

The OPUk Frame Format and Overhead for the OPU0 through OPU3 rates, when we are using BMP/AMP

If we are supporting the OPU0 through OPU3 rates and if we are using AMP (Asynchronous Mapping Procedure) or BMP (Bit Synchronous Mapping Procedure) to map either non-OTN client data or lower-speed ODUj signals into this particular OPUk, then Figure 3 presents the appropriate OPUk Frame format and OPUk Overhead that we will be working with.

OPU0 through OPU3 AMP Applications

Figure 3, An Illustration of the OPUk Frame Format (and Overhead) for the OPU0 through OPU3 rates whenever we are using AMP or BMP.  

Figure 3 shows that the OPUk Frame (for this Operating Mode) has the following overhead bytes:

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

In the case of the OPU0 – OPU3/AMP/BMP modes, the JC1, JC2, JC3, NJO, and PJO bytes will all support the mapping and de-mapping of client data into and out of the OPUk signal.

Please see the AMP Post for more details on the roles of these byte-fields.

The PSI byte carries information about the type of client data that the OPUk frame is transporting.

Please see the PSI post for more details about the roles of this byte-field.

NOTE:  Figure 3 presents the appropriate OPUk Frame Format and Overhead to use for PT = 0x20 applications.

The OPUk Overhead for the OPU0 through OPU3 rates, when we are using GMP to map/de-map client signals into/out of the OPUk signal

If we are supporting the OPU0 through OPU3 rates and if we are using GMP (the Generic Mapping Procedure) to map either non-OTN client data or lower speed ODUj signals into this OPUk signal, then Figure 4 presents the relevant OPUk frame format and OPUk Overhead that we will be working with.

OPU0 through OPU3 - GMP Applications

Figure 4, An Illustration of the OPUk Frame Format for the OPU0 through OPU3 rates whenever we are using the GMP mapping procedure.  

Figure 4 shows that the OPUk Frame (for this Operating Mode) has the following overhead bytes:

  • JC1 – Justification Control Byte # 1
  • JC2 – Justification Control Byte # 2
  • JC3 – Justification Control Byte # 3
  • JC4 – Justification Control Byte # 4
  • JC5 – Justification Control Byte # 5
  • JC6 – Justification Control Byte # 6
  • PSI – Payload Structure Identifier byte

In the case of the OPU0 – OPU3/GMP modes, the JC1, JC2, JC3, JC4, JC5, and JC6 bytes will all support the GMP mapping and de-mapping of client data into/from an OPUk signal.

Please see the GMP Procedure for Mapping/De-Mapping Non-OTN Client signals post for more information on how we use these byte-fields to support the mapping/de-mapping of non-OTN client data.

Likewise, please see the GMP Procedure for Mapping/De-Mapping Lower-Speed ODUj Signals post for more information on how we use these byte-fields to support the mapping/de-mapping of lower-speed ODUj signals.

The PSI byte carries information about the type of client data that the OPUk frame is transporting.

Please see the PSI post for more details about the roles of this byte-field.

NOTE:  Figure 4 presents the appropriate OPUk Frame Format and Overhead to use for PT = 0x21 applications.

The OPUk Overhead for OPU4 Applications – Non-OTN Client Case

If we are supporting the OPU4 rate and if we are also using GMP to map/de-map a non-OTN client signal into/from this OPU4 signal, then Figure 5 presents an illustration of the appropriate OPU4 frame format overhead fields that we will be working with.

OPU4 Frame for Non-OTN Client applications

Figure 5, An Illustration of the OPU4 Frame structure, whenever we are using GMP to map/de-map a non-OTN client.  

Figure 5 is very similar to Figure 4 with one exception.

For OPU4 applications, the last eight columns (within the payload) is always a fixed-stuff region and cannot be used for data transport.

Other than that, Figure 5 has the same set of Overhead Bytes as does Figure 4.

The JC1, JC2, JC3, JC4, JC5, and JC6 bytes will all support the GMP mapping and de-mapping of client data into/from an OPU4 signal.

Please see the GMP Procedure for Mapping/De-Mapping Non-OTN Client signals post for more information on how we use these byte-fields to support the mapping/de-mapping of non-OTN client data.

The OPUk Overhead for OPU4 Applications – Lower-Speed ODUj Signal Case

If we are supporting the OPU4 rate and if we are also using GMP to map/de-map lower-speed ODUj signals into/from this OPU4 signal, then Figure 6 presents an illustration of the appropriate OPU4 frame format and overhead fields that we will be working with.

OMFI Location

Figure 6, An Illustration of the OPU4 Frame structure, whenever we are using GMP to map/de-map a lower-speed ODUj signal

Figure 6 is identical to Figure 5 with one exception.

For Non-OTN Client applications, the byte-field in Row 4/Column 16 is labeled “RES” (for RESERVED) and serves no purpose for mapping/de-mapping of client-data into/from the OPU4 signal.

For Lower-Speed ODUj Mapping applications, we call this byte-field the OMFI (OPU Multi-Frame Identifier) field.

The JC1, JC2, JC3, JC4, JC5, JC6, and OMFI bytes will all support the GMP mapping and de-mapping of lower-speed ODUj data into/from an OPU4 signal.

Please see the GMP Procedure for Mapping/De-Mapping Lower-Speed ODUj Client signals post for more information on how we use these byte-fields to support the mapping/de-mapping of Lower-Speed ODUj client data.

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