How can I automatically check if an OTAA connection is still upright?
Should I trigger a new join process once a day to restore a possibly disconnected connection from the TTN server?
Or what is the best way to restore a lost connection to TTN server?
Hi @ledi007, I use commercial sensors from a number of manufacturers. A lot of them seem to use variations on a similar strategy. They all use OTAA. Most of the uplinks do not request an ACK but periodically they send an uplink requesting an ACK. If they do not get an ACK then they also send the next routine uplink with a request for an ACK. If there is still no ACK then they raise the SF. If there is still no ACK then they attempt to re-join.
It should also be noted that there is no concept of connection that can be maintained or lost. Packets are sent and can be received or not, without a stable connection.
If the node is moving, then maybe some packets can be lost. The technique mentioned by @cultsdotelecomatgmai is used to adjust SF when the node thinks packets are lost, of course only sometimes because uplinks cannot be too much. Re-joining is not a good idea because, in principle, you have to join just one time and then save your parameters.
Ok, but what can i do, when ttn server fails?
How do I know in this case that I need to reconnect with join otaa?
I would not prepare for a relatively rare, catastrophic event, in which TTN loses your keys. More likely you will do some mistake on node side. Remember, there is no connection: only a way to associate your node to your application.
This is a good, yet perhaps now old, read on more or less your same issue:
For nodes placed in remote locations with difficult access this “rare” case is a case to be taken into absolute consideration and a periodic rejoin, in my opinion, is advisable to save yourself a trip.
Ok!
I want to build up 100 or more nodes outside and all PCBs are shed. The lifetime of a node is calculated with > 5 years before the battery must be replaced. But within this time it is not possible to make a restart of the MCU if a connection to TTN is lost. Therefore it must be robust. And if the node does not need a new join process after the first join is done successfully, this will be great.
Use the advice @cultsdotelecomatgmai provided. Make sure the node can rejoin, but don’t rejoin too often as each join uses a random nonce and after a number of joins new attempts will fail due to nonces not being unique (which is required). The nonce is 16 bit so each node will only be able to join 65536 times, however conflicting nonces will be generated much sooner. (LoRaWAN 1.1 solves this issue allowing all 65536 nonces to be used but is not available for the rn2483 modules and the TTN community network does not support it.)
Thank you for information!
I think a good way to do that is to count the number of failed transfers in order in the MCU software. A 9-byte value is sent once per hour. And if the consecutive transfer fails after the 10th attempt, then a new join otaa should be executed.
Just make sure you do not exceed 10 downlinks including acknowledgements a day. Keep in mind a gateway is not receiving anything when it is transmitting so downlinks (includes join accepts and acks) don’t scale.
You have to use RN2483 commande mac get status, and check bit 4 : Join status (‘0’ – network not joined, ‘1’ – network joined)
look at
RN2483 LoRa® Technology Module Command Reference User’s Guide for more details
Best regards
that’s a good hint, thank you. But I mean it is bit 0.
Bit 4 is automatic reply status.
be carefull, join status bit mapping is differente beetween versions , if before 1.0.4, join status bit is 1 for 1.0.4 or later it’s bit 4
Since also Jac is here (and I trust him 
), let me check if it’s me missing something.
I agree that in general a strategy for rejoining is needed (in particular for nodes with 5y expected life). However, it seems to me that thinking at network server failure is looking at the least important factor.
@cultsdotelecomatgmai advice works well first of all for the most likely events (failed or moved gateway, a truck in front of the node that shields signals, etc), while network server failing could be considered one of the least likely. It does not only need that the server is temporarily switched off, but also that it lost all keys, without backup. If it just shuts down gracefully and then is restarted, there is no real need for rejoin (@kersing: am I missing something on this? it’s not a TCP connection). You could do it, but guidelines ask not to do it too often, and I would not use it as a solution for other issues.
This technique does not tell you that a rejoin is needed. 99.9% of times it tells you there is something wrong in the communication chain (your node and gateways being the first places to look for). So it’s not that a new join is needed: you know you need to do something. First thing to try is to increase SF, if you are not yet at SF12. If it failed 10 times, there is a high probability that a new join will fail too, because of something in the middle.
This without considering how you know that 10 attempts failed. If you mean that all packets are confirmed, then one per hour is more than the maximum allowed by fair use policy.
it is useful to know if a joining attempt succeeds, but then it will stay as is even if the network server is switched off. So it is not a way to know the network server crashed.
… and be careful because this bit isn’t so reliable. It’s not clear how the RN2483 estabilish if a join is lost and how update conseguently this bit. In my case I use a combination of this bit with a confirmed packet every X time and a join every Y time. The supposition is that RN2483 uses a nack on confirmed packet to clear or not this bit… but it’s only a supposition. Any one know more?
Dear ledi007
I am not sure whether you got your information and whether my input will be sound or not. Though, I add my two cents.
I think I asked a similar question as yours 2 months ago. I experienced interruption of the sending of payloads from my arduino through LoRa using the TTN protocol and I was wondering how to overcome these interruptions through being able to check whether the connection was still OK.
I finally used the following command:
ttn_response_t toto = ttn.sendBytes(payload, sizeof(payload));
It seems to both send the payload and put the feedback from the gateway into the toto variable, with values being 1 when the transmission is successful, -10 when there is a problem, -1 when the payload could not be sent, and maybe other values in other situations.
Then I added to my script a test on the toto value to restart the join procedure when the value of toto is different from 1. And it works finely.
Best regards.
PB
Normally there is no feedback from the gateway, unless you send confirmed packets, which are limited to maximum 10/day because they involve an uplink. Likely the response tells you whether the packet has been sent or not by the radio chip, which in turn likely depends on your (ab)use of the duty cycle.
If join process was successful, how can i get the device address (e.g. 26012C98) from TTN?
Now my plan is to do the following steps with the RN2483 node after power up:
And here i want to save the unique device address from TTN in RN2483 EEPROM with mac set devaddr 26012C98 - but how can i receive it from TTN.
If this is done and the device address is stored normally i never have to do a join OTTA process, right?
But nevertheless i want to check the statusbit number 4 once a day and if it is 0, i start a new join process.
What do you think about this procedure? Is it a good way or not?
It’s been said before: devices don’t “connect” to a network. They simply transmit, and hope one or more gateways receive their packets and forward those to the operator (TTN) at which you registered that device.
I think that getting the join status bit from the RN2483 will tell you if it has ever received a DevAddr and the secret session keys in an OTAA Join Accept, and still knows those. (Those details are persisted between reboots using mac save.) If this status would also change if the device somehow knows its uplinks are no longer being processed, then I’d expect the RN2483 to already have initiated a new join itself? Or have a setting for that? This would invalidate the old secrets.
So, I’d expect that querying that status bit is of no use to you (after you once joined successfully).
Using ADR or using a confirmed uplink every now and then (say, every few days) might enable the RN2483 to figure out that the network no longer responds. For ADR this would take much longer than one day, if the device transmits once per hour. That could make it decrease the SF, or maybe increase its transmission power if the network ever told it to decrease that, and after a lot of tries decide its uplinks are no longer being processed. You’d have to get information from Microchip’s documentation to see if that indeed would get it to a point where it decides to re-join by itself (or only change that status bit, which I doubt).
To extend on what has already been written about the need to re-join, I feel there’s only 3 reasons why a re-join would ever help:
When the frame counters overflow; I think it’s documented that for this the RN2483 will re-join automatically.
To change to a different operator. This is not limited to a network stopping its operations, but is something you might also want if the current network is still operational; see How can an operational node be triggered to join a different network?
If the network (TTN) lost its keys in some disaster. For that, a TTI developer once wrote:
Still, I feel you should backup those details yourself too.
If the network does not receive/process a device’s uplinks for other reasons (like: poor coverage) then re-joining will not help, as that will fail too.
It’s already received in the OTAA Join Accept. But the DevAddr will change for every new OTAA join. So, there’s no point in setting it when you’re going to do a new OTAA join? Also, the DevAddr does not suffice to restore a session: you also need the secret NwkSKey and AppSKey, which I think the RN2483 keeps a secret from the application code. Anyway, mac save will save all those details, including much more state, such as the network channel settings, the device’s frame counters, and its ADR states.
Many thanks for this information!
In this case i will check the status bit once and if join process was successfully i will never check it again.