LoRaMac hint "Joined", but "Joined failed” actually #1193

QINLIMIN · 2021-10-20T07:20:53Z

QINLIMIN
Oct 20, 2021

Hi, I face some issues when end-device had joined in NS but it cannot communicate with NS. After we check the debug log of end-device and the message on NS. We found that LoRaMac will think of itself joined once receive Join-Accept from NS, but as we know that end_device must send a ‘ConfirmDataUp’ to NS after receive Join-Accept, So a complete network join process should like as below:
Join-Request ——> Join-Accept ——> ConfirmDataUp ——> UnconfirmDataDown
But unfortunately, the end-device will set itself to “Joined" state once it only receive a “Join-Accept” message, even receive UnconfirmDataDown failed. It will make end-device never join again, it will cause communicate failed, isn’t it?
So static void OnJoinRequest( LmHandlerJoinParams_t* params ) it better to be called after a complete network join process, right?
Following, the debug log of end-device:

2005-8-2 0:42:34  Start to Join!
###### =========== MLME-Confirm ============ ######
STATUS      : Rx 2 timeout

###### =========== MLME-Confirm ============ ######
STATUS      : OK
###### ===========   JOINED     ============ ######

OTAA

DevAddr     :  260BAD2A


DATA RATE   : DR_0

###### =========== MCPS-Confirm ============ ######    ——> ConfirmDataUp failed
STATUS      : Rx 2 timeout

###### =====   UPLINK FRAME        1   ===== ######

CLASS       : C

TX PORT     : 0

DATA RATE   : DR_0
U/L FREQ    : 868500000
TX POWER    : 0
CHANNEL MASK: 00FF

And one more question, under what condition that end-device ofter got a “RX 2 timeout” error? Is it relative to “RECEIVE_DELAY” and “JOIN_ACCEPT_DELAY” definition? Because most time it got this error when use default value, which is 1000mS and 5000mS where in <RegionCommon.h>. But when I change to 980mS and 4950mS, it will have higher success rate.

/*!
* Receive delay of 1 second.
*/
#define REGION_COMMON_DEFAULT_RECEIVE_DELAY1 950 // Jimmy change, original is 1000

/*!
* Receive delay of 2 seconds.
*/
#define REGION_COMMON_DEFAULT_RECEIVE_DELAY2 ( REGION_COMMON_DEFAULT_RECEIVE_DELAY1 + 1000 )

/*!
* Join accept delay of 5 seconds.
*/
#define REGION_COMMON_DEFAULT_JOIN_ACCEPT_DELAY1 4975 // Jimmy change, original is 5000

Answered by mluis1

Oct 20, 2021

Could you please indicate the following elements:

Which LoRaWAN specification version are you using?
Which version of this project are you using?
Are you using one of this project supported platforms or your own one?

Back to your questions.

Once an end-device receives the JoinAccept message it means it has joined the Network. It has all the required information to operate under the specific NS (session keys as well as some basic network parameters).
In case of Class C end-devices the specification asks the end-devices to send Confirmed Uplinks up until they receive the ACK. These confirmed uplinks are there to inform the NS that the end-device is ready to receive downlinks on RXC windows.

View full answer

mluis1 · 2021-10-20T09:09:32Z

mluis1
Oct 20, 2021
Maintainer

Could you please indicate the following elements:

Which LoRaWAN specification version are you using?
Which version of this project are you using?
Are you using one of this project supported platforms or your own one?

Back to your questions.

Once an end-device receives the JoinAccept message it means it has joined the Network. It has all the required information to operate under the specific NS (session keys as well as some basic network parameters).
In case of Class C end-devices the specification asks the end-devices to send Confirmed Uplinks up until they receive the ACK. These confirmed uplinks are there to inform the NS that the end-device is ready to receive downlinks on RXC windows.

This stack will send automatically confirmed uplinks even in case the user tries to send unconfirmed uplinks.

LoRaMac-node/src/mac/LoRaMac.c

Lines 5231 to 5239 in 05353ff

    
           // Apply confirmed downlinks, if the device has not received a valid 
        
           // downlink after a join accept. 
        
           if( ( Nvm.MacGroup2.NetworkActivation == ACTIVATION_TYPE_OTAA ) && 
        
               ( Nvm.MacGroup2.DeviceClass == CLASS_C ) && 
        
               ( Nvm.MacGroup2.DownlinkReceived == false ) && 
        
               ( request.Type == MCPS_UNCONFIRMED ) ) 
        
           { 
        
               request.Type = MCPS_CONFIRMED; 
        
           }

In addition this behavior is checked by the LoRaWAN certification process and this project fulfills the requirement. Please refer to Releases pre-certification results wiki page chapter Release Version 4.5.2 to see the pre-certification results.

Concerning the second question.

The files under this project mac directory should not be modified.
Doing so will potentially break the pre-certification results.

In case you have timing issues related to your platform porting process you may increase the maximum tolerated time errors value.
The stack implementation automatically computes the time when the reception windows should be open taking in account this maximum error tolerance.

LoRaMac-node/src/mac/region/Region.h

Lines 940 to 977 in 05353ff

    
           /* 
        
            * Rx window precise timing 
        
            * 
        
            * For more details please consult the following document, chapter 3.1.2. 
        
            * https://www.semtech.com/uploads/documents/SX1272_settings_for_LoRaWAN_v2.0.pdf 
        
            * or 
        
            * https://www.semtech.com/uploads/documents/SX1276_settings_for_LoRaWAN_v2.0.pdf 
        
            * 
        
            *                 Downlink start: T = Tx + 1s (+/- 20 us) 
        
            *                            | 
        
            *             TRxEarly       |        TRxLate 
        
            *                |           |           | 
        
            *                |           |           +---+---+---+---+---+---+---+---+ 
        
            *                |           |           |       Latest Rx window        | 
        
            *                |           |           +---+---+---+---+---+---+---+---+ 
        
            *                |           |           | 
        
            *                +---+---+---+---+---+---+---+---+ 
        
            *                |       Earliest Rx window      | 
        
            *                +---+---+---+---+---+---+---+---+ 
        
            *                            | 
        
            *                            +---+---+---+---+---+---+---+---+ 
        
            *Downlink preamble 8 symbols |   |   |   |   |   |   |   |   | 
        
            *                            +---+---+---+---+---+---+---+---+ 
        
            * 
        
            *                     Worst case Rx window timings 
        
            * 
        
            * TRxLate  = DEFAULT_MIN_RX_SYMBOLS * tSymbol - RADIO_WAKEUP_TIME 
        
            * TRxEarly = 8 - DEFAULT_MIN_RX_SYMBOLS * tSymbol - RxWindowTimeout - RADIO_WAKEUP_TIME 
        
            * 
        
            * TRxLate - TRxEarly = 2 * DEFAULT_SYSTEM_MAX_RX_ERROR 
        
            * 
        
            * RxOffset = ( TRxLate + TRxEarly ) / 2 
        
            * 
        
            * RxWindowTimeout = ( 2 * DEFAULT_MIN_RX_SYMBOLS - 8 ) * tSymbol + 2 * DEFAULT_SYSTEM_MAX_RX_ERROR 
        
            * RxOffset = 4 * tSymbol - RxWindowTimeout / 2 - RADIO_WAKE_UP_TIME 
        
            * 
        
            * Minimal value of RxWindowTimeout must be 5 symbols which implies that the system always tolerates at least an error of 1.5 * tSymbol 
        
            */

The change of the SystemMaxRxError parameter value can be done by modifying the value provided to LmHandlerSetSystemMaxRxError function. In below example a 20 ms time error will be tolerated.

LoRaMac-node/src/apps/LoRaMac/periodic-uplink-lpp/NucleoL476/main.c

Lines 291 to 292 in 05353ff

    
           // Set system maximum tolerated rx error in milliseconds 
        
           LmHandlerSetSystemMaxRxError( 20 );

As it looks like you have timing issues I would recommend that you first validate your porting by setting your end-device in Class A mode of operation. Once you have validated the Class A operation then you can enable the Class C mode of operation.

While doing your platform debug please try to keep things simple at beginning (Class A) and then increase the difficulty (activate Class C).

In case you are a LoRa-Alliance member you can have access to the LCTT tool. This tool is used to pre-certify the end-devices. Please take a look at LoRa-Alliance web server certification page https://lora-alliance.org/lorawan-certification/ for further details.

5 replies

QINLIMIN Oct 20, 2021
Author

Thank you Sir,

Which LoRaWAN specification version are you using? ----> V1.0.4
Which version of this project are you using? ----> GitHub version to 4.4.7
Are you using one of this project supported platforms or your own one? ----> we ported to the other MCU, and created an new app

As 'LoRaWAN Link Layer Specification v1.0.4 Line-1548' document say The end-device that expects to receive Class C downlink frames SHALL send a confirmed uplink frame or a frame that requires an acknowledgment as soon as possible after receiving a valid Join-Accept frame.The end-device SHALL continue to send such frames until it receives the first downlink from the Network (while respecting duty cycles, if applicable, and retransmission timers). Means that the end-device must receive a downlink from NS after joined, which joined in ClassA, so should I re-send confirm uplink in our app code, until receive a downlink from NS?
But from the apps/demo code, they also only send uplink to NS one time after joined.

static void OnJoinRequest( LmHandlerJoinParams_t* params )
{
    DisplayJoinRequestUpdate( params );
    if( params->Status == LORAMAC_HANDLER_ERROR )
    {
        LmHandlerJoin( );
    }
    else
    {
        LmHandlerRequestClass( LORAWAN_DEFAULT_CLASS );     // only send uplink one time after join success
    }
}

If this uplink chance failed, NS will never know the class of end-device is C. Right?

For the timing issues on our platform, we will check that later.

mluis1 Oct 20, 2021
Maintainer

This project 4.4.7 version implements LoRaWAN specification 1.0.3 as stated in README.md Introduction chapter.

To use LoRaWAN specification 1.0.4 you need to base your code upon version v4.5.2 of this project.
The transmission of a confirmed uplink after the join procedure for Class C devices has been introduced within LoRaWAN specification 1.0.4.

The way the uplinks are scheduled are to be managed at the application layer.
This means that if your application does not receive the ACK to the first uplink it is up to your application to schedule further uplinks until it receives the ACK.

In the provided examples we will not observe this situation because the example periodically makes an uplink.

Concerning the timing issues. This is what you should work on first.
The reason why you should work on this first is because a LoRaWAN end-device requires to have a precise time handling in order to properly work.

QINLIMIN Oct 20, 2021
Author

1, Now I have create a timer, send a confirm uplink to NS after Joined. Once end-device receive an ACK, it will stop the timer. And it work normally now!
2, We are thinking how to confirm the timing on our hardware platform correct not. But currently we can ensure that the timing is working properly, otherwise the LoRaMac never can be run. It is possible that the timing error is large, which results in the asynchronous with NS. Can we change the tolerate to 50mS in this function:

// Set system maximum tolerated rx error in milliseconds
LmHandlerSetSystemMaxRxError( 20 );

mluis1 Oct 21, 2021
Maintainer

Yes, you can change the value to 50 ms.
However, do not increase it too much because then other issues start to happen. Changing this parameter will make the end-device to open reception windows earlier and for longer time.

Could you please mark the topic as answered?
It looks like you have the solution to your question.

QINLIMIN Oct 22, 2021
Author

OK, thank you.

QINLIMIN · 2021-10-22T03:20:58Z

QINLIMIN
Oct 22, 2021
Author

where can i set this discussion to answered?

1 reply

mluis1 Oct 22, 2021
Maintainer

Thanks. I have just marked as answer the previous thread instead.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LoRaMac hint "Joined", but "Joined failed” actually #1193

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 2 comments 6 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

LoRaMac hint "Joined", but "Joined failed” actually #1193

QINLIMIN Oct 20, 2021

Replies: 2 comments · 6 replies

mluis1 Oct 20, 2021 Maintainer

QINLIMIN Oct 20, 2021 Author

mluis1 Oct 20, 2021 Maintainer

QINLIMIN Oct 20, 2021 Author

mluis1 Oct 21, 2021 Maintainer

QINLIMIN Oct 22, 2021 Author

QINLIMIN Oct 22, 2021 Author

mluis1 Oct 22, 2021 Maintainer

QINLIMIN
Oct 20, 2021

Replies: 2 comments 6 replies

mluis1
Oct 20, 2021
Maintainer

QINLIMIN Oct 20, 2021
Author

mluis1 Oct 20, 2021
Maintainer

QINLIMIN Oct 20, 2021
Author

mluis1 Oct 21, 2021
Maintainer

QINLIMIN Oct 22, 2021
Author

QINLIMIN
Oct 22, 2021
Author

mluis1 Oct 22, 2021
Maintainer