Subject: Re: [lp-wan] some topics to discuss related to schc-lorawan draft

From: Olivier Gimenez <[email-masked]>
Date: Thu, 19 Mar 2020 13:37:39 +0000

Thank you Arun

From: Arunprabhu Kandasamy <[email-masked]>

ii)
 I tried to put it in a dia. hope it is better to understand now. please share your thoughts on this.

As described in “8.4.3.2.  Receiver behaviour” of RFC-to-be 8724:

Reassembly of the SCHC Packet concludes when
   o  a Sender-Abort has been received
   o  or the Inactivity Timer has expired
   o  or the Attempts counter has exceeded MAX_ACK_REQUESTS
   o  or when at least an All-1 SCHC Fragment has been received and
      integrity checking of the reassembled SCHC Packet is successful.

Your example falls in the last sentence as an All-1 is received or the RCS is correct, so inactivity timer can be stopped; it is also described in the Figure 42.
Nevertheless the implementation can keep the current context until it receives a payload other than an All-1

iii)

another thing that I observed is about the ACK expected after each window;
While the draft specifies this as an optional feature. Shouldn't there be some writings that talk about default behavior?
If I'm using class C (connected to unlimited power source), I would be worried about the downlink usage for sending ACKs rather than the battery life.

   _Note_: As LoRaWAN is a radio communication, it is RECOMMENDED for an

   implementation to use ACK mechanism at the end of each window:

   o  SCHC receiver sends an SCHC ACK after every window even if there

      is no missing tiles.

   o  SCHC sender waits for the SCHC ACK from the SCHC receiver before

      sending tiles from next window.  If the SCHC ACK is not received

      it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as

      described previously.

   This OPTIONAL feature will prevent a device to transmit full payload

   if the network can not be reach, thus save battery life.

I am not sure to understand what should be added. We recommend to use an ACK after each window in order to save battery life, but state that it is optional. Would you like to have something like:

This OPTIONAL feature will prevent a device to transmit full payload  if the network cannot be reach, thus save battery life if used, orreduce downlinks volume  the implementation might chose to use

This OPTIONAL feature allows the implementation to select between:

 * SCHC ACK after every window: Save battery life by preventing a device to transmit full payload if the network cannot be reached

 * Otherwise: Reduce downlink load on the network by reducing the number of downlinks

i)
Disallowing all-1 carrying payload seems suboptimal usage of available payload space. Is there any reason (probably, I missed to see it) for why we don't allow it?

The All-1 message + one tile does not fit in US915/SF10 payload: only 11 bytes are available.
Furthermore I did not compute the figures but probability of sending a new fragment just for the last tile should be low as, in most cases, several tiles will be send in a fragment

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.