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

From: Julien CATALANO <[email-masked]>
Date: Wed, 1 Jul 2020 12:30:31 +0200

Dear SCHC-over-LoRaWAN editors and sheperd, lpwan-ers',

I proof-read the latest SCHC-over-LoRaWAN draft [1] following our
discussion yesterday during lpwan interim.

The document is in a very good shape, and I had a good time reading it
again.

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

What do you think?

Concerning the exponential back-off discussion:

I tend to agree that it is not necessary in this context. It will add
complexity the document for no real gain. I withdrawn the comments I
made during the lpwan interim on that topic.

I have a few minor remarks on terminology as well. I understand and
agree with using the SCHC names (Device, NGW, etc.) in the text. It
looks actually better this way. But, in several places there are terms
weakly defined.

 - "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).
 - "network" is poorly defined (used several times in section 4.1): Use
either "Network Gateway", "Radio Gateway", SCHC Gateway" or "LoRaWAN
Network Server"
 - "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)
 - I would advice to define in the LoRaWAN section what is an "empty
frame" an use it elsewhere (No FPort, No FRMPayload)
 - Section 4.3: rename to "General Frame Types" and explicitly name
"LoRaWAN Confirmed message" and "LoRaWAN Unconfirmed message"

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.

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

Thank you
Julien

[1]
https://github.com/Acklio/schc-over-lorawan/tree/draft-ietf-lpwan-schc-over-lorawan-08

---

From: Olivier Gimenez <[email-masked]>
Date: Thu, 2 Jul 2020 19:53:38 +0000

Hi Julien,

Thank you for this review and positive comments!

I answered in your email

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

> From: lp-wan <[email-masked]> On Behalf Of Julien CATALANO

> Sent: 01 July 2020 12:31

> 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.

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

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

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

>  - 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.

---

From: Julien CATALANO <[email-masked]>
Date: Fri, 3 Jul 2020 15:37:23 +0200

Hi Olivier,

Your comment makes sense for downlink fragmentation.

All the changes are OK for me: good job!

Enjoy your holidays
Julien

Le 02/07/2020 à 21:53, Olivier Gimenez a écrit :
> ClassA end-
> [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.
>
>  
>
> [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
>
>  
>
> [OG] Thank you, I made those changes
> <https://github.com/Acklio/schc-over-lorawan/commit/e980ddcd6f4b21de4450cb2a71e50b371902c242>,
> again, please feel free to update them
>
>  
>
> [OG] Added here
> <https://github.com/Acklio/schc-over-lorawan/commit/bf19fa6cbcd2f29b18ec1302da732567831a63b8>
>
>  
>
> frame" an
> [OG] That is a great idea, implemented here
> <https://github.com/Acklio/schc-over-lorawan/commit/3d18df081095ab821bf2dd9977410d990007b1e3>
>
>  
>
> [OG] Done here
> <https://github.com/Acklio/schc-over-lorawan/commit/dc12dc97155851d9537fbd491165ef77625bc024>
>
>  
>
> [OG] Thank you, fixed all of themhere
> <https://github.com/Acklio/schc-over-lorawan/commit/7e18006f5a09f8ff86aa09c6cb506cba3e7a0b68>
>
>  
>
> [OG] I saw the last sentence after making the corrections, but if you
> see any other you can submit a PR JThank 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.