Subject: Re: [lp-wan] LoRaWAN profile - Retransmission timer

From: Olivier Gimenez <[email-masked]>
Date: Tue, 2 Jun 2020 16:38:47 +0000

Dear,

Here is my proposition following today's interim, for comments:

  Retransmission timer: Set by the implementation depending on the application
  requirements. As LoRaWAN class A devices can only receive a message after an
  uplink the retransmission timer might expire before the SCHC ACK REQ is send
  by the NGW.  In this case implementation SHALL ensure that only one SCHC ACK REQ
  is queued. If the NGW is not able to provide queue status, implementation MAY
  disable retransmission timer or set it to a value greater than the inactivity
  timer

Best regards
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: Alexander Pelov <[email-masked]>
Date: Wed, 3 Jun 2020 09:49:37 +0200

Dear Olivier,

Thanks for the mail! It captures what we discussed yesterday in great
detail.

(chair hat off)

Suggestion of wording:

...

In this case implementation SHALL ensure that only one SCHC ACK REQ

  is queued. In case the implementation cannot ensure that only one SCHC
ACK REQ is queued

(e.g. the NGW is not able to provide queue status), the implementation MAY

  disable retransmission timer or set it to a value greater than the
inactivity

  timer.

Seems a little bit more generic (e.g. maybe the NGW does not provide a
queue status, but there is another way to find out).

But that's a small detail - I'm happy with the way you phrased the
paragraph.

Cheers,

Alexander

On Tue, Jun 2, 2020 at 6:38 PM Olivier Gimenez <[email-masked]> wrote:

> Dear,
>
>
>
> Here is my proposition following today’s interim, for comments:
>
>
>
> 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.
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 3 Jun 2020 10:13:16 +0200

Hello,

Please find an inline comment below:

> ....

I think that the "SHALL" needs to be a "SHOULD".

(Note that "SHALL" corresponds to the same requirement level as "MUST".)

The above sentence has a "SHALL", but then the subsequent sentence allows
not complying with it, so the former cannot really be a "SHALL"...

Cheers,

Carles

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jun 2020 12:11:00 +0000

Yes, and in a general manner we tend to use MUST rather than SHALL.

  Retransmission timer: Set by the implementation depending on the application
  requirements. As LoRaWAN class A devices can only receive a message after an
  uplink the retransmission timer might expire before the SCHC ACK REQ is send
  by the NGW.  In this case an implementation SHOULD ensure that only one SCHC ACK REQ
  is queued. If the NGW does not provide enough information, the implementation MUST
  either disable retransmission timer or preferably set it to a value greater than half the inactivity
  timer

Note the "half" and "preferably" which at least allows for one retry while never having 2.

Take care,

Pascal

> -----Original Message-----
> From: lp-wan <[email-masked]> On Behalf Of Carles Gomez
> Montenegro
> Sent: mercredi 3 juin 2020 10:13
> To: Alexander Pelov <[email-masked]>
> Cc: Olivier Gimenez <[email-masked]>; lp-wan <[email-masked]>
> Subject: Re: [lp-wan] LoRaWAN profile - Retransmission timer
> 
> Hello,
> 
> >   is queued. In case the implementation cannot ensure that only one
> > SCHC ACK REQ is queued (e.g. the NGW is not able to provide queue
> > status), the implementation MAY
>

---

From: Olivier Gimenez <[email-masked]>
Date: Fri, 5 Jun 2020 17:28:57 +0000

Thank you all for your suggestions.
After stepping back and looking at the issue from a higher point of view, thanks to Dominique:

The initial comment from Ana was "Retransmission timer should not be deactivated" and my answer was "it must be done for class A downlinks (Ack-Always fragmentation)", then we tried to find a workaround for current draft working with:
 * NGW allowing to control the queue
 * NGW not allowing you to control it.
There is an option which might solve the issue, and another we did not discuss: creating a SCHC heartbeat for class A devices

*LoRaWAN class B&C*:
There is no issue to use retransmission timer as devices will have regular (class B) or continuous (class C) downlink opportunity

*LoRaWAN class A*:
The heartbeat will open a downlink opportunity at a pace defined by the application. By setting the retransmission timer to an higher value (ex: 3 times more than the heartbeat) it will ensure:
 * Device will have downlink opportunities without relying on non SCHC traffic
 * When the SCHC gateway cannot control the NGW downlink queue, it will not contain several SCHC ACK REQ are they already had several downlinks opportunities

Then it will also solve another issue: how the initial downlink fragmentation starts ? The SCHC gateway need to start a downlink fragmentation session: in class A, if the device does not send any uplink the inactivity timer might trigger before the first downlink is send. Thanks to the heartbeat we can ensure that there will be one or several downlink opportunity before the inactivity timer expiration.

The proposed heartbeat message format can be in the form of a new reserved port (=ruleId) with empty payload, and this prepare the future for the draft Pascal created regarding the command registry

Any comment ?

Thank you
Olivier

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jun 2020 05:43:33 +0000

Hello Olivier 

This looks great; note that the heartbeat does not come from the application but from the SCHC fragment layer. It is only active when there is a fragment going. So why not make it a normal ack that says where you are since the last ack might be lost? 

This changes the SCHC fsm, adding a new timer to resend the ack proactively. Your draft may thus indicate that formally, maybe saying that you update SCHC.

Take care,

Pascal

> Le 5 juin 2020 à 19:29, Olivier Gimenez <[email-masked]> a écrit :
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jun 2020 05:51:08 +0000

Let us be clear I mean resend the last thing that was sent and even that I’m not 100% sure is innocuous with SCHC fsm. Food for thoughts...

Regards,

Pascal

> Le 8 juin 2020 à 07:44, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Hello Olivier 
>

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 8 Jun 2020 06:23:40 +0000

Hi Pascal,

Your proposition is what is currently described in the draft-007, please see "5.6.3.5.  Class A end-device": the retransmission timer have been moved to SCHC receiver. I should have put more context in previous communication, but I have been told that we cannot deactivate "retransmission timer" from SCHC sender by reviewers.
Dominique told me that it has been discussed for the RFC8724 but not kept.

The proposition in my last email is to have this heartbeat even when there is no SCHC fragment on going, this solve the issue when the SCHC gateway needs to start a fragmentation session but the class A device does not emit anything, so there is no RX window

Best regards
Olivier

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jun 2020 14:34:27 +0000

Oups, OK I missed that.

If this is out of the fragmentation, this can be anytime then. Now I'm' confused: What difference is there between that and a class B?

Pascal

> From: Olivier Gimenez <[email-masked]>
> Sent: lundi 8 juin 2020 08:24
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: lp-wan <[email-masked]>; Carles Gomez Montenegro
> <[email-masked]>; Alexander Pelov <[email-masked]>
> Subject: RE: [lp-wan] LoRaWAN profile - Retransmission timer
> 
> Hi Pascal,
> 
> Your proposition is what is currently described in the draft-007, please see
> "5.6.3.5.  Class A end-device": the retransmission timer have been moved to
> SCHC receiver. I should have put more context in previous communication, but
> I have been told that we cannot deactivate "retransmission timer" from SCHC
> sender by reviewers.
> The proposition in my last email is to have this heartbeat even when there is no
> SCHC fragment on going, this solve the issue when the SCHC gateway needs to
> start a fragmentation session but the class A device does not emit anything, so
> there is no RX window
> 
> 
> Best regards
> Olivier
> 
> collect, process and share, and the rights and options you have in this respect,
> see www.semtech.com/legal.

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 8 Jun 2020 15:11:38 +0000

In class B the device is tracking a beacon which helps it to synchronise configurable RX window every [2; 128] seconds. The beacon is coming from the gateways and they rely on the PPS signal of their embedded GPS receiver.

What we propose is to have an uplink every X minutes/hours/days/weeks selected by the application:
 * No dependency on outdoor gateways (for GPS)
 * Configurable heartbeat value so device power consumption is not impacted, as the application will configure it to match its needs

Olivier

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jun 2020 15:58:50 +0000

WFM...

How can we tune the uplink so that if there are more applications / more app needs, there will be more uplinks?
Typically there's a form of adaptive time out that augments (like exponentially) when the uplink does not trigger downstream.

Take care

Pascal

> Sent: lundi 8 juin 2020 17:12
> In class B the device is tracking a beacon which helps it to synchronise
> configurable RX window every [2; 128] seconds. The beacon is coming from the
> gateways and they rely on the PPS signal of their embedded GPS receiver.
> 
>  * Configurable heartbeat value so device power consumption is not impacted,
> as the application will configure it to match its needs
> 
> Olivier
>

---

From: Olivier Gimenez <[email-masked]>
Date: Tue, 9 Jun 2020 07:02:43 +0000

Hi Pascal,

> From: Pascal Thubert (pthubert) <[email-masked]>

I think that most application will not need dynamic change for it, but if they do it will also require it for retransmission/inactivity timer changes accordingly, so I would say that it is out of scope of LoRaWAN profile. Is it an issue for you ?

> Typically there's a form of adaptive time out that augments (like exponentially)
> when the uplink does not trigger downstream.

In this case the heartbeat also helps to initiate communication from SCHC gateway, so I do not think that adaptive timing should be used. Heartbeat adaptive timing will also create issues with retransmission/inactivity timer

Olivier

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Jun 2020 07:25:01 +0000

I'm good with that Olivier; just checking.

In any fashion I feel that the larger problem of an asynchronous cross-app pull from the class A device is a LoRaWAN problem, not an IETF problem.

Take care,

Pascal.

> Sent: mardi 9 juin 2020 09:03
> > From: Pascal Thubert (pthubert) <[email-masked]> How can we tune
> > the uplink so that if there are more applications / more app needs,
> > there will be more uplinks?
> 
> I think that most application will not need dynamic change for it, but if they do
> it will also require it for retransmission/inactivity timer changes accordingly, so
> I would say that it is out of scope of LoRaWAN profile. Is it an issue for you ?
> 
> > Typically there's a form of adaptive time out that augments (like
> > exponentially) when the uplink does not trigger downstream.
> 
> In this case the heartbeat also helps to initiate communication from SCHC
> gateway, so I do not think that adaptive timing should be used. Heartbeat
> adaptive timing will also create issues with retransmission/inactivity timer
> 
> 
> Olivier
>

---

From: <[email-masked]>
Date: Tue, 9 Jun 2020 10:31:32 +0000

Hello Pascal, Olivier,

I concur.
The generic SCHC Ack-Always and Ack-on-Error modes require bidirectional
links.
If one wants to use them on quasi-bidirectional links, such as LoRaWAN
Class A, one needs to make sure that the link appears bidirectional to
SCHC.
The proposal by Olivier is that the schc-over-larawan instantiation makes
the Class A link bidirectional for the generic SCHC fragmentation to work.
It does that by adding an uplink hartbeat message. The period is to be
configured as part of the context, same as everything SCHC-related.
Whoever writes the context knows the application, that's a premise of
SCHC. Therefore, he/she is also able to draw the trade-off between power
consumption and downlink latency.
I like this solution, it is clean.
I'd love to hear yeahs or neahs from the device manufacturers.

Dominique

Le 09/06/20 09:25, « lp-wan on behalf of Pascal Thubert (pthubert) »
<[email-masked] on behalf of pthubert=[email-masked]>
a écrit :

>In any fashion I feel that the larger problem of an asynchronous
>cross-app pull from the class A device is a LoRaWAN problem, not an IETF
>problem.
>
>Take care,
>
>Pascal.
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Olivier Gimenez <[email-masked]>
Date: Thu, 11 Jun 2020 19:40:07 +0000

Thank you Dominique. Before I write the proposition in the draft, is there any other comment ?

Best regards
Olivier

> From: [email-masked] <[email-masked]>
> 
> I concur.

---

From: Ivaylo Petrov <[email-masked]>
Date: Fri, 12 Jun 2020 09:32:49 +0200

Hello,

I also like this solution. It will make reasoning about and configuring the
class A device timers, etc much simpler and as Dominique pointed out, the
tradeoff between power efficiency and latency would be done for each
application individually allowing in my opinion optimal performance.

Cheers,
Ivaylo

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 15 Jun 2020 22:53:02 +0000

Hi,

Here is the proposed text for downlink retransmission timer (Ack-Always):

#### Retransmission timer

Class A and Class B or Class C devices do not manage retransmissions and timers
in the same way.

##### Class A devices  {#uplink-class-a}

Class A devices can only receive in an RX slot following the transmission of an
uplink.  Therefore the SCHC gateway cannot initiate communication to a Class A
device.
Class A devices SHALL implement an heartbeat sending uplink on port
FPortCommandControl with an empty payload.  It will create a downlink
opportunity for the SCHC gateway to start a SCHC session or send the SCHC ACK
REQ if the retransmission timer expires.  Timing is application specific,
RECOMMENDED value is one heartbeat every 12h.

The device replies with an SCHC ACK message to every single fragment received
from the SCHC gateway:

* FCN=0: All fragment but the last have an FCN=0 (because window size is 1).
  Following it the device SHALL transmit the SCHC ACK. It SHALL transmit up to
  MAX_ACK_REQUESTS ACK messages before aborting. The device should transmit
  those ACK as soon as possible while taking into consideration potential local
  radio regulation on duty-cycle, to progress the fragmentation datagram as
  quickly as possible. The ACK bitmap is 1 bit long and is always 1.

* FCN=1: The last fragment of a datagram. If the RCS is correct, the device
  SHALL transmit the ACK with the bit C=1. This message might be lost
  therefore the SCHC gateway MUST request a retransmission of this ACK in the
  next downlink when the retransmission timer expires.  The device SHALL keep
  this ACK message in memory until it receives a downlink, on SCHC FPortDown
  different from an SCHC ACK REQ: it indicates that the SCHC gateway has
  received the ACK message.

The SCHC gateway implements an inactivity timer with a RECOMMENDED duration
of 48 hours. For devices with very low transmission rates (example 1 packet a
day in normal operation), that duration may be extended, but this is application
specific.

#### Class B or Class C devices

Class B devices can receive in scheduled RX slots or in RX slots following the
transmission of an uplink. Class C devices are almost in constant reception.
For those classes there is no need of an heartbeat to open RX window.

RECOMMENDED retransmission timer value:

* Class B: 3 times the ping slot periodicity.
* Class C: 30 seconds

The RECOMMENDED transmission timer value is 12 hours for both Class B and Class
C devices.

Olivier

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Jun 2020 07:43:21 +0000

Hello Olivier

“SHALL” is the common term in many SDOs inc. IEEE and it is legal at IETF; still we’re used to “MUST” and it would be probably nicer to the community to use that term.

about
“

The device should transmit
  those ACK as soon as possible while taking into consideration potential local
  radio regulation on duty-cycle, to progress the fragmentation datagram as
  quickly as possible.
“

The text hints that the device should delaying the SCHC ack (inserting a inter-schc-ack gap) to limit the pressure on the NGW duty cycle.
Since the gap is bounded by the setting of retransmission timers, I believe that the text could be more specific, like give a name and a range to the gap.

an SCHC ACK REQ -> a SCHC ACK REQ since we pronounce “chic”

Take care,

Pascal

From: Olivier Gimenez <[email-masked]>
Sent: mardi 16 juin 2020 00:53
To: lp-wan <[email-masked]>
Cc: [email-masked]; Ivaylo Petrov <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; Carles Gomez Montenegro <[email-masked]>; Alexander Pelov <[email-masked]>
Subject: RE: [lp-wan] LoRaWAN profile - Retransmission timer

Hi,

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<http://www.semtech.com/legal>.

---

From: Olivier Gimenez <[email-masked]>
Date: Tue, 16 Jun 2020 08:07:35 +0000

Thank you Pascal. I will change shall to must.

Regarding device ACK it is not to release pressure on NGW, just a reminder that regulation should be respected. But following the discussion we had last interim I guess that:
The device should transmit those ACK as soon as possible to progress the fragmentation datagram as quickly as possible.
Is enough as regulation is ensured by LoRaWAN stack

Olivier

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Jun 2020 08:29:54 +0000

Hello Olivier:

> Regarding device ACK it is not to release pressure on NGW, just a reminder that regulation should be respected.
That’s what I meant by duty cycle…

> But following the discussion we had last interim I guess that:

Well tried, but “as soon as possible” is obfuscating the tension between the retransmission timer and the duty cycle, leaving the implementor with the guess work. A spec is supposed to tell the implementer what to do. If it cannot, then at least it must explain the tension and the limits.

I understand the problem as follows (correct me if I miss something):

  *   On the one hand, the device must wait before sending the ack to protect the NGW duty cycle. But it has no clue on how much the NGW is consuming its duty cycle at this time.
  *   On the other hand the device must not wait more than retransmission timer, else the end points are desynchronized and enter unduly a recovery scenario.

So what can you do to make the life of the implementor a bit easier?

When we do not know better we usually provide a configuration knob or a rule of a thumb.

In this case, you may (for instance) index the inter-schc-ack-gap to the retransmission timer, like 40% of it. If you do that, there will be time to send the schc-ack twice before the retransmission timer elapses.

This way, in a deployment that is very loaded, it is always possible to use a longer the retransmission timer, and that will naturally slow the SCHC fragments.

See you at the interim,

Pascal

From: Olivier Gimenez <[email-masked]>
Sent: mardi 16 juin 2020 10:08
To: Pascal Thubert (pthubert) <[email-masked]>; lp-wan <[email-masked]>
Cc: [email-masked]; Ivaylo Petrov <[email-masked]>; Carles Gomez Montenegro <[email-masked]>; Alexander Pelov <[email-masked]>
Subject: RE: [lp-wan] LoRaWAN profile - Retransmission timer

Regarding device ACK it is not to release pressure on NGW, just a reminder that regulation should be respected.

But following the discussion we had last interim I guess that:
The device should transmit those ACK as soon as possible to progress the fragmentation datagram as quickly as possible.
Is enough as regulation is ensured by LoRaWAN stack

---

From: Olivier Gimenez <[email-masked]>
Date: Tue, 16 Jun 2020 09:09:31 +0000

[OG] No, the device must wait to respect its own duty cycle to meet the regulation. As you say devices has not clue about RGW duty cycle and we cannot create an algorithm on the device to release pressure on it. It is up to the NGW to optimise and select relevant RGW for each downlink.

The idea behind “as soon as possible” is to ask the SCHC stack to send the ACK without any delay so the fragmentation session can continue without any time lost. How can we formalize it ? Maybe “The device should immediately transmit those ACK if no SCHC downlink have been received during RX1 and RX2 window” ?

[OG] Asking all devices to delay by a fixed amount of time the ACK retransmission will not release pressure on RGW as at this time the duty cycle for this specific RGW might still high because of other devices.  Olivier Seller (LoRa inventor) did a nice talk about radio planning: https://www.youtube.com/watch?v=VmYuItA6q4I

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Jun 2020 09:39:29 +0000

Hello Olivier

Thanks for the link, I’ll watch it.

At least the disagreement is clarified. So the “as soon as possible” is intended as “immediately” within the device capabilities, no wait. And this is what I object to.

If a device sends the ack as soon as possible without any forced gap, then the NGW is constrained to reply immediately or loose the slot. If the NGW has used its full duty cycle it loses that opportunity. When the load on the NGW grows, we end in retransmission timer for all devices and congestion collapse.

This is why there is such a thing as flow control. Which usually starts with the source pacing its traffic. Usually we protect the receive buffers on the destination, here it’s the NGW duty cycle that cannot be exceeded. This is what I meant by “protect the NGW duty cycle”.

In this case, we might not be able to afford a very complex flow control. But I do think you need a something. Inserting a tunable gap makes sense to me, but feel free to propose some other approach. Not doing anything is the recipe for an interesting future.

Take care,

pascal

Sent: mardi 16 juin 2020 11:10

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>

---

From: Olivier Gimenez <[email-masked]>
Date: Tue, 16 Jun 2020 10:05:40 +0000

[OG] Ok, I will update

[OG] We can plan for it at SCHC level, but I do not think that having the same delay for all will resolve the issue. We might define to add a random delay instead

---

From: Ivaylo Petrov <[email-masked]>
Date: Tue, 16 Jun 2020 15:39:54 +0200

Hello,

This is a very interesting discussion with a number of unknowns regarding
future deployments, but here are my 2c. Obviously trying to plan how much
duty cycle the NGW will have is impossible from the device side without
some significant extra complexity (the simplest mitigation that comes to
mind is some method to increase delay between uplinks as long as there are
missing downlinks). In theory, there could be many different RGWs that
cover a set of devices and they each have more duty cycle than each device
(but are significantly less than the devices obviously, therefore the
amount of duty cycle needed by the RGWs will depend on the time when
devices try to communicate). So having a really good idea how the system
would behave would require either observations on large scale deployments,
or good simulations. Without any of those two inputs, I feel that we will
be guessing a lot. That being said, adding some small random variation in
the time of uplink can help in case many devices try to receive information
at exactly the same time for some reason (during some network
initialization or something else).

Simply slowing the devices will obviously decrease the chance of issues as
there are expected to be less messages at any given time and less load on
the RGWs, but would limit some possible use cases, because of the reduced
reactivity. I am yet to see evidence that slowing the devices in a way that
will not decrease the volume of messages being sent will have a real
positive effect on the peak network usage.

Cheers,
Ivo

On Tue, Jun 16, 2020 at 12:05 PM Olivier Gimenez <[email-masked]>
wrote:

>
>
>
>
> *From:* Pascal Thubert (pthubert) <[email-masked]>
> At least the disagreement is clarified. So the “as soon as possible” is
> intended as “immediately” within the device capabilities, no wait. And this
> is what I object to.
>
>
>
> [OG] Ok, I will update
>
>
>
> If a device sends the ack as soon as possible without any forced gap, then
> the NGW is constrained to reply immediately or loose the slot. If the NGW
> has used its full duty cycle it loses that opportunity. When the load on
> the NGW grows, we end in retransmission timer for all devices and
> congestion collapse.
>
> This is why there is such a thing as flow control. Which usually starts
> with the source pacing its traffic. Usually we protect the receive buffers
> on the destination, here it’s the NGW duty cycle that cannot be exceeded.
> This is what I meant by “protect the NGW duty cycle”.
>
> In this case, we might not be able to afford a very complex flow control.
> But I do think you need a something. Inserting a tunable gap makes sense to
> me, but feel free to propose some other approach. Not doing anything is the
> recipe for an interesting future.
>
>
>
> [OG] We can plan for it at SCHC level, but I do not think that having the
> same delay for all will resolve the issue. We might define to add a random
> delay instead
>
>
>
>
>
>
>

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 16 Jun 2020 15:47:32 +0200

Hi Olivier, all,

Lots of interesting input for the discussion!

One point :
For me SCHC deals with SCHC fragments and Rules / RuleID. There seems to be
a pretty good way to map SCHC RuleID -> FPort.
I think it would be better to have a SCHC Rule instead of specifying an
FPort for the uplink message. (the specific SCHC Rule will then map to the
desired FPort of course)

Cheers,
Alexander

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 22 Jun 2020 14:27:53 +0000

Hi,

I made changes to class A devices retransmission timer following last interim.

1.       I removed “heartbeat” word, but did not used “polling” as I think that there is no need to put a name to this mechanism anymore

2.       It is now RECOMMENDED to send an uplink every 24 hours. It can be disabled and timing is chosen by the application => this fix the issue when SCHC gateway needs to start a SCHC session

3.       Class A retransmission timer is now specified, mechanism to create downlink opportunity for the NGW is defined.

The changes are following otherwise it is this commit<https://github.com/Acklio/schc-over-lorawan/commit/24b8d2299ebd7e5b02ef08ee61a8753627268def>

Olivier

### Downlink fragmentation: From SCHC gateway to device
Class A devices can only receive in an RX slot following the transmission of an
uplink.  Therefore the SCHC gateway cannot initiate communication (ex: new SCHC
session);  in order to create a downlink opportunity it is RECOMMENDED for
Class A devices to send an uplink every 24 hours when no SCHC session is
started, this is is application specific and can be disabled. RECOMMENDED uplink
is a LoRaWAN message without FPort and FRM payload.

#### Downlink retransmission timer {#downlink-retransmission-timer}

##### Class A devices

uplink.

The SCHC gateway implements an inactivity timer with a RECOMMENDED duration
of 36 hours.  For devices with very low transmission rates (example 1 packet a
day in normal operation), that duration may be extended: it is application
specific.

RETRANSMISSION_TIMER is application specific and its RECOMMENDED value is
INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).

**SCHC All-0 (FCN=0)**
All fragment but the last have an FCN=0 (because window size is 1).  Following
it the device MUST transmit the SCHC ACK message. It MUST transmit up to
MAX_ACK_REQUESTS SCHC ACK messages before aborting.  In order to progress the
fragmentation datagram as quickly as possible, the device should immediately
transmit those SCHC ACK if no SCHC downlink have been received during RX1 and
RX2 window.

_Note_: The ACK bitmap is 1 bit long and is always 1.

**SCHC All-1 (FCN=1)**
The last fragment of a datagram, the corresponding SCHC ACK message might be
lost; therefore the SCHC gateway MUST request a retransmission of this ACK when
the retransmission timer expires.  To open a downlink opportunity the device
MUST transmit an uplink every RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 2) hours.
The format of this uplink is application specific.  It is RECOMMENDED for a
device to send an empty uplink (no FPort and FRMPayload) but it is application
specific and will be used by the NGW to transmit a potential SCHC ACK REQ.

_Note_: The device MUST keep this SCHC ACK message in memory until it receives
a downlink, on SCHC FPortDown different from an SCHC ACK REQ: it indicates that
the SCHC gateway has received the ACK message.

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 22 Jun 2020 14:33:39 +0000

Hi,

Is there any other input on that discussion ? Should we try to plan for network load and how ?
I think that this should not be managed on SCHC level, or we can add some random delay in retransmission timer, but it will be difficult to do more

Best regards
Olivier

From: Ivaylo Petrov <[email-masked]>
Sent: 16 June 2020 15:40
To: Olivier Gimenez <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; lp-wan <[email-masked]>; [email-masked]; Carles Gomez Montenegro <[email-masked]>; Alexander Pelov <[email-masked]>
Subject: Re: [lp-wan] LoRaWAN profile - Retransmission timer

Hello,

This is a very interesting discussion with a number of unknowns regarding future deployments, but here are my 2c. Obviously trying to plan how much duty cycle the NGW will have is impossible from the device side without some significant extra complexity (the simplest mitigation that comes to mind is some method to increase delay between uplinks as long as there are missing downlinks). In theory, there could be many different RGWs that cover a set of devices and they each have more duty cycle than each device (but are significantly less than the devices obviously, therefore the amount of duty cycle needed by the RGWs will depend on the time when devices try to communicate). So having a really good idea how the system would behave would require either observations on large scale deployments, or good simulations. Without any of those two inputs, I feel that we will be guessing a lot. That being said, adding some small random variation in the time of uplink can help in case many devices try to receive information at exactly the same time for some reason (during some network initialization or something else).

Simply slowing the devices will obviously decrease the chance of issues as there are expected to be less messages at any given time and less load on the RGWs, but would limit some possible use cases, because of the reduced reactivity. I am yet to see evidence that slowing the devices in a way that will not decrease the volume of messages being sent will have a real positive effect on the peak network usage.

Cheers,
Ivo

On Tue, Jun 16, 2020 at 12:05 PM Olivier Gimenez <[email-masked]<mailto:[email-masked]>> wrote: