4 posts were split to a new topic: Simulated confirmed downlinks no longer getting to the gateway
Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair Access Policy
Node receiving packets out of order and with packet loss when using client.send()
Also, this would only be true for SF7 (to be exact: 10 bytes of payload data allow at most 486 messages at SF7). But if ADR tells the node to use SF8, the number is already limited to half of that. For SF10 you'd be down to 80 messages per day, and you would still be pushing the limit all day then. Please consider the maximum to be an upper limit; if everyone would push the limit then a gateway can only support 1,000 nodes.
I'll never understand that "thousands of nodes" figures. You would need people to deploy their own nodes by the hundred, and given the low price of gateways it's unconceivable they wouldn't densify the network to improve the quality of service!
EDIT: I should reformulate: I understand the community network having limitations, because most users don't want to invest into the infrastructure. However, anyone deploying more than 10 nodes would most likely also deploy a gateway, therefore locally increasing the network capacity. If a gateway ever has to service a thousand nodes at once, then something has gone very wrong along the infrastructure chain.
LoRaWAN Limitations at 915Mhz (US915)
@arjanvanb Thank you for info. Now I got a more clear picture.
@Gig "1000 nodes" were used as an extreme case.
Please clear me if i get something wrong
what i understood is: there may be two types of duty cycle limits
1- Duty Cycle imposed by European Commission and that is the same throughout the EU
2-Under generic EU limitations, there is further a fair usage poilcy of 30 messages per node per day imposed by TTN.
What if i only follow the 1 but do not follow the 2nd in my own network?
If yes, can i say
The maximum number of packets per hour per node can be seen as 60*60/Time on Air + Time off
There are two types of duty cycle: (1) the one imposed by regulations and (2) the one imposed by LoRaWAN.
The Fair Access Policy is there to make sure that the community network is not abused by large deployments and applies to all of the community network, not just EU.
In your own private network you only have to be compliant with the (1) and (2), not with the fair access policy of TTN.
I am testing on 10 End Device and Each Device Send packet at 40 sec time interval. As per testing log lost of packets Droped, So is it practically possible (Drops) or some issue in code or hardware (its banch test senerio ) .
Thanks for the reply. could you please explain both of the duty cycles with an example. what would be max no. of packets per hour regarding both duty cycles to make it more clear.
Another question: Can we take Time on Air as a communication latency of lorawan?
Thanks in anticipation
Please read the relevant articles in the wiki.
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?
It depends on what you mean by latency.
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
So would running ttnmapper for a few weeks at higher than fair use rates be generally allowed as R&D for us to map the coverage of the gateways we are installing by car?
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  + MQTT broker to Application network latency
 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.
@arjanvanb Can you provide a similar detailed list of restrictions/specifications that TTN enforces on US915 networks ?
I ask because I presume some duty cycle related specifications would be different for US915.
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.