Link between registered devices and gateways (Extended)

With reference same topic (Link between registered devices and gateways), I got answers that we cannot configure which sensor should talk to which lora gateway. As Mr.BoRRoZ told that “all LoRaWAN gateways within range of the node will receive and forward the data to the TTN backend.”
Suppose a site has 10 Nodes installed. Out of 10 nodes, we have installed 3 Nodes and one lora gateway. In this case, we dont want data from the nodes which we have not installed and our lora gateway should only talk to our nodes (3 Nodes). How can we achieve this?

For example:

Sensor 1 (Installed by us) ----> Gateway 1 (Installed by us) ----> TTN
Sensor 2 (Installed by us) ----> <Talks to Gateway 1>
Sensor 3 (Installed by another party) ----> Gateway 2 (Installed by another party) ----> TTN
Sensor 4 (Installed by another party) ----> <Talks to Gateway 2>

In above example, Gateway 1 and 2 are both lora gateway. And we don’t want to receive data from Sensor 3 and 4 and we want send RPC commands to only Sensor 1 and 2.

Whether this is possible?

To help answer your question, can you first describe why you don’t want to receive data from the nodes installed by other people. Is it a security problem, or is it you don’t want your internet connection to carry other people’s traffic, or some other reason? I am assuming you may not appreciate the benefits you will gain from using a shared network and probably think there are risks which don’t exist. Once we understand your concern I think we can demonstrate the benefits of a shared system and address your concerns.

2 Likes

short answer , No this is not possible on the public TTN network.

and to quote Tony Smith ’ Is it a security problem, or is it you don’t want your internet connection to carry other people’s traffic ?

We don’t want to receive data from the nodes that are installed by another party to avoid unnecessary internet bandwidth consumption and also for security purposes. When we receive data from another devices which we don’t want to process them in TTN to reject it later. So unwanted data comes up to TTN which consumes internet bandwidth. We don’t want that. Also another party devices data may causes our system crash or something like that.

We are considering both aspects here. Internet bandwidth is priority for us.

If you use the TTN what is a public service, and you wan’t to transport your own traffic to the public TTN router, you all so accept that you transport data from other’s to the TTN router.

Or you change to your own router behind your gate way’s and dont use the public from TTN. So do it by your own.

But how many bandwith you think you transport, I have done last month a test with a LoRaWan (TTN) gateway connected to a satellite gateway. and it cost me only a 10 to 15Mb/day as traffic from the gateway to the TTN router. and I pushed in that test every 30/60 seconds a mesage to the TTN router from several node’s

so what is it: I f you use a public service like TTN you must also do someting back to it (expand the TTN over the globe) . It’s a way off thinking and we must expanding the TTN all over the world.

but if you can’t effort these few Mb extra from other’s: yea what should we say about that. :wink: :laughing:

Regards

Johan

2 Likes

Your application in TTN Console won’t receive those messages. TTN will forward those to the application to which the device is registered, or drop a message altogether if it cannot route it.

No.

As for bandwidth, see What is the maximum data output of a LoRaWAN gateway?, especially the remarks about the bandwidth needed for status messages.

V3 Stack may have such a filter to save bandwidth, but at present it is not.
Since you are asking how to achieve the behaviour you want, for this specific application you could stay outside TTN and outside LoRaWAN specification (LoRa <>LoRaWAN). You may modify a packet forwarder to add a filter selecting your own nodes, and send them to your own installation of a network server, which in turn could be even too much if you have to serve only your nodes, and in a specific site. So you may just send them to your application without infrastructure in the middle, if needed. Check the WAZIUP project for an IoT framework outside this more open world.
In any case, you cannot control who is using the frequencies.

1 Like

The non-encrypted part of an uplink reveals a device’s DevAddr, but that is not unique.

So, filtering needs the gateway to know the secret NwkSKey for all whitelisted devices, to be able to validate the MIC to uniquely identify the device. (In LoRaWAN 1.0.x it would even need to know, or brute force, the frame counter’s 16 most significant bits, which are not in the message either. I don’t know for 1.1.) For OTAA, the NwkSKey changes for each join. (OTAA Join Requests could probably be filtered using the non-encrypted AppEUI.)

Yes, TTN does a lot of work for us! :slight_smile:

2 Likes

I agree. I was only suggesting some shortcut with unavoidable issues to be able to filter, but it is not something I would do. Likely even private networks on TTI are discarding packets only at server level. With V3 this could be different (apart from community considerations, it is reasonable that a GPRS based gateway tries to limit traffic).

2 Likes

If the public TTN does not provide the filtering you are asking about then maybe you need to run your own Lora Server and complete back end. Even if you do this your private gateway will still hear and forward packets from the other people’s nodes. So therefore this is not a TTN issue but a feature of the LoraWan design.

In the 915MHz bands where there are many channels (64 in Australia for example), the solution would be to run a private LoraWan system on channels not used by TTN. However the 868MHz system works different and you need 3 common channels so you can’t get the separation you are looking for. The conclusion here, the fundamentals of LoraWan change slighty from one country to another. What could be made to work in one country may not be available in another.

My recommendation would be to learn more about the encryption used in LoraWan, particularly look at the end-to-end encryption being used. This will satisfy you that packets from your node which may be transported by other people’s gateways are secure, other people can’t see your data. I would also look at radio propagation and how it can change in time and therefore get to understand the benefit you will receive by having other gateways in addition to your own. You will find the reliability of your service will increase with other gateways in the vicinity. I would also measure the data volumes and not assume they will be excessive.

2 Likes

Thank you for your replies.

So, TTN will not process the device’s data that are not registered in application. That’s good but data from the devices comes up to the lora gateway and gateway to TTN. Right?
What we want to do is filter out the unnecessary data at Gateway level itself. So Lora gateway will not send any data to TTN. So we want Lora gateway to decide what packets should be sent to Network server. So that internet bandwidth between Gateway and TTN will be reduced.

I think you guys are understanding my point.

Regards,
Bhimashankar

Thank you all for the replies.

I have to discuss this status with my team and will come back to you asap.