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

[Arunprabhu Kandasamy <[e-mail]>]

Hi Olivier,

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

[image: image.png]


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)
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?


thanks,



On Wed, Jan 22, 2020 at 9:41 AM Olivier Gimenez <[e-mail]>
wrote:

>
>
>
>
> *From:* Arunprabhu Kandasamy <[e-mail]>
> *Sent:* 18 December 2019 09:26
>
>
>
> In order to avoid overlapping the state machine of the receiver, the
> sender could wait some time, if he has knowledge of the inactivity timer
> configured at receiver, (inactivity timer + delta) before sending the
> fragments from next session. But I think, this is not the behavior that is
> specified in the draft.
>
> So, it would be good to have some section or sentence that gives the
> implementors some suggestions on how to interleave fragments when there is
> no dtag.
>
>
> Topic 2(new):
>  Since we don't have a dtag in the headers, it might create some ambiguity
> in the receiver to manage statemachines for the devices when it receives a
> new fragmented packet while the inactivity timer is still active. Note that
> the sender doesn't have the knowledge of the inactivity timer.
> It would be nice to have a section in the draft to discuss this behavior
> and probably a solution to overcome it.
>
>
>
>
>
>
> Hi Arun,
>
>
>
> I try to understand this but I have hard time figuring out how to enter in
> the state where sender starts the fragmentation session N+1, when the
> receiver did not end the session N ?
>
> Although, if we enter in such case, the receiver will be able to see wrong
> windows & FCN counters then transmit a Receiver-Abort message, so both
> sender/receiver can be reset.
>
>
>
> 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.
>


-- 

<https://t.sidekickopen05.com/s1t/c/5/f18dQhb0S7lM8dDMPbW2n0x6l2B9nMJN7t5X-FfhMynW4Wr-Yl7d-0fCW56dGqW1GQ8t2102?t=https%3A%2F%2Fackl.io%2F&si=7000000001059340&pi=5991da3d-efb6-4959-f4d5-a627f1b5eb8b>

*Arunprabhu KANDASAMY *R&D Engineer-IPCore
[phone]

www.ackl.io

[image: W3Schools] <https://www.linkedin.com/company/acklio/> [image:
W3Schools] <https://twitter.com/acklio>