As Krishna Easwaran said in video Gateway Demo: LoRa Basics Station - Krishna Easwaran (Things Industries) & Anton Beitler (Semtech) - YouTube (at time 17.20) choosing relevant gateway depends on RSSI, SNR and other factors. Theorethically I agree, but in practice is different picture.
We have some nodes, covered by three gateways at least. Gateways are on different locations, so their RSSI&SNR are on different levels. Some nodes are really close to particular gateway. As far as I have noticed, closer nodes are rarely connecting to closest gateway. By the rule, the closest gateway has far the best RSSI&SNR.
The explanation, which I couldnât find is how gateway server choose which gateway which will process particular packet. In our case there are nodes on different areas which are connecting to gateways with weaker signals in nearly 30 % cases at least (in case of one gateway even in more than 80%).
If the node is too close to the GW and signal received by other GWâs then it can be that those are used rather than the nearest as it may not be handling correctly, without you realising. In addition GWâs also have a duty cycle/dwell time limit or other constratints depending on where in the world so if the GW has transmitted multiple times to other devices in range (Join Accepts, MAC commands, Downlink Messages driven by applications, confirmation messages ackâing confirmed uplinks etc.) then the NS will keep track of that and will choose another GW giving appropriate coverage rather than try and then fail due to TX constraints etc.
A node doesnât connect to a gateway. It connects to TTS. The gateway is just a receiver, listening to everything on its frequencies and if there is a valid LoRaWan-signal decodes the data-package and send it to TTS. TTS decides which gateway to use to send the âjoin acceptâ if the âjoin requestâ is received by several gateways.
But I donât know how this decision is made.
Nodes do not connect to a gateway. All gateways that receive the transmission will forward the data to TTN. If you look in the meta data of an uplink you can see which gateways received the data with which RSSI and SNR. You can check if the closer gateway is listed and with what values.
A closer gateway using a slow internet connection could be missing from the list. TTN collects all related uplink packets for a certain timeframe and ignores any that are received after that window expired (those uplinks are considered replay attacks).
Also the positioning of antennas and objects between the node and the gateway can cause transmissions not to be received or with a severely degraded signal resulting in a gateway further away being the best match for a downlink.
As far as I have noticed, closer nodes are rarely connecting to closest gateway.
I apologize, I should wrote : closer nodes are rarely connected âŚ
Thank You to all for answers.
I agree TTS decides which gateway to use to send the âjoin acceptâ if the âjoin requestâ is received by several gateways. I also agree the NS will keep track of that and will choose another GW giving appropriate coverage rather than try and then fail due to TX constraints etc. It also makes sense if gateway is choosen due to faster connection between GW and NS. But is it rational (in terms of SF, battery life) to choose gateways with much weaker level of signal or worse SNR, as you can see from the picture? There is GW Frankovo naselje, fourth from the top, with excellent RSSI/SNR/LAN link (even not too strong or to close), but for 9 packets has been choosen only once. I believe source code could uncover âhowâ but my knowledge is not good enough to do this. Thatâs why Iâm asking on same way as Krishna explained.
We are located in a city area. Most of the time there are at least two or three gateways listed in the messages. The console only reports the RSSI of the first gateway, but we can see all gateways in the message data. The order of the gatways is not fixed, so there are sometimes strange jumps in the console message if the gateways change order. Sometimes also the strongest gateway, which is just a few meter away, is not listed at all.
Variability in the Internet connectivity/backhaul times for the various GWâs?
Also if messages outside a given NS message receive window arrive slowly (I .e. if too late) will be consider a replay attack by the NS and messages will be droppedâŚthat can often explain some GW messages being dropped - even if physically the closest they may be âfar awayâ as measured by the transit time to the NS.
If itâs not listed, itâs not heard the uplink or not heard it in time to contribute to the meta data.
The live data console isnât something anyone should use for analysis - itâs for debugging & a quick take on whatâs going on. You need several days worth of gateway meta data to get a good picture of whatâs going on - truck deliveries, commuter bio-mass, rain, sleet, snow, local use of microwave ovens, lift motors, all can vary signal strength on a minute by minute basis.
As others have mentioned, an unlisted gateway is one that did not report in the packet, or did so with too much delay to be included in the de-duplication.
If the node is as close to the gateway as you describe, the receiver may have been so overloaded that the message was distorted and not received correctly at that gateway. Edge conditions can go either way - sometimes they work, sometimes they donât. Generally you do not want to have any nodes that close to a gateway, as they can blank out more distant transmissions that theoretically should be distinct in terms of frequency or spreading factor, too.
Also note that unless youâre talking about a downlink, thereâs no real concept of âchoosingâ a gateway. Since the payload reported by all should be identical, it doesnât really matter. And in terms of downlinks, those are supposed to be quite rare.
@kersing Yes, Iâve checked. As you can see from the picture there was 5 GWs in particular moment, but packet was processed by the one of gateways with weak signal (GW0, GW3, GW4). For example (RSSI/SNR): GW0 -125/-6,25; GW1 -104/6; GW2 -81/11; GW3 -129/-9,25; GW4 -132/-12.
So, in particular moment were two gateways with better signal (RSSI as well as SNR), but algorithm didnât choose those gateways. Neither after 10 minutes for next uplink. Does algorithm choosing something between weakest and strongest?
As @descartes pointed out we should avoid conclusions from console. In our case we are monitoring 5 gateways on wider area for some months under different conditions. Behaviour is the same all the time.
What do you mean by the packet was processed by? A gateway does not process a packet. It simply forwards it to the back-end.
The only time a gateway needs to be choosen is for a downlink. Are you talking about downlink to a node?
Because for uplinks all gateways that receive the uplink will forward it to TTN and no processing is done on a gateway. TTN processes the data. Gateways are dumb media convertors that receive RF data and when it matches LoRaWAN packet format forward it to a back-end over an IP connection or when a back-end provides data over an IP connection the gateway will transmit it (RF) at the specified time.
I´m just talking about gateways seen in the message, I´m aware that sometimes the gateway might be too close and the receiver is oversaturated. But then the gateway will not be listed at all.
Anyway, I would be corious to to know what happens, if messages are received differently. But I assume, the server will just pick one message based on some algorithm (rssi or whatever) without checking (Possibly not necessary at all).
Pick one message for what? For uplinks all data packets are the same. Only the meta data is different. So any packet can be used to deliver to the application. And all meta data for packets received within 200ms will be collated and added to the data delivered to the application. Thatâs why you can get multiple gateways in the array.
I agree. I should used âpacket was received and forwarded by the one of gateways with weak signal.â
Iâm speaking about uplink.
On https://www.thethingsnetwork.org/docs/gateways/ is stated: All gateways within reach of a device will receive the deviceâs messages and forward them to The Things Network. (uplink) The network will deduplicate the messages and select the best gateway to forward any messages queued for downlink. (downlink? Deduplication is probably related to uplink?)
As long as I understand, packets from nodes, forwarded by gateways should be deduplicated somewhere in the TTN back-end. In this process best gateway is selected (I suppose in terms of RSSI, SNR primarily). Or am I wrong?
No the message to be processed and forwarded is basically the 1st to arrive at the NS where it is âcleanâ i.e. it gets through the associated GW having passed all MIC & CRC checks etcâŚits a digital payload and so it doesnt matter if it arrived from a GW seeing RSSI at -60dbm, -61dbm, -70dbm, or -115dbmâŚthe message is the message! Anything arriving at the NS too late (measured from time 1st message is seen) isnt de-dupâed it is simply dropped as it is assumed to be a replay attack! Only one GW is chosen by the NS to send a dowlink back to the node - and it may not be the 1st seen at the time of prior uplinkâŚ
This is a very densely packed sentence - the key word that make it hard to read is and.
The flow would be something like NS gets OK packet, within the window it just drops duplicate packets but logs the gateway signal strength for the meta data.
If there is a downlink scheduled, it chooses the best gateway, for the algorithm that defines best.
It would be better phrased thus:
All gateways within reach of a device will receive the deviceâs messages and forward them to The Things Network
The network will deduplicate the messages.
If there are any downlink messages queued, the network will select the best gateway to forward the next message.
Yes, you are wrongly interpreting the documentation. The selection for the best gateway is for downlink only. As I mentioned all uplinks received at the backend within 200ms will processed and used for deduplication at which time all relevant metadata (gateway information, RSSI, SNR etc) will be combined and after that the entire set of information will be delivered to the application. There is no best gateway for uplinks, all gateways that received the message without errors (CRC and message integrity check) are equally good.
Only for downlinks a best gateway will be chosen from the list of gateways that received the uplink and to determine that gateway RSSI, SNR and available airtime are used.
