Adaptive forward error correction

Abstract

The disclosed communication system includes a Dynamic Multiple Input / Multiple Output Transmitting System (DMTS) module and an Adaptive Forward Error Correction (FEC) module. The FEC module includes a transmit module for receiving a first packet and command from the DMTS module, generating parity checks for n first packets, and retransmitting the first packets, along with the parity checks, to the channel manager in the transmit direction. The FEC module also includes a receive module for receiving a second packet from the channel manager in the receive direction. The DMTS controls when parity checks are transmitted for a given flow. Parity checks may be transmitted across multiple channels, and the FEC module can be enabled or disabled for each traffic flow.

Description

Technical Field

[0001] Cross - reference to related applications This application claims priority to U.S. Provisional Patent Application No. 63 / 521,014, filed on June 14, 2023, the entire content of which is incorporated herein by reference.

[0002] Embodiments of the present invention generally relate to systems and methods for performing forward error correction encoding, particularly adaptive forward error correction (「FEC」).

Background Art

[0003] FEC generally refers to techniques for controlling and correcting errors in data transmission by transmitting redundant data or re - transmission data, assuming that data is dropped during movement. This redundant data can include error correction encoding such as verification information. When implementing known FEC techniques, FEC frames are generally used to regenerate frames at the receiving side in order to avoid the need for re - transmission of data. FEC frames are manually set to be transmitted after every 「n」 data frames. Manual settings do not take into account constantly changing communication link conditions.

[0004] Data packets are transmitted between a hub and spokes which are data paths. Spokes are installed on moving remote devices such as ships or airplanes, while the hub is within a fixed data center. The path between the hub and the spokes can consist of multiple LEO / MEO / GEO / Starlink satellite links with very dynamic link conditions. Thus, for a given customer data (i.e., browsing or streaming or video call), a traffic class is assigned a level of priority, and based on the link conditions, the customer data of the highest - priority traffic class is transmitted over the best link.

[0005] Considering the movement of spokes and dynamic link conditions due to weather conditions, improved methods and systems for data communication are needed in this art. Adaptive FEC, sometimes referred to as AFEC in this art, is a researched and improved version of FEC in which the system flexibly adjusts the transmission of redundant data packets in response to changes in the data packet loss rate at the receiving end. When an increase in data packet loss is detected, the system can increase the rate at which redundant data packets are transmitted, according to known FEC techniques. [Overview of the project]

[0006] The following is a simplified summary of the Disclosure to provide a basic understanding of some aspects of the Disclosure. This summary is not a comprehensive overview of the Disclosure. It is not intended to identify the main or important elements of the Disclosure or to define the scope of the Disclosure. Its sole purpose is to present some of the concepts of the Disclosure in a simplified form as a prelude to the more detailed explanations that will be presented later.

[0007] Methods and systems for implementing adaptive FEC in a communication network are disclosed. The relevant parts of the communication network may include channels, channel managers, FEC engines, dynamic multiplexed input / multiplexed output transmission systems ("DMTS"), and drop-sides. The DMTS is a decision-based engine that can be used to determine which link to transmit packets over.

[0008] In one embodiment, the FEC layer is located between the DMTS and the channel manager. The DMTS engine controls when FEC parity packets are sent for a given traffic flow. FEC parity packets may be sent across multiple channels, and FEC can be enabled / disabled for each traffic flow. If FEC is disabled for a given traffic flow, all packets of that flow arriving from the DMTS engine are simply forwarded to the channel manager without FEC management.

[0009] The following description and drawings detail specific exemplary embodiments of this disclosure. However, these embodiments represent only a fraction of the various approaches to which the principles of the disclosed systems and methods may be applied, and this disclosure is intended to encompass all such embodiments and their equivalents. Other advantages and novel features of the disclosed systems and methods will become apparent from the following description of the subject matter disclosed herein, when considered in conjunction with the drawings. [Brief explanation of the drawing]

[0010] [Figure 1] This figure illustrates one embodiment of the disclosed system, including a DMTS engine, an FEC engine, and a channel manager. [Figure 2A] This figure illustrates an FEC layer, shown with data flowing in the transmission direction, according to one embodiment. [Figure 2B] This figure illustrates an FEC layer, shown with data flowing in the receiving direction, according to one embodiment. [Figure 3] This figure illustrates an exemplary 32-bit superframe according to one embodiment. [Figure 4] This figure illustrates an exemplary superframe pool of remote grid IDs and flow IDs according to one embodiment. [Figure 5]This figure illustrates an FEC engine that maintains a superframe pool for each unique superframe ID, according to one embodiment. [Figure 6] This diagram illustrates a superframe pool accessed via a hash table according to one embodiment. [Figure 7] This diagram illustrates the information contained in a superframe pool according to one embodiment. [Figure 8] This figure illustrates the sequential arrival of three subframes and a parity frame corresponding to a superframe, according to one embodiment of the disclosed processing system. [Figure 9A] This figure illustrates one implementation of a processing system in which, according to one embodiment, subframes arrive late, are discarded, and are not sent to the DMTS. [Figure 9B] This figure illustrates one implementation of a processing system in which, according to one embodiment, a subframe does not arrive, the frame is regenerated by the FEC, and sent to the DMTS. [Figure 10A] This figure illustrates one implementation of a processing system in which, according to one embodiment, the parity frame of the superframe arrives before the last two subframes arrive. [Figure 10B] This figure illustrates one implementation of a processing system in which, according to one embodiment, the processing system discards a third subframe if it arrives late. [Figure 11] This figure illustrates one implementation of a processing system in which the parity frame of a superframe is not received, according to one embodiment. [Figure 12A] This figure illustrates one implementation of a processing system in which two or more subframes are lost, or one subframe and a parity frame are also lost, according to the first embodiment. [Figure 12B]This figure illustrates one implementation of a processing system in which two or more subframes are lost, or one subframe and a parity frame are also lost, according to the second embodiment. [Figure 12C] This figure illustrates one implementation of a processing system in which two or more subframes are lost, or one subframe and a parity frame are also lost, according to the third embodiment. [Figure 13A] This figure illustrates the relationship between the FEC level (x-axis) and consumed bandwidth (y-axis) after performing forward error correction according to one embodiment. [Figure 13B] This figure illustrates the relationship between the FEC level (x-axis) and packet loss (y-axis) after forward error correction is performed according to one embodiment. [Modes for carrying out the invention]

[0011] The following detailed description and accompanying drawings illustrate and describe several embodiments so that those skilled in the art may utilize the invention. Therefore, the detailed description and illustration of these embodiments are merely illustrative and not intended to limit in any way the scope or protection of the invention. It should also be understood that the drawings are not necessarily to scale, and in some cases details not necessary for understanding this disclosure, such as manufacturing or assembly details, may be omitted. In the accompanying drawings, similar numbers represent similar components.

[0012] A communication system including a DMTS module and an adaptive FEC module is disclosed. The adaptive FEC module includes a transmit module for receiving a first packet and command from the DMTS module, generating parity checks for n first packets, and retransmitting the first packets, along with the parity checks, to a channel manager in the transmit direction.

[0013] The adaptive FEC module also includes a receiving module for receiving a second packet from the channel manager in the receiving direction. The DMTS controls when a parity check is transmitted for a traffic flow, the parity check can be transmitted across multiple channels, and the FEC module can be enabled or disabled for each traffic flow.

[0014] In the disclosed communication system, the channel manager switches sub-channels between the FEC module and the channel side, the channel manager determines the link conditions of the link, including packet loss, latency, and jitter, and the channel manager further determines when the link goes online or offline.

[0015] In the disclosed communication system, the DMTS module controls the enabling or disabling of the FEC module, including when selecting a transmission link to use for transmitting data packets and generating and transmitting a parity check at any point within a given channel flow.

[0016] In the disclosed communication system, the DMTS operates in the transmission direction to determine, for a given traffic, the best link from among the many available links for transmitting data packets, the frequency at which a parity check is transmitted by the transmission module of the FEC module, and the number of N packets for which a parity check is generated, based on the priority of the traffic, jitter, latency, packet loss, bandwidth cost, or demand.

[0017] In the disclosed communication system, the receiving module of the FEC module receives a second data packet including a parity check, processes the second data packet, and regenerates any lost packets.

[0018] In one embodiment of the disclosed communication system, the receiving module regenerates a single lost data packet. In another embodiment, if two or more data packets are lost, the receiving module does not regenerate any of the lost data packets.

[0019] In the disclosed communication system, a first data packet may be transmitted in the transmission direction via the transmission module of the FEC module, which assigns one or more of the first data packets to a superframe pool having multiple subframes. The subframes are XORed to generate one parity frame for each superframe pool.

[0020] In one embodiment, the parity check is added to the superframe pool as a subframe, the subframe may be sent to the channel side via the channel manager, and the parity check subframe is sent as the last subframe frame after all subframes have been sent.

[0021] In one embodiment, the second data packet may be received by the receiving module of the FEC module as a subframe arriving from the channel manager, converted into a packet, and sent to the DMTS module. The receiving module of the FEC module may store a copy of each subframe in the buffer pool of each superframe pool, and parity checks are used to generate any lost subframes. In one embodiment, after all received subframes have been processed by the receiving module of the FEC module, the pool is deleted and the superframe pool is released.

[0022] As shown with reference to Figure 1, in one embodiment, the system 100 of the present invention may include a data or network channel for bidirectional data transfer between a drop side 101 (e.g., a connection point to a LAN associated with a spoke) and a channel side 109, the channel may include one or more data transmission engines, including a channel manager 107, an FEC engine 105, and a DMTS engine 103. The channel may be a data transmission path on a designated WAN circuit (i.e., WiFi, Starlink, 5G, SCPC, TDMA, etc.) and may simultaneously handle data transmission for thousands of users. Data transmitted from the drop side 101 to the channel side 109 may be referred to herein as the transmit (Tx) direction, while data transmitted from the channel side 109 to the drop side 101 may be referred to herein as the receive (Rx) direction. The channel manager 107 may be operable to switch subchannels between the FEC engine 105 and the channel side 109. In one embodiment, the channel manager 107 manages multiple LEO / MEO / GEO / Starlink satellite links. The channel manager 107 determines link conditions such as packet loss, latency, and jitter. The channel manager 107 also determines when the link is online or offline.

[0023] DMTS103 is a decision-based engine that can be used to determine which transmission link to use when transmitting data packets. DMTS103 can also control the activation or deactivation of the FEC engine 105, such as when to transmit FEC parity packets, at any point in a given channel flow. In one embodiment, DMTS103 may operate in the Tx direction. For a given traffic, DMTS103 determines the best link to transmit data packets based on priority and other configured parameters such as bandwidth cost and demand.

[0024] In one embodiment, the FEC layer is located between the DMTS 103 and the channel manager 107. The DMTS engine 103 controls when FEC parity packets are transmitted for a given traffic flow. FEC parity packets may be transmitted across multiple subchannels, and the FEC 105 can be enabled / disabled for each traffic flow. If forward error correction is disabled for a given traffic flow, all packets of that traffic flow arriving from the DMTS engine 103 are simply forwarded to the channel manager 107 without FEC management.

[0025] As shown with reference to Figures 2A and 2B, visualizations of the FEC layer where data flows in the Tx direction (Figure 2A) and the Rx direction (Figure 2B) are illustrated. The Tx direction is responsible for generating the parity frame 201a, and the Rx direction is part of the FEC engine that receives all data frames, including the parity frame 201b, and attempts to regenerate the lost frames. In one embodiment, the FEC engine supports the generation of only one lost frame using the parity frame generated across N subframes. In one embodiment, if two or more data frames are lost, the FEC engine ignores the regeneration of the lost frames.

[0026] According to one embodiment, when a data packet is transmitted in the Tx direction via the FEC engine 205a, the packet 211 arriving from the DMTS may pass through the superframe pool 213 and be converted into multiple subframes 215. The subframes 215 are XORed to generate one parity frame 201a for each superframe pool 213. The DMTS determines how many frames later the parity frame is sent based on link conditions such as packet loss, jitter, and latency, thereby making the FEC system adaptive or dynamic. The subframes 215 are then transmitted to the other side (e.g., from hub to spoke) via the channel side 209a. The parity frame 201a is sent as the last frame after all subframes 215 have been sent. The parity frame is a subframe of the superframe pool. The superframe pool has N data packets that are converted into subframes. All subframes have the same unique superframe pool ID to identify themselves as part of that pool.

[0027] According to one embodiment, on the Rx side of FEC205b, subframes arriving from the channel side are returned to the packet and sent to the DMTS. A copy of each subframe is stored in a buffer pool for each superframe pool 217. The parity frame 201b can then be used to generate any lost subframes, such as subframe 2, which was not received and therefore not stored in the buffer pool, as illustrated in Figures 2A and 2B. After all received subframes have been processed, the pool is cleared and the superframe pool is released.

[0028] FEC Engine - Tx Side

[0029] According to one embodiment, on the Tx side of the FEC engine 205a, a packet 211 arriving from the DMTS engine 103 is assigned to a pool referred to herein as the superframe pool 213. The superframe pool 213 can be uniquely identified by a remote ID and a flow ID (spokes and hubs are identified as "grids"). This information can be extracted from the packet frame itself.

[0030] A superframe pool 413 is maintained for each connection between a spoke and a hub. A given spoke can connect to multiple hubs, and each such connection is identified by a unique remote grid ID. Similarly, a given hub can connect to multiple spokes, and the same logic applies (each such connection is identified by a unique remote grid ID). Therefore, for each remote grid ID and unique traffic class / flow ID, the FEC engine maintains a superframe pool 413 (Figure 4). This helps the FEC engine correctly tag subframes with the superframe ID on the TX side and identify which grid the subframe originated from on the RX side, saving a copy in the correct superframe pool. Consecutive packets arriving with the same remote grid ID and flow ID are assigned to the same superframe pool.

[0031] In one implementation, a hash table is maintained to store frames arriving from different grid IDs and flow IDs. Networking over satellite links is highly dynamic, and frames can arrive at any given time. Therefore, the system of the present invention maintains a pool for each grid ID and flow ID to store frames arriving in different time frames. When each frame arrives, a header is extracted to identify the grid ID / flow ID pool. The FEC engine also extracts a superframe pool ID indicating which superframe pool the subframe belongs to. A one-second timer may be maintained for each grid ID and flow ID pool. If not all packets have been received for a given pool, the timer activates and drops all packets for that pool. The parity frame header contains information about the number of subframes sent as part of the superframe pool.

[0032] Once a packet is allocated to the superframe pool, it is called a subframe and is assigned a unique subframe ID. The FEC engine adds a 6-byte FEC header 521 to each subframe 523 before it is sent to the channel manager (Figure 5).

[0033] The FEC engine also maintains parity frames for each superframe pool, which are generated by applying an XOR operation to N subframes. The DMTS makes the system very flexible because it can be instructed to send parity frames at any time. For example, in one embodiment, the DMTS operates only in the TX direction. Since the DMTS is present on both the spokes and the hub, it takes input from the channel manager regarding the current link conditions and sends the traffic class on the correct link. On the RX side, the system receives packets and simply forwards them to the drop side.

[0034] The ideal condition for avoiding frame loss is that an FEC parity frame is sent for every data packet frame transmitted over the link. This scheme offers nearly 100% chance of recovering any lost frame without retransmission. However, this approach is not recommended because it increases bandwidth (potentially doubling it). Therefore, based on link conditions such as packet loss, latency, and jitter, the DMTS determines how many data packets should be followed by a parity frame. In one embodiment, this variable can be set somewhere between 0 and 32 data packets. If the variable is set to 0, no parity frame is sent. If set to 4, a parity frame is sent after every 4 data packets. With this parity frame scheme, if one packet is lost on the link, the receiver can use the parity frame to regenerate that frame. If two or more packets are lost, the FEC engine can do little more than drop its pool, and the higher layers perform the retransmission of the lost packets.

[0035] For example, if DMTS does not indicate that a parity frame is being sent and the maximum number of subframes, 32, is reached, the FEC engine will automatically send a parity frame according to one embodiment. The number of subframes can vary (i.e., it can be more than 32).

[0036] The superframe pool has the following properties:

[0037] Superframe ID

[0038] Subframe IDs (2 or more)

[0039] Parity Frame

[0040] fec_level

[0041] The fec_level determines whether FEC should be generated and sent for a given flow. This means it can be configured from a configuration file and also from a user interface (UI) where users can disable FEC for a given traffic class. For example, if fec_level is set to "0", no parity will be generated and sent for that flow.

[0042] Superframe ID

[0043] Each superframe pool may use a unique superframe ID to assign to each subframe and parity frame. This is used on the RX side to regenerate any lost frames. In one implementation, the system allows only one lost frame to be regenerated. The DMTS determines how often to send parity frames based on the current link conditions. If link conditions are poor, parity frames are sent frequently, for example, after every 4 or every 5 data packets, but as link conditions improve, parity frames are sent less frequently, for example, after every 24 data packets.

[0044] In one embodiment, the superframe ID may be defined as a 32-bit unsigned integer combining a unique counter and a remote grid ID. In one embodiment, of the 32 bits of the superframe ID, 18 bits may be allocated to the superframe counter and 14 bits may be derived from the grid ID signature (Figure 3).

[0045] The superframe counter helps identify all subframes belonging to the single set from which the parity frame was generated. When a parity frame is sent, the superframe counter is incremented, identifying the next batch of subframes from which the parity frame will be generated. The grid ID is used to identify the uniqueness of the sender, ensuring that two subframes arriving from different grid IDs do not end up in the same pool at the receiver.

[0046] Subframe ID

[0047] A subframe ID can be defined as a 5-bit counter that uniquely identifies each subframe in the superframe pool. The subframe ID is incremented with each new subframe arriving from the DMTS to the FEC engine. In one embodiment, there are up to 32 subframes for a given superframe ID, meaning there is one parity frame and subframes 0 through 31 for a given superframe ID. In one embodiment, if a parity frame is not sent by the 32nd subframe, the FEC engine automatically sends a parity frame after the 32nd subframe and resets the subframe ID to 0 for the next batch corresponding to the superframe ID. The combination of superframe ID and subframe ID helps the receiving end of the FEC engine to regenerate any lost frames, as will be discussed later.

[0048] Data Subframe

[0049] Packets arriving at the FEC engine from the DMTS engine are assigned to the superframe pool and converted into subframes by the FEC engine by adding a 6-byte header to the data packet, as shown in the diagram below (the entire data packet is encapsulated in a subframe with the added header, which is the scope of processing for the received data packet).

[0050] [Table 1]

[0051] According to one embodiment, a 6-byte subframe header is illustrated below.

[0052] [Table 2]

[0053] The GCM header has two parts: a header ID and a message ID.

[0054] HDR ID: 4 bits, Value = GCM_FEC: 1

[0055] MSG ID: 4 bits, value = GCM_FEC_DATA: 1

[0056] A GCM can be defined as a grid header added by each layer. To uniquely identify each layer, the header includes a header ID and a msgID. The message ID of the FEC is either a parity frame or a data frame for the RX side to determine the frame type.

[0057] The subframe ID and superframe ID are assigned from the superframe pool, as discussed above. Three bits in the subframe header are reserved for future use according to one embodiment.

[0058] Parity Frame

[0059] For each new packet arriving from the DMTS engine, the FEC engine generates a subframe, as discussed above, and the FEC engine creates a parity frame by applying an XOR operation to the subframe data with respect to previous subframe data. In one embodiment, a parity frame is created uniquely for each superframe pool.

[0060] In one embodiment, the FEC engine adds an 8-byte parity header to each parity frame, as shown below.

[0061] [Table 3]

[0062] In one embodiment, the 8-byte FEC header includes the following information:

[0063] [Table 4]

[0064] In one embodiment, the GCM header has two parts: a header ID and a message ID.

[0065] HDR ID: 4 bits, Value = GCM_FEC: 1

[0066] MSG ID: 4 bits, value = GCM_FEC_PARITY: 2

[0067] The superframe ID is assigned from the superframe pool and used by the FEC engine's receiver. The total subframe length is the sum of the bytes of all subframe data lengths, plus the subframe data lengths used to generate the XOR data of the parity frame, and the total subframes is the total number of subframes that were XORed to generate the parity frame. Both the total length and the total subframes are used by the FEC engine's receiver to regenerate any lost subframes.

[0068] FEC Engine - Rx Side

[0069] In one embodiment, the primary functions of the receiving side (Rx) of the FEC engine are buffer management and the regeneration of any lost frames. The FEC engine may store all received subframes for a given set of superframe IDs until it is known that all subframes have arrived (the parity frame contains this information). Each frame arriving at the FEC engine from the channel side is checked to determine whether it is a parity frame or a data frame, which can be determined from the FEC header added to the frame, as this indicates whether it is a parity frame or a data frame. If the received frame is a data frame, a copy of the subframe is created and the original subframe is sent to the DMTS engine to avoid delay. Header information is extracted from the copy of the data subframe and it is determined which superframe ID the header information corresponds to. As shown with reference to Figure 6, that superframe ID is used as key 641 to retrieve the superframe pool 623 by looking up hash table 621.

[0070] Rx Super Frame Pool

[0071] In one embodiment, the FEC engine maintains a superframe pool for each unique superframe ID (Figure 5). The superframe ID is extracted from the subframe header of a given dataframe. The superframe pool 623 can be accessed via a hash table 621, as illustrated in Figure 6. The information contained in the superframe pool is illustrated in Figure 7.

[0072] FEC algorithm

[0073] In one embodiment, if no superframe pool is found for a given key, a new superframe pool is created and stored in a hash bucket (623, Figure 6). If a subframe received from a channel by the FEC engine is the first subframe of a given superframe ID, the FEC engine creates a new buffer pool and stores this data subframe in the pool for later use.

[0074] As shown with reference to Figure 7, for all consecutive data frames arriving from a channel with a given superframe ID 757, the FEC engine stores copies of its subframes in a buffer pool. At this point, the FEC engine does not know the number of subframes corresponding to a given superframe ID because it needs to wait to receive the parity frame. As soon as the parity frame 751 is received by the FEC engine, the FEC engine checks whether all subframes have arrived 755.

[0075] In one embodiment, if there are N-1 subframes received by the FEC engine, the FEC engine regenerates the single lost frame in its pool and sends it to the drop side. If two or more subframes are lost, the FEC engine discards its pool. Once all subframes have been received by the FEC engine, the FEC engine deletes all subframes, frees the buffer pool, deletes the superframe pool, and removes the corresponding entries from the hash table.

[0076] If a parity frame arrives before N-1 subframes, the FEC engine can store the parity frame and later decide whether to regenerate any lost frames. If a subframe arrives after the corresponding parity frame has been received, the FEC engine recognizes the expected frame for its pool and regenerates the last frame as soon as N-1 frames arrive, without waiting for the last frame to arrive. If the last frame arrives after regeneration, the actual frame is discarded and not forwarded to the DMTS engine. The logic in this specification is that when the FEC engine receives N-1 subframes and a parity frame, it regenerates the last subframe that it was supposed to receive, instead of waiting for a 1-second timer to expire. Thus, if the pool contains 4 subframes and 1 parity frame, and the Rx side receives frames 1, 3, 4 and the parity frame, it regenerates that frame without waiting for a 1-second timer to expire, instead of waiting for the second subframe to arrive.

[0077] In one embodiment, as soon as the first subframe arrives at the FEC engine, the FEC engine starts a 200-millisecond timer, and when the next subframe arrives, the timer is pushed for another 200 milliseconds. If the FEC engine does not receive a subframe within the 200-millisecond limit, the timer expires. When the timer expires, all subframes are deleted, and the timer enters a DISCARD_STATE state for 1 second. If any subframe arrives after the timer has entered the DISCARD_STATE state, a copy of the subframe is not added to the buffer pool, and the received subframe is discarded. After the DISCARD_STATE timer expires, a cleanup operation is performed, and the buffer pool is cleared.

[0078] Exemplary Implementation

[0079] In all of the following exemplary implementations demonstrating how the FEC engine operates, a parity frame is generated for three subframes.

[0080] First exemplary implementation: For superframe ID 1, after all three subframes have been received, the FEC parity frame is received.

[0081] In the implementation illustrated in Figure 8, for superframe ID 1, all three subframes (859-863) and the parity frame 801 arrive sequentially. A copy of each subframe is stored in the buffer pool for a given superframe ID:1 within the superframe pool. When the first subframe arrives, a timer, which is part of the FEC engine, starts for 200 milliseconds and continues to extend as new subframes arrive. After the parity frame arrives, the FEC engine recognizes the total number of frames corresponding to the superframe being processed (from the parity frame, the FEC engine obtains this information from the parity frame header and determines which superframe pool it belongs to), and once all frames have arrived, the FEC engine cleans up as follows.

[0082] - Stop the timer

[0083] - Delete all subframes

[0084] - Delete buffer pool memory

[0085] - Remove the superframepool entry from the hash table.

[0086] - Delete the superframe pool with superframe ID 1.

[0087] Second exemplary implementation: For superframe ID 2, after N-1 subframes have been received, the FEC parity frame is received.

[0088] In the implementations illustrated in Figures 9A and 9B, the algorithm operates as follows:

[0089] 1. For superframe ID 2, the first two subframes (959 and 961) and the parity frame arrive in sequence.

[0090] 2. A copy of each subframe is stored in the buffer pool for the given superframe id:2 within the superframe pool.

[0091] 3. A 200-millisecond timer starts when the first subframe arrives and continues to extend as new subframes arrive.

[0092] 4. After the parity frame arrives, the FEC engine identifies that one subframe is missing and generates the missing subframe 3 (963).

[0093] 5. After the parity frame arrives, the following cleanup operations are performed.

[0094] a. Stop the timer.

[0095] b. Delete all subframes.

[0096] c. Remove buffer pool memory

[0097] d. If subframe 3 arrives late, initiate a 1-second DISCARDTIME_WAIT timeout to discard it.

[0098] 6. In the implementation illustrated in Figure 9A, if subframe 3 arrives late, the FEC engine knows that it has already regenerated the frame, so subframe 3 is discarded and not sent to the DMTS.

[0099] 7. In the implementation illustrated in Figure 9B, if subframe 3 does not arrive, the scenario is acceptable because the FEC engine has already regenerated the frame and sent it to the DMTS.

[0100] 8. When the DISCARDTIME_WAIT timer expires, the following cleanup process is performed.

[0101] a. Remove the superframepool entry from the hash table.

[0102] b. Delete the superframe pool with superframe ID 1.

[0103] Third exemplary implementation: For superframe ID 3, the FEC parity frame is received before N-1 subframes are received.

[0104] In the implementations illustrated in Figures 10A and 10B, the algorithm operates as follows.

[0105] 1. Parity frame 1001 of superframe ID 3 arrives before the last two subframes arrive.

[0106] 2. When the first subframes (1001 and 1063) arrive, a 200-millisecond timer is started (Figure 10A).

[0107] 3. When the parity frame arrives, the FEC engine will recognize that two or more subframes are missing and will need to wait for the additional subframes to arrive.

[0108] 4. The FEC engine will retain the parity frame and wait for the subframe to arrive.

[0109] 5. The FEC engine has determined the expected number of frames (extracted from the parity frame header), so it also updates the expected_frame field in superframe_pool.

[0110] 6. When a new subframe arrives, the FEC engine checks whether it has received N-1 subframes. If not, it continues to add subframes to the buffer pool and extends the 200-millisecond timer. The logic herein is that the FEC engine can always check whether it has received all N subframes. If not, the FEC engine checks whether it has received at least N-1 subframes and parity frames so that it can generate the missing subframes.

[0111] 7. When the FEC engine receives N-1 frames, it regenerates the last subframe and performs a cleanup operation as follows:

[0112] a. Stop the timer.

[0113] b. Delete all subframes.

[0114] c. Remove buffer pool memory

[0115] d. Initiate a 1-second DISCARDTIME_WAIT timeout to discard subframe 3 if it arrives late (Figure 10B).

[0116] Fourth exemplary implementation: For superframe ID 4, the FEC parity frame is not received.

[0117] In the implementation illustrated in Figure 11, the algorithm operates as follows:

[0118] 1. The parity frame for Superframe ID 4 is not received.

[0119] 2. In this case, the 200-millisecond timeout expires, and since no parity frame is received, the FEC engine has no way of determining whether or not there are any missing frames.

[0120] 3. In this exemplary implementation, cleanup is performed within the timer expiration routine.

[0121] a. Delete all subframes (1159-1163).

[0122] b. Delete buffer pool memory.

[0123] c. Initiate a 1-second DISCARDTIME_WAIT timeout to discard frames that arrive late.

[0124] 4. If the parity arrives late, the parity is simply discarded, and the FEC engine waits for the 1-second timer to expire.

[0125] 5. If a parity frame does not arrive, a 1-second timer expires, all copies of subframes are deleted, and the pool is cleaned up.

[0126] 6. When the DISCARDTIME_WAIT timer expires, the following cleanup operations are performed.

[0127] a. Remove the superframepool entry from the hash table.

[0128] b. Delete the superframe pool with superframe ID 1.

[0129] Fifth exemplary embodiment: Lost subframe and / or parity frame of superframe ID 5

[0130] In the implementations illustrated in Figures 12A and 12C, two or more subframes are lost (Figure 12B), or one subframe and the parity frame are also lost (Figures 12A and 12C). In all these cases, the FEC engine is unable to perform much and simply waits for the timer to expire. Once the timer expires, cleanup operations are performed within the timer expiration routine.

[0131] a. Delete all subframes.

[0132] b. Delete buffer pool memory.

[0133] c. Initiate a 1-second DISCARDTIME_WAIT timeout to discard frames that arrive late.

[0134] Figure 13A illustrates the relationship between FEC level (x-axis) and bandwidth consumption (y-axis), and Figure 13B illustrates the relationship between FEC level (x-axis) and packet loss after FEC is performed (y-axis) according to one embodiment. As shown with reference to Figures 13A and 13B, the term "FEC level" refers to the number of packets that are XORed to generate parity check packets. This means, for example, that at FEC level 1 (1331), a parity check is also sent for each data packet transmitted, and the required network bandwidth is high (1333, see Figure 13A), while as the FEC level increases to 6 (1335), the required bandwidth begins to decrease sharply (1337, see Figure 13A). This does not necessarily mean that FEC level 6 is always selected as a set parameter, because the selected FEC level is a trade-off between bandwidth and link conditions such as packet loss and latency. For example, if the FEC level is 1, no significant packet loss will occur (see 1339, Figure 13B), but since approximately 50% of the network bandwidth will be used to send parity checks, end users will experience slow network connectivity.

[0135] The frequency at which DMTS determines the FEC level is set to every second. This approach is adopted to address scenarios where sudden traffic bursts occur, as it is desirable to avoid jeopardizing other types of traffic by potentially eliminating the use of all FEC levels entirely.

[0136] If the packet loss rates are 4.7% and 26.5%, applying FEC does not directly translate them from 4.7% to 26.5%. In fact, if a given FEC level is set to 6, a link with 10% packet loss may improve to 4.7%, and a link with 30% packet loss may improve to 26.5%. Therefore, the higher the packet loss, the lower the required FEC level. A lower FEC level increases bandwidth consumption, resulting in a trade-off as discussed above. The DMTS engine effectively addresses this trade-off by considering traffic type priority, packet loss threshold, and real-time demand.

[0137] In some implementations, non-transient computer-readable media, when executed by a processor, may contain instructions that cause the processor to execute one of the methods described herein, including methods executed by the DMTS engine or module, the FEC engine or module, or the channel manager engine or module. Alternatively, the DMTS, FEC, and / or channel manager may be implemented in a purely hardware configuration or a combination of both.

[0138] The technologies discussed herein refer to servers, databases, software applications, and other computer-based systems, as well as the actions taken and the information transmitted between such systems. Those skilled in the art will recognize that the inherent flexibility of computer-based systems allows for various possible configurations, combinations, and divisions of tasks and functions between components. For example, the server processes discussed herein may be implemented using a single server or using multiple servers operating in combination. Databases and applications may be implemented on a single system or distributed across multiple systems. Distributed components may operate sequentially or in parallel.

[0139] While the subject matter has been described in detail with respect to specific embodiments, those skilled in the art will recognize that, having understood the foregoing, modifications, variations, and equivalents to such embodiments can be readily created. Therefore, the scope of this disclosure is examples, not limitations, and this disclosure does not exclude the inclusion of such modifications, variations, and / or additions to the subject matter that would be readily apparent to those skilled in the art.

Claims

1. It is a communication system, Dynamic Multiple Input / Multiple Output Transmission System (DMTS) module, It comprises an adaptive forward error correction (FEC) module, and the adaptive forward error correction (FEC) module is The system includes a transmission module for receiving a first packet and command from the DMTS module, generating parity checks for n of the first packets, and retransmitting the first packets, along with the parity checks, to the channel manager in the transmission direction, and further In the receiving direction, it includes a receiving module for receiving a second packet from the channel manager, The DMTS controls when parity checks are sent to the traffic flow. The parity check may be transmitted across multiple channels. The FEC module is a communication system that can be enabled or disabled for each traffic flow.

2. The communication system according to claim 2, wherein the channel manager switches subchannels between the FEC module and the channel side.

3. The communication system according to claim 3, wherein the channel manager determines the link conditions of the link, including packet loss, latency, and jitter, and the channel manager further determines when the link is online or offline.

4. The communication system according to claim 1, wherein the DMTS module controls the enabling or disabling of the FEC module, including selecting a transmission link to be used for transmitting data packets and generating and transmitting the parity check at any point in a given channel flow.

5. The communication system according to claim 4, wherein the DMTS operates in the transmission direction to determine, for a given traffic, the best link from many available links to transmit data packets, the frequency at which parity checks are sent by the transmitting module of the FEC module, and the number of packets for which the parity checks are generated, based on traffic priority, jitter, latency, packet loss, bandwidth cost, or demand.

6. The communication system according to claim 1, wherein the receiving module of the FEC module receives the second data packet including the parity check, processes the second data packet, and regenerates any lost packets.

7. The communication system according to claim 6, wherein the receiving module regenerates a lost data packet.

8. The communication system according to claim 6, wherein the receiving module does not regenerate any of the lost data packets if two or more data packets are lost.

9. The communication system according to claim 1, wherein the first data packets are transmitted in the transmission direction via the transmission module of the FEC module, the transmission module assigns one or more of the first data packets to a superframe pool having a plurality of subframes, the subframes are XORed, and one parity frame is generated for each superframe pool.

10. The communication system according to claim 9, wherein the parity check is added to the superframe pool as a subframe.

11. The communication system according to claim 10, wherein the subframe is transmitted to the channel side via the channel manager, and the parity check subframe is transmitted as the last subframe after all subframes have been transmitted.

12. The communication system according to claim 9, wherein the second data packet is received by the receiving module of the FEC module as a subframe arriving from the channel manager, converted into a packet, and transmitted to the DMTS module.

13. The communication system according to claim 12, wherein the receiving module of the FEC module stores a copy of each subframe in the buffer pool of each superframe pool, and the parity check is used to generate any lost subframes.

14. The communication system according to claim 13, wherein after all received subframes have been processed by the receiving module of the FEC module, the pool is deleted and the superframe pool is released.

Images