This is the TTN Forum, supporting private none TTN/TTI based networks is outside of scope.!
Also wrt duty cycle regs. note just because they say you can use up to an given limit does not mean you should - atleast other than in exceptional circumstances (short term testing/mapping coverage/capacity for longer term optimisation and associated benefits, or during emergencies/alarm conditions). Even with LoRa’s interference mitigation and co-existance techniques the airwaves will become quickly clogged if every user bangs up against the limit just because they can!
In practice you need to design you apps to be resiliant to allow for packets not getting through and as a good guide plan on utilising no more than 10% of DC limit, better yet 1% of limit as a socially responsible plan. Note also when considering whether to use TTN or your own private network, TTN has a FUP (not yet enforced but should be adhered to as a guide/self regulating) that limits daily on-air time, number of messages and particularly wrt downlnks (downlinks kill gw capacity as a gw cant ‘listen’ when transmitting causing periods of ‘deafness’ that affect all users…)
Also remember the radio signal is recieved by ALL GW’s in range and just because you use a private instance that does not releive the community/society in general of having to deal with any traffic or congestion you may generate. LoRaWAN nodes associate with the back end NS not the GW’s and all GW’s have their capacity consumed (though not handling downlinks if ‘off net’).by all user activity.
If you encrypt your payloads and only decode in your app then the data remains ‘private’ within the network, and the only ‘information’ seen by others is the fact of a transmission not the content. Given all GW’s in range receive even going ‘private’ wont mask the fact of the TX… e.g. if the only time you TX is when there is an alarm condition then everyone can ‘see’ that an alarm has been triggered even if they dont have detailed access to see what and why 