Subject: [lp-wan] Flow validation in ACK-on-error Mode

From: Rodrigo Muñoz <[email-masked]>
Date: Mon, 16 Sep 2019 11:42:28 -0300

Dear Author,

I am working on the implementation of the SCHC standard for Sigfox and
LoRaWAN. I have the following doubt regarding the data flow when there is a
failure in the transmission of a SCHC fragment in the ACK-on-error Mode.

In this email, I attach my draft compression. Is this flow ok?

I have assumed the following:

   - The SCHC Ack is sent immediately by the receiver at the end of the
   window.

Regards
-- 
-------------------------------------------
*Rodrigo Muñoz Lara*

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 16 Sep 2019 16:06:28 +0000

Hello Rodrigo,

Thanks for your enquiry.

In your flow, you are showing a “Retransmission Timer” time between the retransmitted Reg Frag 1 and the All-1.

If the All-1 is the fragment that would have normally followed Reg Frag 4, there is no need for the sender to wait between retransmitting Reg Frag 4 and the All-1.

This All-1 would trigger again the receiver to send a SCHC ACK, which would notify the sender of the correct (or not) reception of all the previous fragments.

I hope this helps.

Best,

Juan Carlos

From: lp-wan <[email-masked]> On Behalf Of Rodrigo Muñoz
Sent: September 16, 2019 10:42 AM
To: [email-masked]
Cc: Sandra Cespedes <[email-masked]>
Subject: [lp-wan] Flow validation in ACK-on-error Mode

Dear Author,

I am working on the implementation of the SCHC standard for Sigfox and LoRaWAN. I have the following doubt regarding the data flow when there is a failure in the transmission of a SCHC fragment in the ACK-on-error Mode.

  *   The SCHC Ack is sent immediately by the receiver at the end of the window.
Regards
--
-------------------------------------------
Rodrigo Muñoz Lara

---

From: Rodrigo Muñoz <[email-masked]>
Date: Mon, 16 Sep 2019 16:58:44 -0300

Thanks Juan Carlos for your response.

My comments below:

In your flow, you are showing a “Retransmission Timer” time between the
retransmitted Reg Frag 1 and the All-1.
[Rodrigo]: Yes. This timer is definided
in draft-petrov-lpwan-ipv6-schc-over-lorawan document. In the 5.5.1 said:
"If this ACK is not received the end-device sends an all-0 (or an all-1)
fragment with no payload to request an SCHC ACK retransmission. The
periodicity between retransmission of the all-0/all-1 fragments is
device/application specific and may be different for each device (not
specified).

If the All-1 is the fragment that would have normally followed Reg Frag 4,
there is no need for the sender to wait between retransmitting Reg Frag 4
and the All-1.
[Rodrigo]: I don't understand this. Could you explain it in more detail
please? Remember that in my diagram, fragment 1 is lost, but fragments 2, 3
and 4 correctly reach the receiver. In addition, I assume that these
fragments are not in the last window, therefore an All-1 SCHC message
should not be sent

This All-1 would trigger again the receiver to send a SCHC ACK, which would
notify the sender of the correct (or not) reception of all the previous
fragments.
[rodrigo]: Yes, I also agree with you

The problem is: what happens when the sender relays the Frag 1 message and
this message is lost. Neither the sender nor the receiver have timers to
start retransmissions again, or do they have them?

I corrected the diagram to give more clarity

El lun., 16 sept. 2019 a las 13:06, Juan Carlos Zuniga (<
[email-masked]>) escribió:

> If the All-1 is the fragment that would have normally followed Reg Frag 4,
> there is no need for the sender to wait between retransmitting Reg Frag 4
> and the All-1.
>
>
>
> This All-1 would trigger again the receiver to send a SCHC ACK, which
> would notify the sender of the correct (or not) reception of all the
> previous fragments.
>
>
>
> I hope this helps.
>
>
>
> Best,
>
>
>
> Juan Carlos
>
>
>
> *From:* lp-wan <[email-masked]> *On Behalf Of *Rodrigo Muñoz
> *Sent:* September 16, 2019 10:42 AM
> *To:* [email-masked]
> *Cc:* Sandra Cespedes <[email-masked]>
> *Subject:* [lp-wan] Flow validation in ACK-on-error Mode
>
>
>
> Dear Author,
>
>
>

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 16 Sep 2019 23:13:10 +0000

Hi Rodrigo,

From: Rodrigo Muñoz <[email-masked]>
Sent: September 16, 2019 3:59 PM
To: Juan Carlos Zuniga <[email-masked]>
Cc: [email-masked]; Sandra Cespedes <[email-masked]>
Subject: Re: [lp-wan] Flow validation in ACK-on-error Mode

My comments below:

In your flow, you are showing a “Retransmission Timer” time between the retransmitted Reg Frag 1 and the All-1.
[Rodrigo]: Yes. This timer is definided in draft-petrov-lpwan-ipv6-schc-over-lorawan document. In the 5.5.1 said: "If this ACK is not received the end-device sends an all-0 (or an all-1) fragment with no payload to request an SCHC ACK retransmission. The periodicity between retransmission of the all-0/all-1 fragments is device/application specific and may be different for each device (not specified).

[JCZ] Ok, I thought you were referring your question to the authors of the baseline LPWAN SCHC specification (draft-ietf-lpwan-ipv6-static-context-hc), which allows several implementations for different radio technologies. The answer I gave you was with different implementation in mind (e.g. Sigfox), in which you don’t have to wait for a retransmission timer to continue transmitting your other fragments after retransmitting the missing one. If draft-petrov defines it differently I would let the authors of that draft comment (BTW, the draft has been replaced by draft-ietf-lpwan-schc-over-lorawan).

If the All-1 is the fragment that would have normally followed Reg Frag 4, there is no need for the sender to wait between retransmitting Reg Frag 4 and the All-1.
[Rodrigo]: I don't understand this. Could you explain it in more detail please? Remember that in my diagram, fragment 1 is lost, but fragments 2, 3 and 4 correctly reach the receiver. In addition, I assume that these fragments are not in the last window, therefore an All-1 SCHC message should not be sent

[JCZ] Do you mean that there are other fragments after 4 that are not depicted, or that the All-1 is transmitted alone in the last window? Perhaps explaining this would help the discussion.

The problem is: what happens when the sender relays the Frag 1 message and this message is lost. Neither the sender nor the receiver have timers to start retransmissions again, or do they have them?

[JCZ] Again, in the implementation that I have in mind the transmitter would send the missing fragment followed by the next not-yet-transmitted fragments in the same window. I would let Ivo et al. comment about the implementation they propose in their draft.

Best, Juan Carlos

El lun., 16 sept. 2019 a las 13:06, Juan Carlos Zuniga (<[email-masked]<mailto:[email-masked]>>) escribió:
Hello Rodrigo,

Thanks for your enquiry.

I hope this helps.

Best,

Juan Carlos

From: lp-wan <[email-masked]<mailto:[email-masked]>> On Behalf Of Rodrigo Muñoz
Sent: September 16, 2019 10:42 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Sandra Cespedes <[email-masked]<mailto:[email-masked]>>
Subject: [lp-wan] Flow validation in ACK-on-error Mode

Dear Author,

---

From: Rodrigo Muñoz <[email-masked]>
Date: Wed, 18 Sep 2019 16:56:40 -0300

Hi Juan Carlos. My comments below:

*[Rodrigo]:* Yes. This timer is definided

*[JCZ] **Ok, I thought you were referring your question to the authors of
the baseline LPWAN SCHC specification
(draft-ietf-lpwan-ipv6-static-context-hc), which allows several
implementations for different radio technologies. The answer I gave you was
with different implementation in mind (e.g. Sigfox), in which you don’t
have to wait for a retransmission timer to continue transmitting your other
fragments after retransmitting the missing one. If draft-petrov defines it
differently I would let the authors of that draft comment (BTW, the draft
has been replaced by draft-ietf-lpwan-schc-over-lorawan).*

*[Rodrigo]: I’ll write to the authors of the LoRaWAN draft. In LoRaWAN you
can send fragments while you wait for the ACK the lost fragment, but in my
scheme, I supposed that the ACK is sent by the receiver the end of the SCHC
window of the lost fragment.*

* [Rodrigo]*: I don't understand this. Could you explain it in more detail
please? Remember that in my diagram, fragment 1 is lost, but fragments 2, 3
and 4 correctly reach the receiver. In addition, I assume that these
fragments are not in the last window, therefore an All-1 SCHC message
should not be sent

*[JCZ] **Do you mean that there are other fragments after 4 that are not
depicted, or that the All-1 is transmitted alone in the last window?
Perhaps explaining this would help the discussion.*

*[Rodrigo]: In my scheme, I supposed that the ACK is sent by the receiver
the end of the SCHC window of the lost fragment. The size window is of 4
fragments. I send the All-1 because in the draft
(draft-ietf-lpwan-ipv6-static-context-hc-21) say in 8.4.3.1
<http://8.4.3.1>: “On Retransmission Timer expiration: if Attempts is
strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send either
the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to
the last window,”*

This All-1 would trigger again the receiver to send a SCHC ACK, which would
notify the sender of the correct (or not) reception of all the previous
fragments.
* [Rodrigo]:* Yes, I also agree with you

*[JCZ] **Again, in the implementation that I have in mind the transmitter
would send the missing fragment followed by the next not-yet-transmitted
fragments in the same window. I would let Ivo et al. comment about the
implementation they propose in their draft.*

*[Rodrigo]: I’ll write to the authors of the LoRaWAN draft. Thanks*

*Olivier and Ivailo. Can you help me?*

El lun., 16 sept. 2019 a las 20:13, Juan Carlos Zuniga (<
[email-masked]>) escribió:

> Hi Rodrigo,
>
>
>
> *From:* Rodrigo Muñoz <[email-masked]>
> *Sent:* September 16, 2019 3:59 PM
> *To:* Juan Carlos Zuniga <[email-masked]>
> *Cc:* [email-masked]; Sandra Cespedes <[email-masked]>
> *Subject:* Re: [lp-wan] Flow validation in ACK-on-error Mode
>
>
>
> *[JCZ] **Ok, I thought you were referring your question to the authors of
> the baseline LPWAN SCHC specification
> (draft-ietf-lpwan-ipv6-static-context-hc), which allows several
> implementations for different radio technologies. The answer I gave you was
> with different implementation in mind (e.g. Sigfox), in which you don’t
> have to wait for a retransmission timer to continue transmitting your other
> fragments after retransmitting the missing one. If draft-petrov defines it
> differently I would let the authors of that draft comment (BTW, the draft
> has been replaced by draft-ietf-lpwan-schc-over-lorawan).*
>
>
>
> *[JCZ] **Do you mean that there are other fragments after 4 that are not
> depicted, or that the All-1 is transmitted alone in the last window?
> Perhaps explaining this would help the discussion.*
>
>
> *[JCZ] **Again, in the implementation that I have in mind the transmitter
> would send the missing fragment followed by the next not-yet-transmitted
> fragments in the same window. I would let Ivo et al. comment about the
> implementation they propose in their draft.*
>
>
>
> *Best, Juan Carlos *
>
>
>
>
>

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Wed, 18 Sep 2019 20:24:28 +0000

Hi Rodrigo,

From: Rodrigo Muñoz <[email-masked]>
Sent: September 18, 2019 3:57 PM
To: Juan Carlos Zuniga <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; Sandra Cespedes <[email-masked]>
Subject: Re: [lp-wan] Flow validation in ACK-on-error Mode

[Rodrigo]: I’ll write to the authors of the LoRaWAN draft. In LoRaWAN you can send fragments while you wait for the ACK the lost fragment, but in my scheme, I supposed that the ACK is sent by the receiver the end of the SCHC window of the lost fragment.

[Rodrigo]: In my scheme, I supposed that the ACK is sent by the receiver the end of the SCHC window of the lost fragment. The size window is of 4 fragments. I send the All-1 because in the draft (draft-ietf-lpwan-ipv6-static-context-hc-21) say in 8.4.3.1<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F8.4.3.1&data=02%7C01%7Cjuancarlos.zuniga%40sigfox.com%7C5d6ac52f661b4aff5d5e08d73c725bc7%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637044334178125451&sdata=wdo2IyAX412lb854YC7D%2BFIpnPirBTCvKc8afyArdys%3D&reserved=0>: “On Retransmission Timer expiration: if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to the last window,”

[JCZ] >> True. If the window is NOT the last one, you would send a SCHC ACK REQ to ask for the assumed missing SCHC ACK. OTOH, if the window is the last one (i.e. there are no more pending fragments to transmit), you can simply send the All-1 indicating end of transmission and requesting SCHC ACK at the same time.
Best, Juan Carlos

This All-1 would trigger again the receiver to send a SCHC ACK, which would notify the sender of the correct (or not) reception of all the previous fragments.
[Rodrigo]: Yes, I also agree with you

[Rodrigo]: I’ll write to the authors of the LoRaWAN draft. Thanks

Olivier and Ivailo. Can you help me?

El lun., 16 sept. 2019 a las 20:13, Juan Carlos Zuniga (<[email-masked]<mailto:[email-masked]>>) escribió:
Hi Rodrigo,

From: Rodrigo Muñoz <[email-masked]<mailto:[email-masked]>>
Sent: September 16, 2019 3:59 PM
To: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Sandra Cespedes <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] Flow validation in ACK-on-error Mode

My comments below:

Best, Juan Carlos

Thanks for your enquiry.

I hope this helps.

Best,

Juan Carlos

Dear Author,

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 23 Sep 2019 11:14:50 +0000

Hi Rodrigo,

From what I understand the second image your question is: “How does the transmitter knows when to send the All-1 SCHC message” ?
In LoRaWAN class A there is no way to initiate communication from the network, device has to send an uplink so it can open RX windows.

So the device can send the All-1 as soon as RX1, RX2 widows are over without downlink. Please see attached picture

I propose to change the following sentence of §5.1.1, it is clearer for you ?

> At the end of a window or a
> fragmentation session, corresponding ACK(s) is (are) transmitted
> by the network gateway (LoRaWAN application server) in the RX1 or
> RX2 receive slot of end-device.  If this ACK is not received the
> end-device sends an all-0 (or an all-1) fragment with no payload
> to request an SCHC ACK retransmission.

to

> At the end of a window or a
> fragmentation session, corresponding ACK(s) is (are) transmitted
> by the network gateway (LoRaWAN application server) in the RX1 or
> RX2 receive slot of end-device.  If this ACK is not received *by* the
> end-device *at the end of its RX windows, it* sends an all-0 (or an all-1) fragment with no payload
> to request an SCHC ACK retransmission.

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: Rodrigo Muñoz <[email-masked]>
Date: Mon, 23 Sep 2019 14:07:22 -0300

Excelent Olivier!!!!

Thanks for explication. Finally I understood

Regards

El lun., 23 de septiembre de 2019 08:14, Olivier Gimenez <
[email-masked]> escribió:

> Hi Rodrigo,
>
> From what I understand the second image your question is: “How does the
> transmitter knows when to send the All-1 SCHC message” ?
> In LoRaWAN class A there is no way to initiate communication from the
> network, device has to send an uplink so it can open RX windows.
>
> So the device can send the All-1 as soon as RX1, RX2 widows are over
> without downlink. Please see attached picture
>
> 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: Rodrigo Muñoz <[email-masked]>
Date: Wed, 25 Sep 2019 20:11:01 -0300

Hi Olivier

I forgeted answer your question. Yes, I'm agree with the below description

> to request an SCHC ACK retransmission.

Thanks for consider my request

Regards