OTN – Lesson 10 – Video 1M

This post presents the 1st of the 6 Videos that covers training on the Peformance Monitoring of the ODUk Layer (for Multiplexed Applications). This post focuses on the Source Direction ODU-Layer Atomic Functions.

OTN – Lesson 10 – Video 1 – The Entire Source Direction Path – All Atomic Functions (ODU Multiplexed Applications)

Check Out the Video Below

Click HERE to Go to Video 2 – The OTUk/ODUk_A_Sk and ODUk_TT_Sk Atomic Functions

Click HERE to return to the Main Lesson 10 Page – Multiplexed Applications

What We Cover in this Video

Video 1 (of the Multiplexed ODu4 System Videos) covers the following topics.

  • A brief review of Multiplexed Applications:
    • The PT = 0x20 Approach, and
    • The PT = 0x21 Approach
  • A brief review of the ITU-T G.798 Atomic Function’s support of the Multiplexed Applications
    • The ODUkP/ODU[i]j_A_So/Sk Functions (for PT = 0x20 Applications), and
    • The ODUkP/ODUj-21_A_So/Sk Functions (for PT = 0x21 Applications)
  • Our Application Example: 80 Channels of 1000BASEX -> ODU0 -> ODU4
  • ODU0P/CBR_ETC1000X-A_So (1Gbps Ethernet Adaptation Source Function)
  • Main Purpose: To take a 1000BASE-X (1Gbps Ethernet signal) and to map this signal into an ODU0 signal using the GMP-TTT Mapping Procedure.
    • Generates a Default PMOH within the outbound ODU0 signal.
    • Sends the ODU0 signal towards the downstream ODU0_TT_So function for further processing
    • On-Board Clock Generator
      • Synthesizes a 1.244160GHz Clock signal (e.g., the ODU0 bit-rates per ITU-T G.709) along with the AI_CK, AI_FS, and AI_MFS output signals.
    • ODU0 Overhead Settings
      • PT (Payload Type) within the PSI Message – set to 0x07 for 1000BASE-X mapped into an ODU0.
      • CI_SSF -> CSF bit-field within the outbound PSI Message (of OPU0 Frame)
  • ODU0_TT_So Function
  • Main Purpose: To compute a Real (and Correct) PMOH and insert data into its ODU0 data-stream.
    • The role of this function is very similar to what we described back in the discussion of the ODUk_TT_So function (in the Non-Multiplexed Portion of Lesson 10).
  • ODUkP/ODUj-21_A_So Function (ODUk to ODUj Multiplex Source Function)
  • Main Purpose: In this example, the ODUkP/ODUj-21_A_So function will map and multiplex 80 ODU0 signals into an OPU4/ODU4 server signal.
    • Convert each ODUj tributary signal into an Extended ODUj signal by attaching the FAS and MFAS fields to each ODUj frame.
    • APS Support
      • Within the ODUj Tributary Signal itself, and
      • Within the ODUk Server Signal
    • Can configure each ODUj tributaries to operate in the Locked Mode (e.g., it overwrites the ODUj tributary signal with the ODUj-LCK Maintenance signal and maps/multiplexes that signal into the ODUk server signal.
    • Setting the PT byte (within the outbound ODUk server signal to 0x21).
    • Quick Review of the MSI bytes (within each outbound PSI Message).
    • The OMFI Byte-field (for ODU4 Multiplexed Applications ONLY).
    • We set the PMOH within the ODUk Server Signal to the Default Values. Route this signal to the downstream ODUk_TT_So Function.
  • ODUk_TT_So Function
  • Main Purpose: To compute a Real (and Correct) PMOH and insert data into its ODU4 data-stream.
    • The role of this function is the same as what we described back in the discussion of the ODUk_TT_So function (in the Non-Multiplexed Portion of Lesson 10).
  • OTUk/ODUk_A_So Function
  • Main Purpose: To map an ODU4 client signal into the OTU4 Server signal.
    • The role of this function is the same as what we described back in the discussion of the ODUk_TT_So function (in the Non-Multiplexed Portion of Lesson 10).

In Figure 1, I highlight the Atomic Functions that we discuss in Video 1.

ODU4/OTU4 Multiplexed System with the Source Direction Atomic Functions Highlighted

Figure 1, Illustration of the ODU4/OTU4 System, with the Atomic Functions, that we discuss in Video 2, highlighted

You Can Also Check Out the Video Below:

Click HERE to Go to Video 2 – The OTUk/ODUk_A_Sk and ODUk_TT_Sk Atomic Functions

Click HERE to return to the Main Lesson 10 Page – Multiplexed Applications

OTN – Lesson 10 – Video 1N

This post presents the 1st of the 7 Videos that covers training on the Peformance Monitoring of the ODUk Layer (for Non-Multiplexed Applications). This post focuses on the Source Direction ODU-Layer Atomic Functions.

OTN – Lesson 10 – Video 1 – The ODUkP/CBR-ETC100GR-g_A_So (or 100Gbps Ethernet Adaptation Source) Atomic Function

Check Out the Video Below

Click HERE to Go to Video 2 – The ODUk_TT_So and OTUk/ODUk_A_So Atomic Functions

Click HERE to return to the Main Lesson 10 Page – Non-Multiplexed Applications

What We Cover in this Video

Video 1 (of the Non-Multiplexed ODU4 System Videos) covers the following topics.

  • A High-Level Review of the Non-Multiplexed ODU4 System
  • The Conversion of the ODU-Layer circuitry into their ITU-T G.798 Equivalent Atomic Functions.
  • Let’s Take a Walk through the Source Atomic Functions
    • ODUkP/CBR_ETC100GR-g_A_So Atomic Function (100Gbps Ethernet Adaptation Source Function)
      • Explanation of the meaning of the term: ODUkP/CBR_ETC100GR-g_A_So
      • What does this function do?
      • Let’s Take a Look at the ETC100GR_CP InterfaceAccepts Clock and Data from the 100GBASE-R client circuitry
      • Permits the Client Circuitry to assert the CSF bit-field within the outbound PSI Messages
    • On-Board Clock Generator
      • Synthesizes a 104,794,445.815kbps clock signal (e.g., the ODU4 bit-rate per ITU-T G.709), along with the AI_CK, AI_FS and AI_MFS output signals.
    • Lane Processing and Transcoding (Client Specific) BlockReview of PCS Lane Handling Circuitry
      • Review of PCS Encoding and the 100GBASE-R Signal
        • 64B/66B Encoding
        • Sync Header Bits
        • Alignment Marker Block
        • PCS Lanes
        • Meaning of the M0, M1, M2, M4, M5 and M6 fields within the Alignment Marker Block
      • How to Compute the BIP3 (BIP-8) byte within the Alignment Marker Block
      • Review of “PCS Lane Reordering and De-Skewing” block
      • CAUI-10 Interface
      • CAUI-4 Interface
      • 66b Block Synchronizer
      • Alignment Marker Block Synchronizer and AMB Lock
      • PCS Lane Reordering
      • Skew Measurement and Compensation
      • PCSL BIP-8 Verification
      • Fault Conditions
        • What Happens if We Cannot Achieve or Lose 66b Block Synchronization with the 100GBASE-R Data that we receive via the CAUI-4/10 Interface?
        • What Happens if We Cannot Achieve or Lose Alignment Marker block Synchronization with the 100GBASE-R Data that we receive via the CAUI-4/10 Interface?
        • What about Invalid 66b Blocks
      • On to GMP Mapping (as we Described in Lesson 4)
      • ODUkP Overhead Field Settings (as set by this Atomic Function)
      • CI_SSF -> CSF bit-field within outbound PSI Message (of OPU Frame)
      • Review of Performance Monitoring Features of the ODUkP/CBR_ETC100GR-g_A_So Function.
      • Summary of the ODUkP/CBR_ETC100GR-g_A_So Function

In Figure 1, I highlight the Atomic Function that we discuss in Video 1.

ODU4/OTU4 System with 100Gbps Ethernet Adaptation (or ODUkP/CBR_ETC100GR-g_A_So) Function Highlighted

Figure 1, Illustration of the ODU4/OTU4 System, with the Atomic Functions, that we discuss in Video 1, highlighted

You Can Also Check Out the Video Below

Click HERE to Go to Video 2 – The ODUk_TT_So and OTUk/ODUk_A_So Atomic Functions

Click HERE to return to the Main Lesson 10 Page – Non-Multiplexed Applications

Lesson 5 – PT = 0x20 Approach

This blog post provides information and Video Training on the PT = 0x20 Approach for Mapping/Multiplexing Lower-Speed ODUj Tributary Signals into an ODUk Server Signal.

Lesson 5 – PT = 0x20 Approach to Mapping/Multiplexing Lower-Speed ODUj Tributary Signals into an ODUk Server Signal.

This portion of Lesson 5 presents information, along with a Training Video on how we Map and Multiplex Lower-Speed ODUj Tributary Signals into a Higher-Speed ODUk Server Signal, using the PT = 0x20 Approach.

You can watch the Video Training for the PT = 0x20 Approach to Mapping/Multiplexing ODUj Tributary Signals into an ODUk Server Signal, below.

The rest of this blog post presents a brief summary of this Video Training.

Why Do We use the Expression PT = 0x20 and What Does it Mean?

Recall that PT is an abbreviation for Payload Type.

If you recall from our discussion in Lesson 2, (of the OPU frame training) one of the types of Overhead data that an OPU frame will transport (in addition to the client data) is the PSI (Payload Structure Identifier) Message.

This PSI Message is a 256-byte message that transports information about the type of traffic (or client signal) that this OPU data-stream is transporting.

The very first byte, within this 256-byte message, is the PT (or Payload Type) Byte.

I will show you a figure, that I showed you back in Lesson 5, during our OPU Frame Presentation to “jog” your memory.

OPU Frame with PSI Byte-Field Highlighted and a Breakout of the Multiplexed Structure PSI Message

Figure 1, Illustration of an OPUk Frame, transporting the Multiplexed Traffic Type of PSI Message (NOTE: There is no CSF field).

Additionally, I show you another Figure to help state what we mean by the expression “PT = 0x20”.

Listing of Payload Types - with PT = 0x20 Item Highlighted

Figure 2, Illustration of a Table (that I present during Lesson 5 Training) that helps to explain what we mean by “PT = 0x20”.

Hence, if the Source PTE sets the PT byte (within each outbound PSI Message – that it transmits) to 0x20, then this means the following things.

  • We will be using an Older Scheme for Mapping/Multiplexing Lower-Speed ODUj Tributary Signals into an ODUk Server signal
    • The PT = 0x20 Approach came long before the PT = 0x21 Scheme.
  • The PT = 0x20 scheme covers the mapping and multiplexing of the following tributary signals:
    • ODU0, or ODU1 or ODU2
  • Into the following ODUk server signals:
    • OPU1 or OPU2 or OPU3
  • The PT = 0x20 scheme DOES NOT support the mapping/multiplexing of the following ODUj tributary signals:
    • ODUflex, or ODU2e
  • Nor does the PT = 0x20 scheme support mapping/multiplexing ODUj tributary signals into an ODU4/OPU4 server signal.
  • The PT = 0x21 approach supports all of these mapping/multiplexing schemes.

Table 1 presents a summary of the PT = 0x20 Cases that we will be covering during this training.

Table 1, Summary of the PT = 0x20 Mapping/Multiplexing Cases that we will be Covering During this Training

ODUj SignalMapping StructureMapping MethodNumber of ODUj SignalsIntermediate StructureODUk/OPUk Signal
ODU0ODTU01AMP2ODTUG1ODU1/OPU1
ODU1ODTU12AMP1 or 2ODTUG2ODU2/OPU2
ODU2ODTU23AMP4ODTUG3ODU3/OPU3
ODU1ODTU13AMP16ODTUG3ODU3/OPU3

The next three figures, I took from ITU-T G.709. These figures show illustrations of the various PT = 0x20 Mapping/Multiplexing schemes that we will discuss in this Video Training.

ITU-T G.709 Drawing for Mapping and Multiplexing 2 ODU0 Tributary Signals into an ODU1 Server Signal

Figure 3, ITU-T G.709 Illustration for Mapping/Multiplexing two ODU0 Tributary Signals into an OPU1 Server Signal.

ITU-T G.709 Drawing for Mapping and Multiplexing 4 ODU1 Tributary Signals into an ODU2 Server Signal

Figure 4, ITU-T G.709 Illustration for Mapping/Multiplexing four ODU1 Tributary Signals into an OPU2 Server Signal.

ITU-T G.709 Drawing for Mapping and Multiplexing 4 ODU2 or 16 ODU1 Tributary Signals into an ODU3 Server Signal

Figure 5, ITU-T G.709 Illustration for Mapping/Multiplexing four ODU2 or 16 ODU1 Tributary Signals into an OPU3 Server Signal.

For More Information/Resources on Lesson 5, Click on the Items Below.

Resources Page - Lesson 5 - Mapping/Multiplexing Lower-Speed ODUj Tributary Signals into an ODUk Server Signal

Resources – OTN Lesson 5

Resources - OTN Lesson 5 - Mapping/Multiplexing Lower-Speed ODUj Tributary Signals into an ODUk Server Signal This page contains links ...
Read More
The Forum

The Forum Page

The Best Darn OTN Training ... Period - Forum This page serves as a place-holder for the Forum. The Forum ...
Read More
Mistakes and Corrections to OTN Lesson 5 - Mapping Lower-Speed ODUj Tributary Signals into an ODUk Server Signal

OTN – Lesson 5 – Mistakes/Corrections

OTN Lesson 5 - Mapping/Multiplexing Lower-Speed ODUj Tributary Signals into an ODUk Server Signal - Mistakes/Corrections This page identifies any ...
Read More

Defect – Definition

This post presents ITU-T G.806’s definition of a defect or defect condition.

ITU-T G.806 defines the word defect as follows:

Defect: The density of anomalies has reached a level where the ability to perform a required function has been interrupted.

We use defects as an input for performance monitoring, the control of consequent actions and for the determination of fault causes.

In other words, defects are bad.

If some piece of networking equipment is declaring a defect condition, then it is saying that it “cannot do its job properly” because of this condition.

Lesson 2 – OPU Framing

This blog post presents a training video on the OPU (or Optical Payload Unit) frames. This post also contains a written overview of OPU frames as well.

OTN Lesson 2 – OPU (Optical Payload Unit) Framing

An OPU (Optical Payload Unit) frame is that portion of an OTU (Optical Transport Unit) frame that actually carries and transports client data throughout the Optical Transport Network (OTN).

You can Check Out the Training Video on OPU Framing Below.

Click on the Link Below to See the ODU Training Video

Click on the Link Below to Return to the Main Lesson 2 Page.

The OPU frame is a subset of both an ODU (Optical Data Unit) and an OTU (Optical Transport Unit) frame.

Where is the OPU Layer within the OTN Protocol Stack?

Figure 1 presents an illustration of the OTN Protocol Stack, with the OPU Layer Highlighted

OTN Protocol Stack - OPU Layer Highlighted

Figure 1, Illustration of the OTN Protocol Stack, with the OPU Layer Highlighted

This figure shows that the OPU Layer is the closest layer to the Client Layer. In fact, we map the client data into OPU frames and transport them throughout the OTN in that manner.

The Basic Structure of the OPU Frame

I present an illustration of the Basic (or Generic) Structure of the OPU Frame, below in Figure 2.

Generic OPUk Frame

Figure 2, Illustration of the Basic (or Generic) Structure of an OPU Frame

Each OPU frame is a 4 Row x 3810 byte-column structure. The OPU Frame consists of two basic types of fields.

  • The Payload Fields (which are the Pink-colored fields in Figure 2), and
  • The Overhead Fields (those non-Pink-colored fields on the left-hand side of the figure).

Each OPU frame contains 8 overhead bytes. And all OPU-rates (with the exception of the OPU4 frame) contains 15,232 payload bytes. OPU4 frames contain 15,200 payload bytes, as I show later in this post.

We use the Payload Fields to transport the client data, and we use the Overhead fields for management purposes.

What Do the OPU Overhead Fields Manage?

In general, the OPU Overhead Fields (that I show in Figure 2) manage the following tasks.

  • They manage the mapping of client data into the OPU payload, and
  • These fields also (in-turn) manage the de-mapping of client data from the OPU payload.
    • The JC1 – JC6, NJO, and PJO bytes support this effort.
  • They identify (to the OTN) the type of client signal, that we are transporting via this particular OPUk signal.
    • The PSI byte supports this role.
  • And, finally, they support the mapping of Lower-Speed ODUj Tributary signals into an OPU4 frame (in particular).
    • The OMFI byte supports this role.

What are some of the Various Types of OPU Frames

Throughout this training, we will be working with the following four types of OPU frames.

  • The BMP (Bit Synchronous Mapping Procedure) frame.
  • The AMP (Asynchronous Mapping Procedure) Applications
  • The GMP (Generic Mapping Procedure) Applications – up to OPU3 Rates
  • The GMP (Generic Mapping Procedure) Applications – for the OPU4 Rate

Let’s Discuss Each of these Types of OPU Frames, below.

OPU Frames for BMP Applications

Figure 3 presents an illustration of an OPU Frame that is supporting BMP Mapping.

OPUk Frame for BMP Mapping Applications

Figure 3, Illustration of an OPU Frame – supporting BMP Mapping

This is by-far the simplest OPU frame.

In this particular OPU frame, the JC1 through JC3 and the NJO bytes serve no real purpose other than to occupy space. Additionally, for BMP Mapping applications, the PJO byte will always transport client data.

The PSI (Payload Structure Identifier) byte will repeatedly transmit the PSI Message. We will discuss the PSI Message later in this blog post.

Click Here to learn more about the Bit Synchronous Mapping Procedure (BMP) in Lesson 4.

OPU Frames for AMP Applications

Figure 4 presents an illustration of an OPU frame that supports AMP Mapping Applications.

AMP Discussion - Basic Figure - Introduction of OPUk OH

Figure 4, Illustration of an OPU Frame – supporting AMP Mapping Applications

The OPU Frame in Figure 4 looks (and is) very similar to that for Figure 3. However, in the case of Figure 4, the JC1 through JC3, NJO, and PJO bytes are all active and play a significant role in AMP Mapping (or De-Mapping).

Please Click Here to learn more about AMP Mapping and these overhead fields in Lesson 4.

OPU Frames for GMP Applications – up to OPU3

Figure 5 presents an illustration of an OPU Frame that supports GMP Mapping. In this frame, we are looking at a figure that supports OPU rates from OPU0 up to OPU3.

OPU0 through OPU3 - GMP Applications

Figure 5, Illustration of an OPU Frame – supporting GMP Mapping Applications (OPU0, OPU1, OPU2, OPU3, and OPUflex).

As you can see, the OPU Overhead for this frame looks VERY different from that of Figures 3 and 4. AMP and BMP Mapping are closely related to each other. However, GMP is a VERY different mapping procedure from AMP or BMP.

Hence, GMP Mapping will require the use of 6 Justification Control fields (JC1 through JC6). Additionally, GMP does not use the NJO or PJO fields.

Finally, this brings us to the next (and final) type of OPU Frame.

OPU Frames for GMP Applications – OPU4 Applications

Figure 6 presents an illustration of an OPU Frame that also supports GMP Mapping applications. However, this particular figure is only applicable to the OPU4 Rate.

OPU Overhead - GMP Mapping - JC1 through JC6 Break down at the Bit-Level

Figure 6, Illustration of an OPU Frame – supporting GMP Mapping Applications (OPU4 ONLY)

The OPU Frame in Figure 6 looks very similar to that in Figure 5, with just two differences.

  • The OPU4 Frame has an OFMI byte-field in the OPU Overhead in Row 4, and
  • The OPU4 Frame has a total of 32-byte area that is reserved for Fixed Stuffing.

Both OPU Frames in Figures 5 and 6 have six (6) sets of Justification Control Bytes (JC1 through JC6). These Justification Control fields are required to support GMP Mapping.

How is the OPU4 Frame different from the other OPU Frames?

Each of the OPU frames, that I show in Figures 3, 4 and 5 all have 15,232 bytes within their OPU Payload.

However, because the OPU4 frame has this 32-byte Fixed Stuff area (at the back-end of this frame), it only has 15,200 bytes within its OPU Payload.

I show a different illustration of the OPU4 frame, in which the OMFI is more visible, below in Figure 7.

OPU4 Frame for Lower-Speed ODUj applications

Figure 7, Another Illustration of the OPU4 Frame

Click Here to learn more about GMP Mapping in Lesson 4.

The OMFI (or Optical Multi-Frame Identifier) byte field only exists in OPU4 Frames. Additionally, we only use the OMFI field, when are supporting Multiplexed Applications. We will never use the OMFI field if we are just (for example) mapping a 100GBASE-R client signal into an OPU4 payload.

For example, we will use the OMFI field if we are mapping 80 ODU0 signals into an OPU4/ODU4 server signal.

Click HERE to learn more about Multiplexed Applications (e.g., Mapping Lower-Speed ODUj Tributary Signals into a Higher-Speed ODUk Server signal) in Lesson 5.

The PSI Byte and the Payload Structure Identifier Message

Let’s talk about the PSI Byte-field.

In Figure 8, I show an illustration of our Generic OPU Frame, with the PSI Byte-field Highlighted.

Generic OPU Frame with PSI Byte Highlighted

Figure 8, Illustration of the Generic OPU Frame, with the PSI Byte-field Highlighted.

This figure shows that the PSI byte is located in Row 4, Byte-Column 15 within the OPU frame.

The purpose of the PSI byte is to repeatedly transport the PSI Message.

What is the PSI Message?

The PSI (or Payload Structure Identifier) Message is a 256-byte message that identifies the kind of traffic that we are transporting via this particular OPU data-stream.

ITU-T G.709 defines two different types of PSI Messages.

  • The Non-OTN Client/Non-Multiplexed Structure PSI Message and
  • The Multiplexed Structure – PSI Message

Figure 9 presents an illustration of an OPU Frame, with the PSI Byte Highlighted, along with a breakout of the Non-OTN Client/Non-Multiplexed Structure PSI Message.

OPU Frame with PSI Byte-Field highlighted and a Breakout of the Non-OTN Client/Non-Multiplexed PSI Message

Figure 9, Illustration of the OPU Frame, with the PSI Byte-field highlighted, along with a breakout of the Non-OTN Client/Non-Multiplexed Structure PSI Message.

Likewise, Figure 10 presents an illustration of an OPU Frame, with the PSI Byte Highlighted, along with a breakout of the Multiplexed Structure PSI Message.

OPU Frame with PSI Byte-Field Highlighted and a Breakout of the Multiplexed Structure PSI Message

Figure 10, Illustration of the OPU Frame, with the PSI Byte-field highlighted, along with a breakout of the Multiplexed Structure PSI Message.

What is the Non-OTN Client/Non-Multiplexed Structure PSI Message?

The Non-OTN Client/Non-Multiplexed Structure PSI Message is one variation of a PSI Message. This message is 256-bytes in length (just like its Multiplexed Structure counterpart).

We use this type of PSI Message whenever we are working with an OPU frame that is transporting a Single Non-OTN Client Signal (such as 1000BASE-X or 100GBASE-R).

The easiest way to tell if you are working with the Non-OTN Client/Non-Multiplexed PSI Message is if you see the CSF (Client Signal Fail) Bit-field within PSI byte 2.

What is the Multiplexed Structure PSI Message?

The Multiplexed Structure PSI Message is the other variant of a PSI Message.

We use this type of PSI Message whenever we are working with an OPU Frame that is transporting numerous Lower-Speed ODUj Tributary Signals.

The easiest way to tell if you are working with the Multiplexed Structure PSI Message is to see if you do NOT see the CSF (Client Signal Fail) Bit-field within PSI Byte 2.

How Do We Transport the PSI Message?

Since an OPU frame only contains a single PSI Byte, and each PSI Message (whether it is the Non-OTN Client/Non-Multiplexed or the Multiplexed-Structure type) are 256 bytes; we have to transport each PSI Message over a stream of 256 consecutive OPU frames.

The Source PTE will continuously transmit the relevant PSI Message, over and over.

Again, the purpose of this PSI Message is to inform the OTN of the type of client data that we are transporting within this particular OPU data-stream.

What is the PT (or Payload Type) Byte?

If you take a close look at the PSI Messages, within both figures 9 and 10, then you notice that the very first byte within each of these PSI Messages is the PT (or the Payload Type) byte.

The Payload Type byte is key to helping us identify the type of traffic that we are transporting via this OPU data-stream.

Table 1 presents a listing of the many standard values for PT and the corresponding traffic that we are transporting within our OPU data-stream.

Table 1, Listing of the Many ITU-T G.709 Standard Values of PT (Payload Type) and the Corresponding Client Signal(s) that we are transporting within our OPU data-stream.

Payload Type Value (Hex)Interpretation (Client Data Type)
01Experimental Mapping (Note 3)
02Asynchronous CBR Mapping, see Clause 17.2
03Bit-Synchronous CBR Mapping, See Clause 17.2
04Not Available (Note 2)
05GFP Mapping, See clause 17.4
06Not Available (Note 2)
07PCS Codeword Transparent Ethernet Mapping:
1000BASE-X into OPU0, see Clause 17.7.1 and 17.7.1.1
40GBASE-R into OPU3, see Clauses 17.7.4 and 17.7.4.1
100GBASE-R into OPU4, see Clauses 17.7.5 and 17.7.5.1
08FC-1200 into OPU2e mapping, see Clause 17.8.2
09GFP Mapping into Extended OPU2 Payload, see Clause 17.4.1 (Note 5)
0ASTM-1 Mapping into OPU0, see Clause 17.7.1
0BSTM-4 Mapping into OPU0, see Clause 17.7.1
0CFC-100 Mapping into OPU0, see Clause 17.7.1
0DFC-200 Mapping into OPU1, see Clause 17.7.2
0EFC-400 Mapping into OPUflex, see Clause 17.9
0FFC-800 Mapping into OPUflex, see Clause 17.9
10Bit stream with Octet timing mapping, see Clause 17.6.1
11Bit stream without octet timing mapping, see Clause 17.6.2
12IB SDR mapping into OPUflex, see clause 17.9
13IB DDR mapping into OPUflex, see clause 17.9
14IB QDR mapping into OPUflex, see Clause 17.9
15SDI mapping into OPU0, see Clause 17.7.1
16(I.485/1.001) Gbit/s SDI mapping into OPU1, see Clause 17.7.2
171.485 Gbit/s SDK mapping into OPU1, see Clause 17.7.2
18(2.970/1.001) Gbit/s SDI mapping into OPUflex, see clause 17.9
192.970 Gbit/s SDI mapping into OPUflex, see Clause 17.9
1ASBCON/ESCON mapping into OPU0, see clause 17.7.1
1BDVB_ASI mapping into OPU0, see clause 17.7.1
1CFC-1600 mapping into OPUflex, see Clause 17.9
1DFlexE Client mapping into OPUflex, see Clause 17.11
1EFlexE aware (partial rate) mapping into OPUflex, see Clause 17.12
1FFC-3200 Mapping into OPUflex, see Clause 17.9
20ODU Multiplex Structure supporting ODTUjk only, see Clause 19 (AMP only)
21ODU Multiplex Structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see Clause (GMP capable) (Note 6)
22ODU Multiplex Structure supporting ODTUCn.ts, see Clause 20 (GMP capable)
3025GBASE-R mapping into OPUflex, see Clause 17.13
31200GBASE-R mapping into OPUflex, see Clause 17.13
32400GBASE-R Mapping into OPUflex, see Clause 17.13
55Not Available (Note 2)
66Not Available (Note 2)
80 - 80FReserved Codes for Proprietary Use (Note 4)
FDNULL Test Signal Mapping, see Clause 17.5.1
FEPRBS Test Signal Mapping, see Clause 17.5.2
FFNot Available (Note 2)

NOTES from Table 1

  1. There are 198 spare codes left for future international standardization. Refer to Annex A of ITU-T G.806 for the procedure to obtain one of these codes for a new Payload Type.
  2. These values are excluded from the set of available code points. These bit patterns are present in ODUk maintenance signals or were used to represent client types that are no longer supported.
  3. The value “01” is only to be used for experimental activities in cases where a mapping code is not defined in this table. Refer to Annex A of ITU-T G.806 for more information on the use of this code.
  4. These 16 code values will not be subject to further standardization. Refer to Annex A of ITU-T G.806 for more information on the use of these codes.
  5. Supplement 43 (2008) to the ITU-T G-series of Recommendations indicated that this mapping recommended using PT = 0x87.
  6. Equipment supporting ODTUk.ts for OPU2 or OPU3 must be backward compatible with equipment that supports only the ODTUjk. ODTUk.ts capable equipment transmitting PT = 0x21 which receive PT = 0x20 from the far-end shall revert to PT = 0x20 and operate in ODTUjk only mode. Refer to ITU-T G.798 for the specification.

As you can see, from Table 1, if we were to receive an OPU4 signal in which the Payload Type (PT) = 0x07, then this means that this OPU4 signal is transporting a 100GBASE-R client signal. This is one example of how the PSI Message (which contains the PT byte) will inform us of the type of client signal(s) that are transporting via this OPU signal.

We will discuss OPU traffic, in which PT = 0x20 and 0x21 extensively in Lesson 5.

What is the CSF (Client Signal Fail) Bit-field?

As client circuitry (such as an Ethernet MAC) maps its traffic into an OTN signal (such as an OPU4 data-stream) it is expected to monitor the quality of the client signal that it is providing to the OPU Mapper.

If this client circuitry determines that there is a problem with the data (that it is providing to the OPU Mapper), then it is expected to assert the CSF (Client Signal Fail) bit-field.

The CSF bit-field will then travel throughout the OTN (via the PSI Message, within the OPU data-stream). The purpose of this bit-field is to alert the client circuitry (at the remote PTE) that the underlying client signal is corrupted or defective. In other words, CSF is a caution signal.

It’s sort of like the Biohazard Sign that I show in the Figure below.

CSF is like the Bioharzard Sign

Figure 11, A Warning Sign – Similar (in the role) to the CSF (Client Signal Fail) Bit-field.

You Can Also Check Out the OPU Training Video Below.

Click on the Link Below to See the ODU Training Video

Click on the Link Below to Return to the Main Lesson 2 Page.

For More Information/Resource about Lesson 2, Click on the Items Below.

The Forum

The Forum Page

The Best Darn OTN Training ... Period - Forum This page serves as a place-holder for the Forum. The Forum ...
Read More
Mistakes and Corrections to OTN Lesson 2 - OPU, ODU and OTU Framing

OTN – Lesson 2 – Mistakes/Corrections

OTN Lesson 2 - OPU, ODU and OTU Frame Training - Mistakes/Corrections This page identifies any mistakes and corrections to ...
Read More

What is pF_DS at the OTUk Layer?

This blog post briefly defines the pF_DS (Far-End Defect Second) parameter – for the OTUk Layer.

What is the pF_DS (Far-End Defect Second) Parameter for the OTUk Layer?

The purpose of this blog post is to briefly define and describe the pF_DS (Far-End Defect Second) parameter that the OTN STE (or OTUk_TT_Sk Atomic Function) will declare.  

The OTN STE (or OTUk_TT_Sk function) will include information on pF_DS within each Performance Monitoring report, that it sends to System Management.  

Performance Monitoring - Another Image

NOTES:

  1. The OTN PTE (or ODUP_TT_Sk Atomic Function) also monitors and generates information on the PF_DS (Far-End Defect Second) parameter at the ODUk Layer.  Please see the pF_DS at ODUk Layer Post for more details on this parameter.
  2. Throughout this post, I will be using the terms:  OTN STE and OTUk_TT_Sk Function interchangeably.  In the context of this blog post, these two terms mean the same thing.  

Introduction

At the OTUk Layer, the OTN (Sink) STE is the entity that is responsible for detecting and reporting Far-End Defect Second events.

As the OTN STE receives and monitors its incoming OTUk signal, it will check for many things.  It will continuously check the incoming OTUk signal for Service-Affecting Defects (e.g., dBDI, dTIM, dLOF, dLOS-P, etc.) as well as bit (or symbol) errors (e.g., SM-BIP-8 errors, SM-BEI errors, FEC errors, etc.).  

Another thing that the OTN STE will do (as it continuously monitors it its incoming OTUk signal) is to divide each one-second period of (monitoring) time into the following two categories:

  • Far-End Available (Working) Seconds, and
  • Far-End Defect Seconds

Anytime the OTN STE detects and categories a given one-second period as being a Far-End Defect Second, then it will increment the pF_DS parameter and report that information to System Management.  

So When does the OTN STE detect and flag a given One-Second Period as being a “Far-End Defect Second”?

ITU-T G.798 presents the following Perfomance Monitoring Equation for the OTUk_TT_Sk function.  

pF_DS <- dBDI

Where:

dBDI is the current state of the OTUk-BDI or Backward Defect Indicator Defect (at the OTUk Layer)

The OTN STE (or OTUk_TT_Sk function) will continuously evaluate the above-mentioned equation, as it monitors its incoming OTUk signal.  

This equation states that the OTN STE will declare a given one-second period as being a “Far-End Defect Second” if it has declared the dBDI defect condition during any portion of that one-second period.  

So, if the OTUk_TT_Sk function has declared the dBDI defect condition for even a fraction of a given one-second period, it will declare that one-second period as a Far-End Defect Second.  It will also set the parameter pF_DS to 1, and report that information to System Management.  

Conversely, if the OTN STE determines that the OTUk_TT_Sk function did not declare the dBDI defect condition, at all, during a given one-second period, then it will declare that one-second period as being a Far-End Available (Working) Second.   In this case, the OTN STE will NOT set the parameter pF_DS to 1.  

Are there any Times or Conditions, during which the OTN STE should NOT tally the pF_DS Parameter?

Yes, ITU-T G.798 states that the OTUk_TT_Sk function (or System Management) should discard the previous and the current one-second period’s measurement of pF_DS whenever it declares either the dIAE (Input Alignment Error) or dBIAE (Backward Input Alignment Error) defect conditions.

We need to discard the previous one-second period reading, due to the delay of the IAE signaling indicator, coming from the remote terminal equipment.

Is there such a thing as a Near-End Defect Second?

Throughout this post, we have been using the term “Far-End Defect Second”.  Does this mean that there is another parameter called “Near-End Defect Second“?

Answer:  Yes, there is such a parameter.  Please see the post on Near-end Defect Seconds (pN_DS) at the OTUk Layer for more details.  

And Finally, CLICK on the Image Below to see More OTN-Related Topics in this Blog.  

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 is the OTSi/OTUk_A_So Function?

This post briefly describes the OTSi/OTUk_A_So (OTSI to OTUk Adaptation Source) Atomic Function.


What is the OTSi/OTUk_A_So Atomic Function?

The expression:  OTSi/OTUk_A_So is an abbreviation for the term: Optical Tributary Signal to OTUk Adaptation Source Function.

In this blog post, we will briefly describe the OTSi/OTUk_A_So set of atomic functions.

Changes in Terminology

Before we proceed on with this post, we need to cover some recent changes in terminology.  Before the June 2016 Version of ITU-T G.709, the standard documents were referring to this particular atomic function as the OCh/OTUk_A_So function.

However, the standards committee has recently decided to start changing the wording from using the term OCh (for Optical Channel) to OTSi (for Optical Tributary Signal).

For completeness, I will tell you that ITU-T G.959.1 defines the term OTSi as:

Optical signal that is placed within a network media channel for transport across the optical network.  This may consist of a single modulated optical carrier or a group of modulated optical carriers or subcarriers.“.

Therefore, to “speak the same language” as does the standard committee, we will call this atomic function the OTSi/OTUk_A_So atomic function.

Likewise, in another post, we will now call (what we used to call, the OCh/OTUk_A_Sk function) the OTSi/OTUk_A_Sk function.

I have created another post that provides documentation of the relationships between some of the old (now obsolete) terms and the new (and approved) terms that our standard committee is now using.

The OTSi/OTUk_A_So Function

The OTSi/OTUk_A_So function is any circuit that takes an OTUk data-stream, clock, frame-start, and multi-frame start signals and converts this data into a combined, scrambled data-stream, which (in some cases) contains a FEC (Forward Error Correction) field and can be readily converted into the optical format (at the output of this function).

ITU-T G.798 states that the system designer can use this function for all OTUk rates (e.g., from OTU1 through OTU4).

However, in most cases, we will typically use the OTSi/OTUk_A_So function for OTU1 and OTU2 applications.  We will typically use the OTSiG/OTUk_A_So  atomic function for OTU3 and OTU4 applications.

We discuss the OTSiG/OTUk_A_So atomic function in another post.

Figure 1 presents a simple illustration of the OTSi/OTUk_A_So function.

OTSi/OTUk-a_A_So Simple Function Drawing

Figure 1, Simple Illustration of the OTSi/OTUk_A_So function.

ITU-T G.798 defines three variants of this particular function.  I have listed these variants below in Table 1.

Table 1, List of the ITU-T G.798-specified Variants for the OTSi/OTUk_A_So functions

Function NameDescriptionComments
OTSi/OTUk-a_A_SoOTSi to OTUk Adaptation Source Function with ITU-T G.709 Standard FECCan be used for OTU1 through OTU4 applications
OTSi/OTUk-b_A_SoOTSi to OTUk Adaptation Source Function with No FECCannot be used for OTU4 applications
OTSi/OTUk-v_A_SoOTSi to OTUk Adaptation Function with Vendor-Specific FECCan be used for OTU1 through OTU4 applications

Table 1 shows that the OTSi/OTUk-a_A_So and the OTSi/OTUk-v_A_So functions will compute and append some sort of FEC field to the backend of each outbound OTUk frame.

However, this table also shows that the OTSi/OTUk-b_A_So variant does not generate the FEC field.

As a consequence, ITU-T G.798 states that one can use the OTSi/OTUk-a_A_So and OTSi/OTUk-v_A_So functions for OTU1 through OTU4 applications.  Additionally, the standard also recommends that the user NOT use the OTSi/OTUk-b_A_So function for OTU4 applications.

The OTU4 rate requires the use of Forward-Error-Correction.

What Variant will we Discuss Throughout this Post?

Throughout this post, we will be discussing the OTSi/OTUk-a_A_So version of this atomic function.

The OTSi/OTUk-b_A_So  and OTSi/OTUk-v_A_So atomic functions do everything that the OTSi/OTUk-a_A_So does, except that the -b variant does NO FEC Encoding and the -v variant does FEC Encoding differently than what I describe here.

So What All Does this Atomic Function Do?

The OTSi/OTUk-a_A_So function will accept the OTUk data-stream, OTUk clock signal, frame-start signal, and multi-frame start signals via the CI_D, CI_CK, CI_FS and CI_MFS inputs (of this function) respectively, and it will perform the following tasks.

  • It will insert the FAS and MFAS fields into the OTUk data-stream (coincident to whenever the upstream OTUk_TT_So function asserts the CI_FS and CI_MFS input, respectively).
  • This function will compute and append a FEC field to the back-end of each outbound OTUk frame)
  • It will scramble this “combined” OTUk data-stream (consisting of the FAS, MFAS and FEC fields)
  • This function will then transmit this combined (and scrambled) data-stream to external Electrical-to-Optical Conversion circuitry (which will convert our full-blown OTUk signal into the optical format).

Figure 2 presents an illustration of a Unidirectional Connection that shows where the OTSi/OTUk-a_A_So function “fits in” within a system.

OTSi/OTUk-a_A_So Function Highlighted in Unidirectional OTUk End-to-End Connection

Figure 2, Illustration of an STE, transmitting an OTUk signal (over optical fiber) to another STE – the OTSi/OTUk-a_A_So function is highlighted.

Functional Description of this Atomic Function

Let’s take a closer look at this function now.

Figure 3 presents the Functional Block Diagram of the OTSi/OTUk-a_A_So Atomic Function.

OTSi/OTUk-a_A_So Functional Block Diagram

Figure 3, Illustration of the Functional Block Diagram of the OTSi/OTUk-a_A_So Atomic Function

Hence, Figure 3 shows that this function contains the following functional blocks.

  • MFAS/FAS Insertion Block
  • FEC Encoder Block
  • Scrambler Block

I will briefly discuss each of these functional blocks below.

The MFAS/FAS Insertion Block

The MFAS/FAS Insertion block will insert the FAS and MFAS fields into the outbound OTUk data-stream, each time the upstream OTUk_TT_So function asserts the CI_FS input pin.

Likewise, the MFAS/FAS Insertion block will initialize the MFAS byte-field (to 0x00), within the outbound OTUk-data-stream, each time the upstream OTUk_TT_So function asserts the CI_MFS input.

The MFAS/FAS Insertion Block will proceed to increment the contents of the MFAS field, within each OTUk frame that it generates.

The FEC Encoder Block

The FEC Encoder Block (within the OTSi/OTUk-a_A_So function) will compute the FEC field and append this field to the back-end of each outbound OTUk frame.

ITU-T G.709 recommends that (for a Fully-Compliant OTUk Frame) one use the Reed Solomon RS(255,239) Code for its Forward-Error Correction scheme.

The standard also recommends that the System Designer use Symbol-Interleaving and that the user place the resulting FEC code into a 4-row x 256-byte column field, at the back-end of each outbound OTUk frame.

I show the location (that the FEC Encoder should insert the FEC Code) within the OTUk frame, below in Figure 4.

OTUk Frame with FEC Field highlighted

Figure 4, Location of FEC Code (at the back-end of each outbound OTUk frame)

I discuss this Forward Error Correction scheme in much greater detail in another post.

Scrambler Block

ITU-T G.709 mandates that we scramble OTUk data before we transmit it over optical fiber.

The standard requires that we do this to ensure that this OTUk signal (that we transmit over optical fiber) has sufficient bit-timing content for Clock and Data Recovery PLLs (Phase-Locked Loops) within the Sink STE (at the remote end).

ITU-T G.709 further states that the scrambler must operate as a frame synchronous scrambler of sequence length 65,535 (e.g., 216-1) which is operating at the OTUk rate.

Finally, ITU-T G.709 also states that the Scrambler must use the generating polynomial of 1 + x + x3 + x12 + x16.

I show a simple diagram on how one can implement the Scrambler within their OTSi/OTUk-a_A_So function design, below in Figure 5.

Scrambler Function - OTSi/OTUk-a_A_Sk function

Figure 5, High-Level Block Diagram of the Frame Synchronous Scrambler

I discuss the Scrambler function and requirements in greater detail in another post.

Once the OTSi/OTUk-a_A_So function has scrambled this outbound OTUk data-stream, then it will transmit it over to some sort of Electrical-to-Optical conversion circuitry (which will convert this data-stream into the Optical Format) for transmission.

Function Defects

This function does not declare any defect conditions.

Function Consequent Equations

This function does not have any Consequent Action (or Equations).

Pin Description of the OTSi/OTUk-a_A_S0 Function

Table 2 presents a list and description of each of the Input and Output pins of the OTSi/OTUk-a_A_So Function.

Table 2, Pin Description of the OTSi/OTUk-a_A_So Atomic Function

Signal NameTypeDescription
OTUk_CP Interface
CI_DInputOTUk Characteristic Information - Data Input:
The function user (upstream OTUk_TT_So function) is expected to apply the OTUk data-stream via this input. This OTUk data-stream will contain all of the following portions of the OTUk frame.
- OTUk SMOH (Section Monitoring Overhead) data
- All remaining OTUk payload data (e.g., the ODUk/OPUk data).

NOTE: This data will not include the FAS, MFAS nor FEC fields.

All data that the user supplies to this input should be synchronized with the CI_CK input clock signal.

NOTE: This OTUk data-stream should be unscrambled.
CI_CKInputOTUk Characteristic Information - Clock Input:
This clock signal will sample all data that the user supplies to the CI_D, CI_FS and CI_MFS inputs.

The OTSi/OTUk-a_A_So function will also use this clock signal as its base timing source.
CI_FSInputOTUk Characteristic Information - Frame Start Input:
The upstream OTUk_TT_Sk function will drive this input signal TRUE, coincident to whenever it is supplying the very first bit or byte (of a given OTUk frame) to the CI_D input.

The OTSi/OTUk-a_A_So function will insert the FAS field into the outbound OTUk data-stream coincident to whenever the user asserts this input signal.

The upstream OTUk_TT_So function is expected to assert this signal once for each OTUk frame period.
CI_MFSInputOTUk Characteristic Information - Multiframe Start Input:
The upstream OTUk_TT_So function will drive this input signal TRUE coincident to whenever it is supplying the very first bit or byte of a given OTUk superframe to the CI_D input.

The OTSi/OTUk-a_A_So function will set the MFAS byte to 0x00 coincident to whenever the user asserts this input signal.

The upstream OTUk_TT_So function is expected to assert this signal once for each OTUk superframe period, one once every 256 OTUk frame periods.
OTSi_AP Interface
AI_PLDOutputOTSi Adapted Information - OTSi Payload Output:
The OTSi/OTUk-a_A_So function takes all of the data (that the user supplies to the CI_D input pin), along with the FAS, MFAS and FEC data that it has also inserted into this OTUk data-stream. Finally, this function will scramble this data before it outputs all of this data via this output pin.

In summary, this signal will contain a full-blown OTUk data-stream (that consists of all of its framing fields and the FEC) and is also scrambled.

The system-designer will typically route this data-stream to cicuitry that will convert or modulate this dat into the optical format (for transmission over optical fiber).

For More Blog Posts on Optical Transport Networks, please 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

Test Post – Do Not Publish

Test Table

Table Typed in Manually

ODUj SignalMapping StructureMapping MethodNumber of ODUj SignalsIntermediate StructureODUk/OPUk Signal
ODU0ODTU2.1GMP8ODTUG2ODU2/OPU2
ODUflexODTU2.tsGMP1 to 8ODTUG2ODU2/OPU2
ODU1ODTU12AMP4ODTUG2ODU2/OPU2
ODU0ODTU3.1GMP32ODTUG3ODU3/OPU3
ODUflexODTU3.tsGMP1 to 32ODTUG3ODU3/OPU3
ODU1ODTU13AMP16ODTUG3ODU3/OPU3
ODU2ODTU23AMP4ODTUG3ODU3/OPU3
ODU2eODTU3.9GMP3ODTUG3ODU3/OPU3
ODU0ODTU4.1GMP80ODTUG4ODU4/OPU4
ODUflexODTU4.tsGMP1 to 80ODTUG4ODU4/OPU4
ODU1ODTU4.2GMP40ODTUG4ODU4/OPU4
ODU2ODTU4.8GMP10ODTUG4ODU4/OPU4
ODU2eODTU4.8GMP10ODTUG4ODU4/OPU4
ODU3ODTU4.31GMP2ODTUG4ODU4/OPU4

Table Exported in from Excel

ODUj SignalMapping StructureMapping MethodNumber of ODUj SignalsIntermediate StructureODUk/OPUk Signal
ODU0ODTU2.1GMP8ODTUG2ODU2/OPU2
ODUflexODTU2.tsGMP1 to 8ODTUG2ODU2/OPU2
ODU1ODTU12AMP4ODTUG2ODU2/OPU2
ODU0ODTU3.1GMP32ODTUG3ODU3/OPU3
ODUflexODTU3.tsGMP1 to 32ODTUG3ODU3/OPU3
ODU1ODTU13AMP16ODTUG3ODU3/OPU3
ODU2ODTU23AMP4ODTUG3ODU3/OPU3
ODU2eODTU3.9GMP3ODTUG3ODU3/OPU3
ODU0ODTU4.1GMP80ODTUG4ODU4/OPU4
ODUflexODTU4.tsGMP1 to 80ODTUG4ODU4/OPU4
ODU1ODTU4.2GMP40ODTUG4ODU4/OPU4
ODU2ODTU4.8GMP10ODTUG4ODU4/OPU4
ODU2eODTU4.8GMP10ODTUG4ODU4/OPU4
ODU3ODTU4.31GMP2ODTUG4ODU4/OPU4

A different Table

AI_TSF InputMI_AdminState InputCI_SSF OutputCI_D Output
FALSENORMALFALSENormal ODUk Traffic
TRUENORMALTRUEODUk-AIS
Don't CareLOCKEDFALSEODUk-LCK

Pin Description Table

Signal NameTypeDescription
OTUk_AP Interface
AI_DInputOTUk Adapted Information - OTUk Input:
The upstream OTUk_TT_Sk function is expected to apply a bare-bones OTUk data-stream to this input.

NOTE: This OTUk data will contain the following fields:
- OTUk SMOH data
- The contents of the APS/PCC channel (within the ODUk Overhead) and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC fields
AI_CKInputOTUk Adapted Information - Clock Input
This clock signal will sample all data that the user supplies to the AI_D, AI_FS, AI_MFS, AI_TSF and AI_TSD inputs.

The OTUk/ODUk_A_Sk function will also use this clock signal as its base timing source.
AI_FSInputOTUk Adapted Information - Frame Start Input:
The upstream OTUk_TT_Sk function will drive this signal TRUE; coincident to whenever it is supplying the very first bit or byte (of a given OTUk frame) to the AI_D input.

The upstream OTUk_TT_Sk function is expected to assert this signal once for each OTUk frame period.
AI_MFSInputOTUk Adapted Information - Multiframe Start Input:
The upstream OTUk_TT_Sk function will drive this signal TRUE coincident to whenever it is supplying the very first bit or byte (of a given OTUk Superframe) to the AI_D input.

The upstream OTUk_TT_Sk function is expected to assert this signal once for each OTUk superframe period, or once every 256 OTUk frame periods.
AI_TSFInputOTUk Adapted Information - Trail Signal Fail Indicator
The upsteam equipment (e.g., the OTUk_TT_Sk function) will typically assert this input pin whenever it is declaring one (or more) service-affecting defects wit the data that it is ultimately applying to the AI_D input of this function.

This signal has a similar role to the AIS signal. Please see the blog post on AIS for more information on this topic.
AI_TSDInputOTUk Adapted Information - Trail Signal Degrade Indicator Input:
The upstream equipment (e.g., the OTUk_TT_Sk function) will typically assert this input whenever it is declaring the dDEG (Signal Degrade) defect with the data that it is ultimately applying to the AI_D input of this function.
ODUk_CP Interface
CI_DOutputODUk Characteristic Information - ODUk Data Output:
The OTUk/ODUk_A_Sk function will take the ODUk data (that it has de-mapped from the OTUk signal, applied at the AI_D input) and output this data via this output signal.

However, if the user commands this function to output the ODUk-LCK Maintenance Signal, then it will do so via this output pin.

Finally, this function will also output the ODUk-AIS Maintenance Signal via this output if conditions warrant.
CI_CKOutputODUk Characteristic Information - Clock Output:
As the ODUk_CP Interface outputs data via the CI_D, CI_FS, CI_MFS, CI_APS, CI_SSF and CI_SSD outputs, all of this data will be updated on one of the clock edges of this clock output signal.
CI_FSOutputODUk Characteristic Information - Frame Start Output:
The ODUk_CP interface will pulse this output signal HIGH whenever the ODUk_CP interface outputs the very first bit (or byte) of a new ODUk frame, via the CI_D output.

This output signal will pulse HIGH once for each ODUk frame.
CI_MFSOutputODUk Characteristic Information - Multiframe Start Output:
The ODUk_CP Interface will pulse this output signal HIGH whenever the ODUk_CP interface outputs the very first bit (or byte) of a new ODUk Superframe, via the CI_D output.

This output signal will pulse HIGH once for each ODUk Superframe (or once each 256 ODUk frames).
CI_SSFOutputODUk Characteristic Information - Server Signal Failure Indicator Output:
One can think of this output pin as a buffered version of the AI_TSF input pin. This function will drive this output pin HIGH anytime the AI_TSF input pin (at the OTUk_AP Interface) is driven HIGH.

Conversely, this function will drive this output pin LOW anytime the AI_TSD input pin is driven LOW.
CI_SSDOutputODUk Characteristic Information - Server Signal Degrade Output:
One can think of this output pin as a buffered version of the AI_TSD output pin. This function will drive this output pin HIGH anytime the AI_TSD input pin (at the OTUk_AP Interface) is driven HIGH.

Conversely, this function will drive this output pin LOW anytime the AI_TSD input pin is driven LOW.
CI_APSOutputODUk Characteristic Information - APS Channel Output:
The OTUk/ODUk_A_Sk function will extract out the contents of the APS channel (from the incoming ODUk data-stream) and it will output the contents of the APS/PCC channel (as it applies to the APS Level that this OTUk/ODUk_A_Sk function is operating at).
OTUk/ODUk_A_Sk_MP Interface
MI_AdminStateInputManagement Interface - AdminState Input:
This input permits the function user to configure the OTUk/ODUk_A_Sk function to output either NORMAL ODUk data, or the ODUk-LCK maintenance signal via the CI_D output of this function.

Setting this input pin to the LOCKED state will configure the OTUk/ODUk_A_Sk function to override the NORMAL ODUk data, and the ODUk-AIS maintenance signal with the ODUk-LCK maintenance signal.
MI_APS_EnInputManagement Interface - APS Enable Input
This input permits the function user to either enable or disable APS/PCC Channel extraction from the incoming ODUk data-stream.

Setting this input pin TRUE configures the OTUk/ODUk_A_Sk function to extract the APS Messages from the APS/PCC channel (within the ODUk Overhead of the incoming ODUk data-stream) and output this data via the CI_APS output port.

Conversely, setting this input pin FALSE disables APS Message extraction from the incoming ODUk data-stream.
MI_APS_LVLInputManagement Interface - APS Level Input:
This input permits the user to specify the APS Level for this instantiation of the OTUk/ODUk_A_Sk function.

If the MI_APS_En input is TRUE, then this input pin will select the APS Level (and that portion of the APS/PCC Channel) that this function will output via the CI_APS output. Please see the APS/PCC post on more information about this protocol.

If the MI_APS_En input is FALSE, then this input will be ignored.

Pin Description Table

Signal NameTypeDescription
ODUk_CP Interface
CI_DInputODUk Characteristic Information - Data Input:
The ODUk-client is expected to input the ODUk data via this input. This ODUk data will contain all portions of the ODUk frame.
CI_CKInputODUk Characteristic Information - Clock Input:
This clock signal will sample all data that the ODUk-client supplies to the CI_D, CI_FS, CI_MFS and CI_APS inputs.

The OTUk/ODUk_A_So function will also use this clock signal as its timing source.
CI_FSInputODUk Characteristic Information - Frame Start Input:
The ODUk-client equipment will drive this signal TRUE; coincident to whenever it is supplying the very first bit or byte (of a given OTUk frame) to the CI_D input.

The ODUk-client is expected to assert this signal once for each ODUk frame period.

The OTUk/ODUk_A_So function will also use this input signal to determine if it should declare the IAE condition, via the AI_IAE output pin.
CI_MFSInputODUk Characteristic Information - Multiframe Start Input:
The system-side equipment will drive this signal TRUE coincident to whenever it is supplying the very first bit or byte (of a given ODUk/OTUk Superframe) to the CI_D input.

The ODUk-client is expected to assert this signal once for each OTUk/ODUk superframe period, or once every 256 ODUk frame periods.
CI_APSInputODUk Characteristic Information - APS Channel Data:
The system-side equipment is expected to apply the APS Channel to this input.

The function user must set the MI_APS_En input to TRUE and must place a valid value (for APS Level) at the MI_APS_LVL input pins, or the OTUk/ODUk_A_So function will ignore the data at this input.

The OTUk/ODUk_A_So function will map this data into the APS/PCC channel within the ODUk data-stream.

Please see the blog post about the APS/PCC channel for more information.
OTUk_AP Interface
AI_DOutputOTUk Adapted Information - OTUk Data Output:
The OTUk/ODUk_A_So function will take all of the data (that the ODUk-client applies to both the CI_D and CI_APS input pin) and will combine this data together to form a bare-bones OTUk data-stream.

NOTE: This OTUk data will contain the following fields.
- Default OTUk SMOH data,
- The contents of the APS/PCC channel and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC fields. Additionally, the downstream OTUk_TT_So function will compute and generate the correct values for the OTUk-SMOH.
AI_CKOutputOTUk Adapted Information - Clock Output:
As the OTUk_AP Interface outputs data via the AI_D, AI_FS, AI_MFS and AI_IAE outputs; it will updata all of this data on one of the edges of this clock output signal.
AI_FSOutputOTUk Adapted Information - Frame Start Output:
The OTUk_AP Interface will pulse this output signal HIGH whenever the OTUk_AP Interface outputs the very first bit (or byte) of a new OTUk frame, via the AI_D output.

The OTUk_AP Interface will pulse this output HIGH once for each outbound OTUk frame.
AI_MFSOutputOTUk Adapted Information - Multiframe Start Output:
The OTUk_AP Interface will pulse this output signal HIGH whenever the OTUk_AP Interface outputs the very first bit (or byte) of a new OTUk superframe, via the AI_D output.

The OTUk_AP Interface will pulse this output HIGH once for each OTUk Superframe (or once each 256 OTUk frames).
AI_IAEOutputOTUk Adapted Information - Input Alignment Error Output:
The OTUk_AP Interface will drive this output signal HIGH whenever the OTUk/ODUk_A_So function detects a frame slip within the ODUk_CP Interface.

More specifically, if the OTUk/ODUk_A_So determines that the upstream equipment has pulses the CI_FS input at an unexpected CI_CK period, then this function will drive this output HIGH.

This function will keep this output signal HIGH until the OTUk/ODUk_A_So function starts to receive pulses at the CI_FS during the "expected" CI_CK periods again.

Once the OTUk/ODUk_A_So function starts to receive pulses at the CI_FS input (during the "expected" CI_CK period) then it will drive this output pin LOW.
OTUk/ODUk_A_So_MP Interface
MI_AdminStateInputManagement Interface - AdminState Input:
This input pin permits the user to configure the OTUk/ODUk_A_So function to operate in either the LOCKED State or the NORMAL state.

If the user configures this function to operate in the NORMAL state, then it will map NORMAL ODUk traffic (e.g., ODUk traffic that is carrying client-data) into an OTUk frame as it passes through this function.

Conversely, if the user configures this function to operate in the LOCKED state, then the function will generate and map the ODUk-LCK Maintenance signal into the outbound OTUk data-stream.
MI_APS_EnInputManagement Interface - APS Channel Enable Input:
This input pin permits the user to either enable or disable the OTUk/ODUk_A_So function to/from accessing the APS/PCC channel within the ODUk overhead.

Setting this input HIGH permits the OTUk/ODUk_A_So function to access (and send APS messages via) the APS/PCC channel.

Setting this input LOW prevents the OTUk/ODUk_A_So function from accessing (and sending APS messages) via the APS/PCC channel.
MI_APS_LVLInputManagement Interface - APS Level:
This input permits the user to specify the APS Level, that this OTUk/ODUk_A_So function can use when it accesses the APS/PCC channel.

NOTES:
1. This input is ignored if MI_APS_En = FALSE.
2. There are 8 possible valid inputs to this port.

Please see the blog post on the APS/PCC channel for more information about this topic.

Pin Description Table

Signal NameTypeDescription
OTUk_AP Interface
AI_DInputOTUk Adapted Interface - OTUk Data Input:
The function user is expected to apply a bare-bones OTUk signal (which is output from the AI_D output of the OTUk/ODUk_A_So function) to this input pin.

NOTE: This OTUk data will contain the following fields
- Default OTUk SMOH data,
- The contents of the APS/PCC channel and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC field. This function will compute, generate and insert the appropriate OTUk-SMOH into this OTUk data-stream

The OTUk_TT_So function will sample this input signal on one of the edges of the AI_CK input clock signal.
AI_CKInputOTUk Adapted Interface - Clock Input:
The OTUk_TT_So function will sample all data and signals (that the user applies to the OTUk_AP Interface) upon one of the edges of this input clock signal. This statement applies to the following signals: AI_D, AI_FS, AI_MFS and AI_IAE.

This clock signal will also function as the timing source for this function as well.
AI_FSInputOTUk Adapted Information - Frame Start Input:
The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP Interface accepts the very first bit (or byte) of a new OTUk frame, via the AI_D inputs.

The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk frame.
AI_MFSInputOTUk Adapted Information - Multiframe Start Output:
The upstream OTUk/ODUk_A_So function should pulse this input signal HIGH whenever the OTUk_AP interface accepts the very first bit (or byte) of a new OTUk superframe, via the AI_D input.

The upstream OTUk/ODUk_A_So function should drive this input HIGH once for each OTUk superframe.
AI_IAEInputOTUk Adapted Information - Input Alignment Error Input:
the OTUk/ODUk_A_So function (upstream from this function) will drive this input pin HIGH whenever it detects a frame-slip (or IAE event).

Anytime the OTUk_TT_So function detects this input pin, going from LOW to HIGH, then it should respond by setting the IAE bit-field to "1" for 16 consecutive Superframes (or 4096 consecutive OTUk frames).

Please see the blog on IAE for more information on this feature.
OTUk_CP Interface
CI_DOutputOTUk Characteristic Information - OTUk Data Output:
The OTUk_TT_So function will compute, generate and insert the SMOH (Section Monitoring Overhead) into the outbound OTUk data-stream. It will then output this OTUk data-stream via this output signal.

NOTE: This OTUk data will contain the following fields.
- The newly computed, inserted BIP-8 value
- The newly received and inserted BEI-nibble value or BIAE indicator.
- The newly received and inserted BDI bit-value.
- the newly received and inserted IAE value.
- The contents of the APS/PCC channel and
- The rest of the OTUk frame.

This OTUk data-stream will not include the FAS, MFAS or FEC field.

The OTUk_TT_So function will update this output signal on one of the edges of the CI_CK output clock signal.
CI_CKOutputOTUk Adapted Information - Clock Output:
The OTUk_TT_So function will output all data and signals (via the OTUk_CP interface) upon one of the edges of this output clock signal. This statement applies to the following signals: CI_D, CI_FS and CI_MFS.
CI_FSOutputOTUk Characteristic Information - Frame Start Output:
This function will drive this output pin HIGH whenever the OTUk_CP interface outputs the very first bit (or byte) of a new OTUk frame, via the CI_D output.

The OTUk_TT_So function should only pulse this output pin HIGH once for each outbound OTUk frame.
CI_MFSOutputOTUk Characteristic Information - Multiframe Start Output:
This function will drive this output pin HIGH whenever the OTUk _CP Interface outputs the very first bit (or byte) of a new OTUk Superframe via the CI_D.

The OTUk_TT_So function will drive this output pin HIGH once for each OTUk Superframe.
OTUk_TT_So_RP Interface
REI_BEIInputRemote Port Interface - BEI (Backward Error Indicator) Input:
The OTUk_TT_So function will accept one nibble of data (for each outbound OTUk frame) via this input signal and it will insert this data into the BEI/BIAE nibble-field within the Section Monitor field within each outbound OTUk frame.

The BEI value will reflect the number of BIP-8 errors that the collocated OTUk_TT_Sk function has detected and flagged within its most recently recevied and verified OTUk frame.

NOTE: If the OTUk_TT_So function receives a BIAE = 1 (via the RI_BIAE input) then it will overwrite the BEI/BIAE nibble-field with the value "1011" to denote a BIAE event.

Please see the BEI post for more information about Backward Error Indication.
RI_BIAEInputRemote Port Interface - BIAE (Backward Input Alignment Error) Input:
The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input signal and it will do either of the following, depending on the value of this single bit-field.

If BIAE = 0
Then the OTUk_TT_So function will write the BEI value that it has received via the RI_BEI input, into the BEI nibble-field within the Section Monitor byte of the next outbound OTUk frame.

If BIAE = 1
Then the OTUk_TT_So function will not write the BEI value (that it has received from the collocated OTUk_TT_Sk function). It will instead, write the value "1011" into the BEI/BIAE nibble-field, within the Section Monitor byte of the next outbound OTUk frame.
RI_BDIInputRemote Port Interface - Backward Defect Indicator Input:
The OTUk_TT_So function will accept one bit of data (for each outbound OTUk frame) via this input pin and it will write the contents of this value into the RDI bit-field (within the Section Monitor byte) of the next outbound OTUk frame.

If RI_BDI = 0
The the OTUk_TT_So function will set the BDI bit-field to "0" within the next outbound OTUk frame.

If RI_BDI = 1
Then the OTUk_TT_So function will set the BDI-bit-field to "1" within the next outbound OTUk frame.
OTUk_TT_So_MP Interface
MI_TxTIInputManagement Interface - Trail Trace Identifier Input:
The function user is expected to load in the 64-byte TTI Message into the OTUk_TT_So circuitry via this input. The OTUk_TT_So function will then transmit the message to the remote Network Element, one byte-at-a-time, over 64 consecutive outbound OTUk frames.

OTUk_TT_So Sources Table

Overhead FieldLocation within OTUk-SMOHSource of Data/How Derived?
BIP-8 ByteBIP-8 Byte within the Section Monitoring FieldThe OTUk_TT_So function locally computes the BIP-8 value based upon the contents within the OPUk portion of the OTUk frame.
IAE Bit-FieldThe IAE Bit-field within the Section Monitoring ByteBased upon the AI_IAE input to the function (at the OTUk_AP Interface)
BDI Bit-FieldThe BDI bit-field within the Section Monitoring byteBased upon the RI_BDI input to this function (at the Remote Port Interface).
BEI Nibble-FieldThe BEI/BIAE Nibble-field within the Section Monitoring ByteBased upon the RI_BEI and RI_BIAE inputs to this function (at the Remote Port Interface).
BIAE Nibble-FieldThe BEI/BIAE bit-fields within the Section Monitoring byte.Based upon the RI_BIAE and RI_BEI inputs to this function (at the Remote Port Interface).
TTI Byte-FieldTTI Byte within the Section Monitoring Field.The user is expected to load in the contents of the 64-byte Trace Identifier Message (TIM) into a buffer via the MI_TxTI input to this function.

The function will proceed to transmit the contents of this TIM, one byte at a time, via the TTI byte-field within each outbound OTUk Frame.

The OTUk_TT_So function will transport the entire TIM over 64 consecutive OTUk frames.