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

From: Ana Minaburo <[email-masked]>
Date: Sun, 17 May 2020 20:06:48 +0200

Hello Lpwaners,

I hope all of you are well.
I took some time to read and understand the propositions of this draft, I
have also checked the Appendix D list, please find below my questions and
inputs.

- Figure 5. Instead of SCHC payload, put SCHC packet or SCHC header +
payload

- Section 5.1  Check terminology writing for RuleID (RFC8724)

- Section 5.6.1 DTag is not used. While reading your text, I understand
that DTag exists, but it is not defined as it is in the RFC8724. The DTag
value is implicitly defined in the RuleID. Why don't you explain this in
the document?

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

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

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

Check List of Appendix D. I think these are missing:

- What makes an ALL-0 SCHC Fragment and a SCHC ACK REQ distinguishable?
- What makes an All-1 SCHC Fragment and a SCHC Sender-Abort distinguishable?
-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
- MAX_ACK_Request value for each RuleID value, if applicable to the SCHC
F/R mode
-The profile may define a delay to be added after each SCHC message
transmission for compliance with local regulations or other constraints
imposed by the applications

Regards!
Ana

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 18 May 2020 07:40:44 +0000

Hi,

Thank you Ana for your comments,
Please find below my answers.

Olivier

> From: lp-wan <[email-masked]> On Behalf Of Ana Minaburo
> Sent: 17 May 2020 20:07
> 
> - Figure 5. Instead of SCHC payload, put SCHC packet or SCHC header + payload

[OG] Fixed

> - Section 5.6.1 DTag is not used. While reading your text, I understand that DTag exists, but it is not defined as it is in the RFC8724. The DTag value is implicitly defined in the RuleID. Why don't you explain this in the document? 

[OG] While DTAG is not used and does not exist in this profile, users still have the possibility to use different FPorts (RuleID) to create multiple fragmentation sessions in parallel if they really need it. We did not want to write that the DTAG is implicit to avoid confusion. Do you, and the group, think that it would be better to write it ?

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

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

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

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

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

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

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

> -The profile may define a delay to be added after each SCHC message transmission for compliance with local regulations or other constraints imposed by the applications

[OG] As it is a "may" inside an appendix I thought that it is not mandatory to write a note about it if not used but I might be wrong, any advice ?

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: Ana Minaburo <[email-masked]>
Date: Tue, 26 May 2020 11:13:55 +0200

Hello

See my comments below.

> Lorawan device may use? May any other values be used for any different L2
[ANA ] the numbers may be placed as recommended

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

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

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

> [OG] As discussed, missing for Ack-Always

[Ana] You need to stablish these numbers

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

Ana