Hiya, hope you can help. I have 3 identical devices talking to my gateway and I’m experiencing problems whereby they are unable to send data to the gateway.
The console Data tab shows error messages “Activation not valid: no gateways available for downlink”
If I only have 1 device turned on it works fine, 2 is pretty good but 3 is poor. So I am assuming there is some kind of collision - they all send data every half hour at the same time, but the gateways are meant to handle thousands of these things right?
The gateway must adhere to the duty cycle for the frequency band. So if too many devices try to join at the same time (and are using a slow speed) the gateway does not have the airtime to send the join reply packet.
Two things to solve this:
make sure to use SF7 whenever possible
do not send at exactly the same time. Uplink should work, but downlink will be an issue.
BTW, Are you OTAA joining the network every half hour? That is not something you should do. A session should last days if not weeks/months not ‘minutes’.
…but not at exactly the same time. Like kersing also answered: nodes should adhere to a duty cycle. And they should also change frequency for every transmission, all to avoid collissions. Gateways can only decode a single message per frequency and spreading factor at a single time. (Same frequency and different SF should work just fine, and so should different frequencies.)
Although…
Uplinks on exactly the same time, frequency and SF will also fail, right? At best, a given gateway will then receive/decode one of the messages?
(Downlinks seem more troublesome indeed, as the backend needs to send the downlink to the gateway a bit before the gateway needs to transmit it, blocking that gateway for any further downlink until it has transmitted it? And maybe also as, for regular downlinks, TTN prefers RX2 with fixed settings? For OTAA, I think it uses RX1 for SF7-SF11, and RX2 for SF12.)
Timing is not the biggest issue, duty cycle is. For every join response at SF7 the gateway can not send another message for a couple of seconds. So if multiple nodes join just seconds apart all responses need to be transmitted seconds apart which given a number of nodes will make the gateway run out of airtime. The back-end keeps track of the duty cycle for gateways and will report it can’t find a gateway to transmit the downlink data. What the message means is: there is no gateway with free airtime available to transmit the downlink message.
Hi @kersing, it’s been a while!
Thanks for your help - yes my code is trying to re-join every half hour.
My device is mobile, and so can move within range of different gateways. I don’t think the session spans across gateways does it? Maybe there’s a way the code can check to see whether I need to join or not, and only join when it needs to.
Hi @arjanvanb,
Thanks for your advice. I don’t think it is practical for me to change SF or frequency for each device - I can’t control the devices that are in range of my gateway or when the devices will send data - anybody can use it.
Is the claim to support 3000 devices per gateway based on having total control over frequency, SF and time each device sends a message? If so it isn’t going to be a very useful claim for real life situations.
I need to figure out a way of staggering the data transmissions - all the devices use the same clock so the way my code currently works actively encourages collision!! Something to keep me busy this evening
Yes it does. LoRaWAN is not WiFi where a session is bound to a particular access point, in LoRaWAN the session is bound to the back-end, so once joined every TTN gateway will handle your traffic.
That claim is based on devices sending infrequently at a random frequency and a at random time. So LoRaWAN will not work for 3000 devices all sending on the hour (using a clock). It will work if those devices send at random times within an hour. (Each device can send exactly 1 hour after the last transmission as long as all devices do not send in the same timeslot)
A simple way to avoid this is to have your code generate a random number when first started (make sure to prime the pseudo random generator with something like the current time to avoid all of the node getting the same random number [and do not start all nodes in the same second if you use the current time]) and delay all transmissions on that node that number of seconds.
I guess meanwhile you see the design flaw in using a clock to determine when to send (and above all: when to join, as that needs downlinks that are very limited by the gateway’s duty cycle, like explained by kersing). So just for the sake of completeness:
As LoRaWAN nodes do not perform any activity detection before they start sending, nor do any collision detection while sending, LoRaWAN-compliant nodes mustadhere to duty cycles and hopping frequencies (emphasis mine):
1 Introduction
[…]
End-devices may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected:
The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust to interferences.
The end-device respects the maximum transmit duty cycle relative to the sub-band used and local regulations.
The end-device respects the maximum transmit duration (or dwell time) relative to the sub-band used and local regulations.
However, they should not change SF to avoid collisions, but only increase SF if they cannot reach any gateway otherwise.
Disputed; will try to find a source or peek into the LMiC-code later on…: Beware: while joining, a node will increase its SF for each retry, until it receives a Join Accept. Next, for subsequent uplinks, it will keep using the SF that resulted in a successful join, unless your software sets it explicitly, or until instructed otherwise by the network (Adaptive Data Rate), or until it somehow determines it can use a better SF (maybe using Link Check commands?). So, if your node cannot join due to collisions, it might eventually join using a high SF and then (while still hopping channels for each transmission) use that high SF for uplinks, which will quickly eat your maximum allowed air time.
