Filter forwarded packets if on limited cellular plan

Only do that if deployed to an equally ‘private’ back end… see TTN Manifesto…

I understand your reactions, it touches the heart (or spirit) of TTN.
I fully underwrite the manifesto in case anyone doubted that.

I am not even suggesting that gateways having TTN as NS should be configured or allow that. But I do think that it is probable that this option will appear in gateways (if not already exists)

I try to understand how people handle the situation if you are in a remote area, having one (own) TTN connected gateway near a busy road, with 90% traffic from temp loggers in trucks, and your 4 times a day soil moisture is all your node does.

Do not get me wrong : net neutrality, fair and equal access is what makes TTN great, I am asking for the (theoretical) situation that you would be forced to put down your gateway because you cannot pay the cellular traffic.

I know this is TTN forum, I am just thinking loud. How would we know gateways presenting themselves as TTN are not filtering nodes ? One might interpret the meaning of “Their “Things Gateways” will give access to all “Things” in a net neutral manner, limited by the maximum available capacity alone” in a broader way.

Financial capacity may be considered a limiting capacity as well. If your 2G cap is 50MB/month, would that mean you can’t deploy your TTN over 2G?

Could “Device agnostic” also mean that you have a gateway policy “every node that would like to forward packets is welcome without limit, but should do that max 4 times a day” ?

I am not sure if it exists, but even rogue nodes flooding your gateway either intentionally or just wrongly configured might burn your data limit within a short time, leaving the gateway operator with the cost.

I think my question can be discussed. I am not in favor of limiting anything btw.

Thank you for your thoughts on this!

This is out of balance - if it’s really one 4 times a day, a Pay-as-you-go GSM SIM with enough SMS for a month is going to be around £5 in the UK, I’ve just bought 5 x SIM800L for £13, so the “gateway” comms is going to be £2.60. Using nRF24L01’s for local nodes or even LoRa to LoRa is a few pounds. Why buy a full LoRaWAN gateway with a GSM connection & pay for the data SIM?

If I was in a position where I had to deploy a gateway on GSM data, I can have 80Gb for £20 or unlimited data (rate limited when used 80Gb to a mere 384kbps) for £25. Obviously I’d start with a smaller data package and ramp up as required. But I’d probably only do this deployment on TTN if I could identify tangible community use in the area that would benefit.

I sort of get where you are coming from, but I think the scenario is so niche and, as I said, out of balance, that it’s debatable if it’s worth debating IMHO. Particularly as the very very short answer is if you want to setup a LoRaWAN gateway with GSM & whitelisting options, then rent a small virtual server and put ChirpStack on it and run a private instance.

1 Like

Thank you, makes sense…

Discuss away.

But do you think the TTN forum should provide instructions on how to make a free to use community service private, even if it were possible ?

Ok, I get your point. Let’s go on with more down to earth stuff than theoretical scenarios :wink:

Such traffic probably doesn’t exist; if it even did, it’s going to be fairly low intensity.

What you haven’t thought about is the degree to which the baseline housekeeping traffic that has to happen anyway to keep the backhaul link live is going to outweigh what you are concerned about.

1 Like

True @cslorabox, to clarify I was referring to a standalone solar powered gateway with cellular back-haul. You are completely right in a regular household scenario the amount of traffic would be negligible.

That is about 12MB a month (looking at the monthly data usage of one of my remote gateways which services only a single LoRaWAN device which uplinks once an hour,)
That gateway uses the Semtech UDP forwarder.

Chances are the amount of traffic picked up by your isolated device would be as well - especially with regard to “traffic from temp loggers in trucks”

In contrast, baseline housekeeping traffic with no nodes, is about the same data volume as that added by a node that transmits around every 45 seconds - 12 megabytes a month is 277 bytes/minute, which is actually a bit large for a UDP packet report.

If there were a role for filtering at the gateway, it would be a role for filtering out things that aren’t TTN at all. Unfortunately that’s not trivially possible with complete reliability, since while TTN would only hand out device addresses in a certain range, in theory a device with any address could be registered. Preferably that shouldn’t be one with a prefix owned by another network, but it could be.

Probably the place it would be sensible would be if you saw a lot of traffic from one particular network; especially a badly designed network.

Typically starting 26 xx IIRC and I always have to look up if the other is 25xx or 27xx, but then there are ‘Experimental’ nodes on 00 or 01, and TTI/TTN is a big advocate of PacketBroker with an increasing trend over time for mutual exchange of packets between, TTN, TTI, Private instances using same stack/back end stack and eventually other network operators…Filtering will break that arrangement, and for the amounts of data we are discussing should (IMHO) be avoided. I guess if there is a badly behaving node form another network that you cant track down and have corrected or shut down there ‘could’ be an argument to filter that if it is operating illegally, but… rare?

Multiple poll packets a minute (I think one every 10 seconds) and a report packet every 30 seconds so 277 bytes doesn’t seem unreasonable to me at all.

In principle TTN uses addresses starting with 26/27, however filtering on address must include a check that the particular packet is a data message as there will be other data at the address offsets in join request packets. Not forwarding join requests would certainly break the network…

BTW, when I see excessive traffic from nodes it usually is join traffic, not being able to filter that does make this really not worthwhile to me.

My point is that this an actual uplink report tends to be smaller than per-minute share of baseline housekeeping traffic

BTW, when I see excessive traffic from nodes it usually is join traffic, not being able to filter that does make this really not worthwhile to me.

One could contemplate some sort of “spam filter” that rate-limited joins from a particular EUI absent substantial improvement in signal strength or something. Given that many of these are misconfigurations, and the egregious cases can hammer away at rapid rates, that seems kind of fair.

Granted, refusing to report uplinks doesn’t get the noise off the air. But then reporting them probably won’t either, as they’re either misconfigured or not registered on TTN.

Caught up in this would be devices that illicitly re-use join nonces and try to walk into unused territory. But then those devices are defective. In reality one can’t build a compliant LoRaWAN device without storing the history of used values, and letting people use the network for storage by slowly walking the value until they hit an unused one isn’t really something that should be encouraged.

Of course within TTN, a lot of this would be better handled by network-side logic to generate nastygrams upon mis-use. Having an error output stream instead of silently dropping things could be a big improvement.

I wouldn’t mind not forwarding the thousands of SF12 messages my gateway receives daily just out of not wanting to support the unfair usage of airtime.

I assume this is the SAWater project (cooling area for hot citizens?!) called out by @TonySmith on the other thread? High quantity of SF12 Uplink Messages Have either you, Tony or perhaps @Maj approached them to highlight your concerns and perhaps get them to move to ADR or drop SF level to act more socially responsible (and legal?!) manner… a better option than just trying to filter…

1 Like

Not yet, as it isn’t a big issue at this stage with the amount of traffic we have here in Adelaide but as the year goes on if there isn’t a correction in these nodes and if others have the same approach I’m sure there will be congestion in our airtime.
Part of the problem I think is not enough gateways, if we had more gateways then SF12 would not be needed.
My comment earlier was a bit off the cuff and a very premature at this stage.

It sounds like they’re using SF12 out of laziness, not out of need.

Is it even using TTN?

Once badly coded nodes are in the field, they’re probably not going to change behavior.

Yes it is using TTN.

It was commissioned by Fleet Space on behalf of the local councils and SA Water. I am aware of the person (on Slack) who coded the 200-300 nodes.

I will ask why they are running on SF12 but very occasionally I see one running on SF10, so I suspect they may be running ADR. However my gateways reply quite a few times so I suspect the nodes are running in Confirmed mode.

1 Like

Thanks Tony, probably best if we continue this conversation back in High quantity of SF12 Uplink Messages if needed as not to hijack the thread.


Just imagining, since TTN NS monitors, it would be cool to have an indicator in the console to see if your node is complying. Console background red? Then you’re outside the FUP !