High quantity of SF12 Uplink Messages

Let me start by noting that implementing the logic to adhere to TTN fair access policy at node level would be an excellent idea for TTN specific nodes. However care must be taken for it not to break LoRaWAN certification testing requirements. (During testing the stack does not observe legal airtime requirements either to speed up testing [which is done in an RF isolated environment])

Interesting that your experience differs vastly from the commercial nodes I encounter in my deployments. I’m mostly seeing nodes where one controller takes care of both the LoRaWAN stack and the application. Three years ago Microchip RN modules were the de facto standard, these days majority of the new nodes are based on one of the controllers with integrated radio module (not necessarily the same die).

Back of to stay within legal limits. Because the TTN fair access policy is not implemented in any of the commercial devices I know of. Being able to configure such limits would be a good enhancement at standard level in my opinion.
(For commercial LoRaWAN operators a limiting function would be good as well to stay within the plan purchased for the device.)

For any LoRaWAN network to work nodes should only deploy well behaved nodes. If someone starts a private network with misbehaving nodes using the same frequencies TTN uses (and there is not a lot of available space for other plans in large parts of the world) all TTN users suffer.

And that is where I strongly disagree. Most off the shelf products do not allow modification of the firmware without invalidating the LoRaWAN certification (and possibly breaking the stack) because just one processor is being used which drives both the application and the LoRaWAN stack. At least none of the 20+ different node types I handled in the last two years allow these modifications. Some do not even provide means to modify the firmware and the most restricted one not even the operational parameters.

1 Like

As near as I can tell, in arguing for manufacturer non-cooperation as a legitimate excuse to violate it, you are basically stating the opinion that the airtime policy is merely a “goal”, and not any sort of actual “policy” at all.

I believe that with a bit more consideration of the practical impact at scale, you’ll realize that’s not a technically viable position for a growing network - but you are welcome to your own opinions.

In terms of the LoRaWAN certification argument, if certification is allegedly the obstacle to achieving the autonomous backoff behavior needed to be fully compliant with TTN airtime “goals”, then people should probably give up on the idea of LoRaWAN certification as being a positive feature for TTN nodes, and instead focus only on legal certification as a radiator, while achieving node behavior that is actual constructive rather than destructive to the idea of a shared network.

Particularly, that would mean making sure that nodes autonomously behave appropriately in terms of both sharing the airwaves and consuming their own battery, so that they can behave appropriately in precisely the situations where they are receiving no feedback from the network.

First of all I never said devices are allowed to violate the policy. I just pointed out that generic devices from vendors do not implement the logic you demand to keep the airtime within the TTN policy. So the owner of the device is responsible to make sure it stays within policy.

Second, I know for sure me demanding the manufacturer change the firmware to implement this is not going to work. In a past case where a device implemented mandatory acknowledgement on uplink I had to get TTI involved to make the manufacturer see the error in their logic and wait 9 months for an updated firmware (and that was a vendor where I had good relations with their support department). It all comes down to volumes they can sell to you and my projects are not even close to the volume where they consider custom firmware (and the required new LoRaWAN certification).

I don’t state that devices are allowed transmit in excess of the TTN policy. I do state that a mechanism to take care of that in the node would be good, I merely state that most TTN users do not have the leverage to demand that feature.

I even state I think adding such a mechanism to the LoRaWAN standard would be a good idea.

Please read all of my message and not just the parts of it that trigger a knee jerk reaction. And consider how lucky you are if you are in position to demand those changes and have them implemented.

1 Like

If you are saying that it’s okay to rely on the success of downlinks to attempt to comply with the policy, then in reality, you are arguing that it’s okay not to comply.

We all know that downlinks won’t always be achievable - this whole subthread kicked off when someone pointed out that downlink failures meant they were sometimes out of compliance.

And in fact, downlinks are least likely to work, in exactly the situation of gateway change or failure where a node would have autonomously gone to a higher spreading factor and started burning up airtime and its own battery with too many long transmissions. Any viable node simply must backoff its rate in such a situation for its own purposes as well as politeness.

It’s really quite simple: because infrastructure-side intervention isn’t always possible, either you believe that a node must autonomously comply, or you believe that non-compliance is acceptable.

And consider how lucky you are if you are in position to demand those changes and have them implemented.

We refuse to be held hostage by vendors with faulty software; in practical terms we either avoid their products or replace their buggy software with our own maintainable software.

Which gets back to the ealier point: if “LoRaWAN certification” is being seen as an excuse to violate TTN policies, then “LoRaWAN certification” is a bug rather than feature for TTN.