Subject: [lp-wan] Ticket #15 SCHC technology specific parameters (Lastest version)

From: ana minaburo <[email-masked]>
Date: Tue, 19 Jun 2018 17:35:57 +0200

Appendix D. SCHC Parameters - Ticket 15

This section gives the list of parameters that need to be defined in the
technology-specific documents, technology developers must evaluate that L2
has strong enough integrity checking to match SCHC's assumption:

   - LPWAN Architecture. Explain the SCHC entities (Compression and
   Fragmentation), how/where are they be represented in the corresponding
   technology architecture.

   - L2 fragmentation decision

   - Rule ID number of rules

   - Size of the Rule ID

   - The way the Rule ID is sent (L2 or L3) and how (describe)

   - Fragmentation delivery reliability mode used in which cases

   - Define the number of bits FCN (N) and DTag (T)

   - The MIC algorithm to be used and the size if different from the
   default CRC32

   - Retransmission Timer duration

   - Inactivity Timer duration

   - Define the MAX_ACK_REQUEST (number of attempts)

   - Padding: size of the L2 Word (for most technologies, a byte; for some
   technologies, a bit). Value of the padding bits (1 or 0). The value of the
   padding bits needs to be specified because the padding bits are included in
   the MIC calculation.

   - Take into account that the length of rule-id + N + T + W when possible
   is good to have a multiple of 8 bits to complete a byte and avoid padding

   - In the ACK format to have a length for Rule-ID + T + W bit into a
   complete number of byte to do optimization more easily

   - The technology documents will describe if Rule ID is constrained by
   any alignment

   - When fragmenting in ACK-on-Error or ACK-Always mode, it is expected
   that the last window (called All-1 window) will not be fully utilized, i.e.
   there won't be fragments with all FCN values from MAX_WIND_FCN down to 1
   and finally All-1. It is worth noting that this document does not mandate
   that other windows (called All-0 windows) are fully utilized either. This
   document purposely does not specify that All-1 windows use Bitmaps with the
   same number of bits as All-0 windows do. By default, Bitmaps for All-0 and
   All-1 windows are of the same size MAX_WIND_FCN + 1. But a
   technology-specific document MAY revert that decision. The rationale for
   reverting the decision could be the following: Note that the SCHC ACK sent
   as a response to an All-1 fragment includes a C bit that SCHC ACK for other
   windows doesn't have. Therefore, the SCHC ACK for the All-1 window is one
   bit bigger. An L2 technology with a severely constrained payload size might
   decide that this "bump" in the SCHC ACK for the last fragment is a bad
   resource usage. It could thus mandate that the All-1 window is not allowed
   to use the FCN value 1 and that the All-1 SCHC ACK Bitmap size is reduced
   by 1 bit. This provides room for the C bit without creating a bump in the
   SCHC ACK.

   - Define the most common uses case and how SCHC may be deployed.

   - The use of interleaving packets in a specific technology needs to be
   studied and reflected in the specific technology document

   - Padding on SCHC draft is a default solution, technologies may define
   another solution if needed

   - if L2 payload size is the limit to your window size, developers should
   remember that the window size needs to be one fragment shorter than they
   would think to look at the All-0 ACK format, in order to accommodate for
   the extra bit of the All-1 ACK

   - Define the use of SCHC C/D and SCHC F/R in the technology architecture
   and channel definitions. And define which channels do not need the use of
   Fragmentation.

   - Define the use of SCHC C/D and SCHC F/R for any kind of propagation

   - And the following parameters need to be addressed in another document
   but not forced in the technology-specific one:
   - The way the contexts are provisioning

   - The way the Rules as generated