SCHC Rule Format for Forward Error Correction (FEC) in Fragmentation

Introduction A SCHC fragmentation session, besides allowing for larger payload transfer, protects against the loss of fragments through its various Acknowledgment modes, except in No-Ack where lost fragments can never be recovered. In Ack-Always or Ack-On-Error, downlink messages are necessary to identify lost fragments. As some communication technologies are highly asymmetrical (e.g. LPWANs), it may be desirable to use FEC codes to limit trafic in one direction (e.g. increase the numebr of uplinks to avoid downlinks). Simply repeating messages may be sub-optimal, depending on the radio conditions. This draft introduces a new SCHC Rule type - the FEC RuleID. A SCHC FEC Fragmentation Rule is bound to a SCHC Fragmentation Rule, complementing it with the FEC functionality. The SCHC data sent with the FEC RuleID do not have a meaning or sense on their own. Instead, they provide the necessary sequence to recover lost fragments.

Format The format of a SCHC FEC Fragment is the following:

Operation The FEC Fragmentation Rule is bound to a Fragmentation Rule. There MUST be a RuleID allocated in the same space as the RuleID of the Fragmentation Rule to which it is bound. The size of DTag, W and FCN MUST be the same as the bound Fragmentation Rule.) The FEC Fragmentation operates over a FEC Window (FW), which are the Tiles over which the FEC Fragment is calculated. The FEC Window consists of FW tiles. The size of the FW can be fixed (e.g. in the Profile) or variable (e.g. depending on the MTU). The FEC Fragment allows to recover some (or all) of the Tiles in its FEC Window. The DTag, W and FCN values indicate which is the LAST tile of the FEC Window to which a given FEC Fragment refers to. A SCHC FEC Fragmentation Profile defines the algorithm to use for the calculation of the FEC and relevant parametrs. It is RECOMMENDED that a FEC Fragment fits in a single MTU. A change in the MTU during a fragmentation session may lead to a change in the FEC Window size. Change in the radio conditions may as well influence the FEC Window size. The SCHC FEC Fragmentation Profile MUST define the behavior in case of dynamic change of the MTU and/or the FEC Window size. A RECOMMENDED behavior is to restart the FEC calculation, starting with the first Tile after the FEC Window size was changed. If the FEC Window size or the MTU change dynamically all participating SCHC End-points MUST have a way of knowing this. For example, in LoRaWAN a MAC Command may indicate change of the DataRate, which in turn changes the MTU, which in turn may change the FEC Window Size. In this case, the L2 technology provides the protocol machinery for this update. A sender MAY send a FEC Fragment at any moment. Typically, a FEC Fragment is sent after each N_FW number of fragments. However, this may depend on the radio conditions and the network operator. Note that the SCHC FEC Fragmentation operates only with SCHC Fragments. Other types of messages (ACK, All-0, All-1, Abort, etc.) are not covered by this draft. SCHC FEC Fragmentation fields (DTag, W, FCN) MAY be aligned with the corresponding SCHC Fragmentation fields. It is possible, however, to send FEC Fragments, which are not aligned with the bound SCHC Fragmentation. For example, a FEC fragment can be sent before the end of a SCHC fragmentation session, covering the final tiles that are piggybacked in an All-1 message.

| Init SCHC FEC | | Fragmentation | | Fragmentation | | Session | | Information | | Start | | for that Session | | (Init DTag, W, | | (Init FEC.DTag, | | FCN) | | FEC.W, FEC.FCN) | +------------------+ +--------+---------+ | +--------------------------------+ | v +-------------------+ No +------------------+ |SCHC Fragment | ---------> | Release SCHC FEC | | Session Ongoing |<----+--+ | Ressources for | +---+---------------+ | | | this session.End.| | Yes | | +------------------+ v | | +-------------------+ No | | +------------------+ | Send FEC Fragment?|---->+ +<--| Chose FEC.DTag, | | | | FEC.W, FEC.FCN, | | Use algorithm | | Calculate FEC, | | to decide to send | | | | FEC Fragment | Yes | Send FEC Fragment| | or not. |----------> | | +-------------------+ +------------------+ ]]>

| Init SCHC FEC | | New SCHC | | Fragmentation | | Fragmentation | | Information | | Session | | for that Session | | (Init DTag, W, | | (Init FEC.DTag, | | FCN) | | FEC.W, FEC.FCN) | +------------------+ +--------+---------+ | +--------------------------------+ | v +-------------------+ No +------------------+ | SCHC Fragment | ---------> | Release SCHC FEC | | Session Ongoing |<----+--+ | Resources for | +---+---------------+ | | | this session. End| | | | +------------------+ v | | v | | +-------------------+ No | | +------------------+ | Receive FEC |---->+ | | Use DTag,W,FCN | | Fragment | | | to determine FEC | | | | | Window position. | | | Yes | | If possible, | | |----------> | recover missing | | | | | fragment(s). | +-------------------+ | +--------+---------+ +--+ | ^ v | +------------------+ | | FEC integrated in| | | Fragmentation ? | | +------------------+ | | +--------------------------------+ | | | Yes v | No v +-------------------+ | +------------------+ | Process | | | Send recovered | | SCHC Fragment | | | SCHC Fragment | | as per |---->+<-----| to Fragmentation | | Fragmentation FSM | | process | +-------------------+ +------------------+ ]]>

SCHC FEC Fragment Profile for XOR over RFC9011 Uplink Fragmentation One simple method for constructing a FEC fragment between SCHC fragments of the same size is to apply an Exclusive OR (XOR) operation on every two SCHC fragments and send the resulting value as the FEC fragment as an additional message. A receiver needs any 2 of the three fragments to recover the initial two fragments. This example provides a SCHC FEC Fragment Profile bound to RFC9011 Uplink Fragmentation. SCHC FEC Fragment Rule ID = 30, bound to SCHC Fragment RuleID = 20. SCHC fragmentation reliability mode: ACK-on-Error. SCHC header size: 2 bytes (the FPort byte + 1 additional byte). RuleID: 8 bits stored in the LoRaWAN FPort (cf. Section 5.2). DTag: Size T = 0 bits, not used (cf. Section 5.6.1). Window index: 4 windows are used, encoded on M = 2 bits. FCN is 6 bits. Tile size: 10B The tiles per SCHC Fragment are denoted with Tiles per Fragment: TF = MTU size / Tile size (10). FEC Window (FW) is TF*2 tiles. The FEC Fragment contains TF tiles. The default alrogithm to determine when to send a SCHC FEC Fragment is: * One SCHC FEC Fragment for every two SCHC Fragments. The FEC Window covers the tiles of the two latest SCHC Fragments. The FEC is calculated as follows: * The FEC Window is divided in two halves, Left and Right, or Fragment A Tiles and Fragment B Tiles. * The FEC is a bitwise XOR operation between the two halves. * FEC = Left XOR Right. SCHC Packet: 250 Bytes MTU: 50 Bytes TF = MTU / Tile size = 50 / 10 = 5 tiles per fragment

In this example, there will be two SCHC FEC Fragments generated after SCHC Fragment 2 and SCHC Fragment 4. SCHC FEC Fragment 1 will have the following format:

If we illustrate the example based on the SCHC Fragments, we have the following:

| Fragment 1 |-----Frag (RuleID 20), W=0, FCN=19----->| Fragment 2 |-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 1 tiles XOR Fragment 2 tiles |-----Frag (RuleID 20), W=0, FCN=14----->| Fragment 3 |-----Frag (RuleID 20), W=0, FCN=9------>| Fragment 4 |-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 3 tiles XOR Fragment 4 tiles |-----Frag (RuleID 20), W=0, FCN=4------>| Fragment 5 |-----Frag (RuleID 20), W=0, FCN=63+RCS->| Integrity check: success |<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=1 (End) ]]>

| Fragment 1 |-----Frag (RuleID 20), W=0, FCN=19--xx | Fragment 2 lost |-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 1 tiles XOR Fragment 2 tiles | | Recover Fragment 2 from FEC (Fragment 1 XOR FEC) |-----Frag (RuleID 20), W=0, FCN=14--xx | Fragment 3 lost |-----Frag (RuleID 20), W=0, FCN=9------>| Fragment 4 | | Recover Fragment 3 from FEC (Fragment 4 XOR FEC) |-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 3 tiles XOR Fragment 4 tiles |-----Frag (RuleID 20), W=0, FCN=4------>| Fragment 5 |-----Frag (RuleID 20), W=0, FCN=63+RCS->| Integrity check: success |<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=1 (End) ]]>

| FEC = Fragment 1 tiles XOR Fragment 2 tiles | | Cannot recover. Discard. |-----Frag (RuleID 20), W=0, FCN=14--xx | Fragment 3 lost |-----Frag (RuleID 20), W=0, FCN=9------>| Fragment 4 | | Recover Fragment 3 from FEC (Fragment 4 XOR FEC) |-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 3 tiles XOR Fragment 4 tiles |-----Frag (RuleID 20), W=0, FCN=4------>| Fragment 5 |-----Frag (RuleID 20), W=0, FCN=63+RCS->| Integrity check: failed |<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=0, Bitmap: 0000000000111111111111111 |-----Frag (RuleID 20), W=0, FCN=24--xx | Fragment 6 |-----FEC (RuleID 30), W=0, FCN=15----->| FEC = Fragment 5 tiles XOR Fragment 6 tiles | | Recover Fragment 6 from FEC (Fragment 5 XOR FEC) |-----Frag (RuleID 20), W=0, FCN=19----->| Fragment 7 |<----Frag (RuleID 20), ACK, W=0, C=1 ---| C=1 (End) ]]>

References The IETF documents referred to here are .

Security Considerations No security considerations.

IANA Considerations