LoRaWAN Duty Cycle restriction
-
@robert-hh I was making sure that it doesn't violate time on air thing.
-
@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.
-
@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 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 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 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 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 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. -
@robert-hh Thank you.I will try to use it.
-
@jcaron But even most recent firmware doesn't support IN865MHZ when using lopy4. It creates an error
-
@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
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login