[Battlemesh] mesh protocol for lora

[Jonathan Morton]

> On 4 Sep, 2016, at 13:52, Paul Gardner-Stephen <paul at servalproject.org> wrote:
> 
> In this context we don't want to reinvent anything unnecessarily.  In particular, I expect that we will be talking again with the amateur radio community to find out about what waveforms are good candidates for improving on our current proof-of-concept.

HF is certainly a challenging environment to get high data rates through.  That’s in addition to the fact that propagation on any given frequency will often come and go with the state of the ionosphere, on an hourly or daily basis.

My understanding is that a *low* baud rate, implying as many bits as possible per symbol, is desirable to counter burst noise and multipath effects, while multi-tone structure is also strongly advised to mitigate selective fading.  Heavy-duty FEC, including temporal interleaving, is mandatory to handle the extremely noisy and unpredictable RF environment on HF.

With those basic requirements established, you basically have a choice between OMFSK, which has the dual advantages of easy recognition by ear and not requiring a linear power amplifier, and MTPSK, which has theoretically superior SNR and throughput characteristics.  Lora, being a single-tone modulation (despite its chirp format), is not directly suitable, but a multi-tone version of it could theoretically be workable.

Obviously, to get good throughput, you will need to use a generous allocation of bandwidth.  Existing digital modes tend to be designed to fit within the bandwidth of a standard voice SSB radio, which seems to fit your use case.  Chat modes tend to accept a turnaround latency of several seconds, which may be excessive for networking, but this could be improved by several means, including FEC structures which account for the packetised nature of the data.

For example, MT63’s fastest configuration is 20 baud for 140 bps after correction, and occupies 2kHz.  Greater throughput could be achieved by a derivative MTPSK mode in the same bandwidth, by using a less redundant FEC scheme than a 7-bit Walsh-Hadamard function, and/or by using QPSK instead of BPSK per tone.  This would lose some desirable properties that MT63 possesses, but could yield as much as 1280 bps under near-ideal conditions with a conventional 2:1 FEC, or over 400 bps with an aggressive 6:1 FEC.  Careful FEC design and experimentation would be required to ensure such a mode is actually usable in practice, but this is a promising approach for use in good conditions.

OMFSK typically operates at 31.25 baud (resulting from a FFT over an 8kHz audio sample rate) and, at a similar 2kHz bandwidth, can fit 64 tones for 6 dibits per symbol; given a 2:1 FEC code, this yields 93.75 bps.  Greater throughput per bandwidth can be achieved by transmitting two or more tones simultaneously, eg. dividing the 64-tone space into four 16-tone channels gives 16-bit symbols and thus 250 bps after a 2:1 FEC, but this also reduces the power in each tone and thus the local SNR.  The same bandwidth would be occupied by a single 16-tone channel at 125 baud, and would achieve the same throughput, but with much less resistance to multipath effects.

To maximise robustness of an OMFSK signal, I would recommend assigning four more tone-frequencies to each channel than are strictly necessary to convey the given number of dibits.  Use one as a guard-band to the next channel, and never transmit on it - this will aid tuning.  The remaining three are used as a dynamic exclusion zone, so that each transmitted tone is guaranteed to be surrounded by eight “buckets” of silence.  In bad conditions, this can make the difference for getting the signal through.  This implies that for a 16-bit-per-symbol configuration you will require 79 tone frequencies, rather than 64, thus occupying about 2.5 kHz bandwidth at the same baud rate.

An alternative approach can be seen in FSK441, which uses a high baud rate to fit a usable transmission into a short time interval, accepting that high packet loss may result.  For a packet-based network, as opposed to a chat mode, this may be a valid strategy, since the network can be designed to retry packets thought to have been lost, and the reduced latency may be valuable.

I note that ALE 2G itself is an OMFSK mode, but uses a relatively high baud rate and a small number of tones.  It should be capable of 187.5 bps after 2:1 FEC.  As your linked article notes, the actual data rate achieved is much less than ideal, but this is not inherent to OMFSK, rather to substandard protocol layers on top of the basic modulation.  You could reasonably use ALE to locate a suitable channel, then switch to a more specialised mode for networking.

Of course, people who have been working more directly in this field will be more reliable sources of expertise than I am, but that should give you some background for understanding what they say.

 - Jonathan Morton