What is the AMP (Asynchronous Mapping Procedure)?
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.
- BMP – Bit-Synchronous Mapping Procedure
- GMP – Generic Mapping Procedure
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, 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.
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.
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.
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.
- 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.
- 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.
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
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
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.
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