Subject: [lp-wan] Ticket #25 Rule not synchronised

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Feb 2018 16:56:42 +0100

<RJ> A scenario where GW and Dev have not synchronized for the SCHC context
post an update. GW thinks that a Dev is updated to the lastest SCHC context
but it has in reality not been updated. Is there any way to currently
handle this? Point is gw/dev might simply keep receiving the packets and
decompressing it based on the current rule they have. One way I could think
of handle this is to change the rule-id when SCHC context is changed. I
don't know if this needs proper handling or some text in the draft.

<Authors> This is out of the scope of this document.

---

From: Nicolas Sornin <[email-masked]>
Date: Wed, 28 Feb 2018 09:02:30 +0000

Dear all.
A good way to avoid this context synchronization problem is to systematically add a context “index” in every frame.
This index can be coded on very few bits , practically speaking 2 bits is enough  , and rolls over 0,1,2,3,0,1,….
Every time the context is changed the index must be incremented by 1. This way both ends of the link know exactly which set of rules they are using .

Nicolas.

From: lp-wan [mailto:[email-masked]] On Behalf Of Ana Minaburo
Sent: 27 February 2018 16:57
To: lp-wan
Cc: [email-masked]
Subject: [lp-wan] Ticket #25 Rule not synchronised

The e-mail below was received from outside Semtech, exercise caution
________________________________

<RJ> A scenario where GW and Dev have not synchronized for the SCHC context post an update. GW thinks that a Dev is updated to the lastest SCHC context but it has in reality not been updated. Is there any way to currently handle this? Point is gw/dev might simply keep receiving the packets and decompressing it based on the current rule they have. One way I could think of handle this is to change the rule-id when SCHC context is changed. I don't know if this needs proper handling or some text in the draft.