Positive RSSI values are not invalidated

[robshep]

trafficstars

Summary

A rogue gateway is able to supply positive RSSI values. (greather than zero) This means it is selected for downlink path over any other gateway.

Steps to Reproduce

1. Send positive RSSI values in LNS uplink traffic from a gateway.

Technically I don't know how to re-produce this in PF or BasicsStation, but I've seen this in TTN.

Current Result

The gateway with a positive RSSI is apparently selected for downlink path.

Expected Result

This RSSI should be invalidated.

Relevant Logs

{
          "gateway_ids": {
            "gateway_id": "eui-00800000a000bcba",
            "eui": "00800000A000BCBA"
          },
          "time": "2023-08-31T14:43:16.214Z",
          "timestamp": 1787715740,
          "fine_timestamp": "30580349",
          "encrypted_fine_timestamp": "Ks3cCzjF6bFDW99vXhwAfg==",
          "encrypted_fine_timestamp_key_id": "0",
          "rssi": 90,
          "signal_rssi": 74,
          "channel_rssi": 90,
          "snr": -15,
          "frequency_offset": "10971",
          "location": {
            "latitude": 53.3065977478146,
            "longitude": -4.69977875243799,
            "altitude": 10,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "CiIKIAoUZXVpLTAwODAwMDAwYTAwMGJjYmESCACAAACgALy6EJzBudQGGgwIhM7CpwYQ4bSZvwEg4MKl4YO3fCoLCITOwqcGEIDDhWY=",
          "channel_index": 3,
          "gps_time": "2023-08-31T14:43:16.214Z",
          "received_at": "2023-08-31T14:43:16.374141084Z"
        },

URL

No response

Deployment

The Things Stack Cloud

The Things Stack Version

TTN

Client Name and Version

No response

Other Information

TTN forum post here. https://www.thethingsnetwork.org/forum/t/troubleshoot-join-accept-not-being-received/64566

Proposed Fix

Invalid positive RSSI values

Contributing

• [X] I can help by doing more research.
• [ ] I can help by implementing a fix after the proposal above is approved.
• [ ] I can help by testing the fix before it's released.

Code of Conduct

• [X] I agree to follow TTN's Community Code of Conduct.

[robshep]

Maybe as simple as changing this invalidator function to be >=

https://github.com/TheThingsNetwork/lorawan-stack/blob/13bc4dcabb70ed7280e07e832a30aeeba99fc115/pkg/networkserver/downlink.go#L650C64-L650C64

[KrishnaIyer]

Thanks @robshep. Both the UDP protocol spec and the LBS spec don't restrict RSSI to negative values. In practice, I also have not seen valid positive RSSI values for gateways. What do you think @adriansmares?

[robshep]

The operator has sent me this, regarding the unit that is emitting these values.

[robshep]

Potentially an erroneous rssi_offset in the config - but that's just a guess for the time being.

[adriansmares]

So in general the range of the RSSI and SNR is indeed not well defined and it depends on the hardware and environmental factors. There are offsets and temperature coefficients which do indeed heavily affect the resulting RSSI. Also, since these are mainly radio parameters, the LoRaWAN specification is not really the right place to look for extra details.

A possible range which is used by the relay specification is [-142, -15] for RSSI and [-20, 11] for SNR. With that being said, this range has been chosen in order to fit into the binary encoding of the protocol (notice the 127 and 31 ranges), so it should not be used an authoritative margin.

If we look at our network data, we have the following results while looking at the 5% and 95% quartile of the RSSI and SNR:

 p95_rssi | p95_snr | p05_rssi | p05_snr 
----------+---------+----------+---------
      -45 |    13.2 |     -120 |   -10.8

The above are basically the boundaries for 90% of the uplinks in the network, and it includes both matched and unmatched traffic. If we add 5% more data:

 p975_rssi | p975_snr | p025_rssi | p025_snr 
-----------+----------+-----------+----------
       -37 |     13.8 |      -122 |    -14.2

I am inclined to say that a range like [-125, -35] for the RSSI and [-20, 15] for the SNR is probably safe for validation. We won't discard the downlink path, but rather de-prioritize it. cc @johanstokking for thoughts on this.

PS: I recommend updating the firmware on the gateway and moving to the LoRa Basics Station packet forwarder.

[johanstokking]

I think we can indeed validate (and remove) the LoRa RX metadata if the RSSI is outside of the pretty forgiving range [-142, -15] and SNR [-20, 15]. We can still process the uplink frame, but the metadata makes no sense and will cause problems. Downlink scheduling is one of those problems, but not the only thing. Statistics is another. Therefore, we should not make our downlink scheduling more complicated but just discard the RX metadata. This may lead to no RX metadata in an uplink frame.

For the time being, if this is a community connected gateway, we probably want to set the downlink path constraint to "prefer other". I'm not sure if we have Console support for that, CLI for sure.