This is Part 3 of the #LoRa series. If you didn’t read the previous post, check out Part 1 and Part 2.
This is not the final draft. I will come back and keep this draft updated. Feel free to contribute with your ideas and suggestions in the comments down below or contact me.
This is just experimental. Feel free to use LoRaWAN or Meshtastic. We are here to learn and research new technologies.
LoRaLink Protocol Draft
This is the version 1.0.0 of the LoRaLink Protocol. Created on 2. August 2023 and modified last on 20. September 2024. Everyone is welcome to contribute to LoRaLink Protocol.
Protocol Name
The protocol name is the result of feeding ChatGPT with some keywords like LoRa, LoRaWAN, ESP32 and Messaging. I asked in a tweet, which one of ChatGPT’s suggestions sounds the best and should be used for the project.
The name LoRaLink and the title Connecting the Unconnected was the clear winner.
LoRaLink Terminology
List of terms we use for the LoRaLink Protocol.
- LoRaWAN End Node → LoRaLink Node (Node)
- LoRaWAN Gateway → LoRaLink Tower (Tower)
- LoRaWAN Network Server → LoRaLink Server (Server)
- LoRaWAN Application Server → LoRaLink Application (App/Application)
- LoRaWAN Proprietary Messages MAC → LoRaWAN Prefix
- LoRaLink Frame → Complete packet that contains LoRaWAN Header and LoRaLink Body
- LoRaLink Body → Contains the LoRaLink Header and LoRaLink Payload
- LoRaLink Payload → Consists of the payload such as Nonce, Authentication Tag and Ciphertext for encrypted packets
LoRaLink Protocol Introduction
The LoRaLink Protocol is mainly a (little-endian) binary protocol. The focus relies on privacy and security, with as minimal metadata as possible.
It is built on top of the LoRa layer, but it takes advantage of LoRaWAN technology by using LoRaWAN Proprietary Messages. This makes it possible to forward a LoRaLink Frame to one or many LoRaLink Server by any consumer LoRaWAN Gateway that supports the Semtech UDP Packet Forwarder Protocol1.
LoRaLink is not designed with a peer-to-peer solution in mind. There are already many good peer-to-peer solutions out there. LoRaLink Nodes communicate with each other via LoRaLink Towers. This opens new opportunities to have almost unlimited range.
For example, a LoRaLink Node (923MHz) can be somewhere in the Australian Outback and communicate (without Internet) with another LoRaLink Node (868MHz) that is somewhere in the Swiss Alps , as long the LoRaLink Servers are connected together via Internet (or other type of connection).
LoRaLink uses Explicit Header. The Preamble length is 8 symbols and CRC is enabled. SyncWord should be set either to public 52 (0x34) or private 18 (0x12) to be supported by the LoRaWAN Gateways.
For transmitting (uplink) from the LoRaLink Node to the LoRaLink Tower, the device needs to disable Inverted IQ. For receiving (downlink) from the LoRaLink Tower to the LoRaLink Node, the device needs to enable Inverted IQ.
Maximum packet size is 250 bytes (including metadata like LoRaLink Header). It could be extended in future by splitting big packets into smaller chunks.
The LoRaLink protocol is agnostic to the underlying layer. Theoretically you can use any frequency and Transport Layer besides LoRa like TCP, UDP, Raw WiFi Packets or ESP-NOW to transmit LoRaLink Frames as long the receiver can handle the incoming packet and forward it to the LoRaLink Server.
LoRaLink Applications are similar to TTN and other Cloud Providers. LoRaLink Applications can process LoRaLink Frames for further usage.
LoRaLink Frame
A LoRaLink Frame consists of the LoRaWAN Header containing the LoRaWAN Prefix and the LoRaLink Body. The LoRaLink Body contains the LoRaLink Header and the LoRaLink Payload.
The LoRaLink Payload is encrypted and uses Chacha20 stream cipher and Poly1305 for message authentication2. The possibility to use different cryptographic algorithms (specially based on elliptic-curves) is open and should be considered for future usage.
| LoRaLink Frame | ||
| LoRaWAN Header | LoRaLink Body | |
| LoRaWAN Prefix | LoRaLink Header | LoRaLink Payload (Encrypted) |
The LoRaLink Node needs to have the (32 Bytes) symmetric keys of it’s recipients in it’s Key Storage. This could be offloaded to a connected Smartphone or Computer.
Optionally: The Key Storage should be a secure and trusted place on the microcontrollers chip or additional trusted hardware.
In special cases like emergency and rescue operations, it is allowed to send LoRaLink Frames in plaintext Plaintext (14).
The LoRaLink Nodes should use one of 7 channels to transmit and one specified channel (mainly the 8th channel of the frequency band) to receive LoRaLink Frames.
Before the LoRaLink Node transmits a LoRaLink Frame, CAD (Channel Activity Detection) should be used to check if the channel is free to transmit.
If the channel is busy, the device waits for a given amount of seconds and tries at least 3 times before it transmits the LoRaLink Frame even if the channel is busy.
LoRaLink Body
LoRaLink Payloads have fixed sizes. It is easy to determine the LoRaLink Payload size throughout the LoRaLink Flags.
| Name | Size | Description |
|---|---|---|
| LoRaWAN Prefix | 1 Byte | LoRaWAN Proprietary Messages MAC (0xFF) |
| LoRaLink Header | 3 Bytes | Source MAC Address |
| 3 Bytes | Destination MAC Address | |
| 1 Byte | LoRaLink Flags | |
| LoRaLink Payload | n Bytes | Encrypted Body |
In case a packet type does not have a fixed size or does not contain a length field, the payload size can be calculated by subtracting the LoRaWAN Prefix (1 Byte) + LoRaLink Header (7 Bytes) from the received (raw) LoRa Packet.
The Source MAC Address is the last three (unique) octets of the ESP32’s WiFi MAC Address in big-endian order. Devices that are not based on ESP32 can use (or spoof) other unique sources.
Optionally: For additional privacy the Source MAC Address (and the Destination MAC Address) can be set to 0x00 0x00 0x00 and the LoRaLink Packet Type to Plaintext (14). (This brings issues with it. see chapter Problems & Solutions)
LoRaLink Encrypted Body
| Name | Size | Description |
|---|---|---|
| Random Nonce | 8 Bytes | Chacha20 Nonce |
| Auth Tag | 16 Bytes | Poly1305 Auth Tag |
| Ciphertext | n Bytes | Chacha20 cipher stream |
A new random Nonce should be generated for every LoRaLink Frame. Authentication Tag should be checked to verify message authenticity on the receiver side.
Chacha20 is a stream cipher, so the length of the ciphertext may vary, but the majority of the LoRaLink Packet Types have a fixed length.
If the LoRaLink Packet Type is Plaintext (14) the LoRaLink Payload does not contain a LoRaLink Encrypted Body.
LoRaLink Flags
Based on the LoRaLink Flags it is easy to determine the LoRaLink Packet Type and Acknowledgment of LoRaLink Frame.
| Name | Position | Description |
|---|---|---|
| LoRaLink Flags | Bit 1 |
Packet Type |
| Bit 2 | ||
| Bit 3 | ||
| Bit 4 | ||
| Bit 5 | Acknowledgment | |
| Bit 6 | Reserved | |
| Bit 7 | ||
| Bit 8 |
The sender of a LoRaLink Frame sets the Acknowledgment Flag to 0. Received LoRaLink Frames are re-transmitted by the LoRaLink Tower with Acknowledgment Flag set to 1 to signify that the LoRaLink Frame was received and re-transmitted successfully. This packet can be checked by the sender to determine if an error occurred after the transmission of the LoRaLink Frame.
This does not verify if the recipient received the LoRaLink Frame successfully. Later versions should consider some kind of message queuing system to re-transmit packets when the LoRaLink Node was not online and in close proximity.
The reserved Bits 6, 7 and 8 could be used in future to indicate that the incoming packet is split into smaller packets. A possible (theoretical) size could be ~2000 Bytes split into 8 LoRaLink Frames.
LoRaLink Packet Type
The LoRaLink Packet Type is assigned to the first 4 Bits of LoRaLink Flags. 4 Bits gives us a total of 16 possibilities for different packet types. The packet numbers 7 to 13 are reserved for future use.
| Number | Name | Direction | Description |
|---|---|---|---|
| 0 | PING | Node → Tower → Node | Ping a Node |
| 1 | PONG | Node ← Tower ← Node | Reply to a Ping |
| 2 | DISCOVERY | Node → Tower | Try to find out if and how many LoRaLink Towers are in close proximity. Can contain Node coordinates to receive calculated distance to the LoRaLink Tower |
| 3 | ECHO | Tower → Node | Reply to Node Discovery Request. Can contain additional data of LoRaLink Tower |
| 4 | MESSAGE | Node ↔ Tower | Send encrypted message to destination MAC |
| 5 | COORDINATES | Node ↔ Tower | Send encrypted coordinates to destination MAC |
| 6 | FORWARDER | Node → Tower | Forward a message to Third-Party Protocols (Email, Webhooks, XMPP, MQTT, IRC, Discord, Telegram, ...) |
| 7-13 | RESERVED | Reserved for future use | |
| 14 | PLAINTEXT | Node → Tower | Send any payload, binary or ASCII text without encryption to destination MAC |
| 15 | BROADCAST | Tower → Node | Broadcast encrypted or plaintext message to Nodes in close proximity |
LoRaLink Packet Type Descriptions
PING & PONG
A Ping packet gets addressed to destination MAC and sent to the to the LoRaLink Tower. The LoRaLink Server receives the Ping packet and transmits it to the destination MAC and waits for an Pong packet. A successfully acknowledge Pong packet gets sent back to the source MAC.
DISCOVERY & ECHO
LoRaLink Node sends a Discovery packet every 15 seconds to figure out how many LoRaLink Towers are in close proximity. The user should have the option to opt-out if there are any privacy concerns.
The received Echo packet from the LoRaLink Towers contains information, such as RSSI and can be used to print out or draw icons on a display. Additionally other useful information could be sent inside an Echo packet, such as Date and Time data to act as NTP Server to synchronize the LoRaLink Nodes internal time.
Optionally: If the Discovery packet contains Longitude and Latitude of the LoRaLink Node, the Echo packet contains the distance to the LoRaLink Tower.
MESSAGE
- Node A sends MESSAGE to NODE B,
bit 5is set to0. - LoRaLink Tower receives MESSAGE from Node A redirects it to NODE B and set
bit 5to1. - Node A receives the broadcast MESSAGE and checks source/destination MAC and the
bit 5if its set to1. -
NODE B receives the broadcast MESSAGE checks if it is the recipient.
- NODE B sends MESSAGE to Node A,
bit 5is set to0. - LoRaLink Tower receives MESSAGE from NODE B redirects it to Node A and set
bit 5to1. - NODE B receives the broadcast MESSAGE and checks source/destination MAC and the
bit 5if its set to1. - Node A receives the broadcast MESSAGE checks if it is the recipient.
COORDINATES
LoRaLink Node sends it’s coordinates to destination MAC. This can be used in future by opt-in users to broadcast their positions on a public/private Map.
FORWARDER
LoRaLink Node sends custom payload to LoRaLink Server. The payload is forwarded to Third-Party Protocols such as Email, Webhooks, XMPP, MQTT, IRC, Discord, Telegram, etc.
PLAINTEXT
LoRaLink Node sends custom plaintext to the LoRaLink Server. and gets re-transmitted as a boardcast to everyone in close proximity.
BROADCAST
LoRaLink Server broadcasts a plaintext or encrypted message to all LoRaLink Node in close proximity.
Problems & Solutions
The service can be easily exploited by spamming and flooding the several LoRaLink Packet Types. Timing limits on LoRaLink Tower and LoRaLink Server need to be set and adjusted.
Setting the Source MAC Address and/or Destination MAC Address to 0x00 0x00 0x00 can end up in complex and chaotic scenarios. This option should be allowed or rejected on the LoRaLink Tower side.
Changelog
Last modification on 20. September 2024.