Internet-Draft SCHC Rule Format for Forward Error Corre September 2024
Pelov, et al. Expires 13 March 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-pelov-schc-fragmentation-fec-rule-format-00
Published:
Intended Status:
Informational
Expires:
Authors:
A. Pelov
IMT Atlantique
J. A. Fernandez
IMT Atlantique
Q. Nguyen
Actility

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

Abstract

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.

Status of This Memo

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.

▲

Table of Contents

1. 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.

2. Format

The format of a SCHC FEC Fragment is the following:

|- SCHC FEC Fragment Header -|
         |-- T --|-M-|-- N --|
+-- ... -+- ... -+---+- ... -+--------...-----------+~~~~~~~~~~~~~~~~~~~~
| RuleID | DTag  | W |  FCN  | FEC Fragment Payload | padding (as needed)
+-- ... -+- ... -+---+- ... -+--------...-----------+~~~~~~~~~~~~~~~~~~~~
Figure 1: SCHC FEC Fragment Format

3. 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.


  Fragment A              Fragment B           FEC Fragment
+------------------+  +------------------+  +-----------------+
| RuleID = 20/8    |  | RuleID = 20/8    |  | RuleID = 30/8   |
+------------------+  +------------------+  +-----------------+
| W | FCN | Frag. A|  | W | FCN | Frag. B|  | W | FCN | FEC   |
| 0 | 62  | Tiles  |  | 0 | 50  | Tiles  |  | 0 | 39  | Tiles |
+------------------+  +------------------+  +-----------------+
           \       \           /        /             /      /
            \       \         /        /             /      /
             \       \       /        /             /      /
              +-------+     +-------+              +------+
              |Frag. A| XOR |Frag. B|      =>      |FEC   |
              |Tiles  |     |Tiles  |              |Tiles |
              +-------+     +-------+              +------+
              ^12 tiles^    ^12 tiles^             ^12 tiles^
                 W=0          W=0                   W=0
                 FCN=62       FCN=50             FCN=50-12+1=39
              ^------FEC Window------^           > Last tile of
                                              previous fragment.
Figure 2: FEC Fragment concept and calculation example with sample values following RFC9011.If Fragment B is lost in the transmission, the receiver end may recover it by performing a bitwise XOR operation between Fragment A and FEC Fragment. 
+--------------------------+         +----------------------------+
|    SCHC Fragmentation    |         |    SCHC FEC Fragmentation  |
|--------------------------|         |----------------------------|
| - Splits data into Tiles |         | - Operates over FEC Window |
| - Uses DTag, W, FCN      |         | - Uses DTag, W, FCN        |
| - Data transmission      |         | - Calculates FEC over Tiles|
+--------------------------+         +----------------------------+
            |                                  |
            v                                  v
+--------------------------+         +----------------------------+
|     SCHC Fragments       |         |  SCHC FEC Fragments        |
|--------------------------|         |----------------------------|
| - Contains data          |         | - Contains FEC code        |
| - Indexed by DTag, W, FCN|         | - Helps recover lost Tiles |
+--------------------------+         +----------------------------+
            |                                  |
            v                                  v
+--------------------------+         +----------------------------+
|  Transmission to Receiver|         |  FEC Recovery Mechanism    |
|--------------------------|         |----------------------------|
| - Regular SCHC Fragments |         | - Uses FEC Fragments       |
| - As per fragmentation   |         | - Complements SCHC Frags   |
|   rules                  |         | - Enhances reliability     |
+--------------------------+         +----------------------------+
Figure 3: Difference between SCHC Fragments and SCHC FEC Fragments 
+------------------+             +------------------+
| New SCHC         | --------->  | 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.           |----------> |                  |
+-------------------+            +------------------+
Figure 4: State Machine of FEC Fragment Sender. Note that the FEC Fragments can be sent at any time. Often, this could be after the emission of a SCHC Fragment (e.g. sending a new FEC Fragment every 2 SCHC Fragments), but that could be extended to a time-based FEC Fragment emission (e.g. every 4 hours), or some other parameter. Typically, the FEC Fragment sent will be relative to the last SCHC Fragment, but it could refer to any other tile. Receivers are not required to keep a trace of the SCHC FEC Fragments they receive. 
+------------------+             +------------------+
| Start            | --------->  | 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          |
+-------------------+            +------------------+
Figure 5: State Machine of FEC Fragment Receiver. FEC Fragments can be received at any time. The reception of a FEC Fragment may allow to recover missing SCHC Fragments. If the data of a SCHC Fragment is recovered, depending on the implementation there are several options. One is to generate a SCHC Fragment corresponding to the lost SCHC Fragment and send it to the SCHC Fragmentation process (e.g. through an API call or as if it was received through the lower-layer). Alternatively, the SCHC Fragmentation process may be the one implementing the FEC mechanism, in which case the recovery of a piece of data may be processed internally.

5. References

The IETF documents referred to here are [RFC8724].

6. Security Considerations

No security considerations.

7. IANA Considerations

8. Normative References

[RFC8724]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, , <https://www.rfc-editor.org/info/rfc8724>.

Authors' Addresses

Alexander Pelov
IMT Atlantique
2bis rue de la Chataigneraie
35536 Cesson-Sévigné
France
Javier A. Fernandez
IMT Atlantique
2bis rue de la Chataigneraie
35536 Cesson-Sévigné
France
Hoang Quy Nguyen
Actility
65 Rue de la Victoire
Paris