Subject: [lp-wan] ACK compression

From: Olivier Gimenez <[email-masked]>
Date: Tue, 7 May 2019 16:15:24 +0000

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.