Forward Error Correction (FEC) for SCHC framework

FEC in SCHC FEC is a method employed to control errors in packet transmission by embedding additional redundant information within transmitted fragments, thereby reducing the chances for the destination node to request retransmission of missing fragments. Employed in satellite communications and mobile networks, FEC mechanisms use encoding algorithms that allow the destination node to detect errors and often to recover missing components (i.e., to correct the errors). FEC can be classified into intra-frame, where error correction codes add redundancy inside a packet to correct errors on individual packets, and inter-frame (or inter-fragment), where additional redundant frames are transmitted. LoRa technology employed the intra-frame FEC. Indeed, the intra-frame FEC of LoRa uses Coding Rates (CR) 4/5 to 4/8. In this document, a generic inter-frame FEC mechanism is presented in order to obtain higher Data Delivery Rate (DDR). SCHC framework can be applied over lossy radio links such as LPWAN where some of the fragments of a SCHC packet can be lost, which may lead to the failure of the reception of the whole SCHC packet (notably in the case of No-ACK mode). Therefore, incorporating FEC into SCHC allows the destination node to increase the chances for the destination node to recover the missing SCHC fragments without the need for the sender to retransmit the missing SCHC fragments. While FEC mechanisms increase network reliability in lossy networks, they also introduce additional costs. This is because sending additional fragments demands energy and bandwidth. Furthermore, the increase in traffic can ultimately lead to overflow in the transmission queues of relay nodes when such nodes exist. Consequently, the implementation of FEC schemes in networks with constrained resources warrants careful consideration.

XORFEC Algorithm XORFEC employs the Exclusive OR (XOR) operator (⊕) within its FEC mechanism to produce an extra fragment for a fragmented IPv6 SCHC packet. This supplementary fragment contains the redundant information. This additional fragment is sent after the original fragments of the SCHC packet and allows the destination node to detect a potential loss of an original fragment and to recover it, mitigating thus the scenario where the loss of one fragment leads to the entire packet being lost and/or to reduce the number of fragment retries required to avoid the entire packet being lost.

The XOR Operator XOR is a logical operator employed in encoding mechanisms, blending information from multiple fragments during encoding and subsequently decoding the encoded fragments upon reception. XOR is a binary operator, and when applied to fragments that consist of series of bits, is applied bitwise. The key property of XOR utilized in XORFEC for fragment recovery is that applying XOR to the result of an initial XOR operation and one of its input values (i.e., of the first XOR) yields the other input value, see an eample below: B = A ⊕ (A ⊕ B)
A = B ⊕ (A ⊕ B) Indeed, if a SCHC packet is fragmented into two fragments A and B, the additional fragment C generated by the source node will be: C = A ⊕ B In this case, if the destination node receives the A and C fragments but does not receive the B fragment, it can recover B fragment by applying the XOR operator to the successfully received fragments. Note that this function can be generalised to SCHC packets that consists of more than two fragments. Indeed, with k original fragments (F1, F2, F3, ..., Fk), the additional fragment F_additional will be: F_additional = F1 ⊕ F2 ⊕ F3 ⊕ ... ⊕ Fk In a scenario where the destination node receives successfully all fragments except Fi, then it can recover the latter by applying the XOR operator to the successfully received fragments, as it is shown below: Fi = (F1 ⊕ ... ⊕ Fi−1 ⊕ Fi+1 ⊕ ... ⊕ Fm) ⊕ F_additional The main limitation of the XORFEC algorithm is that the loss tolerance is one missing fragment. Indeed, in the previous example of k fragments, the recovery of Fi is only possible if no more than one fragment is lost.

XORFEC Operation Example in LPWAN

XORFEC over No-ACK mode In No-ACK mode, a SCHC Packet is first fragmented into k original fragments and the additional fragment (i.e., F_additional) is generated by applying the XOR operator to these k fragments. In , the example (i.e., Figure 29) from of No-ACK mode of a SCHC Packet that needs 5 SCHC Fragments (and where FCN is 1 bit wide) is adapted when XORFEC is applied to all 5 SCHC Fragments.

| 1st Fragment (received) |-----FCN=0----->| 2nd Fragment (received) |-----FCN=0--X-->| 3rd Fragment (not received) |-----FCN=0----->| 4th Fragment (received) |-----FCN=0----->| 5th Fragment (received) |---FCN=1 + RCS->| The XOR Fragment with Integrity check: success (End) ]]> Thus, even if with No-ACK mode there is no feedback from the receiver, by employing XORFEC, the receiver may successfully reassemble the original SCHC Packet. As a result, both the network reliability and the spectrum/bandwidth utlization efficiency are increased for a certain range of loss/error rates.

XORFEC over ACK-on-Error mode In ACK-on-Error mode, the XOR is applied per Window. In case, when there is one Tile per Fragment, then one additional fragment is introduced per Window. In , the example (i.e., Figure 31) from of ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles is adapted when XORFEC is applied on ACK-on-Error mode is illustrated. A SCHC Packet is fragmented in 11 Tiles, with one Tile per SCHC Fragment, N=3, WINDOW_SIZE=7, and two lost SCHC Fragments.

| 1st Tile/Fragment (received) |-----W=0, FCN=5----->| 2nd Tile/Fragment (received) |-----W=0, FCN=4----->| 3rd Tile/Fragment (received) |-----W=0, FCN=3----->| 4th Tile/Fragment (received) |-----W=0, FCN=2--X-->| 5th Tile/Fragment (not received) |-----W=0, FCN=1----->| 6th Tile/Fragment (received) |-----W=0, FCN=0----->| The additional (XOR) Fragment (no ACK) |-----W=1, FCN=6----->| 7th Tile/Fragment (received) |-----W=1, FCN=5----->| 8th Tile/Fragment (received) |-----W=1, FCN=4--X-->| 9th Tile/Fragment (not received) |-----W=1, FCN=3----->| 10th Tile/Fragment (received) |-----W=1, FCN=2----->| 11th Tile/Fragment (received) |- W=1, FCN=7 + RCS ->| The XOR Fragment with Integrity check: success |<-- ACK, W=1, C=1 ---| C=1 (End) ]]> As it can be calculated, in the original example, there were in total 16 transmissions with two fragment losses, i.e., 11 original transmissions from the Sender, two retransmissions from the Sender, and three acknowledgments from the Receiver. In this XORFEC based approach, there are in total 14 transmissions, i.e., 11 original fragment transmissions from the Sender, two additional XOR transmissions from the Sender, and the ACK at the end from the Receiver. As a result, thanks to the XORFEC, the communication was reduced by two transmissions. Indeed, the ACK transmissions with the Bitmap of the missing fragments was not transmitted, and consequently the retransmissions of the missing fragments.

XORFEC over ACK-Always mode Similar to ACK-on-Error mode, in ACK-Always, the XOR is applied per Window. In case, when there is one Tile per Fragment, then one additional fragment is introduced per Window. In , the example (i.e., Figure 34) from when XORFEC is applied on ACK-Always is illustrated. A SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7 and two lost SCHC Fragments.