Automatic RejoinRequest Frequency on a LoPy4 using OTAA

[mnovella]

Greetings, everybody.

Recently, I managed to successfully implement several LoPy4's and receive telemetry on my LoRa Server. I am using OTAA and so far have been able to join without problems.

Moving on, and reading the Forum and the LoRa WAN specification, I wondered what would happen if a device remained operating a long time, long enough for the FrameCount to reach its limit (which I understand is 2^16).

I then found on the Specification that a device on OTAA mode periodically sends RejoinRequests to the Server, as to attempt to obtain new keys/address and reset the FrameCount properly. This fact would help mitigate the above mentioned scenario of a device "running out" of FrameCount numbers to send.

Reading a bit further on the Specifications, it seems that the specific RejoinRequests that is sent is either Type 0 or Type 1.

Given these things, I was wondering if and how frequent these RejoinRequests are sent by the LoPy4? If I understand correctly, this is up to Pycom to determine and implement on their devices, but I have not found such information on the Docs. Also, could it be possible to configure this RejoinRequest frequency? Or is this something that has to be done manually, by user code?

If there is any other info I should provide I'll gladly do so. Thanks in advance :)

[Eric73]

@mnovella Hello

Thus, we can say that currently the LoPy4 does not support RejoinRequest natively, and that for it to happen the LoRa Module would have to be v1.1 compliant. Is this correct?

LoPy AND LoraWAN operator have to be conform to 1.1 specification to use it.

If yes, then given it's not natively supported, the responsibility for rejoining, etc. would fall on the application programmer (that is, me, or the code my LoPy has), just like you said that you start a join procedure after X time of not getting a downlink. Am I right?

Yes, that's i do, after two week if no downlink as been recevied the device do a new OTA join request

The 1.1 specs say that: "Once activated a device MAY periodically transmit a Rejoin-request message on top of its normal applicative traffic"

It's very important when reading ISO/RFC/ETSI/official specification to be veray careful to the use of 'MUST',"MAY" and 'SHOULD" and there's indeed meaning. The low-level stack MUST support processing RejoinRequest but it's not mandatory that the application use it or is allowed to use it.

That "MAY" part was the one that made me dubious if it was supported by the device or not... so I guess that even if/when Pycom supports LoraWAN 1.1 it will be up to Pycom to decide if/when to do the RejoinRequest if I'm not mistaken...

I don't know what pycom will do when they will working to 1.1 port, but for me it's a "No" if i have had to vote, sending a new RejoinRequest is IMHO and application job and not a low-level stack/driver job.

However, RejoinRequest is not send by a device, it's send by the network. When you do roaming (even in same country) you cant be in a specific area where some frequence channel is unusable (jammed), the network send to the device a RejoinRequest, the device perfom a new joinrequest and in the answer it receive a new channel list used in the area (frequency plan). If your device is static you don't have to think about this.

My device perform new joinrequest as it's a moved device and can be for a long time out-of-network and when it come back is framecounter is far from when it leave the network and we don't receive anymore it's frame if we don't do a new joinrequest.

[mnovella]

Hello @Eric73 thanks for taking the time to reply :) I think I get you better now.

Indeed, it seems that RejoinRequest was added on v1.1.

It also seems judging by the LoRa Module docs, the LoPy4 supports v.1.0.2

Thus, we can say that currently the LoPy4 does not support RejoinRequest natively, and that for it to happen the LoRa Module would have to be v1.1 compliant. Is this correct?

If yes, then given it's not natively supported, the responsibility for rejoining, etc. would fall on the application programmer (that is, me, or the code my LoPy has), just like you said that you start a join procedure after X time of not getting a downlink. Am I right?

I am nearly sure that 1.1 specification allow OTA device to send new joinrequest but it's perhaps not mandatory (i can't be sure i have only pass lorawan specification test for our 1.0.2 device and i havent read specification for a while)

The 1.1 specs say that: "Once activated a device MAY periodically transmit a Rejoin-request message on top of its normal applicative traffic"

That "MAY" part was the one that made me dubious if it was supported by the device or not... so I guess that even if/when Pycom supports LoraWAN 1.1 it will be up to Pycom to decide if/when to do the RejoinRequest if I'm not mistaken...

[Eric73]

Hi, in fact it's mainly depend of your lorawan network operator.

For exemple, in France both national operator follow lorawan 1.0.2 specification and RejoinRequest was added in lorawan 1.1 (if i remenber correctly).

I have a lot of exchange with the one we use for our product and there's answer about this is "it's application dependant".

So after some time without receive any downlink from our backend, our device consider is out of network and restart a join procedure.(please note that we use downlink only because our operator doesn't allow Ack on confirmed uplink ).

I am nearly sure that 1.1 specification allow OTA device to send new joinrequest but it's perhaps not mandatory (i can't be sure i have only pass lorawan specification test for our 1.0.2 device and i havent read specification for a while)