Skip to main content

Forward Error Correction (FEC)

Forward Error Correction (FEC) is a technique used to add redundancy to packets so that they can be rebuilt if they are lost or corrupted. Put simply, FEC adds extra instructions to each packet that tell a receiver how to rebuild the packet if some data is missing or incorrect.

As FEC is typically considered a part of LLC in the Data Link Layer of the OSI model, it is usually handled on a near-physical level. For instance, BLE uses FEC in its Coded PHYs. Regardless, we still define a minimum level of FEC in the Repair Layer to ensure that all packets are protected by at least this level of redundancy. This is to ensure that even if the physical layer does not provide FEC, the network can still function correctly. For some mediums, the repair layer may intelligently choose to add or remove FEC based on what the physical layer provides. Additionally, on less reliable mediums, the repair layer may choose to add more FEC than the physical layer provides or than the minimum amount specified is to ensure that fewer packets are lost.

Challenges​

While using physical layers like BLE that provide FEC out of the box, the repair layer will need to do one of the following, ordered from most to least desirable:

  1. Be programmed (even on a hardware/firmware level!) to understand this physical layer and rebuild packets (as BLE's FEC is done after encryption, repeating nodes should attempt to repair packets before rebroadcasting them)
  2. Attempt to force the application layer/package layer to not use the physical layer's FEC and instead use the repair layer's FEC (i.e. tell things like BLE to not use its built-in FEC)
  3. Wrap all packets in a new layer of FEC that can be understood by the physical layer (lowering the firmware complexity at the cost of added overhead and lower available message sizes)
  4. Pass packets upstream to a device that can understand the protocol and repair them (i.e. send messages to a phone to check and repair if need-be before relaying them)

For the most part, the firmware should already have the ability to understand the physical layer's FEC and rebuild packets. For example, if a hardware device like our Wave Clip has a BLE radio it can relay packets over, it should be able to understand the FEC and rebuild packets as needed. The same applies to things like LoRa. The clear outlier here is devices we are attempting to be compatible with but do not have the ability to modify the firmware of.

Our Role​

Since most(?) of the mediums we plan to initially operate on include some level of FEC by default, our repair layer will need to be able to both implement our own FEC wrapper where necessary and understand the FEC of any physical layers it is operating on. Most of this will be done in the firmware of the devices we are building via the drivers and libraries it is bundled with. Our main role will be to ensure the drivers are configured to use FEC properly and to test that the repair layer is able to rebuild packets as needed.

Second to this, we will need to ensure that the repair layer is able to intelligently add or remove FEC as needed. This will be done by monitoring the network and adjusting the amount of FEC added to packets based on the reliability of the medium. For instance, if a device is operating on a medium that is known to be unreliable, the repair layer may choose to add more FEC than the physical layer provides to ensure that fewer packets are lost. On the other hand, if a device is operating on a medium that is known to be reliable, the repair layer may choose to remove FEC to reduce overhead. The repair layer will also be able to observe statistical patterns in packet loss and adjust the amount of FEC added to packets based on these patterns in real-time. This specific weights of this algorithm are a low priority for us to develop at the moment and will most likely be informed by real-world testing data, so they are not included in this document at this time.