Dear TTN members
After a deep study on Lora IoT cloud platforms, I select TTN as my best chosen platform. I want to understand TTN structure , advantages, and limitations. For thus, I don’t know the starting point from which I start TTN comprehension. I intend to ameliorate TTN structure and modules in order to make it more efficient and overcome its limitations. Please help me to start.
Thanks in advance
Just currious, but what is the eventual purpose for your changed and improved TTN structure, are you setting up your own platform ?
Yes, I set up my own LoRa platform and I use TTN to visualize and manipulate data. However, I find in this link ( https://www.thethingsnetwork.org/docs/lorawan/limitations.html ) some limitations as Not suitable for Realtime data. For thus, I think to participate in the amelioration of some parts in TTN.
A lot of the reasons for that are due to legal restrictions, no way around that, apart from switching to a frequency or ISM band that does not have the same duty cycle restrictions, 2.4Ghz for instance.
The fair use policy of TTN does limit you to 30 seconds of air time, but that is free. If you want more sensor data then you just need to approach TTI and pay. Cannot see how ‘improving’ TTN in some technical way would allow them to provide more free airtime.
You are aware of loraserver.io, that is perhaps more suitable ?
I want to know if it is possible to apply some new lossless compression algorithms such as CRUSH to the payload size in order to pass more data and gain more time for paid or not paid TTN version. For example, we have in the link (https://docs.google.com/spreadsheets/d/1voGAtQAjC1qBmaVuP1ApNKs1ekgUjavHuVQIXyYSvNc/edit#gid=0) the Tpayload in function of the payload size, so if we reduce the payload size we have a gain in the Tpayload value.
How user data is encoded is entirely outside of TTN - you are welcome to do anything you want to it before it is encrypted, packed into a LoRaWAN packet and checksummed, and the same after it has been verified, extracted, and decrypted and presented to your consuming software, without changing TTN.
Keep in mind however that LoRaWAN adds a lot of overhead on top of application data, to the point that shorter packets are mostly overhead with very little application payload. If your application can tolerate it, sending longer packets less frequency is more efficient.
Except that how long a payload can be sent depends on the range from the nearest gateway, which determines what data rate (spreading factor) is used. In Europe long time duration packets are allowed, so to a limited degree even the super-slow long range SF12 can be used.
But in the US we can’t use spreading factors larger (longer) than 10 for LoRaWAN, because at SF11 the LoRaWAN overhead itself would not fit in the packet duration limit.
This may mean that an application ideally chooses what packet to send (vs how often to send) based on the spreading factor currently chosen by the adaptive data rate (ADR) algorithm.
gain more time for paid or not paid TTN version. For example, we have in the link
You were given a somewhat false distinction there. No organization “owns” the airwaves, they are shared resource. Primarily what the TTN fair usage policy concerns is using the capacity of the gateways owned by other members of the community - if you are using a private network, either via TTI or some other solution, you are using your own gateways or perhaps paying to use someone else’s.
At that point the legal and technical limitations remain
The legal limitations vary from place to place.
The technical limitations include the degree to which the design of LoRaWAN as a protocol matches some needs and mismatches others. The range of options there includes not only the TTN public LoRaWAN network vs private LoRaWAN networks, but also private networks that use LoRa in a way different than LoRaWAN uses it, networks that do not use LoRa, networks that use other frequencies, etc.
Likely you should spend some time and gain some practical experience with the existing offering before you jump into building an alternative.
No decision is without tradeoffs, if you make a change to improve one thing, you almost invariably make something else worse. And once you change anything about the network scheme itself, you loose the ability to participate in the public network.
I would add to this that FUP not withstnding just because local legisplation allows you to go up to a particular limit that does not mean you should default to assuming you can use up the limt.
The fact is spectrum is a shared resource and even if you are running your own GW’s remember when you are Txing ALL GW’s in range will hear your ‘broadcast’ and even with the interference mitigation properties inherent in LoRa and the usual problems of near vs far tx’ers you will increase the possibility (probability?) or clashing with others .
If everyone banged up against the limits all the time spectrum can quickly become unusable. Dont do it…it’s anti-social! Design your use case and apllications to allow for far lower duty cycles - perhaps 10-15% or local limits max…better yet, if not running short term tests, aim for usable solution based on on 0.1-2% of usable limit 
Fact is if everyone is gready that is where you may end up anyhow! 