Subject: Re: [lp-wan] Fwd: Review of draft-ietf-schc-over-lorawan

From: Olivier Gimenez <[email-masked]>
Date: Tue, 2 Jun 2020 06:24:04 +0000

Hi Ana,

Thank you for your answer, I replied in the email.

Olivier

From: lp-wan <[email-masked]> On Behalf Of Ana Minaburo

Hello

See my comments below.

> - Section 5.6.2. The values for W, N, etc. are the only values that any Lorawan device may use? May any other values be used for any different L2 packet size?

[OG] Yes
[ANA ] the numbers may be placed as recommended

[OG] No. The values written in the Profile are mandatory for interoperability reasons. An application can use different parameters with other ruleIds, I added “The application can use additional uplinks or downlink fragmentation parameters but SHALL implement at least the parameters defined in this document.”

> - Section 5.6.2 and Section 5.6.3. Retransmission timer. It is a little bit surprising to see this point here. The RFC8724 gives this timer as mandatory for ACK_Always and ACK_on_Error. Are all the Lorawan implementations avoid using the retransmission timer? And so, how the interoperability could be done? How to abort? How do you do if you receive a Send-abort? When are you closing your session?

[OG]
* Ack-on-Error (uplink). It cannot be reliably implemented in a LoRaWAN device: the device might not be able to transmit the SCHC packet at a given time because of the duty cycle, especially if it implements non SCHC traffic. The session is terminated on gateway side thanks to an "inactivity timer" where the value is selected regarding the application needs
* Ack-Always (downlink). Retransmission timer cannot be used with LoRaWAN class A device as the RX window is opened by the device, and not exactly when the SCHC gateway timer will expire. Nevertheless you are right that it is not written, I do not know how we missed it.

Send-Abort can be used as defined in RFC8724

[Ana] I think you need to follow the RFC8724 as it is, and place your numbers corresponding to the things you need. You need to keep interoperability and conformity to this document

[OG] Ok, to be discussed this afternoon regarding class A downlink.

> -Section 5.6.3 You give a solution for downlink to be as similar as possible as for Uplink, but doing this gives you 6bits of padding. Is this deliberated?

[OG] The aim is not to be similar but efficient, the padding might be in the last SCHC fragment depending on payload + residue size.

[Ana] What do the +6 bits mean in the figure section 5.6.3.1?

[OG] SCHC header is 10 bits. As L2 layer size is 1 bytes a complete message will be at least 2 bytes => Payload will be 6 bits + X bytes, and may include padding

> Check List of Appendix D. I think these are missing:
> - What makes an ALL-0 SCHC Fragment and a SCHC ACK REQ distinguishable?

[OG] From RFC8724 :"This condition is also met if the SCHC Fragment Header is a multiple of L2 Words." Which is the case in LoRaWAN, should we explicitly state it in the LoRaWAN profile ?

[Ana] I think this will help implementers

> - What makes an All-1 SCHC Fragment and a SCHC Sender-Abort distinguishable?

[OG] From RFC8724: " This condition is met if the RCS is present and is at least the size of an L2 Word". Which is the case in LoRaWAN, should we explicitly state it in the LoRaWAN profile ?

[Ana] The same, it will be helpful for the implementers

> -Retransmission Timer duration for each RuleD value, if applicable to for SCHC F/R mode
> - Inactivity Timer duration for each Rule ID value, if applicable to the SCHC F/R mode

[OG] As discussed, missing for Ack-Always

[Ana] You need to stablish these numbers

[OG] OK

> - MAX_ACK_Request value for each RuleID value, if applicable to the SCHC F/R mode

[OG] " MAX_ACK_Request" is specified to 8 for Ack-on-error and Ack-Always

[Ana] I think that for the implementation the numbers are important, that's why we made this list

[OG] I am not sure to understand the comment as “MAX_ACK_Request” is defined in the document

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.