Peer-to-peer LoRa wireless protocol software

We do not make use of the standardized LoRaWAN protocol because is lacks efficiency, does not support direct node-to-node communication, and is too costly and far too complicated for many applications. So we have developed our own LoRa wireless protocol software (“RadioShuttle”), which which is capable of efficiently sending messages in a fast and secure way, between simple LoRa modules. This software is equally suitable as a node or as a station (server).

Wireless protocol software (RadioShuttle)

• Secure message transmission (232 bytes user data maximum), the receipt will be acknowledged, lost data is automatically repeated
• Insecure message transmission (requires less time/energy), for applications that often send messages on a regular basis, and where a lost message is no big deal (e.g. temperature data)
• Parallel sending of different messages to an identical or to different stations (runs in the background, to save energy)
• Unique 32-bit device ID (device number) per LoRa member, unique 16-bit app ID (program number for the communication)

Data security

• Login from node to station required (can be switched off)
• Login with encrypted password (SHA-256 encrypted with a random number)
• Encrypted message transmission (configurable per message)
  AES 128-bit encryption, AES messages require a minimum of 16 bytes of data, without using AES, smaller messages can be sent.
  No passwords are transferred. Hacker-proof: logging and repeating encrypted AES messages or logins will not succeed

Air Traffic Control

The nodes only send if no LoRa signal is active on that channel. The stations create an automatic network plan, defining which nodes and stations are allowed to communicate, and when. (Planned)

Optimized protocol

• Message delivery within 110 ms (SF7, 125 kHz, free channel provided)
  • Messages only require 2 x 12 bytes (protocol overhead)
• Default LoRa spreading factor SF7 (SF7-SF12 adjustable)
• Default LoRa bandwidth 125 kHz (125/250/500 kHz adjustable)
  • Narrow bandwidths allow for a longer range
• Automatic transmitting power adjustment saves energy and reduces traffic on the neighboring stations

Operating mode

• Operation as a station, constant power supply recommended
  (12 mA in receiving mode, transmitting mode (20 to 100 mA)
• Operation as Node Online, constant power supply recommended
  • The node is permanently receiving
  • Otherwise behavior like “Node Offline” (12 mA in receiving mode, transmitting mode (20 to 100 mA)
• Operation as wireless sensor (Node Offline checking)
  • Node reports back regularly, to possibly receive data
  • Receiving messages can last up to 30 seconds
  • Otherwise behaves like “Node Offline” (1 µA in standby mode, battery operation for years)
• Operation as a wireless sensor (Node Offline)
  • The node is only active if events are reported (1 µA in standby mode, battery operation for years)

RadioShuttle library resources

• Memory requirement (as of 08/2017)
  • 100 kB Flash for RadioShuttle library with SHA256 & AES
  • 10 kB RAM for Node Offline/Checking/Online mode
  • 10 kB RAM for Station Basic mode (RAM depends on the number of nodes)
  • 1 MB RAM for Station Server mode (Raspberry PI, 10,000 LoRa nodes)
• Accurate timer with steps of 0.5 ms and interrupt

Supported LoRa and MCU boards

• Semtech SX1276MB1MAS and SX1276MB1LAS (SX1276-based)
• MURATA CMWX1ZZABZ-078
• HopeRF RFM95
• STM Discovery kit for LoRaWAN (STMicroelectronics B-L072Z-LRWAN1)
• The LongRa board
• The ECO Power board
• The Turtle board

Supported operating systems

• Arduino, Arduino Zero or newer
• ARM Mbed OS, supported MCUs (e.g. STM32L0, STM32L4)
• Linux (Raspberry PI/Orange PI planned)

Example configurations

1. Simple network with station and nodes | Image or PDF
2. Network with station and 2 nodes (online/offline) | Image or PDF
3. Advanced network with station and 5 nodes (online/offline) | Image or PDF
4. Two advanced networks communicating with each other | Image or PDF

Protocols: LoRaWAN^TM vs RadioShuttle

Comparing the LoRaWAN^TM and RadioShuttle protocol reveals the differences between both:

Download illustration | Image or PDF

LoRaWANTM	RadioShuttle
Concentrator required	No concentrator required, station uses regular LoRa module
Network subscription fees	No monthly fees
One large radio cell	Many small independent radio cells
Busy network in a radius of many kilometers	Small networks with no interference
Risk of failure (Concentrator)	Automatic transmitting power adjustment – longer battery life
High latency, larger spreading factor, e.g. SF11 (1320 ms)	Low latency, small spreading factor, e.g. SF7 (120 ms)