FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules, 2003
Complete Specification
(See section 10 and rule 13)
An Ethernet Channel Based Communication Device
The Tata Power Company Limited, Strategic Engineering Division An Indian company registered under the Indian Companies Act, 1956. 42, Saki Vihar Road, Andheri (East), Mumbai 400072, Maharashtra, India

Field of invention
The present disclosure relates to the Adaptive Forward Error Correction (AFEC) feature developed for Ethernet channel based communication devices to operate in a very high-noise environment. The noisy environment can be due to external electromagnetic interference, power related issues, signal related issues etc. Such noisy environment can interfere with devices and can create disturbances in the flow of electrons that will reflect in the form of bit errors in the data flow stream within the equipment. Such bit errors or errors can impact the performance and regular operations of the equipment making it to malfunction or work with a deviated throughput as good as a malfunctioning unit. These scenarios are addressed here in this disclosure.
Particularly, this disclosure relates to an Adaptive FEC module that can detect and correct errors (refer definitions) at a rate up to 5 in every 10 bits over a TDM (Time Division Multiplexed, Ex. E Carrier, T Carrier) communication line. The module will get automatically activated on detection of error and will adapt (refer “adaptive” in definitions) by selecting appropriate single forward error correction algorithms or concatenated forward error correcting algorithms according to the rate of error present in the communication line and automatically deactivates once the communication link is error free. This functionality happens with least impact on the throughput and bandwidth utilization of the network element.

Traditional FECs: Forward error correction modules are part of any communication devices that relies on TDM or radio frequency communication channels. Though the market have very few FEC standalone systems like TELESTE, MRV, AHA4540 etc., in most of the cases, FEC will be embedded as an internal module for error correction before the communication information is released to the communication network. These modules don’t have an adaptive technology and is limited by an error correction capability of 1 in 200 bits with very high overheads. These systems are designed for specific set of error patterns that is anticipated in a particular environment and lack the ability to adapt to the changes in error patterns. These limitations are addressed by the Adaptive FEC module mentioned in this submission. Additionally there are no present systems that implement forward error correction at the line level for the plesichronous digital hierarchy (PDH) systems.
Definitions
Before discussing the invention in detail, it is considered appropriate to provide definitions of some terms and phrases used in the following sections.
FEC (Forward Error Correction): A technique used for controlling errors in data transmission over unreliable or noisy communication channels. The central idea is the sender encodes the message in a redundant way by using an error-correcting code (ECC) in the form of redundant data bits (parity data) so that it can be recovered by a receiver even when there will be multiple errors.

Flavor: An Error Correction Code (ECC) with higher or lower redundancy resulting in higher or lower bandwidth.
MODEs: Error correcting code’s such as Reed Solomon, Viterbi, etc. (Single FEC) or concatenation of any two error correcting code’s (Concatenated FEC). Each MODE can have any Flavor. This system supports up to 3 modes. The modes include iterative FEC as well as iterative Concatenated FEC methods as well where an iterative method of error correction is adopted. Mode 1 of this system includes no error situation which is also called CRC mode. Mode 2, 3 & 4 comprises of error modes with increasing magnitude of error correction from 2 to 4.
AFEC/Adaptive FEC (Adaptive Forward Error Correction): A mechanism to automatically select any one of the 3 MODEs. A technique similar to FEC but one which can select varying amount of redundancy which is specified by the MODE in order to control varying amounts of errors in the channel so as to preserve channel bandwidth.
Adaptive: A mechanism to automatically select MODE and FLAVOR
AFEC/FEC Encoder’s and decoder’s: This term is used to indicate a set of ECC’s with a combination of Modes and Flavors. The system can support up to 3 Modes.

Concatenated FEC: The use of two error control coding algorithms: As an example, Classical (algebraic) block codes and convolutional codes are frequently combined in concatenated coding schemes in which a short constraint-length Viterbi-decoded convolutional code does most of the work and a block code (usually Reed-Solomon) with larger symbol size and block length "mops up" any errors made by the convolutional decoder. Single pass decoding with this family of error correction codes can yield very low error rates.
Concatenated FEC mode: Where two (Ex. Reed –Solomon and Viterbi etc.) algorithms are used together.
CRC: Cyclic Redundancy Check is an error-detecting code commonly used in digital networks and storage devices to detect accidental changes to raw data.
Error (Noise): Noise is an error or undesired random disturbance of a useful information signal in a communication channel. The noise is a summation of unwanted or disturbing energy from natural and sometimes man-made sources.
Encoder/ FEC Encoder: This module add redundancy to a data message at
transmitter by adding data bits or parity bits according to certain prescribed
rules
Decoder/FEC Decoder: This module uses the redundant data bits or parity
bits and corrects the corrupted data out of incoming stream

FIFO: FIFO is an acronym for first in, first out, a method for organizing and manipulating a data buffer, where the oldest (first) entry, or 'head' of the queue, is processed first. It is analogous to processing a queue with first-come, first-served (FCFS) behaviour, where the data leave the queue in the order in which they arrive.
Frame: Frame is a digital transmission data unit. A Frame typically includes sequences of bits or symbols that indicate to the receiver the beginning and end of the payload data within the stream of symbols or bits it receives.
Overhead or Redundancy: The number of bits used to transmit a message minus the number of bits of actual information in the message. Informally, it is the amount of wasted "space" used to transmit certain data. The redundancy allows the receiver to detect a limited number of errors that may occur anywhere in the message, and often to correct these errors without retransmission. FEC gives the receiver the ability to correct errors without needing a reverse channel to request retransmission of data, but at the cost of a fixed, higher forward channel bandwidth.
PDH: Plesiochronous Digital Hierarchy is a standard technology for synchronous data transmission over a communication channel.
Reed-Solomon Algorithm: Reed–Solomon codes are an important group of error-correcting codes that were introduced by Irving S. Reed and Gustave Solomon in 1960. It is able to detect and correct multiple symbol errors. By

adding the check symbols to the data, a Reed–Solomon code can detect any combination of up to t erroneous symbols, or correct up to [t/2] symbols. This is also widely used for error correction in communication channel.
Remote: Since each system has a receiver and transmitter. The connection to the receiver will always be from the transmitter of the remote system. Hence Remote is referred to as a far end device and is used to identify the far end device with respect to a particular device. For Example, for a receiver at near end, the remote will be the transmitter at far end and vice versa.
SDH: Synchronous Digital Hierarchy is a standard technology for synchronous data transmission over a communication channel.
Single FEC mode: Where only one algorithm (Reed-Solomon,Viterbi etc.) of error correction is used.
Stable and Self Sustaining Network: A communication link that adjusts itself by enabling Adaptive FEC to ensure immunity to the error’s (noise) present in the channel.
Viterbi algorithm: The Viterbi algorithm is a dynamic programming algorithm for finding the most likely sequence of unknown bit or data. The algorithm has

found universal application in decoding the convolution codes used for error correction in communication channel.
Remote control overhead: 2 bit wide data that indicates CRC, and MODEs. This data is repeated 3 times (to ensure accuracy) in every frame thereby using 6 bits of every frame.
Background of invention
The present innovation is an Adaptive FEC module. It works as part of a network element in a highly resilient network that holds strategic importance to business or government agencies. This innovation ensures the availability of a communication link even in case of a highly unstable scenario of error magnitude up to 5 bits error for every 10 bits of incoming data with least impact on bandwidth and throughput using automatic adaptability
The significance of this module lies in the fact that in case of a strategic communication network, the deployment scenario calls for very resilient network elements that could withstand the challenges and demands of an adaptable network that can withstand the fluctuations of noise level due to electromagnetic interference. The Adaptive FEC would not only ensure that the communication link never fails at very high rate of error, but also adapt itself to the level of error that it is exposed to with minimal impact in the line rate ensuring a robust communication channel without any errors.

Such an enhanced method of operation is made possible only because of the Adaptive FEC module that will adapt itself to the level of error present in the line by choosing an appropriate flavor and mode(refer “flavor” and “mode” in definition) of Forward Error Correction. The module’s transmitter (after receiving error information from its receiver) requests the remote transmitter, to ensure the usage of correct ECC (refer “FEC” in definition ) algorithm based on the type of noise in line (example of error types are single error, burst error, combination of both) and thereby the appropriate mode of error correction that must be added to the existing bit stream by the transmitter to enable a successful communication. Such requests are placed by the requesting transmitter to the remote transmitter through the remote receiver module. In addition to these mechanisms, the encoder (refer “encoder” in definitions) will understand the payload on the processor as well before determining the mode of FEC that is required in a particular situation. In case of a no-error situation, all these modules will be in listening mode (refer “CRC mode” in definitions) and won’t intervene in the regular packet flow.
Objects and advantages of invention
An object of the present disclosure is to have a stable and self-sustaining network (refer “stable and self-sustaining network” in definitions) independent of its environment. This disclosure is intended to overcome the shortfalls of traditional non adaptable FEC modules that can work only on a fixed frame and cannot correct rates of error beyond its designed capability. With the traditional modules either there is large wastage of bandwidth due to non-adaptability or the drop of

communication link due to low correction capability to conserve bandwidth. These shortfalls are addressed effectively by the Adaptive FEC methodology.
Another object of this invention is to ensure a stable, reliable and adaptable network for strategic users such as stock exchanges where loss of communication will be synonymous with strategic failure and where the criticality of communication link is extremely high. This invention will plug the gaps of traditional and conventional modules like the fixed frame operations and non-adaptability, and will ensure that the communication link never gets dropped due to the external or internal noise interferences as the throughput gets modified based on the level of error thereby resulting in balance between better correction rates and bandwidth of operation of the equipment while in its deployment.
Yet another object of this invention is to ensure a reliable enterprise environment which the current modules do not offer. In the new age of virtualization, the processing power is taken to a common space like a data center where lot of machines will be working closely. As the level of integration increases the electromagnetic interference also will tend to rise and this will call for an effective error correction mechanism that can adaptively manage the varying ranges of errors without impacting the media throughput performance and such a function can be performed only by an adaptive module with the algorithm mentioned in the coming part of this disclosure

Following are the main improvements and advantages specific to this invention against the existing available modules
- The entire Adaptive Forward Error Correction system (refer Figure 1) and its modules disclosed here analyse the magnitude of the error from the link (figure 1 module 1.5) based on the arithmetic analysis of incoming bits with the parity bits that is transmitted along with the transmission data bits. This arithmetic analysis is inherent to a field programmable gate array (FPGA) FEC decoder (figure 2 module (9.43)) which will use Viterbi, Reed Solomon or any other algorithms (refer “Viterbi”, “Reed Solomon” and “ECC” in definitions) to check whether the received data match with the transmitted data to ensure a successful reception and all these analysis happens in real time. The other FPGA sub-module (module 2.10, 2.12, 2, 8, 2.9 shown in Figure 2) uses the feedback on error detection schemes that work on the basis of Reed Solomon and Viterbi principles or by combining both algorithms in concatenated mode, and identifies the best flavour to correct the error bits iteratively. The FEC decoder module (9.43) along with the decision module (2.9) within the FPGA module 1.3 at the receiver end shown in Figure 2 analyses the error in the line by observing the incoming bits from TDM communication channel (1.5) and understands the payload data which contains the communication information and decides the mode of error correction that must be adopted and sends the information to the AFEC module 1.6 (top) shown in Figure

1. Based on the flavour choice, the encoder module within the FPGA module (top 1.3) at the transmitter end will introduce error correction bits in the stream to ensure an effective communication and will intimate its remote receiver to follow the updated error correction mode. The existing FEC modules don’t support an intelligent operation such as this.
- The existing available FEC mechanisms like Xilinx, Olson Technologies, or Viasat have a very narrow spectrum of error correction (usually irrecoverable beyond 1 error in 1000) and anything beyond the intended capacity of error correction will cause the communication channel to fail. The Adaptive FEC of the invention has a very broad range of correction – up to 5 out of 10 bits in different adaptive modes consisting of desired flavours – which will ensure that the module handle a wide spectrum of errors starting from zero to fifty percentage of total payload, ensuring a reliable communication.
- The FEC modules of the invention will enable a stable communication in tier 2 and tier 3 regions of the country where the power standards are quite rough. This module can adapt to the noise generated from the power source and ensure a working communication link with the available resources even at a lower bandwidth

List of Figures:
Figure 1 shows a broad overview of AFEC system connected between two data
sources, depicting the flow of data through the system with DS01 as transmitter
and DS02 as receiver
Figure 2 shows Overview of various components of AFEC system with FPGA
elaborated
Figure 3 shows the internal flow of architecture for transmit framer
Figure 4 shows the internal architecture for finding the frame marker from the
incoming data
Figure 5 shows the internal architecture of receive framer
Figure 6 shows the internal architecture of decision logic for deciding when to
switch from Mode 1 to Mode 2 and vice versa
Figure 7 shows Overview of the FEC module in FPGA
Figure 8 shows the internal architecture of FEC Encoder controller block in FPGA
Figure 9 shows the internal architecture of FEC Decoder controller block in FPGA
Summary of invention
The innovation disclosed here is an adaptive forward error correction module that will enable successful communication in the worst operation scenarios where the user have to face a communication link which is unstable and not viable for a normal communication. The adaptive forward error correction module will utilize the available bandwidth to ensure successful communication by utilizing additional error correction bits in the communication frames along with error

correction algorithms that will enable in identifying the right data through real time processing as mentioned in the detailed descriptions below.
Detailed description of invention
This Adaptive Forward Error Correction (AFEC) feature is designed as a built in add-on for any routing devices using a TDM network for the data communication over legacy protocols like PDH, SDH, etc. The AFEC feature can also work as an independent external module that can interconnect any IP or Ethernet data stream to a TDM stream over the legacy protocols mentioned above.
Figure 1 shows the AFEC modules connected over a TDM stream (1.5). The IP or Ethernet data input stream DS01.Such Ethernet input is converted to TDM frames in the converter module (1.2) and passed on to the FPGA module (1.3) that introduces error correction algorithms to the incoming TDM frames in the form of overheads. Such processed frame is passed on to the Line interface module (1.4) which will pass on the frame to the TDM stream (1.5). The contents of the TDM stream are also depicted in (1.5). This is explained in the subsequent sections. The entire AFEC system (1.6) can be summarized as the combination of Converter Module (1.2), FPGA processing module (1.3) and the Line interface module (1.4). At the receiving side as mentioned in the figure, same modules are repeated as the Line Interface Module (1.4) interconnect the TDM stream(1.5) with FPGA processer (1.3) which will process the incoming TDM frames, identify the

overheads and filter out the relevant data passing on to the converter module (1.2) which will move as data stream DS02.
To spontaneously adapt to the noise in the communication channel and to correct errors up to 500 bits in 1000 bit TDM frame, any system should address the following challenges:
1. To be able to detect rate and type of error during l operation.
2. To provide a bi-directional communication mechanism.
3. To provide robust and versatile forward error correction encoders and decoders that can correct single bit errors as well as bursts of errors efficiently.
4. To provide layers of error control encoding/decoding algorithm’s that will perform encoding and decoding of up to two different forward error correction algorithms (concatenated codes) on a single frame of TDM data.
5. To provide a line sustaining method that will ensure frame lock is not lost when errors corrupt the entire frame header word as well.
6. To provide an adaptive decision logic block that will accordingly increase or decrease the rate of error correction required according to the amount of noise present in the channel in order to maximize bandwidth.
7. To provide full user configurability of all above parameters to provide security, freedom of choice of FEC algorithm, manual override of required correction rate and compile time customization of any parameter including non-standard TDM frame lengths and headers.

The AFEC module is designed to address these challenges in comparison to traditional FEC modules. The FPGA module (1.3) process the incoming TDM frames and enhances the frames with additional overhead bits and control bits by processing the incoming frames of data within the Encoding Module of AFEC module as shown in Figure 8 (Module 8.41) making it more fool proof for the error magnitude identified in the communication channel by the Decision Logic Module (2.9) at the receive side of the communication network. The additional bits added as overhead will assist in the error detection at receiving FPGA where the data analysis will be done in line with the mathematical principles of Reed Solomon, Viterbi etc.
The AFEC module in Figure 2 provides a detailed view of the components. It comprises of line interface unit – LIU (1.4), a transmit module (2.8), a decision logic (2.9), a receive module (2.10), FEC encoders (8.41) and decoders (9.43), a controller core (2.12) and a WP3 Module (1.2). The section (1.3) depicts the parts of this invention that exists on a FPGA fabric.
The LIU (1.4) and WP3 Module (1.2) are integral parts of the AFEC module to interface the network. The external network will get physically connected to the LIU (1.4). The WP3 Module (1.2) will act as the convertor converting the TDM data to IP packets for user interconnection.

The transmit module (2.8) performs the following sub-functions at the encoder stage:
• Insert of CRC in every frame.
• Add remote control overhead.
• Frame a header.
• Request processing from decision module (2.9).
• Request and addition of FEC overhead for error correction.
The sub-functions performed by the receive module (2.10) and decision module (2.9) involved at the decoder stage include:
• De-frame header.
• Detect remote control overhead.
• CRC processing.
• Request the transmit module (2.8) to ask remote to enable FEC.
• Appropriately send corrupted data for error correction.
The modules (8.41 and 9.43) of Figure 2 consist of a combination of FEC encoders and decoders that can work out different combination of error correction methods based on the algorithm of encoding and decoding used by it.
The modules (8.41 and 9.43) consist of the following Functional modules:
• Viterbi encoders and decoders
• Reed Solomon encoders and decoders

• Concatenated Reed Solomon with Viterbi encoders and decoders
• Control logic and FIFO registers
The FEC decoders (9.43) also submit “Quantity of errors detected per frame” information to the decision module (2.9).
The FEC encoders (8.41) and decoders (9.43) can be customized at compile time for the maximum required rate of error correction. Up to 50 such modules can currently exist on the existing FPGA (1.3). The line bandwidth is reduced with the increase in required error correction.
The use of concatenated algorithms helps enhance bandwidth and perform efficient correction. The use of Viterbi decoders help recover bit errors and then the Reed Solomon decoders can take care of the block errors. The entire AFEC system (1.6) can operate either in CRC mode, single FEC mode, or the concatenated FEC mode. Additionally, there exist up to three flavors of each mode offering different rates of correction and decreasing bandwidth. It can also switch across all these modes automatically depending on the number of errors and the type of error (bit/block) present in the line.
In automatic mode the processing steps change according to several scenarios based on the type and rate of errors detected in the line. The process is reversed

automatically after a customizable threshold entity of error free data is detected from the channel.
• No errors (MODE 1)
• Only 1 bit wide errors (MODE 2)
• At least 2 bit to greater than 8 bit wide errors (MODE 3)
• Both 1 bit and 2 bit to greater than 8 bit wide errors (MODE 4)
The above MODEs (2, 3, and 4) are available in up to 3 flavors each with each mode offering more correction rate than the next - that is up to 3 customizable flavours of each of Viterbi, Reed Solomon and Concatenated Viterbi - Reed Solomon.
Transmit module (Figure 3):
In this section we go into detail into the steps involved to accomplish the above sub-functions.
After power on reset, a local system clock start’s a free running counter (3.12) corresponding to the configured E/T/Custom carrier frame length of data that come from the source
A slot decoder (3.13) and four bit counter for slot generation (3.14) works together to indicate the start of different parts of TDM link (1.5). These include

location of frame alignment word, location of the present mode used, location of data and location of FEC overhead parity or CRC pattern in a single frame.
Registers (3.15) store the entire frame alignment word or custom frame alignment word. The slot decoder (3.13), the Four-bit counter for slot generation (3.14), and the registers (3.15) – they all communicate with a decoder and overhead multiplexor (3.17) which combines the overhead bits with data bits and sends to the FEC Encoder the data including header, remote information, and CRC information. Decoder and Overhead Multiplexor section (3.17) also sends a gapped gated clock for the request for data is sent by a gapped gated clock section (3.16). The received data from Converter Module (1.2) is aligned with the logic (3.18) and (3.19) and combined into the frame consisting of the header and remote data. These modules are provided to manage the delay synchronization.
The data is simultaneously sent to FEC coders (8.41) from (3.19) for coding as well as for CRC calculation (3.20). The CRC information is sent back to decoder and overhead multiplexor (3.17) for insertion into the frame via a delay synchronization module (3.21) and a configurable multiplexor (3.24) in MODE 1. The information from the FEC coders will reach link (1.5) through the interface units (1.4).
The configurable multiplexor (3.24) is controlled by Decoder and Overhead Mux (3.17). This is where the decision to send either the FEC data (MODEs 2, 3, 4) or

the CRC data (MODE 1) is taken. This multiplexer is provided in parallel to serial conversion before it hits the interfacing units. The multiplexor is configured accordingly when more modes or fewer modes are required.
The delay synchronization modules (sections 3.21, 3.22, 3.23) linked to 3.24 adjusts the computed delay of the data received from the FEC coders accordingly so as to make a transition from MODEs 1 to 2, 3 or 4 seamless.
Receive module (Figures 4 and 5):
Figure 4 has 3 sections-viz: an upper section comprising of flows 4.1 till 4.3, left section comprising of flows 4.4 till 4.15 and the right section comprising of flows 4.16 till 4.21. The upper section continuously monitors the incoming data and searches for the frame header. Whenever it finds the frame header it asserts a signal flaw Detected. The left section of figure 4 increments a register rxState4b whenever the frame word has been detected. As per the ITUT standard frame synchronization is achieved if 3 consecutive frame headers have been detected in the expected slot. Frame synchronization is lost whenever 4 consecutive frame headers have not been detected. The right section of figure 4 uses a set of counters to find out the location of various part of the frame (1.5). It also specifies the location to look for the frame header.
As mentioned earlier the Receive module (2.10) and Decision module (2.9) involved at the decoder stage are required to perform a number of sub-functions.

In this section we go into detail into the steps involved to accomplish these sub-functions.
Table 1: Brief description of various blocks in figure 4

lineRxD This is a serial data signal that comes
from the TDM Link(1.5) via the LIU
(1.4)
lineRxClk This is the accompanying clock for
lineRxD
Edge Alignment Register (4.1) This registers aligns the lineRxD and
lineRxClk accordingly to either positive
edge or negative edge as per the LIU
(1.4)
Shift Register (4.2) This register keeps a small window of
LineRxD. The width of this register
corresponds to the width of the frame
alignment word.
Compare (4.3) The contents of the shift register (4.2)
are compared with the actual frame
alignment word.
fawDetected This signal is asserted whenever
Compare (4.3) is true.

SYNC
As per ITUT the SYNC is asserted
whenever 3 consecutive frames with the
expected frame alignment word are
received. And de-asserted whenever 4
consecutive frames do not have the
expected frame alignment word.
RESET (4.4) In order to assert or de-assert SYNC an
rxState4b internal register rxState4b is used to
hold the number of received frame
alignment word.
fawExpectedSlot Upon receiving the frame alignment
word, the first time, it is known where
to expect the same the next frame. This
signal is used to indicate where the
frame alignment word is expected.
Counter (4.27) This is a free running counter whose
length matches the length of a single
frame.
cntFAWforSync This is a register that holds the number
of frames with a valid frame alignment
word that needs to be detected. This
value is set to 3.

rxCustomFrameCntr This is a free running counter whose
length matches the length of a single
frame.
Four bit Counter and slot generation This module handles the count for other
(4.21) parts of the logic as well as generates
several signals indicating various parts
of the frame.
cntFAWforNoSync This is a register that holds the number
of frames with an invalid frame
alignment word that needs to be
detected. This value is set to 4.
ituFAWArea Various parts of the TDM frame (1.5)
customFAWArea are detected by these signals
CustomOHArea
customModeArea
fecOHArea
Table 2: Brief description of various blocks in Figure 5

recieveFramer (5.29) This module consists of all components
of figure 4.
Shift-in customOverhead (5.1) The present operating mode is sent 3
times within a single frame. This is

done so that in the event of an error the
incorrect mode is not activated.
Majority (5.2) Out of the 3-repeated mode setting that
is sent, if 2 have the same mode then
the majority is favored and that
particular mode is used.
Shift-in CRC Byte (5.3) In this block the CRC information
received from the frame is stored. It is
later used in comparing (5.4) with the
re computed CRC (5.5)
De-framing of header takes place at the receive framer logic (5.29), which is explained in detail in Figure 5. The data is first aligned during which the headers will be separated from the data bits of the frame and a comparison with the frame header is made in Shift Register (4.2). Once the comparison is made, the signal indicating the frame alignment word detected during the comparison is asserted in the comparison logical module (4.3). Until then a 4-bit register that indicates the state of frame alignment word is held at ‘0’ as shown in the collection of logic (4.4 to 4.15). This is followed by flow (4.27) that asserts the next location where the header must be found. The remainder of the collection of logic (4.4 to 4.15) looks for the header 3 more times and then asserts the sync signal by changing the 4 bit register that indicates the state of frame alignment word to ‘1000’. The remainder of flow (4.27) sends markers to Second Four-bit Counter and Slot

generation module (4.21) via decoders, following which the size of header; remote data, payload, CRC data, FEC overhead etc. are obtained via (4.21).
From receive framer (5.29), the marker information generated from Figure 4 is sent for CRC calculation and comparison as shown in flow (5.1 through 5.5) as well as FEC decoding and delay adjust logic flow 5.31. The data received is in either MODE 1 or MODEs 2, 3, 4. In the event the data arriving is in MODE 1 and if the output of flow (5.1 through 5.5) detects the incoming CRC is incorrect with that of re-calculated CRC, a request to enable MODE 2 in remote is asserted to the transmit module (2.8) by decision logic (2.9).
If the incoming mode is anything other than MODE 1, then the data is sent to FEC decoder (2.11) for correction and flows (5.32, 5.13 and 5.11) provides the appropriate de-framing and clock gating for retrieving of valid payload.
The decision to request remote to either disable MODE 2, 3, 4 or to enable them is taken by the Decision module (2.9) explained in the next section.
Decision module (Figure 6):
There are two methods used in the Decision module (2.9) to help decide whether or not to enable MODE 1 or MODE 2, 3, 4. In the event the received signal is in MODE 2, 3, or 4, customizable sliding window mechanism accumulates the number of errors detected from the FEC module 9.43. It performs a comparison of

numbers of errors detected with a customizable threshold value which requests remote transmit FEC module 2.8 to enable MODE 1 or continues to inform remote to stay in MODE 2, 3 or 4.
In the event the received signal is in MODE 1, a continuous check for valid CRC is performed. In the event the CRC is corrupt, the decision to request the remote to enable MODE 2 is sent.
Table 3: Signal names used in Figure 6 and their description.

statusCheckSlot(6.1) This signal is either TRUE or FALSE.
It is TRUE once in every frame.
minSwitchGapTimeCntr(6.2) This is a counter that runs for a
specific amount of time which is
configurable. The decision logic is
allowed to make a decision only when
this counter is set to zero. This is done
to prevent frequent switching in the
even error in the channel is rapidly
fluctuating.
fecCheckWindowCntr(6.4) This is a counter that runs for a
specific amount of time which is
configurable. The decision logic
checks for errors only when this

counter is zero. This is done to
prevent excessive checking of errors.
crcErrDet(6.17) This signal is asserted by the receive
module whenever a CRC pattern
comparison has failed. The decision
logic uses this signal to decide to
change to Mode 2 from Mode 1.
fecErrDet(6.17) This signal is set by the FEC decoder
blocks. The decision logic uses this
signal to know when a particular FEC
mode 2 or 3 is no longer able to
correct errors. In this event a decision
is made to change to Mode 3 from
Mode 2 or Mode 4 from Mode 3.
fecCheckErrAccum(6.10) This register stores the number of
error corrected by the FEC decoder.
The decision logic uses this register to
compare with a preset value defined
in
FEC TO CRC CHKSWITCH TRE
SH and
FEC TO CRC CHK WINDOW SI
ZE registers. The decision to switch

to higher or lower mode is made
based on this.
FEC TO CRC CHK SWITCH TRESH This register stores the number of
(6.10) errors correctable by a that particular
flavor of FEC
fecErrorCount(6.12) This is an input to the decision logic
module and it indicates the number of
errors corrected by the FEC decoder.
The decision logic block accumulates
this value and stores it in the
fecCheckErrAccum register.
FEC TO CRC CHK WINDOW SIZE( This is a configurable preset value
6.16) that tells the decision logic module
how long it should accumulate errors
detected.
MIN FRAMES BETWEEN SWITCH( This is a preset configurable value.
6.39) The decision logic counts down this
value to zero and also resets it at
every change of Mode. It changes
Mode only when this is zero. This is
present to prevent frequent switching
of Modes.

FEC module (Figure 7, Figure 8, Figure 9):
We mentioned earlier that the FEC module has a number of sub-functions. In this section we go into detail into the steps involved to accomplish these sub-functions.
The entire AFEC system (1.6) can hold up to 3 flavors of i, ii and iii mentioned above. The use of MODE 1 (Flavor 1, Flavor 2, Flavor 3), MODE 2 (Flavor 1, Flavor 2, Flavor 3), and MODE 3 (Flavor 1, Flavor 2, and Flavor 3) is made by multiplexor (2.9)which selects appropriate path from parallelly running the nine combination instances of transmit framer (2.8) (3 modes x 3 flavors per mode), decision logic (2.9), receiver framer (2.10), encoders and decoders (2.11) on a single FPGA fabric (1.3).
The Viterbi algorithms, Reed Solomon algorithms, and FIFO registers can be generated for any required overhead size, symbol width, symbol length, and error correction rate using IP core generators from Microsemi or other commercially freely available sources. In this module the IP core generators are referred to as FEC encoders (8.41) and FEC decoders (7.43).
Figure 7 shows an overview of the FEC module. It consists of a controller core (2.12), a FIFO register (7.42) and the FEC encoders (8.41) and FEC decoders (7.43).

The various functions accomplished by the controller core (2.12) are:
• Accept line data that needs FEC
• Send line data to FEC encoder or FEC decoder
• Monitor the status of FEC encoder and FEC decoder
• Receive FEC encoded data from the FEC encoder or corrected data from FEC decoder
• Send FEC encoded data back to the transmit framer or FEC corrected data back to the receive framer
The controller core (2.12) is responsible for sending and receiving data to the transmit module (2.8) and the receive module (2.10). The controller core (2.12) is initiated twice; once to transmit FEC encoded data and the second time to transmit corrected data. These events are depicted in Figure 8 and Figure 9 respectively along with an overview of its internal structure.
The encoder receives the data to be encoded through the Serial to Parallel Shifter (Figure 8, module (8.1)) which will convert the data from serial mode to parallel mode for data processing. The Marker Detect Module (Figure 8 Module (8.2)) will identify the frame start and end points so that the Clock Enable Generator (Figure 8, Module (8.4)) can identify the m bit where the encoding bits need to be inserted. Both these inputs will be processed by the Encoding Module (Figure 8, Module (8.41)) which will process the data and complete the encoding procedure. Hence

the output of Encoding Module will be the actual data along with the encoding bits that will make the data secure from possible errors in the link
The purpose of ‘clock enable’ output signal is to pulse whenever m-bit out register has the correct shifted m-bit word. For example, if m = 8 and if 01000000 is transmitted, then ‘clock enable’ is asserted when output consists of word “40”. This is handled by process Clock Enable Generator (see Figure 8). This is then loaded into the FEC encoding module (8.41) as the first symbol.
When the FEC encoding module (8.41) has produced a valid code word it asserts a ready signal which is used by the clock generator and output marker blocks (8.4)Figure 8 to generate PISO enable signals and the output marker.
As a decoder (Figure 9), the same block architecture of encoding module (Figure 8) functions with an additional FIFO register to accommodate for decoder delay and an additional logic to generate a virtual marker to continue error correction even if incoming marker is lost due to excess errors, as long as post-correction frame sync is achieved. The controller code (8.40) generates write enable and read enable signals for FIFO’s memory register as shown in 7.42. When the FIFO contains enough symbols for the FEC decoder (9.43) it asserts a start signal. The FEC decoder (9.43) then requests for data to FIFO. After correction the FEC decoder stores the corrected symbols into FIFO (7.42). This is then retrieved from the controller (8.40) and PISO operation is performed.

What happens when marker is lost ? This could mean two things. One, the transmitter has stopped sending a signal. Now the FIFO’s and RSDec needs to be reset and kept ready for a fresh transmission. Two, there are too many errors in line, hence the loss of markers. In this situation, all operations need to continue as long as succesfull correction is being achieved.
Example of operation
A simple example of operation is explained in the following section through the use of flowchart 1 and flowchart 2.
Consider two devices as shown in Figure 1 let the upper one be A (DS01 and 1.6), the transmitter and the bottom one be B (DS02 and 1.6), the receiver (Figure 1).
Initially when the device is powered on the entire AFEC system (1.6) modules of both devices operate in NO ERROR mode. In this mode a simple CRC is evaluated for the TDM data and sent along with TDM data and remote control data that indicates that the sent or transmit frame is in NO ERROR mode. This is shown in the first rectangle of Flowchart 1. On reception of this data from communication stream, the receiving AFEC module will first search for the frame header and will lock onto the frame. It will then decode the remote data to detect the present operating mode. In this example it is in CRC or NO ERROR mode hence it calculates the CRC of the received incoming data and compare it with the CRC bits in the received data frames. If both the CRC values are same, the

comparison will be treated as successful which means a no error situation will be maintained.
In case of an error in communication channel, the CRC check will fail during which transmit section of FPGA 1.3 of System B enables a request for FEC FLAVOR 1 MODE 2, which is the first error correction mode by adding this information in the remote data it send to the device A . Flowchart 2 depicts the set of operations in MODE 2,3, or 4Based on the flavor and mode which is detected by decoding of the remote mode bits, the appropriate frames will be passed on to the corresponding FEC decoder in FPGA which will give the corrected data as the output. In case the FEC decoder is unable to correct the frames as expected, then the system identifies the need to change the error correction mode using the decision logic block explained earlier and informs transmit framer to request the remote system to send the data with next flavor of error correction. In case the FEC decoder is continually able to correct all errors, the decision module will monitor the number of errors it is correcting. In the event the errors corrected can be done with a lower flavor of FEC then it sends a request to remote system to lower the operating mode. This will work iteratively till the communication happens successfully between A and B and vice versa.
Technical Advancements
The technical advancements offered by the present invention include the realization of:

1) Ethernet to Ethernet transport over standard programmable E1 E2 E3 TDM Links is implemented with Dynamic Adaptive FEC in our unique and proprietary hardware. This is advancement from existing method of using FEC at the transmission level where the adaptation feature cannot be utilized on a network optimization level.
2) The hardware system consist of advanced state of the art network processors, FPGA and line interfaces that works with the router element of the network internally and ensures that the error correction is introduced adaptively enabling maximum throughput. The system takes into account the level of error that is perceivable in the Ethernet transport and based on the amount of error it will dynamically decide the correction overheads quantum thereby ensuring adequate bandwidth during error free periods.
3) Hardware layout is such that it enables the network processor to cater to framed and unframed mode of operation and also supports a non-standard bit rate. This will ensure that the communication link never fails and will work even on a very high rate of error environment. This system is advanced in such a way that it can operate at an error rate of up to 5 in 10 bits considering its application in sectors like defense where communication is the life line of operation. No existing system provides this Error Correction quantum at the network element level which is a radical reform in this segment.

4) Power consumption across all error rates is low due to the usage of advanced state of the art network processors, FPGA and line interfaces. The use of such components will ensure that the power consumption is very less while improving the durability and resilience.
5) The physical E1, E2, and E3 links can be dynamically switched in unbalanced mode of operation. This is advancement from existing feature where the TDM interfaces remain static in nature. This advancement have ensured that in case of a high error environment, while the bandwidth get choked due to large overheads, the user can switch the link to a higher bandwidth enabling him to pump more data.

We Claim:
1. An Ethernet channel based communication device for communicating over a time division multiplexed (TDM) / plesichronous digital hierarchy (PDH) communication line characterised in that said device has an adaptive forward error correction (AFEC) module (1.6) that is capable of operating in high-noise environment to detect and correct errors over said TDM communication line.
2. A communication device as claimed in claim 1, characterised in that said AFEC module (1.6) is automatically activated upon detection of error and adapts according to the rate of detected error and deactivates automatically once the said TDM communication line has been made error-free.
3. A communication device as claimed in any of claims 1 and 2, characterised in that said one AFEC module (1.6) is used at each of the transmitting and receiving ends of said TDM communication line, each of said AFEC module comprising a converter module (1.2), a field-programmable gate array (FPGA) processing module (1.3), and a line interface module (1.4), wherein at the data input end, the data, which is in the form of incoming TDM frames, is transmitted from the converter module (1.2) to the FPGA processing module (1.3) to said line interface module (1.4), and wherein at the data receiving end, the TDM frames are routed through the line interface module (1.4) to the FPGA processing module (1.3) further to the converter module (1.2) to finally send out the data output stream.

4. A device as claimed in claim 3, characterised in that said FPGA module comprises a transmit module (2.8), a decision logic module (2.9), and a receive module (2.10), wherein said transmit module (2.8) receives data from the converter module (1.2) at the transmit end and encodes it with the help of a encoder module (8.41) and a corresponding controller module (2.12), at the receive end, the decision logic (2.9) determines the mode of error with the help of a decoder module (9.43) and another corresponding controller module (2.12) and takes corrective action by sending the mode of FEC or CRC required via its transmit end as well as sends corrected data to receiver module (2.10) for output at the receiver end.
5. A device as claimed in claim 4 characterised in that said transmit module
(2.8) performs the following steps in the sequence shown:
o inserting a cyclic redundancy check in every TDM frame,
o adding remote control overhead,
o framing a header,
o requesting processing from decision module (2.9),
o requesting and adding FEC overhead for error correction.
6. A device as claimed in claim 5, characterised in that said decision module
(2.9) and receive module (2.10) perform the following functions in the
sequence shown:
o de-frameing said headers,
o detecting remote control overhead,
o performing said cyclic redundancy check,

o requesting said transmit module (2.8) to ask remote said receive
module (2.10) to enable or disable FEC or CRC o sending detected corrupt data to 2.12 for error correction.
7. A device as claimed in claim 6 characterised in that said FPGA module at the data input end receives and processes the incoming TDM frames and enhances them with additional overhead bits and control bits by processing said incoming TDM frames within the encoder (8.41) and transmit framer (2.8) of said FPGA module making it more fool proof for the error magnitude identified in the communication channel by the decision logic module (2.9) using information from decoder (9.43) and receive framer (2.10) at the receive side of the communication network, wherein said additional bits added as overhead assist in the error detection and correction at receiving FPGA where the data analysis is done
8. A device as claimed in claim 7, characterised in that said encoder (8.41) and decoder (9.43) comprise:
o any error control encoder and decoder logic, o any concatenated error control encoder or decoder logic, o a controller logic for the above two and a first-in-first-out (FIFO) logic for synchronisation and timing.
9. A device as claimed in any of claims 2 to 8, characterised in that the said
entire AFEC module (1.6) may operate in any of the following ways:
cyclic redundancy check, single FEC, iterative FEC concatenated FEC,
iterative concatenated FEC

10. A device as claimed in claim 9, characterised in that each of said three modes may come in any flavours offering different rates of correction and decreasing bandwidth, and each of said ways may switch across any of the selected flavour for each said way depending on the number and type of the error present in said TDM communication line, said flavours example being a Viterbi logic, a Reed-Solomon logic or a concatenated Reed-Solomon-Viterbi logic.
11. A device as claimed in claim 10, characterised in that said transmit module 2.8 comprises a free running counter (3.12), a slot decoder (3.13) and a four bit counter for slot generation (3.14), registers (3.15) for storing frame alignment word, A decoder and overhead multiplexor (3.17), data combinatory logic modules (3.18 and 3.19), delay synchronisation modules (3.21, 3.22, and 3.23), wherein said slot decoder and said four bit slot generator (3.14) work together to indicate the start of different parts of said TDM communication line (1.5), registers (3.15), slot decoder (2.13) and four bit counter for slot generation (3.14) all communicate with said overhead multiplexor (3.17), which combines the overhead bits with data bits and sends to the FEC Encoder the data including header, remote information, CRC information; said decoder and overhead Multiplexor section (3.17) also sends a gapped gated clock for the request for data by a gapped gated clock section (3.16); the received data from said converter module (1.2) is aligned with said logic modules (3.18) and (3.19) and combined into the frame consisting of the header and remote data, wherein

said delay synchronisation modules are provided to manage the delay synchronization; the data is simultaneously sent to FEC encoders (8.43) from (3.19) for coding as well as for CRC calculation (3.20); the CRC information is sent back to decoder and overhead multiplexor (3.17) for insertion into the TDM frame via said delay synchronisation modules (3.21 and 3.23) in MODE 1 (CRC Mode,) that is no error has been detected; the information from the transmit framer(2.8) will reach link (1.5) through LIU Interface (1.4) through, a configurable multiplexor (3.24) which is controlled by said decoder and overhead Multiplexer 3.17. where the decision to send either the FEC data (MODEs 2, 3, 4) or the CRC data ( MODE 1) is taken, and also wherein said multiplexor is configured accordingly when more modes or less modes are required, wherein Mode 2 represents a state where only 1 bit wide errors are detected, Mode 3 represents a state where at burst type of errors are detected, and Mode 4 represents a state where both 1 bit and burst type errors are detected, wherein the configuration of these modes can be interchanged for any type of error in the channel.
12. A device as claimed in claim 11, characterised in that said decoder module (2.10) carries out deframing as follows:
o data received from remote is first aligned during which the headers are separated from the data bits of the frame and a comparison with the frame header is made in a shift register (4.2), following which

the signal indicating the frame alignment word detected during the comparison is asserted in a comparison logical module (4.3); and wherein until this time, a 4 bit register that indicates the state of frame alignment word is held at ‘0’ as shown in the flow ( collection of logic (4.4 to 4.15)); whereafter, said flow (the collection of logic (4.4 to 4.15)), which is the collection of logic (4.4 to 4.15), is followed by another flow (4.27) that asserts the next location where the header must be found, following which the remainder of flow (the collection of logic (4.4 to 4.15)) looks for the header three more times and then asserts the synchronised signal by changing the 4 bit register that indicates the state of frame alignment word to ‘1000’ and the remainder of flow (4.27) sends markers to a second four-bit counter and slot generation module (4.21) via decoders, following which the size of header; remote data, payload, CRC data, FEC overhead etc. are obtained via (4.21), following which o from a receive framer (5.29), the marker information generated from is sent for CRC calculation and comparison as shown in flow (5.1 through 5.5) as well as FEC decoding and delay adjust logic flow 5.31, and wherein the data received is in either said MODE 1 or said MODEs 2, 3, 4, and further wherein, in the event the data arriving is in said MODE 1 and if the output of flow (5.1 through 5.5) detects the incoming CRC is incorrect with that of re-

calculated CRC, a request to enable said MODE 2 in remote is asserted to the transmit module (2.8) by decision logic (2.9); if the incoming mode is anything other than said MODE 1, then the data is sent to FEC decoder (2.11) for correction and flows (5.32) and (5.33) provides the appropriate de-framing and clock gating for retrieving of valid payload.
13. A device as claimed in claim 12, characterised in that the decision to
request remote said transmit module (2.8) to either disable said MODEs 2,
3, 4 or to enable them is taken by said decision module (2.9) in the
following steps:
o in the event the received signal is in said MODEs 2, 3, or 4, accumulating through a customizable sliding window mechanism the number of errors detected from said decoder module (9.43) by performing a comparison of numbers of errors detected with a customizable threshold value, whereafter said decoder module (9.43) sending a request to remote said transmit module (2.8) to enable said MODE 1 or continuing to inform remote said transmit module (2.8) to stay in said MODEs 2, 3 or 4, or else,
o in the event the received signal is in said MODE 1, performing a continuous check for valid CRC and if the CRC is corrupt, sending a decision to request the remote to enable said MODE 2.
14. A device as claimed in claim 13, characterised in that said AFEC system
(1.6) operates in up to four modes which are CRC (error detection only)

said MODE 1 ), said MODE 2 (any flavor), and said MODE 3 (any flavor) controlled by decision logic module (2.9) by iterative communication with said receiver module (2.10), said encoders (8.41) and said decoders (9.43) on a FPGA fabric (1.3).
15. A device as claimed in claim 14, characterised in that ECC algorithms and FIFO registers are generated for any required overhead size, symbol width, symbol length, and error correction rate using IP core generators from Microsemi or other commercially or freely available sources, and referred to as AFEC encoders (8.41) and AFEC decoders (9.43).
16. A device as claimed in claim 15, characterised in that said AFEC module (1.6) further carries out its function in the following steps:

- accepting Ethernet data or input data that needs FEC,
- sending Ethernet data or input data to FEC encoder (8.41) to transmit module (2.8) as line date,
- sending line data to FEC decoder (9.43) and receive corrected data from FEC decoder(9,43) and send it to receiver module (2.10),
- monitoring the status of FEC encoder (8.41) and FEC decoder (9.43),
- receiving FEC encoded data from the FEC encoder (8.41) or corrected data from FEC decoder (9.43), and
- sending FEC encoded data back to said transmit module (2.8) or FEC corrected data back to the receive module (2.10).
17. A device as claimed in claim 16, characterised in that said controller core
(2.12) sends data to said transmit module (2.8) and receives data from said

receive module (2.10), whereby said controller core is initiated twice; once to transmit FEC encoded data and the second time to transmit corrected data.
18. A device as claimed in claim 17, characterised in that said encoder (8.41) receives the data to be encoded through a serial to parallel shifter module (8.1), which converts the data from serial mode to parallel mode for data processing, where after a marker detect module (8.2) identifies the frame start and end points so that a clock enable generator module (8.4) identifies the mth bit where the encoding bits need to be inserted, wherein both these inputs are processed by said encoding module (8.41), which processes the data and complete the encoding procedure, thus enabling output of said encoding module (8.41) to be the actual data along with the encoding bits which is secure from possible errors in the TDM communications line, whereafter the correct-shifted output m-bit word is loaded into said FEC encoding module (8.41) as the first symbol, whereafter said FEC encoding module (8.41) asserts a ready signal which is used by said clock enable generator module (8.4) and the provided output marker blocks (8.4) generate PISO-enable signals and the output marker.
19. A device as claimed in claim 18, characterised in that in said decoder module (9.43) the same block architecture (2.12) as for said encoding module (8.41) functions with an additional FIFO register to accommodate for decoder delay and an additional logic to generate a virtual marker to continue error correction even if incoming marker is lost due to excess

errors, as long as post-correction frame sync is achieved, wherein a controller core (2.12) generates write-enable and read-enable signals for FIFO’s memory register module (7.42), wherein when the FIFO contains enough symbols for said FEC decoder (9.43) it asserts a start signal, whereafter said controller core (2.12) requests for data to FIFO and sends the data to FEC decoder(9.43); after correction the controller core (2.12) retrieves the data from FEC decoder stores the corrected symbols into FIFO (7.42), PISO operation is then performed by controller core (2.12).