Hi all,
We have been testing our device with gateway and have got some of the other devices are sending join request continuously.
Due to this our network does not remain stable and not able to get all data from all our devices.
What is best practice to handle this kind of scenario in actual development?
Regards,
Lalit Shah
I have had a similar problem a few weeks ago, āMisbehaving Nodesā.
It seems not to be possible to blacklist other nodes. A gateway receives everything and if the CRC is valid the data will be forwarded to the server.
Are you implying the ethernet connection canāt handle the load? (Unlikely) Or does your gateway not receive all traffic from your nodes (to be expected due to collisions on the airwaves)?
Try to find the owner of the misbehaving nodes. There is no way (and it is not useful) to filter traffic with current gateway software.
Hi Kersing,
Thanks for suggestion.
We are able to receive data of node on gateway but not able to forward all our data on back-haul connectivity. As we are getting join request from other Node to fast.
Is there any mechanism we can not forward this traffic on back-haul connectivity?
Regards,
Lalit Shah
Some data would help:
What are you using for backhaul? Join requests is not a lot of data when forwarded from gateway to the backend, at least not for a tcp/ip connection. What data rates are you observing?
No there isnāt in the current standard software versions for gateways. What brand of gateway are you using?
Itās not really a software problem.
Rather itās a designed aspect of architecture & policy: a gateway canāt know what is or isnāt legitimate traffic.
Only the servers know that, in the sense of what nodes theyāve been given information sufficient to interact with.
A lot of people also forget that ātheirā TTN gateway is by definition for other peopleās traffic and not just their own.
That said, in very particular cases such as a flood of join requests it may be possible to implement rate-limiting in a way that would not penalize a legitimate but unknown node, but only reduce the harm caused by a misconfigured one.
That would be possible for gateways where the owner can replace the packet forwarder with something they build themselves (or have someone build for them). As we (still) donāt know what the brand of the gateway is it is hard to provide a definitive answer for this particular case.
It could also be done at a box co-located with the gateway and providing its connectivity, provided that SSL or similar terminates there and not in the packet forwarder.
I like the architectural cleanliness of having a packet forwarder worry about radios and something else deal with the Internet. It meant things like Semtechās sx1302 code being a distinct software project has little headache, since thatās confined to the packet forwarder. Similarly the forwarder need not track improvements in backend scheme.
That works for UDP forwarders but is quite a bit harder to implement for BasicStation.
Hi all,
Thanks for your support and guidance.
We are actually using BasicStation and trying to get it done with basic station.
Regards,
Lalit Shah
You come here to ask for advice but seem unwilling to provide any details asked for.
This feels like wasting other peopleās time.
Hi all,
Sorry but there ware multiple questions and i may have missed and donāt have any intension to waste time of anyone.
We are using 4G connectivity as backhaul.
We are sending data at every 15 minutes from our device.
We have been getting join request from multiple devices and not able to get exact details for those devices.
RSSI and all was good from our devices and other devices from which we are getting join request.
We are using IMST ic880a lora concentrator board and have our own custom gateway design on top of this.
BasicStation does not have filtering build in as far as I know, if you want to filter you will have to modify the software yourself to add that capability.
In my experience (multiple 4G connected gateways) the backhaul should provide plenty bandwidth for LoRaWAN including join requests. If you want all the traffic on a metered connection is another issue of course.
The best course of action would still be to try to locate the devices sending those join requests and get the owner(s) to solve the issue. Search the forum for hints on how to hunt for rogue devices, there have been several forum members that successfully solved their issues that way.
Dear Jac,
Thanks for your support, will try to look into how to hunt for rogue device and will try to get this shorted out.
Regards,
Lalit Shah
Hi All,
we are experiencing similar problems in our 4G gateways for a project we are currently starting in a prototypical phase. There seem to be around 10 devices which all try to join using our gateway in 15 seconds intervals. This seems to be ramping up our data consumption a lot (~75MB gateway/day)
My question is, could such a problem be avoided using a private lorawan network on the things stack instead of using the public ttn? Or would all these join requests still be sent to the network server where they would be rejected leading to an increased traffic like its happening now.
Thanks for the guidance.
LoRaWAN is a broadcast system - basically where all GWs in range of a transmitting node āhearā its messages and allocate resources to handling/demodulating and then send on to their associated Network Server, whether on TTN, TTS or any other service. Only once at the the NS will the packets be dropped if it is determined that they are alien to that network, or not intended for onward transmission to allow e.g. Roaminng or similar services provided by the likes of PacketBroker. Any attempts to block a device can end up rejecting legitimate devices and is not allowed - atleast on TTN. Note this has been discussed many times on the Forum over the years (search is your friend), and as pointed out any attempt to block at the GW on TTN would be a breach of the open & fair usage manifesto. Better option is to highlight and identify the misbehaving nodes and try and find owner/location and solve that way. Note the classic thought is to filter on e.g. Dev Addr, however, these are not unique and there is only a limited pool size for any given net ID - e.g. only the xx bits in a TTN 26 xx xx xx addrā¦it is usually the combination of DevAddr & Dev-EUI and or App-EUI/Join-EUI that allows the NS to identify if on net or foreign device. Sadly Dev-EUI and or Join-EUI may not be unique depending on device manufacturer/developer decisionsā¦
Suggest highlight general geography where you are (Germany?), contact local TTN community for assistance identifying if applicable, call out the details orf the misbehaving nodes. etc,ā¦have fun using directional RF bug hunting 
The device owners may not even be aware their devices are errantā¦
If those devices are yours only and all are trying to join at the same time, you can implement randomization into devices based on number of devices in particular area you are going to deploy, so all devices donāt send data at the same time.
TL;DR?
No.
Yes
Iāve just got some more SIMās to try out on my desk - they are all in the Gb range for pennies, perhaps the 75Mb/day is best solved by shrugging your shoulders or finding a WiFi or Ethernet connection?