[Battlemesh] mesh protocol for lora

Jonathan Morton chromatix99 at gmail.com
Thu Sep 1 05:17:10 CEST 2016


> On 31 Aug, 2016, at 01:48, Kristoff <kristoff at skypro.be> wrote:
> 
> Up to now, APRS has typically been a "high-power transmitter on a high location" type of network where relative few but high-power nodes (e.g. 30, 40 to 50 watt)
> 
> My idea is to go the other way around and try to build a network of a lot of off-the-shelf VHF/UHF datamodules, cheap devices but running at much lower power-levels.
> 
> In practice, this means that a network would concist of a lot more nodes, so some kind of more intelligent "mesh-network" technology is needed. As the size of such a network (in number of nodes) is a lot larger then a regular APRS network, just flooding messages up to "x" steps away is out of the question.

I just took the time to read part of the APRS spec.  Some things are immediately obvious:

- APRS is already a mesh technology - but a “flooding” mesh rather than a “routing” mesh.  Network load is controlled by using a very low duty cycle (message updates every 10-30 mins) and a very limited hop count.

- The network purposely does not attempt to establish any kind of global routing of messages, though there is a rough hierarchy of “mobile node” -> “digipeater” -> “internet”.

- It is however possible to route a message through explicitly named nodes, or in a specified geographic direction; that APRS *does* establish the geographic locations of most nodes makes such source-routing comparatively straightforward.

- The usual physical layer is 1200bps FSK, over HF, VHF or UHF bands.  FSK is very simple to build hardware for, but sits a very long way off the spectral efficiency curve; generally a positive SNR is required, unlike Lora.  Amateur radio has long since progressed to more efficient modulations in “chat” modes; some are difficult to distinguish from background noise by ear, even when strong; some are usually easy to identify, but can still be decoded when inaudible.

- APRS is built around the AX.25 frame, which can be between 20 and 332 bytes long (if I’m counting it right). The address fields are remarkably long, 7 bytes each, and there is provision for up to 8 entries of explicit source routing.  The framing overhead is thus comparable to IPv4 - a bit on the high side.  At 300bps, a maximum-size frame would take 10 seconds to transmit, and a minimum-size one (establishing little information besides the node’s continued presence) costs two-thirds of a second.

- Practically all the fields in each packet are restricted to printable ASCII characters, which further reduces efficiency compared to a full 8-bit encoding.  This may in part stem from typical regulatory requirements for ham-radio transmissions to be cleartext and identifiable.  However I would not characterise APRS as “human readable”, nor as “optimised for machine parsing”.  Frankly, it’s a mess.

So I can see why exploring alternatives to APRS, which do roughly the same job, is an attractive idea.

The easy solution, of course, would be to send APRS AX.25 frames over Lora (instead of FSK) and have done with it.  You would get the same functionality as APRS and the use of mature software, enabling the use of lower-power transmitters, but without solving the RF congestion problem (in fact, making it worse due to the lower data rate and the longer reach of each transmission).  If your hardware can do FSK as well as Lora, it should be straightforward to test this idea.

Lora also has some interesting features which you might not have considered as part of your design:

- Two or more Lora transmissions can supposedly coexist on the same frequency at the same time, if they use different chirp rates; suitable hardware can decode them simultaneously (at an SNR penalty, of course).  Simpler hardware can lock onto any single transmission in the mix and decode that.  This could potentially simplify the MAC problem considerably, if nodes choose a chirp rate at random or cooperatively, eliminating the need for CSMA-CA semantics.

- Data rates can also vary, allowing faster/shorter transmissions where SNR is higher.  This is potentially very useful for improving performance in congested conditions, including some of APRS’ primary applications.  The very low 300bps rate can be reserved for sparse areas of the mesh, where long distances must be covered per hop, and for small discovery probes.

This appears to imply that “supernodes” with more capable decoding hardware may have a natural role in a Lora-based routing mesh in a congested environment, analogously to APRS digipeaters, but that “simple” nodes can still work perfectly well in sparse environments without assistance.  Routing meshes can (in theory at least) automatically discover and make efficient use of these distinctions, without needing to specifically designate any node as a repeater.  Conversely, mobile nodes wishing to limit transmissions to save battery power can avoid becoming repeaters by manipulating their reported routing metrics.

However, routing meshes are generally designed for reliable unicast messaging, not efficient broadcast.  APRS by contrast is optimised for broadcast, using it to mitigate the high packet error rate of FSK on an individual link - as long as at least one node hears a message correctly, it will be repeated and other nodes get another chance to hear it.  Designing a mesh to handle both unicast and broadcast efficiently is likely to be an interesting challenge.

If a node knows the neighbourhood routing matrix, for example, it might infer that after Nodes B and C repeated Node A’s transmission, Nodes D, E, F, G, and H which are its immediate neighbours have *probably* already heard it, so it’s not necessary to repeat it again.  The downside of such efficiency is that receive-only nodes, which are inherently unknown to the routing algorithm, might not be able to hear Nodes A, B or C but could have heard the extra transmission that was avoided.  You’ll have to make a decision on whether that’s important or not.

 - Jonathan Morton




More information about the Battlemesh mailing list