Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible RF collisions of gateway downlinks in RXC window and Class C #517

Open
MarekNovakACRIOS opened this issue Jan 5, 2021 · 1 comment

Comments

@MarekNovakACRIOS
Copy link

  • [ x ] I have searched the issues of this repository and believe that this is not a duplicate.

Summary

When managing an installation of several hundreds of end-nodes acting as street light controllers with 3 gateways on a relatively small area (1.5x1.5km), I found out, by sniffing the spectrum with and SDR, that there are collisions between transmissions of the gateways. I implemented LBT on the end-node side and I plan to enable LBT on the gateways, however, there is one thing, which could help me a lot as well or anybody using Class C and a mid-intensive traffic:

  • When planning the transmission, the mutual geographic location of the gateways should be taken in consideration - if there are 2 downlink frames (for RXC window, not RX2 or RX1 !) to be planned and transmitted on 2 gateways, which are very close (this could be configurable as distance in meters/km), one should be transmitted first and the second after the first, otherwise there is a collision on the air / in the band.

What is the use-case?

  • class C end nodes
  • Street Light Controllers - ~300-400 nodes on 1.5x1.5km area, 3 gateways
  • EU868 band

Implementation description

  • if the location of gateways is available, and if a new gateways is inserted, a matrix of distances should be re-calculated
  • when a downlink (for class C using RXC window / e.g. 869.525MHz for EU868 band) is planned, the matrix should be checked and if the frame to be queued is to be sent to a gateway, which is too close "in time and space", then the transmission / queueing should be posponed.

Can you implement this by yourself and make a pull request?

  • I am more in the Firmware side and have some contribution to https://github.com/Lora-net/LoRaMac-node project, but theretically yes
  • I have however little experience with Go, more with JS/Python/C... But I can definitely make a review of associated pull/merge request!
@sp193
Copy link

sp193 commented Feb 12, 2021

If you have control over the network server: are you already using the highest-possible datarate for RX2? By using a higher datarate, you can reduce the chances of collisions, since the air time for each packet will decrease.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants