What is the OMFI (OPU Multi-Frame Indicator) Field?
OMFI is an acronym for “OPU Multi-Frame Indicator.”
We use the OMFI field whenever we are mapping/multiplexing numerous lower-speed ODUj tributary signals into an OPU4 server signal (where j ranges from 0 through 3 and can include flex or 2e).
Whenever we are mapping/multiplexing these lower-speed ODUj tributary signals into an OPU4 server signal, we will do so on an 80 OPU4 frame Superframe basis.
As we map and multiplex these lower-speed ODUj tributary signals into an OPU4 signal, we will create as many as 80 sets of GMP Mapping Parameter for each Superframe.
At the Source PTE (Path Terminating Equipment), the ODUj to OPU4 Mapper Circuit will insert each of these 80 sets of GMP Mapping Parameters into the Overhead Fields of the 80 consecutive OPU4 frames within each Superframe.
The payload portions of each of these OPU4 frames will contain multiplexed ODTU4.ts data (e.g., ODTU4.1, ODTU4.2, ODTU4.8, ODTU4.31 or ODTU4.ts data-streams).
The Source PTE will then transmit these OPU4 frames to the Sink PTE (at the other end of the path).
At the Sink PTE, the OPU4 to ODUj De-Mapper circuit is going to need to know which set of GMP Parameter data pertains to which ODTU4.ts data-stream, to properly de-map out these ODUj tributary signals from these ODTU4.ts signals, within the incoming OPU4 signal.
The de-mapper will use the OMFI field (within each OPU4 frame) to figure this out.
We will explain this concept in greater detail later on in this blog.
Where is the OMFI field located?
If we are dealing with an OPU4 frame, then the OMFI field will reside within the OPU4 Overhead in Row # 4 and Column Byte # 16.
Figure 1 shows a drawing of an OPU4 frame in which we highlight the location of the OMFI field.
Figure 1, Location of the OMFI field within the OPU4 Frame
The OMFI field does not exist in OPUk frames for any other rates. The OMFI field only exists within the OPU4 frame.
In other words, OPUflex, OPU0, OPU1, OPU2, OPU2e, and OPU3 frames will NOT have an OMFI field.
When would we use the OMFI field?
We will only use the OMFI field if we are mapping/multiplexing some lower-speed ODUj tributary signals into an OPU4 server signal.
In other words, we would use the OMFI field if we wish to perform any of the following mapping/multiplexing operations:
- 80 ODU0 signals into an OPU4
- 40 ODU1 signals into an OPU4
- 10 ODU2 (or ODU2e) signals into an OPU4
- 2 ODU3 signals into an OPU4
- Various combinations of rates/number of ODUflex signals into an OPU4 server signal
Further, we can also use the OMFI field if we are mapping/mapping multiple combinations of rates of ODUflex signals along with the appropriate number of other ODUj tributary signals, (where j can be 0, 1, 2/2e or 3) into an OPU4 server signal.
NOTE: We do NOT use the OMFI field if we are mapping some non-OTN client signals (such as 100GbE/100GBASE-R) into an OPU4 signal.
So What does the OMFI field do?
The OMFI field is a byte-wide counter that counts from 0 to 79 and then overflows back to 0, repeatedly.
More specifically, a piece of OTN Network Equipment (e.g., the Source PTE) will (at some point) transmit an OPU4 frame with the OMFI field set to the value “0x00”.
When the Source PTE transmits the very next OPU4 frame, it will then set its OMFI byte-field to 0x01. The Source PTE will proceed to increment the value that it writes into the OMFI byte-field within each OPU4 frame that it generates and transmits
Eventually, the Source PTE will transmit an OPU4 frame with the OMFI field set to the value 0x4F (which is the number 79 in decimal format).
Afterward, when the Source PTE transmits the very next OPU4 frame, it will then set this field back to 0x00, and it will continue to send another set of 80 consecutive OPU4 frames, in this manner, repeatedly.
This means that the OTN network can (and does) use the OMFI field to group 80 consecutive OPU4 frames into an OPU4 Superframe.
We will discuss these OPU4 Superframes later on in this post.
Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!
Corporate Discounts Available!!!
Why can’t we use the MFAS field for OPU4 Applications?
This is a good question.
The MFAS field (like the OMFI field) is a byte-wide counter. The behavior and function of these two bytes are very similar.
NOTE: Please see the OTUk Post for more information about the MFAS field.
The Source STE increments the value within the MFAS byte as it transmits each new OTUk frame.
However, the OMFI byte-field only counts from 0 to 79, and then it overflows back to 0 and then repeats the process.
The MFAS byte counts from 0 to 255 and then overflows back to 0 and then repeats the process, indefinitely.
The MFAS field is convenient for grouping 256 consecutive OTUk/ODUk/OPUk frames into a 256-frame Superframe.
It is also suitable for grouping 4, 8, 16, and 32 consecutive OPUk frames in smaller Superframes.
NOTE: We use the MFAS byte whenever we are mapping/multiplexing lower-speed ODUj tributary signals into OPU1, OPU2 or OPU3 server signals.
In short, the MFAS is great for grouping OPUk frames into Superframes with sizes of 2n consecutive OPUk frames (e.g., 22 = 4, 23 = 8, 24 = 16, 25 = 32, and so on).
However, there is no integer value for n (within the expression 2n) that will give you a value of 80.
Thus, if I want to group 80 OPU4 frames into an OPU4 Superframe, the MFAS byte is useless for that purpose.
We need a different byte for this role. This is why we have the OMFI byte-field.
Would we use the OMFI field if we are using the AMP (Asynchronous Mapping Procedure)?
In a word “No.”
Whenever we are mapping client signals into an OPU4 signal, we will ONLY use the GMP (Generic Mapping Procedure).
We don’t ever use AMP to map client signals into an OPU4 payload. This is NOT allowed per ITU-T G.709.
NOTE: This statement is true, whether we are mapping non-OTN client data (such as 100GBASE-R) or lower-speed ODUj tributary signals into an OPU4 signal.
To be clear, we can use AMP to map client signals into OPU1, OPU2, and OPU3 signals, but not into an OPU4 signal.
This is a good trick question, however.
I say this is a trick question because if we were using AMP to map client data into an OPUk frame, then the NJO (Negative Justification Opportunity) byte would occupy the very same byte-position that the OMFI field occupies for OPU4 applications.
NOTE: Please see the AMP (Asynchronous Mapping Procedure) post for more information on the NJO byte.
How do we use the OMFI field in a system application?
Let’s assume that we wish to map and multiplex 80 ODU0 tributary signals into an OPU4 server signal.
If we want to do this, ITU-T G.709 states that we should perform this mapping/multiplexing in a five-step process.
- Convert each ODU0 signal into an Extended ODU0 signal.
- Use GMP to map each of the 80 ODU0 signals into their ODTU4.1 structure/signal. This step will create 80 ODTU4.1 signals.
- Byte interleaves all 80 of these ODTU4.1 signals together into a single data-stream.
- Load this byte-interleaved ODTU4.1 data into the OPU4 payload within each outbound OPU4 frame.
- Load the GMP mapping parameters into the OPU4 overhead.
Please see the Extended ODUj Post for more details on the Extended ODU0 signal.
What is an ODTU4.1 Frame/Signal?
The standards define the ODTU4.1 as Optical Data Tributary Unit (for an OPU4/ODU4 server signal) with 1 (one) Time-Slot.
For this post, I will state that the ODTU4.1 structure/signal is an intermediate frame/signal (that we’ve defined in ITU-T G.709).
We only use this frame/signal whenever we are mapping/multiplexing ODU0 tributary signals into an OPU4 signal.
We present a more thorough description of the ODTU4.1 structure in another post.
Figure 2 shows a drawing of a Mapper Circuit that performs this two-step Mapping/Multiplexing Process.
Figure 2, Illustration of an 80 ODU0 Signal to OPU4 Mapper Circuit
Whenever we GMP map a given ODU0 signal into an ODTU4.1 structure, the Mapper circuit will compute the resulting GMP parameters for this single mapping operation.
What’s the Deal with the Number 80?
Since we individually map each of the 80 ODU0 signals into their ODTU4.1 structure, and since each of the 80 ODU0 signals CAN be asynchronous to the remaining 79 ODU0 signals, there will be 80 unique sets of GMP mapping parameters within this OPU4 signal.
The ODU0 to OPU4 Mapper circuit will need to insert each of these 80 sets of GMP parameters into the OPU4 data-stream, to provide the OPU4 to ODU0 De-Mapper circuit (at the remote Sink PTE) with the GMP Justification Control information that it needs to be able to properly de-map out each of the ODU0 signals from their ODTU4.1 signal.
Stuck at Home? You Can Be an Expert at OTN Before You Return to Your Office!!! Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!!
So, where does the Mapper Circuit insert the GMP parameters (for all 80 ODU0s) into the OPU4 Frame?
I earlier mentioned that whenever we are mapping lower-speed ODUj tributary signals into an OPU4 signal, we execute this procedure by creating an 80 OPU4 frame Superframe.
In other words, as we map and multiplex these 80 ODU0 signals into the OPU4 signal, we will also create these 80 OPU4 frame Superframes.
In the OPU Post, I stated that each OPUk frame consists of an OPUk Payload and OPUk Overhead.
Thus, an 80 OPU4 frame Superframe will contain 80 sets of OPU4 payload, and it will also include 80 sets of OPU4 overhead.
Please note that the fact each of these OPU4 Superframe contains 80 frames and we are trying to map 80 ODU0s into an OPU4 is NOT a coincidence.
This was all done by design.
ITU-T G.709 states that an ODU0 to OPU4 Mapper circuit should insert the GMP parameters (that we obtained when we GMP mapped ODU0 # 1 into its ODTU4.1 frame/signal) into the JC1 through JC6 bytes within the Overhead of OPU4 Frame # 1 (within the 80 OPU4 Frame Superframe).
Likewise, the standard also states that the Mapper should insert the GMP parameters (that we obtained when we GMP mapped ODU0 # 2 into its ODTU4.1 frame/signal) into the JC1 through JC6 bytes within the Overhead of OPU4 Frame # 2.
This process should continue, all the way to OPU4 Frame # 80.
At this point, the ODU0 to OPU4 Mapper circuit has completed its transmission of an 80 OPU4 Frame Superframe, and it should start transmitting a new Superframe, by sending OPU4 Frame # 1 again (and so on).
But How Do We Know Which OPU4 Frame is OPU4 Frame # 1, # 2, and so on?
The short answer is the contents of the OMFI byte of each of these OPU4 frames.
Whenever the OMFI byte (within a given OPU4 frame) is set to “0x00”, then we can state that this particular OPU4 Frame is the first frame in the 80 frame Superframe.
Hence, we can designate this frame as being OPU4 Frame # 1.
Likewise, whenever the OMFI byte (within a given OPU4 frame) is set to “0x01”, then we can state that this particular OPU4 frame is the second frame in the 80 frame Superframe.
Thus, we can designate this frame as being OPU4 Frame # 2, and so on.
We Use the OMFI Byte to Identify Each of these 80 OPU4 frames
Therefore, if the Sink PTE (at the remote end) receives an OPU4 frame, in which OMFI byte is set to “0x00”, then we know the following things about the overhead data within that frame. We know that the data (within the JC1 through JC6 bytes) will contain the GMP parameter data that we obtained when the Source PTE mapped ODU0 # 1 into its ODTU4.1 frame/signal.
Likewise, if the Sink PTE receives an OPU4 frame, in which the OMFI byte is set to “0x01”, then we know the following about the overhead data within this frame. We know that the data (within the JC1 through JC6 bytes) will contain the GMP parameter data that we obtained when the Source PTE mapped ODU0 # 2 into its ODTU4.1 frame/signal.
And so on, for the remaining 78 frames within this OPU4 frame Superframe.
Figure 3 presents an abbreviated drawing of an 80 OPU4 Frame Superframe.
This figure also shows some useful information about the contents of the Overhead data within each of the OPU4 frames.
More specifically, this drawing also identifies which ODU0 to ODTU4.1 frame GMP mapping operation that these overhead fields pertain to, within each OPU4 frame.
Figure 3, Illustration of an 80 OPU4 Frame Superframe
For example, for OPU4 Frame 1, there is some red text that states the following: “GMP Mapping Data associated with ODTU4.1/ODU0 # 1″.
This text means that the six Justification Control bytes (e.g., the JC1 through JC6 byte – in the Pink Fields) contain the GMP mapping parameters that the Source PTE generated when it GMP mapped ODU0 # 1 into ODT4.1 signal # 1.
This is handy information for the Sink PTE.
So what does the De-Mapper Circuit do?
As the De-Mapper circuit (within the remote Sink PTE) receives and processes these OPU4 frames, it will need to execute the following two-step procedure to properly de-map and recover these ODU0 tributary signals from this incoming OPU4 data-stream.
- Byte de-interleave the OPU4 payload data into 80 parallel streams of these ODTU4.1 signals.
- Use GMP to de-map each ODU0 signal from their ODTU4.1 signal (e.g., de-map 80 ODU0 signals out of 80 ODTU4.1 signals)
I show an illustration of an OPU4 to 80 Channel ODU0 De-Mapper circuit, below in Figure 4.
Figure 4, Drawing of an OPU4 to 80 Channel ODU0 De-Mapper Circuit
De-Mapping the ODU0 Signal from Each ODTU4.1 Signal
However, for the de-mapper circuit (within the Sink PTE) to be able to do this successfully, it will need to have the correct GMP mapping parameters, that the Source PTE created at the remote-end.
In other words, for the Sink PTE to de-map out ODU0 # 1 from ODTU4.1 signal # 1, it will need to have the same GMP mapping parameters that the Source PTE (at the remote end) generated, when it mapped ODU0 # 1 into ODTU4.1 signal # 1, in the first place.
Likewise, for the Sink PTE to de-map out ODU0 # 2 from ODTU4.1 signal # 2, it will need to have the same GMP mapping parameters that the Source PTE (again, at the remote end) generated when it mapped ODU0 # 2 into ODTU4.2 signal # 2.
The Sink PTE will be receiving 80 sets of GMP mapping parameters, within each 80 Frame OPU4 Superframe.
How does the Sink PTE know which (of the 80) GMP mapping parameters to use to de-map out ODU0 # 1 from ODTU4.1 signal # 1?
Answer: It needs to use the overhead data within the OPU4 frame, in which the OMFI byte is set to 0x00.
Thus, the de-mapper circuit will need to rely on the OMFI value to keep all of this information straight.
In other words, the Sink PTE will use the OMFI byte, to properly marry-up each of the 80 GMP mapping parameters (within the incoming OPU4 data-stream) with 80 ODTU4.1 data-streams.
Hence, by using the OMFI byte, the Sink PTE will be able to correctly de-map out all 80 ODU0 signals from each of their ODTU4.1 signals, that we extract from the incoming OPU4 data-stream.
Does ITU-T G.798 Define any Defects that Pertain to the OMFI field?
Yes, ITU-T G.798 does define the dLOOMFI (Loss of OMFI Synchronization) defect for applications in which we are mapping and multiplexing lower-speed ODUj signals into an OPU4/ODU4 signal.
Summary and Other Related Postings
This post describes what the OMFI field (within the OPUk frame) is, and how we use it whenever we are mapping and multiplexing 80 ODU0 signals into an OPU4/ODU4 signal? We have similar postings (on the OMFI field) for the following cases as well.
- The ODU1 Case – Use of OMFI when mapping/multiplexing 40 ODU1 tributary signals into an OPU4/ODU4 signal.
- The ODU2 or ODU2e Case – Use of the OMFI field when mapping/multiplexing 10 ODU2/2e tributary signals into an OPU4/ODU4 signal.
- The ODU3 Case – Use of the OMFI field when mapping/multiplexing 2 ODU3 tributary signals into an OPU4/ODU4 signal.
- The ODUflex Case – Use of the OMFI field when mapping/multiplexing multiple ODUflex tributary signals into an OPU4/ODU4 signal