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 …
So with details we are finally getting somewhere - its not a need to send thousands of messages per day from a node but rather a need for a GW in an area to handle thousands of messages per day from a lot of nodes… confirmed messages still a problem for the reasons outlined above wrt impact on GW and network behaviour.
and
Is a problem, speard across volume nodes and changing “transmit” to “receive at the gateway” starts to make more sense…but still not with confirmation. Question, why does the node need confirmation? Will it trigger a blind retry if failed/not ack’ed? Better have your back end application decide if something is missing (using say Fcount) and if a gap in data seen request that specific data catch up - either through an adjunct to a follow on message or as a rolling/sliding data window - potentially with some compression schema, though we wont know what is suitable until we know a bit more about the
as there are’ horses for courses’ as they say !
If for example, your “telemetry” is an 8 byte message, that might assemble into a sliding data window of 3 telemetry messages (current, previous and one prior), as 24byte LoRaWAN Payload, then that would be viable for SF7, 8 & 9 for upto 112 messages per day under TTN FUP - close to your 140. a 6byte message would get you to 120 and hey look if only a 4byte telemetry message we get to 145/day exceeding your target again its details details…
A GW should not struggle to service 300 nodes in a location - even if running at such a level of traffic and on constrained range of SF’s - not a great use of GW capacity and not fully LoRaWAN as expected to run on random channels and SF’s though typically nodes settle to their optimal SF under ADR. What will mess up your plan is if your nodes are not the only ones in range of the GW - a few thousand more from say a local street lighting or water metering deployment would increas risk of collisions etc. and certainly any attempt to use regular downlinks (ie. confirmed messages) would be bound to fail as you scale - GW DC exhaustion and too many missed (due to collisions or deaf GW) data sets limiting reconstruction. Also need to avoid all the nodes being timesynched and trying to TX at around same time…rather truely randomly powered and subsequent staggered and time distributed Tx’s to minimise statistical risk of concurrent TX and colliding - obviously a greater risk when all using small number of SF’s…
Such a system might be tested and developed around TTN but for deployment, and use at scale, especially if commercial use, then you woudl need to discuss a paid TTS deployment as private instance.
Either way if nodes must see confirmation and/or if no tolerance to missing messages and thereby data gaps then your application is not a good use case for LoRaWAN (says the guy often accused of seeing LoRaWAN as a hammer to hit every nail put in front of him! )
One final thought the forum volunteers are here to help the community - not provide free consultancy services to commercial application/product developers…if you need consultancy and support, especially if a LoRaWAN novice, then maybe approach some of the LoRaWAN ecosystem players or the more knowledgable folk on the forum to set up a private consulancy/support arrangement, or contact TTI for paid support…just sayin’
1 Like
My friends, thank you very much for your feedback. LoRaTracker, My product is connected to machines and through sensors I can check its status. And I understand that the 10 device free version is for development only. Jeff-UK, There are times when I would like to transfer firmware update files. That’s thousands of bytes. But I can review this question. The data is sensitive and I need to store it on my local server, so I need confirmation.
I couldn’t find answers to these questions here by searching the forum. And I don’t know how to use support, that’s why I asked here.
Look at the LoRaWAN FUOTA specification. (Should be available on the commercial offerings, not on the community network)
No, you need to think differently. Several solutions to make sure all data will be present in your backend have been listed. Acking every message will not work for LoRaWAN, the protocol was never designed to handle such a use case, which has been mentioned multiple times as well.
Those questions won’t be answered because TTN does not want to encourage you pushing the fair use limits.
You need to rethink here as well. What would happen if TTN drops data from your device to the backend? Would your device know about it (not likely given the LoRaWAN protocol of just send and hope the transmission will be received) or still transmit causing usage of the scarce resource airtime on a frequency?
If you need the answers for a commercial deployment, go to Contact Us
As @kersing says, there is nothing definitive in writing otherwise people would spend time gaming the system. If you want absolute numbers, that’s a big big red flag.
But I did make it clear what a larger community install would look like so you do have an answer, you have the Fair Use Policy in writing and as I said above, egregious breaches of the FUP are picked up on the TTI dashboard and if you don’t get it back down to size, terminated.
Which pretty much means you won’t even be able to get started on TTN.
And if you use a paid for instance, it looks like your gateways will breach legal duty cycles very quickly, so you won’t get confirmations back to the devices.
As we’d suggested several times, being more explicit about the application would help as I can think of many ways of transferring time critical & important data, building in redundancy in to the uplinks as well as flexibility for how often a device should transmit under different conditions. As long as it’s not for a safety critical system which LoRaWAN is not suitable due to the potential for packet loss over the air.
As to:
Clearly you have not yet read the learning section - if you had, it would be clear to you that data is encrypted all the way up to the application server, that a LNS is not a database, so everyone has to store their data on their own/local server and there is nothing you have said that justifies the use of confirmations.