MDot JoinBack off Concept?

[Ajay K]

Is there any documentation on the JoinBack off feature in the mdot? I am trying to better understand this particular feature and how it effects the MDot join process when join failure occurs repeatedly .

We recently ended up having a scenario where the conduit lost power in the field and there were all the MDot attempting to join the Conduit. However this attempt to join was made over a 24 hr period, until the power was restored this morning. So I was hoping to better understand the JoinBack off concept and how it effects the join network call and the getNextTms calls?

Thanks,
Ajay.

[Jason Reiss]

Details can be found here.

LoRa Backoff Requirements

[Ajay K]

Thanks a lot Jason for pointing me to the forum article. Just a few follow up questions based on the forum article notes.

1) I am assuming all that applies to private networks?
2) In the US frequency bands will the getNextTmMs return the back off time in ms and if this is significantly greater than a minute, its better to enter a deep sleep and then trying joining again?

3) In the forum article it mentions that the join is alternated between DR0 and DR4. One of the issues we face while joining is that the MDot tries to join at DR4 for a node that is at a significant distance from the conduit and not sure why the mdot is trying this data rate. Shouldn’t it be trying DR0 first and then if it manages to successfully connect to the conduit and then up the DR based on what the conduit drives the DR needs to be.

Thanks,
Ajay

[Jason Reiss]

LoraWAN 1.0.1 specifies the join procedure as alternating between DR0 and DR4. This is for instances when many nodes are attempting to join, some may be close enough for DR4.

The module can sleep while waiting for join backoff to expire. What else can the module do?

[Ajay K]

Thanks Jason for responding back so quickly. You are right about what else can a module do, during a join back off :).

On the joins however is it possible to force it to use SF_10 spread factor always? Since we use ADR, I am guessing the conduit will eventually drive the DR to DR4 when it deems it can operate at that DR?

Thanks,
Ajay

[Jason Reiss]

Nope, that is defined behavior of the protocol for join requests.

[Ajay K]

Thanks Jason. One last question is there a way to figure out if we have hit the Join Back off error scenario. The reason I ask is that we could make potentially decisions based on that in the code. Currently when I call the joinNetwork method, we always get -4 error code and that is generic join network error I am guessing. Is there a way to retrieve the actual error in this case being the join back off error?

Thanks,
Ajay

[Jason Reiss]

getNextTmMs will only return a value in US915 in a join backoff scenario.
Check it after a join failure.

[Ajay K]

Thanks a lot Jason, that helps a lot.

[Ajay K]

This was in the MDot logs, how come we are getting such a big number from the getNextTxMs for the join backoff interval? The percentages called out in the Join Backoff features, is that a function of time? FYI we have not been connected to the conduit for about 14-15 hours now, also when we get into a series of join failure we get into a 5 minute sleep cycle, so technically we shouldn’t have reached such as large back off time correct?

4/18/2017 12:55:25 PM: [TRACE] Checking if connected to the LORA Network.....

4/18/2017 12:55:25 PM: [TRACE] Not connected to the network.....

4/18/2017 12:55:25 PM: [TRACE] joining network....

4/18/2017 12:55:25 PM: [TRACE] Initiating join...

4/18/2017 12:55:25 PM: [TRACE] Join Network - Auto OTA

4/18/2017 12:55:25 PM: [TRACE] Join attempt #446

4/18/2017 12:55:25 PM: [DEBUG] Join Backoff: 71122 s

4/18/2017 12:55:25 PM: [ERROR] Join backoff

4/18/2017 12:55:25 PM: [ERROR] failed to join network -4:Join Error

4/18/2017 12:55:25 PM: [DEBUG] getNextTxMs: 71122000

4/18/2017 12:56:31 PM: [TRACE] Initiating join...

4/18/2017 12:56:31 PM: [TRACE] Join Network - Auto OTA

4/18/2017 12:56:31 PM: [TRACE] Join attempt #447

4/18/2017 12:56:31 PM: [DEBUG] Join Backoff: 71057 s

4/18/2017 12:56:31 PM: [ERROR] Join backoff

4/18/2017 12:56:31 PM: [ERROR] failed to join network -4:Join Error

4/18/2017 12:56:31 PM: [DEBUG] getNextTxMs: 71057000

4/18/2017 12:57:36 PM: [TRACE] Initiating join...

4/18/2017 12:57:36 PM: [TRACE] Join Network - Auto OTA

4/18/2017 12:57:36 PM: [TRACE] Join attempt #448

4/18/2017 12:57:36 PM: [DEBUG] Join Backoff: 70991 s

4/18/2017 12:57:36 PM: [ERROR] Join backoff

Thanks,
Ajay

[Ajay K]

Hi Jason,

The other thing we noticed that is the getNextTxMs returns a non-zero value right after a join fails, I thought for US915, this should always return a zero, until we encounter a join-back off? We got a 2000 ms value after the very first join failure. Is this expected?

Thanks,
Ajay.

[Ajay K]

Just another update, so we have either put the mdot to sleep for a period equal to the join back off or a larger interval as much as 5 minutes when we have over 12 contiguous join/ack failures.

Here is trace log of the mdot writing out to the debug o/p. We have been disconnected from the network for 40 minutes, we would get the getNextTxMs, either return 0 seconds, 1 second or 2 seconds, and we have ensured all the join back of times were adhered to, however all of a sudden we got a join back of time of 3276 seconds, which is massive. So I was hoping if we can get a better sense of the algorithm behind the getNextTxMs call as to how does it decide what the interval would be?

4/19/2017 1:11:50 PM: [ERROR] Failed to join network

4/19/2017 1:11:50 PM: [ERROR] failed to join network -4:Join Error, Join Attempts: 2

4/19/2017 1:11:50 PM: [DEBUG] getNextTxMs: 0

4/19/2017 1:11:51 PM: [TRACE] Initiating join...

4/19/2017 1:11:51 PM: [TRACE] Join Network - Auto OTA

4/19/2017 1:11:51 PM: [TRACE] Join attempt #96

4/19/2017 1:11:51 PM: [INFO] Send join request RxDelay: 1 Rx1Offset: 0 Rx2Freq: 923300000 Rx2Dr: 8

4/19/2017 1:11:51 PM: [TRACE] DevEUI:

4/19/2017 1:11:51 PM: [TRACE] AppEUI:

4/19/2017 1:11:51 PM: [TRACE] AppKey: 

4/19/2017 1:11:51 PM: [WARNING] Max time-on-air limit met for current join backoff period

4/19/2017 1:11:51 PM: [WARNING] JoinBackoff: 3276 seconds  Time On Air: 42368 / 36000

4/19/2017 1:11:51 PM: [TRACE] Sending 23 bytes

4/19/2017 1:11:51 PM: [TRACE] Number of available channels: 1

4/19/2017 1:11:51 PM: [DEBUG] Using channel 67 : 907800000

4/19/2017 1:11:51 PM: [INFO] Configure radio for TX

4/19/2017 1:11:51 PM: [DEBUG] Session pwr: 20 ant: 3 max: 26

4/19/2017 1:11:51 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22

4/19/2017 1:11:51 PM: [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0

4/19/2017 1:11:51 PM: [INFO] Configure radio for TX

4/19/2017 1:11:51 PM: [DEBUG] Session pwr: 20 ant: 3 max: 26

4/19/2017 1:11:51 PM: [DEBUG] Radio Power index: 20 output: 19 total: 22

4/19/2017 1:11:51 PM: [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0

4/19/2017 1:11:51 PM: [DEBUG] mDotEvent - TxDone

4/19/2017 1:11:51 PM: [TRACE] Event: OK

4/19/2017 1:11:51 PM: [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0

4/19/2017 1:11:51 PM: [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0

4/19/2017 1:11:52 PM: [TRACE] RX1 on freq: 925100000

4/19/2017 1:11:52 PM: [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1

4/19/2017 1:11:52 PM: [TRACE] Stats: Up: 155 Down: 48 DupTx: 0 CRC Errors: 2

4/19/2017 1:11:52 PM: [INFO] Rx Window 1

4/19/2017 1:11:52 PM: [TRACE] Event: RX_TIMEOUT

4/19/2017 1:11:52 PM: [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0

4/19/2017 1:11:52 PM: [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0

4/19/2017 1:11:53 PM: [TRACE] RX2 on freq: 925100000

4/19/2017 1:11:53 PM: [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1

4/19/2017 1:11:53 PM: [TRACE] Stats: Up: 155 Down: 48 DupTx: 0 CRC Errors: 2

4/19/2017 1:11:53 PM: [INFO] Rx Window 2

4/19/2017 1:11:53 PM: [TRACE] Event: RX_TIMEOUT

4/19/2017 1:11:53 PM: [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0

4/19/2017 1:11:53 PM: [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0

4/19/2017 1:11:53 PM: [ERROR] Failed to join network

4/19/2017 1:11:54 PM: [ERROR] failed to join network -4:Join Error, Join Attempts: 3

4/19/2017 1:11:54 PM: [DEBUG] getNextTxMs: 3274000

[Jason Reiss]

1 hour 1% duty-cycle
36/3600 seconds
The first hour gets 36000 ms of time on air. After which the device must wait until the hour has expired.

1-11 hours 0.1% duty-cycle
36/36000 seconds
The next ten hours also get 36000 ms of time on air. After which the device must wait until ten hours have expired.

11+ hours 0.01% duty-cycle
After which each 24 hour period can use 8700 ms of time on air.

The intermediate back-off (1-3 seconds) is a minimum designed with randomness in order stagger repeated attempts from multiple devices.
Only the total time on air per period is enforced to allow independent implementation flexibility.

You could enforce a Y minute back-off after X failed attempts if you want the retries to be more staggered.

Please let me know if you need further clarity.

[Ajay K]

Thanks Jason for taking the time to explain the Join Back off interval calculations. Although the gateway wouldn’t be down that long, for two times now because of a power outage we lost power on the gateway/conduit for over 24 hrs and hence we are hitting these scenarios where the mdots are attempting to join the network several times over the 24 hrs.

Any best practices on how best to join the network when you have a conduit outage such as the one I have described above other than just adhering to the Join Back off intervals?

Thanks,
Ajay

[Ajay K]

Also Jason, just seeing the duty cycle requirements mentioned in your earlier response, does it apply for the US frequency bands as well as I thought most duty cycle requirements were for the European frequency bands and also does the same duty cycle requirements apply when uplinking packets using the “Send” method?

FYI we are operating in the US915 frequency bands.

Thanks,
Ajay

[Author]

Posts