Duty cycle regulations in Europe

Hello all,

I have just been digging into the LoRaWAN specs and I have a quick question about the duty cycle regulations. Ignoring the TTN Fair Access Policy for now, and focusing on the 863-870 ISM band in Europe:

In order to reduce interference, the amount of time LoRa devices are allowed to transmit is limited by ETSI to a percentage of the time in a day. In order to accommodate ~1000 nodes per gateway TTN limits nodes to 30 seconds per day.

In page 34 of the LoRaWAN specs the channel frequencies for the 868-870MHz ISM band are discussed :

The per subband duty cycle regulations are described, as well as the timeOffSubband regulation to prevent bursty traffic. The implication here is that duty cycle limitations for bands are counted seperately (“During the unavailable time of a given sub-band, the device may still be able to transmit on another sub-band”).

In the ETSI compliance datasheet for the SX1272 modem, the applicable subband for wideband modulation are described, on page 3: http://www.semtech.com/forum/images/datasheet/etsi-compliance-sx1272-lora-modem.pdf

There are several different subbands listed there, each with different spectrum access allocations.

My questions are:

  1. In this post (Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair Access Policy) explaining TTN limits, they mention 8 frequencies. What are these 8 frequencies?

  2. And, is the 1% duty cycle limitation for LoRaWAN across the whole 863-870MHz band, or is the duty cycle counted per subband e.g. could I transmit in the 868-868.6MHz band (g1) for 36 seconds in a hour, AND also transmit for 36 seconds in the 869.7-870MHz (g4) band that same hour? I realise I could not do this on TTN, and it would reduce the number of nodes that could be supported per gateway - but theoretically if I had a private network, could this be done without breaking ETSI regulations?


  1. Those 8 frequencies are the channels of our frequency plan for Europe. We use 868.1, 868.3, 868.5, 867.1, 867.3, 867.5, 867.7, 867.9 (which are in the g1 and g band).
  2. It’s indeed per sub-band, so you could do this in a private network.

However, if you feel you need to push the limits like this, you are probably better off looking at other technologies than LoRaWAN.



That’s very clear, thank you. I’m not looking to push the limits, but more to see what the limits are, if you understand me.

So if I understand correctly, the channels are set by the network operator, and those channels can be located in any of the 5 subbands mentioned in that semtech document above?

So for example in TTN, I could send a packet in a channel in the g1 band, and then if I wanted to transmit again before the timeOffSubband has expired, I could transmit in a channel in the g band. Then if I wanted to transmit again, I would have to wait for a timeOffSubband to expire. And if there was no TTN Fair Access Policy, I would be able to transmit for 1% of the time on each subband, so 36+36 = 72 seconds per hour?


Isn’t it 72 seconds per hour?

1 Like

Oops yeah you’re right - 1% of an hour is 36 seconds, so 72 seconds per hour. I’ll edit above.

In a lab environment this would be possible, yes. But if you do this in a real environment, you’ll probably make some enemies.

That makes sense!

There seems to be a lot of different new technologies being introduced that use the sub GHz ISM bands, especially 868, like Sigfox, LoRa, Weightless-P, Dash7, 802.11ah, Zigbee, etc. Is there any sort of regulation beyond the duty cycle limits and LBT that organises access to this band? Or do we just have to rely on a sort of gentlemanly agreement not to push the limits of the band?

Also, I’ve read that to set up a LoRaWAN network as a proper operator, you need to be issued a NetID by the LoRa Alliance. Do the Alliance do this to try police the multiple deployment of LoRa networks in one area? Like, if there were a number of LoRaWAN networks running simultaneously in one city, they would interfere with each other right?

As far as I know it’s just the existing regulations, the limitations in the protocol specifications, and the fair access policies that are implemented by “operators” of those networks. Luckily, LoRa is relatively resistant to interference of other protocols and other LoRa signals (see https://youtu.be/T3dGLqZrjIQ), but that obviously doesn’t mean that everybody should just transmit as much as he can, because eventually you’ll have so many collisions that you can’t decode your data anymore.

NetIDs are used in number of places:

  • They are part of the encryption keys (see section 6.2.5 of the LoRaWAN spec v1.0.2)
  • They are in Class B Beacon frames (The Things Network doesn’t support this)
  • They determine the first 7 bits of device addresses (section 6.1.1 of the spec)

Because of the last point, operators that have overlapping service areas can filter out traffic that is meant for a different network. This however doesn’t have anything to do with physical interference.

Just for clarification, is it correct that these are the different sub-bands?

  • 433.05-434.79 MHz 10% DC
  • 863-867 MHz 0.1% DC
  • 868-868.6 MHz 1% DC
  • 868.7-869.2 MHz 0.1% DC
  • 869.4-869.65 MHz 10% DC
  • 869.7-870 MHz 1% DC

Or are there more/less sub-bands in the 863-870 band where we can use LoRa?


That looks about right, but check https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html for more details

1 Like