I’m trying to configure a LoRaWAN network. My goal is setting between 300 and 1200 sensors, that will send alarms when specific events happen.
As far as I know, LoRaWAN duty cycles are restricted by ETSI EN300.220 standard as:
g (863.0 – 868.0 MHz): 1%
g1 (868.0 – 868.6 MHz): 1%
g2 (868.7 – 869.2 MHz): 0.1%
g3 (869.4 – 869.65 MHz): 10%
g4 (869.7 – 870.0 MHz): 1%
and nodes select the channel frequency for transmission in a pseudo random way. My first doubt is, how can I make sure this duty cycles restrictions are accomplished if I can’t control the frequency selection?
My second question is, these duty cycles are meant for a single device, or for a full network? For example, if duty cycle is 1%, it gives me 864 seconds/day, which means 36 seconds/day. If my Time on Air frame is 30ms (because my alarm payload is just 1 byte), I can send 1200 messages in an hour ((36secs/hour)/(30ms/message)), which means 1 message each 3 seconds ((3600secs/hour)/(1200)). If I have one just single node sending 1 message each 3 seconds, I am respecting duty cycle policy. However, if I am sending this same message each 3 seconds with 300 nodes, I am not respecting it, right??
Thank you in advance for your help. Please correct me if I am doing any wrong suposition.
The payload is 1byte, cause I just need 8 bits for identificating a node. Perhaps 2bytes, but according to https://www.loratools.nl/#/airtime the time on air is 25-30 ms.
Yes, I am assuming SF7 and 125KHz.
About TTN, I don’t know if I should use it. I want a private network, so I hesitate about implementing it with a public platform as TTN. I know I can set keys to my apps in TTN, but I’m not sure about the security in this case. What do you think?
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
If looking for a private instance I suggest you consider contacting the TTI guys directly, or depending on where you are in the world you may be able to work with various local teams and professionals to implement a TTI instance…by definition the TTN is a community/open initiative but that doesnt mean it is insecure or unable to support secured payloads Principal problems using TTN tend to consolidate to stability/availablility of any given GW (Many are professionally installed and set for the long term, others are hobbyist projects turned on & off at owners will or fail frequently etc.), and the potential risk of local disruption caused by existing or new introduction of none LoRaWAN compliant Single (or Dual) Channel Packet Forwarders (generally less of an issue by proportion of deployed GW’s than it used to be given continued drop in cost of uGW’s over time), also whilst actual routing seems quite resiliant any trawl of the Forum will show all too frequenft drop off of status tools and console, with visibility on console particularly of GW status, being unreliable if using to monitor/configure/train.
Go for it wrt TTN and see how it works out for you - if not satified you can always move to private instance later
