For IN865 and EU868 Data Rate not changed for Join request retransmission

[PG430]

Hi,

As per LoRa Spec: When an end-device attempts the transmission of a "confirmed" frame toward the network it expects to receive an acknowledgement in one of the subsequent reception slot. In the absence of the acknowledgement it will try to re-transmit the same data again. Re-transmission happens on a new frequency channel, but can also happen at a different data rate (preferable lower) than the previous one.

It is strongly recommended to adopt the re-transmission strategy as stated in the LoRaWAN specification, Section 18.4:

Above should also apply to the "JOIN request Retransmission" but STM32WLE release 1.1.0 using same data rate for all the JOIN request Retransmission. Working on IN865 and EU868 and identify this problem. Possibly it is also same in other region too.

Logs are attached for are details joinRequestLogs.txt

[ASELSTM]

ST Internal Reference: 134776

[ASELSTM]

Hi @PG430,

Referring to our development team the Join Requests are still unconfirmed and the retransmission section 18.4 describes only the DR usage for the Confirmed Data Uplink.

In section 4.2.1 of the L2 v1.0.3 specification, the Message Type describes the MAC Payload content:

MType     Description
000       Join Request
001       Join Accept
010       Unconfirmed Data Uplink
011       Unconfirmed Data Downlink
100       Confirmed Data Uplink
101       Confirmed Data Downlink
110       RFU
111       Proprietary

The section 18.4 describes only the retransmission for the Confirmed Data Uplink (100) with 8 retries (by default) of the same data payload + FrameCount.

And this DR downgrade is executed by this LoRaMac.c method:

static void AckTimeoutRetriesProcess( void )
{
    if( MacCtx.AckTimeoutRetriesCounter < MacCtx.AckTimeoutRetries )
    {
        MacCtx.AckTimeoutRetriesCounter++;
        if( ( MacCtx.AckTimeoutRetriesCounter % 2 ) == 1 )
        {
            GetPhyParams_t getPhy;
            PhyParam_t phyParam;

            getPhy.Attribute = PHY_NEXT_LOWER_TX_DR;
            getPhy.UplinkDwellTime = Nvm.MacGroup2.MacParams.UplinkDwellTime;
            getPhy.Datarate = Nvm.MacGroup1.ChannelsDatarate;
            phyParam = RegionGetPhyParam( Nvm.MacGroup2.Region, &getPhy );
            Nvm.MacGroup1.ChannelsDatarate = phyParam.Value;
        }
    }
}

For the Join procedure, all requests are unique and cannot be re-transmitted by the same 'confirmed' method. So, the Join DR is defined by the user LmHandlerParams.TxDatarate init structure :

void LmHandlerJoin( ... )
{
    MlmeReq_t mlmeReq;
    mlmeReq.Type = MLME_JOIN;
    mlmeReq.Req.Join.Datarate = LmHandlerParams.TxDatarate;

The LmHandlerParams.TxDatarate value must be defined for the worst end_device configuration, to prevent some unexpected data loss. The Adaptive Datarate feature will increase or decrease the DR in running (after the join accept). But the Join procedure must be pre-defined with acceptable parameters for your infrastructure.

Additionally, the TS001-Link Layer v1.0.4 specification doesn't more contain this section 18.4 Data-Rate Adaptation during Message Retransmissions. This deletion seems described by :

• ADR behaviors clarified

• Improved the ADR Backoff Example

Its maybe because this algorithm is redundant with the datarate downgrade option defined in the ADR feature.

With regards

[PG430]

@ASELSTM thank you for the detailed clarification. helps a lot to understand this point in better than source

[ASELSTM]

Hi @PG430,

Pleased to know that this has helped you. Please allow me thus to close this thread.

With regards,