OTUk Overhead Bytes

The Byte Format of the OTUk Frame

Figure 1 presents an illustration of the byte format for the standard ITU-T G.709-compliant OTU Frame.

OTUk Frame - Byte Format

Figure 1, Illustration of the Byte Format of the ITU-T G.709-Compliant OTU Frame

Figure 1 shows that an OTU Frame is a 4-Byte-Row by 4080-Byte-Column Structure.  Hence, each OTU Frame consists of (4 x 4080 =)16,320 bytes.

Please note that all OTU Frames (whether it is an OTU1, OTU2, OTU3 or OTU4 frame) are all the same size and therefore, each frame has exactly 16,320 bytes.

NOTE:  Since each of these OTU frames are the same size (regardless of whether we are talking about an OTU1, OTU2, OTU3 or OTU4), we will from here on, refer to these OTU frames as OTUk frames.

The Fields within an OTUk Frame

Some of the fields in the OTUk frame have the following labels.

  • FAS
  • MFAS
  • OTUk OH
  • FEC
  • ODUk Frame

I will briefly define each of these bytes below.

FAS – Framing Alignment Signal field

The Framing Alignment Signal field occupies the first 6 bytes within an OTUk Frame.

The first three bytes (which are sometimes called OA1) each have the fixed value of 0xF6.

The remaining three bytes (in the FAS) are sometimes called OA2, and each has the fixed value of 0x28.

The purpose of the FAS bytes is to provide the remote receiving OTN terminal with this fixed pattern so that it will “know” that it is receiving the first bytes of a new OTUk frame.

The Receiving OTN terminal will parse through its stream of incoming OTN data and will search for the occurrence of three consecutive bytes (each with the value 0xF6) followed by another set of three consecutive bytes (each with the value 0x28).

Whenever the Receiving OTN terminal receives data with this particular pattern, then it “knows” that it is currently parsing through the beginning of a given OTUk frame.

The Receiving OTN terminal will rely on these FAS bytes to acquire and maintain framing alignment/synchronization with the incoming stream of OTUk frames.

MFAS – Multi-Frame Alignment Signal byte

The MFAS byte occupies the 7th byte within an OTUk frame and “resides” immediately after the FAS bytes.

Unlike the FAS bytes, the value of the MFAS byte is not fixed.  A given OTN Terminal will transmit OTUk frames in groups of “Multi-frames.”

Each of these groups of multi-frames consists of 256 consecutive OTUk frames.

Whenever an OTN terminal transmits the first OTUk frame (of a given Multi-frame), it will designate this particular frame, as being the first frame by setting its MFAS byte field to 0x00.

When the OTN terminal transmits the next OTUk frame, it will then set the MFAS byte (within that particular OTUk frame) to 0x01 and so on.

As the OTN terminal transmits each OTUk frame, it will increment the value of which it will assign to the MFAS byte field, until it reaches the value 0xFF (or 255 in decimal format).

The OTN terminal will then start over with transmitting a new multi-frame and will set the MFAS of this next OTUk frame to 0x00, and the process repeats indefinitely.

The MFAS is a useful byte for a receiving OTN terminal to keep track of because there is other data (such as the TTI – Trail Trace Identifier message – that is transmitted via some of the other overhead bytes across multiple OTUk frames).

This data (or multi-byte messages)  will be aligned with the MFAS byte as it is being transmitted out onto the network.

MSI (Multiplex Structure Identifier)

  • The PSI Message is a 256-byte Message, that a given Source PTE (Path Terminating Equipment)  will repeatedly transmit to the Sink PTE.
  • The Source PTE will repeatedly transmit this PSI Message via the PSI byte (within each ODUk/OPUk frame).
  • The purpose of this PSI Message is to permit the Source PTE to inform the Sink PTE of the type of traffic that this particular ODUk signal is transporting.
  • The first byte (Byte 0 – within the PSI Message) will be the PT (or Payload Type) byte.
  • This means that there are still 255 other bytes, that are available to transport information, within each PSI Message.

I show an illustration of the PSI byte-field and the PSI Message below in Figure 1.

Payload Structure Identifier Message and PSI Byte within an OPUk Frame

Figure 1, Illustration of the PSI byte-field and PSI Message

A Multiplex Structure ODUk

If the Source PTE (that is transmitting an ODUk signal to the remote Sink PTE) has set the PT byte value (within each PSI Message) to either 0x20 or 0x21, then this means that this ODUk signal is a Multiplex Structure ODUk signal.

If a given ODUk signal is a Multiplex Structure ODUk signal then this means that it is transporting at least lower-speed ODUj signal within its payload (where k > j).

n this case, the Source PTE (or upstream circuitry) has mapped and multiplexed lower-speed ODUj signals into this particular higher-speed ODUk signals.

For the OTN to work properly, the Source PTE needs to send sufficient information to Sink PTE, about the type of traffic/data that a given ODUk signal is carrying.

The Sink PTE needs more information than the PT byte value

So if the Source PTE sets the PT Byte value (within each outbound PSI Message) to 0x20 or 0x21, then it is “telling the Sink PTE” that this ODUk signal is a Multiplex Structure signal.

However, the Sink PTE needs more information for it to be able to properly handle this ODUk data-stream.

In particular, the Sink PTE needs to “know” how many, and what type of lower-speed signals that this ODUk is signal transporting.

Let’s take a Look at an ODU4/OPU4 Signal

For example, if we are dealing with an ODU4 signal, and if the PT byte is set to 0x21, then the PSI Message (that this ODU4/OPU4 signal transports) could have the format that we show below in Figure.

Multiplex Structure Identifier for 80 ODU0 Signals within an OPU4 Signal

Figure 2, Illustration of the PSI Message for an ODU4/OPU4 that is transporting 80 ODU0 signals

Figure 2 shows the PSI Message, that a Source PTE would transport (within an ODU4 signal) if that ODU4 signal was transporting 80 ODU0 signals (that have been mapped and multiplexed into this ODU4).

Please note that ODU4/OPU4 signals can transport other types of multiplexed traffic.  For example, it can transport any of the following types of multiplexed traffic.

  • 80 ODU0 signals.
  • 40 ODU1 signals
  • 10 ODU2 or ODU2e signals
  • 2 ODU3 signal
  • Some number of ODUflex signals (provided that the total bandwidth of all of these signals does not exceed 80 time-slots or the OPU4 payload carrying capacity of 104.35597533 Gbps).
  • Various combinations of each of the above signals (again, provided that the total bandwidth of all of these signals does not exceed 80 time-slots).

How to Read/Decipher these Multiplex Structure Identifier fields

Figure 2 shows that each PSI Message (starting at Byte 2) has 80 consecutive bytes of data, in which bit 1 (the left-most bit) is set to the value of “1”.  When bit 1 (within these fields) is set to “1”, then it means that some lower-speed ODUj signal is using this particular time-slot (or bandwidth).

These 80 bytes (of data) are the Multiplex Structure Identifier for this ODU4 signal.  When the Sink PTE reads in these PSI Messages, it will “know” that this particular ODU4/OPU4 signal is transporting 80 lower-speeds ODUj (ODU0) signals.  In this case, the Sink PTE has sufficient information about this ODU4/OPU4 signal, to be able to handle it properly.

NOTE: we mention that each time-slot (for PT = 0x21 applications) represents approximately 1.25Gbps of bandwidth.

I have also included below Figure, which will help you better understand these Multiplex Structure Identifier fields.

Mutliplex Structure Identifier Definition for OPU4 Applications

Figure 3, Multiplex Structure Identifier – Bit Definitions for ODU4/OPU4 Applications.  

PSI (Payload Structure Identifier)

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

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

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

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 Design map each of these client signals into their corresponding OPUk structure.

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

 

OTN frame struture

The Optical Transport Hierarchy OTH is a new transport technology for the Optical Transport Network OTN developed by the ITU. It is based on the network architecture defined in ITU G.872 “Architecture for the Optical Transport Network (OTN)” G.872 defines an architecture that is composed of the Optical Channel (OCh), Optical Multiplex Section (OMS) and Optical Transmission Section (OTS). It then describes the functionality that needed to make OTN work. However, it may be interesting to note the decision made during G.872 development as noted in Section 9.1/G.872 : “During the development of ITU-T Rec. G.709, (implementation of the Optical Channel Layer according to ITU-T Rec. G.872 requirements), it was realized that the only techniques presently available that could meet the requirements for associated OCh trace, as well as providing an accurate assessment of the quality of a digital client signal, were digital techniques….” “For this reason ITU-T Rec. G.709 chose to implement the Optical Channel by means of a digital framed signal with digital overhead that supports the management requirements for the OCh. Furthermore this allows the use of Forward Error Correction for enhanced system performance. This results in the introduction of two digital layer networks, the ODU and OTU. The intention is that all client signals would be mapped into the Optical Channel via the ODU and OTU layer networks.” Currently there are no physical implementations of the OCh, OMS and OTS layers.

Why use OTN

OTN offers the following advantages relative to SONET/SDH:

  • Stronger Forward Error Correction
  • More Levels of Tandem Connection Monitoring (TCM)
  • Transparent Transport of Client Signals
  • Switching Scalability

OTN has the following disadvantages:

  • Requires new hardware and management system

We will discuss the advantages and disadvantages in the following sections.

Forward Error Correction (FEC)

Forward error correction is a major feature of the OTN.

Already SDH has a FEC defined. It uses undefined SOH bytes to transport the FEC check information and is therefore called a in-band FEC. It allows only a limited number of FEC check information, which limits the performance of the FEC.

For the OTN a Reed-Solomon 16 byte-interleaved FEC scheme is defined, which uses 4×256 bytes of check information per ODU frame. In addition enhanced (proprietary) FEC schemes are explicitly allowed and widely used.

FEC has been proven to be effective in OSNR limited systems as well as in dispersion limited systems. As for non-linear effects, reducing the output power leads to OSNR limitations, against which FEC is useful. FEC is less effective against PMD, however.

G.709 defines a stronger Forward Error Correction for OTN that can result in up to 6.2 dB improvement in Signal to Noise Ratio (SNR). Another way of looking at this, is that to transmit a signal at a certain Bit Error Rate (BER) with 6.2 dB less power than without such an FEC.

The coding gain provided by the FEC can be used to:

– Increase the maximum span length and/or the number of spans, resulting in an extended reach. (Note that this assumes that other impairments like chromatic and polarization mode dispersion are not becoming limiting factors.)

– Increase the number of DWDM channels in a DWDM system which is limited by the output power of the amplifiers by decreasing the power per channel and increasing the number of channels. (Note that changes in non-linear effects due to the reduced per channel power have to be taken into account.)

– Relax the component parameters (e.g launched power, eye mask, extinction ratio, noise figures, filter isolation) for a given link and lower the component costs.

– but the most importantly the FEC is an enabler for transparent optical networks: Transparent optical network elements like OADMs and PXCs introduce significant optical impairments (e.g. attenuation). The number of transparent optical network elements that can be crossed by an optical path before 3R regeneration is needed is therefore strongly limited. With FEC a optical path can cross more transparent optical network elements.

This allows to evolve from today’s point-to-point links to transparent, meshed optical networks with sufficient functionality.

Note: There is additional information on FEC in Section 11 of sup.dsn Also Appendix 1 of G.975.1 lists some additional Enhanced FEC schemes.

OPUk Overhead and Processing

The OPUk (k = 1,2,3) frame structure is shown in Figure 15. It is organized in an octet-based block frame structure with four rows and 3810 columns.

The two main areas of the OPUk frame are:

• OPUk overhead area;

• OPUk payload area;

Columns 15 to 16 of the OPUk are dedicated to OPUk overhead area.

Columns 17 to 3824 of the OPUk are dedicated to OPUk payload area.

NOTE – OPUk column numbers are derived from the OPUk columns in the ODUk frame

OPUk OH information is added to the OPUk information payload to create an OPUk. It includes information to support the adaptation of client signals. The OPUk OH is terminated where the OPUk is assembled and disassembled.

OPUk Overhead Byte Descriptions

The OPUk Overhead bytes are shown in Figure 16

 

Payload Structure Identifier (PSI)

The 256-byte PSI signal is aligned with the ODUk multiframe (i.e. PSI[0] is present at ODUk multiframe position 0000 0000, PSI[1] at position 0000 0001, PSI[2] at position 0000 0010, etc.). PSI[0] contains a one-byte Payload type. PSI[1] to PSI[255] are mapping and concatenation specific. Click here for more infromation http://www.phpini.in/otn/psi-payload-structure-identifier.html

Payload Type (PT)

A one-byte payload type signal is defined in the PSI[0] byte of the payload structure identifier to indicate the composition of the OPUk signal. The code points are defined in Table 5.

Mapping Signals into an OPUk

There are a number of Payload Types defined in Table 5..

 

 

I2C using GPIO C code

Understanding the I2C Bus: I2C using GPIO

The I2C bus is a very popular and powerful bus used for communication between a master (or multiple masters) and a single or multiple slave devices. Figure 1 illustrates how many different peripherals may share a bus which is connected to a processor through only 2 wires, which is one of the largest benefits that the I 2C bus can give when compared to other interfaces.

Continue reading

Storage Classes in c language

Storage classes define the scope (visibility) and life time of variables which help us to trace the existence of a particular variable during the run time of a program.

C Language supports 4 types of storage class they are:

Storage Classes

  1. Auto
  2. Register
  3. Static
  4. Extern

Syntax:   <storage class> <data type> <variable name>;

ex:

auto int month; register int month; extern int month; static int month;

Auto:  A variable declared inside a function without any storage class specification, is by default an automatic variable. They are created when a function is called and are destroyed automatically when the function exits. Automatic variables can also be called local variables because they are local to a function. By default they are assigned garbage value by the compiler.

Example

{
   int mount;
   auto int month;
}

Register: The register variable functionality is same as auto storage class except that storage of variable is in register instead of memory. Register variable has faster access than normal variable. Frequently used variables are kept in register. Only few variables can be placed inside register depends on the register of processors. The Register variable does not guarantee the storage of variable in register it depends on the availability of register.

NOTE : We can never get the address of such variables.

Example

{
   register int i;
      for(i=0;i<100;i++) {
   printf("register storage class"); }
}

In the above example the variable i is accessed in loop. using register declaration the loop will be executed fast compared to normal storage class i.e auto.

Static : This storage class is used to declare static variables which are popularly used while writing programs in C language. Static variables have a property of preserving their value even after they are out of their scope! Hence, static variables preserve the value of their last use in their scope. So we can say that they are initialized only once and exist till the termination of the program. Thus, no new memory is allocated because they are not re-declared. Their scope is local to the function to which they were defined. Global static variables can be accessed anywhere in the program. By default, they are assigned the value 0 by the compiler.

Example

#include <stdio.h>
void fun()
{
 static number;
 printf("%d\t", number); 
 number++;
}
void main()
{
 fun();
 fun();
 fun(); 
}

output: 0 1 2

In the above example the static variable number is declared inside the fun function but still the value persist after multiple call the  fun function from main.

Extern: The extern keyword is used before a variable to inform the compiler that this variable is declared somewhere else. The extern declaration does not allocate storage for variables.

When you have multiple files and you define a global variable or function, which will also be used in other files, then extern will be used in another file to provide the reference of defined variable or function. Just for understanding, extern is used to declare a global variable or function in another file.

The extern modifier is most commonly used when there are two or more files sharing the same global variables or functions as explained below.

Example

file1: main.c

#include <stdio.h>
 
int count ;
extern void write();
 
main() {

   count = 5;
   write();
}

file2: support.c

#include <stdio.h>
 
extern int count;

void write(void) {
   printf("count is %d\n", count);
}

To compile:

$gcc main.c support.c

It will produce the executable program a.out. When this program is executed, it produces the following result ?

count is 5