Re: [lp-wan] draft-ietf-lpwan-schc-over-lorawan review

[Olivier Gimenez <[e-mail]>]

Hi Julien,



Thank you for this review and positive comments!

I answered in your email



> -----Original Message-----

> From: lp-wan <[e-mail]> On Behalf Of Julien CATALANO

> Sent: 01 July 2020 12:31

> One comment concerning the downlink fragmentation in LoRaWAN ClassB or

> ClassC: Using ACK-Always seems overkill there. It is necessary for ClassA end-

> devices to trigger receive windows as we go, but for classB/C the receive

> windows are more frequent (or permanent) and do not need an uplink. I

> wonder if we could move the downlink fragmentation in those classes to Ack-

> on-error?

>

> My reasoning is that it is more efficient on the radio link, do not load the

> medium for nothing and actually will allow faster fragmentation session (no

> need to wait for the uplink).



[OG] Technically yes, but it add more complexity on the Device and SCHC gateway as the device can switch between class A and B at any time because of the beacon tracking acquisition/loss. What happens to the current SCHC fragmentation session in such case ? So we proposed this approach at the beginning to keep it simple, and it still work well with class B & C devices.



>  - "LoRaWAN device": either use "Device (Dev)" (uppercase 'D', SCHC

> Terminology) or "LoRaWAN end-device". A LoRaWAN device is not clear (can

> be a gateway, an end-device or anything in between).



[OG] Ok, I propose the changes in this commit<https://github.com/Acklio/schc-over-lorawan/commit/362f813b2b88ac1f91111d6d3f200670d15fae09>, please update if you think it can be improved



>  - "network" is poorly defined (used several times in section 4.1): Use either

> "Network Gateway", "Radio Gateway", SCHC Gateway" or "LoRaWAN Network

> Server"



[OG] Thank you, I made those changes<https://github.com/Acklio/schc-over-lorawan/commit/e980ddcd6f4b21de4450cb2a71e50b371902c242>, again, please feel free to update them



>  - "SCHC Gateway" is also weakly defined, but used in many places: Add the

> definition in the Terminology section (now it is defined only between

> parenthesis in section 4 intro)



[OG] Added here<https://github.com/Acklio/schc-over-lorawan/commit/bf19fa6cbcd2f29b18ec1302da732567831a63b8>



>  - I would advice to define in the LoRaWAN section what is an "empty frame" an

> use it elsewhere (No FPort, No FRMPayload)



[OG] That is a great idea, implemented here<https://github.com/Acklio/schc-over-lorawan/commit/3d18df081095ab821bf2dd9977410d990007b1e3>



>  - Section 4.3: rename to "General Frame Types" and explicitly name

> "LoRaWAN Confirmed message" and "LoRaWAN Unconfirmed message"



[OG] Done here<https://github.com/Acklio/schc-over-lorawan/commit/dc12dc97155851d9537fbd491165ef77625bc024>



> Some typos, here and there:

>

>  - an device => a Device

>  - devEui, devEUI => DevEUI (as per Terminology section)

>  - Figure 5 table borders are not aligned

>  - Figure 10 does not fit in document width

>  - You list bitmap value in section 5.6.2.3: 63 is not listed but referenced.



[OG] Thank you, fixed all of them here<https://github.com/Acklio/schc-over-lorawan/commit/7e18006f5a09f8ff86aa09c6cb506cba3e7a0b68>



> I will be happy to edit the text on Github if you agree with my comments.



[OG] I saw the last sentence after making the corrections, but if you see any other you can submit a PR ☺ Thank you again for this review





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.