Just wanted to tell you all about a little LoRa experiment. I ordered two LoRa devices, they worked fine right out of the box with the included firmware but my target was to create a two-way LoRa radio link between two MQTT brokers on different networks. With such a link I should be able to transfer messages between two systems just using radio
Just to add, obviously you have to think about security here as well, encrypt the data before sending it, checking the source etc etc but this was just a first test
It looks like your broker has TLS support that's where you might want to start form security point of view. There are approaches in LoRaWAN spec that might help with device Authentication and session data encryption. As @dceejay says you are running in licence free radio spectrum and it's not like WiFi there are time-on-air/dwell time constrains. What part of the world are you? I can help ensure your acting as a good network citizen, don't worry there are no RF police!!
Yes, you are correct, I think here in Europe (Sweden) it is "allowed" to transmit maximum 36 seconds / hour / channel. It is for sure just suitable for shorter and limited amounts of messages but the long distance is the key selling point I think
Regarding encryption, yes, I have look into that a bit. Using TLS is fine but I have to see a little bit here about that. I know the brokers does support it (I actually have it running on another broker I have locally here in my network) and the OpenMQTTGateway does support TLS as well. But then the question is how the data in the payload is handled all the way over the radio since the brokers are not bridged, they are unawere of each other. Maybe I could encrypt the payload data already in Node-RED and decrypt on the other side, using the same method and keys. Makes me think about a general feature, why not have the possibility to always encrypt all messages in Node-RED? A setting in settings.js maybe?
What data rate/spreading factor are your transmitting at?
Are you using 868/433 mhz ? looks like your using 868mhz (10% duty cycle) there are channel frequency that allow more power and longer TOA (time on air)
What was Band g3: 869.4 to 869.65 mhz - 27 dBm 10% duty cycle (SF7-SF12)
In terms of security LoRaWAN uses a device ID for authentication and shared key (symmetrical key) to encrypt msg herder and payload so your approach of doing this in NR makes sense.
Currently I was just "desktop testing" but it will be very few messages sent if/when I put it in operation
I'm just using the default settings of OpenMQTTGateway, here:
//Default parameters used when the parameters are not set in the json data
#define LORA_BAND 868E6
#define LORA_SIGNAL_BANDWIDTH 125E3
#define LORA_TX_POWER 17
#define LORA_SPREADING_FACTOR 7
#define LORA_CODING_RATE 5
#define LORA_PREAMBLE_LENGTH 8
#define LORA_SYNC_WORD 0x12
#define DEFAULT_CRC true
Just some experimenting using encryption. Encrypting the payload before sending it and when received, decrypting it, seems to work fine (using AES).
At "Start" a message is encrypted and published to the first broker, the first LoRa device picks this up and sends it to the second Lora device that publish it to the second broker
The received message is printed to debug (for debuggging), decrypted and then printed in clear to debug. After 5 seconds a response message is encrypted and sent back, received, decrypted and printed in clear to debug
Nice one ok I'm going to have a look at the docs on OpenMQTTGateway as 868E6 don't mean much.
Other than it's 868 mhz doesn't say frequency is, also I want to look at tx_power to see what unit of measurement is. can you get the length of you message and put it into this time on air calculator The Things Network
In this setup I'm not using LoRaWAN, just LoRa for direct communication between the devices
17 mW
I have not tested if my devices supports 250E3 (250 khz) but if so, the time on air would be reduced by 50% for the same message length
The encryption adds of course. Using the encryption nodes (node-red-contrib-crypto-js-dynamic) with the AES algo and encrypting just two chars generates a payload of 44 chars. Encrypting my test message consisting of 27 chars generates a payload of 64 chars
Time on air result is below in image. With the "allowed time on air" 36 seconds/hour I think I should be ok sending approx 260 such messages per hour
