The Police.
There is plenty of information in the documentation about duty cycle and fair use policy, which requests that you do not use acknowledgements as a default as you are limited to 10 downlinks a day. And sending at a very high frequency is not good either, check out the air time calculator web link above.
Thanks Nick McCloud, where do i access this documentation? My ttn account is free. I didn’t know about this msg limitation. I will need to transmit tens of thousands of messages per day. With confirmation. I will need to find another solution. Maybe create my own NS.
Thanks
(1) Sorry but that is not a LoRa or LoRaWAN use case…. Don’t even attempt it
Absolutely….
See (1)!
Use the airtime calculator….even with zero payload and just using FPort value to indicate some signal/condition au915 is max 647msg/day at fastest SF7…. As stated NOT LoRaWAN use case….
https://avbentem.github.io/airtime-calculator/ttn/au915/0
Jeff-UK, In my case, I use a gateway, in the radio part. My device connects to this gateway directly, so in this case there is no data usage limitation on the radio. This limit only happens when I send the data from the gateway through The Things Network to my application. I need TTN to validate my lorawan keys.
If I could create my own NS I wouldn’t need any third party to transfer my data. Then there would be no msg quantity limitation.
Yes you do have limitations, read Nick post and look up your local RF authorities limitations on ISM (915) usage.
The FUP is to do with the load you are putting on the RF and TTN servers, so every time you verify your keys you are using there server.
I don’t think the authorities will agree with you.
And even if you use your own LNS, the gateway(s) will not be able to transmit that many confirmations.
Maybe if you explain what you are trying to achieve, other than heavy fines or even a jail sentence, we can advise you better.
Yes there is. You share the frequencies with others. Monopolizing the frequencies will not be popular with other users of them.
In that case, even if you escape the TTN FUP you are still constrained wrt messages to 776 zero byte/hr…. See above link for details….not 000’s! Start adding payload and count quickly falls….and that with poorest range on SF7. Also if acking messages remember when gw tx’s an ACK it goes deaf to any other uplinks! Effectively creating a DoS for yourself, you can quickly find if the ack important and node missing one does a retry you cascade into message storm and near total message fail……to say nothing of impact to scarce shared spectrum and other users per Jac et al…… it comes down to (2)!!!
Not sure I understand - are you saying your gw is effectively a node ie no LoRaWAN radio connection between sensor and gw? Just hard wired? The Gw I then just an internet router and can talk directly to your own back end (over IP) and no LNS need be involved!
It would be very helpful to the members of this forum, who are volunteers trying to help people, if you describe, in some detail, what your project actually is, how you currently have the devices arranged, and what changes you want to make that seem to involve TTN.
"
And please provide the details on this also, why exactly do you need ‘tens of thousands’ of messages a day ? How many devices are there, how much data do they send and how often, why exactly is confirmation required ?
@lafourcade. Reading a bit of this thread, I think you are better off learning a bit more on LoRaWAN and LoRa in general. That should help answer most of the questions yourself.
You can use the following videos to learn about the basics of LoRaWAN.
The radio concepts that you are referring to Data Rate, Spreading Factor etc are explained by Thomas in the following awesome video.
TL;DR: Governments in each region have dedicated regulations committees to define how much data can be sent and how often on each frequency used. LoRaWAN specifications are then created to fit into those regional regulations. Creating a private NS won’t help since you are sharing radio frequencies with other devices in your region.
Thanks everyone for the messages. Jeff, Communication is wireless, using the AU915 frequency. I need to certify my device with the local agency, Anatel. At this point I will have to adapt to local determinations. Lorawan is a new technology and will also evolve. I’ll bet on it. Initially, I believe I can stay, initially, with a rate of 200 msgs per day, per device. There would be 100 confirmed uploads and 100 downloads. Every message I send is sensitive and needs confirmation.
I really appreciate your help. I’m trying to understand how to use technology. And how to use TTN for that. My product is telemetry. Today I use a cell phone chip to send my messages, but many customers don’t have good cell phone coverage. Then we thought of the radio. There are customers who have more than 300 devices in the same physical location. Each device today sends about 140 msg per day with status reports. From what I understand, we will have to rethink this number to adapt to local conditions.
I say this amount because there are situations where I need to bootloader and update the firmware of a device. In this case it would be more than 100,000 bytes to send a file over the radio. But I might rethink how to do that, maybe using a USB stick.
Just to understand how this works: I send a payload with an amount of data using DR2 to my Gateway through the Radio, my gateway sends the data to TTN where the keys are handled, as my msg requires confirmation TTN responds with a ACK, if you receive the msg and checking the keys, validate the msg. Now the question: Does TTN have a byte counter to check how many bytes I sent that day? According to this amount, do they limit the amount of bytes I can send, returning a NACK if I exceed my limit? Is this limit per device? From a certain time of day, if I reduce the number of bytes sent, will I be able to send larger packets again?
No it’s not, no it won’t. There have been several iterations of the 1.0.x series of specification and it’s now embarking on 1.1.x.
And it doesn’t matter a fig about the technology, the legal restrictions remain the same.
It beggars belief why you are trying to use LoRaWAN when every message is “sensitive and needs confirmation” when all over the forum you will find discussions on why this is not a good use case. Why are you using a system that you haven’t even learn’t the basics?
You may use a paid TTI instance, but this is not a use case for TTN.
Most of your explanations don’t seem very joined up - if you have devices in the same location that send a lot updates, what’s wrong with WiFi and a central gateway/server box? Incorporating firmware updates in to LoRaWAN is non-trivial but probably a lot more efficient than doing it 300 times with a USB stick.
But from what you have said so far, it may be that LoRaWAN could work but not as an implementation as you describe so far. Having a clearer use case and learning what the technology can do is strongly recommended.
Yes, no, not really. Confirmed uplinks don’t work that way for a start.
Your usage will be flagged very quickly and if not reduced, terminated.
The short answer is that about 50 devices sticking to the Fair Use Policy, two or three gateways so you provide your own coverage & contribute to the community and whilst the FUP says 10 downlinks a day, we strongly recommend one a fortnight at most, is a larger install on TTN.
Any other use, particularly explicit commercial, should be on a paid for TTI instance.
But it remains to be seen if your use case fits LoRaWAN.
As you are clearly looking to bludgeon your way through making this work without doing the volunteers the courtesy of reviewing the materials linked to above, let’s put this on slow motion and see what you may be able to figure out.
Please read this: https://www.thethingsnetwork.org/docs/lorawan/
Erm sorry no it is not! From an RF perspective LoRaWAN is LoRa and we announced the technology 10 years ago at Electronica 2012, after many years development and testing and using principles (Chirp Spread Spectrum) dating back to cold war radar development/jamming/detection in the late 1940’s through early 1960’s! LoRaWAN is ‘just’ (ok over simplification!) a protocol layer and network management mechanism/security system layered over the top of that phy layer with gateway to LNS connections of some flavour of IP… yes the latter evolves - but not in a way that will help you - often by way of clarification and behaviour mitigations and frankly a lot of that is/has been to reduce the abuse of the systems from spec mis-match/interpretation…or people trying to stretch the limits that are not considered good behaviour (see above!), other evolutions are around e.g. security and interchange mechanisms etc. Evolution at the Phy layer is possible from a regulation perspective but the community and wider LoRaWAN ecosystem fear (and indeed across all such LPWAN technologies operating in open shared ISM bands) is that evolution may be in the form of ‘the authoritise’ loosing patience with abusing users in what is supposed to be a largely self regulating and policing arrangement, with enforcement by certification and exception management, and actually deciding to tighten the airtime limits as a consequence - remember the number of deployed RF devices is growing almost exponentially and so spectrum management can only get worse…dont screw the system to the detriment of the other users!
As a guide I believe TTI suggest your application should be resiliant enough to tolerate a typical packet loss of upto 10%, personally across my GW/sensor fleet I see average more like 2% - YMMV. What does impact that signficantly is if some clown in the area of a GW starts using lots of consistent confirmed uplinks! Why? Because as explained above when the GW transmits an acknowledgement to a confirmed message it is deaf to ANY new messages from ALL other nodes in the area - including your own! (so much for expecting a confirmation - it may never even get heard)… deploy a few nodes and quickly the airtime dc of the GW can be exhausted (remember the GW is a transmitter in its own right and has its own RF regulatory limits) and no further ACK’s possibe - but also no other dl’s to ANY other node in the area - no new join accepts, no ADR adjustment, no MAC commands and optmisations and no C&C related dl’s… so for pities sake listen to what you are being told and as Nick put it dont
Its not going to happen!!!
If there are several/many ACK based nodes in the area and node doesnt see an ack - because GW was deaf as it was Txing ACK to another node - assume your node will retry, and retry and retry…the system snowballs, goes unstable and essentially grinds to a halt with a mathematically constrained, statistically determined min throughput for all users in the area - where that chaos limit falls is dependent of the behaviour and number of nodes in range and cannot reasonably be predicted. Either way it will not support lots of 1 up/1 down devices!
Note there have been proprietary commercial devices introduced over the years where their payload required 1:1 messaging, but they were not suitable for deployment on TTN/LoRaWAN other than for relatively low messgage throughput (say 1-2/hr), and they had therefore to evolved to either highly reduced conf rates (say 1:20 or even 1:200), or even shift to unconfirmed payload options once it was realised how badly behaved they were (use cases included cold -chain management/storage and building environmental monitoring). As noted above whilst you are permitted 10/day our guidance on the forum for TTN is think more interms of once per fortnight or even once per month - of if possible a dl or two for join accept, MAC configs and potentially ADR optimisation and nothing more for its operating life 
Use forum search extensively and review all the linked documentation and videos above and comeback when you have an outline of what woudl be considered a reasonable and thought out use case and implementation plan and we will happily help steer you through any issues arrising that arent covered by…forum search extensively and review all the linked documentation and videos above 
Your still not really describing the actual project.
However, you said ‘customers’ but TTN is a free to use service for the community …