Internet-Draft | SCHC Rule Format for Forward Error Corre | September 2024 |
Pelov, et al. | Expires 13 March 2025 | [Page] |
This document defines a new Rule Format for Forward Error Correction (FEC) of SCHC Fragments. It is backwards compatible with RFC8724, as an implementation which does not have the necessary FEC code implementations can simply ignore the messages with this new RuleID format.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 March 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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:¶
No security considerations.¶