What is Running Disparity (RD)?

The Running Disparity (or RD) is defined as the difference between the number of logic 1 bits and logic 0 bits between the start of a data sequence and a particular instant in time during its transmission.


What is Running Disparity (RD)?

The Running Disparity (or RD) is defined as the difference between the number of logic 1 bits and logic 0 bits between the start of a data sequence and a particular instant in time during its transmission.

In other words, the RD for a character is the difference between the number of logic 1 bits and logic 0 bits in that character.

Hence, if there are more logic 1 bits than logic 0 bits (within a character or string of consecutive bits) then we can state that the RD is positive.

If there are more logic 0 bits than logic 1 bits then we can state that the RD is negative.

Finally, if the number of logic 1 and logic 0 bits are the same, then we can state that the RD is neutral or zero.

We can express the Running Disparity as either an integer or as a ratio:

EXPRESSING RD AS AN INTEGER NUMBER:

If you wish to express the RD of a character or string (of consecutive bits) as an integer number, then you can calculate the RD with the following equation:

RD = (Number of Logic 1 bits in the character or string) – (Number of Logic 0 bits in the character or string)

For example:  

The running disparity of the hexadecimal expression of 0x78 is 0.

To understand why this is the case, if we were to express this value in its binary format, we get 0111 1000.  The binary expression (for this value) contains four 0s and four 1s.

Thus, RD = 4 – 4 = 0

On the other hand, the running disparity of the hexadecimal expression of 0x7F is +6.

Again, if we were to express this value its binary format, we get 0111 1111.  The binary expression (for this value) contains seven 1s and one 0.

Hence, RD = 7 – 1 = +6

EXPRESSING RD AS A RATIO:

If you wish to express the RD of a character or string (of consecutive bits) as a ratio, then you would do the following:

  • Count the total number of logical “1s” in the expression.
  • Count the total number of logical “0s” in the expression.

And then express this information in the following format:

Number of Logical 1s (in character/string) :  Number of Logical 0s (in character/string)

For example:

We express the running disparity of the hexadecimal expression of 0x78 as:

4:4, which we can reduce (or simplify) to 1:1.

Likewise, we can compute and express the RD for the value 0x7F as
7:1.

Some communication and data storage system standards (such as Gigabit Ethernet/1000BASE-X, Fibre-Channel, etc.) require that the RD be maintained to as near neutral as possible.

This means that the system designer must ensure that the ratio of logical 1 bits to logical 0 bits (over time) should be kept close to 1:1.

Thus, the System Designer must follow any character/string with negative disparity with another character/string with an equal amount of positive disparity, and vice-versa.

The purpose of keeping RD to a minimum is to maintain dc balance on the transmission medium.

The System Designer must ensure that the RD does not increase without bounds.

The 8B/10B line code is a specific example of a line code that requires and exercises control over RD.

NOTE:  Controlling and monitoring RD can also be useful in detecting transmission errors.

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