LoRaWAN Duty Cycle restriction
-
Can anybody please tell me how duty cycle restriction is enforced In LoRaWAN?
-
@prashanth It is in the release candidate version 1.20.0 rc12. You have to use the downloader 1.15.2 https://forum.pycom.io/topic/3425/new-beta-firmware-updater-1-15-2-b0 and/or download the tar file from https://forum.pycom.io/topic/2777/downgrading-firmware-advanced-users
-
@jcaron But even most recent firmware doesn't support IN865MHZ when using lopy4. It creates an error
-
@robert-hh Thank you.I will try to use it.
-
@pp Just as an additional note: on request of some board member I compiled packages for IN865. You'll find them here: https://github.com/robert-hh/Shared-Stuff
I have also submitted PR's for that.
-
@jcaron IN865-867 is subset of EU863-870 in terms of frequency band and i am using the channel frequency which lies in IN865-867 band.
I don't think there should be any restriction on channel selection if I am complying with the band and sufficient band gap between channels.If any such restriction can be there please let know.
-
@pp If you use that firmware with the EU region, then you will most probably face duty cycle restrictions.
Duty cycle limitations are set by authorities. It's one of the possible rules to make sure all users of the same shared, unlicensed band can co-exist (so that one does not send continuously with a huge transmit power, preventing anyone else from using the band). Other limitations can include maximum EIRP, requirement to do LBT-AFA, frequency hopping, spread-spectrum, etc.
In the EU, ETSI has set duty cycle restrictions (0.1%, 1% or 10%) on each of the sub-bands that are used by LoRa (unless you use LBT-AFA, which LoRaWAN does not use), along with maximum EIRP. This is a legal requirement that every device has to respect. ETSI (or the LoRaWAN spec) do not care at what level this is done, it just has to be done.
In your case, it's the LoRaWAN stack managing it. As you are using a nano-gateway, you are using a single channel, which means a single sub-band, and most probably you are on a 1% duty cycle sub-band. So you can't send more than 1% of the time.
Note that the network can't do anything to enforce duty cycle restrictions for uplinks (other than prevent you from using the network). Each device is responsible for respecting the duty cycle limitations.
If you want to go above that (which probably defeats the whole purpose of LoRaWAN anyway), you need to either switch to a newer firmware version which includes support for the IN865 band, or build a version of the firmware with duty cycle limitations removed. I would recommend the former.
Note that it is also quite possible that you are currently using a channel which is allowed by EU868 but not allowed in India. You will have to check you are using an allowed channel.
The change of region needs to be done on both the end-device and the gateway, of course, otherwise they probably won't be on the same channel for join requests.
-
@jcaron As IN band is not available in the given firmware,I am using EU band and I am using my own nano gateway,so I think I can relax the duty cycle constraints.
As you said duty cycle limitation is imposed by local authorities Can I say that duty cycle constraint is imposed by service provider of gateway not the the end device MAC?
One place in lorawan specification v1.1 it says "End-devices may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected:" under which one point is "The end-device respects the maximum transmit duty cycle relative to the sub-band used and local regulations." What does it mean? Does it mean that it should be taken care by application of end device not MAC?
I tried to upgrade with latest firmware but I was facing some issues with OTAA so I reverted it back.I will try to upgrade with newer firmware.
-
@pp That's a pretty old version of the firmware, you should probably upgrade to a more recent one.
Actually, as far as I can trace it back, the IN865 region wasn't even supported in that version. What region are you actually using? 863-870 is the EU band, not the IN band.
Duty cycle limitations are usually not imposed by the LoRaWAN spec, but by the local authorities. I don't see any such limitation in the 865 MHz band in India, but I'm not quite familiar with the local requirements so I may have missed it.
The current version of the region files for IN865 have duty cycle enabled, but with 100% duty cycle possible in theory.
You should upgrade to a more recent firmware and make sure you use the right band (and channels within that band).
-
@jcaron I am in India and I am using 863-870 MHz band. I am using firmware release-'1.15.0b2',lorawan-'1.0.0'.
lorawan specification version 1.0 and lorawan regional parameter v1.0 doesn't talk anything about Indian region but lorawan regional parameter version1.1 says "There is no dwell time or duty-cycle limitation for the INDIA 865-867 PHY layer."Hence I wanted to confirm about the duty cycle restriction in firmware.One more thing I want to clarify that long back i performed this experiment,in my notebook i had written DR0 but the calculations which I did,indicates it is for DR1. So if it was at DR1 Time on air for 51 bytes packet comes to around 1.56 seconds.so number of packets which can be transmitted in an hour according to 1% duty cycle=3600x1/100x1/1.56=23.07 and i was getting exception after 25 to 27 packets which seems bit reasonable.Anyway i will do this experiment again and let you people know.
-
@pp Which region are you in?
The rule for the EU region per ETSI (i.e. not necessarily what the firmware does) is that you should not exceed the given % of time on air for each sub-band over any one hour, IIRC. The percentage is 0.1, 1 or 10 % depending on the sub-band. Sub-bands are counted separately, but channels within the same sub-band are counted together.
At DR0, it's pretty easy to quickly reach the limit. Even the shortest possible frame takes about 1.5 seconds to send, so you can't send more than 24 frames per hour at DR0 on a given sub-band. For longer frames, that's even less.
Using channels in different sub-bands helps a little, but the number of really usable sub-bands is quite limited.
-
@robert-hh I was making sure that it doesn't violate time on air thing.
-
@jcaron Ok,Thanks.I will analyze further.
-
Don't have the time to check at the moment, but I think there is some code related to duty cycles in the stack, though I don't remember if it's currently enabled or not, and how it actually works.
IIRC at some point it did implement the old-style (LoRaWAN 1.0.0) duty cycle restrictions (e.g. don't send on the same sub-band for 99 times the last transmit time), not sure if that was updated to a more lenient "need to make sure we are under the limit over an hour".
But 27 packets of 51 bytes at DR0 will most certainly exceed the allowed limits in the EU band, so whether the stack enforces it or not, you should reduce your band usage.
-
@pp My gues is "some other issue". I did not analyze the LoRa stack in detail, but never came accross somthing related to duty cycle enforcement.
At DR0, a 51 byte packet takes about 3 seconds to be sent. (((51 + 13) * 1.25 + 8) * 8 / 250). If you send faster than that, then trouble is guaranteed.
-
@robert-hh We are running our own server. what I have observed is at DR0 and DR1 if my transmission frequency is very fast like 5 or 6 seconds after certain number of packets(in case of DR0 after 25 to 27 packets of 51 bytes size) lopy4 node gives exception error so when I reduced the transmission frequency i m not observing any exception error.
So my doubt is Is there anything related to Duty cycle is implemented in LoRaWAN MAC of End Node or is it because of some other issue i am facing the Problem?
If anything related to duty cycle is implemented in LoRaWAN MAC, I want to understand how it is calculated?
-
@pp If you run your own server: not at all. In theory someone could complain about the band being blocked, and then the responsible administration may act. So it's all about behaving well.
If you go through TTN or similar, you might see some restrictions as suppressed downlink messages. But even that is not enforced at the moment. Looking at the traffing I see at my full service LoRaWAN gateway, this is not a problem at all. Besides my own ones, I see like 5 messages/day in average.
