RFC ‐ Mesh LoRa RF Protocol - redengin/enmesh GitHub Wiki

Mesh LoRa RF Protocol

Abstract

The use of LoRa has expanded as RFC-8376 predicted. LoRa mesh implementations allow users to communicate with others beyond the reach of their LoRa radio. Current LoRa mesh implementations are now struggling to provide transmit availability as the density of LoRa nodes increases.

Mesh LoRa provides value by

Ensuring participants can both send and receive toward the mesh
Providing anonymity - Mesh LoRa Anonymity

Status of This Memo

This is an internet Standards Track document.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Motivation

People need a more direct way to interact - especially with their local community. The internet has diluted local community interactions.

Increase Coordination - platforms control access to information toward monetization
- rather than prioritize interactions that would increase the coordination, the algorithms specifically de-prioritize coordination to increase interactions where the user has no agency. By minimizing agency, platform usage is maximized by creating endless rabbit holes to explore rather than leverage agency to resolve the local issues.
Increase Anonymity - internet based communications provide many vectors to de-anonymize the participants
- The evolution of the internet has maximized it's ability to de-anonymize users - used by observers toward monetization and controlling speech.

Growing use of Decentralized Networks

Reticulum cryptography-based networking stack for building local and wide-area networks
Solid a platform for linked-data

Users are seeking out the ability to communicate without the interference of platforms - returning the control of communication to the users.

Re-enforcing LoRa design

LoRa was designed to be near impossible to jam (denial of service by transmitting noise into the RF band). Chirp spread spectrum (CSS) mitigates jamming - allowing communication even below the noise floor of the RF channel.

Mesh LoRa is equally robust to denial-of-service attacks - participants shall always have transmit access.

RFC-XXXX

1. Terminology

LoRa - LoRa is a proprietary RF radio broadcast mechanism supporting half-duplex communication at [0.3 ... 27] kbit/s.
Store and Forward - Provides a delay tolerant network - communications propagate toward the end user(s).
Content Distribution Network (CDN) - CDNs provide high availability and performance by distributing content geographically closer to the end user(s).
Beta Reputation System - Where most Reputation Systems require additional traffic to coordinate the reputation of nodes, Beta Reputation Systems eliminate the need for additional traffic as nodes can directly observe performance of peers.

2. Introduction

Mesh LoRa follows in the footsteps of FidoNet. FidoNet provided global communication when communications were confined to dial-up modem.

Mesh LoRa is a distributed CDN using the Store-and-Forward paradigm. Mesh LoRa participants observe LoRa broadcasts and bucket them per content.

LoRa bridges - Mesh LoRa node(s) accessible to the shard with access to more distant shards via LoRa
internet bridges - Mesh LoRa nodes that provide internet connectivity to distant shards via an internet gateway
(or any other communication channel that supports a bridge)

LoRa transmissions are a geographical RF broadcast. Not all nodes within a geographical range will receive local transmissions as LoRa transmissions need line-of-sight for reception. To propagate LoRa transmissions toward the mesh, Mesh LoRa nodes rebroadcast LoRa transmissions - increasing the access toward bridge nodes.

LoRa channel

frequency (F) and band width (BW) - center frequency, and bandwidth
- US915 Partitioning: 64 channels of 125 kHz bandwidth, and 8 channels of 500 kHz
- EU868 Partitioning: 8 orthogonal channels of 125 kHz bandwidth.
spreading-factor (SF) - (aka chirp rate)
- Chirp protocol allows LoRa participants to communicate below the noise floor of the RF spectrum of the environment
- spreading-factors are orthogonal on the RF spectrum
  each spreading-factor is effectively a separate LoRa Channel

Mesh of Shards

Mesh LoRa nodes follow the Store and Forward paradigm to propagate LoRa communications toward the mesh. As Mesh LoRa nodes store data, they are a distributed CDN

As not all Mesh LoRa nodes will be able to access a universal mesh CDN, these nodes provide local CDN content(a shard).

The Mesh LoRa CDN paradigm maximizes access to Mesh LoRa peer's content.

Mesh LoRa participants use multiple LoRa channels (seeking out LoRa channels that support needs of both the participant)

Mesh LoRa design coordinates the participants toward eventual synchronization - by each Mesh LoRa participant node seeking out shards (LoRa channels) that maximize the peer's communication needs (timeliness, bandwidth, caching, etc.).

LoRa Node Types

local only - only able to communicate with nearby nodes via LoRa
long-range - able to communicate with distant node(s) via LoRa
- LoRa nodes with greater range via LoRa (aka repeaters)
- bridged - nodes that proxy LoRa communications over other channels (e.g. internet gateways)

Long-Range Node Design Guidance

Use multiple LoRa radios to provide timely synchronization of shards - one LoRa radio per shard
- if the number of LoRa radios is less than the number of shards, the node must time-divide shard service - delaying data synchronization and decreasing the timeliness of the shard.
Maximize storage
- minimize the need for data retransmissions by storing the data locally, eliminating the need of participants to re-transmit into the mesh. By providing longer-term storage, the CDN contents are more likely to be available to participants.

Mesh LoRa Robustness

Under Mesh LoRa, there are no defined LoRa channels. This makes Mesh LoRa robust to malicious actors that overly transmit on a LoRa channel denying transmit access to other participants.

A Beta-Reputation algorithm is used by each participant to prioritize usage of LoRa channels toward the shard communication needs.

Mesh LoRa nodes constantly seek/create shards per the communication needs of their peers:

timeliness - minimize the time to destination
bandwidth - maximize bandwidth for large transfers
storage - maximize the duration that content will be preserved inside the mesh

Mesopredators

Most participants of a mesh don't want to be concerned about the bad actors. For user-maintained-networks, there only needs to be a small crowd of concerned participants that will actively hunt bad actors - de-anonymizing them to motivate observation of the norms.

As Mesh LoRa protocols focus on anonymity, hunting efforts must create their own methods to de-anonymize a participant.

3. Overview

How do LoRa radios handle contention on a LoRa Channel?

LoRa radios are very sensitive (capable of communication below the noise floor).

LoRa radios seek out the "loudest" transmissions in the vicinity. When there are multiple radios transmitting on a LoRa channel in the vicinity, the participant's node will only observe the "loudest" transmissions.

Mesh LoRa Contracts (Beta Reputation)

Mesh LoRa's objective is to maximize the number of participants by ensuring ability to transmit. As a broadcast based protocol participants will always be able to receive.

The Beta Reputation System allows each participant to judge the use of LoRa channel(s) toward the shard's mesh communication needs.

LoRa Channel Contract

Use of a LoRa channel must allow all local participants to transmit
- When a node observes contention for transmit, the node must delay it's own transmissions to allow access to others

Mesh LoRa node Contract

Each node in Mesh LoRa provides store-and-forward functionality
- As storage is limited, nodes are free to drop packets per their discretion
Stored content can be queried by participants - coalescing the participant to the shard when the participant misses the original broadcast.
- Content queries are lowest priority as Mesh LoRa prioritizes the LoRa channel usage toward upstream synchronization of the mesh.

4. Architecture

Current LoRa mesh implementations (e.g. Meshtastic, MeshCore, Reticulum) provide great functionality to users but aren't robust to LoRa denial of service attacks. Mesh LoRa provides a distributed networking layer below these LoRa mesh implementations while still supporting the protocols. Mesh LoRa is agnostic to the higher level protocols of the mesh implementation, while increasing access and anonymity of mesh participants.

As LoRa is broadcast based, LoRa better matches a distributed networking paradigm - leveraging the Store and Forward pattern over broadcast based channels. Mesh LoRa transmissions bubble up across the mesh toward reaching more distant participants. Where routing protocols expose the end-points of the sender and receiver, Mesh LoRa forwards content across the mesh - there are no sources or destinations, just distributed content (providing anonymity of usage).

Store-and-Forward Paradigm

Every Mesh LoRa node maintains a cache of Mesh LoRa packets labeled by a content identifier. To support universal mesh coordination, content identifiers should be globally unique.

When a Mesh LoRa node observes transmissions for a content identifier it only rebroadcasts (aka forwards) the transmission if it's cache doesn't contain the transmission - minimizing the usage of LoRa channels.

Shard participants that missed the original transmissions, can query the shard per content identifier - eliciting a re-broadcast of content. Query based re-broadcasts are lower priority, as the primary use of LoRa channels is to provide timely forwarding of new transmissions.

Robustness by using multiple LoRa Channels

Nodes without multiple LoRa radios will have to time-divide servicing LoRa channels. Under time-division servicing, it's likely that the node will miss LoRa transmissions on the other LoRa channels.

The Store-and-Forward query functionality allows participants to recover missed transmissions. As the query elicits a LoRa rebroadcast of transmissions, all shard participants on the LoRa channel are also updated - i.e. each query not only satisfies the query creator, but also satisfies other nodes on the LoRa channel (reducing their need to query).