Duty Cycle - Time on Air


(Lawrence Griffiths) #1

There doesn't seem to be much talk of the constrains of using ISM Band frequencies that LoRaWAN runs on. I'm no expert (those who are pls put me right) but wanted to get a conversation going for those new to ISM band coms.

In Europe I'm using a crude rule of thumb which is max of 30 seconds of transmission time in every hour to meet a duty cycle 1%.

// From LoRaWAN spec
Example: A device just transmitted a 0.5 s long frame on one default channel.
This channel is in a sub-band allowing 1% duty-cycle.
Therefore this whole sub-band (868 – 868.6) will be 30 unavailable for 49.5 s.
So in my simple world that is approximately 1 transmission every minuet.

For those who want to dive a little deeper you can use the LoRa calculator
http://www.semtech.com/apps/filedown/down.php?file=SX1272LoRaCalculatorSetup1%271.zip

Also those who want to explore Antenna range Link-Labs have neat tool.
http://www.link-labs.com/symphony-link/

Can we add an RF Category to forum please.


Does LoRa have constraints similar to Sigfox?
(Thomas Telkamp) #2

This is indeed something to consider carefully. Good thing is that there are multiple sub-bands, so you can switch between them to increase your air-time (testing this right now with the lmic implementation). There also is a sub-band with 10% duty-cycle.

Right now, different vendors use different frequency plans. We have some options, and choice to be made.

I'm putting together a wiki page on frequencies, bands, and channel plans, to collect all this information. Hope to have it up tomorrow. Feel free to comment.

And thanks for the links!


Does each channel in a band have its own duty cycle?
(Lawrence Griffiths) #3

@Thomas assume you are taking about?
Band g3 869.4 MHz 869.65 MHz 27 dBm 10 % or LBT
Which is single channel

It's worth noting MultiTech LoRaWAN mDots don't support band G3
They use Band g1 and currently don't allow band switching if using the AT command interface


(Nestor Ayuso) #4

There are MAC commands that server can send to nodes to change or create new channels.
These commands are intended to be sent after the join procedure although can be sent whenever.

Todays severs don't implement such procedure generally.


(Thomas Telkamp) #5

g1 is only 3 frequencies, is that all the MultiTech is listening on?

Do you have an overview of its default channel configuration?


(Lawrence Griffiths) #6

@Thomas I've been reading the LoRaWAN speck and it seems that an end node MUST support first three channels
EU 868.1, 868.3, and 868.5 MHz
EU 433.175, 433.375 and 433.575 MHz
China 779.5, 779.7 and 779.9 MHz.
NA US 902-928MHz is more complex. See below

EU868Mhz end-devices should be capable of operating in the 863 to 870 MHz frequency
band and should feature a channel data structure to store the parameters of at least 16
channels. A channel data structure corresponds to a frequency and a set of data rates
usable on this frequency.

The first three channels correspond to 868.1, 868.3, and 868.5 MHz / DR0 to DR5 and must
be implemented in every end-device. Those default channels cannot be modified through
the NewChannelReq command and guarantee a minimal common channel set between
end-devices and network gateways.


(Thomas Telkamp) #7

@iikaw Indeed, and those seem to be supported on every implementation I have seen so far.

I'm collecting everything related to bands, duty-cycles, frequencies, and channel plans on this wiki page: http://thethingsnetwork.org/wiki/LoRaWAN-Frequencies

Feel free to comment and contribute.


Why is RX_SLOT 1 not used?
(Joerg Wende) #8

Thank you for the collection!
I'm a bit curious about G3 - the German legislation states a bandwidth of 25kHz, but the LoRa specifikation talks about 125kHz.
Regards
Joerg


(Thomas Telkamp) #9

The ETSI recommendation, and I would guess the German as well, allow you to use the whole G3 band as a single channel (without bw limitation). That's essentially what we're doing. We are not subdividing the band.


(Joerg Wende) #10

Ok. Thanks for clarification.
With 10% duty-cycle ? That would give us more thruput than g0 and g1.
J.


(Thomas Telkamp) #11

Indeed, but with a higher chance of interference.

Also, a lot of other applications seem to use g3 as well due to the power allowance.


(Sridhar Naidu Chappa) #12

If i want to work with Lora in India,what are the frequencies i should operate and what are the duty cycle limitations..?


(Leon Schenk) #13

I have a question about the additional join frequencies.

They are set on frequency: 864.1 MHz (and more), which is supposed to be in g2.
However the band regulation parts say g2:
g2 868.7 – 869.2 MHz 0.1% or LBT+AFA, 25 mW
LoRaWAN specification also mentiones these 864 MHz frequencies with 0.1 % dc limitation.
Should I disable these frequencies in LMiC?

How is this band regulated? And do gateways listen on these frequencies?


(Thomas Telkamp) #14

The 864.x join frequencies are not used, and have been removed in the LoRaWAN 1.0.1 update. You can remove them from LMiC (both Matthijs and myself already did in our versions).

The 0.1% DC for joins is also based on the 1.0 specification, it is more restrictive the the band DC. This also has been relaxed in 1.0.1, you can use a 1% DC for joins in the first hour of joining. After that you need to back-off to 0.01% again.


#15

As LoraWAN specification clarifies channel hopping in order to stand with Time on Air restrictions, how is handled need of sending ACKs uplink packets by gateway? Time on Air of Gateway will be multiplicated by number of nodes?
It refers not only to ACKs, but to whole downlink...


(Arjan) #16

It would, if all nodes would always use confirmed uplinks. But nodes should not do that; you can’t send all messages as ‘confirmed uplink’:

All devices have to comply with these regulations, so that includes gateways. As a result, downlink capacity of the network is even smaller than uplink capacity. This means that you should use unconfirmed messages unless you really need confirmed messages and send as little downlink data messages as possible.


#18

Hi @Thomas

The wiki link does not seem to work anymore?


#19

Is it the plan that the wiki-page comes back up?

Is there any way to get the actual time on air after a package has been sent from the RN2483? Or is it only possible to calculate it?

I'm a bit on doubt about how the duty cycle limitation is enforced (on the RN2483). When trying to transmit too often I get the "no_free_ch". Is this the "legal limit" you can use (I know that this is not in compliance with the fair usage policy of TTN, this is just for testing) in the EU or do I still need to pay attention as to how often I transmit?

According to the calculator the time on air should be 61 ms, which should prohibit me from sending for the next 6 seconds. However the "no_free_ch" doesn't occur before I've transmitted 8 times (rapidly after each other). I've read in another thread, that it is because I can send on 8 channels and it is only when I'm sending on the first one again, that the duty cycle is violated. However all of the transmission is in the same sub-band as far as I understand (868-868.6), so what am I missing?


Does each channel in a band have its own duty cycle?
(Med Amin Peper) #20

hello mahe
i am facing the same issue here, i wonder if you have found any solutions to this problem and thanks.


(Osman) #21

Yes i am also wondering about this. I am able to send uplinks without any pause. And after some continuous uplinks i get this no free channel.