Re: [lp-wan] ACK compression

[Olivier Gimenez <[e-mail]>]

Dear,

It has not been a lot of discussion on that topic, here is my proposition. My changes are underlined and in italic (3rd bullet of first paragraph, added 3 figures)

Please see my first email, quoted at the end of my email for the context.


Best regards
Olivier

8.3.2.1.  Bitmap Compression

   For transmission, the Compressed Bitmap in the SCHC ACK message is
   defined by the following algorithm (see Figure 16 for a follow-along
   example):


*         Build a temporary SCHC ACK message that contains the Header followed by the original Bitmap (see Section 8.2.2.3 for a description of Bitmaps).

*         Position scissors at the end of the Bitmap, after its last bit.

*         While the bit on the left of the scissors is the same than the last SCHC bit and belongs to the Bitmap, keep moving left, then stop.  When this is done,

*         While the scissors are not on an L2 Word boundary of the SCHC ACK  message and there is a Bitmap bit on the right of the scissors,  keep moving right, then stop.

*         At this point, cut and drop off any bits to the right of the scissors

   When one or more bits have effectively been dropped off as a result
   of the above algorithm, the SCHC ACK message is a multiple of L2
   Words, no padding bits will be appended.

Because the SCHC Fragment sender knows the size of the original
   Bitmap, it can reconstruct the original Bitmap from the Compressed
   Bitmap received in the SCH ACK message.

   Figure 16 shows an example where L2 Words are actually bytes and
   where the original Bitmap contains 17 bits, the last 15 of which are
   all set to 1.

   |---- SCHC ACK Header ----|--------      Bitmap     --------|
             |-- T --|-M-| 1 |
   +--- ... -+- ... -+---+---+---------------------------------+
   | Rule ID |  DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
   +--- ... -+- ... -+---+---+---------------------------------+
           next L2 Word boundary ->|

            Figure 16: SCHC ACK Header plus uncompressed Bitmap - Trailing 1 compression

   Figure 17 shows that the last 14 bits are not sent.

   |---- SCHC ACK Header ----|CpBmp|
             |-- T --|-M-| 1 |
   +--- ... -+- ... -+---+---+-----+
   | Rule ID |  DTag | W |C=0|1 0 1|
   +--- ... -+- ... -+---+---+-----+
           next L2 Word boundary ->|

       Figure 17: Resulting SCHC ACK message with Compressed Bitmap - Trailing 1 compression

   Figure 18 shows an example of a SCHC ACK with tile indices ranging
   from 6 down to 0, where the Bitmap indicates that the second and the
   fourth tile of the window have not been correctly received.

   |---- SCHC ACK Header ----|--- Bitmap --|
             |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
   +---------+-------+---+---+-------------+
   | Rule ID |  DTag | W |C=0|1 0 1 0 1 1 1|      uncompressed Bitmap
   +---------+-------+---+---+-------------+
       next L2 Word boundary ->|<-- L2 Word -->|

   +---------+-------+---+---+-------------+~~~+
   | Rule ID |  DTag | W |C=0|1 0 1 0 1 1 1|Pad|  transmitted SCHC ACK
   +---------+-------+---+---+-------------+~~~+
       next L2 Word boundary ->|<-- L2 Word -->|

          Figure 18: Example of a SCHC ACK message, missing tiles


   Figure 19 shows an example of a SCHC ACK with FCN ranging from 6 down
   to 0, where integrity check has not been performed or has failed and
   the Bitmap indicates that there is no missing tile in that window.

   |---- SCHC ACK Header ----|--- Bitmap --|
             |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
   +---------+-------+---+---+-------------+
   | Rule ID |  DTag | W |C=0|1 1 1 1 1 1 1|  with uncompressed Bitmap
   +---------+-------+---+---+-------------+
       next L2 Word boundary ->|

   +--- ... -+- ... -+---+---+-+
   | Rule ID |  DTag | W |C=0|1|                  transmitted SCHC ACK
   +--- ... -+- ... -+---+---+-+
       next L2 Word boundary ->|

         Figure 19: Example of a SCHC ACK message, no missing tile



   Figure 20 shows an example where L2 Words are actually bytes and where the original Bitmap contains 17 bits, the last 6 of which are all set to 0 due to missing tiles.

   |---- SCHC ACK Header ----|--------      Bitmap     --------|
             |-- T --|-M-| 1 |
   +--- ... -+- ... -+---+---+---------------------------------+
   | Rule ID |  DTag | W |C=0|1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0|
   +--- ... -+- ... -+---+---+---------------------------------+
           next L2 Word boundary ->|

            Figure 20: SCHC ACK Header plus uncompressed Bitmap - Trailing 0 compression

   Figure 21 shows that the last 6 bits are not sent.

   |---- SCHC ACK Header ----|CpBmp|
             |-- T --|-M-| 1 |
   +--- ... -+- ... -+---+---+-----+
   | Rule ID |  DTag | W |C=0|1 1 1 1 1 1 1 1 1 1 1 1 |
   +--- ... -+- ... -+---+---+-----+
           next L2 Word boundary ->|

       Figure 21: Resulting SCHC ACK message with Compressed Bitmap - Trailing 0 compression




From: Olivier Gimenez
Sent: 07 May 2019 18:15
To: [e-mail]
Subject: ACK compression

Dear,

In the discussion following the draft-ietf-lpwan-schc-over-lorawan v04 with Dominique Barthel we are wondering if an improvement can be made:
In the LoRaWAN profile, from device to SCHC gateway, we tried to minimise the number of windows in order to minimise the number of required downlinks. This has a side effect:  bitmap can be up to 16 bytes.

Let's assume that the profile does not allow to put the last tile in the all-1 message.
Fragment 1:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=126 | 4 tiles |               => Receiver's bitmap b'1111 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Fragment 2:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=122 | 4 tiles |               => Lost, receiver's bitmap stays unchanged
Fragment 3:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=118 | 4 tiles |               => Received, receiver's bitmap becomes b'1111 0000 1111 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Fragment 4:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=114 | 4 tiles |                  => Lost, receiver's bitmap stays unchanged
Fragment 5 - All 1:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=127 | MIC |         => Received, MIC is wrong, receiver returns ACK
ACK :                | ruleId=b'000000 | Dtag=b'0 | W= b'00 | C=0 | bitmap = b'1111 0000 1111 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 | => Compression will not reduce the bitmap size in this case

What we are thinking is to allow compression of trailing bits also for 0 with the same rule than 1, which will result in the ACK:
Compressed ACK :                | ruleId=b'000000 | Dtag=b'0 | W= b'00 | C=0 | bitmap = b'1111 0000 1111 00

The sender knows how many tiles have been send, so it can resend tiles 122->119 and 114>111. What are your thoughts ?

Thank you

Best regards
Olivier

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.