The DC-limits don’t tell me how the things should work but how they shall (must?) work.
As an operator of gateways I am responsible that the devices fulfill the requirements of the telecommunication-law for SRDs. But I hope that the manufacturer of the gateway took the DC-limits into account.
Then you’ll want to write or at least audit enforcement code yourself.
That’s completely contradictory to your earlier statement. A gateway manufacturer is much less likely to know the regulatory regime in which a gateway is operating than a network server administrator. Gateways in LoRaWan are supposed to be simple translators between RF and IP, they don’t really have any “understanding” of what they are doing.
If you are concerned, then don’t “hope” - actually go and check.
I see.
It was an obvious fault to try to already break down my problem, instead of briefly outlining the concrete overall situation. I didn’t anticipate all the components.
Situation is, that I have to set up and schedule a class C multicast session for a significant amount of nodes in a network and thus also many nodes for each gateway. This needs some (2-3) downlinks to every included end-device in the init-phase, which may lead to crowded gateway-cells. I was told, that the gateways that are being used by the company, would drop packets if DC exceeds limit and so I’m trying to find, how my software can deal with that.
My conclusion so far: I don’t really have a choice but to rely on ACKs and to set a fixed number of attempts for each packet of the init-phase.
That’s really off topic for the TTN forum.
This needs some (2-3) downlinks to every included end-device in the init-phase
Needing more than one downlink per devices indicates your design needs some re-thinking
I was told, that the gateways that are being used by the company, would drop packets if DC exceeds limit and so I’m trying to find, how my software can deal with that.
If you’re going to write a custom network server, you need to start by really understanding what gateways do. Read the source code.
My conclusion so far: I don’t really have a choice but to rely on ACKs and to set a fixed number of attempts for each packet of the init-phase.
First model what’s allowed in your server, as part of chosing the best gateway for each transmission.
Then you might look at transmit acks coming back over the gateway backhaul protocol.
TTN back end takes care of DC limits, so even if the gateway manufacturer didn’t (and at least 90% won’t as the Semtech reference software doesn’t) you’re safe. It is one of the reasons TTN strongly advices not to connect a gateway to multiple backends.
Yeah, I figure that. So I will now leave it at that.
Thanks again all of you.