filter on receiving hotspots with the strongest RSSI

[pdvaneijk]

Currently when the uplink LoRaWAN frame from a device connected to the Helium Network is received in Console the hotspot that is recorded as the receiving hotspot is not necessarily the one with the strongest RSSI, presumably closest to the device. If you chose to pay for multiple packets received by additional hotspots you end up with what looks like a random collection of hotspots.

Given the fact that Helium has a known location for every hotspot one can easily solve for an approximate location of the device based on these gateway locations and the RSSI values associated with the particular uplink using Semtech's LoRa Cloud service. However, the current Helium Router/Console implementation prevents one from finding the location of a LoRaWAN device that does not offer additional geolocation capabilities like GPS/GNSS scan or WiFi scan.

Would it be possible to filter the list of hotspots that received a copy of the UL by RSSI ?

[jdgemm]

This request has similarities with this issue: https://github.com/helium/router/issues/456. The Coverage feature already provides average RSSI values of Hotspots transferring data. We are looking at extending the Coverage feature to allow users to choose their own "preferred Hotspots" for data transfer. Users could sort those Hotspots and prioritize device data from Hotspots with the strongest RSSI values.

[pdvaneijk]

Yes, a feature to pick your own preferred hotspots based on the strongest RSSI values would be great!

[jdgemm]

ok, thanks for the reqeust, going to close this as this is a duplicate with https://github.com/helium/router/issues/456

[Oliv4945]

Hi @jdgemm, I am not sure that #456 answers @pdvaneijk request. From what I understand of #456 you pick the hotspot names/ids that your prefer to use. In @pdvaneijk request you want to locate devices thanks to RSSI, therefore you will not know which hotspot will receive the data.

From what I understand it would be required to sort this map by RSSI before filtering down to the number of hotspots selected in the console

[RichL306]

ok, thanks for the reqeust, going to close this as this is a duplicate with #456

Guys, this is an entirely different request and I think that you are confusing two separate issues. In one request someone wants to force packets to be selected from known hotspots, this request is asking to purchase the best ones. Today, if you purchase, say 2 packets and the uplink was received by 6 hotspots, then the two you get sent will be any from those 6.

What we are asking for here is that all packets are sorted in RSSI rank order and the first 'N' are purchased. This means that if you are trying to locate a mobile device (in the same way as using WiFi hotspots) by the location of the hotspots, then naturally you will want those closest to the device. Whilst the strongest signal is not guaranteed to be closest hotspot, it is after all very simple to do, and way better than the random selection we see today.

@pdvaneijk , @jdgemm can we re-open this?

Thanks

[pdvaneijk]

Hopefully Dal can re-open this issue :)

[macpie]

In a normal LoraWan network this would be easy, the problematic on the Helium network is that packet are not directly given to Router by Hotspots but are instead offered first.

The offer does not include any RSSI information, even if it did the network is considered an un-trusted environment meaning that a Hotspot could lie about its RSSI value to make sure to get its packets picked up.

Note that I am open to any idea to get around this.

[Oliv4945]

Hi, I have no easy answer but I am lacking of knowledge in this area. Do you have any documentation on the buying mechanism? How the selection is done today?

Thanks

[macpie]

Hi, I have no easy answer but I am lacking of knowledge in this area. Do you have any documentation on the buying mechanism? How the selection is done today?

Thanks

Here is the offer definition for ref and the buying logic.

[firmwareguru]

I am observing very bizarre behavior with Console/Router and my LoRaWAN device, and my attempt to find a solution has led me here. The join message is reported through only 1 hotspot, and it is far away. Similarly, the uplink messages are very very weak (SF10 < -100 dBm) and reported by one hotspot from a random selection it seems, and almost always from a hotspot far far away. There are a dozen closer hotspots, including one in my own house that is not selected for reporting!

This is most bizarre because about a month ago I was working with another device, and everything worked as one would expect: the join message was received by five (5) hotspots according to Console, one of them my local gateway. The uplinks would be reported by one (1) hotspot - the one with the best RSSI as we would expect. Uplinks were SF7, now they are SF10.

So what has changed in the last couple of weeks? Was it the introduction of the roaming feature?

I enabled the Multiple Packet feature in console just to see if my gateway was actually working, and I found out that almost 60 hotspots were seeing my uplinks. And that the selection of the "best" hotspot is based on nothing more than the first one to report! See the screenshot below.

If the selection criteria is based on first to report, how does ADR work? ADR should allow the device to settle on a lower spreading factor like SF7 and lower TX power so that maybe 3-4 nearby hotspots see it. With the current implementation I don't see how this can work. And this is hugely important to managing device battery life - if the device has to run SF10 instead of SF7 its battery life could be reduced by a factor of 5 or more.

Lastly, not including RSSI in the hotspot offering packets is a non-starter. It seems like it was doing that not too long ago. RSSI must be available to anyone making decisions on what packets to select. If it is a matter of trust, the hotspots should be signing these offering packets if they aren't already, and you will need to use your witnessing system or start a staking/voting scheme for hotpots to establish trust and to root out malicious/unreliable ones. Users of these packets could vote for certain hotspots, and then only allow hotspots with certain vote thresholds to be part of the offer package. Anyways this is something that needs to figure out, fast, because right now the network, at least through Console, is broken.

[pdvaneijk]

As far as I know the ADR function is not implemented in console, for this they would need a way to keep track of device proximity to its nearest gateway based on RSSI and use this data to force each device to use the lowest possible (within Link-budget) spreading factor and thus conserve battery time since lower SFs requires shorter time on air. But this would of course require a mechanism by which Helium would always select the gateway with the strongest RSSI to both receive the ULs from the device in question and to transmit the downlinks to this device. There is a related issue about "default hotspots" published here: https://github.com/helium/router/issues/456

Someone correct me if I am wrong here, but I think all the ADR button (when enabled) does is that it send the CF List in a DL ADR MAC command without changing any of the TX UL power and UL SF settings on the end device in question. This was originally added as a quick and dirty fix for the missing CF List as part of the Join Accept if I recall correctly. At this point I am not sure what real benefit this ADR button adds right now ?

The below text that is listed under the ADR Enable/Disable Button is misleading. Instead of "When ADR is disabled the channel Mask" at the start of the second sentence, it should state "While the ADR function is still disabled on the Helium Network, the ADR Channel Mask...)"

"ADR allows devices to use an optimal data rate which reduces power consumption and airtime on the network based on RF conditions. When ADR is disabled the channel mask is still transmitted via ADR command, but power output and data rates are not impacted. Recommended: only use ADR for fixed or non-mobile devices to ensure reliable connectivity."

[firmwareguru]

I enabled ADR a couple of hours ago in the Console (under Profiles) for the device in question. I can say that it seems to work. The SF has now been brought down to 7, also the TX power was reduced (according to the MAC downlink). Now my hotspot can show higher up the list, sometimes at the top. I have an integration with Cayenne, and it is the hotspot at the top of the list whose UL packet gets forwarded on. But with ADR working the network situation is much improved. Ideally "Cool Graphite Snail" should feature at the top of the list sorted based on RSSI.

FWIW, it seems that right now hotspots with faster net connections or faster hardware can game the system by simply being first to grab the credit for transferring a packet.

[RichL306]

As we have observed in the bay area on your devices @pdvaneijk, some uplinks can be caught by several hundred hotspots. In London my own packets often hit between 100 and 200 hotspots. One of the most important reasons for ADR is to reduce the level of noise (collisions) on the spectrum. Thus leaving all devices to decide on data rate by themselves is not a long term scalable plan.

There is also a byproduct of a highly dense network with hundreds of duplicates of every message kicking around.... and that is the extra load created at every stage in the network. The more hostpots offering, the more the console needs to communicate, the more the delays build up, memory, bandwidth etc. and start to cause issues.

I agree with @firmwareguru - we definitely need to find a way to put rssi in the offer and somehow weed out those hotspots spoofing rssi through the proof of coverage algorithms.

RSSI is a fundamentally important parameter in managing a radio network (second only to SNR)

[Oliv4945]

Hi, I have no easy answer but I am lacking of knowledge in this area. Do you have any documentation on the buying mechanism? How the selection is done today? Thanks

Here is the offer definition for ref and the buying logic.

Thanks @macpie , I am not really efficient in Erlang, but could you please validate those assumptions?

• Packets are dropped if they are reported after configured RX2 here. If I understand it correctly it could be an issue by itself as the value is fixed to 2 sec and not taken from device's profile.
• Same comment is also valid for this comparison
• The packets are bought in the arriving order: if one packet only is bought it will be the one with the lowest latency/hold time, is it correct?
• From this comment, the ADR issue related to the "first arrived, first used for the ADR" seems to be well known by the dev team :)

Buying the packets from a gateway with low latency/hold time is currently useful to have a round time trip lower than 5 sec (Join) or RxDelay (uplink) until light hotspots are deployed, but after this deployment:

ADR If only one gateway is receiving the packets, and always the same one, ADR works as expected and the router controls TxPower/DR. But what Patrick and Rich are seeing is a gateway far away from the device with lower latency/hold time always bought by the router, as the signal quality is not good the router sets high TxPower/DR: this leads to unnecessary power consumption and reduce network capacity/increase collisions.

• Static devices: this will be mitigated with preferred hotspot selection but it needs manual actions by the device owner to select the gateways for each device, with regular checks to see if the network changed (preferred gateway removed or better gateways added). This does not scale :(
• Mobile devices: they should not use ADR, so it is not really an issue

RSSI Location We could assume that the 16th first packets to be selected will be evenly distributed around the device, but having the best RSSI would allow better location results. Another workaround is to buy all the packets and sort them in the AS but it can quickly be expensive in places like the Bay area where 300+ gateways receives the uplinks.

Potential solution Why do we have this "First to be reported, first bought" mechanism? That way the gateways with the lowest latency will always be selected and earn more than one which could be closer to the device, moreover network capacity and power consumption is not optimized and we loose some advantages of LoRaWAN.
Why not buying all the packets and distribute the reward evenly between the receiving gateways? This would avoid any gateway trying to fake the RSSI to cheat the system, would allow correct ADR control, and help RSSI location

[mfalkvidd]

Great work everyone. Imo, these discussions will lead Helium becoming an even better network.

I am not sure if Helium has every worked like this (it certainly doesn't work this way now), but this is how the buying mechanism was described to me by a Helium developer about 1.5 years ago:

1. When network receives the message from the first gateway that reports the message, a 500 ms timer is started.
2. The network continues receiving the message from other gateways
3. When the timer expires, an offer is sent to the router using the gateway that reported the highest RSSI.

This limits the delay, but gives all gateways with a reasonable latency a chance to participate. It does not prevent gateways from faking RSSI to become the winner.

If this doesn't help the discussion, feel free to disregard my comment :-)