Duty cycle limitations are not latency. Latency is the delay between transmitting a packet and its arrival at its destination. In TTN this takes somewhere between 100ms to several seconds.
LoRaWAN is not a real-time communication technology in the sense that you can almost continuously transmit, e.g. like in wifi or cellular. It is meant to transmit short bursts of data at long intervals between bursts. If you need to transmit more data or in a more continuous way, you should look to other technologies.
Thanks for your reply @Epyon. I was looking at LoRaWan for industrial monitoring (As mentioned on Semtech webage, it is suitable for this use cases) but i was interested to calculate the communication latency of lorawan to find out suitable communication intervals. How can I calculate it if you have any idea?
Secondly, the latency you referred in your last comment is only from the end node to gateway?not to the LoRa communication server?
If you mean the delay between the emission of a LoRaWAN message by an end node and its reception by your application, then it’s generally < 5s. If you mean the average delay between the emission of downlink by your application and the reception by your end node, then it depends on how often you send uplinks in the first place. As a rule of thumb, you can’t expect to do much better than 15 minutes.
In a nutshell, there’s no “communication” in LoRaWAN like you would find on an IP network. There are messages, but no connection.
Latency and duty cycle are not really related anyway. However, some class A devices send uplink messages to poll for downlink data periodically, and by this polling exceeding the duty cycle or fair access policy. This need is removed when Class B and C become generally available, not only in TTN but also in end device stacks. Class B is going to be a bit challenging though, but definitely doable on GPS time synced gateways.
In any case, the fair access policy is not being enforced today, and exceptions will be made for R&D. I can imagine the following steps:
Formulate and communicate fair access policy: done
Make ADR generally available in all regions and to optimize capacity on the network level: in progress
Monitor to see how devices and applications are behaving with respect to the fair access policy: in progress
Give solution makers insight in how their devices and applications behave and provide documentation on how to use less capacity (= less power consumption too): in progress
Send warnings to application owners that are consistently exceeding the fair access policy for a larger number of devices, so this is where we make exceptions for R&D: todo
Use MAC commands to reduce uplink from the devices, e.g. tighten duty cycle levels, if applicable: todo
If the warnings and duty cycle don’t help, trigger QoS measures to partially drop uplink or downlink traffic: todo
So basically we don’t go from formulating the fair access policy to dropping traffic right away. We’re only at step 2 and 3 of the above.
@Gig If you mean the delay between the emission of a LoRaWAN message by an end node and its reception by your application, then it’s generally < 5s.
Yes, I exactly mean this but how is it possible to calculate this precisely? It may serve the two fold purpose.
1- It would be useful to determine the suitable monitoring interval in predictive maintainance
2- can be used to calculate the energy consumption of LoRaWAN
Thanks again
Both depend on the spreading factor (SF) you use. If you have good reception and are at SF7, you can transmit your message in tens of milliseconds to your gateway. If you have bad reception and are at SF12, it can take up to 1,2 seconds. At SF7 you will be able to send more messages because each message takes up less airtime. If you keep the messages short, you can also send more. See this thread for airtime calculation.
The transit time from the gateway to your application completely depends on the solution you choose. On TTN and with a gateway connected through wired Ethernet this will only take some tens of milliseconds (at current load levels). If the gateway uses a slow cellular connection this delay will of course add up. If suddenly tens of thousands of people start using TTN, it will probably slow down too.
Remember that the TTN service is ‘best effort’. In a commercial setting you will probably sign (and pay) SLA’s with commercial providers which will indicate the maximum latency between gateway and your application.
I agree with the wording of @Gig that LoRaWAN is not for real time communication but for (short) message sending. Like you would send an e-mail or a text message. Latency isn’t the factor determining the quality of the service here, as long as the message gets delivered in a timely fashion.
Adding to that: this is typically variable with ADR enabled, the recommended setting for static devices
So summarizing, on a high level:
Latency = Time On Air + Gateway to NS network latency + Deduplication Window + Routing Services processing time [1] + MQTT broker to Application network latency
[1] this is minimal when data stays in the same region, otherwise there’s of course the network latency between regions
Thanks very much @johan for the explanation. Can we fairly estimate this kind of delay?
Furthermore, It is trivial that duty cycle would impact the energy consumption in the uploaded image. But could you please explain, what is the relationship between used duty cycle in the LoRa calculator and Energy calculations in the right bottom of the screenshot?Formula to calculate this consumption?
I’m not familiar with that calculator and I can’t think of a reason other than that the device polls every x ms for data, within the set duty cycle, so the duty cycle would drive the polling interval and therefore energy consumption. But that’s just guessing.
There is no duty cycle in US915, but there is a so-called “dwell time”. If you keep individual transmissions under 400ms, there are no other legal restrictions.
TTN’s fair access policy still applies, but this is currently not enforced in any way.
@arjanvanb I didn’t found that info in TTNmapper FAQ, do you know which packet rate (nb of seconds between packets, or packets/min) is authorized in SF7 (BW125) in Europe when performing mapping (and only mapping of course)? As for R&D, I imagine it’s higher than what is defined in Fair Access Policy? Because it’s hard to map with 5 minutes or so between packets with a moving node…
For mapping and any R&D, any duty cycle regulations for one’s region would still apply as usual.
The Fair Access Policy is a daily maximum of 30 seconds. As even a zero byte application payload would be fine for mapping, you could send 647 packets in SF7, with a delay of 4.6 seconds† (assuming a 1% maximum duty cycle). So, you could be mapping for almost an hour without hitting the Fair Access Policy either. Even more, it’s not enforced yet.
† Same values for 1 and 2 bytes application payloads (plus the 13 bytes header)
Hello
When a ‘Link Check commands’ is used, the TTN send an Downlink with empty payload.
Is this downlink is count in restriction ( 10 downlink per day ) ?
Thank for response
All downlinks count, also downlinks sent in response to requests sent by the device. This includes ACKs to confirmed uplinks and responses to MAC requests such as LinkCheck for example.
In Brazil we use the AU915, which is quite similiar to the US915.
Most recent regulation stands that for bandwiths less than 250kHz the transmision should hop through at least 35 different frequencies and the mean dwell time should be under 400ms within a 14s interval.
For bandwiths greater or equlas to 250kHz it should hop through at least 17 different frequencies and the mean dwell time should be under 400ms within a 7s interval.
Is this the same restriction applied in the USA by FCC15? Or does this 14s (or 7s) window actually defines a duty cycle, also?
Anyway, this clearly limits the SF usage, prohibiting the usage of SF12/BW125 since the 1byte payload message would take about 600ms. Is this correct? @htdvisser did such a great job explaining the duty cycle here (https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html), I would like to have a clear picture about those other restrictions as well.
Hylke knows where to find the TTN documentation, he needs links to the official documentation as provided by the appropriate authority for a country.
You state the information for Russia is incorrect, it would help if you point to the correct information (preferably in English)
