Re: [lp-wan] SCHC over LoRaWAN review

[Laurent Toutain <[e-mail]>]

Hi Olivier,

Thank you for your answers, and the explanation for a Tile of 3 Bytes,
that's a good way to fill the frame.
I still have questions on fPorts:

- rule 20 is fully specified by the draft and that's logicial, and is
designed for short uplinks, that's perfect.

for the other rules
- rule 21 is for any SCHC rule uplink
- rule 22 is for any SCHC rule downlink,

For these rules are less directive, I suppose an implementer may decide to
use then as he wants, even if he does not follow the draft representation.

In SCHC a compression rule is bidirectional you can with the same rule ID
use it differently up and downlink. How do you plan to map it in the
LoRaWAN case?
same rule ID but the fport is changing regarding it has been sent by the
device or the network?

In SCHC the fragmentation rules are in one direction, the other direction
is used for ack with the same ruleID.
how do you map it ? do you use the same fPort for the ack ? For instance if
I send the combination fPort:RuleID
21:1000 for a fragment, the ack will be 21:1000 or 22:1000 (personally I
prefer to use 21: for the Ack).

See you

Laurent

On Fri, Jun 14, 2019 at 3:28 PM Olivier Gimenez <[e-mail]>
wrote:

> Thank you Laurent for your review.
>
>
>
>
>
> - On your point about *relation between FPort and RuleID*, I think that
> Dominique's proposition could indeed make this part clearer.
>
>
>
> Something like
>
> FPort:RuleID ?
>
> 20: for the small one
>
> 21:RuleID for uplink
>
> and
>
> 22:RuleID for downlink
>
>
>
> No. *22:RuleID for all downlink* is OK but not 20 and 21.
>
> *21:RuleID works for all uplinks*, fragmented or not, add 2 bytes of
> overhead.
>
> *22: RuledID for fragmented uplinks* where payload is less than 381
> bytes, add 1 byte of overhead. I should add a comment that this one is not
> mandatory on device side, as using FPort 21 for a fragmented payload of 200
> bytes will also work. It is only purpose is reduce the overhead for small
> fragmented payloads.
>
>
>
>
>
>
>
>
>
> - On your point about *relation between compression and fragmentation, *we
> can add a bit more text about it, but our general idea was that compression
> depends much more on the specific scenario, so we are only providing the
> required parameters for it and we leave it to the <<*user>> * to figure
> out the remaining details. This is why this part is much shorter and
> probably less detailed. The fragmentation is the part that seemed the most
> likely source of interoperability issues and that is why most of our
> efforts so far have been concentrated on it.
>
>
>
> ok
>
>
>
> - While tile size of 6 could be used, the idea to have it only 3 bytes
> long is that mac commands in FOpts can be placed, without affecting too
> much the fragmentation. In addition, different payload sizes seem to fit
> well with this tile size. My guess is that only through observing real
> traffic we will be able to select the best tile size for most cases. If you
> have reasons to believe that other tile size will be more appropriate,
> please let us know.
>
>
>
> No I was surprised by the value, but it is a good trade-off
>
>
>
> It is the best one to have an efficient packing of tiles in all LoRaWAN
> MTU, taking into account that there can be FOpts. Using 2 would be even
> better but we would not comply with IPv6 MTU of 1280 bytes.
>
>
>
>
>
> Regarding comments about compression not described: what should be
> described ? The rules are user specific, and user can use 62 rules. What
> else should we write in the document ?
>
>
>
>
>
> I will think about not specifying ruleId in the document, and if it is not
> too difficult to implement.
>
>
>
>
>
> Please find attached the Word document with answers to your comments.
>
>
>
>
>
> 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.
>