Patent Description:
The present disclosure generally relates to Forward Error Correction (FEC). More particularly, the present disclosure relates to systems and methods for OpenFEC error marking.

Ethernet interfaces have a Mean Time to False Packet Acceptance (MTTFPA) requirement of End of Life (EOL). Also, new Ethernet interfaces operate at a higher Bit Error Rate (BER) and make use of Forward Error Correction (FEC) decoding capabilities to mark appropriate datapath errors to guarantee and meet MTTFPA requirements. This is a known practice for Ethernet interfaces, and these interfaces (until now) have been using Hard Decision (HD) FEC decoders, so the approach is fairly straightforward. That is, HD FEC easily identifies error locations, simplifying error marking.

New Ethernet coherent interfaces use Soft Decision (SD) FEC decoders, and marking specific uncorrected errors is complicated and problematic. Currently, the only standard coherent Ethernet interface is 400ZR driven by the OIF. It uses a concatenated FEC (CFEC) approach, which provides moderate performance FEC. Error marking has been addressed with 400ZR. There is another coherent Ethernet interface referred to as OpenZR+ (available at www. openzrplus. org) and described in the OpenZR+ Specifications, v. <NUM>, <NUM> September <NUM>. OpenFEC is described in the Open ROADM MSA <NUM> W-Port Digital Specification (<NUM>-<NUM>) (available at www. org), June <NUM>, <NUM>, and it is referred to herein as the Open ROADM Specification. OpenZR+ utilizes OpenFEC (OFEC) for higher performance applications. The mappings utilize the Ethernet 257b Physical Coding Sublayer (PCS) encodings. Of note, there are no published schemes on OpenZR+ interfaces to meet MTTFPA requirements, i.e., to support error marking.

Flexible OTN (hereinafter referred to as FlexO) is defined, e.g., in<NPL>),<NPL>). FlexO includes a specific frame structure, which is the same as the 400ZR frame as defined in OIF-400ZR-<NUM>, March <NUM>, <NUM>. OpenROADM also includes a similar frame structure and OpenROADM is defined in the OpenROADM MSA ver. <NUM>, December <NUM>, <NUM>. As described herein, ZR is used to include the 400ZR, ZR+, OpenROADM, etc. specifications. That is, there are various coherent interface specifications being issued and worked on and all of them are contemplated herein.

The present disclosure relates to systems and methods for OpenFEC error marking. That is, the present disclosure enables error marking for OFEC that is used in ZR+, FlexO, etc. The present disclosure can be implemented in a coherent Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC), etc. The present disclosure provides a process for error marking to meet MTTFPA requirements for ZR+ and FlexO interfaces. It also can apply to any OFEC applications, such as described in the Open ROADM MSA <NUM>. Further, this approach can be extended to any FEC scheme that utilizes padding data where the padding data is then spread out with CRC data included therein for error marking.

The invention is defined by independent claims <NUM> and <NUM>.

In various embodiments, the present disclosure relates to systems and methods for OpenFEC error marking. That is, the present disclosure enables error marking for OFEC that is used in ZR+, FlexO, etc. The present disclosure can be implemented in a coherent Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC), etc. The present disclosure provides a process for error marking to meet MTTFPA requirements for ZR+ and FlexO interfaces. It also can apply to any OFEC applications, such as described in the Open ROADM MSA <NUM>. Further, this approach can be extended to any FEC scheme that utilizes padding data where the padding data is then spread out with CRC data included therein for error marking.

The following definitions are used herein from the OpenROADM MSA:.

The following definitions are used herein from G.

Of note, as described herein "FlexO" is meant to refer to any implementation with OpenFEC including OpenROADM, G. <NUM>, etc. Also, "ZR" is meant to refer to any implementation with OpenFEC from the OIF, e.g., 400ZR, 800ZR, etc. Of course, the approach described herein can be used with any implementation using OpenFEC.

OFEC includes a block-code-based encoder and iterative soft-decision-based decoder, such as with an overhead of <NUM>% and a Net Coding Gain (NCG) of <NUM> dB for Quadrature Phase Shift Keying (QSPK) and <NUM>. 6dB for <NUM>-Quadrature Amplitude Modulation (16QAM) after three soft-decision iterations, with pre-FEC BER threshold of ∼<NUM>×<NUM>-<NUM>.

Generally, the present disclosure includes taking padding bits that are associated with OFEC adaptation and distributing them across the payload and incorporating Cyclic Redundancy Check (CRC) data for integrity. That is, the present disclosure modifies the current standard documented OFEC adaptation procedures to provide support for error marking. The distributed Cyclic Redundancy Check (CRC) data is used to detect error locations during decoding process. Further, the distributed padding bits are not simply dummy data but CRC data. Having the padding bits distributed reduces buffering and latency for computing CRC since the block size is reduced. Further, the distributed padding enables more specific error marking, so only packets in-between CRC checks are required to be marked as errored, reducing error amplification. For example, a single CRC at the end in the OFEC adaptation could be used to detect and mark, but this would require marking all packets in the datapath, i.e., it is not localized. The distributed padding approach enables greater localization of error marking.

Thus, this disclosure presents a process of tweaking/modifying OFEC adaptation in a way to accommodate the insertion of CRC (checksums) for the purpose of error marking. The CRCs are checked in the FEC adaptation function (post-FEC decoding). It conveniently could also be used for FEC convergence and improve the FEC decoders. The process of FEC convergence is a check in a decoder that verifies the integrity of the data, and if errors are detected, the FEC decoder can continue with additional iterations. The process can be used for ZR+ interfaces as well as FlexO-xe (e.g., underclocked Ethernet optimized) interfaces that make use of OFEC for higher performance applications and direct Ethernet mapping.

The process may not be backward compatible with existing, standardized OFEC interfaces, but can be implemented for future <NUM>, <NUM> and <NUM> OFEC interfaces (e.g., 800ZR+ and FlexO-8e-DO). Also, the process may be used with existing OFEC interfaces in a proprietary implementation.

<FIG> is a block diagram of the functional flow of modified OFEC adaptation for error marking. Data is shown flowing from left-to-right, starting at a Digital Signal Processor (DSP), then FEC decoding, then adaptation, then FlexO/ZR, demapping, and Ethernet PCS coding. The modified OFEC adaptation detects a post-FEC error (CRC) and marks the data as bad. Then the Ethernet PCS will replace such bad data with /E/ error control blocks. This guarantees that any malformed packets (also matching packet CRC) will not be falsely accepted.

FlexO and ZR+ signals mapped to 16QAM (Quadrature Amplitude Modulation), 8QAM, and QPSK (Quadrature Phase Shift Keying) modes are using <NUM>, <NUM> and <NUM> rows, respectively, when mapping FlexO/ZR (payload) data into the OFEC adaptation. The common divisor is <NUM> (29x2, 29x3, 29x4). In an embodiment, the scheme in this disclosure distributes the OFEC adaptation padding across <NUM> FlexO/ZR frame rows evenly. This differs from the original OFEC adaptation procedures.

<FIG> are block diagrams of FlexO-<NUM> interfaces for describing OFEC adaptation. Specifically, <FIG> illustrates conventional OFEC adaptation with padding at the end. Specifically, the conventional OFEC adaptation is from Figure <NUM> of the OpenROADM Specification. <FIG> illustrates the modified OFEC adaptation, where the padding is distributed every <NUM> rows. <FIG> illustrates the modified OFEC adaptation, where the padding is distributed every <NUM> rows in an interleaved manner. <FIG> are diagrams of a frame <NUM> prior to OFEC adaptation.

Those skilled in the art will recognize the frame <NUM> for the FlexO-<NUM> interfaces in <FIG> are presented for illustration purposes, and the modified OFEC adaptation is applicable to other interfaces, such as <NUM>, <NUM>, and <NUM> (and beyond such as <NUM>) interfaces as well. For example, in an embodiment, this proposed scheme could keep the ratios of <NUM> padding bits per <NUM> columns consistent across all data rates. That is, the present disclosure can apply to other framing schemes including FlexO-<NUM>, FlexO-<NUM>, etc. as well as future schemes, e.g., FlexO-<NUM>, FlexO-<NUM>, etc..

For example, Table <NUM> in the OpenROADM Specification illustrates the OFEC adaptation rates as follows:.

Of note, there are enough PAD bits <NUM> to use CRC and to distribute the PAD bits <NUM> with CRC included therein for error marking in the payload area <NUM>. The following descriptions describe this approach with reference to FlexO-<NUM>, but those skilled in the art will recognize this is only for illustration purposes.

Again, <FIG> are the FlexO-<NUM> FlexO frame structure from the OpenROADM Specification. In each of <FIG>, there is an OFEC input block with the payload area <NUM> (<NUM>,<NUM>,<NUM> bits for FlexO-<NUM>). This data is processed in the OFEC adaptation, such as described in the OpenROADM Specification. Note, other sections are also adapted with OFEC, but there is no need to modify the padding in the non-payload area since the present disclosure is concerned with error marking in the payload area <NUM>. In <FIG>, the conventional OFEC adaptation includes adding <NUM> PAD bits <NUM> for padding at the end of the payload area <NUM> for the FlexO-<NUM>.

The PAD bits <NUM> are for aligning and synchronizing the FlexO/ZR frame <NUM> to an OFEC structure (e.g., see Section <NUM> in the Open ROADM Specification). The PAD bits <NUM> are appended to the Flex-O data to enable this alignment. Alignment is not necessarily associated with row boundaries as conveniently drawn. The PAD bits <NUM> are removed after the decoder on the receive interface. In a conventional embodiment, the PAD bits <NUM> are an all-zero field that gets scrambled prior to encoding and removed after decoding and descrambling.

That is, the OFEC adaptation uses some padding to make it work with FlexO/ZR multiples. But there is no ability for any error marking in current standards. Placing the CRC there as is defined today, as in <FIG>, the CRC would cover a large number of bits and require memory to store and delay the data so it can be marked (this can be cumbersome and adds latency and keeping link latency low is critical in many applications). Of note, while it looks like the PAD bits <NUM> are distributed in <FIG>, only a single set of PAD bits <NUM> are used for all of the payload area <NUM>. This does not provide fine enough granularity for error marking. At best, it could determine an error is in the payload area <NUM>, but this would require marking all data as errored.

The present disclosure distributes the padding across rows in the payload area <NUM>, making the CRC cover a smaller number of bits, requiring less memory and less latency, making it suitable for an error marking scheme. That is, instead of one set of PAD bits <NUM> for the entire payload area <NUM>, the present disclosure distributes this across different rows - resulting in the same amount of PAD bits, but distributed.

In <FIG>, the modified OFEC adaptation distributes these <NUM> PAD bits <NUM> as distributed PAD bits <NUM> into four sections of <NUM> bits, every <NUM> rows. Thus, the amount of padding is the same but distributed as the distributed PAD bits <NUM>. Also, the <NUM> bits can include <NUM>-bits of CRC data and <NUM>-bits of padding data. Thus, the <NUM>-bits of CRC data every <NUM> rows can be used to localize and mark errors. That is, the present disclosure does not use all-zeros for the PAD bits, but rather some CRC bits <NUM> and some PAD bits <NUM>, e.g., <NUM>-bits for the CRC bits <NUM> and <NUM>-bits for the PAD bits <NUM>. Note, CRC32 is just presented as an example, other values can be used. Also, other error checking schemes are also contemplated instead of CRC.

In <FIG>, it is convenient to draw <NUM> rows, but the process could also alternatively use <NUM> or <NUM> rows to reduce the block size and error amplification introduced with error marking (there are enough padding bits). Again, error amplification means having a lot of Ethernet frames marked as errored, triggered by a small number of post-FEC errors. With distributed padding and CRC, it is possible to mark significantly fewer frames. g <NUM>-bit CRCs are common but other values can be considered) is inserted in the padding bits and protects <NUM> bits (post-FEC) for marking purposes.

In <FIG>, an alternative approach could be to map two interleaved (even/odd) CRC32 per padding opportunity. The CRCs would protect their respective even/odd payload bits. OFEC is described as using two parallel decoders, again using even/odd bit interleaving. In this alternative approach, the two CRCs can feedback back to the two parallel decoders to assist in FEC convergence functions. As described herein, FEC convergence relates to iterations in SD FEC. With knowledge there are no errors, based on the CRC, the convergence can be improved and iterations reduced (resulting in a lower power FEC).

<FIG> is a flowchart of a process <NUM> for error marking using modified OFEC adaptation. The modified OFEC adaptation process contemplates implementation in a circuit, electrical circuitry, e.g., a DSP, FPGA, ASIC, etc. The process <NUM> is described with reference to a receiver that receives transmitted data and is performing FEC decoding. The modified OFEC adaptation allows error marking in the process <NUM>.

The process <NUM> includes receiving blocks of data that has been Forward Error Correction (FEC) encoded via Open Forward Error Correction (OFEC) adaptation (step <NUM>); decoding the blocks of data (step <NUM>); processing Cyclic Redundancy Check (CRC) data that is included in padding data required in the OFEC adaptation, wherein the padding data is distributed across N rows of payload data (step <NUM>); and determining a location of any errors in the payload data based on the processed CRC data (step <NUM>).

At the other end, prior to the receiving, the process <NUM> can include performing the OFEC adaptation and distributing the CRC data across the N rows with the padding data.

The process <NUM> can further include marking Ethernet blocks with an error code based on the location (step <NUM>). The process <NUM> can further include utilizing the CRC data to assist in FEC convergence (step <NUM>). Typical SD FEC schemes are based on iterative processes to correct errors. When payload data is clean and errors are no longer present, further iterations are not needed and dissipate power unnecessarily. A CRC can be used to check the integrity of the payload and stop the further iterations, which means the FEC has converged. The CRC proposed herein can be used for such purpose as well as error marking.

The padding data can include M bits that are spread across the N FlexO/ZR frame rows thereby having M/N padding bits for each distributed location, and wherein the M/N padding bits include X CRC bits and Y pad bits. For example, for FlexO-<NUM>, M = <NUM>, for FlexO-<NUM>, M = <NUM>, and for FlexO-<NUM>, M = <NUM>.

The N rows can include any of <NUM> rows, <NUM> rows, and <NUM> rows. For <NUM> rows and <NUM> rows, this means the distributed padding data is included in the middle of a row (for <NUM> rows) and at a quarter of the row (for <NUM> rows). The CRC data can be utilized in an interleaved manner, such as illustrated in <FIG>. Here, there are two CRC codes - one covering even bits and the other odd bits in an interleaved manner. The two CRCs can be placed in the padding. Since OFEC uses two decoders, again in an even/odd bit interleaved scheme, the interleaved CRCs can be used for FEC convergence, as described above.

The OFEC adaptation can be for mapping the blocks of data into any of a FlexO frame structure, a ZR frame structure, and variants thereof. The OFEC adaptation can include a plurality of modes includes a <NUM>-Quadrature Amplitude Modulation (<NUM>-QAM) mode, an <NUM>-QAM mode, and a Quadrature Phase Shift Keying (QPSK) mode using <NUM>, <NUM>, and <NUM> rows, respectively, in the payload data. The padding data can be distributed across <NUM> rows for each of the plurality of modes.

The frame <NUM> in <FIG> is the FlexO-x-oFEC from the OpenROADM MSA. The same approach described herein with the frame from G. That is, the present disclosure can utilize any frame structure utilizing OpenFEC, including FlexO-x-oFEC, FlexO-x-DO, and any other frame structure including 800ZR. With the frame <NUM>, the CRC or checksum can be distributed in the PAD data in the frame from G.

The distribution of CRC data is useful for error marking, FEC convergence, uncorrectable error verification. The logical place is to put this CRC in adaptation padding and the padding could be distributed (instead of lumped) to minimize error marking window. For example, with 800ZR, <NUM>-bit CRC at the end of every <NUM> rows, <NUM> that would result in <NUM> CRC values, Error mark blocks of <NUM>,<NUM> bits.

It will be appreciated that some embodiments described herein may include or utilize one or more generic or specialized processors ("one or more processors") such as microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs): customized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs), or the like; Field-Programmable Gate Arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more Application-Specific Integrated Circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as "circuitry configured to," "logic configured to," etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.

Moreover, some embodiments may include a non-transitory computer-readable medium having instructions stored thereon for programming a computer, server, appliance, device, one or more processors, circuit, etc. to perform functions as described and claimed herein. Examples of such non-transitory computer-readable medium include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by one or more processors (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause the one or more processors to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

Claim 1:
A method (<NUM>) comprising steps of:
receiving (<NUM>) blocks of data that has been Forward Error Correction, FEC, encoded via Open Forward Error Correction, OFEC, adaptation;
decoding (<NUM>) the blocks of data;
processing (<NUM>) checksum data that is included in padding data required in the OFEC adaptation, wherein the padding data including said checksum data is distributed throughout a payload area (<NUM>) corresponding to an OFEC input block, the payload area (<NUM>) comprising rows of payload data with the checksum data distributed every N rows of the payload area, the checksum data for any of specific error marking of less than the entire payload area (<NUM>),
determining (<NUM>) a location of any errors in the payload data corresponding to associated payload data in-between the processed checksum data, based on the processed checksum data.