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

From: Olivier Gimenez <[email-masked]>
Date: Thu, 2 Jul 2020 20:05:25 +0000

Hi,

As discussed during the interim I made 3 changes:

·         Let the application<https://github.com/Acklio/schc-over-lorawan/commit/bd7c7e39da565fa7b46fcbaba19784164290f814> customize the number of RX windows during SCHC ACQ REQ transmission after All-1 SCHC message

·         Clarify uplink<https://github.com/Acklio/schc-over-lorawan/commit/774ec3991adfadffd6422b512e71603e69789ffd> to initialize downlink fragmentation session with the text defined during interim

·         Clarify All-0<https://github.com/Acklio/schc-over-lorawan/commit/713dd4eb82e96743c2317e43d55309aa2ec0cdc3> retransmission timer with the text defined during interim

Best regards
Olivier

From: Olivier Gimenez
Sent: 22 June 2020 16:28
To: lp-wan <[email-masked]>
Subject: RE: [lp-wan] LoRaWAN profile - Retransmission timer

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.

This uplink could be avoid when there is application traffic

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

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

##### Class A devices

Class A devices can only receive in an RX slot following the transmission of an
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, the SCHC layer should immediately queue for transmission
those SCHC ACK if no SCHC downlink have been received during RX1 and
RX2 window. LoRaWAN layer will respect the regulation if required

_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. Factor 2 should be application specifics
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.

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.