Subject: [lp-wan] Ticket #21 C bit in ACK

From: ana minaburo <[email-masked]>
Date: Tue, 19 Jun 2018 16:50:49 +0200

Interim 13/06/2018

   - For the moment consensus on the ML

Option 1: AM, DB, CG, LT, JCZ

   - Update Ticket 15 with the warning to adjust MAX_WIND_FCN accordingly,
   if L2 technology constrains Bitmap size

Section 7.5 Baseline mechanism

Notice that the SCHC ACK for the All-1 window carries one more bit (the C
bit) compared to the SCHC ACKs for the previous windows. See {{SCHCParams}}
for a discussion on various options to deal with this "bump" in the SCHC
ACK.

Appendix D. SCHC Parameters - Ticket #15
<https://trac.ietf.org/trac/lpwan/ticket/15>

   - 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 utilised, i.e.
   there won't be fragments with all FCN values from MAX_WIND_FCN downto 1 and
   finally All-1. It is worth noting that this document does not mandate that
   other windows (called All-0 windows) are fully utilised 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 don'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.