See Spreadsheet for LoRa airtime calculation, and be sure to limit your payload: Best practices to limit application payloads is a work in progress, but I heard a “Cookbook” being mentioned in this update.
Will bidirectional communication be available?
Does this refer to DevAdr, and then specifically for “Activation by Personalization”?
The DevAddr consists of 32 bits identifies the end-device within the current network. […] The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager.
For Over the Air Activation, this DevAddr is only known after activation, but then a DevEUI is already known, which is truly unique and not related to any gateway location:
6.2 Over-the-Air Activation
[…] The join procedure requires the end-device to be personalized with the following information before its starts the join procedure: a globally unique end-device identifier (DevEUI), the application identifier (AppEUI), and an AES-128 key (AppKey). […]
6.2.1 End-device identifier (DevEUI)
The DevEUI is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device.
But one could also hard-code the DevAdr in the node:
6.3 Activation by Personalization
[…] Activating an end-device by personalization means that the DevAddr and the two session keys NwkSKey and AppSKey are directly stored into the end-device instead of the DevEUI, AppEUI and the AppKey. The end-device is equipped with the required information for participating in a specific LoRa network when started.
I guess Activation by Personalization is impossible with TTN being global: the NwkID only being 7 bits, TTN won’t have its own unique NwkID (but probably needs to know what identifiers are already used around a specific gateway)?
LoRaWAN bit per second transmission rate is supposed to be between: 250 to 5470 bps.
So assuming you only have 30 seconds on air time every 24 hours, then a Node can send between 937 bytes and 20,512 bytes per day, meaning it could be as low as 39 bytes per hour. For a single 1-byte value sensor I can get a guaranteed remote sensor resolution of one reading every 2 minutes.
Is this calculation correct?
How much of this 30 second OTA time is being used up by protocol headers or is that handled outside of this fair use limit calculation?
I had thought that LoRaWAN enabled negotiation with devices to set their transmission behaviour. Surely, if the gateway is only seeing a small number of devices talking to it, it can inform them to transmit more frequently as there is much more available bandwidth, then as density of device in an area increases, so the devices on air schedule is managed and reduced across all of them, and of course you always leave a large percentage of unallocated air time; but I guess that is not how its going to work?
Nope… As meanwhile you might have seen in the Spreadsheet for LoRa airtime calculation, in worst conditions (SF12) it could be as low as 5 bytes (plus 13 for the LoRaWAN header) per hour… (On average; you could send 25 packets of 5 bytes with just 2 minutes delay.) And going from 5 to 1 byte doesn’t even get you from 25 packets to 26 packets per day.
I’m not the expert, but given @Thomas’s explanation of that limit, I’d guess all air time counts, not just the time for the payload. (If not, then my addition of the Fair Access Policy to that calculation sheet is wrong.)
I assume the team uses the same calculation as they do in the ttntool, this include all bits transmitted, see below extract …
preamble := float64(8 + 4.25)
payload := math.Max(math.Ceil(float64(8phyPayloadSize-4int(spreadingFactor)+24)/float64(4int(spreadingFactor)-2dataRateOptimization))*5, 0)
crc := float64(8)
return (preamble + payload + crc) * tSymb, nilYes, that looks like the formula from http://www.semtech.com/forum/images/datasheet/LoraDesignGuide_STD.pdf to calculate air time. I indeed assume that the very same value is used for the Fair Access Policy.
(Actually, that formula is slightly different; I’ve reported some possible bugs to the team.)
@arjanvanb Thanks for the extra explanation. I can understand the origin of the fair use policy, but I think its far too inflexible. Discussion I have been having offline with people far more clued in than me, highlights that LoRa devices can transmit for up to 36s per hour and still be within the required duty cycle limits. My problem with 30seconds per day (or as Thomas seems to suggest one message per hour) is that you can’t implement any kind of tracking application with TTN’s fair use policy for a sensor/Node that is mobile. Part of the attraction and advertised capability for LoRaWAN was that it would enable such location based tracking with really low power non-GPS enabled devices. It would seem that TTN just cannot sensibly support that…?
I’m the guy who asked about regulatory. I still need to understand how the security works and end-user devices get on to the network.
I see a BIG problem if there is a situation where TTN does allow anonymous access as then the network can be misused and gateway operators could be liable for traffic passing through their systems.
In the UK if you operate a network open to the public - you can be classified as a Public Electronic Communications Network (under the Communications Act 2003), this is what telcos/ISPs are regulated under. Though there are no longer licensed telecommunications companies, if you’re a PECN you have obligations under the Comms Act (whether you like it or not, and ignorance is no excuse under the law).
If I have a say Arduino node I guess somewhere I have to register an end-point and that is an application somewhere. If that access is controlled, then you have at least control of which devices can connect and which cant. If anyone can register an application with TTN and then just use their devices and TTN will let them through that’s where it becomes scary.
As an (devils advocate) example. I go to some maker event and buy some (say Arduino LoRa) nodes for cash and connect them to bombs placed strategically around a city, they register to an app that I have built on a platform hosted in another country (or some dubious free hosting service somewhere that doesn’t require identity checking).
When all the devices register, I know they’re on the network and can then send them back a command to detonate.
When the security services come looking they find bits of LoRa kit and want to trace it back to TTN. Security services then ask for ALL kit involved in TTN so they can do forensic analysis … I realise this is a worst case scenario, but …
Also with the IP Bill being rushed into law (in the UK) at the moment, police/etc can ask for logs, connection records etc. TTN is a comms network, so would need to comply … well at least gateway operators in the UK.
There’s another issue that ISPs that provide the actual Internet connection to the gateways may have T&Cs against running networks on top of theirs.
1 Like
ps if anybody feels like reading the IP Bill and what it means for a comms providers
Note that all this also depends on network coverage. If the node can use SF9 or better, then it can send 6 bytes for two 24 bit coordinates every 10 minutes, all day long. Or much more often when not sending all day.
(On the other hand: some say a moving node should use SF12, some others say that’s making things worse. See references at Best practices when sending GPS location data which is also work in progress, and needs some clarifications.)
Hi, @johan
Are the powerpoint slides from the Tech Update Feb 29th be available for download?
Thanks,
Martijn
1 Like
Slide 10 says:
Private Networking
Run The Things Network components on-premise: Docker images are made available and maintained by the core team
A private networks optionally falls back to community coverage and vice-versa
To me this sounds like someone could “take” from the community without “giving” anything? Also, I wonder how such fallback would work with the network keys?
@arjanvanb I think it would be bidirectional only. And it would be the raw data; the network session keys reside in the broker. So the router discovers which broker(s) can handle the data, and that might be one in a private network if it is plugged in. Whether a message can be handled really depends on the message integrity check which happens in the broker.
1 Like
@johan: Thanks for the answer during the Hangout, where to find more details or who could I contact?