Patent Description:
It should be understood at the outset that, although illustrative implementations of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims.

<FIG> is a schematic diagram of a PON <NUM>. The PON <NUM> may be suitable for implementing the disclosed embodiments. The PON <NUM> may comprise an OLT <NUM> located in a CO <NUM>, ONUs<NUM>-n <NUM><NUM>-n located at the customers' premises, and an ODN <NUM> that couples the OLT <NUM> to the ONUs<NUM>-n <NUM><NUM>-n. N may be any positive integer. The PON <NUM> may provide wavelength-division multiplexing (WDM) capability by associating a downstream wavelength and an upstream wavelength with each OLT port<NUM>-n <NUM><NUM>-n so that a plurality of wavelengths is present, then combining those wavelengths into a single optical fiber cable <NUM> via a wavelength multiplexer/demultiplexer (WM) <NUM> and distributing the wavelengths to the ONUs<NUM>-n <NUM><NUM>-n through an RN <NUM>. The PON <NUM> may provide TDM as well.

The PON <NUM> may be a communications network that does not require any active components to distribute data between the OLT <NUM> and the ONUs<NUM>-n <NUM><NUM>-n. Instead, the PON <NUM> may use passive optical components in the ODN <NUM> to distribute data between the OLT <NUM> and the ONUs<NUM>-n <NUM><NUM>-n. The PON <NUM> may adhere to any standard related to multiple-wavelength PONs.

The CO <NUM> may be a physical building and may comprise servers and other backbone equipment designed to service a geographical area with data transfer capability. The CO <NUM> may comprise the OLT <NUM>, as well as additional OLTs. If multiple OLTs are present, then any suitable access scheme may be used among them.

The OLT <NUM> may comprise the OLT ports<NUM>-n <NUM><NUM>-n and the WM <NUM>. The OLT <NUM> may be any device suitable for communicating with the ONUs<NUM>-n <NUM><NUM>-n and another network. Specifically, the OLT <NUM> may act as an intermediary between the other network and the ONUs<NUM>-n <NUM><NUM>-n. For instance, the OLT <NUM> may forward data received from the network to the ONUs<NUM>-n <NUM><NUM>-n and may forward data received from the ONUs<NUM>-n <NUM><NUM>-n to the other network. When the other network uses a network protocol that differs from the PON protocol used in the PON <NUM>, the OLT <NUM> may comprise a converter that converts the network protocol to the PON protocol. The OLT <NUM> converter may also convert the PON protocol into the network protocol. Though the OLT <NUM> is shown as being located at the CO <NUM>, the OLT <NUM> may be located at other locations as well.

The OLT ports<NUM>-n <NUM><NUM>-n may be any ports suitable for transmitting waves to and receiving waves from the WM <NUM>. For instance, the OLT ports<NUM>-n <NUM><NUM>-n may comprise laser transmitters to transmit waves and photodiodes to receive waves, or the OLT ports<NUM>-n <NUM><NUM>-n may be connected to such transmitters and photodiodes. The OLT ports<NUM>-n <NUM><NUM>-n may transmit and receive waves in any suitable wavelength bands.

The WM <NUM> may be any suitable wavelength multiplexer/demultiplexer such as an arrayed waveguide grating (AWG). The WM <NUM> may multiplex the waves received from the OLT ports<NUM>-n <NUM><NUM>-n, then forward the combined waves to the RN <NUM> via the optical fiber cable <NUM>. The WM <NUM> may also demultiplex the waves received from the RN <NUM> via the optical fiber cable <NUM>.

The RN <NUM> may be any component positioned within the ODN <NUM> that provides partial reflectivity, polarization rotation, and WDM capability. For example, the RN <NUM> may comprise a WM similar to the WM <NUM>. The RN <NUM> may exist closer to the ONUs<NUM>-n <NUM><NUM>-n than to the CO <NUM>, for instance at the end of a road where multiple customers reside, but the RN <NUM> may also exist at any suitable point in the ODN <NUM> between the ONUs<NUM>-n <NUM><NUM>-n and the CO <NUM>.

The ODN <NUM> may be any suitable data distribution network, which may comprise optical fiber cables such as the optical fiber cable <NUM>, couplers, splitters, distributors, or other equipment. The optical fiber cables, couplers, splitters, distributors, or other equipment may be passive optical components and therefore not require any power to distribute data signals between the OLT <NUM> and the ONUs<NUM>-n <NUM><NUM>-n. Alternatively, the ODN <NUM> may comprise one or more active components such as optical amplifiers or a splitter. The ODN <NUM> may typically extend from the OLT <NUM> to the ONUs<NUM>-n <NUM><NUM>-n in a branching configuration as shown, but the ODN <NUM> may be configured in any suitable P2MP configuration.

The ONUs<NUM>-n <NUM><NUM>-n may comprise laser transmitters to transmit waves and photodiodes to receive waves. The ONUs<NUM>-n <NUM><NUM>-n may be any devices suitable for communicating with the OLT <NUM> and customers. Specifically, the ONUs<NUM>-n <NUM><NUM>-n may act as intermediaries between the OLT <NUM> and the customers. For instance, the ONUs<NUM>-n <NUM><NUM>-n may forward data received from the OLT <NUM> to the customers and forward data received from the customers to the OLT <NUM>. The ONUs<NUM>-n <NUM><NUM>-n may be similar to optical network terminals (ONTs), so the terms may be used interchangeably. The ONUs<NUM>-n <NUM><NUM>-n may typically be located at distributed locations such as the customer premises, but may be located at other suitable locations as well.

An EPON is an emerging access network that provides low-cost methods of deploying optical access lines between a CO and customers' premises. EPONs seek to bring forth a full-service access network that delivers data, video, and voice over a single optical access system. Optional FEC methods are used to improve communication reliability in error-prone environments like EPONs. In an FEC process, an EPON frame may be encapsulated into an FEC frame carrying parity and other FEC bits. Use of FEC results in an increased link budget, which enables higher bit rates, longer optical terminal to optical network unit distances, and higher split ratios for a single PON.

Institute of Electrical and Electronics Engineers (IEEE) <NUM>-<NUM>, Section Four, which is incorporated by reference, discusses 64B/66B in clause <NUM>. 64B/66B is a line code that transforms <NUM>-bit data to <NUM>-bit line code to provide enough state changes to allow reasonable clock recovery and facilitate alignment of a data stream at a receiver. 64B/66B provides for the transmission of Ethernet frames using <NUM>-bit blocks. Each block contains a <NUM>-bit payload and a <NUM>-bit sync header. For some applications, the transmission of <NUM> gigabit/second (Gb/s) Ethernet-formatted data requires additional features that are not provided in the basic format. Two such features are the inclusion of FEC and low-level OAM information.

There are two standardized methods to add FEC to 64B/66B data. The first method adds a small amount of error tolerance and is described in clause <NUM> of IEEE <NUM>-<NUM>, Section Five, which is incorporated by reference. The second method adds a large amount of error tolerance and is described in clause <NUM> of IEEE <NUM>-<NUM>, Section Five, as well as <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; and <CIT>, which are incorporated by reference. The second method is the most relevant FEC method for optical transmission systems.

<FIG> is an illustration of a mechanism <NUM> for providing FEC with 64b/66b data which may be used in conjunction with the inclusion of OAM information as described further below. The mechanism <NUM> shows how the second method described above adds FEC through the generation of parity blocks and the insertion of the parity blocks into a codeword <NUM> including both the payload data and the parity blocks. Specifically, for every <NUM> payload blocks <NUM>, <NUM> parity blocks are added, as described further below. Each of the <NUM> payload blocks comprises a <NUM>-bit payload and a two-bit payload block sync header loaded into each payload block. Thus, the first payload block <NUM> of the <NUM> payload blocks <NUM> comprises a <NUM>-bit payload <NUM> and a two-bit payload block sync header <NUM>, having the value "<NUM>" by way of example. Similarly, the second payload block <NUM> includes a <NUM>-bit payload <NUM> and a two-bit payload block sync header <NUM> containing the value "<NUM>" by way of example, and the twenty-seventh payload block <NUM> comprises a <NUM>-bit payload <NUM> and a payload block sync header <NUM> containing the value "<NUM>". The values of the payload block sync headers are examples, and may change depending on the type of the payload in the corresponding payload block.

The FEC is based on a Reed-Solomon code comprising <NUM> parity bytes, and <NUM> data bytes. This Reed-Solomon code is referred to as an RS(<NUM>, <NUM>) code. Thus, to provide the <NUM> data bytes to a Reed-Solomon encoder, the <NUM> payload blocks <NUM> are mapped onto a codeword payload <NUM> comprising <NUM><NUM>-bit blocks. Each of the <NUM>-bit blocks may comprise a <NUM>-bit header derived from a corresponding payload block sync header and the <NUM>-bit payload. For example, the first <NUM>-bit block <NUM> comprises a <NUM>-bit payload <NUM> and a header <NUM> containing the value "<NUM>" corresponding to the least significant bit (LSB) of the payload block sync header <NUM>, the second <NUM>-bit block <NUM> may comprise a <NUM>-bit payload <NUM> and a header <NUM> containing the value "<NUM>" corresponding to the LSB of payload block sync header <NUM>, and the <NUM>th <NUM>-bit block <NUM> comprises a <NUM>-bit payload <NUM> and a <NUM>-bit header <NUM> containing the value "<NUM>" corresponding to the payload block sync header <NUM>. The values contained in the <NUM>-bit headers are examples and may change with changes in values of the payload block sync headers, such as payload block sync headers <NUM>, <NUM>, <NUM>. The twenty-seven <NUM>-bit blocks encompass a total of <NUM> bits, leaving <NUM> padding bits <NUM> to pad out a total of <NUM> bytes. The padding bits <NUM> in codeword payload <NUM> may be padded stuffed with zeros for example. Alternatively, the padding bits <NUM> may be used to encode OAM data as described further below in conjunction with <FIG>.

The twenty-seven <NUM>-bit blocks <NUM> and the <NUM> padding bits <NUM> are input to a RS(<NUM>, <NUM>) encoder <NUM> as indicated by the path <NUM>. The RS(<NUM>, <NUM>) encoder <NUM> outputs four <NUM>-bit parity blocks <NUM>, <NUM>, <NUM>, and <NUM>. Thus, the four parity blocks <NUM>, <NUM>, <NUM>, <NUM> are calculated based on the twenty-seven <NUM>-bit blocks <NUM> and the <NUM> padding bits <NUM>. The group of <NUM> blocks <NUM> then is mapped to a FEC codeword <NUM> which includes the group of <NUM> blocks <NUM> and four parity sync headers <NUM>, <NUM>, <NUM>, and <NUM>. To decode the codeword, a receiver needs to find the start and end of the codeword. This is accomplished by marking the parity blocks <NUM>, <NUM>, <NUM>, and <NUM> with a special pattern for the parity sync headers <NUM>, <NUM>, <NUM>, <NUM>. Those parity sync headers <NUM>, <NUM>, <NUM>, <NUM> comprise two bits, and are different from the payload block sync headers <NUM>, <NUM>, <NUM> because the parity sync headers <NUM>, <NUM>, <NUM>, <NUM> have a specific pattern, namely <NUM>, <NUM>, <NUM>, <NUM>. This distinction makes it simple for the receiver to determine the codeword alignment and decode the data.

The padding bits <NUM> are not transmitted over the link. Thus, if one or more of these bits were used to transmit OAM data, the receiver would have an incomplete codeword, which would contain the <NUM> payload blocks <NUM> and the <NUM> parity blocks <NUM>, <NUM>, <NUM>, <NUM>, but not the OAM data. This OAM data can be considered an "erasure" of the channel - that is, data that is known to be lost. The receiver can use the FEC algorithm to deduce the OAM data that is missing. However, doing so takes away from some of the error correcting capacity of the system. Thus, there remains a need for carrying OAM information in <NUM>-bit systems that does not diminish the error correcting capacity of the system.

Disclosed herein are embodiments for carrying OAM information in <NUM>-bit systems. Specifically, a single OAM bit is sent in every FEC codeword. The OAM bit may be used to determine the FEC block sync-header patterns. The disclosed embodiments are described in the context of the FEC mechanism described in clause <NUM>, but the disclosed embodiments apply to any coded systems with sync-header patterns.

When sending OAM information, it may be desirable to keep the code format as close as practicable to the standardized format. Thus, in at least some embodiments, the amount of OAM information transmitted in a single codeword may be minimized. The smallest amount of OAM information would be <NUM> bit per FEC codeword. The sync headers are adapted for sending the OAM information, thus preserving the actively used payload bits and parity bits. In particular, as described above, in the FEC codeword, the sync headers have a fixed bit pattern. To incorporate OAM information, the encoding rule for the parity sync headers is changed to include two predetermined bit patterns. The <NUM> bit of OAM information can be used to determine which of the two bit patterns should be transmitted. One of the bit patterns is the existing pattern, <NUM>, <NUM>, <NUM>, <NUM>, and the other bit pattern is the complement, <NUM>, <NUM>, <NUM>, <NUM>. The bit patterns have <NUM> bits.

Using two bit patterns roughly doubles the chances of seeing a false sync-header pattern. However, the functioning of the receiver synchronization state machine already results in a very low probability of false alignment. The mean time to false lock is measured in millions of years. This small impact is therefore tolerable.

<FIG> is an illustration of a mechanism <NUM> for adapting an FEC codeword like the codeword <NUM> to include OAM information according to an embodiment of the disclosure. The mechanism may be implemented, for example, by a network device as shown in <FIG> described below. As in <FIG>, each of the <NUM> payload blocks <NUM> comprises a <NUM>-bit payload block <NUM>, <NUM>, <NUM> and a two-bit payload block sync header <NUM>, <NUM>, <NUM> loaded into each block. As described above, the FEC is based on a Reed-Solomon code comprising <NUM> parity bytes and <NUM> data bytes. This Reed-Solomon code is referred to as an RS(<NUM>, <NUM>) code. To provide the <NUM> data bytes to a Reed-Solomon encoder <NUM>, the <NUM> payload blocks <NUM> are mapped onto a codeword payload <NUM> comprising <NUM><NUM>-bit blocks. Similarly to <FIG>, each of the <NUM>-bit blocks comprises a <NUM>-bit header derived from a corresponding payload block sync header and the <NUM>-bit payload. For example, the first <NUM>-bit block <NUM> comprises a <NUM>-bit payload <NUM> and a header <NUM> containing the value "<NUM>" corresponding to the LSB of the payload block sync header <NUM>, the second <NUM>-bit block <NUM> comprises a <NUM>-bit payload <NUM> and a header <NUM> containing the value "<NUM>" corresponding to the LSB of the payload block sync header <NUM>, and the twenty-seventh <NUM>-bit block <NUM> comprises a <NUM>-bit payload <NUM> and a <NUM>-bit header <NUM> containing the value "<NUM>" corresponding to the LSB of the payload block sync header <NUM>. The values contained in the <NUM>-bit headers are examples and may change with changes in values of the payload block sync headers. Again the twenty-seven <NUM>-bit blocks encompass a total of <NUM> bits, leaving the <NUM> padding bits <NUM> to pad out a total of <NUM> bytes. In the mechanism <NUM>, the <NUM> padding bits <NUM> comprise a <NUM>-bit padding <NUM> and a <NUM>-bit OAM datum <NUM>. The OAM datum <NUM> may contain either a "<NUM>" or "<NUM>".

The twenty-seven <NUM>-bit blocks <NUM> and the <NUM>-bit padding <NUM>, and the OAM datum <NUM> are input to an RS(<NUM>, <NUM>) encoder <NUM> as indicated by the path <NUM>. The RS(<NUM>, <NUM>) encoder <NUM> generates, four <NUM>-bit parity blocks <NUM>, <NUM>, <NUM> and <NUM>. Thus, the four parity blocks <NUM>, <NUM>, <NUM>, <NUM> are calculated based on the twenty-seven <NUM>-bit blocks <NUM>, <NUM>, <NUM>, the <NUM> padding bits <NUM>, and the <NUM>-bit OAM datum <NUM>. Consequently, the values of the parity bits reflect not only the twenty-seven payload blocks <NUM>, but also the OAM datum <NUM>. The group of <NUM> blocks and four parity sync headers that delimit the parity blocks <NUM>, <NUM>, <NUM> and <NUM> constitute an FEC codeword <NUM>.

In the FEC codeword <NUM>, the four parity blocks <NUM>, <NUM>, <NUM> and <NUM> each comprise two bits and together form a pattern. Rather than a fixed pattern comprising alternating pairs of complementary values, the pattern comprises one of two alternating complementary values based on the value of the <NUM>-bit OAM datum <NUM>. Thus, the symbol "XX" in parity sync headers <NUM>, <NUM> of a sync header-pattern denotes a pair of bits having either the value "<NUM>" or "<NUM>. " The symbol the "XX" in sync headers <NUM>, <NUM> denotes the complement of the pair of bits in the parity sync headers <NUM>, <NUM>. As would be appreciated by those of ordinary skill in the art, the complement of a bit "<NUM>" is "<NUM>" and vice versa. By detecting the sync-header pattern, the receiver can determine which OAM bit was contained in the <NUM>-bit OAM datum <NUM>. For example, a "<NUM>" in the <NUM>-bit OAM datum <NUM> corresponds to the pattern <NUM><NUM><NUM><NUM> contained in the parity sync headers <NUM>, <NUM>, <NUM> and <NUM>, respectively. Conversely, a "<NUM>" in the OAM datum <NUM> corresponds to the complementary pattern <NUM><NUM><NUM><NUM> contained in parity sync headers <NUM>, <NUM>, <NUM> and <NUM>, respectively. Alternatively, a "<NUM>" in the OAM datum <NUM> corresponds to the pattern <NUM><NUM><NUM><NUM> contained in the parity sync headers <NUM>, <NUM>, <NUM> and <NUM>, respectively, and a "<NUM>" in the OAM datum <NUM> corresponds to the pattern <NUM><NUM><NUM><NUM> contained in the parity sync headers <NUM>, <NUM>, <NUM> and <NUM>, respectively.

On receiving the codeword <NUM>, the receiver calculates its own parity blocks to verify the error-free receipt of the payload and corrects the payload data if there are errors. As previously described, the <NUM> bits comprising the <NUM> padding bits <NUM> and the <NUM>-bit OAM datum <NUM> are not transmitted down the link. However, by detecting the sync-header pattern, the receiver can infer the value of the OAM data as either "<NUM>" or "<NUM>" and regenerate the value and use it along with the received payload to calculate its four <NUM>-bit parity blocks. If the parity blocks compare, the receiver knows there is no error in the payload data. If the parity blocks do not compare, then the receiver may use the difference between the received and calculated parity blocks to correct the received payload data.

Thus, OAM information is reflected in the mechanism <NUM> in three ways. First, there is an addition of a <NUM>-bit OAM datum <NUM>. Second, the <NUM>-bit OAM datum <NUM> replaces one of the padding bits <NUM> in <FIG>. The symbol "X" denotes a bit which may take a binary value "<NUM>" or "<NUM>. " The values "<NUM>" and "<NUM>" represent complementary logical values taken by a parameter in an embodiment of the codeword <NUM> and do not necessarily correspond to values of the physical embodiment of the parameter. Third, the <NUM>-bit OAM datum <NUM> determines the parity sync-header pattern. The symbol "XX" in sync header-pattern denotes a pair of bits having either the value "<NUM>" or "<NUM>". The symbol "XX" denotes a pair of bits having the complementary value.

The FEC algorithm used in 64b66b code format is RS (<NUM>, <NUM>), and this algorithm actually has a small number of unused payload bits. These unused bits are filled with zero before the parity is calculated. In order to keep as close to the standardized 64b66b code with FEC format as possible, the amount of Point-to-Point (PtP) WDM OAM information to be sent with 64b66b coded services must be reduced. <FIG> shows a way of sending <NUM>-bit OAM information per FEC codeword.

The best place to send this information is in the sync-headers, as the payload and parity bits are actively used. The <NUM> bit of OAM information determines which of the two bit patterns should be transmitted in the parity sync-headers. For example, as shown in <FIG>, when the PtP WDM OAM bit is <NUM>, the FEC parity sync-header pattern is the existing pattern (<NUM>, <NUM>, <NUM>, <NUM>). When the PtP WDM OAM bit is <NUM>, the FEC parity sync-header pattern is the complement, in other word, (<NUM>, <NUM>, <NUM>, <NUM>).

In this way, one bit of OAM information is carried in each codeword of <NUM> blocks of data. Because this format is used for <NUM> Gb/s data links, the data rate is approximately <NUM> megabits per second (Mb/s), which is fast enough for the OAM application. The OAM information can also be carried via the FEC payload block sync-header patterns.

<FIG> is schematic diagram of a network device <NUM> according to an embodiment of the disclosure. The network device <NUM> is suitable for implementing the disclosed embodiments. The network device <NUM> comprises ingress ports <NUM> and receiver units (Rx) <NUM> for receiving data; a processor, logic unit, or central processing unit (CPU) <NUM> to process the data; transmitter units (Tx) <NUM> and egress ports <NUM> for transmitting the data; and a memory <NUM> for storing the data. The network device <NUM> may also comprise optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress ports <NUM>, the receiver units <NUM>, the transmitter units <NUM>, and the egress ports <NUM> for egress or ingress of optical or electrical signals.

The processor <NUM> is implemented by hardware and software. The processor <NUM> may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor <NUM> is coupled to and in communication with the ingress ports <NUM>, receiver units <NUM>, transmitter units <NUM>, egress ports <NUM>, and memory <NUM>. The processor <NUM> comprises a 64b66b encoder/decoder <NUM>. The 64b66b encoder/decoder <NUM> assists in implementing the disclosed embodiments. The inclusion of the 64b66b encoder/decoder <NUM> therefore provides a substantial improvement to the functionality of the network device <NUM> and effects a transformation of the network device <NUM> to a different state. Alternatively, the 64b66b encoder/decoder <NUM> is implemented as instructions stored in the memory <NUM> and executed by the processor <NUM>.

The memory <NUM> comprises one or more disks, tape drives, and solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory <NUM> may be volatile and non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), and static random-access memory (SRAM).

<FIG> is a flowchart of a method <NUM> for receiving an FEC codeword according to an embodiment of the disclosure. At step <NUM>, an FEC codeword is received. For instance, the receiver <NUM> of the network device <NUM> receives the FEC codeword <NUM>. At step <NUM>, FEC parity sync-headers are extracted from the FEC codeword. For instance, the 64b66b encoder/decoder <NUM> extracts the parity sync headers <NUM>, <NUM>, <NUM>, <NUM> from the FEC codeword <NUM>. At step <NUM>, a bit pattern is determined from the FEC parity sync-headers. For instance, the 64b66b encoder/decoder <NUM> determines whether the parity sync headers <NUM>, <NUM>, <NUM>, <NUM> have a (<NUM>, <NUM>, <NUM>, <NUM>) pattern or a (<NUM>, <NUM>, <NUM>, <NUM>) pattern. Finally, at step <NUM>, OAM information is determined based on the bit pattern. For instance, the 64b66b encoder/decoder <NUM> determines that the OAM information is a binary <NUM> if the bit pattern is (<NUM>, <NUM>, <NUM>, <NUM>) or a binary <NUM> if the bit pattern is (<NUM>, <NUM>, <NUM>, <NUM>).

<FIG> is a flowchart of a method <NUM> for transmitting an FEC codeword according to an embodiment of the disclosure. At step <NUM>, OAM information is processed. For instance, the 64b66b encoder/decoder <NUM> in the network device <NUM> processes the <NUM>-bit OAM datum <NUM>. At step <NUM>, a bit pattern is determined based on the OAM information. For instance, the 64b66b encoder/decoder <NUM> determines that a bit pattern is (<NUM>, <NUM>, <NUM>, <NUM>) if the <NUM>-bit OAM datum <NUM> is a binary <NUM> or (<NUM>, <NUM>, <NUM>, <NUM>) if the <NUM>-bit OAM datum <NUM> is a binary <NUM>. At step <NUM>, FEC parity sync-headers are formed based on the bit pattern. For instance, the 64b66b encoder/decoder <NUM> forms the parity sync headers <NUM>, <NUM>, <NUM>, <NUM> based on the bit pattern. At step <NUM>, an FEC codeword is formed with the FEC parity sync-headers. For instance, the 64b66b encoder/decoder <NUM> forms the FEC codeword <NUM> with the parity sync headers <NUM>, <NUM>, <NUM>, <NUM>. Finally, at step <NUM>, the FEC codeword is transmitted. For instance, the transmitter <NUM> of the network device <NUM> transmits the FEC codeword <NUM>.

While several embodiments have been provided in the present disclosure, it may be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the scope of appended claims.

The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the appended claims.

Claim 1:
An apparatus comprising:
means for processing (<NUM>) one-bit operations, administration, and maintenance, OAM, information, wherein the one-bit OAM information determines one of two patterns;
means for forming (<NUM>, <NUM>) a forward error correction, FEC, codeword with FEC parity sync-headers, wherein the FEC parity sync-headers comprise an eight-bit pattern which is determined (<NUM>) based on the OAM information, wherein the eight-bit pattern is "<NUM>, <NUM>, <NUM>, <NUM>", or "<NUM>, <NUM>, <NUM>, <NUM>"; and
means for transmitting (<NUM>) the FEC codeword.