Maybe this paper can help you to understand the Duty Cycle:
1 Like
Great, many thanks, Wolfgang.
The authors seem to conclude similiar things:
The duty cycle does not have any restric-tions how the transmissions should be spread out in time.It makes no distinction if transmission times are evenlyspaced out or if the transmission time is used up at thebeginning of the observation period and the rest of theinterval waited out. The only thing that must be respectedis the maximum duty cycle ratio itself. As such, devicesare allowed to transmit using bursty traffic, e.g., transmit-ting 36 s and then waiting for 3564 s for a duty cycle of1%.
I think I got a picture of how to implement it. Thanks all and have a nice evening!
Points arising:
-
Duty Cycle is a device problem, not a gateway or network server problem - they process what they receive - the only thing that a network server can do is ask to adjust the data rate, it can’t stop a device from transmitting.
-
The academics love to write papers.
-
Your 20 uplinks of 51 bytes in short order needs a total rethink - unless you are writing an academic paper - if so, I rest my case on point 2, as no one in reality would do this.
-
This forum is for LoRaWAN on TTN discussions only. Chirpstack is off topic. But as a general discussion it’s OK if we aren’t dragged in to implementation details specific to a non-TTN setup.
1 Like
My understanding has always been that, for regulations of this type, the EU introduces regulations that then require member states to introduce matching regulations for their own countries.
In the case of the UK, IR-2030 which refers extensivly to EU standards, is in itself enforced by regulations to the Wireless Telegraphy Act. So IR-2030 is in effect a UK regulation.
Absolutely, but they don’t get much of a choice, if the EU comes up with a regulation, they are meant to implement it ‘as-is’ in their national legislation.
I believe this was a key discussion point in some paperwork exercise that we’ve had foisted on us in the UK recently.
The 20 uplinks of that short cadence were merely an “extreme example” to clarify what edge cases I see. And the CS was the background information, why I am bothering with that thoughts, but I considered the question itself not vendor-specific.
And as I understood it, both ends of the air-channel would have to respect DC limits, devices and gateways. I learned, that the RAK gateways don’t deal with DC, while others do and drop/deny packets. Is that against your experience?
A gateway has to follow the DC-limits too. It has to fulfill the same requirements as a node (SRD).
I realize, that I have so far completely disregarded the fact that the network server nearly has no real choice to “clerverly schedule” or postpone a downlink, because the downlink is dependent on the uplink and at most it may choose between Rx1 and Rx2.
So… well then. what happens, if there are downlinks for “too much” nodes on a single gateway? The gateway must discard some downlinks for DC limits and the NS/AS won’t notice unless it were confirmed downlinks?
Persons reading the thread will assume the limits being discussed are those that apply to TTN and in the legal sense only they do.
However, most often the legal limits are not the limiting factor for TTN but the fair useage limit is, clarity is needed.
Oh, I totally missed that, I’m sorry. Makes sense, now that I’m reading it.
My idea was just to ask people with “real experience” and for that I considered TTN as a perfect fit. I didn’t intend to stir things up.
Agreed. But the Fair Use Limits are recommandations, the DC-limits are given by law. If the gateway of a user exceeds the DC-limits, the user (operator) of the gateway (and not TTN) might have problems with the authorities.
But my last question remains:
Is it your experience too, that (some) gateways just drop downlinks, if they would otherwise violate DC restrictions? And if they do, would the network server ever know (if not for missing ACK)?
That often falls into the crack between how things should work, vs how they are presently implemented.
It’s often considered easiest for the network server to track gateway transmit duty cycle. As long as the gateway only belongs to one network server, and the network server gets it right, that works.
Things like packet broker which theoretically should allow a gateway to function as part of multiple networks move the requirement to track airtime to the gateway. They also mean that there really needs to be a path to tell the network server that a gateway will not transmit, either because it is out of airtime, or because it is already going to be transmitting at that time under the orders of a different network server, so that the network server could route that transmission through another in range but slightly more distant gateway that might have availability. It turns out that at present this is unimplemented - there’s a thread about it around here somewhere.
1 Like
This was the bit that raised my eyebrows - plus the sudden reference to Chirpstack.
No problems with an academic discussion, mostly we do real world discussions, it was/is unclear if where on the spectrum your first few posts lay but the 20 uplinks at an inappropriate SF had both eyebrows up.
There are only a few code bases for packet forwarders so you could look in to them. If you are developing some actual real world software, I’d concentrate on other things than reinventing the gateway wheel with downlink DC as your design should do it’s utmost not to and if it does, assume it wasn’t received.
Always worth setting the scene when starting a discussion.
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.
1 Like
Yeah, I figure that. So I will now leave it at that.
Thanks again all of you.