What is the PSI – Payload Structure Identifier Byte

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 (or Payload Structure Identifier) byte is an Overhead byte within the OPUk structure.

Figure 1 presents an OPU frame with the location of the PSI byte identified.

Figure 1, Illustration of an OPUk Frame Structure with the Overhead Bytes (along 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).

The primary purpose of this 256-byte PSI Message is to permit the Source PTE to alert the OTN (Network) of the type of data (or traffic) we are transporting within this particular OPU data stream.

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

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

Please see the OTUk Frame Structure post 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 sending 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 sending the second byte within this 256-byte message (e.g., PSI[1]) via the PSI byte field, and so on.

Two Types of PSI Messages

An OTN Source PTE will transport one of two types of PSI Messages.

The Non-Multiplexed Traffic – PSI Message, and
The Multiplexed Traffic – PSI Message.

I will describe each of these types of PSI Messages below.

The Non-Multiplexed Traffic PSI Message

We will use the Non-Multiplexed Traffic PSI Message when transporting Non-Multiplexed Traffic within our OPU data stream.

Examples of Non-Multiplexed Traffic would be:

Transporting 1000BASE-X via an OPU0 signal
10GBASE-R via an OPU2e signal.
100GBASE-R via an OPU4 Signal.

In other words, we are handling Non-Multiplexed Traffic whenever we only transport a single Non-OTN client signal via this OPUk data stream.

I present an illustration of an OPU Frame, with the PSI field highlighted (along with a break-out of the Non-Multiplexed Traffic type of PSI Message) below in Figure 2.

Figure 2, Illustration of an OPU Frame, transporting the Non-Multiplexed traffic of PSI Message

NOTE: The easiest way to tell if you’re working with the Non-Multiplexed Traffic type of PSI Message is to check and see if you see the CSF (Client Signal Fail) bit-field in PSI Byte # 2.

If the CSF bit-field is present, you’re dealing with the Non-Multiplexed Traffic type of PSI Message.

If the CSF bit-field is NOT present (within the PSI Message), then you are dealing with the other type of PSI Message.

The Multiplexed Traffic Type of PSI Message

We use the Multiplexed Traffic type of PSI Message anytime we work with an OPU server signal transporting numerous lower-speed ODUj Tributary Signals.

For example, if we mapped and multiplexed 80 ODU0 tributary signals into an OPU4 server signal, then this OPU4 signal would transport the Multiplexed Traffic type of PSI Message.

Figure 3 presents an illustration of an OPU Frame, with the PSI field highlighted, along with a break-out of the Multiplexed Type of PSI Message.

Figure 3, Illustration of an OPU Frame transporting the Multiplexed Traffic Type of PSI Message

Again, one big difference between the Multiplexed Traffic type of PSI Message and that for Non-Multiplexed Traffic is that the Multiplexed Traffic type of PSI Message will not have the CSF (Client Signal Fail) bit-field.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

The PSI Message

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

Let’s talk a little bit about the data that we are transporting within these PSI Messages.

PSI[0] – or PSI Byte # 0 – PT (Payload Type)

The first byte of the PSI Message (e.g., PSI[0]) carries the Payload Type (or PT) value. The PT byte identifies the type of client data the OPUk structure is transporting via its payload.

First, Table 1 presents a list of standard PT values and 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

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

NOTES:

We will discuss the PT = 0x07 case when mapping 100GBASE-R into an OPU4 in Lesson 4.
Access to Lesson 4 requires that you have a membership to “THE BEST DARN OTN TRAINING PERIOD” training.

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

NOTE:

We will discuss cases where PT = 0x20 and 0x21 in Lesson 5.
Access to Lesson 5 requires that you have a membership to “THE BEST DARN OTN TRAINING PERIOD” training.

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

Other posts contain detailed information on how ITU-T G.709 recommends that the System Designer map each client signal 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 that we will discuss in another post.

In Multiplexed-Traffic Type of PSI Messages

For the Multiplexed-Traffic type of PSI Message, we use these bytes to transport MSI (Multiplex Structure Identifier) information throughout the OTN.

In other words, we will transport the MSI information (via these PSI Messages) for applications in which we are mapping/multiplexing lower-speed ODUj tributary signals into higher-speed OPUk/ODUk server signals.

The MSI aims to identify these lower-speed ODUj tributary signals we are transporting via this OPUk/ODUk signal to the OTN.

You can think of the MSI as a passenger list or manifest of lower-speed ODUj tributary signals riding along (or being transported) within this OPUk server signal.

In Non-Multiplexed-Traffic Type of PSI Messages

PSI byte 2, Bit 1 (for the Non-Multiplexed Traffic PSI Message) is the CSF (or Client Signal Fail) indicator. The ITU-T Standards Committee has reserved PSI Byte 2, Bits 2 through 8 for “future standardization.”

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

We also extensively discuss these PSI Messages within THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!.

You can click on the Banner below to learn more our this training package.

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

Discounts Available for a Short Time ONLY!!

For More Information on OTN-Related Posts in this Blog, click on the image below.

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? ...

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 for mapping 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.

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

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 the bit rate of the OPUk payload.

In other words, the System Designer must ensure that ALL the following conditions are true before they can use the Bit-Synchronous Mapping Procedure to map a particular 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.

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 handle 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.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

ITU-T G.709 Recommendations on Using BMP

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

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

BMP and De-Mapping Jitter

BMP offers the best de-mapping jitter 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 a clock-smoothing or jitter attenuation scheme to comply with de-mapping jitter requirements.

This requirement 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 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

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

Discounts Available for a Short Time!!!

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

OTN Related Topics within this Blog

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

What is the OPU – Optical Payload Unit?

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

What is the OPU – Optical Payload Unit?

The 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 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.

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

We will typically give the OPU (just like its larger OTU cousin) 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 the data-carrying capacity for each type of OPU structure.

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

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

The OPUk frame consists of two types of bytes:

Payload Bytes (which we use to transport the Client Data) and
Overhead Bytes 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 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 15,240 bytes.

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

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

Why Do I Call Figure 2 a “Generic Illustration”?

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

The names and roles of these OPUk Overhead fields will change depending on which of the following sets of data rates and mapping procedures we are using.

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 running 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 tributary signals into/from this OPU4 server signal.

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

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

The OPUk Frame Format and Overhead for the OPU0 through OPU3 server rates when 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 non-OTN client data or lower-speed ODUj tributary signals into this OPUk server signal, then Figure 3 shows us the OPUk Frame format and overhead that we will be using.

Figure 3, An Illustration of the OPUk Frame Format (and Overhead) for the OPU0 through OPU3 server rates whenever we use 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 operations of client data into and out of the OPUk signal.

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

The PSI byte carries information about and identifies 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 for all PT = 0x20 applications and some PT = 0x21 applications in which we use AMP.

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

If we support the OPU0 through OPU3 rates and use GMP (the Generic Mapping Procedure) to map either non-OTN client data or lower speed ODUj tributary signals into this OPUk server signal then Figure 4 shows a drawing of the OPUk frame format that we will be using.

Figure 4, An Illustration of the OPUk Frame Format for the OPU0 through OPU3 rates whenever we use 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 signal training (in Lesson 4 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!) on how we use these byte-fields to support the mapping/de-mapping of non-OTN client data into/from OPU frames.

Likewise, please see Lesson 5 (within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!) for information on how we use the GMP Procedure for Mapping/De-Mapping Lower-Speed ODUj Tributary Signals into an ODUk Server signal. This same lesson will also include information on how we use these byte-fields to support the mapping/de-mapping lower-speed ODUj tributary signals into/from the ODUk server signal.

Once again, the PSI byte carries information about and identifies 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 for some PT = 0x21 applications.

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

If we support the OPU4 rate and use GMP to map/de-map a non-OTN client signal into/from this OPU4 signal, then Figure 5 presents an appropriate OPU4 frame format and overhead fields that we will be using. Hence, we would use this OPU frame when GMP mapping a 100GBASE-R signal into an OPU4 signal.

Figure 5, An Illustration of the OPU4 Frame structure whenever we use 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) are always a fixed-stuff region that we cannot use to transport data.

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 client data into/from an OPU4 signal.

Please see the GMP Procedure for Mapping/De-Mapping Non-OTN Client signals lesson (e.g., Lesson 4 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!) 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 Tributary Signal Case

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

Figure 6, An Illustration of the OPU4 Frame structure whenever we use GMP to map/de-map lower-speed ODUj tributary signals.

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 client data into/from the OPU4 signal.

For Lower-Speed ODUj Tributary Signal 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 tributary signals into/from an OPU4 signal.

Please see Lesson 5 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!! For more information on how we use these byte-fields to support the mapping/de-mapping of Lower-Speed ODUj Tributary signals into an ODUk Server signal.

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

Discounts Available Temporarily

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

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? ...

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is the PSI – Payload Structure Identifier (Byte and Message)?

The PSI Byte

Two Types of PSI Messages

The Non-Multiplexed Traffic PSI Message

The Multiplexed Traffic Type of PSI Message

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

The PSI Message

PSI[0] – or PSI Byte # 0 – PT (Payload Type)

The Remaining Bytes within the PSI Message

In Multiplexed-Traffic Type of PSI Messages

In Non-Multiplexed-Traffic Type of PSI Messages

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

Discounts Available for a Short Time ONLY!!

For More Information on OTN-Related Posts in this Blog, click on the image below.

OTN Related Topics within this Blog

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is the BMP (Bit-Synchronous Mapping Procedure)?

What is the Bit-Synchronous Mapping Procedure?

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

ITU-T G.709 Recommendations on Using BMP

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

BMP and De-Mapping Jitter

Summary

TABLE 2, MAPPING PROCEDURE TIMING REQUIREMENTS

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

Discounts Available for a Short Time!!!

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

OTN Related Topics within this Blog

<br /> (adsbygoogle = window.adsbygoogle || []).push({<br /> google_ad_client: "ca-pub-3980739213079532",<br /> enable_page_level_ads: true<br /> });<br /> What is the OPU – Optical Payload Unit?

The Basic OPUk Frame Format

Why Do I Call Figure 2 a “Generic Illustration”?

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

The OPUk Frame Format and Overhead for the OPU0 through OPU3 server rates when using BMP/AMP.

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

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

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

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

Discounts Available Temporarily

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

OTN Related Topics within this Blog

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

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

What is the OPU – Optical Payload Unit?