Good question. I don’t think we’ve actually ever given “official” recommendations on using different spreading factors during the Join procedure. @benolayinka is currently working on a “best practices” document that includes some of the content from my earlier posts here. Maybe we can also write something about this.
It’s always a tradeoff. For the “jitter” part, no, because that’s just randomization. For backoff you’ll need to set a maximum delay. For some devices it’s perfectly acceptable to have the retry delay slowly increase to a maximum of 24 hours ±20%. For other devices you may want them to retry more frequently.
Note: It is important to vary the DR. If you always choose a low DR, join requests will take much more time on air. Join requests will also have a much higher chance of interfering with other join attempts as well as with regular message traffic from other devices. Conversely, if you always use a high DR and the device trying to join the network is far away from the LoRaWAN gateway or sitting in an RF-obstructed or null region, the gateway may not receive a device’s join request. Given these realities, randomly vary the DR and frequency to defend against low signals while balancing against on-air time for join requests.
In LDL, OTAA rotates through all spreading factors from most efficient to least efficient. LDL will keep retrying until OTAA is successful or the application cancels the operation.
The JoinRequest transmit time is dithered by up to 30 seconds on each attempt. LDL will also gradually reduce the duty cycle so that it does not exceed 0.0001 over 24 hours as described in the specification.
Source of random used for dither depends on how LDL has been integrated. It can be pseudorandom (i.e. rand()) seeded by entropy gathered by the radio driver which is made available to the application on startup.
This can get “fun” when someone cheats building “less immediately needed” functionality during a port to a new platform. The system behaves oddly (maybe always starts with the same already used-up join nonce…) and on investigation it is found that:
I have a Dragino lt-22222-l device and I think it’s at the outer limits of the nearest gateway. I was under the impression - from this thread + also ABP vs OTAA | The Things Stack for LoRaWAN, that once it joined successfully, it should not need to reconnect because of bad reception or something.
While connecting works, it’s not very smooth; am often having this accept join request loop (pbly issues with downlink). Once connected, I always see new join requests within a few days at the most (no power outage or anything), which is pretty annoying. I switched to ABP which keeps working, but was wondering what could cause this and if there are better solutions?
The newer LoRaWAN standards include a kind of keep alive handshake which makes the node rejoin if it doesn’t get any response from the network for an extended period.
What is your uplink period and what spreading factor is being used? Is your device within the fair use limits of TTN? (Average of 30 seconds of airtime a day)
I put the uplink period slightly smaller than 2 hours (imagining there might be more other devices sending at very regular intervals), cause it uses SF12 (default is 10 minutes for this node ). Not sure if even half the messages get through, but I can live with that. Still, during such an accept join request loop, it did seem to send more frequently than my uplink period, so the keep alive seems counterproductive in case of a crappy connection.
Um, you appear to be saying that you get about 1 every 2 hours but you are trying once every 10 minutes. If this is the case, then you are breaching the Fair Use Policy by a wide margin and very likely the local legal duty cycle.
LoRa Alliance members (like wot TTI is) are required to restrict routine SF11 & SF12 for the very reasons you are discovering - it’s just far too marginal for regular use & takes up seconds of air time.
It looks like you need to review your gateway antenna, perhaps the device antenna or add another gateway.
No, sorry if I explained myself badly: default/factory settings of lt-22222-l is 10 minutes; I changed that to slightly smaller than 2 hours to not breach fair use policy. Thing is, if the node needs to rejoin with OTAA, the accept join request loop it often gets stuck in, displays messages more often than I’d expect based on the configured uplink period (but once connected it does match this configuration). But a reconnect can basically take from a few hours to a few days due to the shaky reception. If this keep alive cannot be disabled or configured it looks like I can better keep using ABP (or invest in my own gateway to have better reception)
The rejoin uplinks use different (non configurable) timing setting.
The keep-alive has been implemented to recover automatically when LoRaWAN Network Server and node are out of sync. That happened when moving from TTN V2 to V3. It allows nodes to get back in sync without the need to visit it for a physical reset. Afaik there is no way to disable it.
This as well needs to be handled by the application, right? I can’t find anything in the LoRaWAN 1.0.4 specification which says this is handled by a MAC-Command or so.
This is an old discussion. LoRaWAN stacks implementing 1.0.4 are very good at recovering connectivity using build in mechanisms. Only if you are sure there is no longer a connection with the LNS you should attempt a reset and yes, that is something the application should take care of as there won’t be anyway for the LNS to instruct the device to reset using a MAC command when there is no connection between the two.
I have devices that are running for years without having been reset, so be careful when to apply resets as it is seldomly required. Once a week is certainly overkill. (Rejoining requires several downlinks and downlinks do not scale well in LoRaWAN so avoid them whenever possible.)
). Not sure if even half the messages get through, but I can live with that. Still, during such an accept join request loop, it did seem to send more frequently than my uplink period, so the keep alive seems counterproductive in case of a crappy connection.