What is the OTU Frame/OTUk Frame?
An OTU (Optical Transport Unit) frame is a data structure that an OTN Terminal (or Source STE) will use to transport its data to the outside world.
This post will call any entity that generates and transmits OTUk frames a Source STE (Section Terminating Equipment). Likewise, we will call any entity that receives, processes, and terminates OTUk frames a Sink STE.
In other words, as the Source STE accepts OPU/ODU frames to create an OTUk frame, it will encapsulate these OPU/ODU frames into an OTU frame by “tacking” on the OTUk overhead.
Additionally, the Source STE will pre-condition each OTUk frame for transport over Optical Fiber by computing and appending an FEC (Forward Error Correction) field at the back end of the OTU frame and scrambling much of the OTUk frame data before converting this data into the optical domain and sending it out on Optical Fiber.
Likewise, the OTU frame is a data structure that an OTN Terminal (or Sink STE) will accept as it receives data from the outside world.
In this case, the OTN Terminal (e.g., Sink STE) will perform the reverse functions as the Source STE.
It will receive an optical signal from the remote STE and convert this data back into an electrical format. Afterward, it will descramble this incoming OTUk data stream, decode the FEC field, and correct most symbol errors in the process.
Finally, the Sink STE will terminate the OTUk data stream by extracting out the OPU/ODU frames and routing this data to downstream circuitry.
To be clear, What do We Mean by Frame?
OTN, just like many other Networking Standards, uses framing to organize the data it transmits and receives.
Framing is a Data Link Layer function. A transmitting terminal will organize a group of data bits into a specific data structure (called a “frame”) before transmitting it across a link.
Please see the post about the Data Link Layer for more information about the concept of Framing.
Please note that we are not talking about this kind of frame.
For OTN applications, we only transmit data that we have encapsulated into the form of an OTU frame out onto optical fiber.
OPUk and ODUk signals may be handled and processed internally (within a network element or an integrated circuit).
But we NEVER transmit OPUk and ODUk data onto the network (over optical fiber) unless we first encapsulate these signals into an OTUk frame and pre-condition this data for transport over Optical Fiber.
OTN Section and Path Terminating Equipment
In the OTN arena, we will often state that OTN Section Terminating Equipment (STE) is the entity that is responsible for transmitting and receiving OTUk frames.
We will also state that OTN Path Terminating Equipment (PTE) handles and processes ODUk frames.
Please see the posts for OTN Section Terminating Equipment (STE)and OTN Path Terminating Equipment (PTE) to understand the differences between these two types of equipment.
The OTUk Frame Format
Figure 1 illustrates the format for the standard ITU-T G.709-compliant OTU Frame.
Figure 1, Illustration of the Format of the ITU-T G.709-Compliant OTU Frame
This figure 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 an OTU1, OTU2, OTU3, or OTU4 frame) are all the same size; 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
Let’s talk about the various 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 we sometimes call the OA1 bytes) each have a fixed value of 0xF6.
The remaining three bytes (in the FAS field), which we sometimes call the OA2 bytes, each have a fixed value of 0x28.
The purpose of the FAS bytes is to provide the remote receiving OTN terminal (e.g., the Sink STE) with this fixed pattern so that it will “know” that it is receiving the first bytes of a new OTUk frame.
The Sink STE will parse through its incoming OTUk frame data stream. As it does this, it will search for the occurrence of three consecutive bytes (each with the value 0xF6) followed by another set of three successive bytes (each with the value 0x28).
The Sink STE will rely on these FAS bytes to acquire and maintain framing alignment/synchronization with the incoming stream of OTUk frames.
If the Sink STE repeatedly fails to acquire and maintain framing alignment/synchronization with this incoming stream of OTUk frames, it will declare the dLOF (Loss of Frame) defect condition.
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 MFAS byte’s value is not fixed, as I will explain here.
A given Source STE will transmit OTUk frames in groups of Multi-frames.
Each of these multi-frames consists of 256 consecutive OTUk frames.
Whenever a Source STE transmits the first OTUk frame (of a given Multi-frame), it will designate this particular frame as the first frame (of this multi-frame) by setting its MFAS byte field to 0x00.
When the Source STE transmits the next OTUk frame, it will set the MFAS byte (within that particular OTUk frame) to 0x01, and so on.
As the Source STE transmits each OTUk frame, it will increment the value assigned to the MFAS byte field until it reaches the value 0xFF (or 255 in decimal format).
The Source STE will then start over with transmitting a new multi-frame and set the MFAS of this next OTUk frame to 0x00, and the process repeats indefinitely.
The MFAS is a significant byte for a receiving OTN terminal (e.g., Sink STE) to keep track of because other data (such as the TTI – Trail Trace Identifier message – that is transmitted via some of the additional overhead bytes across multiple OTUk frames).
The Source STE will align the transmission of these particular messages (e.g., the SM-TTI messages, PM-TTI messages, PSI Messages, etc.) with the MFAS byte as it transports these messages via the OTUk data stream.
Please see the relevant posts on SM-TTI (Section Monitoring – Trail Trace Identifier) Messages, PM-TTI (Path Monitoring – Trail Trace Identifier) Messages, and PSI (Payload Structure Identifier) Messages to learn more about these types of messages.
ODUk Frame
The ODUk Frame “portion” of the OTUk frame is all the remaining data (which resides within the OTUk frame) that is not considered an OTUk Overhead field. This includes all bytes within the ODU (Optical Data Unit) and, in turn, OPU (Optical Payload Unit) within the OTUk frame. Please see the posts for ODUk and OPUk to learn more about those parts of the OTUk frame.
FEC – Forward Error Correction
ITU-T G.709 specifies that OTUk frames should include an FEC (Forward Error Correction) field that contains the Reed-Solomon RS (255,239) FEC codes.
NOTE: I discuss the RS(255,239) FEC code in detail in Lesson 9, within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!
The FEC field permits a Sink STE to detect and correct many symbol (or byte) errors that may have occurred during transmission.
ITU-T G.709 indicates that using FEC is optional for OTU1, OTU2, and OTU3 applications.
However, the use of FEC is mandatory for OTU4 applications.
Please see the OTUk FEC discussion within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!! for more information about this field.
New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!!
The Rest of OTUk OH (Overhead) fields
The remaining OTUk OH fields consist of the following three fields for a total of seven (7) bytes:
- SM Field
- GCC0 Field
- OSMC (OTN Synchronizing Messaging Channel) Field
- RES (Reserved) Field
We will briefly describe each of these fields below.
SM (Section Monitoring) Field (3 bytes)
Figure 2 shows the byte format for the Section Monitoring or SM Field.
Figure 2, Byte-Format of the SM (Section Monitoring) Field
This figure shows that the SM Field consists of the following three bytes:
- TTI – Trail Trace Identifier Byte
- BIP-8 Byte
- SM Byte
Below, we will describe each of the bytes (within the SM field). We also discuss these fields in much greater detail in their respective posts.
TTI – Trail Trace Identifier Byte
This byte-field carries the 64-byte Section Monitoring Trail-Trace Identifier message. Since there is only one TTI byte within each OTUk frame, the OTN Transmitter (or Source STE) will transmit 64 OTUk frames to send the entire 64-byte Trail Trace Identifier message.
Please see the Section Monitor-Trail Trace Identifier post to learn how we use this identifier in an OTN system.
BIP-8 (Section Monitoring BIP-8) Byte
The Source STE will perform a BIP-8 calculation over the entire OPUk frame within its corresponding OTUk frame.
Afterward, the Source STE will insert the results of this BIP-8 calculation into the SM-BIP-8 byte field of the outbound OTUk frame two frame periods later.
Finally, the remote Sink STE will use this BIP-8 calculation to check for bit errors during transmission.
Please see the Section Monitoring BIP-8 post for more information about how we compute and use this byte field in an OTN system.
SM (Section Monitoring) Byte
Figure 3 presents the bit format for the Section Monitoring Byte (not to be confused with the 3-byte SM field).
Figure 3, Bit Format of the Section Monitoring Byte
This figure shows that the SM Byte consists of the following bit fields:
We will briefly describe each of these bit-fields below.
BEI/BIAE – Section Monitoring – Backward Error Indicator (BEI) or Backward Incoming Alignment Error (BIAE) – (4 bits)
The purpose of the BEI/BIAE nibble-field is two-fold.
- To permit the Source STE to provide the remote Sink STE (at the far-end) with feedback on the number of SM-BIP-8 errors that the near-end (local) Sink STE is detecting within its incoming OTUk data stream.
- The Source STE will set the BEI/BIAE nibble-field (within each outbound OTUk frame) to the SM-BEI (Backward Error Indicator) value.
- And to permit the Source STE to alert the remote Sink STE (again, at the far-end) that the near-end (local) Sink STE is declaring the dIAE defect condition.
- The Source STE will accomplish this by setting the BEI/BIAE nibble-field to the value of “1011”, which carries the BIAE (Backward Input Alignment Error) Indicator.
Table 1 presents the range of values that the Source STE can set the BEI/BIAE Nibble-field, within its outbound OTUk frames, for each of the conditions mentioned above.
Table 1, How to Interpret the Section Monitoring BEI/BIAE bit-fields
| OTUk SM_BEI/BIAE Nibble-Value | Sink STE declaring the dIAE Defect? | Number of SM-BIP-8 Errors Detected | Comments |
|---|---|---|---|
| 0000 | NO | 0 | Good Condition |
| 0001 | NO | 1 | BIP-8 Error |
| 0010 | NO | 2 | BIP-8 Errors |
| 0011 | NO | 3 | BIP-8 Errors |
| 0100 | NO | 4 | BIP-8 Errors |
| 0101 | NO | 5 | BIP-8 Errors |
| 0110 | NO | 6 | BIP-8 Errors |
| 0111 | NO | 7 | BIP-8 Errors |
| 1000 | NO | 8 | BIP-8 Errors |
| 1001, 1010 | NO | 0 | Good Condition |
| 1011 | YES | 0 | BIAE Indicator |
| 1100 to 1111 | NO | 0 | Good Condition |
Please see the Section Monitoring Error/Defect post to learn more about these defect and error conditions.
BDI – Section Monitoring – Backward Defect Indicator Bit Field
The purpose of the BDI bit-field is to permit the Source STE to alert the remote (far-end) Network Element that the local (near-end) Sink STE is declaring a service-affecting defect.
This Source STE will set this bit-field to “0” or “1” depending upon whether the local (near-end) Sink STE is declaring a service-affecting defect condition (at the OTUk-layer), as I describe below.
0 – The Source STE will set the BDI bit-field to “0” if the near-end Sink STE is NOT declaring a service-affecting defect condition.
1 – The Source STE will set the BDI bit-field to “1” if the near-end Sink STE is currently declaring a service-affecting defect condition.
Please see the OTUk-BDI post to learn more about the BDI defect condition.
IAE – Section Monitoring Incoming Alignment Error Bit-Field
The Source STE will set this bit-field to “0” or “1” depending upon whether the upstream circuitry detects a frame-slip event within an ODU signal that we are ultimately mapping into this particular OTUk data stream (that this Source STE is transmitting downstream).
0 – Indicates that upstream circuitry is NOT detecting any frame-slip events (within the ODU signal we are mapping into this particular OTUk signal). The Source STE will set the IAE bit-field to “0” (within its outbound OTU data-stream) to denote this good condition.
1 – Indicates that upstream circuitry is currently detecting a frame-slip event (within the ODU signal we are mapping into this particular OTUk signal). The Source STE will set the IAE bit-field to “1” (within its outbound OTU data-stream) to denote this abnormal condition.
I present detailed information on the IAE bit-field within Lesson 9 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!.
GCC0 – General Communication Channel # 0 – (2 bytes)
The GCC0 is a general communications channel for proprietary communication to the System Designer/Manufacturer.
This channel is similar to the DCC (Data Communication Channels) in SONET/SDH.
Please see the GCC0 post for more information about how the System Designer/Manufacturer can use this field.
OSMC – OTN Synchronization Messaging Channel – 1 byte
The Network User can use the OSMC channel to transport SSM (Synchronization Status Messages) or PTP (Precision Time Protocol) messages throughout the OTN.
Please see the OSMC post for more information about how the System Designer/Manufacturer can use this field.
RES – Reserved (or Undefined) (1 byte)
OTUk Frame Repetition Rates and Bit Rates
Since all speeds (or types) of OTUk signals use the same frame size, the reason that (for example) an OTU2 runs at a faster bit rate than does an OTU1 is that the frame repetition rate for an OTU2 is higher (e.g., more rapid) than that for an OTU1.
Table 2 presents the OTUk frame period and bit rate for each type of the OTUk signal.
Table 2, Frame Periods and Bit-Rate for each kind of OTUk signal
NOTES:
- This post has defined the Fully Compliant OTUk frames. It does not address the functionally standardized OTUk frames (such as the OTUkV or OTUk-v). Please see the posts for the OTUkV and OTUk-v frames for more information on these types of frames.
- This post does not discuss the new OTUCn types of OTN signals. Please see the OTUCn post for more information on these higher-speed signals.
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!!
(DISCOUNT OFFERED for a Short Time ONLY!!)
For More Information on OTN Posts in this Blog, click on the Image below.
OTN Related Topics within this Blog
